The Connected Device Service Call Triage SOP

Purpose

This SOP decides, before a truck rolls, whether a "my smart thing stopped working" call is a device fault, a network fault, an account fault or a change somebody made. Run in order, it settles most of these calls in ten to fifteen minutes on the phone, and it sends a tech only when the device itself is the suspect. Without it, the shop dispatches on every connected-device complaint, the tech arrives to find a router that was replaced on Saturday, and the customer gets a trip charge for a problem that was never in your equipment. That visit costs a slot, and it starts an argument about whose fault the bill is.

Scope

Covers: inbound calls and messages about equipment your shop installed or services that has a network or app connection: thermostats, leak sensors and automatic water shutoffs, connected water heaters and appliances, smart locks, video doorbells, cameras, energy monitors, garage door openers with an app, pool and irrigation controllers.

Does not cover:

  • Commissioning a new device. See related: The Connected Device Commissioning SOP.
  • Any change to the customer's router or network settings. Triage may identify that a change is needed; making it runs under the customer network change authorization SOP.
  • Walking the customer through a reset. Triage decides a reset is the next move; the scripted call runs under the reset how-to.
  • A call where the equipment's primary function has failed with a hazard present (no heat in freezing weather, water on the floor, a burning smell). That is an emergency dispatch, and Step 1 routes it out before any network question is asked.

Roles and responsibilities

Role Owns Hands off when
Office (call taker) Steps 1 to 6, the triage record A step's stop rule says dispatch, or Step 6 points at the device
On-call or lead tech Reviewing a "device suspect" triage before dispatch, choosing parts The triage record is incomplete or contradicts itself
Dispatched tech Confirming the triage on arrival, recording what was actually found The site does not match the triage record
Owner or service manager Monthly review of triage outcomes against what techs found Triage and site findings disagree on more than one call in five

The handoff that matters is office to tech. The tech reads the triage record before leaving the shop, not in the driveway, so a missing answer gets chased by phone while there is still time to cancel the visit.

Procedure

Step 1: Screen for a hazard before anything else

Ask, in this order: is there water where it should not be, any smell of gas or burning, any sparking, heat or warping at the device, and is anyone without heat or cooling in dangerous weather. Acceptance: all five answered no, recorded in the triage record. Wrong looks like: any yes. Stop triage. For a gas or burning smell, tell the customer to leave the house now without touching switches, lights or the device, and to call the gas utility or 911 from outside; then dispatch as an emergency. For water near electrical equipment, tell them not to walk through standing water to reach a panel or the device, and to close the main water valve only if they can reach it from a dry floor. Network questions wait until the hazard is gone.

Step 2: Confirm which device, and that it is ours

Get the device type, its location in the house, the install date from your job record, and the app name the customer is looking at. Acceptance: the device matches a line in the customer's equipment record, or the customer confirms another company installed it. Wrong looks like: the customer describes a device you have no record of, or two devices share a name in the app ("Thermostat" upstairs and downstairs). Do not proceed on a guess; ask them to read the device name and the model line off the app's device page. If it is not your install, say so, record it, and quote it as a new diagnostic call rather than a warranty or service-agreement visit.

Step 3: Read the app status, not the customer's summary

Ask what the app shows for that device: online, offline, last seen time, any error banner, and the battery level if it is battery powered. Acceptance: you have the literal status and a last-seen time in hours. Wrong looks like: "it just doesn't work." Ask them to open the device page and read it word for word. Offline with a last-seen time tells you when it dropped, which Step 5 needs. Online and showing an error points away from the network and toward the device or its sensor. Online with no error and the customer still unhappy usually means an automation or schedule changed, which is Step 5 territory too. The app is the customer's own; never ask for their login to look yourself.

Step 4: Check power and the local controls

Ask whether the device's own display, light or indicator is on, and whether the local control still works (the thermostat buttons, the lock keypad, the valve's manual override). Acceptance: the device shows power and responds locally, or you have a specific power fault (no display, breaker off, dead batteries). Wrong looks like: no display on a hardwired device. Ask whether a breaker is tripped, but the customer does not reset a breaker that trips again immediately, does not open a panel cover, and does not touch a device with a scorched or melted look; any of those is a dispatch. A battery device showing low or dead batteries gets a battery change on the phone and a re-check of Step 3 before going further.

Step 5: Ask what changed, and when

This is the step that settles the most calls. Ask about the last two weeks: a new router or internet provider, a technician from the internet company, a power outage, a changed Wi-Fi password, a new phone, a family member who set up a new app, an app update prompt. Line each answer up against the last-seen time from Step 3. Acceptance: either a dated change that lines up with the drop to within a day, or a recorded "no changes known." Wrong looks like: a change that lines up, which means stop triage and route: a new router or password goes to a network reconnect under the reset how-to or the network change SOP; a new phone or app account goes to account recovery. See related: It Worked Until Last Tuesday and Nobody Touched It.

