Days To Go Live

What it measures

For each customer that goes live in the period, the calendar days from the contract signature date to the go-live date — the first day the customer begins paying, or the contractual start date if it precedes first billing. Summed across all such customers and divided by their count, it captures how long, on average, the path from "signed" to "live and generating revenue" actually takes. It excludes time spent in the sales cycle before signature and any work after go-live.

Why it matters

Days to Go Live is the operational heartbeat of implementation and customer success. Every day between signature and go-live is revenue you have booked but cannot yet recognize, a deployment team that stays tied up instead of moving to the next account, and a customer whose enthusiasm is cooling before they ever see value. Long activation windows delay revenue recognition, cap how many customers each implementer can onboard, and raise the risk of early churn. Shortening DTGL pulls revenue forward, frees capacity to grow without adding headcount, and gets customers to their first win faster — which is the strongest predictor of renewal.

How to read it

Read DTGL as a trend, not a single number. Track it month over month and quarter over quarter: a rising trend means onboarding is slowing — look for the cause in team capacity, product complexity, training gaps, or technical blockers — while a falling trend signals you are getting more efficient. Pair the mean with the median, because a few painful enterprise rollouts can drag the average far above the typical customer experience. Above all, segment: if enterprise customers take 40 days and SMB take 8, a blended average hides both stories. Break DTGL down by deal size, product tier, region, and use case so you can tell whether a shift is broad or concentrated in one segment.

What good looks like

Watch-outs

• Mixing definitions of "go-live" across teams. Finance counts first billing, Product counts first feature access, and Customer Success counts "customer ready to use" — three different dates. Agree on one definition (typically first billable date) before anyone calculates DTGL, or the number means nothing.
• Reporting only the mean. A handful of slow enterprise rollouts can pull the average far above the typical experience. Always show the median alongside the mean, and report the distribution where it matters.
• Blending segments into one average. Enterprise implementations are naturally longer than SMB; a single blended number hides whether SMB onboarding is quietly degrading. Break DTGL out by deal size, product tier, region, and use case.
• Counting only successful activations without noticing the ones that never go live. If some signed contracts never activate, excluding them is correct for DTGL — but track that abandonment separately, or a falling DTGL might just mean your hardest customers dropped off rather than your process improving.

Worked example