What this automation does
Job requests arrive from several channels and leave as a confirmed slot on the right technician’s schedule, with the customer kept informed at each step.
- Intake. Requests come from a web form, a booking widget, a shared inbox or a call transcript. Each one becomes a row in a jobs table, with the original text stored alongside it.
- Parse. A language model turns free text such as “water heater leaking from the bottom, tenant home after 3” into job type, urgency, required skill, estimated duration, access notes and the customer’s availability window, returned as strict JSON.
- Propose. A scoring step in code checks each qualified technician’s open time, starting location or previous job, drive time, certifications and workload, then ranks the best three options.
- Approve. The dispatcher sees the proposal in Slack or a simple board and accepts it, swaps the technician or moves the slot. True emergencies skip the queue and page the on-call technician.
- Book and notify. The job is written to the field service system, the technician’s schedule updates, and the customer gets a text with their arrival window. On the day, an “on my way” text goes out with an ETA.
- Reshuffle. When a job runs long or a technician calls out, the workflow re-scores the affected jobs and proposes moves, so the dispatcher is not rebuilding the afternoon from scratch.
When it is worth building
The return comes from two places: dispatcher hours and windshield time. If one person spends most of each morning on the phone moving jobs around, or technicians cross the county several times a day because jobs are booked in the order they came in, this is worth a look.
It is usually not worth a custom build below about five technicians, or when the scheduling board in your field service software already fits how you work. ServiceTitan, Jobber and Housecall Pro each ship a dispatch board, and some offer routing or capacity features on higher plans. Use those first. Build when you need logic they do not offer, such as custom skill matching, intake from several systems, SLA rules for commercial contracts or an approval step shaped around your dispatcher. If what you mostly want is an assistant that books jobs over chat or phone, start with the home services booking agent guide instead.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Intake | Web form webhook, shared inbox, call transcripts | Every channel lands in one jobs table, so nothing gets booked twice |
| Parsing | Claude Haiku 5.5 or Sonnet 5.5 with a JSON schema | Job descriptions vary wildly, and a fast model handles most of them cheaply |
| Scheduling logic | Postgres plus a code step, or Google OR-Tools for larger fleets | Slot and technician selection must be deterministic and explainable |
| Drive time | A routing API such as Google Maps | Straight-line distance misjudges bridges, highways and rush hour |
| Orchestration | n8n | Connects intake, scoring, approval and messaging, with retries and logs |
| System of record | ServiceTitan, Jobber, Housecall Pro or Google Calendar | Technicians keep using the app already on their phone |
| Customer messages | Twilio SMS | Confirmations, ETA texts and reply handling |
A word on access. Field service platforms restrict their APIs. ServiceTitan access usually runs through its partner or developer program with approval tied to your account, and Jobber and Housecall Pro gate API access behind developer app registration or specific plans. We confirm this in week one, because it decides whether the workflow writes jobs back directly or falls back to calendar sync. Our ServiceTitan notes go into more detail.
How to build it
- Map the real constraints. Sit with the dispatcher for a morning and write down every rule they apply from memory: who is certified for gas work, who does not cover the far side of the river, which commercial clients need a two-hour window, and how long each job type actually takes.
- Define the job schema. Job types, required skills, default durations, priority levels and time windows. The parser writes this schema and everything downstream reads it.
- Load technician data. Skills, certifications, start location, working hours and time off. Keep it in a table the office manager can edit, not hard-coded in a workflow.
- Write the scoring function. Start simple. Filter to qualified technicians with a long enough gap, rank by added drive time, then break ties on workload. Log the score breakdown for every proposal so the dispatcher can see the reasoning.
- Add the approval step. Send the top proposals to the dispatcher with one-click accept. Record every override and its reason, because overrides are your list of missing rules.
- Connect write-back. Create or update the job in the field service system, then read it back to confirm. Never assume a write succeeded.
- Add customer messaging. A confirmation at booking, a reminder the day before and an ETA text when the technician heads out. Classify replies into confirm, cancel, reschedule or needs a human.
- Handle the bad day last. Build the reshuffle path once normal booking is stable. It is the hardest part and also the most valuable.
What breaks in production
- Duration guesses. If “AC not cooling” is booked for 60 minutes and routinely takes 150, every afternoon slips. Recalculate default durations each month from actual job times.
- Double booking from sync lag. A dispatcher drags a job on the board while the workflow books the same slot. Hold the slot at proposal time and re-check availability right before writing.
- Bad addresses. Unit numbers, new subdivisions and rural routes geocode poorly. Validate addresses at intake and send low-confidence matches to a person.
- Replies that are not keywords. “Can he come after 4 instead?” is not a clean reschedule. Anything the model cannot classify with confidence goes to the office, never into a loop of automated texts.
- Emergency surges. No-heat calls on the first cold week of winter break a tidy schedule. Give emergencies their own path that interrupts the plan instead of competing in the scoring.
- Time zones and daylight saving. Store times in UTC with the customer’s zone attached. DST weeks reliably expose bugs in hand-written slot math.
Timeline and cost
Most dispatch builds take four to eight weeks because they touch intake, a field service system, scheduling logic and customer messaging. Lumeor typically builds this in the range of $15,000 to $35,000. The lower end covers one intake channel, calendar-based booking and dispatcher approval. The upper end adds direct write-back through a partner API, automated reshuffling and two-way SMS. Waiting on API approval is the most common cause of delay. For how we scope multi-workflow projects like this, see the n8n automation program cost breakdown.
How to measure success
- Dispatcher hours per day spent building and repairing the schedule
- Average drive time per job, and completed jobs per technician per day
- Time from request received to customer confirmed
- Share of automated proposals accepted without changes
- Arrivals outside the promised window
- Reschedules and no-access visits, which usually trace back to poor intake data