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.
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:
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.
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.
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.
Call ML-0056. This is the one I'd point at if you only looked at a single thing:
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.
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:
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.
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.
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.
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