• Replies 9 replies
  • Subscribers 2 subscribers
  • Views 12 views
  • Users 0 members are here
Options
Related

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

Keiko Tanaka

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

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

Reply

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

Children
  • in reply to Sylvia Chen

    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.