Approval Wait Time in Executive Support: A Measurement Plan

Table of contents

• Question and method
• The four stages
• Why the start event matters
• What counts as decision-ready
• Open requests and censoring
• Denominator choices
• Report by decision type and approver role
• A reporting table
• Limits and ethical boundaries
• Sources
• Frequently Asked Questions

Question and method

Research question: How should an executive-support team measure the time a delegated request waits for an owner decision, so the result distinguishes a slow approval from slow preparation or slow execution?

This paper is a measurement design, not a study of observed approval times. It defines the events, fields, denominator, and reporting rules needed for an internal measure. It assumes the team records requests in a task system or shared queue rather than only in email.

Approval delay is a common source of friction in delegated work. The assistant prepares a decision-ready request, the owner is traveling or in meetings, and the task sits. If the team measures only total cycle time, the delay looks like an assistant performance problem. A stage-based measure locates the wait.

The four stages

Break an approval into four observable stages:

1. Request opened: the assistant records the need for a decision.
2. Decision-ready: the request contains the options, evidence, recommendation (if asked), and consequence of delay.
3. Decision made: the owner approves, declines, or requests more information.
4. Execution complete: the approved action is carried out and verified.

Approval wait time is the interval from stage 2 to stage 3. Preparation time is stage 1 to stage 2. Execution time is stage 3 to stage 4.

This separation is the core of the design. It prevents a slow owner decision from being averaged into the assistant's preparation time, and it prevents a fast decision from hiding a slow execution.

Why the start event matters

Starting the clock when the request is opened measures the assistant's preparation speed as well as the owner's wait. Starting when the owner first hears about the request verbally is not auditable. The defensible start is the moment the request becomes decision-ready and is delivered to the owner through the agreed channel.

Record both timestamps anyway. The difference between opened and decision-ready is a useful measure of queue preparation, especially when the assistant is handling many requests.

What counts as decision-ready

A request is decision-ready when it includes:

• the decision needed, stated as a question
• the options and their consequences
• the source or evidence
• the deadline and what happens if it slips
• the assistant's recommendation, if the owner has asked for one
• the approver and backup

If any element is missing, the request is not decision-ready. The owner may still decide, but the wait time should be attributed to preparation rather than approval.

Open requests and censoring

Some requests will still be open at the reporting cut-off. Do not assign them a wait time of zero. Report:

• Decided within the period: observed wait time.
• Open at cut-off: age at cut-off, with the request state.
• Withdrawn or superseded: excluded from the wait measure, with a reason.

This is a censoring problem. Dropping open requests biases the measure toward fast decisions. Treating them as infinite makes the average meaningless. Reporting age for open requests is the honest middle path.

Denominator choices

Possible denominators:

• requests that became decision-ready in the period
• requests decided in the period
• requests by decision type
• requests by approver role

Each answers a different question. "Decided in the period" excludes long-waiting requests and can flatter the process. "Became decision-ready in the period" includes open requests and requires censoring. For management, the second is usually more honest, provided open ages are reported.

Report by decision type and approver role

Approval speed varies by decision. A travel exception and a contract approval are not comparable. Group at least by:

• spend or commitment
• schedule or travel
• personnel or sensitive matter
• external communication
• scope change

Report by approver role rather than individual name in aggregate. The purpose is to route the fix: a backup approver may be missing, a decision may need a lower threshold, or the request format may be unclear.

A reporting table

The numbers are illustrative structure, not findings. An organization must populate the table with its own records and state the reporting period.

Limits and ethical boundaries

The measure can encourage speed at the expense of quality. Pair it with a quality check: the share of decisions reopened or reversed, and the share of requests returned for missing information. A fast approval based on an incomplete request is not a good outcome.

The measure should not be used to rank assistants on how quickly they obtain approvals. Owners control the decision. The assistant controls preparation and follow-up, which are separate measures.

The O*NET executive administrative assistant profile and U.S. Department of Labor hiring guidance provide role context. The NIST Privacy Framework is relevant when approval requests include personal or sensitive data; keep the request record minimal and access-controlled.

Sources

1. O*NET OnLine: Executive Administrative Assistants
2. U.S. Department of Labor: Hiring
3. Bureau of Labor Statistics: Occupational Outlook Handbook
4. NIST Privacy Framework
5. U.S. Office of Personnel Management: Delegation

Frequently Asked Questions

Does a faster approval mean a better process?

Not necessarily. A fast decision on an incomplete request can create rework. Measure approval speed alongside the rate of returned or reversed decisions.

How do we handle approvals given verbally?

Record the decision, the time, and the channel immediately. If the decision is material, confirm it in writing. The record should show what was approved, not just that a conversation happened.

Should the assistant follow up on open approvals?

Yes, on an agreed cadence with a next-check time. Follow-up should state the decision needed and the consequence of delay, not simply ask for an update.

Review cadence

A quarterly review should compare the same stages across requests and report the share that reached a decision without a second submission. If the approval stage dominates, test a decision brief with a clear recommendation and a named approver. If the request stage dominates, fix the intake form. Keep the stage definitions stable so the next review measures the same process.

A good review also records the requests that were withdrawn or never submitted. Those cases can reveal a process that is too expensive to use, which a completed-case median will never show. Count them separately and describe why they stopped. The distinction keeps the analysis honest about demand as well as delay.

Finally, keep the working file small. A stage-level summary, a short exception list, and the decision that follows are enough for the review. Do not publish the request content or the names of the people involved. The value is in the pattern and the next change, not in a complete archive of every approval.