Time to value: the supplier's clock and the buyer's clock
A time-to-value promise needs two clocks: the supplier's, from contract to a usage milestone, and the buyer's, from agreed baseline to measured result. Write each with its start, stop, owner and report.
A time-to-value promise can reach a business case as a single number of days or weeks. The supplier may count the time until the software reaches an agreed usage milestone; the buyer can count until a report shows the agreed business target has been reached against its baseline. The two clocks can end far apart, and a promise that does not say which one it means can be read as the second and delivered as the first.
What a supplier's clock measures
GitLab publishes the clocks its customer success managers work to in its public handbook. Time to First Value runs from the original contract date to a First Value Date, with a goal of 30 days. The handbook's rule is that a customer "is considered to have met first value when at least 10% of their Production licenses are activated". Where licence data reaches GitLab's system, the date is set automatically when known licence utilisation "meets or exceeds 10%". Where it does not, the customer success manager enters the date "based on their best estimate".
That gives the supplier a named start, stop, target and owner. The automatic measure records licence activation, not whether the customer's costs, lead times or risks have moved.
In their annual reports, GitLab, Datadog and Okta use the phrase as a benefit or competitive factor in statements that do not say when the clock starts or stops. So when the phrase appears in a proposal, ask for the start event and the stop event before you read the number.
What the buyer's clock measures
Public benefits management gives the buyer's clock its form. The UK Infrastructure and Projects Authority's guide for major projects says benefits "should be measurable", and "if they cannot be measured they cannot be claimed as 'realised'". It calls the current level of performance the baseline and says the baseline "should be taken during project initiation so that performance is not impacted by any element of project implementation". Benefits are "typically measured during project delivery and after the project has closed", and a Benefits Owner takes "responsibility for ensuring the benefit is realised after delivery".
The guide gives each benefit a profile holding "the measure, baseline, target, frequency of measurement and associated risks", and a benefits report "produced at an agreed frequency" that compares "the baseline, target and actuals". It is written for government projects, and its fields make a ready form for a software buyer's clock.
Sales Engineering work in a complex sale starts from the same place: "What the change means for the customer’s business and which outcomes the economic buyer will commit to." How to agree the starting figure and the follow-up is set out in value-based selling before and after the sale: "The agreement names the baseline, the target, the report both sides will use and who runs it."
The two clocks side by side
The first clock can use supplier data where it is available; the second needs an agreed business measure and access to its results.
| Clock | Starts | Stops | Who keeps it | What the buyer can check |
|---|---|---|---|---|
| Supplier: time to first value (GitLab) | Starts Original contract date | Stops Known licence utilisation reaches 10%, or the customer success manager's best estimate | Who keeps it The supplier's customer success manager | What the buyer can check Licence activation in supplier data when available; otherwise ask how the date was estimated |
| Buyer: benefit realised (UK guide) | Starts Baseline taken at project initiation | Stops Measured result against the baseline reaches the agreed target | Who keeps it The buyer's Benefits Owner | What the buyer can check Baseline, target and actuals in a report at an agreed frequency |
A worked example, with invented figures
A business case for field-service scheduling software promises "time to value: 60 days". Written as two clocks, the promise becomes:
1. Supplier's clock. Starts on the contract date. Stops when 80 of the customer's 100 planners have scheduled at least one job in the new tool. Goal: 45 days. Kept by the supplier's customer success manager and reported weekly from product data.
2. Buyer's clock. Starts with the baseline the customer's operations analyst takes before rollout: an average of 2.4 visits per completed repair over the last six months. Stops when the monthly report shows 2.0 or fewer for three months in a row. Target date: six months after go-live. Kept by the customer's head of field operations.
The original 60-day promise names neither of these proposed targets. The supplier can commit to supporting the first milestone, but reaching it also depends on the customer's planners using the tool. The economic buyer can commit to the business outcome and a report that checks the second target.
What to check before you sign or send
1. Ask which clock the number refers to: use of the product, or a business result.
2. For each clock, write the start event, the stop event, who keeps it and the report it appears in. A stop event either side can observe is better than an estimate.
3. If only a usage milestone is offered, ask for the business number behind the product number, and for its baseline.
4. Agree the baseline and how it will be measured before the rollout affects the work. The business value assessment template has a place for it.
5. Put both clocks in the business case for the software purchase, with the buyer's clock as the one the case is judged on.
Sources
- Customer Onboarding (Time to Value metrics), Customer Success Management handbook. GitLab, undated.
- Annual report on form 10-K for the fiscal year ended January 31, 2026. GitLab Inc. (SEC EDGAR), 17 March 2026.
- Annual report on form 10-K for the fiscal year ended December 31, 2025. Datadog, Inc. (SEC EDGAR), 18 February 2026.
- Annual report on form 10-K for the fiscal year ended January 31, 2026. Okta, Inc. (SEC EDGAR), 5 March 2026.
- Guide for Effective Benefits Management in Major Projects. Infrastructure and Projects Authority (copy hosted by the Association for Project Management), October 2017.
Facts last checked on 5 November 2026.