Time to First Repeat Behavior: Why Your Onboarding Metric Is Lying to You

Most SaaS onboarding operations run on a single headline metric: Time-to-Live. Days from contract signature to the customer using the product. It is easy to measure, it is easy to report, and it is the wrong thing to optimize.

Time-to-Live measures one thing well: how quickly your team finished configuration. It measures nothing about whether the customer experienced value. You can drive Time-to-Live down to five days with hyper-efficient implementation and still produce a churn-prone customer base — because "live" is a statement about your team's task completion, not about the customer's success.

This post argues for a different primary metric, explains how to find yours, and is honest about the fact that adopting it will make your numbers look worse before they look better.

The metric that actually predicts retention

The metric is Time to First Repeat Behavior — TTRB. It asks: how long from the customer's first day on the product until they perform a specific, defined, in-product action for the second time?

The repeat is the entire point. The first time a customer does something, it is novelty — they were guided to it, or they were curious. The second time is the beginning of a habit. The third time is the beginning of dependence. A customer who has done the meaningful thing twice, the second time unprompted, is a fundamentally different retention prospect than a customer who did it once during a training call and never again.

Time-to-Live cannot see that difference. TTRB is built around it.

Finding your TTRB candidate

Every SaaS product has a TTRB candidate action. The right one meets four criteria. It requires the customer to have completed the core configuration, so it sits past technical setup. It is voluntary — not forced by the onboarding flow itself. It correlates with retention in your historical data. And it is observable in your product analytics.

What this looks like varies sharply by product. For a CRM, it might be the second time the customer logs an activity against a deal they created themselves rather than imported. For a workflow tool, the second time they publish a workflow to real users rather than a draft. For a monitoring tool, the second time they respond to a triggered alert. For a collaboration tool, the second time they create something jointly with another user. What these share: the action is observable, it requires the product to have real value rather than merely be configured, and it reflects genuine workflow use rather than test use.

The exercise to identify yours is concrete. Take your last 100 retained customers and your last 100 churned customers. Look at the in-product actions each took in their first 30 days. The action whose presence in the first 30 days most strongly correlates with one-year retention is your TTRB candidate. You are not guessing — you are reading it out of your own data.

Designing onboarding backward from TTRB

Once you have a defined TTRB, every onboarding stage gets a sharper job, because every stage's purpose becomes the same: move the customer closer to the second repeat behavior.

This produces an onboarding flow that looks different from configuration-led onboarding. Kickoff focuses first on identifying who at the customer will actually perform the target behavior and what motivates them — before configuration is even discussed. Configuration is scoped to the minimum required to enable the target behavior, with optional features deferred rather than front-loaded. Activation is measured against the first occurrence of the target behavior. Adoption explicitly tracks the second. And steady-state is not declared until the customer has performed the target behavior at the expected frequency for two consecutive weeks.

A useful planning rhythm inside this design is the 14-30-60-90 framework. By day 14, the customer has completed enough configuration to perform the target behavior, and has performed it once with team guidance. By day 30, they have performed it twice — once guided, once unprompted — which is the real activation milestone. By day 60, they are performing it at the expected frequency, so adoption is genuine rather than theatrical. By day 90, their usage pattern matches that of your retained-customer cohort, and the CSM can hand off to Account Management with confidence. Every one of those milestones is defined by customer behavior, not by your team's task completion. That is the whole shift, in four dates.

The part nobody warns you about

Switching your primary metric from Time-to-Live to TTRB has four consequences, and the first one is uncomfortable enough that some teams abandon the change before the others arrive.

Reported onboarding times go up. Not because anything got slower — because what you were previously calling "complete" was not complete by the honest definition. The new, larger number is the same reality, finally measured properly. A leadership team that is not warned about this will read it as a regression.

Early churn drops, within about two quarters. Customers who were never going to retain used to be quietly labelled "onboarded" and then discovered as a problem at renewal. Under TTRB they are caught inside the onboarding window, while there is still time to act.

CSM capacity feels tighter for a month or two, then loosens. The team stops pouring effort into customers whose churn was already inevitable and redirects it to customers still genuinely in play.

Renewal forecasts get more accurate, because TTRB is a stronger predictor than activation, and expansion conversations land better because they are timed to real readiness rather than a calendar date.

The honest summary: the shift is uncomfortable for one to two quarters, because the metrics get worse before the reality gets better. Then it becomes obviously correct, and going back feels unthinkable. Most metric changes are cosmetic — they rename what you already track. This one changes what the team optimizes for, which is the only kind of metric change worth the disruption.