The job is on the board and the tech is assigned. If your team still handles confirmations and follow-up by hand, the work around that job can consume time the schedule never shows.
Someone has to confirm the day before. Someone has to text when the truck leaves. Someone has to notice the invoice never went out, ask for the review, and remember that a tech wrote "water heater is 14 years old, recommend replacement" on a job three months ago that nobody followed up on. On a slow Tuesday all of that happens. On the Monday after a hard freeze, none of it does, and the week you needed the follow-up most is the week it did not run.
Before hiring someone to handle routine follow-up, separate the decisions that need a dispatcher from the messages a recorded job event can trigger.
What ServiceTitan, Housecall Pro, and Smart Service already do
Your field service software already holds everything the follow-up needs: the customer record, the address, the schedule window, the assigned tech, the job status, the invoice, and the tech's notes. Most of these platforms also ship some notification features. Check what yours already sends before you build anything. If Housecall Pro is already sending an on-the-way text your customers like, do not rebuild it in n8n. You will end up with two systems texting the same person and no clear owner for either.
Do not assume your platform cannot combine conditions. ServiceTitan's audience documentation describes multiple filters, including dynamic audiences that update as records change. Check the rules and messaging features available in your actual plan, then test the exact sequence you need. A custom workflow earns its place when a required step crosses systems or cannot be configured reliably in the tools you already pay for. The gap must be demonstrated, not assumed.
Source: ServiceTitan: create audiences. Check the features and plan available in your account before deciding what to build.
The four gaps around a plumbing job
Gap 1: the confirmation, the afternoon before.
An unconfirmed job is a truck roll gamble: locked gate, nobody home, wrong unit number, the tenant who did not know. A text sent the afternoon before with the arrival window, the tech's first name, and two reply options (C to confirm, R to reschedule) turns that gamble into information you get while you can still fill the slot with somebody else.
Gap 2: the on-the-way text.
This one fires off a status change, not a clock. When the tech sets the job to en route, the customer gets a text with the tech's first name and a fresh arrival window. The value is not politeness. It is the "is he still coming" questions your office stops fielding. I do not have a measured number for how many of those you get in a day, and neither does anyone selling you software. Count them for one week and you will have your own.
Gap 3: the hour after the job.
Invoice out, photos attached, honest feedback requested. Use the same review eligibility rules for satisfied and dissatisfied customers. Send service problems to the owner as a separate task; do not use a complaint or callback flag to decide who gets a public review invitation.
Gap 4: the deferred work.
The tech recommends a replacement, the customer says not this month, and that note sits in job history forever. This can be a valuable gap to close when recommended work is being forgotten. A workflow can read job notes tagged as recommended work and queue a follow-up 60 or 90 days out, drafted, waiting for a human to approve before it sends.
Assign an owner to each follow-up step, whether native software, a workflow, or a person handles it. A step with no owner is easy to miss on a busy week.
The workflow, step by step, in an account you own
What follows is a build pattern, not a case study. No client is named in it. Where I cite a client result later in this post, it is a published figure with its basis attached.
We build this in n8n, running in the client's own instance, connected to the client's own messaging account. That matters less for how it works and more for what happens later: you can open it, read the run history line by line, see exactly what was sent to whom, and pause it without calling anyone.
Step 1: get the event out of the field service software.
There are three ways, and which one you get depends on your platform and your plan. A webhook on job status change if your plan exposes one. A poll every five to ten minutes against the jobs endpoint, filtered by an updated-since timestamp with a stored bookmark, if it does not. A scheduled export if you are on an older desktop-based system where the API is thin. I cannot tell you which tier your account has without looking, and that is the first thing to check, because it sets the shape of the whole build.
Step 2: normalize the record into one shape.
Every downstream node reads one internal object: job id, customer id, mobile number in E.164 format, window start and end, tech first name, job type, status, tags, and a consent flag. Do this once at the top. It means the day you change platforms, or add a second one for a sister company, you rewrite one node instead of fourteen.
Step 3: gate before you send anything.
Five checks: is this a valid mobile number, is the customer on the do-not-text list, is it inside quiet hours for their timezone, has this customer already hit the daily message cap, and is this message transactional or promotional. A failed gate writes a log line and stops. It does not fail silently, because a silent drop is how you find out three weeks later that half your confirmations never went.
Step 4: reserve the message, then send and record the receipt.
Build a key from the job id, message type, and scheduled date. Reserve it atomically under a unique database constraint before calling the provider; an overlapping run must fail that reservation and stop. Store the provider receipt and write the message into the job history. If the provider call times out, mark the send uncertain and check its status before trying again. The dispatcher should see an unresolved send instead of the customer receiving a blind retry.
Step 5: catch the reply.
An inbound webhook handles responses. "C" confirms and updates the job. "R" creates a task assigned to a named dispatcher and auto-replies with that person's name so the customer knows a human has it. Anything else routes the full thread to a named person's inbox or a Slack channel that person owns. An inbound reply must never land somewhere nobody is responsible for.
Step 6: the post-job branch.
After completion, schedule the same honest-feedback invitation for all eligible customers, with consent and duplicate checks. Do not filter invitations by satisfaction, callback flags, or invoice disputes: Google's review policy prohibits selectively soliciting positive reviews. Route flagged service problems to the owner independently. An unpaid invoice can have its own reminder flow, with disputed invoices routed to the office manager for review before a collection message.
Review policy: Google Maps prohibited and restricted content. Ask for an honest account of a real experience, without incentives.
| Step | What triggers it | Who a human hears from |
|---|---|---|
| Confirmation text | Job scheduled, sent the afternoon before the window | Dispatcher, only if the customer replies R to reschedule |
| On-the-way text | Tech sets job status to en route | Dispatcher handles an unresolved provider response |
| Invoice nudge | Job completed, invoice unpaid after three days | Office manager approves the second nudge |
| Review request | Job completed, consistent invitation timing for all eligible customers | Owner handles service problems separately; invitations are not filtered by satisfaction |
| Deferred work follow-up | Tech note tagged as recommended, 60 or 90 days later | Named person approves each draft before it sends |
What happens when the same job event fires twice
This is the question underneath every "just automate my dispatch" pitch, and it is what separates a demo from something that still runs in a year. Webhooks retry. Polls overlap when one run takes longer than the interval. A job gets reopened and re-completed. A tech taps en route twice because the app lagged on a bad signal. Every one of those can fire the same branch of your workflow again.
Use a database that can enforce a unique reservation atomically, such as Postgres. A read followed by an insert into an ordinary log is not enough: two overlapping runs can both see an empty result and send. Keep reservation, accepted, and uncertain states distinct, and reuse the original key during reconciliation. If the provider supports idempotency keys, use the same key there too. Your local log alone cannot guarantee exactly-once delivery across a network failure.
Test it on purpose before go-live. Fire identical webhook payloads simultaneously and confirm only one provider call occurs. Simulate a provider accepting the text and then timing out: the workflow must reconcile that attempt without sending again. Reopen and complete a test job and verify that it retains the original review-invitation key. Add a per-customer daily cap, but test its concurrency behavior too.
Who approves the unusual cases
Anything the workflow is not confident about goes to a named person, not a shared inbox. Reschedule requests. Replies that are not C or R. Jobs above whatever dollar threshold you set. Any job where the tech flagged a callback. Every deferred-work follow-up draft, one click each.
In practice this becomes a short daily queue, and most items are a single click. Two things make it work. First, the customer can always reach a human, by name, in one reply. Second, someone specific owns the queue. If the queue is not on a person's actual job description, it turns into a graveyard within a month and you are back where you started, only now with a system you have stopped trusting. Assign the name before you launch, not after.
What this does not fix
Dirty data. If a third of your customer records have a landline sitting in the mobile field, or the same household exists three times under three spellings, automation will broadcast that mess faster and at higher volume. Clean the customer table first, or at minimum run the gate in log-only mode for a week and look at how many records fail it.
Consent. Keep a per-customer consent record with a timestamp and a source, honor opt-outs automatically inside the gate step, and keep transactional messages separate from review requests and promotions in your templates. Registration and content rules for business texting come from your messaging provider and the carriers behind it, and they change, so get the current requirements from your provider in writing before your first send and have your own counsel read the templates. I build the workflow. I do not give legal advice on message content.
And it will not fix the wrong bottleneck. Sometimes follow-up is not the constraint at all: it is a backlog you cannot staff, techs writing quotes on paper, or an intake form that drops new requests into a shared inbox nobody owns.
Nobel Tip Kitabevleri is the version of this I would point at. Before anything got automated, every department was audited in person and one prioritized roadmap came out of it, and the client reports an 18% cut in operating costs after executing that roadmap. The order mattered more than the tooling.
If you are not certain follow-up is your constraint, get the map before the build. The Free Opportunity Map is five form fields and about two minutes; within two business days we send back with the three places AI or automation pays back fastest in your shop, ranked, with what each one takes to build. Free, yours to keep, no obligation.
Build order, and what you should own at the end
Build the on-the-way text first. One trigger, one message, easiest thing in the stack to test and the fastest to show your dispatcher a difference. Then the confirmation with reply handling, because replies introduce humans. Then the post-job branch. Then deferred work last, because it depends on techs tagging their notes consistently, and that is a habit you have to build before software can read it.
Timeline for a build in this shape is roughly 14 to 21 business days once API access is sorted out. The variable is never the number of nodes. It is access to your platform's data and the state of your customer records.
Ownership is the part most buyers skip and later regret. The n8n instance should be yours. The messaging account should be in your name, with the number registered to your business. The credentials, the run history, the sent log: yours, and you should be able to log in today and read them.
VOT Distribution illustrates the broader work involved: two AI storefront assistants are in production, alongside outbound campaign systems. The client reports a 12% campaign response rate and $120K in generated sales opportunities from those campaigns. Those are VOT's reported results, not a forecast for a plumbing workflow.
If the answer to "can I see the workflow" is a screenshot, you are renting the automation, not owning it. That distinction costs you nothing while things work and everything the day you want to change vendors.
