Measuring the Time From Inbound Request to First Dial

Research question and evidence scope

When an inbound appointment request arrives, how long does it take before a caller first dials the number the prospect provided? The scope is one outsourced appointment-setting queue during a defined period, not an industry benchmark. The measure starts with the timestamp on the inbound request and ends with the timestamp on the first outbound dial tied to that request. It answers a narrow operational question: did the team act, and how long did the customer wait before the first attempt?

This review does not measure whether the prospect answered, whether the call produced an appointment, or whether the customer was satisfied. Those outcomes depend on the offer, the list, the script, and the skill of the caller, and each needs its own review. A fast first dial can still be a poor call, and a slow dial can still produce a good conversation. The purpose here is to separate timing from persuasion so each can be improved without blaming the wrong part of the process.

The unit is one inbound request that asks for contact, not one outbound dial and not one customer record. A person who submits two separate requests on different days creates two units, while a request that generates several attempts remains one unit with a first-attempt time and later attempts noted separately. Keep the original request identifier beside every attempt so the chain stays visible. This unit prevents a request with five retries from being counted five times in the timing measure.

Operating scenario and evidence

Begin with a dated export from the system that receives the request and a second export from the dialer or phone system that records outbound attempts. Include the request identifier, received timestamp with its time zone, source, channel, requested service, the number the prospect supplied, the assigned caller, the first dial timestamp, the outcome, and any suppression or blocked flag. Do not rely on a manually typed note as the only source for either timestamp. The two systems should be joined on the request identifier, not on a customer name that may repeat.

Define the request timestamp as the moment the system of record accepted the submission or the inbound call ended, and write that definition beside the result. An import time, a download time, or the moment a supervisor assigned the record is not the request timestamp. If the source system records only a date and no time, mark the interval as unverified rather than inventing a midday value. The same rule applies when the request arrives through a channel that batches submissions at the end of an hour.

Method and review criteria

Define the first dial as the first outbound attempt event in the dialer or phone system, not the first note that mentions a call. Record the timestamp with the same time-zone convention used on the request side, and keep the original zone visible when the two systems differ. A manual call from a mobile phone needs a phone-system record or a documented exception, because a typed time is weaker evidence. If no dial event exists, the request has no first-attempt time, even when a note says someone tried.

Classify each request before calculating any average. A request attempted inside the written window is on time, one attempted after the window is late, one with no usable number or a suppression block is blocked, and one with no dial event and no block is still open at the review cutoff. Report all four states with the same denominator so the on-time share is not inflated by quietly dropping the blocked records. Keep the window definition in the report, because a change from two hours to four changes every comparison.

Exclude test records, internal transfers, duplicate submissions from the same person for the same need, and requests the campaign was not permitted to call. State those exclusions in a short methods note and keep the excluded count beside the included count. A large exclusion group can hide a queue problem, so review a sample of excluded records before accepting the filter. Do not exclude a late request merely because the delay had an obvious cause; label the cause instead.

Authority and practical implications

Use only the fields needed to answer the timing question, and restrict access to the joined export. Request identifiers and call outcomes can be linked to a named person, so treat the working file as personal data even when the report itself is aggregate. Store it in an approved location, remove it when the review closes, and follow the organization's retention rule. These controls support the measurement without turning a queue review into a wider collection of customer information.

The result becomes useful when it names an owner for each delay pattern. A cluster of late requests in the first hour of a shift points to staffing or assignment, while a cluster of blocked requests points to the intake form or a missing field. A cluster of open requests at the cutoff points to queue capacity or an ownership gap between shifts. Give each pattern a named owner and a due date, and check whether the repair changed the next measurement.

Split the result by source, channel, hour of arrival, shift, and campaign when the groups are large enough to compare. A web form that arrives overnight follows a different clock from a phone request made during calling hours, and a small campaign may swing wildly on one record. Report the count in each split beside the rate so a group with four requests is not treated like a stable trend. Keep the splits stable across review cycles or label the change.

Limitations, conclusion, and sources

Report blocked requests as their own outcome rather than treating them as zero-minute failures or as missing data. A blocked request has a cause, such as an incomplete number, a duplicate, or an active suppression, and that cause is often more actionable than the elapsed time. Count how long each blocked request waited before it was routed to an owner. A blocked request that sits unresolved for two days is a queue problem even though no dial was possible.

Use a census for a small queue and a documented sample for a larger one. Freeze the selection rule before reading the records and report any request added after the cutoff separately. Oversample the first and last hour of each shift, because handoffs and closing routines are where timestamps are most likely to be missing or wrong. Have a second reviewer recompute the interval for a subsample and record every disagreement.

Reviewer disagreement usually comes from a different definition, not from arithmetic. Ask each reviewer to state which timestamp they used and whether they counted a blocked request. Compare the two coding sheets before discussing the cause of any delay. If the definitions cannot be reconciled, narrow the measure to requests with two clean system timestamps. A smaller, well-defined sample is more credible than a large sample with guessed times.

The measure has limits. System clocks can drift, a request may be legitimately held until the next permitted calling window, and a fast dial can still reach a number the prospect no longer uses. The result describes the queue that produced the export and does not prove that a shorter interval will increase appointments. Pair it with answer rates and appointment outcomes before changing a staffing plan. Keep those outcomes separate so a timing repair is not credited with a sales effect it did not cause.

Run the review after any change to the intake form, the dialer, the assignment rule, or the shift schedule. A monthly cadence suits a stable queue, while a weekly check may fit a campaign with frequent changes. Archive the exports, the coding sheet, the window definition, and the methods note so another reviewer can reproduce the result. Use the same unit and states next time so the comparison remains honest.

Sources: FTC guidance on complying with the Telemarketing Sales Rule; FCC guidance on telemarketing and the Telephone Consumer Protection Act; NIST Privacy Framework; U.S. Small Business Administration guidance on managing a business. Each source was checked on November 8, 2026 and is used for general operating context, not as a local performance benchmark. These references frame calling rules, privacy, and record-keeping expectations but do not validate any single queue's timestamps. Record the definition and sample size beside the result so the review can be repeated.