Decide which VA tasks need a second reviewer

A second reviewer is warranted when an error would be costly, hard to reverse, or visible to a client. Start by listing the tasks that meet one of those conditions. Do not put every task through review, because a review queue that is always full stops being a control. Separate what was observed from what was assumed.

Write the rule as a short set of triggers with examples. A payment change, a contract commitment, and a client-facing statement are typical triggers. A routine calendar update is not. The rule should let an assistant classify the task without asking for permission.

Ask what happens if the task is wrong and nobody catches it. If the answer is a small delay that can be corrected quietly, a second reviewer may not be needed. If the answer is a financial loss, a compliance issue, or a damaged client relationship, review is justified. Record the observation time so the next reviewer can tell when the evidence was checked.

Consider how hard the error is to reverse. A sent email cannot be unsent, while a draft can be edited. A payment can sometimes be recalled, but the customer relationship may still suffer. The reversibility of the error is as important as its size.

The reviewer should be a role with the authority to approve or reject the work. Name the role, not just a person, so the rule survives a staffing change. The reviewer needs the source record, the output, and the reason the task was routed. A review without evidence becomes a second opinion.

Set a review deadline that fits the task. A client-facing statement may need review the same day, while a monthly report may allow two days. The deadline should be visible in the queue so the work does not stall silently. A short note with four fields is easier to use than a long narrative.

Reviewing everything teaches the team to treat the review as a formality. That is worse than no review because it creates a false sense of control. Keep routine work on a sampling path instead. The sample checks quality without adding a approval step to every task.

Revisit the triggers when the work changes. A task that was low-risk last quarter may become high-risk after a new client or a new system. The rule should be reviewed on a schedule, not only after an error. Use the same format for every handover so the next reader can scan it.

Every reviewed task should show who reviewed it, when, and what changed. If the reviewer approved without changes, say so. If the reviewer rejected the work, record the reason and the next step. The record is how the team learns which tasks need more support.

Keep the record with the task, not in a separate log that nobody reads. The next assistant should see the review outcome when opening the task. That visibility prevents the same error from being repeated. Ask whether a new reviewer could act on the record without a conversation.

When an error reaches a client, ask whether the task should have been reviewed. If the rule missed it, update the trigger. If the rule covered it but the review failed, fix the review step. Do not blame the assistant for a boundary the process did not make clear.

Share the change with the team in a short note. Name the task, the trigger, and the new step. A rule that changes quietly will be applied inconsistently. The goal is a review system that protects the work without becoming the work.

For the support model behind this work, review the [services page](/services) and the scope it describes. Use the [contact page](/contact-us) when the decision needs a written boundary or an approval. The [U.S. Small Business Administration](https://www.sba.gov/business-guide/manage-your-business/manage-your-finances) publishes public guidance on documenting recurring finance and operations work. Keep the links in the handover so the next reviewer can find the same reference.