How to turn service call enquiries into dispatch-ready jobs

This guide from AR Labs is for owners, office managers, dispatchers and customer service staff at plumbing, heating, HVAC, electrical and similar field-service businesses. If your office spends the afternoon ringing customers back to ask what exactly is wrong, which property it is, or whether it is an emergency, the jobs were not dispatch-ready when they were booked. The guide shows how to define a complete job record, collect it at first contact by phone, web form or message, and check it before a job reaches the dispatch board, so that a technician with the right skills and parts arrives at the right address in the right time window. Most of the fix is a written job record, a call script and the configuration of software you probably already pay for; the guide says where integration, custom software or AI might come in after that.

It applies our general method for mapping a business process before automating it, and rests on public job advertisements, owners' posts in trade forums and the software vendors' own pages. We have not built a booking or dispatch system for a trades firm.

Why jobs arrive incomplete

Turning a call into a job is skilled, paid work. Job advertisements for service coordinators at HVAC and plumbing firms in the United States, the United Kingdom and Australia describe the same role: log service requests, prioritise urgent call-outs, coordinate parts and technician calendars, keep job and site records accurate, and chase return visits. One UK heating and plumbing employer asks for enough trade knowledge to ask sensible questions rather than pass messages to an inbox. When that first conversation is thin, the cost lands later: a call-back before anyone can be sent, or a technician who arrives without the skill, the part or the access the job needed.

Three patterns recur in public reviews and trade discussions:

• Details belong to the job, not the customer. A landlord may have several properties, each with its own access and contacts. When notes hang off the customer record, the wrong tenant gets the text or the technician arrives without the gate code.
• Exceptions take judgement. Urgent call-outs, return visits, parts on order and changed times all break the tidy path a booking screen assumes.
• Taking a message is not taking a job. Owners in public forums describe answering services that wrote down a name and number, and evening call-backs that found many of those callers had already booked someone else.

flowchart TD
  C["Customer calls, emails or fills web form"] --> T["Whoever is free answers"]
  T --> N["Name, number, rough problem noted"]
  N --> B["Job booked on calendar"]
  B --> D{"Dispatcher: enough to send someone?"}
  D -->|"no"| CB["Call customer back for details"]
  CB --> D
  D -->|"yes"| V["Technician visits"]
  V --> R{"Right skill and parts?"}
  R -->|"no"| RV["Return visit booked"]
  R -->|"yes"| F["Job done"]

The current flow in many small firms: details are recovered after booking, and some only surface on site.

What your existing software already does

Before changing anything, find out what your field-service management software (the system that holds customers, jobs, schedules and invoices) can already do. The common products, among them ServiceTitan, Housecall Pro, Jobber, simPRO and Tradify, handle the routine cases: taking a booking, recording the customer and job, and scheduling it. From their own published pages:

• ServiceTitan describes custom prompts that help staff collect the information the business needs on every call, with customer details filled in as calls arrive (ServiceTitan call booking), and its help documentation covers configuring job types with default services (ServiceTitan help: call booking).
• Housecall Pro lets a business set up its services, pricing and coverage areas for online booking, with booked jobs going straight to the calendar (Housecall Pro online booking).
• Jobber online booking covers service descriptions, durations, team calendars, lead time, buffers between appointments, service area and drive-time limits (Jobber online booking).
• Tradify collects leads from online forms and email, turns enquiries into quotes and jobs, and lets staff attach photos, videos and notes to jobs (Tradify features).
• General form builders such as Jotform can show follow-up questions depending on earlier answers, make a field required only when it applies, and skip pages that do not apply (Jotform conditional logic).

The manual work that remains, by owners' accounts in public reviews and forums, is the patterns above plus long web forms and scripts not followed; some public reviews of answering services report requested questions being skipped or noted inaccurately. The steps below deal with those gaps.

Set against the current flow above, the path the steps build has no call-back loop. Seven stops run from first contact to dispatch; a job missing a required fact goes to a not-ready list with a named owner instead of the dispatch board, and two decisions, marked with flags, stay with a person.

