Field notes › Choosing software
Getting your office to actually use the new system
The system that gets chosen is rarely the reason a rollout fails. What kills it is a coordinator who keeps a private spreadsheet because it is faster, a second coordinator who half uses the new tool, and a month later two versions of the truth and nobody trusting either.
Rollout is an operations problem with a training component, not the other way round.
Pick one site and go properly
The instinct is to move everything at once so there is only one system. The better first step is the opposite: pick one client site, ideally a busy one with a coordinator who is not the most sceptical person in the office, and run it entirely in the new system. Roster, compliance, client access, the lot.
One site done properly teaches you more than five sites done partially, because partial use never surfaces the questions that matter. And a busy site is a better test than a quiet one, since a quiet site can be run on habit alone.
Set an end date for the spreadsheet
Parallel running is sensible for a week and corrosive after that. If the spreadsheet is still there in month two, it is the system of record and the software is a data entry chore.
Name the date the spreadsheet stops, before you start, and make somebody responsible for it. The conversation to have on that date is not are we ready, it is what specifically is still missing, because a vague sense of not being ready will last forever.
Train on your own data, not a sandbox
Demonstrations on sample data teach people what buttons exist. Training on your own workers, your own sites and your own requirements teaches them the job.
It also surfaces setup problems while there is still someone around to fix them: a competency named differently to how the site names it, a site requirement missed, a role that turns out to need its own list. Those are cheap to find in training and expensive to find at a gate.
Train the roles separately
The office, the crew and the client need different things and should not sit through each other's training.
The office needs a couple of hours: build a roster, fill an open shift, handle a blocked booking, run the expiry list. The crew needs about five minutes and it should be a message with pictures, not a session: here is where your roster is, here is how to set availability, here is how to put your hand up for a shift, here is how to upload a ticket. Clients need less than that: here is your login, here is your roster, here is how to ask for someone.
If crew training takes more than five minutes, that is worth raising with the vendor. Software that a casual workforce needs a course to use will not survive contact with a churning crew.
Expect the blocked booking argument
Somewhere in week one, the system will refuse a booking that a coordinator wants to make, and there will be a moment of genuine annoyance. How that moment is handled sets the tone for the whole rollout.
The right response is to look at why. Usually the block is correct and the paperwork is genuinely missing, which is the system doing its job on the first day. Occasionally the requirement is wrong and needs fixing. Either way, treat it as information rather than an obstacle, and say so out loud, because if the office decides the checks are the enemy they will spend the next year trying to work around them.
Give it a fortnight before judging
New tools feel slower for about two weeks, because familiarity is most of what makes a spreadsheet feel fast. Agree in advance that nobody makes a verdict inside that window, and then genuinely review it at the end: what is faster, what is slower, what is still missing.
Write the answers down. A review with specifics turns into a fix list. A review without them turns into a feeling.
Who to put in charge
One person, in the office, who owns the rollout and has the authority to change how things are done. Not the most technical person necessarily, but the one whose opinion the other coordinators actually take seriously. Rollouts run by the person with the most spare time rarely land.
The how it works page covers the setup we do at our end, and what to expect from implementation covers the timeline.