Describe the work before the technology.
Write one sentence: When [trigger] happens, [owner] needs to produce [result] using [systems], with [approval or exception]. For a local service business, that might be routing a new inquiry. For an enterprise team, it could be assembling an approval packet.
Compare three candidates.
| Question | What to record |
|---|---|
| Frequency | How often does it happen in a normal week? |
| Effort | How many minutes of active work does each case take? |
| Quality | How often is rework, missing context or delay a problem? |
| Readiness | Can the owner provide representative, permissioned examples? |
| Risk | What happens when an output is wrong or an action is repeated? |
| Ownership | Who can accept the result and maintain the process? |
Estimate capacity carefully.
Monthly effort = cases per month × active minutes per case ÷ 60. If 100 cases each take 12 minutes, the current effort is 20 hours per month. That is a baseline, not a savings promise. Subtract review time and exception handling from any projected improvement. Reclaimed capacity does not automatically mean cash savings.
Write the acceptance criteria.
- The system completes the defined task on representative examples.
- A person owns exceptions and can stop automated actions.
- The workflow handles duplicate requests and missing data.
- The result is measured against the original baseline.
- Support, documentation and change ownership are agreed.
Run one bounded pilot.
Choose the smallest scope that proves the whole handoff. Review what fails as closely as what works. Expand only when the process is reliable enough for its real consequences.
Use the evaluation playbook to build your test cases, or discuss a workflow with us.