Sending a technician: scheduling is a promise about time

A ticket records a fault. A schedule is a promise somebody made to a customer about a morning, and the promise is the part that gets broken. Most systems keep the ticket and treat the promise as a field inside it, which is why nobody can say afterwards who committed to what, or when it stopped being true.

Is the promise a window or an hour?

A window, and a wide enough one to survive a day. "Between eight and twelve" is a commitment a technician can keep through traffic and a job that runs long. "At nine" is a guess dressed as a commitment, and the one time in three it slips costs more trust than a kept window ever earned.

Width is the test: a window longer than half a day is not a promise, it is a date. And the window has to sit where the customer can read it — the same words the dispatcher saw, in the confirmation that was sent. A promise made on the phone and written nowhere is a promise only one side remembers, which is how a dispute about lateness starts with two honest people.

Why does the technician arrive without the part?

Because the part is a stock question, and scheduling systems rarely touch stock. Two failures produce the empty-handed visit: the fault was diagnosed on the phone from a description and the diagnosis was wrong, or the right part was identified and never reserved to the job, so it left the store on another call at ten o'clock.

The fix is not a better schedule. The ticket carries the likely part before dispatch, the stock is held against that job, and a visit that ends without the part is recorded as an outcome with a reason — which creates the second visit deliberately, with a date, instead of leaving the customer to call back and ask.

How much of the day is actually travel?

More than the plan assumes, and it is work. Six calls across a city are not six hours of repair: they are four hours of repair and two of driving, and a planner who blocks only repair time builds an afternoon that cannot happen.

So travel is blocked between stops, at the honest time from the map plus a margin for the barrier, the lift and the parking. The gap between planned and actual travel is the first number worth reading each week, because it is where a schedule starts lying.

What happens when the first job runs long?

The day is replanned, and every replanning breaks a promise somebody already made. There are only two honest ways to absorb it: shorten the unscheduled tail, meaning the last calls of the day that no customer is waiting on yet, or move a window before it is missed rather than after.

The order matters more than the software. Windows already promised stay where they are, and the overrun is pushed into the part of the day that is still open. When it cannot be absorbed, the dispatcher calls the affected customer while the technician is still en route — a call that costs two minutes and keeps the promise, where an arrival an hour late ends it.

A system that lets the schedule be dragged around by whoever is loudest will produce a day that looks optimised on the screen and generates three complaints by the evening.

What must a visit leave behind?

Proof, of three kinds: the customer's signature, a photograph of the work, and a reading from the machine — hours, a meter, a temperature, a serial number. The reading is the strongest, because it is the only one that could not have been produced from an office.

The proof matters because the visit is the unit the customer is paying for. A closed ticket with no proof is an invoice with a story attached; a ticket with a photo and no reading answers whether somebody came, not whether anything changed.

What does the callback rate tell you that a completion count does not?

Whether the repair held. A completion count measures activity; a callback — the same machine, the same fault, inside a short window after closure — measures quality, and it is the one number in the trade that cannot be improved by working faster.

It is also the number most often missing, because a callback is usually logged as a new ticket for the same address, and two tickets hide one failure. Closing a ticket has to require an answer to a single question — was this the same fault as the last visit — or the rate is never computed at all.

Read it per technician and per machine type, with the parts list beside it, because the causes differ. A man who returns twice to one fault needs a better diagnosis. A machine that returns twice needs a different part, or a conversation about replacing it.

Object	What it holds	What it must not do
Ticket	the fault, its history, the parts used	own the promise
Visit	a day, a window, a named technician	promise an exact hour
Part	a quantity held against one job	appear at the door

In what order do you build this?

1. Count last month's visits and the ones that needed a second trip, with a reason for each.
2. Replace appointment times with windows, and print the window on the customer's confirmation.
3. Give the ticket a likely part before dispatch, and hold it.
4. Block travel between stops, using the map's time plus a margin.
5. Require proof at closure: signature, photograph, reading.
6. Count callbacks per technician and per machine, and read them monthly.

Where this goes wrong

• The exact hour is offered to win the call, then broken by the third stop of the day.
• The window is a placeholder in the software and a different promise on the phone.
• The part is checked at the door, which turns a repair into an inspection and a second visit.
• Travel is invisible, so the plan is built for a city with no traffic and no lifts.
• Proof is a signature only, collected at the end of a long day by the man being measured.
• Callbacks are logged as new tickets, so the rate looks healthy while the same machine fails every quarter.

What this does not cover

It does not design a route optimiser and it promises no number of calls per day; both depend on the city, the trade and the equipment. It assumes several technicians and somebody dispatching: one man with a phone needs a list, not a schedule. And it says nothing about warranty terms or who pays for the second visit, which is a contract question rather than a systems one.

We build the schedule as a promise kept in the record — a window the customer can read, parts held to the job, travel counted as work, and proof at the door.