Operations · Free implementation template
Business Workflow Discovery Template
Document one workflow from trigger to completed outcome, including systems, handoffs, exceptions, ownership, and measurable baseline.
Introduction
What the Business Workflow Discovery Template is for.
Document one workflow from trigger to completed outcome, including systems, handoffs, exceptions, ownership, and measurable baseline.
A completed operations template is the definition of done for a cross-functional workflow: the trigger, the authoritative records, the owner at each step, the exception path, and the point at which the work is genuinely finished. This one covers trigger, current path, exceptions, baseline, and it is written for operations leaders, smb owners, ai implementation teams. Each section is a decision that has to exist before the workflow can be built or automated — the prompts are there to force the decision, not to be filled in for their own sake.
A completed template is also a structured brief. ARIA can read it as the objective, the systems involved, and the constraints that apply, which is what turns the specification into something that runs rather than something that gets filed.
- Category
- Operations
- Sections
- 4
- Format
- Markdown, no signup
- Best for
- Operations leaders, SMB owners, AI implementation teams
The problem
Specifications fail on the decisions nobody wrote down.
Most operating workflows fail on the last item. Nobody wrote down the observable condition that means the work is complete, so cycle time cannot be measured, the workflow cannot be automated, and "done" is whatever the last person to touch it believed.
The second failure is shared ownership. A step owned by a team is a step owned by nobody, and it is reliably where the workflow stalls.
The third is that the failure path is discovered rather than designed. The happy path gets specified and built; the exception path gets improvised the first time a record is ambiguous, usually by dropping it.
You're likely here because
- You are choosing what to automate first and the list keeps growing
- Different teams describe the same process differently
- Nobody can state where the current process actually ends
How it works
From a blank Business Workflow Discovery Template to a running workflow.
Each stage is a decision that has to be made once. Making them in this order is what keeps the later ones answerable — you cannot set an automation boundary before you know who owns the record.
Step 01
State the trigger
Name the event that starts the work and the system that emits it. A workflow triggered by "when someone notices" cannot be operated.
Step 02
Assign single ownership
One accountable owner per step, with a named backup and a response expectation. This is the step most templates skip and most workflows fail on.
Step 03
Declare record authority
Where two systems hold the same field, record which one wins, so an automated write cannot quietly overwrite the authoritative value.
Step 04
Design the exception path
Specify who receives a failed or ambiguous item, what the retry behaviour is, and when it escalates — alongside the happy path, not after it.
Step 05
Define completion
Write the observable condition that marks the work finished. Everything downstream — measurement, automation, SLA — depends on this one sentence.
The template
Every section, with the prompts that force the decision.
Section 01
Trigger
Section 02
Current path
Section 03
Exceptions
Section 04
Baseline
After it is filled in
What the completed specification is actually consumed by.
Filling in the Business Workflow Discovery Template produces an artifact, and an artifact on its own changes nothing. What matters is what consumes it afterwards.
Handed to the runtime, the completion condition in an operations specification becomes the thing the workflow actually measures. That single field is why cycle time becomes reportable and why the workflow can be automated at all — an observable end state is what lets a system decide it is finished instead of waiting for a person to say so.
The exception path is the other half. Most operating workflows are not slow in the normal case; they stall on the ten percent nobody specified, where the work sits unowned because the document only described the happy path. Naming the exception owner is a smaller change than it looks, and it is usually where the recovered time comes from.
Implementation path
How to actually fill it in.
- 01
Map the workflow as it actually runs today, including the undocumented steps people perform to make it work.
- 02
Assign a single owner to each step, and confirm with that person that they accept it.
- 03
Write the completion condition before writing any automation, and check it can be evaluated from data.
- 04
Run the exception path deliberately during the pilot — introduce an ambiguous record and see where it lands.
- 05
Measure cycle time and exception rate from the first week so later improvement has a baseline.
Controls this specification sets
Controls that matter.
Control 01
Consequential steps stay behind explicit human approval.
Control 02
Failed or ambiguous items land in a queue with their source context preserved; a silent drop is treated as a defect.
Control 03
Access to each system is scoped to the specific workflow rather than the full capability of the connection.
Control 04
Every automated step records what triggered it and what it changed.
Worked examples
When teams reach for this one.
Choosing the first automation
Discovery usually reveals the highest-volume process is not the highest-value one; frequency and pain diverge more than expected.
Before an integration project
Mapping the workflow first is what prevents connecting two systems around a process nobody agreed on.
After a failed automation
A workflow that broke in production almost always has an undocumented step people were performing manually.
Limitations
What this template does not do.
- Discovery documents the current state; it does not tell you what the future state should be.
- People describe processes as intended rather than as performed — validate against system data.
- It does not size the engineering effort required to change anything.
- Cross-department workflows need a session per department to be accurate.
FAQ
Questions about the Business Workflow Discovery Template.
Who should fill in the Business Workflow Discovery Template?
The people who own the outcome, together. This template is written for operations leaders, smb owners, ai implementation teams, and the value comes from surfacing disagreement between them rather than from one person completing it alone.
How long does it take?
A focused session, usually one to two hours for a first pass. Sections that take much longer are normally pointing at a real disagreement, which is the template doing its job rather than failing.
Is it free, and is there a signup?
Free, with no gate. The Markdown download link at the top of this page returns the full template immediately.
What happens after it is filled in?
The completed template becomes the specification the build works from. You can hand it to ARIA to resolve into an objective and an execution path, hand it to an internal team, or use it to brief a vendor — the artifact is the same in each case.
Does this replace the tooling?
No. It specifies what the tooling has to do. Operations tools differ in how much of this they can enforce, which is itself useful information when you are comparing them.
How often should it be revisited?
When the process it describes changes, and on a scheduled review otherwise. A specification that no longer matches what runs is worse than none, because people still trust it.
More operations templates
Other operations specifications.
AI Automation Readiness Checklist
Score whether a workflow is ready for automation based on repeatability, data quality, permissions, exception rate, and consequence level.
Open the template →
Approval Workflow Template
Design approvals with explicit thresholds, owners, evidence requirements, escalation, and auditability.
Open the template →
Client Onboarding Workflow
Map client onboarding from signed agreement through intake, access, kickoff, delivery setup, and first success milestone.
Open the template →
Keep exploring
Related reading and next steps.
Start with ARIA
Hand the brief to ARIA.
A completed template is a structured brief. Tell ARIA the objective and it resolves the systems involved and the execution path — so the specification becomes a running workflow, not another document.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Fill it in, then hand it to ARIA.
A completed template is a structured brief. ARIA can resolve it into the objective, the systems involved, and the execution path — so the specification becomes a running workflow rather than another document.