Route-based work looks simple from outside. The same customers, on a schedule, forever. Which is exactly why it goes wrong: nothing about it is urgent, so nothing about it gets attention until a customer notices you skipped them.

Filters, linen, uniforms, pool chemicals, pest treatments, grease traps. The business model is a promise to show up on a cycle. The operational problem is that the cycle lives in a spreadsheet somebody maintains, or in one person’s head, and both degrade.

The cycle is per customer, not per service

This is the detail that breaks naive scheduling.

You might sell quarterly service. In practice one site is quarterly, one is every eight weeks because the environment is dirtier, one is annual because they pushed back on price, and two are on a schedule somebody agreed verbally three years ago and never wrote down. A filtration customer might have sprinkler, alarm and extinguisher components each on a different interval at the same address.

So a system that assumes one interval per service type will be wrong for some share of your customer list on day one, and the people using it will go back to the spreadsheet.

I am not going to tell you what that share is, because I have looked at a small number of these and would be guessing. The design conclusion does not actually depend on the number. Storing the interval per customer per component costs nothing extra to build, and storing it per service type cannot represent the exceptions at all. When one option handles both cases and the other handles one, you do not need to know the ratio to choose. Whatever holds the schedule has to hold an interval per customer per component, and it has to be editable by whoever answers the phone.

What actually gets automated

Three things, in this order of value.

Generating the next visit before it is due. The system looks at the last completed visit and the interval, and creates the next one far enough ahead that it can be routed sensibly rather than squeezed in. This is the whole ballgame: a missed cycle is revenue you never invoice and a customer who starts wondering what they pay for.

Telling the customer it is coming. A short message a few days ahead, with the date and a way to move it. Reschedules that happen before the truck leaves cost nothing. Reschedules discovered on arrival cost a whole visit.

Flagging the ones that did not happen. Not the visits that were completed, the ones that quietly were not. A weekly list of customers whose interval has lapsed is the single most useful report in this kind of business, and almost nobody has it.

Notice that none of these is the part people ask for, which is route optimisation. Optimising the order of stops matters much less than not missing stops.

Where the data has to live, and the awkward truth about CRMs

Here is a pattern worth knowing before you buy anything.

Plenty of route businesses run order processing, invoicing and purchase orders in QuickBooks, and separately own a CRM that is used only for tracking new leads. Everything operational is in the accounting system. The CRM is a sales tool that never became an operations tool.

That matters because most recurring-service automation assumes the CRM is the operational record. I have seen one business where it was not: the orders lived in QuickBooks and the CRM held only leads and opportunities. One is not a pattern, so I will not tell you it is the common case. It is worth thirty seconds of checking before you plan anything, because if it is true of you it changes the whole approach. If it is, you have two options and they are genuinely different:

  • Move the operational data into the CRM. More capable long term, and a real change to how your team works every day. If adoption has been patchy already, this is the harder path and you should be honest with yourself about that.
  • Drive the automation from the accounting system instead. Less elegant, and it works with the habits you already have. For QuickBooks Desktop specifically, Method CRM syncs two-way in real time, firing whenever a record changes on either side (Method Sync in Detail), so estimates and invoices move between the two without re-entry. Watch it run against your own data before you rely on it.

I would usually start with the second. Low CRM adoption is often a usability problem rather than a discipline problem, and making the tool easier to use is a smaller job than making everyone change what they do.

The invoicing side, and what I have not built

The obvious next step is that a completed visit generates an invoice without anyone keying it. If the visit record carries the customer, the service, and the materials used, the invoice is a derivation.

I have not built this part, so treat what follows as reasoning rather than experience. The hard bits I would expect: materials used at the site are the piece least likely to be captured accurately, because that is a technician typing on a phone in a plant room. Any invoice generated from incomplete material data is worse than no invoice, because now your bookkeeper is reconciling instead of entering. I would sequence it last, after visit generation and lapse reporting are reliable for a couple of months.

The three ways this goes wrong

The customer list is stale and the automation makes that visible all at once. If a quarter of your intervals are wrong, turning this on generates a wave of visits for customers who cancelled two years ago. That is survivable, but it should be expected and the list should be cleaned first. This is the most common reason these projects feel like a failure in week one.

Completion is recorded loosely. If a technician marks a visit done at the end of the week for five sites, the next cycle dates are all wrong by days. The generation is only as good as the completion data, and completion data is only as good as how easy it is to record.

Nobody owns the lapse report. A weekly list of missed cycles that lands in a shared inbox and is read by nobody is worse than not having it, because it creates the belief that the problem is handled. It needs a name attached.

Working out whether it is worth it

Take your customer count, your average visit value, and your honest guess at the share of cycles that slipped last year. If you cannot estimate that share, that is the finding, and it is the argument for the lapse report before anything else.

I am not going to give you an industry figure for missed cycles, because I do not have one and any number I offered would be invented. What I can tell you is that every route business I have looked at could not answer the question from its existing records, which is itself the reason to fix it.

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.