How many systems does one job pass through before it gets invoiced?

Ask an operations manager at a growing maintenance firm how many systems they run, and watch them count on their fingers.

A CRM, because the sales side needed a pipeline. A scheduling tool, because the whiteboard stopped working somewhere around the twentieth engineer. A mobile app that produces service sheets, because clients started asking for evidence. Accounting software, obviously. And a spreadsheet. There is always a spreadsheet, and it is usually the thing actually holding the business together.

Nobody chose this. It accumulated.

How it happens

It happens because growth is not smooth, and neither is buying software.

Early on, one system does everything, and that system is usually a spreadsheet with a shared inbox next to it. It works, because an independent team can hold the whole business in their heads and shout across the office when something changes.

Then the shouting stops working. So you buy something. Usually the thing that solves the loudest problem that month, which is normally scheduling, because you have run out of ability to remember who is where.

Then clients start asking for evidence. Certificates, service sheets, photographs of what was actually done. So you buy something for that too, and because it is a different problem you buy it from a different vendor.

Then someone points out that you have no idea which quotes turned into work, so you buy a CRM.

Every one of those decisions was correct at the time. Each one solved a real problem. The trouble is that none of them was made with the others in view, because the others did not exist yet.

What it actually costs

The cost is not the licences, though they add up faster than most firms realise.

The cost is the handoffs.

Somebody keys the same job in twice.

A client rings, the job goes into the scheduling system. It gets done. The service sheet comes back through the mobile app. Now someone has to make sure the app's record and the scheduler's record agree, and then get both into a state where an invoice can be raised. That person exists in every firm running multiple systems, and their job title is never "data entry".

The truth lives in different places depending on what you are asking.

Where is Dave right now: the scheduler. Did the job actually get done: the mobile app. Has the client been invoiced: accounts. What did we quote them originally: the CRM. Nobody can answer a simple question without opening three tabs, and when the answers disagree, nobody knows which one is right.

Reporting becomes a manual assembly job.

The monthly client pack, the one that proves you are doing what the contract says, gets built by hand from exports. It takes a day. It takes a day every month, forever, and it is the first thing to slip when someone is off.

And nothing chases itself.

A job that was raised but never sent to a subcontractor sits there. An inspection that failed and needed a remedial gets forgotten because the remedial lives in a different system from the inspection. A quote goes out and nobody follows it up. None of these are anybody's fault. They are simply the gaps between systems, and things fall into gaps.

Why "we will integrate them" rarely lands

The natural response is to connect them. Most vendors will tell you that they integrate, and most of them genuinely do, in the sense that data can be made to move.

Two things go wrong.

Integrations move data, not process.

Getting a job record from your scheduler into your accounting system is the easy part. Deciding what should happen when an engineer marks a job complete but the client disputes it, or when a job needs a second visit, or when a quote is approved three weeks later, is the hard part. That logic ends up living in somebody's head, or in the spreadsheet, because no integration can hold it.

Every integration is a thing that can break.

And when it breaks, it breaks quietly. Records stop flowing, nobody notices for a fortnight, and then someone finds a pile of jobs that never made it to invoicing.

Integration is a reasonable answer when the systems you are connecting are genuinely different domains. Your accounting package should be a separate thing that your operational system talks to. That is a clean boundary and it works.

It is a much less reasonable answer when you are connecting three systems that are all trying to describe the same job.

What to actually ask before you buy anything else

If you have reached the point where you are reviewing this, the temptation is to look at what is available and compare features. Do that later. Ask these first.

How many times does one job get typed in, and by whom?

Follow one job from the client's first phone call to the invoice going out. Write down every system it touches and every person who re-enters information that already existed. That number is your actual problem.

Where does the truth live?

If two systems disagree about a job, which one wins? If you cannot answer that instantly, you have a data integrity problem rather than a software problem, and buying a fourth system will not fix it.

What are you keeping and what are you replacing?

Some boundaries are genuinely worth keeping. A CRM does a different job from an operations system, and holding on to yours may well be correct. But if two of your systems are both describing jobs, sites and assets, they are competing rather than complementing.

What happens to the history?

Years of asset records, service history and compliance certificates sit inside these systems. Any answer that does not include a serious plan for moving that data is not a real answer.

And who is going to do the work?

This is the one that quietly kills more projects than anything else. Whoever inside your business knows the estate and the people will need real hours to set the new thing up properly. If those hours do not exist, the rollout will not finish, and you will end up with four systems instead of three.

The honest summary

Running three systems is not a sign that anyone made bad decisions. It is a sign that a business grew faster than its tooling, which is a better problem than the alternative.

But it is worth being clear about what you are solving. The goal is not fewer logins. The goal is that a job gets entered once, that everyone asking a question about it gets the same answer, and that the paperwork at the end of it happens without a person retyping what an engineer already wrote down.

If the option in front of you does not do that, it is a fourth system.