Handoff template
Dispatch board job-request handoff
Most calls end as a job request on the dispatch board. If the request is complete, dispatch can schedule it without calling the customer. If not, every missing field is a callback.
| Who receives it | The dispatcher or scheduler, in whatever system holds the schedule |
|---|---|
| When it is used | During business hours for most service calls; next morning for non-urgent after-hours calls |
| Used by these call types | No-cooling (AC not cooling) call checklist, Tune-up and maintenance visit call checklist, Reschedule and cancellation call checklist, "Where's my technician?" call checklist |
Why this handoff matters
Dispatchers juggle live capacity, technician skills, drive time and priorities. The last thing they need is a request that says 'AC problem, call back'. The job request is the product of the whole intake process, and it is where missing fields become visible.
Some vendors describe putting jobs directly onto field-service boards. Avoca's ServiceTitan page says booked jobs include customer name, address, service type and call notes; Goodcall's HVAC scheduling page lists emergency reprioritisation and skill matching as dispatch concerns. Whether a job arrives through software or a person typing it in, the fields are the same.
The board also has to show which requests arrived flagged as urgent. Avoca's page for its Dispatch integration shows this in a demo log: overnight calls such as a burst pipe at 4:12 AM and a gas smell at 11:58 PM go to the job board, while a Saturday no-cooling call and a routine tune-up request are simply synced. Goodcall's dispatch-answering article recommends call recordings and reports so you can check whether information was passed on accurately. Both are vendor descriptions, but together they suggest two habits: tag urgency on the request itself, and spot-check requests against what callers actually said.
What the handoff must contain
| Field | Why the receiver needs it |
|---|---|
| Job type (repair, maintenance, estimate, return visit) | Decides duration and technician. |
| Priority tag from your rules | Dispatch sees why. |
| Customer, number, address, access | Standard fields, confirmed. |
| Problem in the caller's words | Technician preparation. |
| Equipment as described and age if known | Parts and skills. |
| Plan status | Priority and pricing. |
| Customer availability | Schedules without a callback. |
| What the customer was told | Dispatch keeps the promise or corrects it. |
| Existing-job link | Avoids duplicates for repeat callers. |
Example format
An illustrative layout with placeholder details. Adapt the labels to your own system; keep the order consistent so the receiver always knows where to look.
JOB REQUEST · type: repair · priority: P2 (rule: no cooling, plan member) CUSTOMER: Name · number (confirmed) · existing · plan: yes ADDRESS: Street · access: side gate, call on arrival ISSUE (caller's words): "…" since … EQUIPMENT: central AC, about 12 years (caller estimate) AVAILABILITY: weekdays after 1 pm; flexible for cancellations TOLD CUSTOMER: request received, dispatch will confirm by [time] LINKED: none found for this address
Delivery channels
- A job or request record in your field-service software
- A shared scheduling board or calendar
- Email or chat to dispatch as a fallback, in the same format
Closing the loop
- Dispatch confirms or adjusts the time and tells the customer.
- Duplicates are merged, not double-booked.
- Requests missing required fields are returned to intake, not guessed.
Where this handoff breaks
| Failure | Prevention |
|---|---|
| Duplicate jobs for repeat callers | Search by phone and address first; link, don't duplicate. |
| Requests without availability | Capture availability on every call. |
| Priority unclear | Tag with the rule that applied. |
| Customer told a time dispatch never agreed | Record exactly what was said. |
| Requests drift from what callers said | Each week, spot-check a few requests against call recordings or notes. |
How the HVAC Reception concept would use it
Proposed · not available
The proposed HVAC Reception design would produce a job request in this format for every service call, tagged with the rule that set its priority. It has no connection to any field-service software today; how a real product would connect is an open question covered in our compatibility guide.
Frequently asked questions
What should an HVAC job request include?
Job type, priority and why, confirmed customer contact and address, access notes, the problem in the caller's words, equipment as described, plan status, customer availability, what the customer was told, and any link to an existing job.
Should intake book directly on the board or send requests?
Both work. Direct booking is faster but needs rules for which slots intake may use; requests keep dispatch in control. Many offices allow direct booking for maintenance and send requests for repairs.
How do we handle repeat callers?
Search by phone number and address before creating a new job. If a job exists, update it and tell dispatch the customer called again — that is often a sign the job is at risk.
Would HVAC Reception put jobs on my ServiceTitan or Housecall Pro board?
No. HVAC Reception is a concept with no integrations. Read our field-service software compatibility guide for the questions to ask any vendor that claims to do this.