Start with a workflow, not an automation idea
A useful audit begins with work that already happens repeatedly: qualifying an enquiry, preparing a quote, onboarding a client, chasing documents or compiling a weekly report. Give the workflow a clear trigger and a clear completed outcome.
Avoid starting with a tool name. Saying that the business needs a chatbot or an AI agent skips the more important question: which part of the work is slow, unreliable or unnecessarily manual?
Map what actually happens
Speak to the people doing the work and follow a real recent example from start to finish. The written procedure is useful, but the real process often includes inbox searches, copied spreadsheet rows, private reminders and informal approvals that the procedure misses.
- What event starts the process?
- Which information is needed at each step?
- Who owns the next action and how do they know?
- Which systems, documents and communication channels are involved?
- Where does work wait, loop backwards or get re-entered?
- What marks the process as complete?
Measure the friction before proposing a fix
Record a simple baseline: how often the workflow runs, how much handling time it consumes, how long it waits, how often information is missing and what happens when a step fails. Exact financial modelling is not always necessary, but there should be enough evidence to judge whether change is worthwhile.
A process that takes five minutes once a month may not justify integration work. A ten-minute task repeated fifty times a week might. Frequency, risk and commercial impact matter together.
Check whether the workflow is ready
Good candidates have repeatable inputs, understandable rules and a useful destination for the output. Poor candidates depend on unclear judgement, constantly changing exceptions or information that is not available reliably.
- The trigger can be detected reliably.
- Required information is available in a consistent form.
- Rules and exceptions can be explained in plain language.
- The next system or person can receive the output safely.
- Failures can be logged, retried or escalated.
- A human approval point exists where risk requires it.
Define a first build that can be judged
The first version should solve one complete operational problem. It might capture an enquiry, validate the details, create the correct record and assign a follow-up task. It should not attempt to replace every tool or automate every exception on day one.
Agree the success measure before implementation. Useful measures include response time, handling time, missed handoffs, error rate and the number of manual updates removed. Review the result against the original baseline after real use.