A single response-time number usually combines several systems and two different meanings. The first meaning is operational: how long did capture, validation, routing, and Delivery take? The second is human: when did a person first call, email, text, or otherwise respond? Your lead platform can prove the first path. It can prove the second only when the downstream system returns a genuine response event.

Start with one formula and name both events

Every duration follows the same formula: response time = end timestamp - start timestamp. The arithmetic is easy. The hard part is choosing events that describe what actually happened and come from a durable system of record.

Formulas for five distinct lead response time metrics
Metric Start End What it proves
Capture to Validation Intake accepted Validation Outcome decided Time spent producing the routing gate
Validation to first attempt Qualified outcome decided First Delivery attempt started Queue and Destination-resolution delay after qualification
Capture to first Delivery outcome Intake accepted First Delivery attempt reached a terminal outcome Pre-CRM handoff time for the first attempted Destination
Capture to first successful Delivery Intake accepted Earliest successful Delivery finished Time until one Destination accepted the handoff under your success rule
Human response time Intake accepted First verified human response Time until a person responded, if the downstream system supplies proof

These are related metrics, not interchangeable labels. If a dashboard shows "lead response time," its definition should appear beside the value. State whether the end event is a Delivery attempt, a successful Delivery, CRM assignment, or a human reply.

Give each timestamp one owner

Lead handoff timestamps, their system owners, and their limits
Timestamp System of record Required detail Does not prove
Intake accepted Lead intake platform Server-recorded acceptance after the payload reaches the Intake When the visitor began or submitted a browser form
Validation decided Validation workflow Outcome, completed time, and the checks used That a Destination received the Lead
Delivery attempt started and finished Lead delivery platform Destination, attempt identity, outcome, and retry relationship Downstream processing or human follow-up
CRM assignment CRM Assigned owner or queue and assignment time That the owner saw or answered the Lead
Human response CRM, dialer, phone, email, or messaging system Response channel, event time, and a safe correlation key Whether the response led to a sale

Salesforce documents that lead assignment rules assign Leads to a user or queue. That is useful ownership evidence, but assignment is still not a call, email, or conversation. Keep the CRM assignment duration under its own name.

Measure the controllable handoff in five stages

  1. Accept the Intake. Stamp the Lead when the server accepts the submission. Do not start the operational clock from a browser button click because browser retries, blocked scripts, and failed requests can create a time with no accepted Lead.
  2. Complete the Validation Run. Record when the overall outcome becomes qualified, review, blocked, or error. Provider latency belongs inside this stage. Review wait time should remain separately visible when a person must decide.
  3. Resolve enabled Destinations. In Lucidity's current default routing path, each qualified Lead is forwarded to every enabled Destination for its Business. Record the gap between the qualified outcome and the first Delivery attempt. If another system decides geographic or rep ownership, measure that downstream stage separately.
  4. Record every Delivery attempt. Give each attempt its own start, finish, outcome, and retry relationship. An HTTP 202 Accepted means a request was accepted for processing, but RFC 9110 says processing may not have completed.
  5. Import downstream response evidence. Use an actual call, reply, message, or equivalent event when the connected system makes it available. If it does not, stop the metric at Delivery and label that boundary honestly.

Carry one correlation key across the path

Timestamps are useful only when they can be joined to the same Lead and attempt. Preserve stable Lead, Validation Run, Destination, and Delivery identifiers at each boundary. For service-level tracing, the W3C Trace Context specification defines traceparent so systems can carry a trace identifier and parent relationship across requests. The OpenTelemetry tracing specification models operations with start and end timestamps and permits child spans for smaller stages.

A trace ID is observability metadata, not a replacement for durable business IDs. Traces may be sampled or retained for a shorter period than Lead and Delivery facts. Keep personal contact values out of trace names, attributes, and logs. Correlate with opaque identifiers instead.

Do not let retries rewrite the first attempt

A Lead may have several Destinations, and each Destination may have several Delivery attempts. Preserve every attempt. Report capture to first attempt, capture to first terminal outcome, and capture to first successful Delivery as separate measures. Overwriting the original attempt with a later retry erases the delay you need to diagnose.

Include failed and timed-out attempts in attempt-latency reporting. For time-to-success, show how many qualified Leads never reached success and do not assign them an invented duration.

Review and blocked Leads also need an explicit denominator. They did not enter the same qualified-to-Delivery population, so mixing them into that metric produces missing values with no explanation. Report Validation Outcome counts beside routing latency.

Use median and p90 instead of one average

An average can look healthy while a smaller group waits much longer. The median shows the typical observation, while p90 shows the duration that 90 percent of observations meet or beat. Google's Site Reliability Engineering guidance on service-level indicators recommends percentiles for skewed latency data because they keep the long tail visible.

Publish both numbers with the same population and window. For example: qualified Leads accepted from August 1 through August 7, measured from Intake acceptance to the first terminal Delivery outcome, median 18 seconds, p90 74 seconds, 412 included attempts, and 9 qualified Leads with no terminal outcome. Those values are synthetic examples, not Lucidity or industry benchmarks.

A response-time dashboard specification

Dashboard fields required for auditable lead response time reporting
Dashboard block Show Required filter or note
Population Accepted Leads and counts by Validation Outcome Business timezone, Intake window, and total denominator
Stage latency Median and p90 for Validation, routing queue, and Delivery Named start and end events for every stage
Delivery outcomes Success, retryable failure, terminal failure, and timeout counts Connector and Destination filters
First-success view Median, p90, successes, and qualified Leads without success State whether success is transport acceptance or stronger confirmation
Human response Median, p90, coverage count, and source system Only Leads with a verified downstream response event

Segment only where the result can change an operational decision. Business, Intake, Destination, Connector, Validation Outcome, and hour of day are common candidates. Always keep the unsliced total beside a segment so a tiny group does not masquerade as a broad trend.

Keep GA4 outside the operational timer

Lucidity Leads, Validation Runs, and Deliveries are first-party facts. GA4 supplies traffic context and may have different processing and reporting timing. Use it to understand acquisition, not to reconstruct whether a specific Lead passed Validation or whether a Destination received a Delivery. The GA4 data freshness guide explains how to label those sources separately.

Primary sources checked August 28, 2026

For the surrounding workflow, see the Lead Delivery software guide, the Lead routing best practices, and the Lead tracking software guide.

Frequently asked question

Which timestamps should be used to measure capture, validation, routing, Delivery, and human response?

Use the Intake acceptance time as the common start. End each first-party stage at its own durable event: Validation decision, first Delivery attempt start, first terminal Delivery outcome, or first successful Delivery. Measure human response only when the downstream CRM, dialer, phone, email, or messaging system supplies a real human-response timestamp. Never label assignment or transport acceptance as human response.

Measure the handoff before the CRM

Bring one Lead Intake and its enabled Destinations. See how Lucidity records Validation timing and separate Destination Delivery outcomes without calling a transport receipt a human response.

Request a response-time walkthrough