What to Measure in the First 90 Days of a New System

Adopting a new system is a decision that almost never gets reviewed. There is an evaluation before, an implementation during, and then silence. Three months later everyone is using it, and whether it helped is a matter of impression rather than evidence.

That is a shame, because ninety days is exactly the right window: long enough for the novelty to wear off, short enough that switching is still realistic.

Record the baseline before you start

This is the step that makes the rest possible, and it is the one always skipped, because at the point it must be done nobody is thinking about measurement yet.

Before anything is switched on, write down four or five numbers describing the current situation. How long it takes to produce a quote. How many enquiries get a reply within a day. How many hours a week go into a particular report. How many customer records exist, and how many have a valid email address.

The numbers do not need to be precise. They need to exist. A rough baseline beats an exact measurement of the new state with nothing to compare it against, which is the position most businesses find themselves in.

Measure the work, not the software

Every system reports on itself: logins, records created, features used, tasks completed. These are measures of usage, and usage is not benefit.

A team can log in daily, create hundreds of records, and be slower than before, because the tool has added administrative overhead that the reporting cannot see. High usage of a system that makes work harder looks identical to high usage of one that helps.

So measure the outcomes that existed before the system did. Time from enquiry to reply. Proportion of quotes that get followed up. Errors caught before a customer saw them. These are comparable across the change; internal metrics are not.

The three things that actually predict success

Does anyone use it when nobody is watching? Adoption during a rollout is compliance. Adoption in week nine is preference. If usage declines sharply once the attention moves on, the tool is not fitting the work, whatever the training records say.

Has the workaround disappeared? There was a spreadsheet, a shared document, a personal list. If it still exists in month three, the new system has been added to the process rather than replacing part of it — and the total work has gone up. This is the single most reliable indicator, and it takes one question to check.

Can somebody new be shown it in an hour? A system that only the people who configured it can operate is a dependency, not an asset. Test it with an actual new person rather than assuming.

Speed is worth its own measurement

If the system is one your customers touch, its responsiveness is part of what you adopted.

Web Vitals exists "to provide unified guidance for quality signals that are essential to delivering a great user experience on the web" [1], and the reason to measure it deliberately in the first ninety days is that a slow customer-facing system fails quietly. Nobody complains that a page took four seconds; they just do slightly less, and the effect appears as a small, unexplained decline in whatever the page was for.

Internal speed deserves attention too, for a different reason. A system that is slow to use will be used less carefully — records left incomplete, steps skipped — and the data quality problem that results will be blamed on the team rather than the latency.

Do not build a measurement apparatus

There is a failure mode where evaluating the new system becomes a project of its own: dashboards, weekly reporting, a set of indicators nobody agreed on.

Four or five numbers, checked at day thirty, sixty, and ninety, is enough. The rule that keeps this proportionate is the same one that keeps records usable — not gathering things speculatively "in case it is useful later" [2]. If a number will not change a decision, it does not need to be collected, and the effort of collecting it is a real cost charged against the thing you were trying to evaluate.

Know what leaving would cost, while you still might

Ninety days is the last moment when reversing the decision is straightforward, so it is worth knowing the terms while the question is still live.

Two facts are worth having written down. What the cancellation terms actually are — ours are cancellation at any time, taking effect at the end of the current billing period [3], and the equivalent for any system you adopt should be that specific. And whether you can get your data out in a usable form, tested by actually running the export rather than reading about it.

Doing this at day ninety, when there is no crisis, takes an hour. Doing it at month eighteen, when there is one, is a different experience entirely.

Expect the dip, and do not misread it

One pattern is consistent enough to plan for: things get worse before they get better, and the trough arrives around week three.

The first fortnight is usually positive. Attention is high, someone is helping, the novelty carries people through the awkward parts. Then the support recedes, the real edge cases start arriving, and the team hits the parts of the system nobody configured because nobody anticipated them. Productivity dips below where it was before the change.

This is normal and it is also the moment most rollouts are judged, because it is when complaints peak. A business that reviews at week three concludes the system was a mistake. A business that reviews at week twelve sees a different picture entirely.

The useful discipline is to decide in advance what would constitute genuine failure as opposed to the expected dip. A trough that recovers by week six is adoption. A trough that is still there at week ten is a real problem, and the distinction is only visible if you measured the baseline and agreed the timeline before the discomfort started.

The review itself

Book it before you start, with a date and the people who will attend. Reviews that are not scheduled do not happen, because at ninety days everyone is busy with the next thing and the system is working well enough.

Ask three questions. Did the baseline numbers move? Did the workarounds go away? Would we choose this again knowing what we now know?

The third question is the one that matters, and the honest answer is often "yes, but we would configure it differently" — which is worth acting on immediately, while changing it is still cheap.