Define the operational outcome before discussing tools
Name the outcome, its accountable owner and the evidence that would demonstrate improvement. This boundary prevents the initiative from becoming an unprioritised feature list.
Before the workshop, state what is outside the scope as well. An explicit boundary protects the team from adjacent requests and lets options be compared against one outcome rather than the number of features proposed.
Observe real work, including exceptions
Follow several cases from start to finish with the people doing the work. Email threads, spreadsheets, informal approvals and manual recovery steps usually expose the true dependencies.
Ask participants to show the most recent real case instead of describing an ideal day. The gap between the official process and the process people actually use exposes time, access and data-quality constraints.
Map decisions, data and hand-offs
For each step, record the information received, the decision made, the output produced and the role taking over. Include waiting time, rework and external systems.
The map should be understandable to someone outside the department. Use action verbs, name the responsible system or role, and mark the points where human judgement changes the route.
Measure friction instead of relying on impressions
Capture waiting time, duplicate entry, error rates, interruptions and exception volume. A few reliable measures separate a visible annoyance from a problem worth investing in.
Add an approximate cost to observed problems: lost hours, delayed requests, corrections, compliance exposure or customer frustration. The estimate need not be perfect; it should support prioritisation and a realistic business case.
Separate strong candidates from poor automation choices
Start with repetitive, stable and verifiable steps. Keep human review where context is ambiguous, consequences are significant or rules change frequently.
A frequent step is not automatically a good candidate. If inputs are inconsistent or the rule depends on tacit judgement, improve data quality, clarify policy or redesign the interaction before automating it.
Turn the audit into a decision brief
Summarise the current process, risks, available data, options, recommended first scope and success criteria. The brief becomes a shared basis for product, operations and engineering decisions.
The brief should record unresolved questions, validation owners and missing evidence. A credible audit does not remove all uncertainty; it reduces risk enough to select a limited and testable next step.
Lethavia
Turn the analysis into a next step
Share the context, constraints, and outcome you need. Lethavia will help structure a clear path forward.
Prepare a process audit