Your schedule is right at 7am. By 10am it is fiction.

The first job needed a part nobody knew about. The tech who was supposed to be at the second site is still at the first. The customer at the third site has taken the afternoon off work and is waiting. Nobody has called her, because the person who would call her is the person now solving the parts problem.

This is the cascade, and it is the actual scheduling problem. Not building the schedule. Repairing it.

Why most scheduling software does not help with this

Most of it is good at the first version of the day and bad at the seventh. It will let you build a route, assign a crew, and publish it. What it usually will not do is answer the question you have at 10am, which is: given that job one is running two hours long, what is now wrong, and who needs to be told?

That question has three parts, and they are worth separating because they automate very differently.

Knowing a job is running long. Automatable, and the foundation of everything else.

Deciding what to do about it. Not automatable in any business I have looked at. It depends on which customer is more likely to walk, who is closest, which tech is certified for what, and who you owe a favour. That is a dispatcher’s judgement and it should stay one.

Telling everyone affected. Automatable, and the part that gets skipped, because it is the part that takes twenty minutes of phone calls nobody has.

So the useful system is not a scheduler. It is a detector and a notifier wrapped around a human decision.

Knowing a job is running long, without asking anyone

The cheapest reliable signal is the one you are probably already collecting: the time clock.

If you use TCP Time Clock Plus, job costing comes from its Professional job costing module. TCP’s own documentation says its reporting captures up to five levels of job costing per labour code (TCP Software, job costing), so the code structure is yours to design rather than fixed. Customer, then location, then service type is a sensible three of those five, and it exports to CSV or Excel, which is all an automation needs.

That gives you elapsed time per job against whatever you estimated. Once that comparison exists, a job running long is a calculation rather than a phone call.

What a time clock will not give you. It answers “who worked where, for how long, on what code” and very little else. The note field on a clock-in is built for a short remark, not a work description, and it captures neither materials used nor signatures. Check the actual field length in your own account before you design anything around it, because it is the kind of limit that is easy to assume and annoying to discover late. If you need the description and the materials too, that is a second simple form, or a field service module.

TCP or QuickBooks Time

Worth answering directly, because most people already own one of them.

If you run payroll through QuickBooks, QuickBooks Time tracks time against customers, projects, classes and service items, and job costing sits in its Elite tier rather than the cheaper Premium one (QuickBooks Time review, Research.com, 2026). The advantage is not the feature list. It is that the job code and the invoice live in the same system, so nothing has to be reconciled between two vendors.

TCP is the better instrument if you want a genuine clock: more costing levels, and hardware terminals for crews who do not all carry a company phone.

The honest summary is that this choice matters much less than whether the codes get selected correctly at clock-in. A cheap system with disciplined coding beats an expensive one without it, and no amount of either fixes a job code nobody picked.

The notification is the part worth building

When a job crosses its estimate by some threshold you choose, the useful output is not an alert to the dispatcher, who already knows. It is a prepared set of consequences:

  • Which later jobs are now at risk, in order
  • Which customers are affected, with their contact details
  • A draft message for each one, saying the technician is running late and giving a revised window

The dispatcher reads the list, changes what needs changing, and sends. Twenty minutes of calls becomes two minutes of review, and the customer at the third site hears from you before she works out for herself that nobody is coming.

That last part is most of the value. Customers forgive a late technician. They do not forgive being left waiting without being told.

Geofencing solves a different problem than the one you think

TCP and similar systems can geofence: draw a boundary around each customer site, and clock-ins register a location, optionally restricted to inside the fence.

It is usually sold as a way to stop time theft. In practice that is the least interesting thing it does. What it actually gives you is automatic arrival and departure times per site, without anyone writing anything down. That is the input your job duration estimates have been missing, and after a couple of months it tells you which jobs you consistently under-quote.

Two honest cautions. Geofenced clock-in restrictions cause real problems when the fence is drawn slightly wrong or the site has bad signal, and the failure mode is a technician who cannot start work. And if half your technicians are on personal phones rather than company ones, location tracking becomes a conversation with your team rather than a configuration setting. That is a policy decision and not a technical one, and it should be made deliberately.

Where this stops

It will not build a better route than a good dispatcher. Route optimisation is genuinely useful when you have a large stable customer list and fixed cycles. When the day is reactive, the optimiser’s answer is stale by the time it finishes.

It will not know that a customer is about to leave you. The system sees a job running long. It does not see that this is the third time for the same account.

It needs the estimates to be roughly honest. If every job is estimated at two hours regardless, then everything runs long, the threshold fires constantly, and people stop reading the alerts. Deliberately underestimating to look efficient breaks this before it starts.

What it costs

The detection and notification side is a scheduled job reading a CSV export and an AI model drafting the messages. That is a few dollars a month in API usage on top of whatever you already pay for the time clock.

The alternative is a field service platform with dispatch built in. For a comparable scope I have seen that land in the region of $270 a month for fifteen technicians, made up of a dispatcher seat plus a per-technician charge. It is more polished, it is multi-user by default, and somebody other than me supports it.

My honest recommendation for most people reading this: prove the workflow on the cheap version first. If manual entry and CSV exports turn out to be the painful part rather than the scheduling, then the platform is worth its monthly cost and you will know why.

I am Kenyon Sutherland. I build the automation described above for small manufacturers and service companies: email and quote intake, screening, and reporting, on the tools you already run. If you want to know what applies to your operation, send me a week of your real emails and I will tell you.