What's your approach to handling jobs that take twice as long as estimated?

We're seeing a pattern in our electrical division where complex commercial jobs are running 75–100% over initial time estimates. The immediate impact is cascading delays through the afternoon schedule, frustrated customers, and technician overtime that wasn't budgeted.

From an operational standpoint, I'm less concerned with the occasional overrun and more interested in how teams structurally account for this reality. A few specific questions:

  • Do you build buffer time into every estimate, or only certain job types?
  • How do you communicate delays to downstream customers without damaging trust?
  • What visibility do your dispatchers have into job progress before the technician marks complete?

We're currently evaluating whether to move toward "optimistic" scheduling with explicit buffers, or "realistic" scheduling that bakes contingency into every job. I'd welcome perspective from teams that have made this choice deliberately.

Parents
  • lol mike basically admitting he's bribing his techs to do the job right

    so what i did was basically i started texting my next customer directly when i knew i was running long like not waiting for dispatch to do it just "hey it's connor running about 40 behind on my current job will keep you posted" and customers actually loved it??? like they would text back "no rush take your time" and then i didn't feel rushed and the job went better

    but then my manager saw i was doing that and said it had to go through the office so now we're back to the customer not knowing anything until dispatch gets around to it which is basically never when they're busy

    anyway my point is the communication piece matters more than the buffer probably

  • Connor's manager is why we can't have nice things...

    But he's right. The buffer debate is mostly theater. Customer who's informed and feels heard will tolerate a two-hour slip. Customer who's in the dark will burn your review over twenty minutes.

Reply Children
No Data