The mid-job check-in: re-plan the day at halftime, not at the end of the job

Every dispatcher knows the call. It's 11:20, the tech says the 9:00 job is going to take another hour, and the 11:00 customer has been waiting twenty minutes. Now you're choosing between bad options with no time to think.

That job didn't start running long at 11:20. It started running long at about 9:50, when the tech pulled the panel and found the problem was bigger than the work order said. The tech knew then. Nobody asked.

This guide is about asking at the right moment, and about the arithmetic of what to do with the answer.

Why halfway is the right moment

There are three times you could find out a job is running over:

• At the start. Too early. The tech hasn't diagnosed anything yet.
• At the end. Too late. The next job is already affected, and you have minutes to fix it.
• Halfway through. The tech has diagnosed the problem and has a fair idea how much is left, and there is still time before the next job to move things.

Halfway works because most of the uncertainty in a job is resolved early. Once the tech knows what's wrong and has the parts in hand, the rest is mostly labor they can estimate. A tech asked "are you on track?" at the midpoint can usually answer within 15 minutes.

The other reason is lead time. If the planned job is 90 minutes and you ask at 45, you have about 45 minutes plus the drive to act before the next customer's start. That's enough to call someone, offer a new time, or hand the job to another tech. At the end of the job you have none of that.

The re-flow arithmetic

When a job extends by X minutes, everything after it on that tech's day moves by up to X, less whatever slack sits between jobs.

New start of job k = Planned start of job k + max(0, X − S_k)

S_k is the total slack between the extended job and job k: every gap where the tech would have arrived before the planned start. Gaps absorb the overrun first. When the slack is used up, the push carries forward.

In this example only jobs 2 and 3 are affected. Job 4 is safe because enough slack sat in front of it. The point of the arithmetic is that you only need to act on the jobs that actually move past their window. Arrival window math explains why later jobs carry more of this risk to begin with.

What to do with a pushed job

For each job that the extension pushes outside its arrival window, you have three choices, in this order of preference:

1. Hand it to a teammate who can make the same time. The customer sees no change. This works when another qualified tech has a gap at that hour and can reach the address from where they'll be.
2. Move it to the nearest open time. Today if possible, otherwise the earliest slot that fits. The customer gets a new time, early.
3. Keep it and tell the customer. Sometimes the push is small and the customer is fine with a later arrival. Tell them now, not at the end of their window.

The order matters. A handoff costs the customer nothing. A move costs them a change of plans. A late arrival with no notice costs you the customer. The scripts for what to say are in running late: what to tell the customer.

Make the check-in a habit, not a phone call

The reason most companies don't do this is that it means the dispatcher calls every tech halfway through every job. With eight trucks and four jobs each, that's 32 calls a day. It doesn't happen.

So make the question small and the answer smaller. The check-in should be one prompt, with four possible answers:

• On track
• Need +15 minutes
• Need +30 minutes
• Need +60 minutes

That takes the tech three seconds. Anything bigger than +60 is a different conversation: a return visit, a quote, a second day.

In CrewLink, this is built into the tech phone app. About halfway through a job the app asks if the tech is on track or needs +15, +30 or +60 minutes. An extension re-flows the rest of that tech's day right away: later jobs that no longer fit are handed to a teammate who can make the same time, or moved to the nearest open time, and the affected customers are texted. The office sees the result on the dispatch board.

Without software, you can approximate it with a rule: techs text the office a single number (0, 15, 30 or 60) at the midpoint of any job planned for an hour or more. The dispatcher re-flows by hand.

Fix the estimate, not just the day

A check-in rescues today. It doesn't stop the same overrun tomorrow. If the same service keeps needing +30, the planned duration is wrong.

Track two numbers per service type:

• Extension rate: the share of jobs where the tech asked for more time.
• Average extension: how much they asked for when they did.

If a service's extension rate is above about one in three, raise its planned duration. If a specific tech extends far more than their teammates on the same service, that's a training or diagnosis conversation, not a scheduling one. Your job duration estimate should come from what jobs actually took, and the recorded time on site is the raw material.

Common questions

What should a technician do when a job is running long?

Say so as soon as they know, which is usually after diagnosis, around the middle of the job. Give a size: 15, 30 or 60 more minutes. The office can then move or hand off later jobs while there is still time.

How do you handle job overruns without wrecking the schedule?

Absorb what you can with slack between jobs, then act only on the jobs pushed outside their window. Hand those to another tech who can make the same time, or move them to the nearest open time, and tell the customers early.

Should I build buffer into every job instead?

Some buffer time, yes, especially before afternoon jobs. But buffer on every job costs booked hours every day, even when nothing runs over. A mid-job check-in lets you run tighter and react only when an overrun actually happens.

What if the job needs more than an hour extra?

Treat it as a different job. Finish what can be finished, book a return visit or a second day, and move the rest of the tech's day as a whole.