Step 1: Write down what a dispatch-ready job contains

What to do. On one page, list every fact a dispatcher needs to send the right person with the right parts without phoning the customer again, grouped into customer, site, job and scheduling. Mark each required or optional, and note who can supply it: the caller, your records, or only a technician on site.

Why. Nobody can ask for information that has never been written down as needed, and new software will otherwise ask whatever its defaults ask. The list becomes the source for the script, the form and the software fields, so all three ask the same thing.

Example. For a no-heat call to a gas boiler: the caller's role (owner, tenant, property manager), who authorises and pays, the address and access notes, the boiler make and rough age, the symptoms (heating, hot water or both; any error code), any smell of gas, anyone vulnerable in the property, and available windows.

• One page lists the facts for each common job type
• Each fact is marked required or optional
• Site facts are separate from customer facts
• The dispatcher has confirmed the list is what they actually need

Step 2: Sort your job types and agree urgency rules

What to do. List the job types that make up most of your calls (for example: no heat, leak, blocked drain, annual service, installation quote). For each, write your urgency classes and the rule that puts a call in each. Write safety rules as instructions the person answering must follow, approved by the owner or a qualified technician.

Why. Urgency decides the arrival window, which decides who can go; if every call handler judges it differently, the schedule is rebuilt by hand all day.

Example. "Water actively leaking and cannot be isolated: emergency, same day. Leak contained, stopcock off: urgent, next available. Dripping tap: routine." For a reported smell of gas, the script tells the caller to follow the gas emergency procedure for their country before anything else, and the call is handed to a person. The script does not diagnose.

• Top job types listed, with the questions that distinguish them
• Urgency classes defined by observable facts, not feel
• Safety instructions approved by a qualified person
• Calls outside the rules go to a named person, not a guess

Step 3: Give whoever answers the phone a script per job type

What to do. Turn steps 1 and 2 into a short call script per job type: the order of questions, follow-ups for vague answers, and a read-back at the end. Keep it beside the booking form, or load it into your software's call prompts.

Why. A script lets someone without deep trade knowledge collect what an experienced coordinator would. The read-back catches mistakes while the customer is still on the line, not on site.

Example. "Is water coming out now? Can you turn it off? Where is the leak? How old is the water heater, roughly? Can you send a photo of its label?" Then: "So that's a leaking water heater in the garage at 14 Elm Road, water now off, you're there after 2pm. Is that right?"

• Script per common job type, with follow-ups for vague answers
• Read-back at the end of every call
• Script available where calls are answered, including any outside answering service
• Spot-check a sample of booked jobs against the script

Step 4: Make the web form ask the same questions

What to do. Rebuild your booking or enquiry form from the same list. Ask the job type first, then only the questions for that type. Check the postcode against your service area early, allow photo upload, say what the details are used for, and ask only what the job needs.

Why. The same questions produce the same record whichever way the customer arrives. Branching keeps the form short; at least one public review of a trades booking form complained that it was too long and hard to adjust. Addresses, access codes, photos of a home and notes about vulnerable occupants are personal data, so check the data-protection rules where you operate.

Example. "Blocked drain" asks which fixture, whether other drains are affected, and for a photo. "Annual service" asks for the appliance make and last service date instead.

• Form questions match the script
• Job type first, with conditional questions after it
• Service-area check early
• Photo upload offered for job types where photos help
• Form says what the details are used for and asks nothing the job does not need

Step 5: Configure your software to hold the record

What to do. Add your job types, urgency classes and required fields to your field-service software. Store site details (access, contacts, equipment) against the location, not only the customer, and load your script into any call prompts or booking questions it supports.

Why. A record in a notepad or email gets re-typed, and re-typing is where details drop. Site details held against the site carry over to the next job there, and multi-property customers stop getting the wrong messages.

Example. A property manager with 12 rental units has one customer record and 12 locations, each with its own tenant contact and access note, so a call about Unit 7 opens Unit 7's history.

