AI automation
Automation for the work nobody wants to do twice
The interesting AI projects are rarely the ones that pay. What pays is usually duller: the inbox somebody sorts by hand every morning, the PDFs that get retyped into a spreadsheet, the same six answers written out again and again. That is where we start, and often where we finish.
What this covers
Processes, not experiments
Everything here has a person at the end of it who can see what the system did and override it. That is not a limitation, it is the reason these projects survive contact with real work.
Document and form processing
Pulling structured data out of invoices, applications, contracts, delivery notes and scans, then putting it into whatever system already holds it. Handles the messy ones, flags the ones it isn't sure about.
Inbox and ticket triage
Classifying what arrives, routing it to the right person, and drafting the reply. A human still approves anything that leaves the building unless you decide otherwise.
Internal assistants
A system that answers from your own documents, policies and records, with the source shown next to the answer. Useful where one person keeps getting asked the same question by everyone else.
Drafting workflows
First drafts of repetitive writing: summaries, reports, product copy, responses to standard requests. Editing a draft is faster than starting from an empty page, and the quality floor is higher.
Systems integration
Connecting the automation to the tools you already pay for, so the work ends up in the CRM, the ticketing system or the finance package rather than in a separate dashboard nobody opens.
Evaluation and guardrails
A test set built from your real cases, a measured accuracy figure, and a defined behaviour when the model is unsure. Without this you are not automating, you are hoping.
Where we come in
The three calls we get most
"We tried a chatbot and it embarrassed us."
Almost always the same three causes: it wasn't grounded in your own content, nobody measured it before launch, and there was no fallback for when it didn't know. All three are fixable.
"One person is the bottleneck."
A process that only moves when a specific person is at their desk. The goal isn't to remove them, it's to stop the queue forming behind them while they're on holiday.
"We're drowning in one kind of document."
High volume, roughly consistent structure, and someone typing it into a system by hand. This is the clearest case for automation there is, and usually the quickest to prove.
How it works
One process, measured, then widened
We start by watching the work. An hour sitting with the person who actually does the task tells us more than a week of stakeholder workshops. It also surfaces the exceptions, which is where these projects usually come apart.
Then we pick one process: narrow, high volume, and low consequence if it gets something wrong. We build it end to end, including the part where a person checks the output, and we measure it against cases you have already handled so there is a number to argue with.
If the numbers hold, we widen. If they don't, you have spent a small amount finding out something useful rather than a large amount finding out the same thing eighteen months later.
When we'll tell you not to
Automation pays where a task is repeated often and follows rules. If your bottleneck is a decision nobody wants to own, or a process that changes every time it runs, a model will make it faster and wrong. We would rather say that at the first meeting than at the third invoice.
Tools
What we work with
Model choice is a decision we make with you, based on cost, accuracy and where your data is allowed to go.
- Claude
- OpenAI
- Amazon Bedrock
- Vector search
- Retrieval (RAG)
- Python
- n8n
- Make
- Zapier
- Document pipelines
- Webhooks & APIs
- Evaluation harnesses
Answers
Questions about AI work
Does our data get used to train a public model?
Not if it's set up properly. The business API tiers we use do not train on your data by default, and where the requirement is stricter we can run the whole thing inside your own AWS account using Bedrock.
How do we know it's accurate enough?
We build a test set from cases you have already processed, measure against it, and agree a threshold before launch. You see the failures as well as the successes.
Will this replace people on our team?
In our experience it removes the part of a job nobody enjoys rather than the job. What it does reliably change is how much a small team can absorb before it needs to hire.
What does it cost to run each month?
Model usage is billed per token, so it scales with volume. We estimate the running cost from your real volumes before building, and design around it if the number looks wrong.
Can it work with our existing systems?
Usually. If a system has an API we can integrate directly, and if it doesn't there are normally exports and imports to work with. We check this before scoping, not after.
How long before we see something working?
For a single narrow process, weeks rather than months. Anything quoted in quarters usually means the scope hasn't been narrowed enough yet.
Related
Often needed alongside this
Get in touch
Tell us which task your team repeats most.
That one sentence is usually enough for us to say whether it's worth automating, and we'll tell you if it isn't.