“We spend too much time on this task; it needs to be automated.” The conclusion sounds obvious. Yet many projects automate the most visible step while the real problem sits elsewhere: an ambiguous commercial rule, information captured too late, or an approval no one truly owns.
Technology is therefore not the right starting point. The first decision concerns the process itself.
A strong automation candidate is not merely repetitive. It is understood well enough to define what the system should do when the situation is not normal.
1. Describe a real flow, not the official procedure
Take one recent case and follow it from trigger to final outcome. For an order, this might begin with the customer request and end with delivery and invoice reconciliation. Record every hand-off: who receives what, in which format, what decision is made and where the information is stored.
Separate three types of time:
- active time, when someone is actually working on the case;
- waiting time, between actions and approvals;
- rework time, spent correcting, searching and entering the same data again.
An operation may require twenty minutes of work but remain blocked for three days. Making data entry faster will not necessarily address the main constraint. A notification, a clear owner or the removal of one approval may create more value than complex automation.
2. Score six signals before discussing software
I use a simple grid. Each signal receives a score from 0 to 2: absent, moderate or strong.
- Volume: how many cases actually go through the flow each week or month?
- Unit cost: how many minutes and how many roles does a normal case require?
- Cost of error: does a mistake create minor inconvenience, or a customer delay, credit note or legal risk?
- Rule stability: given the same information, would two experienced people make the same decision?
- Input quality: does the required data exist, and can it be captured in a usable format?
- Ability to act: is someone accountable for the flow and available to decide how exceptions should work?
A high score is not an automatic green light. It indicates that a short diagnostic is worthwhile. Conversely, low volume, unstable rules and no product owner are three good reasons not to build too soon.
3. Start with exceptions
A demo almost always follows the happy path. The daily product lives in incomplete cases: an unknown reference, negotiated price outside the catalogue, unreadable document, duplicate, absent approver, blocked customer or contradictory information.
For every common exception, ask four questions:
- how will it be detected?
- who makes the decision?
- which information is needed to decide?
- how does the flow resume without losing the audit trail?
This list determines much of the interface and architecture. If there are no clear answers, the first deliverable may need to be a new business rule rather than code.
4. Choose the right level of automation
Not every step should become autonomous. There are at least four possible responses.
Remove
An entry or approval that no one uses should disappear. This is the cheapest form of automation and often the most profitable.
Simplify
A single form, shared naming convention or clearer tracking view can remove most friction without introducing a complex engine.
Automate with rules
When inputs are structured and the decision is explicit, deterministic rules are preferable. They cost less, are easy to test and remain understandable.
Assist with AI
AI becomes useful when inputs vary: emails, contracts, photographs, free descriptions or heterogeneous documents. It can extract, classify, match or draft a summary. Conventional rules should still control whatever can be controlled, and a person should remain in the loop when the cost of error is material.
5. Quantify value without inventing ROI
A useful estimate is built from visible assumptions:
monthly gross benefit = volume × time saved per case × fully loaded hourly cost
Then include costs that are often forgotten: operation, monitoring, correction, rule changes and user support. The project should also be compared with a simple alternative. If a process change can recover 70% of the benefit in two days, test that before commissioning bespoke software.
Time is not the only measure. Track lead time, rework, cases with no visible status, errors discovered after delivery and the share of cases requiring manual intervention.
6. Test the main risk with a vertical slice
An isolated prototype can prove that an API works without proving that the product will be used. I prefer a vertical slice: one case type and a small user group, but the full flow through to a real outcome.
For an order received by email, that might cover receipt, extraction, mandatory field checks, correction request, approval, creation in the target system and an audit log. The scope is narrow, but every difficult layer is represented.
The decision at the end should be explicit: expand, fix the organisation, change the approach or stop. Stopping the wrong project after two weeks is a useful result.
What should exist before development begins
A serious diagnostic can fit into a few pages: current-flow map, baseline measures, ten main exceptions, decision rules, affected systems, risks and a proposed first scope. It enables leadership to compare the cost of the status quo, a lightweight improvement and a bespoke product.
At AI7, this is where product analysis connects with technical delivery. It avoids selling AI to an ownership problem, or building a complete SaaS product when a focused business tool is enough.