Method
Discovery → Evals → Deployment
The loop doesn't stop at the first process. As soon as one workflow works, the next bottleneck becomes visible — usually immediately upstream or downstream of it.
Timeline
What the first quarter looks like
This is a typical schedule for a moderately complex back-office process. The dates move. The order doesn't.
- Week 1
Observation
We sit with the team. The first day is mostly quiet: they work, we watch. We ask questions when something unusual happens — the memory is fresh then, and we're talking about a real case rather than an abstract rule.
- Week 2
Exception log
We write down every deviation. That list becomes half the specification later. In parallel we pull the system logs: the ERP and CRM tell us what nobody says out loud.
- Week 3
Map and matrix
The operating map comes together, and we mark each step: what stays code, what becomes a model call, where a human stays in the loop. Alongside it, an ROI matrix of what to do first.
- Weeks 4–6
Golden dataset and evals
We build a measurement set from historical cases, run the system against it, and see where it stands and where the errors actually come from.
- Weeks 7–12
Shadow mode
The system runs but doesn't decide. Your team sees what it would propose and can flag when it's wrong. That feedback goes back into the evals.
- Week 13+
Staged go-live
High-confidence categories go automatic first, the rest to a human. The threshold moves on measurement, not impatience.
The decision
We decide step by step what goes to a machine
This is the real product of discovery: not "we're introducing AI", but a per-step answer for what should happen to each one.
- Deterministic
- Agent
- Human
- Exception
- 01
Intake and normalisation
Unpack attachments, drop duplicates, land on one format. No model involved — none is needed.
- 02
Extraction
From PDFs, screenshots, forwarded threads. Judgement belongs here, because no two senders are alike.
- 03
Schema validation
Required fields, totals, vendor master. If it fails, it doesn't move on.
- 04
Matching and coding
Tie to the purchase order and delivery note, propose a cost centre, flag uncertainty.
- 05
Approval
The finance clerk sees the proposal and the source on one screen. They press Enter, not the model.
- 06
Write back to the ERP
Through the existing API. We don't migrate systems, we build on them.
- 07
Exception queue
Whatever the system won't finish doesn't vanish — it queues up, with a reason.
Principles
What we don't compromise on
We build on what you already run
If someone spent two years rolling out an ERP, the last thing they need is another migration. We build on the APIs.
Everything is logged
Every step is reviewable: what came in, what the system decided, on what basis. There is no trust without it.
The human moves up, not out
Approval stays with a person. The system prepares, proposes and explains; the responsible colleague decides.
The exception is a deliverable too
What the system won't finish doesn't vanish quietly. It queues, with a reason, an owner and a deadline.
We build model-agnostic
Your own eval set decides which model runs. When a better one ships, switching is a measurement, not an article of faith.
We close in numbers
Hours saved, error rate reduced, risk avoided. If we can't state it in numbers, we don't claim it.
Frequently asked questions
What's the shortest engagement that makes sense?
A standalone discovery, which is two to four weeks. Any shorter and you can't map a process with its exceptions included — and the exceptions are the point.
Do you need to be on site?
For discovery, yes — typically two to three days a week. The build is mostly remote. If the team itself is distributed, we adapt.
What happens at the end?
Handover: documentation, runtime, eval set and training. The goal is that your team can operate and extend it. We'll stay on for support if you want, but we don't build dependency.