Time to value (TTV) is how long a new customer takes to get the first result they bought your product for, counted from the day they sign. Until that day, the customer is paying for software that hasn't done anything for them yet, and every week of waiting is a week they can wonder why they bought it.
Measuring it takes one subtraction. Shortening it means knowing which stage the days go to, then going after the one you can finish without the customer's people. If you sell a CRM, an ERP or vertical software, that's getting their data out of the old system and into yours. If you lead onboarding, implementation or customer success, this number is yours.
How do you calculate time to value?
For one customer: time to value = date of first value − date the contract was signed. For your business: the median of that number across the customers who signed in a period.
Two choices decide whether the number means anything.
- Start at signature. Not at kickoff, and not at first login. The days between signing and kickoff are days the customer waits too. Start the clock later and you drop them from your own report.
- End at an outcome the customer would name. A first month-end close. A first report run on their own records. A first invoice sent from your product. Never "setup complete": setup is your milestone, not theirs.
Write both events down and keep them the same for every customer.
Why does one time-to-value number hide the problem?
Because three different things get folded into it.
The average. A few customers who take three times as long pull the average up, and it stops describing a typical customer. Amplitude's advice is short: "Track medians rather than averages since TTV distributions often have long tails."
The window. Measure last quarter's customers and you only count the ones who already got there. The slow ones are still onboarding, so they aren't in the number at all. Michał Chorowski puts it plainly: "shorter windows systematically exclude customers who need more time."
The mix. Some waits are about people. HubSpot's list of why onboardings stall starts with "unclear next steps, missing stakeholders, or an unresolved technical blocker that no one owns." Other waits are about data: the customer's records aren't out of the old system yet. In one total they look the same. They need different fixes.
How do you time each stage of time to value?
Log seven events for every new customer. Most teams already have the dates somewhere: the CRM, the onboarding project, the support ticket.
| Event | What marks it |
|---|---|
| Signed | The contract is countersigned. The clock starts here. |
| Kickoff | Your first working session with the customer's team. |
| Data received | The customer's export, files or access to the old system is in your hands. |
| Data loaded | Their records are in your product and the customer has checked them. |
| Set up and trained | Configuration is done and the people who'll use it have been trained. |
| Go-live | The customer's team does its real work in your product. |
| First value | The result they bought it for, like a first month-end close or a first report on their own records. |
The gaps between those events are your stages. The data work is the odd one out: it doesn't have to wait for kickoff. You can start the data work at signing and run it beside setup and training, so time it as its own track, from data received to data loaded. Go-live waits for whichever track finishes last.
Time to value, split into stages you can time
Time to value runs from contract signature to first value. After signing, the customer waits for kickoff. The data track runs from data received to data loaded and can start at signing. The setup track runs from kickoff until configuration and training are done. Go-live waits for the slower of the two tracks. Then the customer uses the product until first value.
For each stage, report three things every month: the median, the slowest quarter of customers, and how many customers are sitting in that stage today. Then look at the go-lives that ran late and ask which track they waited on. That's the stage worth fixing.
What does stage timing show? Brivity's numbers
Brivity, a real estate software company, timed its import: the turnaround from receiving a customer's data to uploading it into Brivity. It averaged 10.6 days. Brivity's story calls the import timeline the anchor the whole onboarding process was built around.
With Rubie, the import averaged 5.3 days, and average time to launch went from 30 days to 25. Brivity's story says the faster imports "directly translated to faster client launches."
About five days off the import. Five days off the launch.
Brivity: one stage got shorter, and so did the launch
Brivity's average import turnaround fell from 10.6 days to 5.3 days with Rubie. Its average time to launch fell from 30 days to 25 days.
Which stage should you shorten first?
The longest stage whose work doesn't need the customer's people.
Setup and training need their people in the room. Approvals need their people to sign. You can push on those, but you can't do them for the customer. The data stage is different. It needs the customer's data, not their time. The extraction, cleanup, mapping and loading can all be your work.
You can make the stage smaller, too: not every record has to move. ERP Research lists migrating everything as a mistake: "Dragging years of obsolete history forward inflates cost, slows load and clutters the new system." Agree with the customer on what moves before go-live and what can wait. Our onboarding guide has a way to decide what moves and what stays behind.
If your late go-lives keep waiting on the data track, that's the track we take on. Rubie gets a new customer's records out of the system they're leaving, even one with no API or clean export, cleans and maps them, sends anything doubtful to your onboarding team for review, and loads them into your product. No engineering time. In Rubie's data, migration timelines run 50 to 90% shorter on average. See how a Migration Playbook works.
Time to value FAQ
- What is a good time to value?
- There's no universal number. A product people can use the day they sign up and one that needs years of a customer's records first will never share a benchmark. The useful comparison is your own median, split by customer segment and by stage, and whether it's falling quarter over quarter.
- What's the difference between time to value and time to first value?
- Time to first value stops the clock at the first result the customer gets, like the first report run on their own records. Many teams use time to value to mean the same thing. Some teams also track time to full value, when the customer gets everything they bought.
- Is time to value the same as time to go live?
- No. Go-live is the day the customer's team starts working in your product. Value comes after, when that work produces the result they bought it for. Go-live is a stage to time, not the finish line.