Who automates dispatch and booking follow up for a plumbing company?

It has two halves. On the dispatch side, every new job, wherever it came from (a call, a website form, a text, a marketplace lead), becomes one record on the board with the address, the problem and the access notes, without anyone retyping it. When the job is assigned, the customer gets the window and the tech's name. When the tech marks en route, the customer hears about it before the truck is in the driveway. When a job is rescheduled, the customer is told once, correctly, instead of not at all.

The follow-up side is what happens after the truck leaves. An estimate sent Tuesday and untouched by Friday gets a nudge. A closed job gets a review request the next day, from the customer who was happy, not the one who was not. A recommendation the homeowner declined in March gets revisited before the season when it matters. A membership that is about to lapse gets a renewal note while the relationship is still warm. None of this is clever. It is a written process that software executes on time, every time, which is the whole trick.

It is worth naming what this does not do. It does not decide who goes where. Routing a plumber is judgment: who is closest, who has the part on the truck, who handles that customer well, which job can slip to tomorrow without a complaint. A good build leaves that with your dispatcher and takes away the typing, the chasing and the question nobody can answer at 4pm, which is whether anyone called the Hendersons back. If a vendor tells you the software will decide dispatch better than your dispatcher, ask them how many trucks they have run.

Follow-up is usually where the money is, and it is the half owners skip, because the dispatch board is visible and someone complains when it breaks. Unsent follow-up is silent. Quotes that never got a second look, memberships that lapsed, review requests nobody sent: nothing in your software records the miss, so it never reaches a report and it never makes your shortlist.

The build lives or dies on what your field service platform will let an outsider read and write. There are roughly three levels, and you want to know which one you have before you pay anyone. The best case is an API with webhooks that fire on real events (job created, status changed, estimate sent, job completed) plus write access, so the automation reacts the moment something happens. The middle case is a read and write API with no event feed, which still works, but the automation checks on a schedule, so instant becomes within a few minutes. The worst case is a nightly export, which means batch only: your follow-up can still go out, but nothing happens in real time. Ask your software vendor which of the three you have, in writing, and get the answer before you take quotes.

The second dependency is your own data discipline, and it is the one that sinks more builds than any API limit. A trigger needs a state change that a human actually makes. If half your techs close jobs the next morning, if estimates sit in draft forever because nobody presses send, if the same customer exists three times under two spellings of the same street, then the automation fires late, fires twice, or texts the wrong person. The fix is boring and cheap: one owner for the data, agreed job statuses everyone uses the same way, and a week of cleanup. Do that before the build, not after, because automation does not clean a mess, it repeats it faster.

Where the automation runs is the third thing, and it is a question of ownership rather than capability. Benian builds these on n8n inside your own account, with your own credentials, so you can open it any time and see exactly what ran and what it sent. When a provider hosts the workflow on their own platform and holds the keys, you are renting the process, and the day the relationship ends you find out how much of your operation went with it. Ask whoever you hire where the build lives and whose login opens it.

Count for two weeks before anything is built. Five numbers, all of which you can get without buying software: time from first contact to a scheduled window, the share of jobs where the customer got a confirmed window and an arrival heads-up, estimates sent against estimates accepted within fourteen days, how many closed jobs received any follow-up at all, and dispatcher touches per job, which is a tally sheet on a desk. If you cannot count it now, you will not be able to prove the build worked, and you will not be able to hold your vendor, or us, to anything.

After launch, measure the same five with the same definitions over the same length of window, and add one more: what the automation got wrong. Duplicate texts, a message to the wrong customer, a follow-up sent after the job was cancelled. Every real build has some of these in the first month. A provider who reports zero errors usually means nobody is checking, and the fix belongs in the build (a retry, a guard, a person who gets told) rather than in a reassurance.

Label your own numbers the way you should demand a vendor label theirs. At Hall's Heating & Air, the 100% pickup rate through seasonal peaks, the 23 jobs booked in month one, and the fact that 80% of the calls the AI handles arrive after hours are all measured, straight from the call logs. The 2 hours of owner time saved per day is what the owner told us, so we call it client-reported and we do not dress it up as a system reading. Those figures come from an HVAC contractor running a voice agent on intake, not from a plumbing dispatch build, and that distinction matters when you are deciding what to expect.

Four questions separate builders from talkers, and they work on us too. First, make them write a real record into your system in front of you, using your login, before you sign anything. "We integrate with your field service software" can mean a booked job on your board or an email with a transcript attached, and the demo settles it in five minutes. Second, ask what happens when a step fails at 2am: who gets told, does the job land somewhere a human will see it in the morning, does it retry. A silent failure is worse than no automation, because you stop checking. Third, ask who owns the accounts and the build if you part ways. Fourth, ask what they would refuse to automate in your shop; a provider with no answer is selling builds, not judgment.

Two more things, and then the money. Ask for their numbers with a basis attached, measured or client-reported or projection, and walk if every figure is round and none carries a label. And ask where your customer data goes: which third parties touch it, where it is stored, and what their notification window is if something leaks. Get that in writing rather than accepting a badge on a website as the answer. Nobody, us included, should be waving a certification at you instead of naming the systems your data passes through.

On price: the only figure Benian publishes is the $4,500 AI Audit, four weeks, fixed scope, half at kickoff and half when the plan is delivered, and you keep the plan whoever builds from it. Automation builds are quoted after the diagnosis because the drivers genuinely vary: how many systems have to talk to each other (field service platform, phone, calendar, accounting, review platform), whether your software supports real events or only scheduled checks, how many workflows and message rules you want, how clean your customer and job data is today, whether a human approval step sits inside the loop, and your job volume. Two plumbing companies of the same size can land far apart on all six.

A fair quote names the workflows in scope one at a time, says what happens when each one fails, states who owns the accounts, and lists what is out of scope. A quote that is one line and one number is a guess, and you will pay for the guess later in change orders. Once scope is settled, a build ships in 14 to 21 business days, and a smaller single-workflow project in 7 to 10. The clock starts after the scope, and the data cleanup is usually the part that takes longest on your end.

If you run one or two trucks and book ten jobs a week, do not buy this. One person who knows every customer, a phone, a board, and a fifteen-minute block each afternoon for callbacks will beat a build you spend more time maintaining than using. Automation earns its money on repetition, and at low volume there is not enough repetition to pay it back. Any provider who will not say that to you is not describing your business, they are describing their pipeline.

Skip it too if you have no field service software at all, or if your team does not really use the one you bought. Buying the field platform and getting everyone to use it the same way is the purchase in that case, and it is the one that makes every later automation possible. Same answer if your process is not written down: an automation is a written process executed by software, so if two dispatchers do follow-up two different ways, you are paying to freeze one of them in place before you have decided which one is right.

And check which half is actually leaking before you spend. If calls go unanswered during a burst and homeowners with water on the floor are dialing the next name on their list, then automating follow-up on jobs you never booked is polishing the wrong end of the chain. Your phone log will tell you which problem you have, and reading it costs nothing. That is also the first thing a diagnosis looks at, and if it turns out your dispatch and follow-up are already tight, the honest recommendation is to fix the phone and leave the rest alone.