The customer said yes. What happens next?

01The gap between buying and being looked after

A customer signs, receives an automatic receipt and waits. The salesperson considers the job handed over. The delivery team is waiting for a brief. The customer is wondering whether anyone has started. Each person may be doing their assigned work while the experience between them remains unowned.

Customer experience includes these quiet stretches. A new interface can make buying easier while leaving the uncertainty after purchase intact. Begin by choosing one transition that customers actually experience: payment to confirmation, appointment to arrival, installation to support. Define the beginning and end in their terms.

02Map one handoff from both sides

Illustrative example: a small equipment-maintenance provider confirms a visit online. Its customer needs to know whether to keep a staff member on site and whether the equipment must be shut down. The confirmation says only that the booking was successful.

Draw four rows: what the customer does; what the customer sees; what the team must do; and what information or tool makes that work possible. At the booking step, the visible confirmation depends on a real slot, a named dispatcher and preparation instructions. If a dependency is absent, reassuring copy alone cannot repair it.

NN/g describes service blueprints as a way to connect customer touchpoints to the people, processes and supporting resources behind them. The useful move here is to map a narrow transition and inspect its dependencies, rather than attempt a poster of the entire company.

03Design the normal path and the exception

For the example, a better confirmation could identify the requested visit, state whether the slot is confirmed or still awaiting review, explain what preparation is required and provide a clear way to change the request. Any response window must reflect actual operating capacity.

Now try the uncomfortable version. The technician is unavailable. The customer entered the wrong site. The preparation instructions do not apply to this equipment. Who detects the problem, who contacts the customer, and what can that person actually offer? A handoff needs both an owner and a recovery action.

Do not solve uncertainty with a stream of messages. A useful update changes what someone knows or needs to do. Repeated notices with no new information can create more work for the customer.

04Try the service before automating it

Walk through a fictional booking internally, using no real customer data. Have someone unfamiliar with the process play the customer. Ask what they believe is confirmed, what they would do next and whom they would contact if plans changed. Record the unanswered questions without explaining away the confusing parts.

Then compare the map with a small, consented sample of real interactions. Staff accounts are valuable but do not prove what customers understood. Look for repeated requests for status, duplicate questions, missed preparations and preventable transfers between people.

A spreadsheet and a carefully written message may be enough to test the change. Automate once the responsibility and exception handling are clear. Otherwise the automation simply moves an ambiguous promise faster.

05Decide what improvement means

Choose an observable result tied to the transition: customers can correctly identify their next action; fewer requests need to be re-entered; unresolved handoffs become visible to an owner. Record the baseline and the period observed. A fall in support contacts alone is ambiguous: customers may be more confident, or they may have stopped asking.

The test is whether the customer and the team can act with less uncertainty. The finished map is useful only when somebody changes the service because of it.