How to Work With a Virtual Assistant: A Practical Collaboration Guide

Your virtual assistant finishes a client-ready draft on Thursday. You assume the next step is obvious: publish it. Your VA assumes publishing still requires your approval, so the task stops.

Nobody ignored a message. Nobody missed a deadline. The missing piece was a working rule: what can the VA complete independently, and when does the client need to step back into the process?

That is one way delegation can create more management work instead of less.

If you want to know how to work with a virtual assistant, the answer is not simply to communicate more often or install more software. A stronger approach is to make the operating rules explicit so routine work can move, real blockers reach you quickly, and both sides know what they own.

This guide focuses on an ongoing relationship with one human virtual assistant. If you are still preparing accounts, first responsibilities and the initial ramp-up, start with the guide to onboarding a virtual assistant.

Here, the goal is different: create a simple working agreement for what happens after the relationship is underway.

Make the Working Rules Explicit Before the Work Gets Busy

Many working problems begin with assumptions that were never written down.

The client assumes the VA will make a small judgment call.

The VA assumes approval is required.

The client considers a message urgent.

The VA sees it as part of the normal queue.

One person thinks “Friday” means the end of their own working day. The other is operating several hours ahead or behind.

A useful solution is a lightweight working agreement.

Atlassian describes working agreements as shared ways of working that help people establish mutual expectations around communication and collaboration. Its model is designed for teams rather than specifically for virtual-assistant relationships, but the underlying idea adapts well: decide how you will work together instead of leaving important rules implicit.

Define what the VA owns

Start with responsibilities, not a long list of isolated tasks.

For example:

Too vague:
Help with marketing.

Clearer:
Own the preparation and scheduling of approved weekly social posts.

Or:

Too vague:
Handle lead generation.

Clearer:
Research prospects that meet the approved criteria, add verified information to the prospect sheet, and flag records that need a client decision.

The important question is:

What should normally move forward without the client having to reassign it every time?

Ownership does not mean unlimited authority. It simply tells both sides who is expected to move the work.

For individual assignments, use a more detailed task brief. The guide on how to give a virtual assistant clear instructions covers outcomes, sources, deadlines, decision limits and clarification paths in more depth.

Agree where the current version lives

A VA should not have to guess whether the current instruction is in an email, an old chat message, a project board or a document that was updated yesterday.

Choose an agreed home for active work and make version rules clear.

For example:

• Active assignments live in the project system.

• Approved SOPs live in one documentation location.

• Final files live in the agreed folder.

• A changed requirement must be recorded in the task before the old instruction stops applying.

You do not need a particular product stack. You do need both people to know which location is authoritative.

If you need to choose the systems themselves, use the separate guide to tools for managing a virtual assistant.

Define response windows, deadlines and time zones

“Be available during business hours” sounds clear until the client and VA work in different countries.

Write down:

• normal working hours;

• any useful overlap window;

• expected acknowledgment time for ordinary questions;

• what qualifies as urgent;

• which time zone controls deadlines;

• whether a stated deadline means completion, submission for review or final approval.

A deadline such as “Friday at 5” is incomplete when two people are working across time zones.

A better rule is:

Deadline: Friday, 17:00 ET, ready for client review.

The exact hours will vary. The important part is making the convention explicit.

Use this VA Working Agreement

The following is a practical editorial template for a client and VA to complete together. It is not a formal industry standard or a legal agreement. Its purpose is simply to remove recurring operational ambiguity.

You do not need to complete every row with a long policy.

A one-sentence rule is often enough.

The value comes from having one answer both people can refer back to when the same question appears again.

Give Each Task Enough Context to Move

A good relationship-level agreement cannot rescue a task that has no useful instructions.

Before assigning work, give the VA enough context to answer four questions:

1. What outcome is required?

2. What current source should control the work?

3. What can the VA decide?

4. What should happen when the normal process no longer fits?

This does not mean writing an essay for every two-minute assignment.

Routine work may need only a short task name and due date because the process is already known.

New, risky or judgment-heavy work needs more context.

State the outcome and current source

