Your Scheduling Software Isn't the Problem. Your Logic Is.

By 9:15am on a Tuesday in March 2022, I had three techs texting me from three different driveways asking variations of the same question: how long is this supposed to take? One was at a panel inspection the board had blocked for 45 minutes. One was at an EV pre-assessment I'd somehow booked back-to-back with a service upgrade 22 minutes across town. The third had arrived at a GFCI job and discovered the customer wanted to talk about a whole-house surge protector for 20 minutes before letting him touch anything.

I had beautiful scheduling software. Jobber looked exactly like the demo. The drag-and-drop board in particular looked like something a serious operation would use — clean colors, tech availability visible, automatic SMS to customers when the tech was en route.

What I had not done was define a single thing about how jobs actually worked before I started dragging and dropping them.

The Board Looks Great. Then You Try to Run a Day on It.

At Lonestar Electrical Services, where I ran service jobs from 2014 to 2021, somebody long before I got there had done the hard work. Job types were defined. Duration standards existed. A panel inspection was 90 minutes on the board, not because it took exactly 90 minutes every time, but because the data had settled on that block as the right call for the average case plus margin. Drive time was built into the zones. There was a rule about not booking two full-scope jobs on the same tech after 2pm because afternoon jobs almost always ran.

I didn't build any of that at Reeves Electric. I just opened Jobber and started booking.

The board looked organized. It was actually just a list of things I had no real estimate for — blocks I'd picked by feel, no drive time, no buffer, no meaningful difference between a GFCI swap that takes 55 minutes and a service upgrade that might take all day. By 10am my dispatcher, which was also me in those days, was on the phone rebuilding the afternoon from scratch. Every day.

The Software Isn't Broken. Your Inputs Are.

I spent a couple of weeks assuming Jobber had a scheduling problem. It doesn't. It does exactly what you configure it to do. If you tell it a job takes two hours, it blocks two hours. If you haven't set drive time assumptions, it ignores drive time. If you haven't defined job types with any rigor, every job looks the same on the board regardless of what it actually is.

This is the same dynamic I kept hitting with intake. Owners don't know the board is failing them because they've never measured what a day should look like against what it does. They feel the friction — techs running late, customers getting pushed, the afternoon always a disaster — but they blame the techs or the traffic or the customer who wouldn't stop talking. They don't blame the fact that they've never built scheduling logic, because they don't know that's something you have to build.

The dispatch board isn't your scheduling system. It's a display layer on top of your scheduling logic. If the logic doesn't exist, the board is just showing you your confusion in a cleaner font.

The pricing parallel is exact. I ran day rates for my first three months at Reeves Electric and lost money I couldn't account for. Not because the number was obviously wrong, but because I'd never defined what a job actually cost to produce. I didn't know my average job took 2.4 hours of labor plus 38 minutes of drive time plus variable parts. I just picked a number that felt competitive. The scheduling problem at Reeves Electric in March 2022 was the same failure in a different department: I was letting the tool run before I'd defined the inputs.

What Scheduling Logic Actually Means

You need a few things defined on paper before you touch a single setting in Jobber, Service Fusion, or wherever you're running jobs. Not in the software. On paper first.

Duration standards by job type. Not a single default block. Actual numbers, by type, based on your jobs. At Reeves Electric I care about GFCI/AFCI install, panel inspection, EV charger pre-assessment, EV charger install, service upgrade, and troubleshoot/diagnosis — you know the rest of the list. Each one has a meaningfully different time profile. A GFCI swap in a bathroom is 55 minutes including customer sign-off. A panel inspection with a load calc conversation runs 90. A service upgrade — pulling permit, coordinating with the utility, setting the meter base — I don't book that at anything under four hours and I don't book it after noon.

The default "2-hour block" most shops use hides all of that. A GFCI swap and a service upgrade look identical on the board, which means one of them is always wrong.

Drive time by zone. In East Austin, a 12-mile drive at 8am and a 12-mile drive at 4pm are completely different. I split the service area into three informal zones based on average drive time, not distance. The cutoffs are roughly 15 minutes, 30 minutes, and 45 minutes out. I try not to stack the far-zone jobs on the same tech in the same day without a real gap between them. None of this lives in Jobber as a setting. It's in the booking logic my dispatcher Carla uses before she touches the board.

Buffer rules. I run 20 minutes between every job on a given tech's day, and I don't book the last slot of the day within 90 minutes of close unless it's a short scope I trust. That buffer isn't wasted time. It's the margin that keeps a 9am problem from cascading into a 4pm disaster.

The EV charger example is worth pulling apart because the scheduling problem starts before the job is booked. A customer calls wanting a Level 2 charger in their garage. Looks like a half-day job. But without a 20-minute pre-quote phone screen and a $99 site assessment, I have no idea whether I'm walking into a clean 200-amp panel with a short run or a 1972 ranch with a Federal Pacific panel and the meter base on the wrong side of the house. Book a 3-hour block for the second scenario and I'm there all day while the afternoon falls apart. The site assessment does sales work, yes — but it also does scheduling work.

The Ninety-Day Rebuild

My NPS in month two of Reeves Electric was a 4. By month nine it was 81. I've written about the ninety days in between before, but the part that's relevant here is this: the scheduling logic rebuild was downstream of the listening exercise.

The complaints in those early reviews weren't about the electrical work. They were about timing — tech arrived late, customer got a 4:30pm call saying their job was being pushed, nobody communicated when the window changed. All of it traced back to a dispatch board loaded with guesses.

