The decision to
move off paper tickets is usually easy. The migration is where companies get stuck, and the reason is almost never the software.
It’s that a shop switching systems is running two processes at once, in the middle of a busy season, with crews who did not ask for this. Handled well, that lasts a few weeks. Handled badly, it lasts a year and the company ends up back on paper with a subscription it doesn’t use.
Here’s a sequence that works, drawn from watching it go both ways.
Before you start: know your numbers
Measure three things while you’re still on paper. You’ll want them later, and you cannot reconstruct them afterwards.
Days from job completion to invoice sent, averaged over a month.
Days from job completion to invoice sent, averaged over a month.
Tickets that went missing or were never billed, counted over the same month.
Hours your office spends per week on ticket entry, chasing, and reconciliation.
Write them down. In three months these become the proof that the change worked, or the early warning that it didn’t.
Step 1: pick the pilot crew carefully
Do not start with everyone. Do not start with your best crew either.
Start with one crew that runs a representative workload and includes at least one skeptic. The skeptic matters. If the system survives him, it survives the rollout. If you pilot with your most enthusiastic crew, you learn nothing about what the rest will do.
Two to four weeks of pilot is usually enough to surface the real problems.
Step 2: run parallel, but set an end date
For the pilot period, tickets go in both systems. Paper as the system of record, digital alongside it.
This feels wasteful and it’s worth it, because it lets you compare the two directly and catch what the digital ticket is missing before it matters.
The critical part: announce the end date at the start. Parallel running with no deadline never ends. Crews default to paper because paper is familiar, and the digital system quietly becomes a data entry chore nobody does.
Step 3: move the data that earns its keep
You do not need ten years of history in the new system.
What you do need: your current customer list, active equipment with serial numbers and current status, current rate structures by customer, and open jobs.
What can stay behind: closed jobs, historical tickets, old pricing. Keep the archive accessible in your accounting system or an export. Migrating history is expensive and almost nobody looks at it afterwards.
One exception. If you have equipment under warranty or with recertification dates coming up, bring those dates across. Missing a recertification because it lived in the old system is an expensive way to learn this.
Step 4: train the field differently than the office
These are two different training problems and treating them the same is why rollouts stall.
The field needs fifteen minutes, once, on a phone, doing the thing they’ll actually do. Not a slide deck. Show them the ticket screen, have them complete one, answer questions, done. If it needs more than fifteen minutes, the software is wrong, not the training.
The office needs several hours across a few sessions, because their job changes more. Approvals, invoice generation, the accounting sync, what to do when something doesn’t look right.
Train the office first. When a tech has a question in week one, the answer should already be in the building.
Step 5: expect week two to be the hard one
Week one goes well. Everyone is paying attention, the trainer is around, and the novelty helps.
Week two is when the crew hits a job that doesn’t fit the standard flow, the supervisor is busy, and the easiest thing is to grab a paper ticket. That moment decides the rollout.
Plan for it. Have someone available specifically to answer questions in week two, and make it clear that going back to paper for one job means the office gets an incomplete picture for that job.
![image]()
Step 6: cut over fully, then check your numbers
At the end of the parallel period, stop printing tickets. Not “discourage.” Stop.
Then, thirty days later, measure the same three numbers you measured before. Days to invoice. Missing tickets. Office hours per week.
Shops that do this properly typically see days-to-invoice drop from the mid-teens to under five, and missing tickets go to zero because a ticket that doesn’t exist in the system is visibly absent rather than silently lost.
If the numbers haven’t moved, something in the process is still broken, and now you know to look.
What goes wrong most often
Rolling out during peak season. If you have a choice, do it in the quiet part of the year. If you don’t have a choice, extend the pilot and shrink the first wave.
No named owner. Migrations without one person accountable drift. It doesn’t have to be a manager, but it has to be somebody whose week includes this.
Skipping the baseline numbers. Without them, six months later nobody can prove the change worked, and the next investment gets harder to justify.
Configuring everything before going live. Perfect configuration on day one is a trap. Get the ticket flow right, go live, then tune. The things you’d configure in advance are usually not the things that turn out to matter.
The part nobody mentions
The crews usually come around faster than management expects, for a reason that has nothing to do with features.
A digital ticket with a customer signature on it ends arguments. The tech who used to get questioned about hours three weeks after a job now has the signed record on his phone. That’s worth more to him than any efficiency gain, and it’s what to lead with when you introduce it.
