Contractor AI HubField guidesGuides
Field guides

Callback Note Minimum Fields Before AI Dispatch

Contractor AI Hub · 2026-10-18

An after-hours HVAC callback arrives as a short voice mail, a text thread, or a half-finished intake form. The temptation is to let an AI dispatcher invent a clean job ticket from that fragment and send the next available tech. That is how wrong addresses, wrong unit types, and missing access details become expensive night calls. The safer pattern is a minimum field set: collect or explicitly mark UNKNOWN for every required intake field, refuse to dispatch until a named owner fills the gaps that matter, and only then ask a model to summarize what is already present.

This guide is office-process education for contractor intake and AI-assisted dispatch notes. It is not legal advice, not a warranty policy, and not a claim that any particular AI product is safe for unsupervised dispatch. The worked example below uses a stated fictional callback so you can see which fields block dispatch and which can wait until morning.

Why a minimum field set beats a free-form summary

Free-form notes feel complete when they are long. Dispatch needs completeness of a different kind: enough structured facts to choose a tech, a truck stock list, and a safe arrival plan. A model that is asked to "create a dispatch ticket" will often fill empty slots with plausible guesses. Your office then inherits invented unit ages, invented access codes, and invented symptoms that never appeared in the customer message.

A minimum field set reverses the default. Every required field must either contain a value taken from the customer or tech notes, or contain the literal token UNKNOWN. Summarization is allowed only after that contract is satisfied. Anything still marked UNKNOWN that is on the dispatch-blocking list stays visible on the ticket and owns a named person who must resolve it before the tech leaves the shop or home base.

This pairs with the earlier field-routing work on this site: some fields are summarizeable, some must be withheld, and some escalate to a human owner. Here the focus is the intake gate before any AI dispatch step runs. See the guides index for related office AI topics, and keep personal identifiers out of model prompts using the same redaction discipline as your other HVAC note handoffs.

The minimum intake fields for an after-hours callback

Use one stable checklist. Rename fields to match your CRM, but do not silently drop a category. For each field, record the source (customer text, prior job history, tech call-back) and the confidence (stated, inferred from prior job, unknown).

Dispatch-blocking fields (must be filled or escalated before the tech is sent):

  • Service address and unit location — street address plus enough detail to find the equipment (basement furnace, rooftop RTU, apt number, gate). A city alone is not enough.
  • Customer contact for arrival — a reachable phone or named on-site contact for the expected arrival window. After-hours calls need a live contact path, not only an email.
  • Reported symptom class — a short controlled vocabulary (no heat, no cool, water leak, burning smell, breaker trip, other). Free text may accompany it, but the class drives stock and safety routing.
  • Safety / shutoff status — whether power or gas was already shut off by the customer, whether a breaker is open, and whether anyone reports a gas odor or CO alarm. If unknown, mark UNKNOWN and escalate; do not invent "customer said it is safe."
  • Access method — lockbox, gate code, manager meet, or "customer will unlock." Codes themselves should stay out of AI prompts; store them in the secured CRM field and mark the AI-visible note as ACCESS_ON_FILE or UNKNOWN.

Non-blocking but required-before-close fields (can remain UNKNOWN overnight if dispatch already has the blockers):

  • Equipment brand / model / serial (often available only on site)
  • Prior job ID or warranty flag
  • Preferred morning follow-up contact
  • Billing party if different from caller

In this example the AI may summarize the SMS into a clean symptom line and list the two blocking UNKNOWN fields. It must not invent "basement gas furnace" or "customer already flipped the breaker." The night lead owns both blockers: one quick call to ask unit location and whether gas/power was shut off. Until those return, the ticket stays in intake, not in dispatched.

The UNKNOWN rule and named owners

Marking UNKNOWN is not a failure. Leaving a blank field is the failure, because blanks look like oversights and invite hallucinated fills. Train intake staff and any AI prompt to output the token explicitly. Pair every dispatch-blocking UNKNOWN with a named owner and a next action time, even if that time is "call customer now."

Owner examples that stay realistic for a small HVAC office:

  • Night lead — owns blockers that need a customer call within the hour.
  • On-call tech — owns blockers that only a tech can judge from a photo or prior visit note (for example, whether a known rooftop unit is the one in scope).
  • Morning CSR — owns non-blocking unknowns that can wait until business hours.

When the model summarizes, require an output section titled OPEN_UNKNOWNS that lists each unknown field, its owner, and whether it blocks dispatch. If that section is empty but a required field was blank in the source notes, the summary fails verification and must be regenerated after the blanks are fixed.

Personal information handling still applies. Collecting minimum fields does not mean pasting full payment card numbers, government IDs, or unlock codes into a chat model. The FTC's protecting personal information guide frames taking stock of what you collect and keeping only what you need. The related start with security guidance likewise emphasizes limiting access to sensitive data. Keep AI-visible notes to operational fields; keep secrets in systems with access control.

A reusable intake-before-dispatch prompt contract

You can reuse a short prompt once the CRM or paste buffer already holds the raw callback text with secrets removed. The contract below is a process template, not a guarantee about any vendor model.

Required model outputs:

  1. A field table with exactly the minimum field names your office uses.
  2. Each cell either a verbatim or lightly normalized value from the source, or UNKNOWN.
  3. A DISPATCH_GATE line: READY or BLOCKED, with the blocking field names if blocked.
  4. An OPEN_UNKNOWNS list with owner slots left blank for a human to fill (the model must not invent owner names that are not in your roster).
  5. A one-paragraph customer-facing status only if DISPATCH_GATE is READY; otherwise a one-line internal note that intake is incomplete.

Verification checklist before anyone hits send on dispatch software:

  • Every dispatch-blocking field is either valued or owned.
  • No access codes, card numbers, or full SSNs appear in the AI transcript.
  • Symptom class matches a controlled list; "other" has a short free-text note.
  • A human initials the DISPATCH_GATE line.

Assumptions and limits

The example address, symptom, and field values are hypothetical. Real offices differ in CRM fields, union rules, manufacturer warranty intake, and state licensing constraints. This article does not define emergency response criteria for gas leaks or CO alarms beyond "escalate and do not invent safety status." It does not claim that AI dispatch is appropriate for every contractor, and it does not replace your written after-hours SOP.

If your team already uses a richer triage tree (priority scores, SLA clocks, multi-unit campuses), keep those systems authoritative. Use this minimum field set as the AI-visible subset that must be honest before any model writes a ticket summary.

Sources and method

AI-assisted writing with automated source, calculation and editorial checks. No hands-on testing or professional certification is claimed. Check the stated assumptions before applying this guide.