Time to Value in SaaS: Formula, Examples and Incomplete Onboarding
By Ulas ArslanPublished Updated
Time to value measures the elapsed time between a defined starting point and a useful customer outcome. To calculate it, subtract the start timestamp from the timestamp of the first agreed value event. The hard part is choosing those events consistently and keeping customers who have not reached value in the report.
Choose the start before looking at the result
A self-serve product may start the clock at signup. A managed implementation may track time from contract start, kickoff or access readiness. These choices answer different questions. Pick one for the customer experience you want to measure and write the definition beside the chart.
For example, measuring from access readiness helps assess the guided setup itself. Measuring from contract start includes the customer’s earlier waiting time. Both can be useful, but combining them in one average makes comparisons hard to interpret.
HubSpot connects onboarding with reaching a first meaningful outcome. Use that principle to define a value event the customer recognizes, then document it in the onboarding checklist.
Define a value event that can be checked
For a reporting product, the event might be a customer-approved report used in a planning meeting. For a scheduling product, it might be the first valid schedule shared with the intended team. Choose one event for a specific use case instead of using the same generic activation label everywhere.
Keep the event timestamp and its evidence. If a customer confirms value during a later call, distinguish the date the useful result happened from the date it was recorded. That prevents a reporting delay from becoming an apparent onboarding delay.
A first useful output can happen well before the full business outcome. Record both when needed. Reducing reporting effort over a quarter requires more evidence than producing one accurate report.
Work through a simple calculation
Assume five fictional accounts all started on the same day and were observed for 14 calendar days. Three reached the defined milestone. The other two had not reached it by the reporting cutoff.
| Account | First value after start | Status at day 14 |
|---|---|---|
| A | 2 days | Reached |
| B | 4 days | Reached |
| C | 9 days | Reached |
| D | Not yet reached | Waiting for data approval |
| E | Not yet reached | Setup issue under review |
Report time and completion together
The mean time among completers is (2 + 4 + 9) ÷ 3 = 5 days. Their median is 4 days. The share of the full cohort reaching value within 14 days is 3 ÷ 5 × 100 = 60%. These are three different results and should be labeled separately.
A headline of “five-day time to value” would leave out the two accounts still waiting. A clearer report says: “Three of five accounts reached value within 14 days; the median among those three was four days. Two accounts remain incomplete.”
If the waiting accounts finish later, update the report for a longer observation window. Preserve the original 14-day result if you use it to compare onboarding cohorts. Never record an incomplete account as zero days; that would make failure to reach value look unusually fast.
Make cohort comparisons fair
Compare customers with similar use cases and implementation needs. A one-team rollout with no migration is a different task from a company-wide deployment. A shift toward simpler accounts can improve the overall figure even when the process has not changed.
Give every account the same chance to complete the measurement window. In a rolling report, a customer that joined yesterday has not yet had 14 days. Keep it in a pending observation group instead of comparing its result with an older, fully observed cohort.
Use one timezone for timestamps and state whether the report uses calendar time or working time. Calendar time captures the customer’s wait. Working time can help analyze delivery effort. Switching definitions between months creates a misleading trend.
Use the delays to choose an improvement
Break the elapsed time into a few observable stages: waiting for access, configuration, correction and customer acceptance. You do not need perfect time tracking to identify a repeated blocker, but you do need a consistent way to record it.
If most of the delay comes before access is approved, improve the access request and ownership. If customers complete setup but cannot produce a useful output, revisit the use case and guidance. Sending more reminder messages is useful only when it addresses the actual reason for waiting.
After a change, compare the next similar cohort with the earlier one using the same definitions. Read the time, completion rate and quality of the first outcome together. Keep longer-term adoption in a separate product adoption measure, so a faster first step does not stand in for sustained customer value.