Inbound lead response time is often presented as a simple fact: the team took twenty minutes, or two hours, or a day. In practice the number is the output of several decisions that are rarely written down. When the decisions change, the number changes, and the argument becomes about performance even though the disagreement is about definitions.

This paper sets out a measurement protocol for inbound response time in a business-to-business sales operation. It treats the clock as an event model with a declared population, calendar, and treatment of missing data. The protocol is for analysts who need a number another analyst can reproduce, not for public ranking of teams.

Contents

The measurement question

"How fast do we respond?" is not measurable because it names no event, population, or clock. A measurable version is: for inbound leads created through the website form between two dates, what was the elapsed business time between server receipt and the first qualifying outbound contact, and what share had no qualifying contact by the end of the observation window?

That question contains five commitments: source boundary, population, start event, stop event, and observation window. Each can be checked. A report that omits one is not necessarily wrong, but it cannot be compared with a report that makes a different commitment.

The protocol also separates a measure from a target. A target is a management decision about the service level the team intends to provide. A measure is an observation about what happened. Confusing the two produces reports that exclude the leads that missed the target, which is the population the target is meant to influence.

Define the start event

The start event should sit where the lead becomes actionable. For a web form, that is server receipt, not the time the lead appears in a representative's inbox. Mail transfer, spam filtering, and CRM sync can add minutes or hours that belong to the system rather than to the representative.

For a phone enquiry, the call log creation time is usually the earliest reliable event. For chat, the first message. For a purchased or event list, the import completion time, because the lead was not actionable before the list entered the system. For a partner referral, the referral record creation time, not the date the partner says they sent it.

Each choice needs a rationale and an owner. Server receipt is preferred for forms because the receiving system generates it and it is harder to edit. If the form vendor or CRM integration changes, the timestamp semantics can change without notice, so the owner should confirm that the event still means what the protocol says.

Define the stop event

The stop event is harder because it involves judgment about what counts as a response. An automated acknowledgement is not a response. A marketing email is not a response unless a person wrote or approved it for that lead. A call attempt with no message may or may not count, depending on the channel and the team's definition.

A defensible definition has three parts: activity type, direction, and minimum content. For example, an outbound call with a voicemail that names the reason for the call and offers a next step, or a personally addressed email that references the enquiry and proposes a specific time. Two or three examples let a reviewer classify edge cases consistently.

Record the stop event as a structured activity rather than inferring it from free text. If the only evidence is a note that says "called", the measurement depends on reading prose and on the representative's willingness to log. The protocol should also name which roles can stop the clock and record the actor on the activity.

Put every timestamp in one reference frame

Timestamps arrive from several systems, often in local time with unclear offsets. Store every event in UTC and keep the original value and offset in the raw extract. Convert to a display time zone at the reporting layer, never in the stored data.

This matters around daylight saving transitions. An hour that does not exist or occurs twice can produce a negative elapsed time, a duplicated event, or a lead that appears to be answered before it arrived. The IANA Time Zone Database is the maintained reference for offset rules and should underpin the conversion library rather than a hard-coded table.

Publish the time zone used for business hours and the version of the rules used in the calculation. Regional calendars can differ, but the underlying event times stay in UTC. A report that mixes local timestamps without offsets cannot be reproduced.

Separate routing delay from selling delay

A total response time combines at least two processes: the time to assign a lead to an owner, and the time for that owner to make a qualifying contact. The two have different causes and remedies. Reporting only the total makes the diagnosis ambiguous.

The protocol should capture the assignment timestamp and compute two intervals. The first runs from the start event to assignment. The second runs from assignment to the stop event. A routing change should move the first; a workload or notification change should move the second.

A third interval is easy to miss: the gap between assignment and the representative's awareness of it. If assignment happens in the CRM but the notification arrives in a next-morning digest, the representative is accountable for a delay they could not see. Capture an acknowledgement event where the system supports one, or state the limitation.

Handle business hours without hiding nights

