Follow one real example.
Ask someone who does the work to walk through the last completed request. Where did it start? What did they copy? Which system was trusted? When did they wait, and how did they know the work was done?
Watch for the activity between systems. Copying a record, checking an attachment and chasing an update may not appear on a formal process chart, but they often account for much of the effort. Record both time spent and time waiting.
Score the opportunity before choosing the technology.
Use a simple relative score to compare candidates. High frequency is useful, but only when the result is valuable and the error consequences are understood.
| Question | Stronger first candidate | Reason to investigate further |
|---|---|---|
| Can we define done? | An observable complete record or handoff | A vague goal such as improve productivity |
| Are inputs accessible? | Supported systems and clear permissions | Unknown access, ownership or data quality |
| Can we detect errors? | Validation and a recoverable exception path | Silent errors with consequential effects |
| Will the team use it? | A named owner and a recurring burden | No sponsor for the operating change |
Separate rules, AI interpretation and human decisions.
A fixed approval rule does not need a language model. Reading an unstructured email may benefit from one. A consequential judgment may belong with a person even when the surrounding administration is automated.
Draw these as different responsibilities. This makes a project easier to test and helps the team understand why the system acted. Avoid making an entire workflow autonomous merely because one step uses AI.
Agree on a baseline and a pilot boundary.
Pick a measure that represents the problem: completion within a time window, manual touches per request, exception age or staff time spent collecting information. Record the current process before changing it.
Pilot on a limited workflow, team or account group with a recovery plan. Compare representative periods and note changes in volume, staffing and data quality. Do not call every difference an automation effect.
A practical first-project brief.
Write a one-page brief before a feature specification. It should let someone outside the process understand what needs to improve and what is not yet known.
- Trigger, inputs, owner and completion condition
- Current tools and the most common exceptions
- Baseline measure and desired direction of improvement
- Actions requiring approval
- Pilot boundary, recovery plan and operating owner
