In this guide 6 sections
After go-live, the work shifts from building to running. Expect questions from staff, data corrections, a few small fixes and requests for change. Name one person who owns the system. Agree who to call for each kind of problem. Track a few simple measures. Batch change requests instead of raising each one at once.
The first two weeks are about use, not features
Go-live day is the start of the work, not the end. Staff will still reach for the old sheet or the old register out of habit. That is normal and should be expected.
Keep the old method switched off, or read-only, as soon as the new one is trusted. Two live systems make staff enter everything twice. Then the two disagree and nobody knows which is right.
Ask a manager to sit with each team for an hour in the first week. Watch what people actually do. Note where they hesitate, where they type the same thing twice and where they ask a colleague.
- One named person answers staff questions on the floor
- A short list of known workarounds, shared with all users
- A daily check that no one is using the old method
- A place to record every question asked
Expect data corrections and plan for them
Moved data is rarely perfect. Duplicate customers, wrong units and missing opening balances tend to appear once real users look at real screens. Treat each one as a correction, not a failure.
Decide who may correct data and how it is recorded. A small log works well. Note what was wrong, what it was changed to, who changed it and when.
Fix the cause as well as the entry. If staff keep picking the wrong customer, the search screen may need a change. If units keep going wrong, a default value may be the reason.
Know who to call for what
Agree this before the first problem, not during it. A problem with how to do something goes to the internal owner. A fault, such as a screen that will not open, goes to the vendor or support team.
A third kind of request is a change, such as a new report or a new field. These are not faults. They should go on a list and be decided together, not phoned in one by one.
Write the three routes on one page and pin it where staff can see it. Include phone numbers, working hours and the details a support person will ask for.
- How to do it: the internal system owner
- Something is broken: the support contact
- Something should change: the change list
- Wrong figure or record: the data log
Measure a few things, not everything
Pick three or four measures that show whether the system is being used. Examples are the share of orders entered on the day, the number of manual corrections each week and the number of support calls by topic.
Review them weekly for the first month and then monthly. A falling number of corrections is a good sign. A rising number of calls about the same screen points to a training gap or a design problem.
Avoid measuring everything. A long report that nobody reads is another unused screen.
When to ask for changes
Wait a few weeks before asking for large changes. Early requests often come from habit and not from need. By the fourth or fifth week, real patterns show which changes matter.
Collect requests in one list, with who asked, why and how often the problem occurs. Rank them by how many people are affected and how much work they cost today.
At about the 90-day mark, hold one review with the vendor. Go through the list, the measures and the open faults. Agree what changes next and what stays as it is.
First 90 days tracker
A sheet of one page with three columns for weeks one to two, weeks three to six and weeks seven to twelve. Each column lists the checks to run, the measures to record and the open questions. Keep the data log and change list stapled behind it. Review the sheet at each weekly meeting.
Open a blank worksheet to printQuestions owners ask
Should we run the old and new system together?
Only for a short, planned period, and only for the work that needs checking. A long overlap makes staff enter data twice and the two records drift apart. Set an end date before go-live.
Who should own the system inside the business?
One person who understands the daily work and has the authority to decide rules. It is often an operations or accounts manager. The vendor supports the system but the business owns its use.
Is it normal for staff to resist the new system?
Yes. People take time to trust a new way of working. Resistance usually falls when training is role-based, the old method is retired and managers use the new reports themselves.
When should we ask for new features?
After a few weeks of real use. Collect requests on one list and review them together. This avoids paying for changes that habit asked for and daily work does not need.