Why software rollouts fail in the trades

Implementation timelines in this market are long. Buyer guides routinely describe six to twelve months for the larger field service platforms, with a separate implementation fee attached. That is a long time to be spending money on something that is not yet working, and a large share of the businesses that go through it end up somewhere disappointing: the system is live, the office uses part of it, the crews use as little as they can, and the spreadsheet never actually went away.

In almost every case we are called into afterwards, the product was fine. The rollout was the problem, and it failed in one of a handful of recognizable ways.

Six ways it goes wrong

1. Nobody owned it

The single strongest predictor. Not a sponsor who approves things — an owner with time in their week, authority to decide, and enough standing that their decisions hold. Projects with a real owner and a mediocre product beat projects with a great product and a committee, every time.

2. It was rolled out to everyone at once

A company-wide launch means every problem surfaces simultaneously, in front of everybody, with no reserve capacity to fix any of them. The first two weeks generate the story people tell about the system for years, and a chaotic launch writes a story you cannot rewrite. One crew, one division, or one job type first is slower on paper and faster in reality.

3. Parallel running never ended

Running the old way alongside the new feels prudent and is the most reliable way to kill an implementation. People double-enter, resent it, and quietly decide which system is real — and it is never the new one, because the old one is where their muscle memory and everyone else's information lives.

Parallel running should be short, fixed, and announced with an end date before it starts. "We will run both until people are comfortable" is not a plan, it is a way of never cutting over.

4. The data was migrated dirty

Ten years of customer records with three spellings of the same name, addresses in a notes field, jobs that were closed in reality and open in the system. Import that as-is and the first week produces duplicate customers, wrong histories, and invoices to the wrong entity. Users conclude the system is unreliable — and for them, it is.

Data cleanup is the least glamorous line in any implementation, it is frequently the largest, and it is the one most often skipped because it can be. It cannot be skipped afterwards.

5. Training happened before the system was real

A two-hour session, six weeks before go-live, on a demo dataset. By the time anyone uses it for real, they remember nothing, and the training is now a reason nobody asks for help — they were shown, after all. Training that lands happens on real data, in the week of use, in fifteen-minute pieces, and is repeated.

6. The first use of the data was disciplinary

A supervisor pulls up the new system to challenge someone's hours in week two. Everyone hears about it by lunchtime. From that moment the app is a surveillance tool, entry quality collapses to whatever the minimum acceptable answer is, and every number the system produces afterwards is fiction. This is recoverable in theory and almost never in practice.

What a rollout that lands looks like

What crews are actually reacting to

Resistance in the trades gets described as people not liking technology, which is almost always wrong. The crews have smartphones and use complicated apps all day. What they are reacting to is more specific and more reasonable.

• They have been through a failed rollout before. Their expectation is that this is more paperwork wearing a new hat, and that expectation was earned.
• The last system made them look bad. Data entered badly under time pressure got used against them, or a report showed them as slow because it counted drive time as idle.
• Nobody asked them anything. The system encodes assumptions about their work made by people who have not done it in years, and they can see it in the first screen.
• It is slower than what they had. Frequently true at first, and denying it destroys credibility. Acknowledge it, and be specific about what they get in return.
• They are not sure what it is for. If the honest answer is "so the office can see what you are doing", they already know, and pretending otherwise is worse than saying it.

Pick the most respected skeptic on your crew and build it with them. If they defend it, the rollout is already done.

Judge it at ninety days

Set the success measure before you start, in terms of the behavior you actually want: what share of jobs have hours attached the same day, how long from job complete to invoice sent, how many customer calls are answered without phoning a truck. Numbers about the process, not about the software.

Then look at them at ninety days and be willing to hear the answer. If the behavior has not changed, more training is usually the wrong response — something in the design or the sequence is wrong, and the honest move is to find it rather than to blame adoption. Related territory: choosing features you will actually use and how to scope a first automation project.