Remote Triage: Send a Tech Now or Schedule Later (Decision Tree)

Why this matters

Every inbound call, text, or photo makes you decide, often in under a minute, whether this is a dispatch-now situation or something that can wait for the next open slot. Send urgent dispatch to everything and you burn emergency capacity on non-emergencies while a real one waits; treat everything as routine and you leave a genuine emergency on the schedule for two days. This tree is the triage call itself: what information decides "now," what decides "later," and what to do when you genuinely cannot tell yet.

Start here: screen for hazard first, every time

Before you weigh convenience or scheduling load, screen for danger. This overrides every other factor below.

• If the caller reports gas smell, smoke, sparking, active flooding near electrical, no heat in freezing conditions with vulnerable occupants, or anything actively worsening while you're on the phone, this is an emergency dispatch or an immediate safety instruction (evacuate, shut off, call emergency services as the hazard requires), not a scheduling decision. See related: Smell of Gas or Burning: Response Decision Tree.
• If there is no hazard signal, continue the triage below.

Step 1: is the system's core function completely out, or degraded

• If the core function is completely down and there is a real dependency on it right now (no heat in genuinely cold conditions, no water at all, no power to essential circuits, a safety device that will not reset), lean toward same-day or next-available dispatch.
• If the system still functions, just imperfectly (running but less efficient, an intermittent noise, a minor drip, a cosmetic issue), lean toward scheduled, non-emergency booking.

Step 2: is the situation actively getting worse, or stable

• If the customer describes something worsening in real time (a leak that is spreading, a smell getting stronger, a noise getting louder), treat the trend as more urgent than the current severity. A moderate problem trending worse outranks a worse problem that has been stable for a week.
• If the situation has been present and unchanged for some time, even if the base severity is high, you have more room to schedule properly rather than react.

Step 3: does anyone in the home have a specific vulnerability

• If the household includes very young children, elderly residents, someone medically dependent on climate control or power, or anyone with a condition the outage genuinely threatens, weight the dispatch decision up a level from what the technical severity alone would suggest.
• If there is no stated vulnerability, judge purely on the technical severity and trend from steps 1 and 2.

Step 4: what does remote information actually let you conclude

• If a video or photo (see the related articles on reading customer photos and video) clearly confirms a straightforward fix the customer can do themselves (a reset, a switch, a filter), you may resolve this with no dispatch at all. Confirm it worked before closing the ticket.
• If the remote information narrows the cause but cannot resolve it, use that narrowing to route the RIGHT tech and part to a scheduled slot rather than changing the urgency itself.
• If the remote information is inconclusive or contradicts itself, do not let ambiguity default to "wait." Ambiguous plus any hazard-adjacent signal defaults to sooner, not later. Ambiguous plus a clearly low-stakes complaint defaults to normal scheduling.

Weighing it together

No single row decides it alone. A degraded-but-functioning system with a worsening trend and a vulnerable occupant can outrank a fully-out system that has been stable for a week in a home with no vulnerability. Weigh the whole table.

The recap

1. Screen for hazard first; a real hazard is never a "later" decision.
2. Judge core function: out versus degraded.
3. Judge trend: worsening versus stable.
4. Weight for vulnerable occupants.
5. Use remote information to resolve or narrow, not to justify defaulting to "wait" under ambiguity.

References

• Trade-standard practice for emergency dispatch triage
• See related: Reading the Customer's Photos Before Arrival; What a Customer's Phone Video Can (and Can't) Tell You; The Emergency Call Triage Decision Tree