I started answering every call myself for ninety days. Not to suffer through it. Because I needed to understand what information was actually being exchanged during intake and whether any of it was helping me make real decisions. It wasn't. Customers were giving me enough to name a job type but not enough to scope it. I wasn't asking the right questions. The board was showing me that confusion all day.

That listening practice is now a weekly habit. Carla and I pull four calls — two that booked clean, two that ran into problems — and tag what happened. About eight months ago I started applying the same discipline to job duration, pulling actual on-site time logged by the tech against the block I'd set, by job type, every week.

What I found: two job types were running consistently long. Panel inspections were averaging 90 minutes but I was booking them at 55. Troubleshoot/diagnosis calls were averaging over 100 minutes but I was booking them at 75. Those two gaps, compounded across a day, were exactly why the afternoon always fell apart.

I didn't need new software to find that. I needed to pull the data I already had and read it.

What the Airtable Tracks That Jobber Doesn't Surface

My attribution obsession — tracking every job source with CallRail numbers and UTM tags on every channel — applies inward too. The same discipline that tells me where last quarter's booked revenue came from can tell me that my GFCI swap is routinely running 90 minutes when I'm booking it at 60.

Jobber's built-in reporting is useful for a lot of things. Job duration variance by tech and job type, at the level of granularity I needed, wasn't one of them. The raw data exists in Jobber — job records, clock-in and clock-out timestamps — but pulling it into something I could actually analyze meant exporting it and building a simple Airtable.

That's not a knock on Jobber. For a five-truck residential service shop, Jobber or Service Fusion at the core is the right call. Neither one will proactively surface the finding that your GFCI swap is running 30 minutes over book time on average. You have to build that pull yourself.

The Airtable tracks job type, tech, estimated duration, actual duration, variance, and a notes field for outliers. Carla updates it weekly from the FSM export. Takes about 25 minutes. The patterns it's surfaced have been worth far more than that.

CallRail adds another layer. When I pull recordings for jobs that ran long, I can almost always hear the scope confusion happening during intake. The customer mentions something — "oh, and we've been having some flickering in the back bedroom too" — and whoever booked the call either missed it or caught it and didn't flag it for the dispatcher. That's a scheduling problem that started on the phone.

Where to Start

Pull the last 60 jobs from your FSM. Filter by job type. Compare estimated block time to actual on-site time. If your FSM doesn't log actual on-site time separately from travel time, that's the first finding — fix the time-logging before anything else. Look for job types where the variance is consistently over 20 minutes. Those are the broken blocks. Write down the real numbers.

Then pull four intake calls from the past two weeks for jobs that ran long. Listen for scope questions that weren't asked during booking — the moment the customer mentioned something that should have changed the block time and nobody caught it. If you don't have CallRail yet, set it up this week. It runs $50 to $150 a month for a small shop and the recordings alone are worth it. I keep writing about this because most shops still aren't doing it.

Then write your logic down before you touch the board. Duration standards by job type, drive time rules by zone, buffer policy. One page. Share it with your dispatcher. Run it for 30 days before you reconfigure anything in the software.

The board is not the problem. It never was.

---

FAQ

My dispatcher says the board works fine — is this really a problem if no one's complaining?

Probably yes, and the silence is part of the problem. Good dispatchers adapt. They rebuild the day manually and make it work without flagging it as a systemic issue — because that's what good dispatchers do. Ask a different question: how often does the afternoon schedule resemble the morning schedule you built? If the answer is "almost never," the board isn't working fine. Your dispatcher is covering for it, and there's a limit to how long that holds.

We use Jobber. Should we switch to Service Fusion to get better scheduling features?

That's not the fix. Service Fusion has a slightly different dispatch interface and some features Jobber doesn't. But if you haven't defined duration standards, buffer rules, and drive time logic, Service Fusion will reflect your confusion just as clearly. Do the duration audit first. If after 60 days of running real scheduling logic you're hitting a ceiling that's specifically a software feature ceiling, then evaluate a switch. Don't switch to solve a logic problem with a tool.

How do I build duration standards if I only have six months of job history in the software?

Six months is enough to start. Filter by job type, throw out the obvious outliers where something went badly wrong, and average what's left. You're not looking for statistical precision — you're looking for a defensible number that's better than your gut. If you have 12 panel inspections and 10 of them ran between 80 and 100 minutes, set a 95-minute block. Start there and refine it every quarter.

What's the minimum viable version of this for a two-truck shop?

Same framework, less complexity. Fewer job types in regular rotation, smaller service area, simpler zone logic. The duration standards matter just as much — maybe more, because one blown block on a two-truck day is a bigger share of total capacity than on a five-truck day. The buffer rules still apply. The call recording review still applies.

My techs push back when I add buffer time because they think I'm assuming they're slow.

Tell them the buffer isn't about their pace — it's for the customer behind them. A tech who finishes in 55 minutes on a 75-minute block has 20 minutes to clean up, write notes, and drive without stress. A tech who finishes in 75 minutes on a 75-minute block is already late for the next customer before they've started the truck. The buffer protects their day. Most techs get it immediately when you frame it that way.

When does it actually make sense to look at AI dispatch tools?

My read: AI dispatch is going to take a real piece of the dispatch decision in the next 36 months. I'd rather be early and wrong than late and right. But the shops that get value from it are the ones who did the boring work first — defined job types, logged actual durations, built real buffer rules. The shops feeding garbage inputs into an AI dispatch tool are going to get garbage outputs with a cleaner interface. Get your logic clean, get 18 months of accurate variance data, then take a hard look at what the vendors are actually offering. The ones worth talking to will ask to see your historical duration data before they promise you anything.