The first thirty days of a rollout: what can actually be measured
A month is too short for a return on investment and quite long enough to know whether the rollout is heading the right way. What to watch so that you are not waiting six months for an answer you could have in four weeks.
Rollouts
In brief
- A month is too short for a return on investment and exactly long enough to know whether the rollout is heading the right way. Asking whether it paid off after 30 days is the wrong question.
- A baseline from before go-live cannot be reconstructed later. Two weeks of noting things by hand will do, as long as the definition of what you are timing is written down rather than remembered.
- Each week answers a different question: does it work, are people using it, where are they going around it, has the target number moved. Reversing that order kills projects early.
- Workarounds are the cheapest audit you will ever get. People go back to the old route because in that specific situation it is faster - and it is that situation that is the information, not the workaround itself.
- On day thirty, four things should exist: a baseline with definitions, coverage against the threshold you agreed, a list of workarounds with a reason for each, and one sentence about the direction of the target number.
- Reading time
- 6 min
- Length
- 1,173 words, 8 sections
- Updated
- 11 September 2026
Asking "did it pay off" a month after go-live is the wrong question. A month is too short for the effect to reach the bottom line, and just long enough for people to lose heart.
The right question is a different one: is this heading the way it was meant to head. After four weeks that answer already exists - provided somebody decided beforehand what to look for.
Set the baseline before anything changes
This is the one step that cannot be made up later, and the one most often skipped. Once you are live, nobody remembers how long handling a case really took before. Numbers appear from memory, and those are systematically too flattering.
Measuring before go-live does not have to be elegant. Two weeks of noting things by hand in a spreadsheet will do, as long as you note the same thing the system will later count. What matters is that the definition is written down: what exactly "handling time" means, from which event to which. Without that, the comparison a month later compares two different things and will support any argument you like.
Four weeks, four different questions
A rollout is not uniform. Each week answers a different question and is measured by something different.
- Week 1 - does it work at all. The only thing that matters is whether data goes in and comes out where it was supposed to. No conclusions about efficiency - everyone is still clicking more slowly than usual.
- Week 2 - are people using it. The proportion of cases that went down the new route, against all of them. This is the most important number of the whole month.
- Week 3 - where are they going around it. There are always workarounds. The question is whether they come from lack of practice or from the old route genuinely being faster.
- Week 4 - has the target number moved. Only now, and only as a direction, not as a result.
Reversing that order is the most common mistake. Looking at the target number in week one gives a reading that means nothing and can kill the project.
Workarounds are information, not misconduct
In every rollout, part of the team goes back to the old way. The natural reflex is to remind people of the procedure. That is usually a mistake, because a workaround is the cheapest audit you will ever get.
People do not bypass the system out of spite. They bypass it because in that particular situation the old route is faster, or the new one does not handle something. Take that literally and ask about a specific case rather than general impressions.
The gap between a question that gets you nothing and one you can act on is large. Here is the first kind:
How are you finding the new system?
And the same thing asked so that the answer is useful:
Three cases went the old way yesterday. Can we walk through one of them step by step and see at which point the new route was slower?
The first question gets you "fine" and no information. The second usually gets you something specific you can fix within the hour.
Three numbers that tell the truth early
Whatever the rollout is about, these three numbers are available from week one and they are honest.
- Coverage - what proportion of cases went down the new route. Rising coverage with a flat target number tells you the process works, but not where it hurts.
- Correction rate - how often a person corrects what the system proposed. Falling means it is learning in the right direction. Flat means the rules are not keeping up.
- Time to first action - from the event to the first response. This one reacts fastest of all, because it does not depend on how long the work itself takes.
The target number, the one that was the reason for the whole rollout, is worth watching but not worth drawing conclusions from before the second month. It carries too much noise and too few observations.
Scope that grows is not success
In week three a suggestion almost always appears: while we are at it, let us add one more process. That is the most common way a good rollout turns into a rollout without end.
A rule that holds up: until the first process is closed and measured, nothing gets added. Suggestions go on a list, the list is visible to everyone, and that is usually enough for nobody to feel their request was lost. Widening the scope before the first measurement takes away any chance of answering whether the first step worked at all.
What should exist on day thirty
Not a return on investment. Four things which together let you decide on the next step.
- A baseline from before go-live, written down together with its definitions.
- Coverage above the threshold agreed at the start, or an understanding of why it is not there.
- A list of workarounds with a reason beside each one, rather than a count of cases.
- One sentence about the direction of the target number, with an honest note that this is not a result yet.
If those four things exist, the decision about carrying on is easy, whether it comes out as "we continue" or "we stop". If they do not, another thirty days will explain nothing.
Where this sits in Omnira
You come in with one module, not a whole platform, and precisely for this reason: so that the first thirty days are about a single process that can be measured. Further modules add to the same organisational context, so the second step is shorter than the first.
If you have a process that eats more than it should, book a call. We start from what you measure today, because that decides whether there will be anything to compare against in a month.
Frequently asked questions
We have no baseline at all - is it too late? No, but say so out loud. The first two weeks after go-live are then spent building the baseline, and the assessment window shifts by those two weeks. Pretending you remember the baseline is worse.
What counts as good coverage after a month? There is no single number, because it depends on how many cases are suitable for the new route at all. The threshold is agreed with the team before go-live, and that matters more than how high it is.
Can that month be shortened? The measurement itself, no - it needs observations. What can be shortened is what comes before it: the narrower the first process, the faster it goes live and the cleaner the reading.
What if the number has not moved after thirty days? That is normal, and it is not an answer to the question of whether the rollout makes sense. The answer is coverage and the correction rate. If coverage is rising and corrections are falling, the number usually moves in the second month. If coverage is flat, the problem is elsewhere and a second month will not fix it.
