A Tech Calls In Sick Mid-Morning: Decision Tree

Why this matters

A mid-morning sick call is the single most common way a well-planned day falls apart, because unlike an overnight callout, it lands after the board is already live and customers are already expecting someone. The instinct is to panic-shuffle everything at once. The better move is a short, ordered read: how many jobs are actually affected, which ones can move, and who is honestly available to absorb them, before touching a single slot.

Start here: get the real picture from the tech first

Before you touch the board, get two things from the tech in the same call: how they are actually doing, and what is still sitting on their plate for today. A tech who is genuinely too sick to work needs to hear that first, not be grilled about their jobs before you have asked how they are. Once that is settled, ask plainly what is left on their route and whether anything already in progress needs a handoff mid-job versus a job that has not started yet. This distinction changes everything downstream.

Step 1: List every affected job and sort by urgency

Pull every remaining job on the sick tech's route for the day and sort into three buckets:

• Time-sensitive or already-committed, meaning the customer is expecting someone at a specific window today and rescheduling has a real cost (a no-cool call in genuine heat, a commercial account with an SLA, a customer who already rearranged their day once).
• Flexible but was scheduled today for a reason, meaning it can slide a day or two without real harm.
• Genuinely low-priority filler that was only on today's board because there was room, and moving it costs nothing.

This sort takes two minutes and determines everything else. Do not start reassigning jobs before you know which ones actually need to happen today.

Step 2: Check real capacity before reassigning anything

Look at the rest of the board for genuine open capacity, not just techs who are technically not booked back to back. A tech with a fifteen-minute gap between two other jobs cannot absorb a forty-five-minute job plus drive time without cascading a delay onto their own afternoon. Be honest about this before you commit a job to someone who does not actually have room for it.

• If there is real slack somewhere on the board (see related: Building Slack Into a Fully Booked Week), reassign the time-sensitive jobs there first.
• If there is no real slack, you are choosing between delaying a job, calling in help, or asking an available tech to extend their day. Name which one you are doing on purpose rather than defaulting to whichever tech complains least.

Step 3: Handle a job that was already in progress

If the sick tech had started a job and had to leave mid-visit, this is not the same as a job that never started. Get from the tech, before they sign off, what state the job was left in: what has been done, what is left, whether anything is disassembled or unsafe to leave as-is. A second tech picking up a half-finished job with no handoff information wastes time re-diagnosing and risks missing what was already found. See related: The Job That Needs a Second Tech Mid-Visit: Decision Tree for the handoff mechanics.

Step 4: Call the affected customers yourself, before they call you

For every job you are moving, proactively call the customer rather than waiting for them to notice a tech has not shown up. Say plainly that a technician called in and you are adjusting the schedule, give them a real new time if you have one, and thank them for the flexibility. A customer told about a delay before it happens is inconvenienced. A customer who finds out by watching the clock and calling you angry is lost trust on top of the inconvenience.

Step 5: If no reshuffling covers everything, decide who makes the call on what slips

Some days there is genuinely not enough capacity to cover every job even after reassigning. When that is true:

• Protect the time-sensitive bucket first, always, even if it means the flexible and filler jobs slide entirely.
• Escalate to a manager or owner if the gap is large enough that a customer relationship is genuinely at risk, rather than quietly absorbing the loss yourself. This is a capacity problem worth someone above dispatch knowing about, not just a dispatcher's private headache.
• Document what slipped and why, so a pattern of understaffing shows up in the record instead of disappearing into "just a rough day" every time it happens.

The recap

1. Check on the tech first, get the job list second.
2. Sort remaining jobs by real urgency before reassigning anything.
3. Verify actual capacity before committing a job to another tech.
4. Get a real handoff on any job left mid-visit.
5. Call affected customers proactively, before they call you.
6. If capacity genuinely falls short, protect urgent jobs first and escalate the shortfall.

References

• See related: Building Slack Into a Fully Booked Week
• See related: The Job That Needs a Second Tech Mid-Visit: Decision Tree
• Trade-standard practice for field-service staffing contingencies