Why a demo predicts little
A demo runs on material you selected yourself: a tidy email, a complete transcript, a document without scans or signatures. A client process runs on whatever comes in that day. The difference between the two is where almost every automation project gets stuck, and the model is rarely what falls short.
So treat the step from demo to process as a series of gates rather than an implementation. Each gate is a question with an answer you can write down. If you cannot pass it, you know exactly what is missing.
The seven gates
- Real input. Does the workflow run on twenty random cases from the past month rather than selected examples? Deliberately include messy ones: forwarded chains, attachments without a text layer, unfinished sentences.
- An owner for each step. Who reviews the proposal, who approves it, who intervenes if something goes wrong? A workflow without a name behind every step stops as soon as someone goes on vacation.
- The control level. Does the workflow only read, propose with human approval, or execute with a log of every step? Choose this per step, not per project.
- The way out when uncertain. What does the workflow do when it does not know? An explicit route back to a person is a functional requirement, not a nice afterthought.
- Permissions and visibility. Can the workflow see everything the requester may see, and nothing more? Existing permissions remain authoritative; a connection that bypasses permissions solves one problem by creating a larger one.
- The log. Can you see, for each run, which source was read, which proposal was made and what happened to it? Without that, you cannot investigate a deviation or change a control level based on evidence.
- The second time. Can someone other than the builder set up the same workflow for a second client or department using only the configuration and documentation? If not, you have a demo with a longer lifespan.
What to record for each gate
Keep it short: about three lines per gate. Which question, which answer, who provided it and on what date. That document is not a formality — at delivery, it is the only thing that still explains why one step may be automatic and another may not.
Gates you do not pass are just as valuable. A gate marked "not yet" is an explicit scope limitation rather than a surprise at the first failure.
The order is not optional
Gates 1 and 2 always precede the rest. Choosing a control level for input you do not know, or devising a fallback without knowing who is at the other end, produces paperwork that gets ignored at the first exception. Gate 7 comes last and determines whether you have a solution or an assignment.