Put automation scope on one page before you buy.
It looked capable in the demo. After the contract, the awkward cases still live in inboxes and nobody can say what success looks like. Usually the tool wasn't the problem. The job was never written down, and one page would have done it.
Before you buy or build automation, fill one page: case type, handoff, owners, three real exceptions, success evidence in the system of record, and explicit non-goals. Use that page to interrogate demos. A feature grid without exceptions and evidence is not a scope.
You did not buy a bad logo
The tool looked capable on the demo path. After the contract, the awkward cases still live in inboxes, ownership is unclear, and nobody can say what success looks like in the system of record.
You did not buy a bad logo. You bought an underspecified job. Put the job on one page before the next demo or the next build ticket.
Six blocks
Case. The one repeating type you are tempted to automate. Not a department.
Handoff. What moves, from whom, to whom, and how the next person knows it is ready.
Owners. Who accepts the next action, who may override, who is accountable when a connected system is down.
Three exceptions. Real ones, from the last month. Where they go, and what evidence travels with them.
Success evidence. What would be true in the record if this worked. Not a feeling after the demo.
Non-goals. What this purchase will not do. If non-goals are empty, the scope will expand to match the vendor's feature grid.
Fill the page with the operators in the room. Not only with the vendor present.
How the work moves
Six blocks on one page
- Case type
One repeating ordinary path and the systems it touches.
- Handoff
Sender, receiver, and what acceptance means.
- Owners
Process owner, operators, builder boundary.
- Exceptions
Three awkward cases with owner, evidence, return path.
- Success evidence
Proof in the system of record—not chat confidence.
If the exception path is blank, you are not buying automation—you are buying a demo.
Use the page in the buying conversation
Ask the demo to show your handoff, your exception, and the record that would prove success. A feature grid that cannot land your three exceptions is not a scope. It is a brochure.
Refuse a purchase that cannot show where incomplete work goes. The logo is irrelevant until those blocks are filled.
Decision guide
Demo path vs scope one-pager
| Consideration | Demo-led buy | One-pager-led buy |
|---|---|---|
| Starting artifact | Feature grid and happy-path video. | Filled handoff, owners, exceptions, evidence. |
| Awkward cases | Deferred to “phase two.” | Named on the page before money moves. |
| Success | Applause in the room. | Observable record change operators trust. |
| Non-goals | Implied; drift under pressure. | Written; expansion requires a new page. |
| After signature | Scope arguments restart. | Page travels with the ticket or contract. |
Map first
Trace one real item before you compare products. The page is easier to write after you have watched the loop than before. It is also harder for a demo to wave away.
If two systems disagree, write which one people trust. That disagreement is part of the scope, whether or not the vendor has a slide for it.
What a blank page would have caught
An owner who is "the team." An exception path that is "we'll handle it." Success that is "users like it." A non-goal list that was never written, so the implementation tries to automate the whole department.
Those blanks are cheaper on a page than in a contract.
Put this into practice
Pick one case type. Fill the blocks with the people who do the work. Take the page into the next demo. If the vendor cannot speak to the exceptions and the evidence, you are not behind. They are early.
When the page points at process design rather than a catalog SKU, the work sits under business process automation.
Related work: Sutton Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.