In client conversations over the past year we have met two opposite extremes. One side says “let AI mature a bit first”. The other has already bought company-wide licences and is looking for somewhere to use them. Both end up in the same place: a year later, no process is actually faster.
Effective AI for business operations does not start with “which tool”, but with “which process burns the most person-hours on repetitive work”.
Four criteria for choosing the first process
- High repetition. A task taking 15 minutes but done 80 times a week deserves priority over one taking 4 hours once a quarter.
- Historical data exists. Having processed thousands of similar cases means you already have something to measure accuracy against.
- Errors are checkable. Drafting an email for a human to review is a good start. Moving money automatically is not.
- Someone owns the process. A specific person who understands it, wants it faster, and has the authority to change how it works.
The fourth criterion is the most underrated: plenty of pilots run beautifully in technical terms and never reach production, because nobody on the business side takes responsibility for them.
Five processes to start with
- Extracting data from documents. Invoice PDFs, scanned orders, goods-receipt notes — high volume, clear rules, immediately verifiable, so this almost always pays back fastest. The approach is OCR combined with a language model for context, plus a confidence threshold: any field the model is unsure about goes to a person.
- Classifying and routing incoming requests. Shared inboxes, support tickets, customer messages — easy to measure because historical data gives you the correct labels. The biggest gain is usually a shorter first response time, not headcount savings. Classify first, auto-reply later.
- Drafting. Quotes, template emails, product descriptions, weekly reports. The right goal is a good draft, not a finished document. The hard part is not the writing but connecting the background information — current price list, transaction history, internal policies.
- Searching internal knowledge. The answer sits somewhere in the documentation, but asking the person who knows is still faster than finding it — so your most experienced people spend their time answering questions they have answered before. The prerequisite is cleaning out obsolete documents: three versions of the same policy will produce a wrong answer that is very hard to spot.
- Checking quality on the way in and out. Reconciling figures, flagging unusual transactions, reviewing source code. AI does not replace the person deciding — it narrows what needs looking at from thousands of lines to a few dozen worth attention. Inside CONCRETE, an automated reviewer runs first on every pull request, so the review meeting focuses on design and business logic.
Measure the result in numbers, not impressions
This is why many AI projects fail to convince management even though users “find it handier”. Measure the current state before rollout so you have a baseline, then track four indicators:
| Indicator | What it tells you |
|---|---|
| Processing time per case | The easiest for management to read — before versus after |
| Automatic completion rate | What percentage needs no human intervention |
| Rework rate | If people still fix nearly everything, nothing has been saved |
| Running cost per case | Decides whether scaling up is economically viable |
The rule we apply: a use case must prove its value in the numbers before it is rolled out widely. If it does not, stop — the cost of stopping early is far lower than the cost of maintaining a system nobody uses.
Three things to settle before going live
- Where the data goes. For personal data, contracts or financial figures: where it is sent, whether it is used for further training, how long it is retained — and consider private infrastructure from the outset.
- Who is accountable when the output is wrong. There must be a person confirming anything that touches customers or money — accountability cannot be handed to a tool.
- Whether the cost scales. Running 100 times a day and 10,000 times a day are different problems; do the arithmetic at your target volume first.
In short
Bringing AI into operations is a series of small improvements, each aimed at a process narrow enough to measure: start where repetition is heaviest, keep a human in the loop at the points that matter, and only scale when the numbers say you should. If you have a process you suspect is a good candidate but are not sure, see how we approach it or get in touch and let’s assess it together.