How To Run A Service Blueprint Workshop in 5 Steps, Tips And Pitfalls

A customer emails to request a repair. They want to know when someone can come. Before your team can answer, someone has to identify the equipment, assess the problem, check technician availability and confirm the appointment. The customer sees one service, while several people and systems have to make it happen.

A service blueprint workshop brings those parts of the work into the same picture. For a business owner or team lead, a useful result is a shared map of one customer scenario and one improvement with an owner and a plan to test it. Bring records of the work and the people who understand it; the workshop can also reveal questions that need investigating afterward.

The five steps below use a fictional maintenance-request example to show what belongs on the map, how to investigate a failed handoff and where AI assistance might fit.

What is the Service Blueprint?

A service blueprint connects the customer’s experience with the work required to deliver it. A customer journey describes what the customer does and experiences; a blueprint adds the people, activities and dependencies behind those moments.

Set it out as a sequence across the page, with a separate row for each layer:

• Customer actions: what the customer does, such as sending a repair request or accepting an appointment.
• Frontstage actions: what staff or technology do in view of the customer, such as answering a call, sending an acknowledgement or offering appointment times.
• Backstage actions: work hidden from the customer, such as checking the equipment record or assigning a technician.
• Support processes: the work and systems that enable delivery, such as maintaining customer records and technician schedules.
• Evidence: the physical or digital things customers or staff encounter, such as an email, an internal ticket or an appointment confirmation.

The line between customer actions and frontstage actions marks their interactions. The line of visibility separates what the customer sees from what happens backstage. These distinctions, explained in Nielsen Norman Group’s service blueprint guide, help you trace a visible problem back to the work supporting it.

Why do I need a blueprint?

Use a blueprint when improving the customer experience requires understanding how work passes between people or teams. A complaint about a slow reply may begin with an incomplete request, an unclear responsibility or a scheduling constraint. Looking at the reply alone leaves those dependencies out of view.

In the maintenance example, a prompt acknowledgement could make the service appear responsive while the actual booking remains stuck. Mapping the request through to a confirmed appointment gives the team a way to discuss that gap. The map identifies something to investigate; it does not establish the cause until the team checks what happened.

Keep the exercise focused on an existing service or a clearly defined proposed one. If the team is still deciding what service to offer, it needs to resolve that question before trying to map detailed delivery steps.

Prepare the workshop before bringing everyone together

Choose one scenario and collect enough material to discuss actual work. For an existing service, that might include a recent customer request, the messages that followed, the relevant internal record and the steps staff took to resolve it. Include an example that encountered a problem, so the discussion can move beyond the ideal sequence.

Invite people who can explain the customer interaction and the work behind it. For the fictional maintenance company, that means customer support, the scheduling coordinator and someone familiar with technician requirements and the records they use. Include a person who can take responsibility for the next improvement. If a necessary role cannot attend, arrange to check its part of the map afterward.

Give one person responsibility for facilitating. Their job is to keep the scenario in scope, make room for different accounts and record unresolved questions. This preparation follows the practical emphasis of NN/g’s guide to service-blueprinting workshops: the meeting builds on customer and internal research, and further investigation may still be needed afterward.

A wall with sticky notes or a shared digital board is enough to begin. Draw the rows, leave room for the service sequence and agree simple labels for evidence, assumptions and open questions. Use words as well as colours so everyone can understand the labels. If a starting layout would help, Service Design Tools provides a blueprint explanation and template.

The five workshop steps

The sequence below adapts established blueprinting guidance into a practical workshop. NN/g’s broader five-step process also covers gaining support, gathering research and distributing the finished map. Some of that work happens before and after the meeting described here.

Step 1: Agree on one scenario and the result you want

Write the customer, starting point and finishing point where everyone can see them. Make the boundary specific enough that participants know which events belong on the map.

For the maintenance company, the scenario could be: an existing customer emails about faulty equipment, and the process ends when they receive a confirmed appointment. The repair visit, invoicing and contract renewal stay outside this first map. An urgent request may need a separate path if it changes who acts and what happens next.

Then agree what the workshop needs to clarify. “Improve customer service” leaves too much open. “Understand why requests wait between acknowledgement and a confirmed appointment” directs attention to a recognisable problem without assuming its cause.

Before moving on, ask participants to describe the scope in their own words. If one person is mapping an emergency response and another is mapping a routine appointment, settle that difference before continuing.

Step 2: Review the evidence and mark what you do not know

Walk through the example request and the records brought to the meeting. Establish what the customer asked, what the team did and where the available record stops. Distinguish a recorded event from someone’s explanation of why it happened.

In the fictional example, the email might name the customer’s site but leave out which piece of equipment has failed. The scheduling coordinator says a booking cannot proceed without that detail. A colleague says it should already be available in the customer record. Both accounts belong in the discussion; agreement by a show of hands would not establish what the record contains.

Mark the missing check on the board and assign someone to inspect the record. If the team cannot resolve it during the workshop, keep it visible as an open question. If the answer would change the sequence substantially, map the two possible paths rather than silently choosing one.

Let participants write their observations individually before discussing them together. That gives the facilitator something to work with beyond the first or most confident account. Before moving on, check that the board distinguishes recorded events, staff accounts and open questions.

Step 3: Map what the customer does and sees

Build the customer-action row from left to right. Add the visible service beneath each action, then the email, screen, document or other evidence associated with it. Use specific actions such as “customer sends equipment details” rather than a broad label such as “engagement”.

