The short version
- A go-live is a delivery milestone, not a business outcome. Ninety days later is when the truth is visible: either measurable numbers moved, or you bought software and a training session.
- Four changes should be visible by day 90: money moves faster (cycle times, days-to-invoice), work resolves with fewer human touches, the data has become trustworthy enough to run meetings from, and people live in the system because their job is easier there.
- Every outcome needs a baseline captured before the build. The most common reason a 90-day review fails is not bad numbers; it is that nobody wrote down the old numbers.
- Logins are a vanity metric. Measure records created per rep, pipeline updated without chasing, and whether the old spreadsheets actually got switched off.
- A flat day-90 review usually means a stalled rollout, not a failed one. Most stalled orgs we audit are rescuable with process and configuration work, not a re-implementation.
The Quietest Failure in Enterprise Software
Nobody writes a post-mortem for the implementation that technically succeeded. The system went live on schedule. Training happened. The go-live email had a rocket emoji. And ninety days later the sales forecast is still built in a spreadsheet, invoices still go out when someone remembers, and the only thing that measurably changed is the software line on the P&L.
That is the quietest failure in enterprise software, and it is common precisely because nobody is lying: the project team really did deliver what was scoped. The gap is that delivery metrics and business outcomes are different currencies. Scope delivered, tickets closed, and users trained are delivery metrics. The business bought something else: faster cash, fewer manual touches, numbers it can trust. Ninety days after go-live is when you find out which one you paid for - long enough for habits to form, short enough that nobody has rationalized the gap as normal.
The Four Changes That Should Be Visible by Day 90
Across our own builds, the outcomes worth reviewing sort into four buckets. Every number below is from our published, named case studies - not benchmarks, just proof that the buckets are measurable:
- Money moves faster. Some cycle between effort and cash should be visibly shorter: quote turnaround, lead response, days from work-done to invoice-sent. In our Texas oilfield field service build, invoicing moved four days faster because job data flowed to billing without rekeying - that is a day-90 number anyone can read off a report.
- Work resolves with fewer human touches. Routine volume should be leaving the queue without a person pushing it: deflected cases, automated follow-ups that actually fire, scheduling that does not need a coordinator. Our published Agentforce service build runs at 92% autonomous resolution; your target will differ, but the direction is the same - headcount effort per unit of work should be falling.
- The data became trustworthy. The test is behavioral, not technical: do managers run the pipeline meeting from the dashboard, or do they still ask someone to "pull the real numbers"? Field completeness on forecast-driving records is the measurable proxy - our California SaaS migration hit 92% record completeness, and that number is why the dashboards got believed.
- People live in it because their job got easier. Not logins - logins are attendance, not adoption. Records created per rep per week, stages moved without chasing, and the sharpest signal in every org we audit: whether the old spreadsheet was actually switched off. A shadow spreadsheet still breathing at day 90 is the team voting no.
Notice what is not on the list: feature counts, customization volume, number of automations shipped. Those are inputs. If an input did not move one of the four buckets, it was decoration.
The 90-Day Review: One Meeting, Four Numbers
The review itself is almost embarrassingly simple, which is why it so rarely happens. One meeting. For each bucket, two columns: the number before the build, the number now. The whole discipline lives in a single rule applied months earlier: capture the baseline before the build starts. The most common reason a day-90 review fails is not bad results; it is that nobody wrote down the old quote-turnaround time, so improvement is invisible and the conversation collapses into anecdotes.
When a number did not move, resist the two reflexive explanations (the users, the software) and look for the three culprits we find in nearly every stalled org we audit: no baseline was captured, so nobody can see the change that did happen; the process that was configured is not the process the team actually runs, so the system fights the work instead of carrying it; or no single person owns the number, so it is reviewed once and never again. All three are fixable without touching a line of the build.
When the Review Says "Stalled"
Here is the honest part, from a firm that gets called into these orgs: a flat day-90 review almost never means re-implement. Stalled and failed look identical in the monthly numbers and cost wildly different amounts to fix. Stalled means the platform is standing but the process, baselines, or ownership never arrived - and the fix is an audit-shaped project measured in weeks: reconstruct baselines from historical data, close the gap between configured process and real process, score data quality on the records that drive decisions, and hand a ranked punch list to a named owner. Failed means the foundation is wrong, and its tell is different: workarounds multiplying over time instead of shrinking.
We run exactly that audit as a fixed-price scope, including on orgs other partners built - the deliverable is the punch list, not a rebuild proposal, and plenty of audits end with "most of this is fine, fix these six things." If your go-live is a quarter or three behind you and the four buckets above have no numbers in them, bring what you have to a free scoping call - and judge us by the standard this post sets: our case studies publish the before-and-after numbers, named clients attached, because that is what a day-90 review should look like when it works. The broader practice, from new builds to rescues, lives at salesforce-consulting.