Many teams report response time in business minutes, which reflects staffing but can conceal a lead that arrived on Friday evening and was answered on Monday. Elapsed wall-clock time is large while business time is small.

Report both. Wall-clock time captures the buyer's experience. Business time captures the service level within declared hours. A weekend wait is not necessarily a failure, but the buyer experienced it, and the report should show it.

The business calendar needs a version and an owner. Working hours, regional holidays, and exceptional closures should be stored as data rather than embedded in a formula. A useful convention is to publish median wall-clock time, median business time, and the share of leads arriving outside business hours. The third figure explains why the first two diverge.

Treat missing timestamps as evidence

Missing data is common. A lead may have no assignment timestamp because routing failed. A representative may have called without logging an activity. A form may have used an older endpoint that did not capture server time.

Classify missing data rather than dropping it. Distinguish leads with no stop event, leads with no start event, and leads with an implausible sequence, such as a stop before the start. Each class has a different implication and should appear in the report.

Dropping incomplete leads biases the result toward leads that were measured successfully, which are often the ones handled promptly. Report the count and share of incomplete records and, where possible, the direction of the likely bias. The NARA records management policy is written for federal records, but its central idea transfers: a dataset that is overwritten each month cannot support a year-over-year comparison or an investigation of a disputed lead.

Report denominators and censoring

Every report needs a denominator: the number of leads that entered the population during the period, not the number successfully measured. Leads still open at the end of the observation window are censored and should be reported as open rather than excluded.

Censoring matters when the window is short. If a report is produced weekly, leads that arrived on Friday and had not been answered are censored. Excluding them makes Friday look better than it was. Including them as open preserves the information.

State the treatment of duplicates, tests, and disqualified enquiries. Each exclusion needs a reason code and a count. An exclusion that cannot be counted was probably applied by hand and cannot be reproduced. A compact table is enough: period, population, measured, censored, excluded by reason, median wall-clock, median business time, and the share answered within target.

Test the clock before trusting it

Before the measure enters a management review, run a reconstruction test. Select a small sample of leads, trace each through the source systems, and compare the computed intervals with the raw events. Include a lead that arrived outside business hours, one that was reassigned, one with a missing activity, and one answered by someone other than the assigned owner.

This is not statistical validation. It is a check that the pipeline and the definitions agree. Most errors found here are integration errors: a field mapped to the wrong timestamp, a time zone applied twice, or a status filter that removes the leads the report is meant to count.

Document the cases and the result. When a system changes, rerun them. A clock that has not been reconstructed after an integration change is an assumption, not a measurement.

Limits of public benchmarks

Public material on sales response often presents a single number, such as the share of leads answered within an hour. Such figures can frame a conversation, but they should not become a target or evidence about a specific team. The population, start event, and stop event behind a public number are usually not comparable with a local process.

The BLS occupational outlook describes the broad role of sales representatives rather than response-time performance, and the SBA management guide describes general operations rather than sales service levels. Neither supports a specific response target. Local targets should follow from staffing, buyer expectations, and the cost of a missed lead.

External context is most useful for challenging assumptions. A team that adopts a benchmark without measuring its own baseline has skipped the step that makes the benchmark meaningful.

Sources

  1. IANA Time Zone Database. https://www.iana.org/time-zones
  2. NIST Cybersecurity Framework 2.0. https://www.nist.gov/cyberframework
  3. NIST SP 800-53 Rev. 5. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
  4. Microsoft Work Trend Index. https://www.microsoft.com/en-us/worklab/work-trend-index
  5. Asana Anatomy of Work. https://asana.com/resources/anatomy-of-work-hub
  6. U.S. Small Business Administration, Manage your business. https://www.sba.gov/business-guide/manage-your-business
  7. U.S. Bureau of Labor Statistics, Wholesale and manufacturing sales representatives. https://www.bls.gov/ooh/sales/wholesale-and-manufacturing-sales-representatives.htm
  8. National Archives, Records management policy. https://www.archives.gov/records-mgmt/policy