“Update the spreadsheet” describes an activity.

“Update the approved prospect records using the current source list and flag any conflicting company information” gives the VA a result to work toward.

The second version also reduces a common problem: completing the requested activity while missing the actual purpose.

Separate “done” from “ready for review”

Some delegated work can be completed from beginning to end.

Other work should stop before publication, sending, purchasing or another irreversible step.

Those states should not be treated as the same thing.

For example:

Ready for review: article has been formatted, links checked and metadata prepared.

Done: client approval received and article published.

A visible review stage is especially useful when approval is genuinely required. If you want to implement that distinction in a task board, the tutorial on how to set up delegated VA tasks in Trello or Notion shows one way to structure it.

Define the decision boundary

One of the most useful questions in a working relationship is:

What should the VA decide without asking me?

You can divide decisions into three groups:

Decide: routine decisions the VA can make independently within the agreed process.

Ask: decisions that require your approval before work continues.

Escalate: unusual conditions, conflicts or risks that should stop the normal workflow.

For example, a VA researching prospects might be allowed to exclude companies that clearly fail written criteria, required to ask before changing those criteria, and expected to escalate when reliable sources contradict one another.

That creates autonomy without pretending every situation can be predicted.

Match Communication to the Decision

More communication is not automatically better communication.

If every normal status update becomes a meeting, the working relationship can become expensive to manage.

If every difficult decision is pushed into asynchronous chat, important context can disappear across dozens of messages.

The useful question is:

What kind of communication does this situation require?

Use asynchronous updates for routine work

Routine updates usually do not require both people to be online at the same time.

A project task, written update or compact report can show:

• what was completed;

• what is active;

• what is blocked;

• what needs a decision;

• who owns the next action.

That gives the client visibility without requiring repeated “Any update?” messages.

For recurring work, the virtual assistant weekly report template provides a more detailed reporting structure.

Use live discussion when it resolves ambiguity faster

A call can be useful when:

• a new responsibility is being introduced;

• several connected decisions need to be made;

• written discussion is becoming longer rather than clearer;

• a sensitive issue needs context;

• an unclear process needs to be demonstrated.

The goal is not to choose “async” or “meetings” as a philosophy.

Use the format that helps the work move.

Put final decisions back where the work lives

A quick chat or call may resolve a question, but the final decision should not disappear when the conversation ends.

If a deadline changes, record the new deadline.

If the acceptance criteria change, update the task.

If an exception becomes the new normal, update the SOP or working agreement.

Otherwise the VA may correctly follow yesterday’s written instruction after today’s conversation quietly replaced it.

Agree an escalation route

Not every problem deserves an urgent interruption.

But some problems should not sit inside the normal update cycle.

Agree what qualifies as an escalation.

Examples might include:

• access failure blocking time-sensitive work;

• conflicting instructions from two authorized sources;

• a task that would exceed an agreed budget;

• a request involving information the VA is not authorized to use;

• an irreversible action that falls outside the approved decision boundary.

The threshold should match the work. There is no universal list that fits every VA relationship.

Give Access in Proportion to Responsibility

Remote support often requires access to business systems, files or accounts.

That makes access management part of collaboration, not something to improvise after the first password request.

NIST defines the principle of least privilege as limiting users to the minimum access necessary to accomplish assigned tasks.

Applied to a VA relationship, that means giving the access needed for the responsibility rather than automatically giving the broadest account permissions.

Prefer individual access where the platform supports it

Where possible:

• create a named user or collaborator account;

• grant the permission level needed for the current responsibility;

• avoid sharing administrator access when a lower role is sufficient;

• keep account ownership with the business;

• review access when responsibilities change.

The exact permission options depend on the platform.

The principle is more important than any single tool.

Use MFA where available and plan access changes

CISA recommends multifactor authentication as an important protection for business accounts.

Enable appropriate MFA where the service supports it, particularly for accounts that contain sensitive information or elevated permissions.

Also decide what happens when:

• the VA stops handling a responsibility;

• a project ends;

• access is no longer required;

• a credential or device is suspected to be compromised.

