Six months after the rollout, the office runs on a spreadsheet again. The software is still paid for. The logins still work. The dispatcher opens it in the morning to see the board and then does the day in the sheet, the techs text the office when a job is done, and the quotes come out of the same Word template they came out of before. Nobody decided this. It happened one Tuesday at a time.
The owner draws one of two conclusions. Either the team will not adopt software, or the shop bought the wrong one. Both are usually wrong, and they are wrong for the same reason.
It was not the software, and it was not the team
A job moves through a shop as a chain of handoffs. A call becomes a quote, the quote becomes a job, the job becomes an invoice, the invoice lands in the books. Before the software, that chain ran through a phone pad, a template, a group text and QuickBooks, and every link was a person re-typing what the previous link already knew. It was slow, and it worked, because it was connected to the things that actually happened.
The new system was set up as a destination. Customers imported, logo uploaded, logins handed out, a training afternoon. It was not set up as a link in that chain. Nobody sat down and said: the accepted quote goes here, and from here it becomes the job without anyone typing it again. So the chain kept running where it always ran, and the tool became a second place to type the same thing.
A person under pressure will always drop the second place to type. The spreadsheet survived because it was the one still connected to the job.
That is the whole diagnosis. Everything below is the three ways it usually happens, what adoption actually means, and the one-week test to run before you buy anything else.
Three patterns of a rollout that went back to the sheet
-
01
The empty price book
The software went live with thirty items in it, because thirty was what fit in the afternoon someone had. The real prices lived in a Word template and a supplier PDF. So on day one the quote screen in the new tool was slower than the template, and the office manager, who had eleven quotes to get out, used the template. By day thirty the tool had a reputation for being slow at quoting. It was never slow. It was empty.
-
02
The field never joined
The office uses the tool. The techs still text photos and a few words to the office manager, who types them in. That is not adoption; it is a clerical layer on top of the same job, and the office is now doing the tech’s data entry as well as its own. The usual verdict is that techs will not use apps. Look at what the app asked them for: six fields the office needed, and in return, nothing they needed. No history at the address, no parts on the truck, no way to see tomorrow. Adoption is a trade, and nobody offered the field anything.
-
03
The books stayed the boss
The bookkeeper corrects an invoice in QuickBooks, because that is where the bookkeeper works. The field tool syncs one way, out to the books, so the correction never comes back. By month two the tool and the books disagree on a dozen jobs, everyone learns not to trust the tool, and a spreadsheet reappears as the thing that reconciles them. This one gets blamed on the sync. It is a working rule that was never set: edit in the field tool, read in the books.
Notice that none of the three is a missing feature. The first is data that was never loaded, the second is a trade that was never offered, the third is a rule that was never set. Switching products fixes none of them, which is why the shop that moves from one tool to another in this state is back on the sheet again a year later, with a second migration behind it. If you are reading the comparison pages on this site (Jobber vs Housecall Pro, ServiceTitan alternatives, Buildertrend vs JobTread) with one of these three going on, read this one first.
What “adoption” actually means
Not training. Not a champion. Not a memo saying the sheet is banned from Monday. Adoption is whether the tool sits on the shortest path of the job. If the handoff the tool was bought to remove is still done by a person, the tool is an extra step, and extra steps get dropped by exactly the people who are busiest, who are the people you most needed to use it.
So the test for any feature, in the tool you have or the one you are being shown, is one question: name the manual step it replaces. If you can point at the step and the person, it is a link in the chain. If you cannot, it is a demo, and it will be on the bill and off the shortest path within a quarter. The same test is the spine of what AI can actually do for a shop like yours, because AI features fail the same way, faster.
The one-week test before you buy anything else
Before you switch tools, before you add an AI receptionist, before you sign the renewal: a week, one crew, one job type. It costs some patience and nothing else.
- 01
Trace one job from last week.
Phone to bank. Every screen it touched, every person, every re-type. Half an hour with the office manager and one tech. Write it down; you will want it later.
- 02
Find where the spreadsheet re-enters.
There is one step where the job leaves the tool and goes into a sheet, a text or a template. That step is the handoff nobody mapped. It is almost always the quote or the close of the job.
- 03
For one week, make the tool the only place that step happens.
One job type, one crew. Load the twenty price-book items that crew actually uses. Make the tech close the job on the app before leaving the driveway. Have the office read from the tool and not from the sheet, even when the sheet is faster, for five working days.
- 04
Count what happened to the re-type.
If it disappeared, the tool was never the problem, and the fix is to roll the same week to the next crew. If it moved somewhere else, you have found the next handoff. If nobody could make the tool do the step at all, now you have a real reason to switch, and, more usefully, a written description of what to demand from the next one.
Set that week against what a migration costs, which is a price-book rebuild, a customer import, a month of running two systems and a month of everyone hating the new app. The migration section on the ServiceTitan page itemises it. The week is cheaper by a long way, and it is the only one of the two that tells you what was actually wrong.
The spreadsheet is telling you something
Do not delete it. Read it. Its columns are the fields the tool is not capturing. Its tabs are the handoffs the tool is not making. The colour coding is the status the tool does not show at a glance. It was built, one column at a time, by the people doing the work, to hold exactly what they needed and nothing else, and that makes it the best requirements document your shop will ever get. Every software rollout that stuck, in my experience, started by someone reading the sheet it was replacing and asking why each column was there.
Then, and only then, configure the tool to hold those columns. Load the price book. Set the rule about the books. Give the field something back. The sheet goes quiet on its own, because it stops being the shortest path.
If you would rather not run the week yourself
The trace in step one, done properly, across every job type and with a dollar figure beside each re-type, is the AI Audit. I map how a job moves through your shop, interview the people who do the work, count the places it gets typed twice, and hand you a written blueprint that says what to configure, what to connect, and what, if anything, to buy. A fixed fee, $5,000, sized by headcount. If the recoverable savings do not cover it, you do not pay, and you keep the blueprint. The calculator will give you a rough number first, from four inputs, if you want to know whether it is worth the call.