State what the workflow is for, so every rule after it has something to be right or wrong about.
3a · business outcome
Define the outcome the workflow must deliver
Start with the example, then try it yourself. The last case is optional practice.
Meet Samir.
Samir follows what happens after a decision. He helps name the next owner, check permission to act, and confirm that work reached its destination.
Samir · Workflow operator
The case
A workflow that nobody can say is working
Workflow success means a business outcome was confirmed, not simply that every configured step ran.
Documented purpose
"Make sure leads get followed up"
Steps
Five, all firing correctly
Reported success rate
Ninety-something percent
Meetings booked
Nobody has the number
Question that ended the review
"Working compared to what?"
Your task
Choose the event that proves the outcome. Name its owner and record what to do when no conversation is booked.
Need a little guidance?
You’re done when: The workflow has one observable completion condition beyond “the automation ran.”
A workflow can execute perfectly and still fail the business.
Need a reminder? Reopen the worked example
Watch one example first
A workflow creates a draft and a task. Those steps ran, but neither proves the buyer received a response. The seller owns confirming delivery and the intended follow-through.
Why this follows from the evidence
Technical completion describes configured steps. A business outcome needs its own observable evidence. Name what “done” means before designing the path.
GTM Lab
Saved locally
Workflow Specification · 0 of 8 sections started
Saved locally to your browser.
Case evidence
A workflow that nobody can say is working
Documented purpose
"Make sure leads get followed up"
Steps
Five, all firing correctly
Reported success rate
Ninety-something percent
Meetings booked
Nobody has the number
Question that ended the review
"Working compared to what?"
The review above ended on a question nobody could answer. Write the outcome that would have answered it.
Workflow workbench
Follow one request to a real outcome
Mark the event that proves the business result, name its owner, and record a useful non-result when no conversation is booked.
Choose the outcome
Machine steps are not the outcomeFollow the example events in time order. No live integration runs here.
09:00
Request qualifies
The workflow is eligible to begin.
Supported
09:01
Task and response draft are created
Machine work completed; no business outcome is confirmed yet.
Needs review
Later
Conversation with account owner is booked
This is the stated business result.
Not checked
Who closes the loop?Read in numbered order. Each handoff needs an owner and acceptance evidence.
1. Workflow
Create the task and response draft
Accepts: Qualified event is recorded
Releases: Human owner receives the task
Supported
2. Named owner not confirmed
Record booking or non-result and next action
Accepts: Task is accepted
Releases: Outcome still needs an owner and reason
Not checked
Step 1 of 3. You can revisit any step.
Changes save in this browser as you work.
Inspect the example policy saved by this activity
These are the supplied example-plan entries, not another test. Complete the workbench above to save its result.
Which of these is a business outcome rather than a description of the machine?
Names the result, names the quality bar, refuses to finish by running out of steps, and you can count it across a hundred records.
An outcome has two halves. Commit to both.
For this workflow, record a booked conversation with the account owner as the result. If it does not happen, record a stated reason and its named owner so the non-result can be reviewed too.
