Set response-time standards your VA can actually meet

Define the clock that starts the measurement

A response-time standard needs a start event that everyone can see, such as the moment a message lands in the shared inbox. If the clock starts when someone notices the message, the measurement rewards attention rather than service. Write the start event, the working calendar, and the time zone into the standard. Then test the definition against last month's threads before publishing it.

Decide whether weekends, holidays, and client closures pause the clock. A standard that ignores the calendar will look excellent in December and terrible in January. Record the coverage window in the same place as the promise so a reviewer can calculate the target. When the client operates in another time zone, state which zone governs the clock.

Test the definition on one unusual week before you announce it. A holiday week, a product launch, or a billing cycle will show whether the clock behaves the way the client expects. Adjust the exclusions rather than explaining away the miss later. The published standard should survive the calendar, not ignore it.

Separate first response from resolution

First response proves that the request entered a queue, while resolution proves that the work is finished. Combine them into one number and the team will optimize the easy part. Publish two standards: an acknowledgement within the coverage window and a resolution target by request type. Put the owner and the next action in the acknowledgement so the client knows what happens next.

Some requests should never receive a fast resolution, such as a refund, a legal question, or a change to a contract. For those, the standard should require a fast acknowledgement and a named reviewer. Tell the client which categories work this way before the first request arrives. That distinction prevents an assistant from guessing just to hit a number.

Write one example of a good acknowledgement and one of a bad one. The good example names the owner, the next action, and the time of the next update. The bad example says only that the request was received. Assistants copy examples more reliably than they follow abstract rules, so the pair does more work than another paragraph of policy.

Group work by channel and urgency

A single inbox standard hides the difference between a chat message, an email, and a task-board ticket. Group requests by channel and by consequence, then set a target for each group. A password reset for a locked employee may need a faster response than a newsletter request. A client escalation may need an immediate acknowledgement even when the fix takes days.

Keep the number of groups small enough to remember, usually three to five. Give each group a plain name that the client and the assistant use in the same way. Publish examples for the boundary cases, such as a request that arrives by email but concerns an urgent customer issue. Examples reduce the daily argument about which clock applies.

Review the groups after the first month and merge any that produce the same behavior. A group that nobody can assign confidently is a source of delay, not a service tier. Rename the groups in the client's language rather than in internal shorthand. The client should be able to predict which target applies before sending the request.

Publish coverage windows with time zones

Write the coverage window in the client's time zone and the assistant's time zone, then show the overlap in plain language. State the handoff time when the primary assistant stops and the backup begins. Include the channel where urgent issues should go outside the window. A promise without a coverage window is really a hope.

Check the window against actual staffing rather than the contract's advertised hours. If the backup is unavailable on Friday afternoon, do not publish a Friday promise that depends on the backup. Review the window when a client adds a region, a shift, or a new channel. The standard should change when coverage changes, not after the first missed request.

Handle breaches with a named owner

Define a breach as a request that passed its target without a response or a documented next step. Route the breach to a named owner who can reassign work, adjust the client's expectation, or approve extra coverage. Record the cause in a short list such as volume, missing access, unclear request, or reviewer delay. A breach log without a cause becomes a scoreboard rather than a repair tool.

Tell the client about a breach before the client discovers it, especially when the delay affects a commitment. Use a short note that states what happened, what is being done, and when the next update will arrive. Do not promise a root cause before the review is complete. Honest timing protects trust better than a quiet recovery.

Review the breach log for breaches that were never visible to the client because the assistant fixed them quietly. A quiet fix is good service, but it can hide a capacity problem. Record the near-miss with the same cause code and review it alongside the visible breach. The pattern matters more than the individual save.

Review the standard against real volume

Once a month, compare the published targets with the actual arrival pattern and the actual staffing. If most requests arrive in a two-hour window, a standard that assumes an even flow will fail every morning. Shift coverage, batch low-priority work, or change the target based on evidence. The standard is a service promise, not a performance slogan.

Ask the assistants which requests consume the most time and which rules cause the most questions. Their answers usually reveal a missing template, an unclear owner, or a tool that forces extra steps. Fix the cause before tightening the target. A faster standard built on a broken workflow only teaches the team to cut corners.