01 / Observe
Pick a real journey
Choose a common request that crosses a location or team boundary. Note where it starts, where it ends, and every person involved.
A field guide for multi-location service teams
Configure first, and the handoffs get lost.
When each location handles a customer differently, a shared CRM needs more than a list of fields. Map the journey first so the right context can follow the customer between people and places.
Explore CRM workflowsStart with the work. Then decide what the software must support.
Field note / 01
ILLUSTRATIVE EXAMPLE
Customer journeyAcross locations
01 / IntakeCustomer makes contact
02 / RouteLocation takes ownership
04 / Follow-upNext action is clear
03 / ServiceContext travels with the request
Ask here ↗Who picks this up when the first location cannot?
The decision framework
Draw the route before choosing the tools.
Bring representatives from the front line and central operations together. Use a recent customer request as a starting point, then trace what actually happens rather than what the procedure says should happen.
02 / Trace
Mark each handoff
Record who owns the next action, what information they need, and how they know the work has arrived.
03 / Compare
Find local differences
Ask locations which variations reflect genuine service needs and which exist because teams lack a shared process.
04 / Decide
Turn gaps into criteria
Write requirements as scenarios a vendor can demonstrate, including exceptions and the people responsible for resolving them.
Margin noteInclude the messy cases. A request sent to the wrong location can reveal more than a perfectly routed one.
From map to requirements
What should the CRM help people see and do?
Use the map to evaluate software against your service process. These are questions to investigate, not assumptions about any particular product.
01
A shared customer record
List the context a second location needs before speaking with a customer: prior conversations, open requests, and relevant service history.
Evaluate: Can authorized teams find and understand that context without relying on a colleague to retell it?
02
Ownership across boundaries
Define who accepts a request, who covers an absence, and what happens when a customer contacts a different location.
Evaluate: Can the process show the current owner, the next action, and a clear route for reassignment?
03
Local context, common language
Agree on a small set of shared stages and essential information. Identify where locations need different details to serve their customers.
Evaluate: Can the proposed setup accommodate necessary differences without making records hard to compare?
04
Visibility for follow-through
Decide what managers need to review, such as requests awaiting an owner or follow-ups that have not been completed.
Evaluate: Can teams find these items in a way that matches their responsibilities and access needs?
Three perspectives
The same journey looks different from each seat.
Test requirements with the people who will use them. A useful map makes the work visible at each point, not just at headquarters.
A customer calls another branch.
What can the person answering see about the original request? Agree on the minimum context needed to avoid asking the customer to repeat the whole story.
An assigned colleague is away.
How does the team identify work that needs attention and transfer it? Map the decision to reassign, including who is allowed to make it.
Service practices differ by site.
Which differences matter to customers, and which make oversight harder? Separate essential local flexibility from stages that need a shared definition.
Your selection brief
Give every requirement a reason to exist.
Before comparing CRM software, turn your map into a short brief. Use it to guide conversations and keep configuration decisions tied to real work.
Return to the mapping stepsEssential
Protect the handoff. Describe what must be visible and who must act when work moves between locations.
Important
Support meaningful variation. Document local needs and ask how each could be accommodated without obscuring the shared process.
Explore
Question the extras. For each proposed capability, identify the task it supports and who would use it. Set aside anything without a clear owner or use case.
Validate
Walk through an exception. Ask to see how a misrouted request would be found, reassigned, and followed up in the proposed setup.