Show the Work a Customer Must Do to Adopt the Product

A deck that promises "setup takes a day" is usually describing the supplier's day. The customer's work sits in the gaps around it. Someone has to decide which of three logo files is the real one. Someone has to grant an access group. Someone has to be named as the person who approves a drawing. Someone has to own the Friday-afternoon case where a live bid needs an asset nobody has approved yet. None of that is installation, and all of it decides whether the product is ever used.

So the most useful thing a sales deck can do is split the transition into two columns and keep them split. Supplier work: accounts, connections, configuration, import mechanics, training delivery, setup support. Customer work: decisions, access, named owners, and hours from specific people who already have jobs. Then order the whole thing by what releases the next piece of work, and leave the unassessed parts visible instead of filling them with a reassuring number.

That's the argument. The rest of this is how to make it specific enough to argue with.

The worked example below is invented. Cavill & Ross is a fictional architecture practice of about 120 people in three offices, and the supplier, the files, the roles and the open questions are all stipulated here rather than observed. No customer data, migration record, timetable or readiness test has been examined. It exists to show the shape of the reasoning, and a real version of it would need authorized workflow records, a written supplier scope, and confirmation from the people named as owners.

Define usable in this customer's workflow

The first slide that usually goes wrong is the one that treats "installed" as "done." Accounts created, software deployed and data imported are intermediate states. They may be necessary and still leave nobody able to do their job without a workaround.

So pick one bounded workflow and define the endpoint inside it. Not the whole organization — one task, done by one kind of person, that the product is supposed to make possible.

At Cavill & Ross, the practice wants an asset-approval library: a place where brand files, photographs, drawing exports and project sheets live with a status attached and a named approver. The tempting endpoint is "the library exists." The usable endpoint is narrower and much more useful: a bid coordinator can assemble a bid pack — six approved photographs, the current logo and two project sheets — without emailing anyone to ask which file is current.

That sentence does a lot of work. It names the person, the task and the test. It also implies a counterfactual the deck should state plainly: today, that person emails the marketing coordinator, waits, and sometimes uses the version they already had. If the new product doesn't remove that email, the transition hasn't landed, however smoothly the import ran.

The same paragraph should say what has to keep working while all this happens. Bids and planning submissions go out weekly and cannot pause for a migration. The existing email approval route stays alive until the library is trustworthy. The shared drive — the S: drive, in this practice — doesn't get frozen. A clean future-state picture that hides present obligations is a picture of a different company.

Expose the customer-side changes

There are four things to trace, and it helps to trace them one at a time rather than bundling them into "change management," which explains nothing.

Information to move. The practice's brand files sit across three offices and about a decade of folders, with four different naming conventions because each office started its own way. Two files both look like the current logo. Nobody can say which one wins without asking the marketing coordinator, and she is not sure either. The supplier can run an import. The supplier cannot decide which file is authoritative, because that isn't a technical question — it's a claim about what the practice has been publishing. Importing everything produces a library where both logos sit with equal standing. That is worse than the drive, because now the wrong one looks official.

People to learn. The bid coordinators need to understand what the status labels mean and what to do when the file they want is marked superseded. The approvers need to know what they're signing. That's customer time from named people, and the deck can say so without pretending it's covered by a training link.

A system to connect. Single sign-on and a connection to the practice's storage. The supplier configures; the customer's IT grants. Somebody creates the directory group and hands over credentials. Access is a customer act even when it takes four minutes.

Someone to own exceptions. A bid goes out Friday. The photograph it needs has never been approved. Today the marketing coordinator says yes informally, and the absence of a rule has never caused a visible problem. Writing it down creates a decision the practice has been avoiding: is that her call, the practice manager's, or does the bid get a different image?

The distinction underneath all four is the one worth putting on a slide. Possession is not readiness. The practice already has the files, the institutional knowledge of who really approves what, and the access it would need to grant. Having information somewhere in the organization is not the same as having it selected, cleaned, authorized and interpreted. Between "we have it" and "the supplier can use it," a person has to make a judgment. That judgment is the customer's deliverable. A dependency doesn't become supplied just because the raw material exists.

Put dependencies before reassuring dates

Once the customer-side work is visible, order it by what releases the next piece of work. Then label each item honestly, because a plan that runs standard work, bespoke configuration, a guess and an unknown down one column is not a plan.

Four labels are enough, and they should look different on the page.

Standard process. Accounts, single sign-on, the base workflow, the supplier's own repeatable work. These run on the supplier's schedule and depend mainly on the customer completing paperwork on time.

Customer-specific configuration. The approval fields, the asset classes, the routing rules. A supplier builds these, but the specification comes from customer decisions. The practice has to say what counts as an asset class and who approves each one before anything can be configured.

Estimate. The import. And here the honest content is that there is no basis for the estimate yet, because nobody has counted the folders or agreed what qualifies as an asset. "Estimate pending a count" is more useful than a number, since a number invites the customer to plan around it. The count itself is customer work — someone has to spend the hours.

Unassessed requirement. Whether drawing exports can carry an approval status at all, which depends on how the offices produce those exports. An unassessed requirement must not be scheduled as though it were standard, because it might turn into configuration, or into a different answer about what's in the first release.

Now look for the controlling dependency. For Cavill & Ross, it's the authoritative-file decision. Nothing can be imported until it's made; the import gates the training, because you can't teach people status labels against a library that doesn't yet exist. The decision depends on the marketing coordinator and the two current studio managers spending an afternoon they haven't scheduled. The practice has three offices; two have a studio manager, and the role in the smallest office has been vacant since the incumbent retired last spring — which is also why drawing approvals have no clear owner in that office. This is exactly the kind of fact a deck should surface rather than smooth over. If the first decision isn't scheduled, the timeline below it is describing a sequence that hasn't started. Saying that is more persuasive than a date, because a buyer can act on it.