For the maintenance request, the customer sends an email, receives an acknowledgement, answers a request for missing information and eventually accepts an appointment. The visible service includes the acknowledgement, the clarification message and the appointment offer.

Keep waiting periods visible. If nothing reaches the customer while staff investigate, a blank space in the frontstage row may be an accurate part of the experience. Do not fill it with an update the team wishes it sent.

Read the sequence back from the customer’s perspective. Can someone explain what the customer is trying to achieve, what information they receive and what they need to do next? If the team is guessing how the customer understood a message, record that as something to validate with customers. An internally agreed map is not a substitute for their perspective.

Step 4: Connect the backstage work and support processes

Now work down from each visible interaction. Identify who prepares it, which information they need and what must happen before they can proceed. Add the systems and support processes they rely on, then connect the handoffs with arrows.

The following table is a simplified illustration of the fictional maintenance service, not a client case or an observed result. It shows how a customer-visible delay can depend on several layers of work.

Pay particular attention to the handoff from support to scheduling. What does “ready to schedule” mean? Who checks that the required details are present? Who contacts the customer if they are not? A label such as “send to operations” conceals these decisions.

Add policies where they affect the sequence. If a certain type of fault requires review before an appointment can be offered, connect that requirement to the relevant action. A delay may reflect a necessary check rather than a staff problem.

Finish by playing through the request from beginning to end. Ask each role to check its actions and dependencies. A usable first map should make a failed handoff traceable, even where an open question still prevents the team from confirming its cause.

Step 5: Choose one improvement and assign a test

Select a failure point that matters to the customer and that the team can investigate or change within the agreed scope. Use the evidence on the map to discuss its consequences and dependencies. Ask which problem each proposed improvement addresses, even if the group already favours it.

Suppose the maintenance team confirms that incomplete equipment details repeatedly interrupt scheduling. Its first improvement could be to clarify the information required before a request reaches the coordinator. That might mean changing the request form, the support checklist or the way staff prepare requests from email. The workshop has identified a choice to test, not a reason to buy software immediately.

Record a short improvement hypothesis. For this example: collecting and checking equipment details before the scheduling handoff should reduce avoidable clarification while preserving the accuracy of the booking. Then make the proposed test concrete:

• Name the person responsible for the test and the people whose work will change.
• Specify the requests included, the information that must be present and how exceptions will be handled.
• Establish a baseline, such as the elapsed time from request to confirmed appointment and the number of clarification contacts.
• Check quality alongside time, including incorrect equipment details, corrected appointments and extra review work.
• Agree a review date and the conditions for continuing, revising or stopping the change.

Keep the current map and the proposed change distinct. Otherwise, someone returning later may mistake the intended process for the process already in use. This step is complete when an accountable person can explain what will be tried, how it will be assessed and which unanswered questions must be resolved first.

Where AI assistance belongs in the blueprint

The maintenance example makes the division of work concrete. An AI-assisted step could extract a draft set of details from a customer’s free-text email and flag information that appears to be missing. Staff would check that draft against the original request, confirm ambiguous details and decide how to handle urgency or an exception. Missing equipment information should remain a question for someone to resolve.

Availability is a different task. The scheduling system can apply booking rules to recorded capacity. A proposed time still depends on accurate records and the company’s approval process; a plausible sentence generated by AI does not establish that a technician is available. Name the person authorised to make the appointment commitment, and show that responsibility on the blueprint.

Before testing AI assistance, compare it with a change to the form or checklist. If the difficulty is that nobody has agreed which details are required, that decision needs to come first. If the details arrive in varied emails and staff spend time interpreting them, a narrowly defined AI step becomes a reasonable candidate to evaluate.

Workflow design also matters beyond a single workshop. McKinsey’s 2026 global AI survey associates fundamental workflow redesign with stronger self-reported AI results. It does not test service blueprint workshops or establish that redesign caused those results. Use your map to decide what needs to change between the customer’s request and a dependable answer.

Common pitfalls in service blueprint workshops

Mapping how the service should work while calling it the current process. Keep desired changes separate. A tidy diagram can hide the problem you came to investigate.

Expanding the scope whenever another issue appears. Record related topics for later, but return to the agreed start and finish. In the maintenance example, an invoicing problem deserves attention without turning the booking workshop into a redesign of the whole company.

Letting seniority settle conflicting accounts. Different accounts may reflect different request types. Show those paths separately when the records support them; otherwise, assign someone to check.

Improving an internal handoff without checking the customer consequence. A request can leave one team’s queue sooner and still reach the customer later. Assess the complete scenario as well as the task being changed.

Leaving with an ownerless diagram. Before closing, confirm responsibility for the map, unresolved questions and the first test. If nobody can own the change, record that constraint rather than presenting the improvement as agreed for implementation.

After the workshop: validate and keep the map useful

Share the map with the participants and anyone whose contribution still needs checking. Ask them to correct the sequence, responsibilities and dependencies, then update the open questions. A short debrief should also capture what was missing from the session so the next discussion has better inputs.

At the agreed review date, examine the test against its baseline and quality measures. Less time spent on one task does not automatically mean less work overall: clarification, checking and corrections still count. Use what the test shows to decide whether to keep the change, adjust it or return to the problem. Update the blueprint when a change in roles, systems or policy alters how the service is delivered.

For a first workshop, begin with one recent request and the people who handled it. That gives you a concrete starting point for deciding what the customer needs and what the team should improve. Untaylored is an AI Transformation Studio covering AI strategy, transformation and build. If the map raises a decision about where AI could help, book a demo for an introductory conversation about the work and a suitable next step.