Automation that pays for itself
or gets switched off.
Most AI automation projects produce a diagram and a demo. The six systems below run in production inside service businesses, on the client's own infrastructure, doing work the team was previously skipping because no human had time for it. Each one is here with the number it produced and the failure mode it has.
Six systems, with their numbers attached.
Paid-lead dispute bot
Google Local Services Ads charges for leads that were never real customers — wrong trade, out of area, spam, a hang-up. Reviewing them by hand across eighteen locations is nobody's job, so nobody does it. The bot pulls each charged lead, downloads the call recording, transcribes it locally, classifies it against the platform's own invalid-lead rules, and files the dispute with the quote as evidence.
$23,000 of invalid spend identified across 2,740 leads. $2,730 came back in the first ten days from seven of eighteen locations — as advertising credit inside the platform, spent on future leads, not as cash.
Callback conveyor
A dispatcher takes a call, the customer says "let me think", and the lead dies quietly. The classifier reads each call transcript, decides whether it is booked, dead, or waiting on something, and posts a card with a deadline into one chat. When the deadline passes, the card is deleted and reposted at the bottom so it actually pushes a notification — one live card per lead, no thread of duplicates.
Validated on 40 real calls: 14 needing action, 13 booked, 12 dead, each with the verbatim quote that decided it.
Call-recording analysis at volume
Nobody listens to 5,000 calls, so the reason bookings are lost stays an opinion. Local transcription plus a classifier turns a month of recordings into a ranked list of where the conversation went wrong — with the exact words highlighted, and only the dispatcher's words highlighted, never the customer's.
One market, 63 paid phone leads read end to end. Booking rate was 49% on the CRM record and 56% once callbacks under a second number were found. Cost to run: under $5 per hundred calls.
Supplier email parser
Parts invoices arrive as PDF attachments from a dozen suppliers, each with its own layout, and someone retypes them. Inbox watcher, PDF extraction, a model that reads the line items, and a structured message into the team chat with the order number and the amount.
Runs unattended. The failure mode that matters is a supplier changing template silently, which is why it reports what it could not parse instead of guessing.
Voice-bot audit
An AI phone agent was booking jobs onto technicians who were marked off, and telling callers that working technicians no longer worked there. Neither was a prompt problem. The availability check paginated three fixed pages of a calendar that had 7,801 events, so anything outside the newest 600 was invisible and the technician looked free.
600 of 7,801 events visible. Eight defects documented, root cause found in the data layer rather than the script.
Operations reporting nobody has to maintain
A dispatcher bonus was being calculated from a spreadsheet whose author had left, with rules nobody could reproduce. I reverse-engineered the formula from the surviving outputs, matched it to the raw exports, and rebuilt it as a self-filling model — then found the previous month had been computed on the wrong date field entirely.
Reconciled 1,500 jobs a month. The wrong date field had misattributed 195 jobs into the wrong pay period.
Client names are not published on this site. Every figure above comes from the system's own output or the client's CRM, and where a number is a floor rather than a total — the recovered amount is, because only seven of eighteen locations had been processed at that point — it is described that way.
Four rules, each one learned by breaking it.
Automate a decision, not a task
The value is not "the computer typed it faster". It is that a judgement which used to require a person reading 5,000 calls now happens on all 5,000. If a human still has to check every output, you have added a step rather than removed one.
Ground every number in a source the model cannot invent
A language model will produce a confident figure from nothing. So figures come from a file, an API, or a database, and the model is only allowed to classify, summarise or route. The moment it is asked to supply a fact, the system has a fabrication surface.
Monitor outputs, not crashes
The expensive failures do not throw errors. A calendar check that silently sees 600 of 7,801 events returns a perfectly valid answer, every time, and it is wrong. So the alarm is on the shape of the output — counts, ranges, distributions — not on the exception log.
Make it survive my absence
Every one of the systems above runs on the client's own infrastructure with the credentials in their account. If the arrangement ends, the automation keeps running and someone else can read it. Tooling that only works while I am on the retainer is a hostage, not an asset.
Rule three has its own write-up, because it is the one that costs people real money: the bug that booked jobs on technicians who were off →
Probably not a fit
- A demo to show investors. These are operational systems that either save money every week or get switched off.
- A chatbot bolted onto a website to answer questions the FAQ already answers.
- Anything where a wrong output goes straight to a customer with no human between it and them, unless we design that gate first.
- Full replacement of a team. Every system above made a small team able to cover work it was previously skipping entirely.
Public code: an anonymised version of the call-analysis pipeline is onGitHub— MIT licensed, no client data, runs on a folder of files rather than anyone's account.
The other half of my work is measurement rather than automation — getting a business cited in AI answers and proving those answers turned into invoices. The two share a spine, which is that a number nobody can verify is not worth having. The AI visibility side →
Questions about automation work.
In practice: pipelines that read something unstructured — call recordings, PDF invoices, chat messages, CRM exports — make a decision about each item, and push a result somewhere a person will act on it. The model is one component, usually the smallest. Most of the work is the plumbing around it: reliable extraction, rate limits, retries, deduplication, and knowing what to do when a source changes shape without warning.
An agency sells you a build and hands over a diagram. I am the person who runs the thing afterwards and gets paged when it breaks, which changes what gets built: fewer moving parts, more logging, and no dependency that only I understand. It also means I will tell you when the honest answer is a spreadsheet and a cron job rather than an agent framework.
Python for anything that has to be reliable, n8n where a client needs to see and edit the flow themselves, Playwright when a platform has no API and the data is only in the interface, local Whisper for transcription so audio never leaves the machine, and Claude or a comparable model for the classification step. Postgres or Supabase for state. Nothing exotic — the exotic part is usually the reason the previous automation broke.
Where a hosted model is genuinely needed, yes, and the account is the client's so the cost and the data are theirs. Where a local model does the job, it runs locally — transcription is the obvious case, and it is why call analysis costs under $5 per hundred calls rather than per call. I will always tell you the running cost before the build, not after.
By never asking it for a fact. Numbers come from the source system; the model classifies, extracts or routes. On top of that, automated gates on the output — expected ranges, required fields, banned phrasings — and a report of what could not be parsed rather than a plausible guess. A system that cannot say "I do not know" will lie to you eventually.
One narrow system first, priced as a fixed-scope project, because the fastest way to find out whether automation helps a specific business is to ship one thing that either saves money or does not. Prices are published on the pricing page. If it works, the natural next step is a monthly arrangement covering the automation plus the measurement layer, since the two feed each other.
Which decision is your team not making because there is no time?
That is the automation worth building. Tell me the process, and you get a written answer on whether it is worth automating — including when the answer is no.