• Job types and urgency classes configured
• Required fields set per job type
• Site details stored against locations
• Booking questions or call prompts loaded, if the software has them

Step 6: Add a readiness check before dispatch

What to do. Make "ready to dispatch" a status a person sets after checking the record against the list from step 1. Jobs missing a required item go to a short "not ready" list that names the missing item and who will get it.

Why. The check moves the call-back from the dispatcher's busiest hour to a planned slot and makes gaps visible before anyone is on site. The decision to send someone stays with a person who knows the technicians.

flowchart TD
  C["Call, form or message"] --> Q["Script or form by job type"]
  Q --> RB["Read-back or form review"]
  RB --> R["Job record in your software"]
  R --> K{"Person checks: all required facts?"}
  K -->|"missing item"| NR["Not-ready list: item and owner named"]
  NR --> R
  K -->|"complete"| U{"Person decides: urgency and technician"}
  U --> D["Dispatched with skills and parts noted"]
  U -->|"outside the rules"| O["Owner or senior tech decides"]

The target flow. Diamond shapes are decisions a person makes; nothing is dispatched by rule alone.

Example. A web booking for "no hot water" arrives without the appliance type. It goes on the not-ready list as "appliance type: office to text customer", and is dispatched once the customer replies with a photo of the label.

• "Ready to dispatch" is a status someone sets deliberately
• Not-ready list names the missing item and the owner
• The list is cleared at set points in the day
• Urgency and technician choice stay with a person

Step 7: Plan for exceptions and after-hours calls

What to do. Write down what happens when the normal path does not fit: after-hours calls, overflow when everyone is on site, return visits, and repeat customers with a new property. For after-hours, choose between an on-call person, an answering service working from your script, or a callback promise with a time.

Why. Message-taking is where enquiries go cold; the aim is a confirmed next step. If anything is automated out of hours, say so and offer a person: some callers reject automated answering, and some commercial contracts require a person to answer.

Example. After 6pm, the answering service uses your script, books routine work into the morning's readiness check, and phones the on-call engineer for emergencies.

• After-hours route written down and tested
• Outside services use your script, not their own
• Callers can always reach a person
• Return visits are linked to the original job

Step 8: Measure, then decide whether to go further

What to do. For a set period, count call-backs before dispatch, visits without the right skill or part, and enquiries that never became a booking, noting which missing fact caused each.

Why. The counts show whether the script, form and configuration have worked; without them there is no way to tell whether a change helped. If they have worked, stop. Only a gap that survives good configuration and a trained team is worth paying to close with integration or software.

Example. If most remaining call-backs are about access to commercial sites, add an access question and a site contact field. If they are about customers who cannot describe the fault, an adaptive conversation that asks a follow-up when an answer is vague could earn its place.

• Call-backs, wrong-skill visits and lost enquiries counted
• Cause recorded for each
• Decision written down: stop, adjust, or look at options below

Choosing how far to go

Each row costs more than the one above it; the ladder of changes explains the general rule.

Approach	What it involves	Good fit when	Limits
By hand	Written job record, call script, read-back, not-ready list	Few call handlers, steady job mix	Depends on people following the script on busy days
Configure an existing tool	Job types, required fields, booking questions, location records in your field-service software and form builder	You already pay for the software and use it daily	Fixed questions; long forms if every case is covered
Connect tools	Web form, phone system and field-service software passing records between them through built-in integrations or an automation service	The same details are being re-typed between systems	Integrations need testing and someone to watch for failures
Build custom	A guided conversation (web chat or voice) that asks follow-ups when answers are vague and hands a confirmed record to a person	Measured gaps remain after configuration and training	Most cost and risk; must hand off into your existing software, not replace it

Our Salesbot shows the last row's pattern in a browser demonstration, not a phone system. It is a structured conversation: the language model talks, while code tracks which answers are still missing and when to move on, and the answers are read back before it closes.

AR Labs offers this kind of discovery and design work to owner-run businesses; more about us is on the about page.