Quote before they call elsewhere
A quote request that sits in an inbox for a day is a job that went to whoever answered first, and the price was rarely the problem. Below is the version I build for owner-run trades firms: an estimate assembled only from your own price book, an engineer picked by skill and postcode rather than by whoever is nearest the phone, and a customer email that ships switched off.
The questionHow do I reply to job requests with a price and get an engineer assigned without sitting at a desk?
How the working version is put together
One form in, one settings node to edit
I take the job through a form rather than an inbox, so the fields are known and nothing has to be parsed out of a paragraph somebody typed at speed. Everything you would otherwise edit in six different places lives in one settings node: your business name, the sheet, the Slack channel, and the switch that decides whether customers get emailed at all.
Price only from your own price book
A tab of your own rates is read and handed to the model with the request, and the estimate comes back as a category, an hour estimate and a low-to-high range built from those rows. The model is not permitted to invent a number. An estimate assembled from your price book beats a guess made on a phone, and it beats a competitor's number that you have to honour later.
If it cannot be priced, a person gets it
When the model cannot price the job from the book, the request goes to Slack marked for a human instead of reaching the customer half finished. This is the branch that decides whether automation is safe to leave running while you are under a boiler.
Pick the engineer deterministically
The servicemen tab is read and a Code node picks one on rules rather than on judgement: the right skill, the right postcode area, on call today, and it writes down why it chose them. Nobody wants a language model deciding who drives across the city, and rules make that decision auditable when somebody asks why a job went where it did.
Dispatch to the person and to the channel
Whoever qualifies gets a direct message with the job and the customer's contact details, and the channel sees it too, so the dispatch is not trapped in one person's phone. If nobody qualifies, the channel gets the job flagged UNASSIGNED, which is a queue rather than a silence.
Log every job, assigned or not
Every request is appended to a log tab whatever happened to it. The unassigned rows are the useful ones: read them after a month and they tell you exactly which skill or which postcode you are short of.
Quote and dispatch home-service jobs from a form with AI, Google Sheets and Slack
I ship this one as an n8n workflow you import and own: 16 working nodes, the setup written on the canvas, and one settings node holding your sheet, your channel and the customer-email switch. Instant download, and the switch that emails customers arrives turned off so nothing surprises anyone.
Open the kit on Etsy ↗Why you lose the job
The cost sits in the timing rather than in the minutes. The owner is under a boiler at eleven in the morning, which is where the owner should be, and the quote request that came in at ten past gets answered at seven that evening. By then the customer has had two other replies.
I have watched small firms lose work that way and conclude they were too expensive. Price had nothing to do with it. They simply came second, every time, to whoever happened to be sitting near a keyboard.
The parts that break
The price book going stale is the big one. Rates change, the sheet does not, and the automation keeps quoting last year's numbers with total confidence. Whoever owns the sheet owns the quotes, and that needs to be a named person rather than an assumption.
Postcode prefix matching is the second. I find it a decent proxy for who is nearby, right up until the day a river or a ring road makes it misleading. If you dispatch on drive time instead, that is one function to change rather than a rebuild.
The third is the customer email switch. It ships off for a reason. Read a few estimates against jobs you already know the price of before you let any of them reach a customer, because the first time it under-quotes a boiler swap you want that to be a Slack message you can laugh at rather than a number somebody is holding you to.
What it costs to run
One model call per request, against a price book that is usually a few dozen rows. This is a small prompt and a cheap one, and the automation platform will cost you more than the inference.
The honest cost is maintaining the two tabs: the price book and the list of who is on call. Neither is difficult and both go stale silently, which is why the log tab matters. It is the only place that shows you the automation quietly dispatching to somebody who left in March.
Why take this from me
Because I build production operations systems rather than demos, and the case studies below are running platforms with real work going through them. The pattern here, a model that proposes and deterministic rules that decide, is the one I reach for whenever the wrong answer costs somebody money.
The fair objection is that my proof is my own operation and the platforms I have built rather than a list of trades clients. That is true, and I would rather say it plainly than let you find out later.
The case for not doing this
If you quote everything on site because every job genuinely needs eyes on it, I would keep your money in your pocket. A range from a price book is useful for the common jobs and misleading for the bespoke ones, and if all of yours are bespoke, an automated estimate is a liability rather than a help.
If you are a one-person firm who answers the phone, you already reply faster than this does. The dispatch half only earns its keep once there are several people who could take the job and somebody has to decide which.
What lands on your desk
- I stand it up in your own n8n, on your own sheet, under your own credentials
- Estimates assembled only from your price book, so no number ever reaches a customer that you did not set
- Dispatch decided on rules you can audit: skill, postcode area, who is on call, and the reason written down
- An UNASSIGNED flag in Slack, so a job nobody matched becomes a queue rather than a silence
- The customer email left behind a switch that ships off, and a walkthrough I write for whoever inherits it
Open the proof
Published case studies of systems that are running. Each links to the thing itself.
My Etsy shop, all the kits ↗Booboo on GitHub (MIT, read the code) ↗
Questions this page answers
- Where do the price estimates come from?
- Only from your own price book tab, read fresh and handed to the model with the request. The model is never allowed to invent a figure of its own.
- What if a job can't be priced from the book?
- It goes to Slack marked for a human, instead of reaching the customer half finished.
- What decides which engineer gets the job?
- I write a code node that picks on rules rather than judgement: the right skill, the right postcode area and today's on-call rota. It writes down why it chose that person, so the choice can be checked later.
- Does it email the customer automatically?
- The switch ships off by default, so nothing sends automatically at first. I'd read a few estimates against jobs you already know the price of before turning it on.
- Should every trades firm build this?
- Not if every job genuinely needs eyes on it before quoting, and not if you're a one-person firm who already answers the phone faster than this would.
Want this built and handed over working?
One line is enough to start. You get an honest answer on fit, and a number rather than a discovery call.
Start a brief