Measuring the Age of Open Callback Requests

Research question and evidence scope

How long does an open callback request wait before a documented attempt, a reschedule, or a close? The scope is the callback queue in one outsourced calling operation during a defined period, not an industry benchmark. The measure matters because an open request can look like routine work while the customer is still waiting for the conversation. The protocol describes the queue path rather than the quality of the eventual call.

This note does not decide whether the caller performed well or whether the customer was satisfied. Those questions require a wider review of call quality and staffing. The narrow purpose is to make the age and stage of open requests visible so the team can repair the handoff. Record the definition and the sample size beside the result so the review can be repeated.

The unit is one callback request, from the moment it is recorded through the first documented attempt or the close. A request that is rescheduled remains the same unit with an additional commitment. If a customer calls again and a new request is created, keep the new request separate and link it to the original. Keep the source reference with the observation rather than relying on a later summary.

Operating scenario and evidence

Start with a dated export of requests opened during the review window. Record the customer reference, the request time, the time zone, the owner, the channel, and the reason. Include requests that were closed during the window so the review can compare open and closed aging. Exclude test records and internal reminders that were never given to a customer.

A request begins when the caller records a specific need and a named owner. It closes when a documented attempt reaches the customer and the question is addressed, or when the customer agrees to a new time. A note that says the team tried once is an attempt, not a close, unless the customer later confirms the arrangement. State the observation window in the note so the reader can compare the next review.

Method and review criteria

Compute age in whole hours for same-day requests and in whole days for requests that cross a date boundary. Report the median, the 75th percentile, and bands such as under one hour, one to four hours, four to twenty-four hours, and over one day. Report the share with no attempt inside the promised window separately. Separate unavailable evidence from a confirmed negative before drawing a conclusion.

Split the age into queue wait, ownership wait, and attempt wait. Queue wait is the time before the request appears in the working list. Ownership wait is the time before a named person accepts it. Attempt wait is the time between ownership and the first documented call. The split shows whether the problem is intake, assignment, or coverage.

Each record needs the request text, the customer time zone, the owner, the attempt time, the outcome, and the next action. If the attempt was recorded after the fact, mark the time as reconstructed. A reconstructed time is weaker evidence than a system timestamp and should be reported separately. Name the owner of the next action so the finding does not become orphaned.

Authority and practical implications

Preserve reschedules and missed attempts. A request that moved three times has a different history from one that was attempted once and closed. Record the handoffs and the reason for each change rather than overwriting the original request. If the customer was not told about a change, record that gap as an exception.

When the queue is small, review every request. When it is large, use a documented sample and add a targeted sample of requests due outside normal hours, requests without a backup, and requests rescheduled more than once. Freeze the sample before collection and report any later expansion separately. Have a second reviewer check a small subsample and record disagreements.

The result can support a decision about staffing windows, the handoff rule, or the callback form. It cannot prove that the customer was satisfied or that the issue was resolved. Pair the timing measure with a sample of call outcomes and complaints before drawing a conclusion about service quality. Preserve the original record when a definition changes and label the transition.

Limitations, conclusion, and sources

Report open requests and missed windows separately, and keep the limitations beside the finding. The output should name one process change, one owner, and one recheck date. That is more useful than a single average that mixes routine callbacks with complex customer issues. Report the limitation in the same note as the result rather than a separate memo.

Run a baseline review, then repeat after any change to the callback form, the shift pattern, or the owner assignment. A weekly cadence is practical for a busy calling floor, while a monthly review may be enough for a stable team. Archive the export, the coding sheet, and the notes so another reviewer can repeat the measurement. Use the same unit and window in the next review so the results remain comparable.

Sources: FCC consumer guidance on unwanted calls; FTC guidance on the Telemarketing Sales Rule; NIST Privacy Framework; U.S. Small Business Administration guidance on managing business finances. Each source was checked on November 4, 2026 and is used for general operating context, not as a local performance benchmark. Record the definition and the sample size beside the result so the review can be repeated.