What to Do in the First Week With a New System
The specific mistakes that make week one fail, and why the first week is a configuration problem rather than a training problem. What to decide before the switch, not during it.
The first week decides the project. Not whether the system is good, not whether the price is right, not whether the implementation was competent. Whether the new system is the enemy.
That verdict is formed fast and it is hard to reverse, and it is formed by the person who has the least context and the most to do: the counter clerk on a busy Saturday with a queue in front of them and a system they did not choose. If week one goes badly, that clerk will have an opinion about the new system for years, and the opinion will be accurate from their point of view, which is the only point of view that matters to them.
The argument of this article is that the first week is not a training problem. The counter clerk does not need persuading, or a manual, or a refresher. They need a system that is already configured the way the business works, so that the ordinary transaction happens without friction. Most week-one failures are configuration decisions that were deferred, arriving all at once on the busiest morning of the month.
How the verdict is formed
Take the constructed week in this article. Six working days, two counter staff, one manager, one owner: 2 plus 1 plus 1 is 4 people, across 6 days, so 24 person-days of first impressions.
On day three, in the constructed example, the counter raises 22 invoices. Six of them are abandoned before saving, which leaves 16, because 22 minus 6 is 16. Two of the 16 are duplicates of invoice numbers already issued that morning, so 14 are new records. The clerk's experience of the new system, on the busiest day of the week, is a queue of customers and 6 abandoned attempts.
Nobody will ever ask why the six were abandoned, and that is the problem. The reason is almost never ignorance. It is that something in the system does not match how the business works, and the clerk worked around it by not completing the transaction, and worked around it the same way four more times before lunch.
The decisions that belong before day one
Week one goes wrong on a small number of specific questions, and every one of them was answerable before the switch. This is the list worth working through in the week before, not on the morning.
Illustrative: the five decisions that decide week one
| The decision | The week-one failure if it is not made | What it costs to decide late |
|---|---|---|
| Who can void or credit an invoice | The clerk asks the manager, the manager is on the floor, the customer waits | Every void becomes a person-shaped bottleneck and the queue stops moving |
| What a discount needs, and who approves it | The clerk memorises the old rule and applies it in the new system | A silent, repeated breach of a control that nobody notices for a month |
| What counts as the end of a day | Two staff close differently and the numbers never add up | Day end stops being a comparison and becomes a reconstruction |
| Which numbering series is live | A test invoice and a real one share a series | The invoice numbers your accountant relies on stop meaning anything |
| What a recorded payment promise means | A customer says they will pay Friday and it is filed as a plan nobody works | Collections become a memory exercise with no owner and no queue |
One login for four people
This is the most common single week-one mistake and it is made to save ten minutes.
The constructed example has four people: two on the counter, one managing, one owning. In week one they share one login, because setting up four accounts with the right roles takes longer than sharing one password. The week works. Nothing breaks.
Then the first question about the week cannot be answered. If the counted cash is short, the system cannot say whose shift it was, because the record says the counter login. If a discount was applied above the threshold, the system cannot say who applied it. If a receipt needs a correction, the system cannot say who was on the machine. Every one of those questions is answerable from memory in the first week, and none of them is answerable in the third month.
The cost of four separate logins is an afternoon of setup. The cost of one shared login is that the system stops being able to tell you anything about the people using it, and a business that has bought a system in order to know things has given up the main thing it bought.
The specific mistakes that end week one
Switching on a busy day
The obvious one, and it is still common. A migration goes live on the first of the month because the books are clean on the first, and the first is also the day with the most deliveries, the most collections, and the most invoices.
Week one should be chosen for being ordinary. Not the first of the month, not the day of the largest order, not the day a supplier is coming. Pick a day where the business looks like the business on a normal Tuesday, because week one is when people learn what the ordinary transaction feels like, and the ordinary transaction is the only thing the system has to get right.
Training instead of configuring
The instinct is to send everyone a video. The effect is that a clerk can follow the demonstration perfectly and still be unable to raise a normal invoice, because the demonstration used a customer with one address and the clerk's customer has three, or because the item in the demonstration was taxable and the clerk's was not.
A demonstration teaches one path. Configuration supports all the paths the business actually takes. In week one the second one matters, and the cost difference is a week of setup against a year of workarounds.
Deleting instead of reversing
Somebody raises a wrong invoice in week one, and the instinct is to delete it. Deleting removes the record, and the number it used is gone, and now the sequence has a hole in it and nobody can say what the hole was for.
The reason reversal is the right answer is worth stating plainly, because it applies far beyond week one. When an invoice is wrong, the correction is a new document that undoes the first one: a credit note, or a reversal, that leaves the original readable. The books do this, and the reason they do is that a record which can be silently removed is a record nobody can rely on. The counter should follow the same principle, and a system that makes the reversal the natural action removes the temptation entirely.
Parallel running that quietly becomes permanent
The most expensive week-one outcome is not a failure. It is a success, of a kind, followed by the old system staying open because closing it was never scheduled.
The counter runs the new one because it is on the counter. The owner still keeps the old spreadsheet open on a laptop, because they are not yet sure. At the end of the month the owner reconciles by eye, which is fine at small volumes and impossible at scale, and at the end of the quarter nobody can say which system the report came from. Every migration that has failed has usually failed here first, and the fix is a date and an owner, agreed before the switch, which is what the cutover rule is for.
Why it is a configuration problem, not a training problem
Here is the test. Take each thing somebody got wrong in week one and ask whether a person chose to get it wrong, or whether the system asked for something the job does not know.
If a clerk applied a discount above the threshold because they were following the practice of three years, that is a threshold that was never configured. If a clerk could not find how to record a part payment, that is a workflow that was never set up. If the day-end figures do not add up because two people closed differently, that is a day boundary that was never defined. If somebody deleted an invoice, that is a system where reversing is harder than deleting. If two invoice numbers collided, that is a numbering series that included a test run.
Not one of those is a training failure. Every one of them is a decision that was available to be made in the week before the switch, and every one of them becomes dramatically more expensive to fix after the switch because after the switch the business has real transactions in the system.
There is one genuine training failure and it is worth naming so it does not get confused with the others: nobody agreeing who is accountable for the day. A manager who is responsible for the close needs to know it, need to know what the close produces, and need to know what to do with a variance. That is a conversation, and it belongs on the Friday before the switch, not in week three when the first variance appears and nobody is sure whether it matters.
What the records are doing in week one
Some of week one is simply the system doing what it says, and it is worth being clear about what that is, because several of these are different from what a spreadsheet does and the difference will confuse people in their first hour.
An invoice and a payment are different records. Paid is not a tick box on the invoice; it is what you get when you read the allocations against it, which is why a part-paid invoice and a settled one behave identically apart from how much is allocated. Somebody will ask about this in week one, because the old spreadsheet had a paid column, and the answer is that the column was always a summary somebody maintained by hand.
A payment promise is a record, not a plan. Somebody said they would pay on a date; that date is now a dated commitment with a person against it, which is a different object from a payment and behaves differently on a report. Expenses live in Nox-Billings only. Purchasing lives in the Commerce area. There is no timesheet record and no payroll module. There is no change-request record, no milestone record, no deliverable record, no contract editor and no e-signature, so a change of scope is a new quote raised against the same project, with its own number. NoxOrigin does not file GST returns or any other statutory return, so where a statutory rule matters the question goes to your own chartered accountant, not to the software and not to this article.
Before the switch, not during it (illustrative)
- One login per person, with roles configured, and a PIN at the counter where it is used.
- The void and credit thresholds written down, with the name of the person who approves each one.
- The day boundary defined in words the counter can repeat, and the same words on the wall.
- The live numbering series agreed, with test numbers issued before go-live rather than during it.
- The numbering series that must never be used again, listed, so nobody reuses it by accident.
- The invoice fields the business actually uses, configured, with everything else left alone rather than half-filled.
- A reversal path for a wrong invoice, demonstrated once, so deleting is not the obvious answer.
- A named owner for the day, and a named owner for the week-one review.
- The cutover date for closing the old system, agreed and written down, with a date and not an intention.
- The one number the business will look at on day seven, agreed in advance so the review has a subject.
Nobody forms an opinion about software by reading the specification. They form it on a Tuesday, in a queue, with four customers waiting, on the third day of a week they did not choose. That opinion is about whether the business has been thought about, and it is formed long before anybody reads a feature list. Everything in week one is decided before the switch. The switch just removes the option of changing your mind.
If the new area is a gate rather than a back office, the same first-week discipline applies to scan outcomes as to invoices. how QR ticket validation works
Frequently asked questions
How much training does a new system need in the first week?
Less than people expect, and none of it is the kind that prevents a failure. Almost every week-one problem is a configuration gap rather than a knowledge gap: a threshold that was never set, a workflow that does not exist yet, a day boundary nobody wrote down. Ask what the screen asked them that their job does not know, and the answer is usually a setup change worth making in an afternoon rather than a course worth booking.
Can our staff share one login for the first week?
It is tempting and it is a mistake that gets more expensive every week it survives. A shared login means the system cannot say whose shift a cash variance belongs to, who applied a discount, or who made a correction. Set up one login per person with the right role before the switch. Four logins is an afternoon, and it is the difference between a system that records your business and one that records that a machine was on.
What should we do about a wrong invoice in week one?
Reverse it rather than deleting it. A deletion removes the record and leaves a hole in the sequence that nobody can later explain. A credit note or reversal leaves the original readable and creates a new document that undoes it, which is the same principle the books use. If the system makes reversing harder than deleting, that is a configuration problem to fix in week one rather than a habit to correct in week six.
Should we run the old system alongside the new one in week one?
Only if the cutover rule says which system is the record and from what date, and the old one is closed on that date. Running both indefinitely is the most expensive possible outcome, because the business ends up reconciling by eye and nobody can say which system a report came from. If the old one is still open at the end of the month, that is a missed cutover rather than a cautious approach.
What about day-end close in the first week?
Do not make week one depend on it. Shift close and day-end reconciliation are assisted-setup maturity rather than self-serve switches, so their quality depends on having been configured and run for a while. Run the counter cleanly for a fortnight, then turn the close on. A close that works on day two has not been earned, and making the launch depend on it puts a fragile control under maximum pressure.
How do we know whether week one went well?
Agree the number before the week, not after it. Abandoned transactions, duplicate invoice numbers, corrections per day, and the one operational number the business watches are all candidates. In the constructed example above, 6 abandoned attempts out of 22 on a single day is the signal, and it is a signal about configuration rather than about the people who hit it.