Two things are worth borrowing from UK public-service practice here, cautiously. The GOV.UK Service Manual's guidance on how the beta phase works, checked 8 September 2026, treats support capacity, transition away from an existing service and dependencies across organizational boundaries as named parts of service development rather than background conditions. Read as a planning lens, that's the habit this section is arguing for: support and legacy transition get written down and owned. It is public-service development guidance, not a US commercial rule, and it contains no duration anyone can borrow for a commercial rollout. It's a prompt to look for these categories, not evidence about this or any other customer's readiness.

Separate transition work from continuing operation

The next slide is the one that decides whether the customer's commitment looks like a project or like a permanent addition to somebody's week. Both may be true — they need to be shown separately.

Work that ends when adoption completes. Deciding which files are authoritative. The initial de-duplication. Creating the access group. The first import. Initial training. Running the old email route alongside the new library. The migration engineer the supplier parks on the account for the first weeks. All of it is real, and all of it stops.

Work that remains. Reviewing exception requests when a live bid needs something unapproved. Bringing new starters into the approval rules. Retiring superseded assets so the library doesn't slowly become the drive again. Re-checking statuses when a project is re-issued and old files resurface. The last one is easy to underestimate, because the whole point of the product is that statuses stay true, and statuses stay true only if someone maintains them.

The mistake to avoid is letting the first list imply the second is small. Supplier setup assistance is time-boxed by definition. Its ending is not evidence that the continuing work disappears; it's evidence that the continuing work was always the customer's. A deck can say, in the customer's own terms, "we'll get you in, and here is the exception review that stays with you." That's not a warning. It's the information the buyer needs to decide whether to commit, and it beats discovering it in month three.

This isn't an argument for designing the customer's staffing model inside a sales deck. The operating plan belongs with the customer, and the deck only needs to name the recurring obligations it creates, without pretending to size the team around them.

Turn the gaps into an honest readiness conversation

Every material unresolved responsibility should appear next to the transition it affects, with a person who can answer for it. Not a risk register — a short list someone can actually work through.

The demo question and the readiness question are different, and the deck should keep them apart. Suppose the supplier ran a convincing session with sample assets: an image moved from draft to approved in three clicks, the audit trail appeared, the notifications fired. That answers can the tool route an approval? It doesn't answer do the studio managers have the time and the mandate to be the approvers? A completed demo is evidence about the product. It is not evidence about the organization, and it should never be allowed to close an item in the table above.

The same restraint applies to what the deck claims overall. It can support a judgment about whether to commit and what to assess next. It isn't a security review, an accessibility conformance statement, a migration guarantee or a certification that the practice can implement the thing — and saying so costs far less than being wrong about it later.

Ending where the buyer can act

The useful end of this is not a promise of effortlessness. It's a transition the customer can question and resource, with its unresolved inputs still showing.

For Cavill & Ross, that means the next move isn't signing or not signing. It's putting five questions in front of five people: which logo, which approver, which access, which exception owner, and whether the exports can carry a status at all. Four of those answers are free afternoons. One of them may change what the first release contains. Together they tell the practice what it's actually committing to, which is more than a date ever could.

Adoption becomes credible when its work is visible. It becomes believable when the people who have to do that work can see themselves in it, and can say yes to the part that is genuinely theirs.

Frequently asked questions

Why is 'installed' not the same as 'usable'?

Accounts, deployment and import are intermediate states; they can leave nobody able to do their job without a workaround. Define usable inside one bounded workflow. For Cavill & Ross, that means a bid coordinator can assemble a bid pack—six approved photographs, the current logo and two project sheets—without emailing anyone to ask which file is current.

What customer-side work should an adoption deck expose?

Four things: information to move, people to learn, a system to connect, and someone to own exceptions. The practice may possess files, knowledge and access, but possession is not readiness. Between 'we have it' and 'the supplier can use it,' a person must make a judgment; that judgment is the customer's deliverable.

How should dependencies be ordered and labeled?

Order them by what releases the next piece of work, and label honestly: standard process, customer-specific configuration, estimate, and unassessed requirement. 'Estimate pending a count' is more useful than a number. The controlling dependency in the example is which files are authoritative; until that decision is scheduled, the timeline describes a sequence that has not started.

What is the difference between transition work and continuing operation?

Transition work ends when adoption completes: deciding authoritative files, initial de-duplication, creating access, the first import, initial training, running the old email route alongside the new library. Continuing work remains: reviewing exception requests, bringing new starters into approval rules, retiring superseded assets, and rechecking statuses when projects are re-issued. Supplier setup assistance is time-boxed, and its ending does not mean the continuing work disappears.

How should a demo and unresolved readiness items be treated?

Keep them apart. A convincing demo answers whether the tool can route an approval; it does not answer whether studio managers have the time and mandate to be approvers. A completed demo is evidence about the product, not the organization, and should not close an open readiness item. The deck's end should put questions to named people: which logo, which approver, which access, which exception owner, and whether exports can carry a status.

Further reading

• Build a Sales Deck Around the Customer’s Decision, Not Your Company History — Before rewriting the whole deck, use this to place supplier and customer effort inside the buyer’s decision sequence rather than a company history.
• When Not to Demo the Product Yet — Use when the room is pressing for a demonstration before readiness is settled; it ties showing to a specific claim and allows deferring what cannot yet be observed.
• Pitch a Customer Pilot With a Decision at the End — When unresolved readiness answers need a bounded next decision, this turns them into a pilot proposal with entry conditions, evaluation criteria, and a named chooser.