"Jobs are taking too long" is not a number you can fix
Every operator can feel when the day is dragging — techs finishing fewer jobs, the schedule slipping, the sense that everything takes longer than it should. But "jobs are taking too long" is a feeling, not a number, and you can't fix a feeling. Before you can do anything about a slow operation you have to answer a sharper question: slow where? Because a job isn't one undifferentiated lump of time. It's a sequence of distinct phases, each with its own causes and its own fixes, and the whole point of a cycle-time report is to stop you from treating them as one thing.
When you lump the phases together, every fix is a guess. You add a tech because jobs feel slow, when the real problem was a two-hour gap between when work came in and when anyone dispatched it — a scheduling problem a new hire won't touch. Or you push techs to work faster on site, when the slow part was actually the drive, and the answer was tighter routing, not more pressure on people who were already efficient. Splitting the job into phases is what turns a vague complaint into a specific, fixable target.
The three phases of a service job
Cleanly measured, a completed field job breaks into three intervals, each answering a different question:
- Dispatch lag — created to en route. How long from the moment a job exists to the moment a tech is actually on the way. This is your office speed, not your field speed. A long dispatch lag means work is piling up before anyone moves it — a scheduling and dispatch problem that no amount of fast driving or fast wrenching will fix.
- Travel time — en route to on site. How long the drive takes. This is your geography and routing number. A long travel phase points at sprawled-out scheduling, bad sequencing, or simply a service area that's outgrowing how you build routes — and it's the most direct measure of the windshield time that earns you nothing.
- On-site time — on site to completed. How long the actual work takes once the tech arrives. This is your field execution number, and it's the one most people assume is the whole story when it's usually a third of it. A long on-site phase can mean genuinely hard work — or it can mean a missing part forcing a second trip or a job the estimate under-scoped.
The power of the split is that each phase points at a different lever. You can't improve "cycle time" — but you can absolutely shorten dispatch lag, or tighten routes, or close the part-availability gap that's stretching on-site time. The report's job is to tell you which lever to pull.
How Hosting Field measures it
Hosting Field's cycle-time report reads directly off the server-enforced job workflow, so the phases come from real recorded transitions, not from anyone's estimate. Because every job moves through draft → scheduled → en route → on site → complete on a timestamped path, the platform can measure the exact intervals — dispatch lag (created → en route), travel time (en route → on site), and on-site time (on site → completed) — across your completed jobs.
It reports the median of each phase rather than the average, which matters more than it sounds. One catastrophic job — a tech who left a job open over a weekend — would wreck an average and send you chasing a problem that doesn't really exist. The median tells you what a typical job looks like, which is what you want when you're deciding where to invest. The report names the slowest phase outright and rolls up a simple posture so you can see at a glance whether things are healthy or drifting, and it breaks the numbers down per technician so you can tell a system-wide pattern from one person who needs support.
The honest scope, and it matters: this is a descriptive report of completed jobs, not a predictive forecast and not an auto-scheduler. It tells you, accurately, where the time went on the work you've already done — it does not predict how long the next job will take, optimize tomorrow's routes for you, or reassign anyone. It surfaces the inputs; you read them and decide. That's deliberate, because the number is only the start of the conversation — why the dispatch lag is long is a question about your intake and your morning, and only a human who knows the operation can answer it. The report makes the slow phase impossible to miss; closing it is the work.
Turning the numbers into action
- Start with the slowest phase, and only that one. The report names it for a reason. Trying to improve all three at once spreads your effort thin and you feel no result. Fix the worst phase first, watch the median move, then go to the next — improvement you can actually see is improvement that sticks.
- Read the per-technician split before you conclude anything. A long on-site median that's really one tech who takes every hard job is a staffing and support story, not an everyone is slow story. The breakdown stops you from pushing a whole crew over a problem that's specific — or missing a genuine system issue because the average hid it.
- Connect the phase to its real cause. A long dispatch lag is rarely "lazy dispatchers" — it's usually work entering the system slowly or a morning that starts late. A long on-site phase is rarely "slow techs" — it's often parts, scope, or the wrong tech sent to the job. Treat the number as a symptom and go find the cause.
What to watch over time
- Each phase's median, tracked as a trend. A single reading tells you where you are; the trend tells you whether what you changed worked. When you tighten routing, travel-time median should fall — if it doesn't, your fix missed.
- The gap between your phases and your estimates. If on-site time consistently runs longer than your quotes assumed, your estimating is optimistic in a way that's quietly eating margin — a direct feed into closing the quoted-vs-actual gap.
- Per-tech spread within a phase. A wide spread between your fastest and slowest tech in the same phase is a training and standardization opportunity, the kind a reusable checklist can close — bring the slow end toward the fast end and the whole median improves.
A service job feels like one block of time, but it's really three — the wait before the roll, the drive, and the work — and you can only fix what you can separate. A cycle-time report built on real, timestamped workflow transitions splits the job into honest phases, names the slow one, and shows you whether it's everyone or someone. It won't predict your next job or schedule it for you; it tells you, truthfully, where today's time went. Read the slowest phase, find its real cause, fix that one thing, and watch the median move. That's how "jobs feel slow" becomes a number you can actually do something about.