Measuring Assistant Turnaround Without Counting Owner Delay

Headline signal

A local measurement protocol, not a benchmark for any provider or country. (https://www.gao.gov/products/gao-20-283g). Treat this as context for planning, not a guarantee about a particular assistant or operating result.

Analysis and operating context

Turnaround time is the most quoted and least examined number in an assistant engagement. A report says a task took four days, and everyone assumes the assistant worked on it for four days. In practice the task may have sat for three days waiting on a price, a signature, or a file that only the client could provide. This protocol describes how to measure the portion of elapsed time that the assistant could actually influence, while preserving the full elapsed time for the owner's view.

The unit of observation is one task record from the moment it enters the assistant's queue to the moment it is accepted, returned, or abandoned. For each record, capture the entry time, the start time, every pause with its reason and owner, the resumption time, the submission time, and the acceptance time. Use one clock and one time zone, and record the system that produced each timestamp. If two systems disagree, keep both values and name which one governs the analysis.

Pausing is the central design decision. A pause begins when the assistant records a specific dependency and notifies the named owner, and it ends when that dependency is resolved. The dependency must be concrete: a missing document, an approval, a clarification, or an access grant. A pause for general workload is not an owner delay and should be classified separately. Without a written rule, pauses become a place to hide slow work, and the measure loses credibility.

Classify pause reasons before looking at outcomes. Suggested categories are owner decision, owner information, access grant, third-party response, system outage, and internal capacity. Keep a free-text note but require the category. Then compute three values per task: total elapsed time, owner-dependent time, and assistant-active time. Report all three. A single assistant-active figure invites the reader to forget that the customer experienced the longer total.

The population must be frozen before inspection. Define the task types, the clients, the channels, and the observation window. Exclude tasks that were cancelled before any work began, but count them separately so the exclusion is visible. Include returned tasks and reopened tasks; excluding them would remove exactly the cases where the brief or the handoff failed. Record the query date and the source export so a reviewer can rebuild the set.

Sampling should be stratified by task type, client, and outcome, because a queue dominated by simple calendar requests will look very different from one handling document production. Set the sample size in advance and disclose any subgroup with too few records for a stable estimate. Do not compare assistants on a combined rate without showing the mix. The purpose is to find design problems, not to rank individuals.

Reviewer calibration matters more than the arithmetic. Have two reviewers independently classify the pause reasons for a small set of records, then compare. Disagreements usually reveal an ambiguous definition, such as whether a question sent to a client counts as an owner delay or a third-party delay. Resolve the definition and rerun the calibration before the main sample. Preserve the initial ratings and the adjudication.

Report the median and the distribution, not only the average. A few tasks with a two-week pause can move an average far from the typical experience. Show counts beside percentages and include the number of tasks with no recorded pause. A high share of tasks with no pause may mean the pause rule is not being used, not that the queue is perfectly efficient.

Interpretation should stay conditional. A short assistant-active time with a long total time points to owner or access dependency. A long assistant-active time on a familiar task type may indicate a brief problem, a missing template, or a skill gap. A short total time with a high return rate suggests speed at the expense of completeness. Each pattern leads to a different correction, and none of them proves anything about a different client or a different month.

Limitations include incomplete pause logging, retrospective entries, clock drift between systems, and the temptation to classify an inconvenient delay as owner-caused. The method also cannot capture work that never entered the queue because someone decided not to delegate it. State these limits in the report and keep the raw records under the retention policy. The output is a better conversation about where time goes, not a single score that ends the conversation.

Apply this to a research support lane

Apply the pause rule to one client lane for four weeks before expanding the measure.

Sources

1. U.S. GAO, Assessing Data Reliability
2. NIST SP 800-53 Rev. 5, Security and Privacy Controls
3. UK ICO, Data Protection Principles

Frequently asked questions

Related research