Technician dispatch and assistance tracking for a home services network

The problem

In home assistance the problem is rarely the first call but everything that follows it. A job comes in, it is assigned to a technician, and from that point the customer stops receiving information: they do not know whether the technician is coming, in what window, or whether the part that was needed has arrived. Each of those uncertainties generates a fresh call, so a poorly tracked job produces several avoidable contacts. Demand also depends on weather and season, with episodes concentrating into a few days a volume that resembles no average, and coverage in the co-official languages is a reasonable customer expectation across much of the country.

What we did

• Treat job tracking as the service rather than as a task that follows technician assignment
• Inform proactively at the points where the customer would call anyway, which are window confirmation and part arrival
• Size against seasonal and weather scenarios with an activatable surge band, rather than against an annual average
• Answer in the co-official language of the territory wherever the service has that as a reasonable expectation
• Close the job against the customer's confirmation rather than the technician's report, because those are two different facts

What would be measured

The indicators the service would be run against, with their definitions. No values are attached: a numeric target set before anyone has seen the client's data is a promise, and the definition is the part that is true before the work starts.

• Contacts per job, read as a measure of tracking quality rather than of productivity
• Share of jobs with a confirmed window before the customer asks for one
• Share of jobs closed with customer confirmation
• Time from job intake to effective technician assignment
• Time to activate the surge band during a seasonal or weather episode