Service Blueprint

Artifact

A document that stacks staff actions, the invisible internal work, and the systems behind them underneath the flow a customer goes through.

Why it exists

A map that only draws what the customer experiences tells you where things stall and stops there. Once a stall is marked, the next question follows immediately: why does this part take four days? The customer's row records only that they waited, so the answer isn't in that row. A four-day wait and a four-hour wait look identical there — one cell marked as waiting either way.

Refund requests at Pagedeck worked exactly this way. Complaints piled up that it took four days on average between filing a request and hearing back, and in the meeting nobody could explain where the four days went. Sofia said she logged requests in the support tool. The finance owner said they checked that list once a day. Engineering said refunds were executed by hand. No single stretch had a delay in it. The four days were scattered across the gaps between stretches.

A service blueprint exists to put those gaps on one page. It hangs extra rows for the inside of the company below the customer's row, so you can count how many hands one request passes through.

What goes in it

A page is a horizontal time axis and five rows with fixed contents. Time runs left to right, and the further down you go, the further you are from the customer.

  1. Customer actions — what the customer actually did, in order. For a refund that's finding the charge, hitting the contact button, writing a reason, waiting, and getting an answer.
  2. Touchpoints — the places the customer meets while doing all that, which is a row of touchpoints laid out in time. Screens, notification emails and a support agent's reply all go here.
  3. Frontstage — the response on the side the customer can see. The automated acknowledgment email and the sentence an agent wrote belong on this row.
  4. Backstage — internal work the customer never sees. The finance owner checking the list, filing a cancellation with the payment processor, and recording it in the settlement sheet.
  5. Supporting systems — the tools and rules the three rows above run on. The support tool, the payment processor, and the refund approval policy.

The line between rows 3 and 4 is called the line of visibility. Above it are activities the customer knows exist; below it are activities they don't. When four days pass below the line and nothing is marked above it, the customer spends those four days feeling forgotten.

The two markers from the journey map carry over. A pain point goes where the customer stalls or turns back, and a moment of truth goes where an impression of the product hardens. Reading the document means looking at what internal work sits underneath each marker on the top row. A marker with nothing drawn below it usually means the bottom rows weren't filled in honestly.

Who writes it and who reads it

A product manager or service designer usually runs it, but no one person can fill it in. The people who know the bottom two rows are spread across departments. So instead of drafting it alone and circulating it, you put everyone involved in a room and fill it in together within two hours. Two hours is enough because nobody has to research anything — each person already knows their own row.

Who comes depends on the stretch. For refunds, that's sales and customer success, who receive the request, finance, who approves it, and engineering, who executes it. The sentence heard most often in that room is that someone didn't know a step existed. Nobody had ever counted that one request changes hands four times.

The material comes from outside the document. User research, meeting people to watch and ask, fills the customer rows, and the accumulated complaints and requests collected as voice of the customer (VoC) supply the stalls. One page carries one protagonist. You pick a single persona — several people's stories condensed into one — and draw the order that person goes through.

Three groups read it. Executives read it to decide which procedure to change, engineering reads it to find which manual step to automate, and customer success reads it to decide what to tell a waiting customer and when. It isn't a document to finish and pin to a wall. You pull it out when the stretch to fix is settled but the reason it behaves that way isn't, and when a procedure changes you edit that row.

How it sounds at work

"Let's blueprint just the refund stretch. Looking at the customer row alone doesn't tell us why it's four days."

Not a proposal to redraw everything, only to dig into the inside of the stretch that broke.

"That row is below the line of visibility. The customer doesn't even know this step exists."

Internal work taking a long time and a customer feeling abandoned are two separate problems.

"There are three places where this gets moved by hand. Automating one of them takes two days out."

Narrowing the thing to fix from someone's attitude to one specific point in the procedure.

After the refund complaints piled up, Mia pulled this document out at Pagedeck. She taped five rows across a meeting room wall and brought in Sofia, the finance owner and Theo to fill in their own stretches. Two hours produced a picture: one request changes tools three times and waits on a human check twice.

Most of the waiting sat in one place, where the finance owner checked the list only once a day. Fixing it took no new feature — an agreement to check twice a day, and one email that states the expected completion date at intake. Handling time went from four days to two.

What people get wrong

The most common reading is that this is a prettier version of the journey map. They share a horizontal axis and look alike, so that reading comes naturally. But they grow in different directions. A journey map gets longer sideways along the customer's time; a blueprint gets deeper downward into the company. One can be finished while the other is still blank, because they are filled in by different people. Miss that and you produce a map with the bottom two rows left blank and some color added, while the reason it's slow stays exactly where it was.

Trying to draw the whole service at once is the other common mistake, since the word map suggests something complete. But filling five rows across twenty-odd touchpoints produces a drawing that covers a wall, and standing in front of it settles nothing. Cutting out one stretch that broke — signup, payment, refunds — is what produces a decision.

Easily confused with

TermWhat it drawsHow it differs
Customer journey mapThe flow of learning about, using and leaving a productIt stops at what the customer saw and felt. Where things stall comes from there; why they stall comes from the blueprint's added rows

Where to go next

Last updated 2026-09-16