Case still
Case study
—
—
—Before
—After
Your team spends its week doing by hand what software should do.
01What it involves
Six stages, and the software is the fourth.
Most automation projects fail for one reason: a tool is chosen before anybody has written down what the work actually is. So the first fortnight produces a document rather than a demo — where the hours go, what is worth automating, and what should simply stop being done.
Point at a stage, or tap it, to play it.
-
01
Audit
A week watching how the work happens rather than how the process document says it does. It ends with a written list of every repeated task, how long it takes, how often it happens, and who it lands on.
Stage clip · not made yet -
02
Triage
Not everything repeated is worth automating. The list is ranked by hours saved against effort and risk, and the tasks where the honest answer is to delete them or move them are marked as such. You approve the shortlist before anything is built.
Stage clip · not made yet -
03
Design
How each automation behaves, and just as importantly how it fails: what a bad input does, what a person still has to approve, and where it stops and asks. Written down before it is built, because an automation nobody can predict gets switched off within a month.
Stage clip · not made yet -
04
Build
Made inside the systems you already pay for wherever possible, rather than a new platform to administer. Where a model is doing the judging, its output is checked against real historical cases before it touches anything live.
Stage clip · not made yet -
05
Run in parallel
The automation runs alongside the manual process for an agreed period and the two are compared. Nothing is switched off until the numbers say the same thing twice.
Stage clip · not made yet -
06
Handover, and out
The automations, the accounts, the prompts and the documentation, in your name. Your team can change them without us, and no retainer is folded into the price to keep you dependent.
Stage clip · not made yet -
From you
What we need from you
- One decision-maker who can sign off
- An hour each with the people who actually do the work
- Read access to the systems it touches
02Proof
Three workflows where this was the whole job.
Not a portfolio. Three projects where a team was doing something by hand every week and stopped — with the hours before and after.
Case still
Case study
—
—
—Before
—After
Case still
Case study
—
—
—Before
—After
On camera
Hear it from a client.
Quote pending — a Ai Automation client, in their own words, on what changed.
Client nameRole, Company
03Questions
The five that only come up about automation.
Cost, timeline, team and scope are answered on the services page. These five are the ones that only arrive once software is going to do somebody’s job.
It has not on the work we have run, and the honest version is narrower than either the sales pitch or the fear: it takes the repeated part off someone whose job also contains judgement. If your intention is to reduce headcount, say so at the discovery call. It changes what is worth building, and we would rather know then than find out at handover.
It is designed for before it is built. Every automation has a defined failure behaviour: what a bad input does, what a person still approves, and where it stops rather than guesses. Anything irreversible — sending, paying, deleting — keeps a human in the loop by default, and taking that out is a decision you make deliberately rather than one we make quietly.
Wherever you have agreed it can, written down before anything is built. We work inside systems you already hold a contract with where possible, we tell you which provider processes what, and we do not put customer data through a model on a consumer plan because it was the convenient thing to reach for.
Usually less than you would expect. Most of what we build runs in the tools you already pay for, because a new platform means a new administrator, a new invoice and a new thing to migrate off in three years. Where something genuinely new is needed, the account is in your name.
Then someone on your team changes it, which is what the handover is for. Automations are documented in plain language next to the thing they automate rather than in a diagram nobody can find. If the change is bigger than that, we bill the hours — there is no retainer holding the work hostage.
05Start here
Tell us where the week goes.
Thirty minutes, no deck. Describe the thing your team does every Monday and you get a straight answer on whether software should be doing it — and we will say it should not when it should not.