How we take one workflow from diagnostic to operation
Our AI implementation process starts with the work your team does today. We map the workflow, build inside your systems, prove parity beside the manual process, then run and monitor it.
| # | Phase | When | What happens | What you have at the end |
|---|---|---|---|---|
| 01 | Diagnostic | Weeks 0 to 2 | We sit beside the people doing the work and map eight to twelve workflows, measuring what each one costs in hours. | A ranked automation backlog with an expected payback against every workflow. |
| 02 | Build | Weeks 2 to 6 | The first agent is built against the real process, in your environment, on your data. Weekly demonstrations with the people who will use it, not with a steering committee. | One agent in production, doing real work. |
| 03 | Prove | Weeks 6 to 9 | The agent runs alongside the manual process and the two are reconciled to zero difference. | Evidence, and then the switchover. |
| 04 | Run and extend | Ongoing | We host it, monitor it, maintain it, and absorb the format and portal changes that break automation. The next workflow comes off the backlog every four to six weeks. | Compounding coverage rather than a finished project. |
Week six is when the first agent starts doing real work. It is not when your manual process stops. Both run from week six until they reconcile to zero difference, and only then is anything switched off. If they do not reconcile, the manual process stays and the date moves.
Phase 01
Diagnostic: map and rank the workflows
Weeks 0 to 2. We sit beside the people doing the work, because a workflow described in a meeting is not the workflow that happens on a Tuesday afternoon.
-
Eight to twelve candidate workflows
We map what is actually done, step by step, including the exception that never made it into any system and the approval that needs a phone call. Candidates are what a diagnostic produces. They are not commitments, and we would expect some of them to be wrong.
-
What each one costs today, in hours
Hours a week, by role, counted with the people who spend them rather than estimated for them. This is the number that ranks the backlog, and it is the number a payback assumption rests on.
-
Expected payback, stated as an assumption
Against every workflow we write what we expect to recover and what that expectation depends on: the hours, the exception rate, how ready the systems are to be connected, and who has to approve the output. When an assumption is weak we say so rather than smoothing it into an average.
-
What you have at the end
A ranked automation backlog, an expected payback against each item, and an agreed first workflow. The backlog is yours whether or not you build anything with us.
Phase 02
Build: work in your environment
Weeks 2 to 6. The first agent is built against the real process, in your environment, on your data.
-
Your environment, not a demonstration sandbox
Your cloud account, your network, or your own hardware, entered with credentials you issue and can revoke. An agent proven on sample data is a prototype, and prototypes are where automation projects go to be admired.
-
Weekly demonstrations with the people who will use it
Not with a steering committee. The clerk who currently does the work is the person who spots the exception we have not handled, and they spot it in week three rather than in month six.
-
Rules, tolerances and approvers, written down
What the agent may decide, what it must hold, and who signs each irreversible action. If a field is missing, it stops and asks. It never substitutes one source for another to keep going.
Phase 03
Prove: reconcile before switchover
Weeks 6 to 9. The agent is on real work from week six, and the manual process keeps running beside it until the two agree.
-
Both run, and both are compared
Every output the agent produces is reconciled against the output the manual process produced for the same period. Not sampled, not spot checked. Line by line.
-
Zero difference, or a named reason
A difference is closed when we can say what it is, not when the percentage looks small. Anything we cannot account for is reported as unexplained, in those words, and it blocks the switchover.
-
The switchover is a decision, not a date
Your team decides to stand the manual process down once the evidence is in front of them. If parity is not proven, the parallel run continues and nothing is switched off.
-
The done-ness test
After the agent goes live, does a person still open that file? If the answer is yes, the work is not finished, whatever the reconciliation says.
Phase 04
Run and extend: keep the workflow correct
Ongoing. We host it, monitor it, maintain it, and absorb the changes that break automation.
-
Monitoring that names a person
Every scheduled run is watched. When something fails, the alert goes to the owner of that workflow with the diagnosis already in the message, rather than to a room. Silence means healthy.
-
The weather of production
A supplier changes an invoice layout, a portal moves a screen, a workbook grows a column. Absorbing that is part of the monthly fee, not a change request.
-
The next workflow comes off the backlog
Every four to six weeks, in the order the diagnostic ranked, revised as you learn what the first one was actually worth. Coverage compounds instead of arriving as a finished project.
Commercials
How the engagement is priced
Three lines, and no seats. We do not bill by the hour, because billing by the hour pays us to be slow.
- A fixed fee for the diagnostic, credited against the first build.
- A fixed price per agent, and a monthly fee to run it.
- Numbers are set after the diagnostic, because quoting before we have seen your process goes badly.
We publish no figures on this page for the same reason. A price quoted against a workflow nobody has watched is either padded to cover the unknown or wrong in the other direction, and both of those cost you more than a two week diagnostic.
Responsibilities
What your team and our team own
Agreed at the start, in writing, so nothing important is owned by whoever happens to notice it.
Scroll sideways to read the table.
| area | your team | our team |
|---|---|---|
| Access | Issues credentials, grants the least access the workflow needs, and revokes it whenever you choose. | Asks in writing, tells you what an agent touches before it touches it, and uses nothing beyond the grant. |
| Business rules | Owns the rules, the tolerances and the definitions, because they are your business, not ours. | Writes them down, encodes them, and shows you where each one is applied in the run. |
| Approvals | Names the approver for every irreversible action and keeps that name current when people move. | Gates the action behind that name and records who released it and when. |
| Environment | Decides where it runs: your cloud account, your network, or your own hardware. | Deploys, hosts and operates it there, and keeps it inside that boundary. |
| Incidents | Confirms the business impact and decides whether to pause a workflow. | Detects, diagnoses, fixes and reports, and tells the workflow owner before they find out from the work. |
| Change | Tells us when a rule, a format or an approver changes, as early as you know. | Absorbs format and portal changes as part of running it, and prices genuinely new scope separately. |
| Handover | Names who will hold the documentation and the credentials afterwards. | Maintains the pack throughout and walks your people through it, on the day you ask. |
What we do with the information you send us before any of this begins is set out in our privacy notice.
Bring one workflow to the diagnostic
You do not need a plan or a business case to start. Bring the workflow that annoys you most, roughly what it costs your team in hours a week, and the name of the person who owns it internally. That is enough for a first conversation.
Questions we get asked most often, answered the way we would answer them on a call, are on the main page.