Step 6: Test whether the network reaches the device

Ask whether other devices near the same spot are online (a phone on Wi-Fi standing beside the device, a speaker, a TV in the same room) and whether other connected devices in the house dropped at the same time. Acceptance: a phone held beside the device shows a working Wi-Fi connection and loads a page, and you know whether the drop was this device alone or several. Wrong looks like: the phone shows weak or no Wi-Fi at the device, or every connected device dropped together. Several dropping together is the network or the internet service, not your equipment; route it per the network SOP and do not dispatch. Weak signal at the device only is a coverage problem worth a quote, not a repair. See related: Measuring Wi-Fi Signal Where the Equipment Lives.

Step 7: Try one remote recovery, then decide

If Steps 1 to 6 pass and nothing changed, try a single power cycle of the device only, where the customer can do it from a switch, a plug or the battery without opening equipment. Never have a customer power cycle the router as part of this step; that disturbs every other device in the house and belongs to the network process. Give it 10 minutes and re-read Step 3. Acceptance: the device returns online and its function works. Wrong looks like: still offline, or back online for under an hour. That is the stop rule for triage: mark the device suspect and dispatch. Do not try a second, different reset on the phone in the same call; two untested changes make the tech's diagnosis harder.

Step 8: Close the call with a stated outcome

Tell the customer which of four outcomes this is: resolved on the phone, network or account issue outside our equipment, coverage problem we can quote, or device suspect with a visit booked. Acceptance: the outcome is read back and the customer agrees to it, including whether the visit is billable. Wrong looks like: the customer believes a visit is free when your terms make it billable. Say the terms now, before booking, and record their answer.

The record this produces

One triage entry on the customer record, filled by the call taker before hanging up:

  • Hazard screen: five answers.
  • Device: type, location, install job number, app device name.
  • App status: literal text, last-seen time, battery level.
  • Power and local control: result.
  • Changes in the last two weeks: each with its date, or "none known."
  • Network check: phone signal at the device, single or multiple drop.
  • Remote recovery: what was tried, time, result.
  • Outcome: one of the four, and the billing terms stated.

The dispatched tech reads it before leaving. The service manager reads a month of them against what techs found, because a triage that says "device suspect" on calls where techs keep finding a router problem means Step 5 or Step 6 is being skipped.

Worked pass

A customer calls at 9:40 on a Monday: their automatic water shutoff's app says "Offline."

TRIAGE - water shutoff, Delgado residence
Step 1  hazard     water: no  gas/burn: no  spark: no
                   heat/cool: n/a  -> PASS
Step 2  device     shutoff valve + 3 sensors, basement,
                   job 4471, app name "Main Water" -> PASS
Step 3  app        "Offline", last seen Sat 18:12
                   sensors: online, battery 80 pct -> logged
Step 4  power      valve status light ON, manual lever
                   moves -> PASS
Step 5  changes    "internet company swapped the modem
                   Saturday afternoon" -> MATCH, STOP
Step 6  network    not run (Step 5 stop)
Outcome network change, not our equipment; reconnect
        call booked 30 min, billable per terms, agreed

Reading the pass. Step 3 recorded a last-seen time of Saturday 18:12, about 39 hours before the call. Step 5 found the internet provider replaced the modem Saturday afternoon, within hours of that time, which meets the stop rule's "within a day." The valve has power and its manual lever works (Step 4), so the device is healthy. The sensors staying online looks contradictory until you note that in this install they talk to the valve over their own radio, not over Wi-Fi; only the valve uses the home network, so only the valve dropped. A call taker who skipped Step 5 would have run Step 7, the valve would have come back up offline, and the stop rule would have dispatched a tech to replace a working valve controller.

What would have changed the outcome. If the last-seen time had been the previous Wednesday, four days before the modem swap, the timing would not line up and Step 5's match fails. Triage continues to Step 6, and a Wednesday drop with nothing changing points toward the device. Same customer, same complaint, opposite answer, and the only difference is a timestamp the call taker had to ask for.

Re-reading the procedure against the pass. Step 6 did not run, and that is correct: a stop at Step 5 ends triage. The record shows "not run" rather than blank, so the tech and the service manager can tell a skipped step from a forgotten one.

References

  • See related: The Connected Device Commissioning SOP
  • See related: Walking a Customer Through a Reset Over the Phone
  • See related: The Customer Network Change Authorization SOP
  • See related: Home Wi-Fi for the Trades
  • Trade-standard practice for remote triage and dispatch