How to Roll Out a New System So Your Team Uses It
A new system only pays off when your team uses it for real work, every day. The software doesn't decide that. The rollout does.
Who this is for
If you're replacing spreadsheets, paper or chat with a new system, this sequence helps you put it into everyday use. It's for the owner who needs the office, warehouse or crew to finish real work in the software, without asking you to explain every handoff.
Before you start
Before rollout, agree on the work the system will handle, who does each part and what a finished order or job looks like. You also need time for people to practice and someone responsible for problems, because sending out passwords doesn't tell anyone how their working day will change.
Prosci's ADKAR model for individual change names five elements: Awareness, Desire, Knowledge, Ability and Reinforcement. In plain terms: people need to understand why, want to take part, know how, be able to do it and have help keeping the change going.
I use that distinction here because a training session only covers part of the work. People also need a reason to change and a usable way to do their jobs.
Eight steps to put the system into daily use
Roll out the system around one piece of work that people can follow from start to finish. Give someone responsibility for the change, let the team practice, then make the switch clear. Keep checking the work after launch so problems get fixed instead of becoming reasons to reopen the spreadsheet.
1. Involve the people who will use it before it's built
Bring the people who touch an order into the conversation before the screens are decided. The warehouse knows what arrives without a label. The office knows which details customers leave out. You need those facts in the build, while changing the plan is still straightforward.
At Silla, I mapped every step from order to complaint with the people doing the work each day. Their old process included paper, Excel and another copy of the address in the courier's system. Those handoffs mattered as much as the order screen.
This week: Follow one current order with someone from each part of the business it passes through. Ask them to show what they actually do, including notes and messages. Ask what happens when a customer changes an order after packing has started. Write down who enters a change and who needs to see it. Give that list to the builder before approving the screens.
2. Name one internal owner and one place to report problems
Name one person inside the company to lead the rollout and give everyone one simple place to report a problem. That person keeps track of what is stuck, gets decisions made and follows up with the builder. They need room in their day to do it.
Choose someone who understands how work moves between people. They don't need to write code. They do need permission to ask for a fix, settle which record is right and bring a business decision to you. Agree which decisions they can make without waiting for you. Choose a backup for the days that person is away.
This week: Put their name on the rollout plan and choose one shared chat thread or issue list. Ask for the order or job number, what the person tried and what happened. Make sure the team can see whether the problem is waiting, being worked on or fixed.
3. Start with one flow or one team
Start with one complete flow or one team whose work has a clear beginning and end. For an order flow, that means following the order through its handoffs, not just entering it. Keep the first group small enough that you can watch the work and deal with problems.
The Government Digital Service's guidance for public services starts private beta with a limited group of users to gather feedback and make improvements. For your business, a small trial gives you a place to check whether people can complete the work before you add more users.
This week: Choose a flow, name the people taking part and define where it ends. Write down what must work before you expand: the order arrives, the next person sees it, the goods leave and the status is correct. Assign someone to check each handoff. Make the handoff to anyone working outside the trial explicit, too.
4. Train on real orders or jobs
Train each person by having them do their actual task in the system, with someone nearby to help. Watching a demonstration isn't the same as completing an order. Include an ordinary job and an awkward one, such as a changed quantity, missing item or return.
At Silla, packing requires scanning the correct model, color and quantity before the task closes. Training for that job needs to include what happens when the wrong item is scanned. A tour of the dashboard wouldn't prepare someone to finish packing an order.
This week: Choose real examples and agree with the builder how to practice without sending duplicate shipments or changing live stock by mistake. Let each person use the controls themselves. Write a short task guide using their own words. Keep the guide beside the workstation, where the person will need it. Finish by asking them to complete the task again without prompting.
5. Set a switch-over date and retire the old spreadsheet
Pick a switch-over date for the flow you're moving and say where every new order or job belongs after that point. If old and new records need a comparison period, make the overlap short and fixed. Give it an end date and name the record everyone should trust.
Keeping two live lists means every change needs two updates. If the records disagree, people start choosing whichever answer suits the task. At Silla, the team stopped using paper and Excel when the full operation went into use. Retirement of the old records was part of the change.
This week: Write the switch rule in plain language: new work goes here from this date; existing work finishes here; this person checks the transfer. Keep the old spreadsheet available for reference, with editing restricted after the overlap. Before switching, confirm that open orders and their current status are accounted for. Include canceled orders.
6. Leave room for rough weeks and fix problems daily
Expect the first weeks to need extra attention and review problems every working day. Separate something that stops an order from something that takes an extra click. Give the builder enough detail to reproduce the fault, and tell the team what to do while the fix is being made.
Agree before switching how the person leading rollout will reach the builder when work gets stuck. When I build for a business, I stay involved through rollout and troubleshooting. You still need someone inside the company deciding what takes priority and checking whether a fix works in practice.
This week: Set a brief daily review with the internal owner. Check blocked work first, then repeated errors, then small annoyances. For each problem, record who will act, the temporary way to finish the work and when you'll check again. Ask for screenshots where useful. Tell the person who reported it what changed.
7. Measure orders, errors and the time spent finding answers
Measure whether the work got easier using numbers the team already understands. Start with orders or jobs completed per day, errors that need correcting and time to answer a status question. Record a baseline before switching so you can compare real work, rather than count logins or completed training sessions.
The Silla case study shows orders rising from about 20 to about 90 a day with the same team. Packing errors fell from 3 to 8 a week to practically none. The team can see who packed each order and when. Status answers went from up to 15 minutes of searching to one screen.
This week: Record your own starting numbers and how you'll count them. Count completed orders, rather than orders entered. Check errors and missing records alongside output. If orders move faster but someone still keeps a private list to finish them, find out what the system is missing.
8. Keep improving as the business changes
Keep reviewing the system after people settle into using it, because the work will change. A new product, another supplier or a different approval rule can make yesterday's screen awkward. Give those changes a place to be discussed and decided before people build a workaround in a separate file.
My ongoing support and improvements are monthly. That gives the owner and team a way to keep working on what needs to change after rollout. Keep each proposed change tied to a task: which repeated step would disappear, which mistake would be caught or which answer would become easier to find?
This week: Start one improvement list with the internal owner. For each request, record who needs it, what they do now and what gets in their way. Separate faults from new requests. Use the monthly review to decide what to change and what can wait. Show people which requests were accepted.
What to do if the rollout goes wrong
When people return to the spreadsheet, follow one unfinished task with them and find the point where the new system stopped helping. A missing permission, wrong stock figure and unclear responsibility need different fixes. Keep the next group on hold until the first group can finish its work reliably.
If the problem is understanding, practice that task again. If a screen or record is wrong, have the builder correct it and let the person affected check the fix. If work cannot safely continue, agree on a temporary fallback, name its owner and record what must be transferred back. Give the fallback a review date so it doesn't become another permanent list. Most of the reasons software projects fail in small companies show up first as people quietly going back to the old file.
Give the team a way to work without you
A rollout should give people a way to finish work without routing every question through you. If you'd like to check that wider problem, the Business MRI is 10 questions, about 2 minutes, no email needed to see your result. It gives you a founder dependency score, your three weakest areas and a first move for each.