Field notes › Choosing software

How to run a software pilot that gives you a real answer

A software pilot is meant to answer one question: should we run the business on this? Plenty of pilots never answer it. They start with enthusiasm, run in a corner of the office with a handful of test records, and fade out when a busy month arrives. Later nobody can say whether the software failed or the pilot did. A pilot that gives you a real answer comes down to decisions you make before anyone logs in.

A trial and a pilot are different things

A trial is for looking around. You click through screens with sample data and see whether the product is the right shape for your work. It's quick and it tells you whether a pilot is worth doing. It can't tell you whether your crew will keep their availability current, whether a client will use a portal, or whether your rosterer will quietly keep the spreadsheet open beside it.

Only real work answers those. Mustr keeps the two separate. The 7-day trial is a sandbox with sample crews and sites that expires, and it needs a work email but no credit card. The pilot is the real system with your own people and shifts. Use the first to decide whether to start the second.

Pick one client site, and pick it on purpose

Run the pilot on one client site with a real crew and real shifts. Not the whole book, and not a pretend site set up for the exercise.

Shift requestsNorth Site · DayMon 14 to Fri 18 · Role: Medic · 4WD requiredAssignA request lands in the office queue. Assigning a workerruns the compliance check before the booking is made.Blocked: worker is missing 4WD (required for this site).12
The booking check runs before every assignment. Failures are blocked, with the reason.

Which site matters more than people expect. The easiest one, with a stable crew and a client who never changes anything, will make any software look good and teach you nothing. The messiest one will bury the pilot under problems that have nothing to do with software. Choose a site that looks like most of your work, with the usual spread of tickets and a client who raises requests the way most of your clients do. If the pilot holds up there, it tells you something about the rest.

Write down what success looks like before you start

If you don't decide what a good result is before the pilot, you'll decide afterwards, based on how the last week felt. Write a short list of things you can observe by the end. For example:

  • The site's roster lives only in the new system, with no spreadsheet kept on the side.
  • Tickets and inductions for that crew are current in the system, and bookings that break a requirement get stopped.
  • The client contact raises requests through their own logins instead of by phone or text.
  • Crew check their roster on their phone rather than ringing the office to ask.
  • The rosterer would choose to keep using it.

Some of those are judgement calls, and that's fine. What matters is that you agreed on them in advance. Write down what failure would look like too. A pilot that can't fail isn't testing anything.

Give it an owner and a date

Every pilot needs one person who owns it. Usually that's the rosterer or operations lead for the chosen site, not the director who agreed to try it. The owner sets the site up, gets the crew signed in, chases the client contact to use their logins, and keeps a running note of what worked and what got in the way. They also need the time, so take something off their plate for the first few weeks.

Set the decision date on the day you start and put it in the calendar with whoever will make the call. A fixed date stops the pilot drifting into an arrangement nobody actually chose. When it arrives, sit down with the success list and the owner's notes and decide whether to roll it out to more sites or stop. If a specific question is still open, extend for a set period to answer it. Don't extend because nobody wants to decide.

Know what you're committing to either way

Read the terms before the pilot starts, not at the decision meeting. On Mustr's pricing page, the smallest plans are $660 a month for up to 30 users and $990 for up to 50, GST included, and every plan runs month to month with no lock-in contract, so you can stop if it isn't working. Every plan carries every feature, so you aren't piloting a cut-down version of what you'd buy. Whatever software you're testing, ask what happens to your price and your data when the pilot ends, and get the answer in writing.

If you'd like to check the shape of it first, try it with sample data, and when you have a pilot site in mind, book a demo.

Bring one roster to the demo. We'll show you Mustr running it.

Book a 20-minute demo