The seven steps at a glance
- 01
Define the business outcome
State what should improve: handling time, capacity, error rate, delivery speed, visibility, or cash collection.
- 02
Map one real case
Follow an actual item from trigger to completion, including systems, handoffs, waits, checks, and corrections.
- 03
Measure the current process
Capture monthly volume, hands-on time, waiting time, exceptions, rework, and the roles involved.
- 04
Separate rules from judgement
Automate stable decisions and route ambiguous or high-impact cases to a named person.
- 05
Simplify before building
Remove duplicate entry, unnecessary approvals, and obsolete steps before encoding the workflow.
- 06
Deliver a bounded pilot
Connect only the systems and cases needed to prove the result with representative data.
- 07
Launch, monitor, and improve
Train users, record failures, measure the agreed result, and expand only after the workflow is stable.
Map the current state without polishing it
A workshop description often shows how the process is supposed to work. Automation needs the version that actually happens. Pick one recent request, order, document, or customer case and follow every action until the work is complete.
Record the trigger, owner, information used, systems opened, decisions made, handoffs, waiting points, corrections, and evidence retained. Include the spreadsheet beside the CRM, the message sent in chat, and the manager who quietly resolves every difficult case. Hidden work is usually where both the cost and implementation risk sit.
Design the target workflow around exceptions
The normal path is rarely the hard part. The target design must say what happens when data is missing, an integration is unavailable, a price needs approval, a document cannot be read, or a customer changes the request.
For each exception, define who receives it, what information they see, what they may change, how the process resumes, and what is recorded. This keeps automation from merely moving manual detective work to another inbox.
| Design question | Useful answer |
|---|---|
| What starts the workflow? | A specific event with required inputs |
| What can run automatically? | Stable rules with testable outputs |
| What needs review? | Ambiguous, unusual, or consequential cases |
| What if something fails? | Named queue, owner, alert, and recovery step |
| What proves completion? | Status, timestamp, output, and audit record |
Choose the least complex architecture that works
A useful solution may be a configuration inside an existing product, an API integration, a workflow service, a focused internal interface, or custom software. AI is one possible component when inputs are variable; it is not the default answer.
- Configure an existing system when the workflow is standard and the capability already exists.
- Connect systems when manual transfer is the main problem and each system otherwise works.
- Build a focused tool when roles, state, exceptions, or business rules are distinctive and important.
- Use AI for document, language, search, or classification work where fixed rules are insufficient—and validate its output.
Pilot one complete slice—not scattered features
A good pilot handles one meaningful process from trigger to result for a controlled group of users. It includes the real source data, required integrations, review step, failure path, and the measure that will determine whether it should continue.
Run representative normal and difficult cases before launch. Where consequences are material, compare the new workflow with the existing process for a short period. The goal is evidence about time, quality, and adoption—not a demonstration that looks impressive in isolation.
Launch with ownership and operating measures
- Name a business owner for policy and priorities.
- Name a technical owner for access, monitoring, failures, and changes.
- Train users on both the normal path and exception path.
- Keep a safe manual fallback during the initial release.
- Compare handling time, turnaround, error rate, backlog, and adoption with the baseline.
- Review exceptions regularly; they reveal what should be improved next.