Implementation and ownership
Scope one customer journey before you connect anything
Write an implementation brief with a starting event, permitted actions, records of truth, exclusions, and completion evidence.
Published · Collection dates are retrospective editorial dates.
Connecting a phone system to a CRM is a technical task. Making a customer request move safely from the phone to the right person is an operating design task. Begin with the second one.
A customer journey brief should explain what starts the work, what the system may do, where the resulting record lives, and how the business knows the request is complete. If those details are unclear, connecting tools can make the ambiguity move faster.
Keep the first brief to one journey. “Customer communication” is too broad. “An existing customer leaves an after-hours request for a routine callback” is specific enough to inspect.
Draw the path in ordinary language
For a hypothetical maintenance company, the first version might look like this:
Customer requests callback → system collects approved details → request is written to the service queue → queue owner accepts it → staff contact the customer.
Each arrow needs an explanation. What details are necessary? Which service queue? What makes a write successful? How does ownership become visible? What happens if staff cannot contact the customer?
The AI may own only the middle portion. Do not call the whole journey automated when people still perform the final work. Scope should describe both system and human responsibilities.
Basecamp's chapter on setting boundaries offers a useful principle for project shaping: constrain the work to a defined investment. Apply that by deciding which journey your team can implement and support before collecting additional feature requests.
Name the starting event precisely
The starting event determines what enters the workflow. A new message, a missed call, a customer reply, and a changed CRM field can all trigger work, but they are not interchangeable.
Specify the eligible population. The system might handle inbound calls routed after closing time, for one location, excluding matters already in an active specialist queue. Define those conditions in a way the implementation can evaluate.
Also define duplicate triggers. If a caller leaves a message and submits a form, should the business create two requests or link them for review? Do not assume the integration will know they refer to the same task.
Set an action boundary
List what the workflow can read, write, and promise. Read-only access and permission to change records create different consequences. A system that may collect preferences should not be able to confirm a booking simply because it can access a calendar.
| Brief field | Hypothetical entry | Acceptance evidence |
|---|---|---|
| Starting event | Eligible inbound call after closing | Routing test under the agreed schedule |
| Information collected | Name, callback number, request category, preferred contact window | Caller-confirmed fields in the record |
| Allowed action | Create a pending callback request | Correct queue item with an identifier |
| Prohibited action | Promise an appointment or price exception | Tests showing the boundary holds |
| Record of truth | Service-request queue | Staff can find and update the request there |
| Human owner | Next-shift service coordinator | Ownership acknowledgement is visible |
| Failure route | Approved fallback with an incident item | Simulated write failure produces recoverable work |
Use your own policies and systems. These entries illustrate a brief; they are not instructions for every maintenance business.
Choose the record of truth
A transcript is evidence of a conversation. It is usually not the best place to manage a queue. Decide which record the team will use to track status, assignment, and completion.
Then define how other copies relate to it. If the system sends an email notification, the email should not silently become a second task list. If staff update the CRM, the service queue needs a reliable way to reflect the change or a clear rule that it remains the authoritative status.
Keep customer-facing language tied to that status. “Request received” should mean the request was safely recorded. “Assigned” should mean a person or queue owns it. “Completed” should mean the agreed work happened, not merely that the conversation ended.
Design the unsuccessful path before launch
Walk through unavailable systems, incomplete details, and unavailable people. Decide which information can be kept safely, what the customer hears, and how the request is recovered.
Do not improvise a promise during failure. If the business cannot support a callback deadline, the system should not invent one to sound helpful. An honest pending state is more useful than reassurance staff cannot fulfill.
Bring the brief to the people doing the work
Have a frontline employee walk through a normal request and an awkward one. Ask them where they would need to search, ask a manager, or reinterpret the customer's words. Those moments reveal missing requirements more reliably than another abstract feature meeting.
Have the technical owner map each step to the necessary integration and permission. A connector should enter the plan because a defined step needs it. Avoid adding broad access now in case the project might use it later.
Freeze the brief for the first implementation, with a way to record changes. If a new request type is added, revisit permissions, tests, costs, and ownership. A small customer journey can become a large system through a succession of apparently minor additions.
The finished brief is a shared contract about the work. It lets operations, technology, and the supplier test the same journey against the same definition of completion.
Sources
For help defining this workflow, explore our workflow integration work.
Keep reading
