Demonstrate a Service With the Human Work Still Visible

Two clicks. That's what most service demonstrations ask for. A customer describes a problem, presses submit, and the next screen says the visit is confirmed. Nothing false was said, and everyone in the room has just been handed a slightly wrong picture of how the service works.

The repair is not a longer demonstration. It is a demonstration with the work outside the interface still attached to the work inside it. Follow one customer task from the request to its completion. Name who acts at each step — customer, software, staff, outside provider — and keep the waits that change what the customer can expect. Then show a second, compact view beside the screen for the work that never appears on it.

That is the whole method in a paragraph. The rest of this article is what it takes to follow it without accidentally promising something the service cannot do.

The service used below is invented. It is not a description of any company's workflow, and its timings are fixed so the sequence can be followed from one paragraph to the next.

Start with one task and its ending

A demonstration that begins with interface features — the dashboard, the notification bell, the status chip — tends to spend its length on the parts that are easiest to show and least informative. Begin instead with a need and a finish line.

The need: a customer's dishwasher is leaking from the door, and they want someone to fix it. The finish line, for this service, is a confirmed visit window that a technician has actually accepted. Not a submitted request. Not a queued job. A window with a person behind it.

Those are different claims, and the difference is the whole lesson. A submitted request is something the customer did. A confirmed window is something four parties produced.

So name them before you build anything. In the fictional service: the customer describes the fault and the address. The software validates the address, queues the request, and sends messages. A coordinator — a person, employed by the service — reads the request and decides whether the partner network can take it. A technician, an independent business in that network, accepts or declines a specific window on their own schedule.

Four parties, one sentence each. That's the cast list. If you can't write it, you don't yet know which parts of the demonstration you're about to hide.

Put both layers on one sequence

Now place everyone's actions in time, not in categories. Here is the fictional sequence at the length it actually takes.

Five of those eight rows say the same thing: nothing changes. The screen the customer is looking at is static for roughly four hours, and during those four hours a coordinator and an outside technician decide whether the booking will exist at all.

That is the pair of views. On the left, a customer experience with two visible moments. On the right, the reason it takes four hours. The Nielsen Norman Group article Service Blueprints: Definition separates customer actions, frontstage work, backstage work, and support processes. That separation is a useful naming convention here, and worth borrowing. What's used here comes from the article's text rather than its diagram, and the article itself is a practitioner design method — it says nothing about any particular company's workflow, costs, staffing, or ability to run at scale. It gives you lanes to sort work into. It does not tell you what goes in them.

Label the lanes however you like, as long as a reader can point at any step and say who did it. The failure mode is not a missing lane. It is a step that appears in the customer lane and was performed by a person.

Name the handoff, and don't smooth over the wait

Two places in that table carry almost all of the risk: 10:40 and 13:20. The coordinator's review, and the technician's acceptance.

For each handoff, be able to answer four questions out loud.

Who receives the task, and what do they need? The coordinator needs the appliance type, the address, and enough of a symptom to let a technician price and prepare the visit. The technician needs the address and a window that fits their route. Neither needs the customer's account history, and neither should have to go looking for the address.

What is the customer told, and is it a promise or an acknowledgment? "Request received" is an acknowledgment. "Confirmed: Thursday, 8–10 a.m." is a completion. They are not the same kind of message, and customers read the first one as progress toward the second. A demonstration that shows one immediately followed by the other, with the queue and the review deleted, teaches the audience that the two are adjacent. They aren't. The gap between them is the service.

What does the customer see while they wait? In the fictional service, the screen does not change for four hours. If the demonstration never shows that stillness, the audience will reasonably assume the confirmation arrives in seconds, and someone will later promise a customer something the workflow cannot deliver.

What if the handoff fails? The technician can decline Thursday. Then the request stops being a queue item and becomes a coordinator's task: choose another window, check whether the customer's stated availability can absorb it, and decide what to tell them. Software can send that message. Someone still has to write what goes in it.

The confirmation window in this example — one business day — is part of the invented scenario's wording, not a benchmark and not a number I measured anywhere. That distinction matters more than it looks, because a demonstration that adds its own turnaround time is making a promise on the service's behalf. Use the service's declared condition. If there isn't one, the honest screen says something like "we'll be in touch," which is a weaker promise but a keepable one.

Label what you staged

Demonstrations are built, not observed. Every one of them contains things that did not happen on the day. None of that is dishonest. Unlabeled, all of it is.

Five labels cover most of it, and each takes one sentence.

Prepared records. "This request was written by our team. No customer wrote it, and this isn't a customer's account." Said once, at the start, this costs you nothing and prevents a long argument later.

Work finished before the meeting. "The coordinator reviewed and approved this job yesterday, so the confirmation you're about to see is genuine." This is the most common staging in service demos, and it is genuinely fine — the step moved earlier in the calendar, it didn't disappear.

