What I've built

I'm not an engineer. I spent five years running operations for a plumbing company in Toronto — not one job in the office, all of them. The phones, the schedule, the quotes, the invoices, the on-call rotation at 2am. Now I build the AI that does that work, and I run a company on it.

Everything on this page is running against real work, for real shops, with real money attached. That's the only reason it's worth reading. Most of what gets written about AI right now has never been near a consequence.

Every seat in the shop

People who build software for the trades usually haven't done the job. That's why so much of it is beautiful and useless. I know where a service business actually leaks because I was the one plugging the holes:

The phoneRings during a job, rings at dinner, rings at 2am. Miss it and the customer calls the next guy on the list — they don't leave a voicemail and wait.
SchedulingGuessing how long a job takes, then watching the whole day slide when the first one runs over.
DispatchGetting an actual technician moving. Not notified — moving, and confirmed.
QuotingPrices living in someone's head. The same job quoted three different ways by three different people.
Invoicing and collectionsWork finished weeks ago and still not billed, because billing is what happens after everything else and there's never an after.
The on-call rotationSomebody has to carry the phone. Nobody wants to. It breeds more resentment between techs than pay does.
The booksReconciling what came in against what went out, usually months late, usually wrong.

Every one of those is a seat a small shop can't afford to hire for, so the owner ends up sitting in all of them. That's the actual problem. Not software — one person doing seven jobs badly instead of one job well.

So I'm building an AI employee for each seat. That's what JobSend is. Below is the one with the longest log, then the honest status of the rest.

The dispatcher — the one I can prove

When someone calls a plumbing shop at 1am with water coming through the ceiling, the normal outcomes are all bad. It goes to voicemail. Or an answering service takes a message that sits in an inbox until 7am. Or it gets forwarded to whichever tech is on call, who is asleep and does not hear the phone.

The system I built answers the call, works out whether it's a real emergency or something that can wait until morning, and then — this is the part that matters — pages a technician and keeps going until one actually confirms he's taking it. If the first tech doesn't answer, it moves to the next. Every step is timestamped, so the owner can see what happened rather than take someone's word for it.

Answering the phone is the easy part, and everyone does it. Refusing to let the job die between the phone call and a technician is the hard part.

What the log says

445
after-hours calls logged
~3 min
typical time to a confirmed technician
3 of 4
confirmed inside 6 minutes

Straight from the live dispatch log for the plumbing shops we cover. "Typical" means the median. "3 of 4 inside 6 minutes" is measured against confirmed dispatches, not against every call that came in — those are different denominators and it matters. It has also dropped calls: two are documented. Anyone claiming a perfect record on emergency work is either not measuring or not telling you.

One night, in detail

Call ML-0056. This is the one I'd point at if you only looked at a single thing:

10:29pmCall comes in, gets classified as a real emergency, first technician paged.
10:36pmNo answer. Seven minutes gone. This is exactly where the job normally dies.
10:37pmChain escalates on its own. Second technician confirms he's got it.

The interesting thing isn't that software answered a phone. It's that a human being failed — a tech didn't pick up, which happens constantly and is the single most repeated complaint in every trade forum you can find — and the customer never felt it. That's the whole product in one line.

JobSend — one system, six employees

Everything is a job. It's born when someone calls, texts or books online. It might become a quote. It becomes scheduled work, sometimes across two visits. It becomes an invoice, and the invoice gets paid. One record, one identity, start to finish.

Around that spine sit six AI employees — the seats above, staffed:

ReceptionistAnswers, works out what the caller actually needs, books it.
DispatcherGets a technician moving and chases until one confirms.
QuoterDrafts the price off what was said on the call. A human approves before anything goes out.
InvoicerBills the finished work instead of it sitting for three weeks.
ImporterGets the shop's existing mess in — customers, price lists, history.
AnalystAnswers "what happened with the Henderson job" without opening four systems.

Emergency dispatch isn't a separate product bolted on. It's a job that comes in flagged as an emergency and takes a fast path — skip the quote, go straight to dispatch and escalate.

Where each one honestly stands

The dispatcher is the only seat with a paying customer and a long log behind it. I'd rather tell you exactly where the rest are than let you assume.

Proven end to end on a test shop, not yet running for customers: reception, booking with real job durations, the quote drafted off a call and routed into a human review pile, the branded PDF that goes out after someone approves it, and one identifier threading the call, quote, booking and invoice together. That last part sounds boring and it's the whole point — in most shops those four things live in four places.

Still on my laptop, deliberately: the consolidated rebuild that puts all six on one database. Nothing in it reaches a real phone number, a real card, or a real customer until I decide it does. Shops move over one at a time, and the one with real emergencies running through it right now moves last.

We also had this syncing into Jobber and tore that out on purpose. Being a polite add-on to someone else's system meant inheriting their limits on exactly the parts that matter.

How it's actually built

Rented infrastructure, almost entirely. Twilio for the phones, ElevenLabs for the voice, Google Cloud underneath, Supabase and Firestore for data. I didn't build any of the hard parts of those and I'm not going to pretend otherwise.

What I did build is the layer that decides what happens: how a call gets classified, the escalation ladder, the confirmation logic, how a conversation becomes a priced quote, how one job keeps one identity from the first ring to the paid invoice, and the audit trail under all of it. Plus a fairly large harness of AI agents that writes and reviews most of the code. I direct that harness. I do not hand-write most of what ships.

That's the thing worth teaching, and it's why I'm writing this stuff down. The interesting question in 2026 isn't whether AI can write code — it obviously can. It's how a person who isn't an engineer keeps a system honest enough to put real emergencies through it.

Build log

Weekly write-ups of what I shipped and what broke go here. First one lands shortly.

If you run a service business and one of those seats is your problem right now, tell me which one. If I can't help, I'll say so.

admin@myserviceops.ai