How much of an assistant's week goes to unplanned requests?

Question and scope

This review asks how much of a virtual assistant's working week goes to requests that were not on the plan. The unit is a task that enters after the day or week has been scheduled and displaces planned work. The scope covers recurring administrative and support roles where the assistant serves one client or a small client group. The review does not estimate a universal percentage, because the mix of planned and unplanned work varies by role, season, and client.

The question matters because unplanned work is usually invisible in a task list. A completed queue can look healthy while the assistant absorbed a stream of interruptions that pushed the real priorities to the evening. The review treats that hidden load as a capacity and design issue rather than a personal failing. The goal is a measurement a manager can reproduce.

Two definitions keep the count honest. Planned work is a task that appeared on the approved queue or schedule before the day began, while unplanned work is a request that arrived later and required action that day. A request that arrived late but waited until the next day is deferred work, not necessarily an interruption. The distinction prevents the log from counting the same task twice.

A role with a fixed daily queue behaves differently from a role that covers a shared inbox. Measure the queue role and the inbox role separately before comparing them. The mix of channels changes the interruption pattern more than the job title does. A buyer should not generalize from one role to another.

Why unplanned work is hard to measure

Most task systems record the work that was completed, not the work that arrived and was refused or delayed. A request handled in a chat thread may never appear in the queue at all. That gap makes the planned list look cleaner than the real week. A useful measure has to start from the channels where requests actually appear.

Assistants also absorb interruptions without labeling them as work. A quick question, a file resend, or a clarification call can take four minutes each and still break concentration for twenty. The cost is not only the minutes but the restart time that follows. A log that records only duration will understate the effect on planned tasks.

Cross-channel work is the hardest to see because each tool keeps its own history. A request may start in email, move to chat, and finish in a task system. The log should record the source that started the work and the channel where it was completed. Otherwise the same request appears twice or disappears between the tools.

What time-use and work-context evidence can show

The American Time Use Survey provides a national picture of how people spend time across work and non-work activities. It can show that work is fragmented and that some tasks cluster at particular times, but it does not measure one assistant's queue. The survey is useful for framing the question, not for setting a target. A buyer should read it as context rather than as a benchmark for an individual.

O*NET work-context data describes the conditions of an occupation, including the importance of interruptions and the pace of work. That description supports the claim that responsiveness is part of many administrative roles. It still cannot say how many interruptions a specific client creates. The individual estimate must come from the assistant's own log.

Use public evidence to justify why the measurement is worth doing, then replace it with local data for any decision. A manager who quotes a national average to demand a specific capacity change will usually lose the argument. A manager who shows four weeks of local logs can make a targeted fix that the assistant recognizes as fair. State the source and the limit beside every external number.

Build an interruption log from real weeks

Ask the assistant to log every request that arrives outside the planned queue for four normal weeks. Record the time, the requester, the channel, the action taken, the time spent, and whether planned work moved. Keep the log to a simple form so it does not become another interruption. Four weeks is usually enough to see a pattern without creating logging fatigue.

Include the requests that were handled in under two minutes, because they are the easiest to miss and the most likely to break focus. Group them by requester and channel at the end of the week. The pattern often shows that one client or one chat channel produces most of the churn. That finding is more actionable than a single total.

Keep the log in a tool the assistant already uses so it does not become a second job. A form linked from the task queue is better than a separate spreadsheet that has to be remembered. Review the first week together and fix the fields that are hard to complete. The log should take seconds per entry, not minutes.

Separate necessary responsiveness from avoidable churn

Not every interruption is waste. A customer escalation or a time-sensitive approval may be exactly the work the role exists to absorb. Mark each logged request as necessary, preventable, or duplicate. Necessary requests belong in the capacity plan, while preventable ones point to a missing brief or a broken tool. The labels turn a count into a decision.

Preventable churn usually has a small set of causes, such as an unclear form, a missing status update, or a requester who does not know where to ask. Fixing one cause can remove a recurring category of requests. The goal is not to make the assistant unreachable. The goal is to keep the interruptions that add value and remove the ones that only repeat information.

Turn the finding into a capacity decision

Compare the unplanned hours with the planned hours and the available hours for the same weeks. If unplanned work consumes a fifth of the week, then the queue was planned against a week that did not exist. Adjust the plan, the staffing, or the service promise rather than asking the assistant to absorb the gap silently. Capacity math should include the interruption allowance.

Decide which requests need a faster channel and which can wait for the daily queue. Publish the response expectation for each channel so requesters know where urgency belongs. A named channel for urgent work reduces the tendency to mark everything urgent. The plan should also say who covers the urgent channel when the assistant is away.

Recheck the interruption allowance after the change rather than treating the first estimate as permanent. A new client or a seasonal peak can shift the mix within a few weeks. Compare the same measures and adjust one variable at a time. A capacity plan that is reviewed on a schedule stays useful after the original project ends.

Method and limitations

This review describes a measurement method rather than a study of a specific provider or team. The public sources are national or occupational descriptions, and their definitions may not match a given role. The local log is self-reported unless it is paired with system timestamps. A manager should state those limits when presenting the result.

Interruption logging can change behavior while it is happening. Assistants may record more carefully or requesters may route work differently because they know the log exists. Treat the first week as a settling period and compare later weeks with the same method. Do not use the log as a performance score, because that would encourage under-reporting.

Decision checklist

Confirm the definition of planned and unplanned work, the logging period, and the channels included. Check that the log captures short requests as well as long ones. Review the pattern by requester and channel rather than only by total. Agree on one cause to fix and one capacity change to test.

Set a review date and compare the same measures. Ask the assistant whether the change reduced the load or merely moved it. Keep the log until the next review and then retire it if the question is answered. A measurement that never ends becomes a burden that the team learns to game.