The Handoff Test: Is a Workflow Ready to Automate?

A workflow is ready to automate when its trigger, inputs, decisions, outcome and failure owner are clear. Test that by writing a short handoff for someone who has never done the task. Wherever they would need to ask a question, the automation also needs a rule, a review step or better information.

The note is a way to expose gaps before building. It is not a requirement that every real system fit on one page, or a substitute for the detailed specification that follows.

What belongs in a one-page workflow handoff?

Describe the work in the order someone performs it. Name the event that starts it, the information required, the steps, the result and the person responsible. Include what to do when a normal step cannot be completed.

Use the actual field names and working queue where they matter. “Update the system” leaves the next person guessing which record to change and what counts as a correct update.

You can start with this brief:

Task:
Trigger: What starts a run?
Inputs: What must be present, and where does it come from?
Steps: What happens, in order?
Decisions: Which rule applies, or who decides?
Finished means: What result can someone check?
Exceptions: What stops the normal path?
Failure owner: Who receives the issue and can resolve it?
Access: Which team-owned accounts are required?

Leave an answer blank when you do not know it. A visible gap is useful. A confident guess can turn into a requirement nobody intended to approve.

How do you run the handoff test?

Give the note and a redacted sample input to a teammate unfamiliar with the task. Ask them to explain the steps and expected result. If access allows, let them run a safe example in a test environment. Record the questions they ask without answering from memory first.

Each question identifies something the written process does not yet contain. “Which customer record?” points to identity rules. “Can I send this reply?” points to an approval boundary. “What if this field is blank?” points to an exception.

Revise the note, then try another example. A person following the brief should reach the same expected result without relying on the original operator’s private knowledge.

Use safe samples. The readiness test should not send real customer messages or change live records just to see what happens.

Which decisions need a rule, and which need a person?

A rule works when its input and result are explicit. Judgment is needed when the decision depends on context the process has not captured, competing priorities or consequences the team has not agreed how to handle.

Decision	Possible rule	Human boundary
Assign an enquiry	Route an agreed service selection to its owner	Unclear or mixed requests enter a review queue
Check required data	Reject or hold a record missing a required field	A person resolves conflicting information
Send an acknowledgement	Confirm receipt after the enquiry is saved	A person makes promises about scope or delivery
Retry a failed delivery	Reuse the original submission reference	Repeated unresolved failures go to the named owner

The boundary is part of the system. A review queue needs an owner and a clear way to resume work after approval. Otherwise, automation simply moves the bottleneck somewhere less visible.

AI assistance does not remove that need. If an assistant proposes a classification or draft reply, define what it may do unaided and which outputs need review.

What does a worked example look like?

Imagine a studio routing website enquiries. This is a hypothetical example. Its first handoff says: “Read the message, add the lead to the CRM and send it to the right person.”

That instruction hides several decisions. A returning buyer may already be in the CRM. A message may mention both services. A failed connection may leave the operator unsure whether a record was created.

The revised brief separates those issues:

• Save each valid enquiry with its own submission reference.
• Match a contact using the CRM’s agreed identity rule.
• Route a clear service selection to its named owner.
• Send mixed requests to a review queue.
• Record delivery confirmation before marking the enquiry delivered.
• Escalate unresolved delivery failures to the operations owner.

Now the repeatable work can be scoped. The team still decides how to respond to an unusual request. The website and CRM guide follows that complete path.

What should you test besides the normal run?

A normal example proves only that the normal path can work. Use examples that expose assumptions: missing data, conflicting information, a repeated request and an unavailable tool. Write the expected outcome before running each one.

Test case	Expected outcome
Complete, valid input	The result arrives with the correct fields and owner
Missing required input	Work pauses with a clear correction or review request
Same request delivered again	The action is not duplicated
Destination unavailable	The request stays recoverable and the failure is visible
Decision outside agreed rules	A person receives the case with enough context
Upstream field changes	The change is detected before incorrect output is accepted

The mechanism depends on the platform. For example, AWS Step Functions documents retry and catch behaviour. Those controls still need business-specific limits and an agreed response when retries do not resolve the problem.

How do you decide whether to build, clarify or keep it manual?

Build when the handoff is clear, test cases have agreed outcomes and the work removed justifies the maintenance. Clarify first when missing data or conflicting rules block a reliable result. Keep it manual when the task is infrequent, highly variable or depends mainly on judgment that cannot yet be captured.

You can also automate a stable portion. Preparing a report may be repeatable even when interpreting it needs a person. Gathering enquiry details may be repeatable even when deciding whether to accept a project is not.

Avoid an arbitrary waiting period. A process does not become ready just because it has existed for months. What matters is whether its rules are understood and whether the team can manage changes.

Our systems audit adds workload, cost and risk evidence to this readiness check.

What makes the handoff hold up after launch?

Keep the brief with the system’s operating instructions. Name who updates it when a form field, routing rule or connected tool changes. The next person should be able to trace a run, recognise a failure and find the recovery instructions without asking the original developer.

Review exceptions after launch. If the same exception keeps appearing, decide whether it deserves a written rule, a process change or continued human review. Do not silently stretch the automation beyond what the team agreed it could do.

Before handing it over, ask a teammate to explain the failure path as well as the successful one. That is a stronger sign of ownership than a demo in which everything works. What we hand over lists the files and access a team needs.

If the note reveals gaps you want to resolve, bring it to a teardown. You will have a concrete process to discuss before choosing a tool.

FAQ

Does every workflow need to fit on one page?

No. The one-page note is a summary that exposes missing decisions. Complex workflows still need detailed specifications, operating instructions and test cases.

Can I automate only part of a task?

Yes. Data collection, checks and routing can be automated while a person keeps the decision that requires judgment. Define that boundary before building.

Can AI fill in the missing rules?

AI can help draft or classify information, but it does not make an unclear business decision accountable. Define acceptable outputs, a review path and who approves consequential actions.

What if the process changes often?

Identify which parts remain stable. Automate those only if the team can maintain and test changes. If the central rules are still unsettled, clarify the process first.