Compressed time. "In this room, those four hours take about fifteen seconds. On Monday morning, they took four hours." If you only say one of these five sentences, say this one.

A colleague playing a role. "Sam is playing the coordinator. The screen is real; the queue behind it is a copy." Note this for the exception case below especially. A chatbot animation standing in for a staff decision turns a judgment into a piece of interface.

Pre-written messages. The clarifying question, the customer's reply, the confirmation — if your team wrote them, say so.

Now the exception, because a smooth demo will not show you one. A second fictional customer writes: "Dishwasher broken. Please send someone." No model, no symptom.

At 10:55 on Monday the coordinator sends it back: which model, and what happens when you start it? The rating plate inside the door usually has the model number. The customer replies Tuesday morning. The coordinator reviews the reply at 09:05, forwards it, and a technician accepts a Friday window at 10:30.

Notice what that round trip does to the promise. The request arrived Monday at 09:31 and said the service would confirm within one business day — Tuesday, 09:31. The confirmation goes out at 10:36. In this invented case the service missed its own stated window by about an hour, because the wording doesn't cover requests that are waiting on the customer. The return-for-clarification is a person's decision about what a technician can accept. It isn't error handling, and it isn't a button. If your demonstration renders it as a status change the software performs by itself, you've deleted the human judgment and a missed promise in the same gesture.

One exception is enough. It shows the audience that staff decisions change what happens next, which is the point you are trying to land.

What the demonstration leaves standing

Come back to the original need and account for it. The customer wanted a working dishwasher. What they have is a visit window and a technician's acceptance behind it. The software validated, queued, and messaged. The coordinator read and routed. The technician committed a morning. Two people did the work that made the booking real, and the customer did very little.

That is the picture to leave the room holding, and it's a picture the audience can use. They can say who does what. They can point at the wait and say why it's there. If a job goes wrong later, they can name who owns a problem at the boundary — the coordinator, if a technician declines; the service, if its wording promised something the workflow can't deliver.

It's also, deliberately, a small picture. One invented request, one review, one acceptance, done at a pace the people involved chose. It tells you nothing about how many coordinators the service needs on a Monday, what the four hours look like in a busy month, what the arrange-ments cost, or whether a partner network's acceptance rate holds up. Those are claims about capacity and reliability, and the only thing that supports them is measurement under real conditions. A single carefully prepared instance is a demonstration of a workflow. It is not a demonstration of a business.

So put the clock in the demo. Let the audience watch the customer's screen sit unchanged while two people decide, and say the elapsed time out loud rather than letting fifteen seconds stand in for four hours. That pause is the least cinematic part of the demonstration and the most useful thing in it, because it's where the audience finally learns where the service actually happens.

Frequently asked questions

What is the finish line for the invented service demo?

The finish line is a confirmed visit window that a technician has actually accepted—not a submitted request or a queued job. For the dishwasher example, the customer wants a leaking door fixed, and the confirmed window has a person behind it. Four parties produce it: the customer, the software, a coordinator, and an outside technician.

How should the customer view and off-screen work be shown together?

Place everyone's actions in time rather than in categories. The invented sequence shows what the customer sees alongside work happening off screen: the customer submits, software validates and queues, a coordinator reviews and sends the job, and a technician accepts. Five of eight rows say nothing changes; the customer screen is static for roughly four hours while two people decide whether the booking will exist.

What four questions should be answered for each handoff?

Who receives the task and what do they need; what is the customer told, and is it a promise or an acknowledgment; what does the customer see while waiting; and what happens if the handoff fails. A technician decline turns the request into a coordinator's task: choose another window, check availability, and decide what to tell the customer. The invented vague-request exception shows a coordinator sending it back for model and symptom; the return is a person's decision, not error handling or a button, and in that case the service misses its stated one-business-day window by about an hour.

What should be labeled in a service demonstration?

Label prepared records, work finished before the meeting, compressed time, a colleague playing a role, and pre-written messages. Say especially that compressed time is compressed: four hours in the room may take about fifteen seconds, but on Monday it took four hours. A colleague playing a coordinator should be named, and pre-written messages should be identified as written by the team.

What does the single invented instance not prove?

It does not demonstrate capacity or reliability: how many coordinators are needed on a Monday, what the four hours look like in a busy month, what arrangements cost, or whether a partner network's acceptance rate holds up. Those are claims about capacity and reliability, and only measurement under real conditions supports them. A single prepared instance demonstrates a workflow, not a business.

Further reading

• When Not to Demo the Product Yet — Use this when a polished demo is standing in for operational readiness, to sort steps into exists, proposed, or unverified and adjust the commitment.
• Pitch a Customer Pilot With a Decision at the End — When someone asks for evidence beyond the demo's single instance, this distinguishes a demonstration from a pilot and sets the comparison and decision rules in advance.