Pilot New Software Without Disrupting Jobs: A 14-Day Plan

To pilot new software without disrupting jobs, do four things in order: pick one job type (not the whole business), run it in parallel with your old routine for 14 days so invoicing never depends on the new tool, write down three go/no-go criteria before day one, and set the exact date the old routine dies. The pilot stays small, short and reversible: if it fails on day 9 you close the tab and lose nothing but two weeks of light double entry. If it passes, the switch-off date is already in the calendar and you do not drift back.

Why a free trial is not a pilot

Most trials are 14 days and calendar-bound: the clock starts when you sign up, not when you get round to it. So you sign up on a Tuesday, poke around for 20 minutes, get called out to a fault, and on day 15 an email says the trial has expired. You learned nothing, but you now believe you evaluated the software.

A pilot has a question and a deadline. The question is not do I like this. It is does this handle a real job, from enquiry to paid, better than what I do now. You cannot answer that in an empty demo account.

So do not sign up the day you first hear about a tool. Sign up on the Sunday evening before a normal working week, with your data ready. You get 14 usable days instead of 3.

Step 1: pick one job type, not the whole business

The biggest cause of a disrupted pilot is scope. People move everything on Monday morning: every customer, every open quote, every half-finished project. Then something breaks on a job that is already three weeks late, and the software gets the blame.

Choose one job type that is high volume, short cycle, and low drama. For an electrician that is usually a callout or a small service job: two to four hours on site, one visit, one invoice. For a plumber, boiler services. For a builder, small remedial works rather than the extension you are mid-way through.

What makes a good pilot job type:

• It completes inside the pilot window. A six-week job never reaches the invoice, so you never test the half that matters.
• You do 8 to 12 of them in a fortnight. Fewer and you are testing anecdotes.
• It touches the full chain: enquiry, price, schedule, on-site record, materials, invoice, payment.
• The customer is forgiving. Pilot on repeat customers and landlords, not on the client who has already complained about paperwork.

Write down the exclusions: no ongoing projects, no jobs already quoted in the old system, no jobs with a main contractor who has their own portal. Exclusions are what stop the pilot leaking.

Step 2: run parallel for a fortnight

Parallel running means the old routine stays the system of record while the new tool runs alongside as a shadow. Invoicing and accounts still come out the old way. People skip this, and it is exactly the part that removes the risk: if the new tool loses a job, mangles a price, or will not load on a roof with no signal, nothing happens to your cash.

Be honest about the cost. Parallel running is double entry, roughly 5 to 10 minutes extra per job. Across 10 pilot jobs that is one to two hours over a fortnight, to settle a decision you will live with for three years.

How to stop the double entry becoming a burden:

• Enter the job in the new tool first, then copy to the old one. The other way round and you skip the new one whenever you are busy, and the pilot dies quietly.
• Only shadow the pilot job type. Everything else goes the old way, untouched.
• Connect nothing to your ledger. If the tool has a Fortnox or Visma connection, leave it off until after the go/no-go.
• Keep a note file open. One line per irritation, with the job number. That file is your evidence.

Step 3: write three go/no-go criteria before day one

Three. Not seven, not a spreadsheet of 40 features. Written before you have any emotional investment, each one a yes or a no. Write them afterwards and you will write them to match whatever you already decided.

Good criteria are measurable and about outcomes, not features:

Pick the three that map to why you are looking in the first place. If you invoice late, one must be about invoicing speed. If your fitters will not fill in job sheets, one must be about a fitter completing a record without you.

Email them to yourself on day zero, date-stamped and unedited. On day 14 you open that email and score each one yes or no. Two out of three is a go. Decide that scoring rule now as well, so you cannot move the goalposts later.

Step 4: set the date the old routine dies

A pilot with no kill date turns into a permanent second system: jobs in two places, nobody sure which is right, admin worse than before you started. That is the real disruption risk, and it comes from indecision, not from software.

So on day zero, before a single job runs, put a date in the calendar: the day the old routine stops. Usually day 21, or the first of the following month, whichever gives a clean boundary. Tell your team and your bookkeeper, in writing.

On that date, one of two things happens:

• Go: the old routine stops for the pilot job type, and the next fortnight brings the rest across, job type by job type. No big bang.
• No-go: you delete the account and go back, with a written note of why. Keep that note. When the same salesperson calls in eight months, you already have the answer.

The kill date is what makes the pilot honest. Without it, no result forces action, so no result matters.

The 14-day calendar

What to move over before day one

Pilots fail because the tool was empty. Typing customer addresses by hand on a Tuesday afternoon is what makes people quit on day 4. Do this on the Sunday:

• Customers. Export a spreadsheet from your current system or accounts package and import it. A rough list of names, addresses and phone numbers is enough.
• Price list. Your top 50 lines cover most jobs. You do not need all 40,000 wholesaler items on day one.
• Your logo and payment details, so a pilot quote and invoice look real enough to send.
• One saved template for the pilot job type: standard description, price, checklist.

Do not migrate history. Old jobs, old invoices and closed quotes stay where they are. History belongs in your accounts and your archive, not in a pilot.

One thing worth checking before you commit a fortnight: if a tool has no bulk import for customers and price lists, and no way to export your data back out, you are not piloting it, you are being captured by it. OdinTask has spreadsheet import and export for customers, articles and suppliers on day one, and a 14-day trial long enough to run exactly the plan above.

The failure modes that actually disrupt jobs

None of these are about features. They are about how you run the pilot.

• Two systems, no system of record. A fitter records the job in the new app, you invoice from the old one, the variation never crosses over, and you invoice short. Fix: the old routine is the record until the kill date.
• Piloting on your worst job. The site that already has a dispute is not a test bed.
• Connecting the accounts early. A half-configured sync pushes drafts into your ledger and your bookkeeper loses a morning.
• Training on an empty account. A 45-minute demo with no data teaches nothing and burns your team's patience for the real thing.
• Evaluating alone. If no fitter touches it, you tested the office half. The site half is where these tools die.

If you are in Sweden: two extra checks

Add these to the pilot job type if they apply. They are the ones that cost money if they are wrong.

• ROT. Run at least two pilot jobs where the deduction applies, through to the payment request. ROT is 30 percent of the labour cost, with an annual per-person ceiling shared with RUT, and the customer must see the net price on the quote. Check the current ceiling at Skatteverket. If the tool cannot produce the husarbete XML for the utbetalning request, that job goes back to a manual form.
• Egenkontroll. If your trade requires a self-inspection record, one pilot job must produce a finished, signed protocol as a PDF. Not a draft.

Outside Sweden the shape is the same: whatever your compliance paperwork is (a UK electrical installation certificate, a gas safety record, a producer statement), one pilot job must produce the finished document. If it cannot, that is a no-go on its own, whatever the other three criteria say.

Pilot new software without disrupting jobs: the short version

1. One job type. Short cycle. 8 to 12 jobs. Everything else excluded, in writing.
2. Parallel for 14 days. New tool first, old routine carries the risk. Accounts sync stays off.
3. Three criteria, emailed to yourself on day zero. Two of three is a go.
4. Kill date in the calendar before you start. Go or delete. No third option.

Two weeks and about two hours of double entry buys a real answer instead of an expired trial.