These steps reduce risk. They do not guarantee that an account or workflow is secure.

If AI is used, agree the rules before sensitive work enters it

Do not assume that AI tools are either automatically permitted or automatically prohibited.

If AI-assisted work is part of the process, agree:

• which uses are acceptable;

• what information must not be entered;

• whether client or customer data is restricted;

• what output must be checked by a human;

• whether AI-generated material requires disclosure or additional review.

The NIST AI Risk Management Framework treats AI use as a risk-management and trustworthiness issue rather than something organizations should use without governance.

For a VA relationship, you do not need a large AI policy to start.

You do need both people to know the rule.

Build Trust by Expanding Autonomy Deliberately

Trust is easier to use when it changes what happens in the workflow.

At the beginning of unfamiliar or high-risk work, you may want more examples, narrower decision authority and an earlier review point.

As the VA learns the process and repeatedly handles the work within the agreed standard, some of those approvals may no longer add much value.

That is a better route away from micromanagement than simply telling yourself to “trust more.”

Use tighter review points when the work is new

New work often contains unknowns on both sides.

The VA is learning your process.

You are learning where the instructions are incomplete.

An early review can reveal:

• missing rules;

• unclear examples;

• exceptions that were not documented;

• decisions the VA should be allowed to make next time;

• parts of the work that need a different approach.

The purpose is to improve the system, not to create permanent supervision.

Reduce approvals when the context supports it

Once the VA has enough context and a responsibility is stable, ask whether every existing approval still serves a purpose.

If not, move suitable decisions from Ask to Decide.

Keep genuine risk points in Ask or Escalate.

Autonomy does not need to be all or nothing.

It can expand responsibility by responsibility.

Review the Relationship Without Constant Monitoring

A working agreement is not something you write once and ignore.

The role may expand.

Tools may change.

A task that once needed approval may become routine.

A previously simple responsibility may become more sensitive.

Reviewing the relationship helps keep the rules aligned with the actual work.

Separate task QA, routine feedback and performance review

These solve different problems.

Task QA asks whether one deliverable meets the agreed requirement.

Routine feedback addresses a specific behavior, mistake, improvement or successful approach while the work is happening.

Performance review looks across repeated work and asks whether there is a meaningful pattern.

Do not turn one mistake into a broad conclusion about the entire relationship.

For a structured approach to recurring evidence, standards and patterns, use the guide on how to review virtual assistant performance.

Give feedback about observable work

Useful feedback should tell the VA what happened and what should change.

Instead of:

“You need to be more careful.”

Try:

“Three records in yesterday’s batch were added without the required source link. Please add the missing sources and use the source field before marking future records complete.”

That gives the person something observable to correct.

Also ask whether the original instruction contributed to the problem.

Sometimes repeated mistakes reflect poor execution.

Sometimes repeated questions reveal a missing rule.

The response should depend on which problem you actually have.

Update the working agreement when the role changes

Return to the agreement when:

• responsibilities expand;

• communication becomes too frequent or too slow;

• the VA repeatedly waits for approvals;

• the client repeatedly becomes the next-action bottleneck;

• new access is required;

• AI-assisted work is introduced;

• reporting is producing too much detail or too little visibility;

• a recurring exception should become a documented rule.

The goal is not to create bureaucracy.

It is to make recurring decisions once instead of remaking them every week.

Working with a virtual assistant becomes easier when both sides know what belongs to the VA, what belongs to the client, where current instructions live, when approval is required, how blockers are raised and how progress will be reviewed.

Start by completing the working agreement above. Keep it short enough that you will actually update it.

Then use the specialist guides when you need to improve a particular part of the system, such as task instructions, collaboration tools, weekly reporting or performance review.

If you eventually move from one VA to several, the coordination problem changes. The guide to managing multiple virtual assistants covers ownership, handoffs and shared team workflows at that stage.

At Boost VA, I provide ongoing and project-based virtual assistant support across practical growth, backend and operational work. If your responsibilities and working rules are already clear but dependable execution is still consuming too much of your attention, that is a sensible point to explore support.