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.

  • Keiko, we've been down this road. The "realistic" approach won for us, but with a twist — we stopped calling it padding and started calling it "mobility time." Technicians accept it when they understand it's job transition and documentation, not slush.

    Here's what actually works:

    • Commercial jobs: 25% buffer minimum, often 40% for first-time sites
    • Residential service: 15% buffer, but we also hard-cap at 4 hours and split anything larger
    • Daily float slot: One 90-minute emergency slot per crew that dispatch can use proactively

    The key is dispatcher authority to trigger the float slot without management approval. If your dispatchers are waiting on ops managers to authorize schedule changes, you're already behind.

    Pro tip: We also trained our CSRs to book slightly longer windows than the estimate suggests — "between 2–4 hours depending on what we find." Sets expectation without promising precision we can't deliver.

  • In my experience the estimate is usually wrong because someone rushed it. Electricians looking at a blueprint for five minutes and declaring "four hours" when they've never seen the actual panel location or the access constraints.

    We moved to requiring site photos before any estimate goes out. Slowed our quoting by a day but cut overruns by half. The buffer discussion becomes secondary when your starting point isn't fantasy.

    That said, I don't trust dispatchers to manage buffers in real time. They're juggling too much. Better to pad upfront and let the tech finish early occasionally than pretend someone watching a screen can predict field reality.

  • Art — totally hear you on the site photos, but how do you handle emergency calls where there isn't time for that? Do you just quote a wider range upfront?

    We struggle with this because customers want a number immediately but our field assessment often reveals complications. Thanks so much for any insight!

  • Wide range plus authorization threshold. "Somewhere between $400 and $800, we'll stop and call you if we hit $600." Gives you the out without the overrun drama.

  • We're structured differently — dispatch doesn't control buffers, the tech does. Each job card shows:

    • Estimated time
    • Tech's real-time % complete (they update at 25/50/75)
    • Auto-calculated downstream impact

    If a tech hits 50% at the estimate's halfway mark, they're green. If they're at 50% and 90 minutes in, the system flags it and dispatch gets an alert. No waiting for "complete."

    The communication piece: We auto-text customers when their job slips more than 30 minutes. Template is honest but not apologetic — "Your technician is completing a complex diagnosis; new arrival window is 2:30–3:00 PM."

    Our reschedule rate actually dropped after we started doing this. Customers prefer transparency over precision.

  • Another way to think about this: The question isn't buffer vs. realism, it's where in your system you want to absorb variance.

    Front-loading realistic estimates pushes customer conversation earlier (harder to win the job). Back-loading through float slots keeps sales clean but requires operational flexibility you may not have. Your 75–100% overruns suggest the variance is landing on your dispatch and technician teams, which is the most expensive place to absorb it.

    We've had success with a hybrid — standard jobs use realistic estimates, complex jobs use optimistic estimates plus mandatory post-job review. The review isn't punitive; it's data collection. After enough reviews, you know which job types need the buffer.

  • Tried the "mobility time" framing. Techs saw through it in a week. They're not stupid.

    What actually worked: Paying them for the full scheduled window whether the job takes it or not, plus bonus for finishing early without callback. Aligns incentives. Dispatch gets more predictable, customers get techs who aren't rushing to beat an unrealistic clock.

    Costs more. Worth it.

  • 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.