# Hiring a remote virtual assistant: start with a clear brief

An original reusable resource by Waseet Mahyudin. Adapt it to your agreed project scope.
All bracketed entries are placeholders; decision examples are illustrative, not client results.

Choose a useful first task, define access and review points, and agree what a finished handover includes. Use the editable brief to discuss scope with a freelance VA.

## Who this is for

For founders and small teams looking for remote administrative support, research assistance or help organizing recurring work.

A task brief that makes responsibilities, priorities and acceptance criteria clear before you hire a virtual assistant.

## 1. Start with an outcome you can review

Hiring remote support is easier when the first assignment has a defined result. “Help with everything” hides priorities and makes review difficult.

- [ ] Pick a bounded task: organize a research list, update approved CRM fields, prepare a document or maintain a task tracker.
- [ ] Describe the present problem and who will use the result. Include a representative example with sensitive details removed.
- [ ] Separate a one-off backlog from recurring responsibilities; agree scope for each rather than assuming ongoing availability.
- [ ] List tasks that need your approval, such as contacting customers, publishing content or changing a business record.

## 2. Agree inputs, access and working arrangements

A virtual assistant needs enough context to work independently and a clear route for questions. Access should fit the actual assignment.

- [ ] Name the tools, source files, expected volume and the person who can answer questions.
- [ ] Use individual invitations and appropriate permissions where supported. Never put passwords or private datasets in a public enquiry form.
- [ ] Discuss time zones, any required overlap, deadlines and communication channels before agreeing the work.
- [ ] Agree the scope and commercial terms directly. A service page does not establish a fixed rate, turnaround or unlimited revisions.

## 3. Make progress and blockers easy to see

A small review point can catch a misunderstanding before it spreads across a large task. The aim is a useful result, not activity for its own sake.

- [ ] Review a representative example or first batch against written acceptance criteria.
- [ ] Track task, owner, status, next action and blocker in an agreed shared format.
- [ ] Separate completed work from work awaiting information or approval; do not treat unanswered questions as implicit permission.
- [ ] Keep research sources and record-change notes when the task depends on evidence or alters supplied data.

## 4. Close the task with an organized handover

The person receiving the work should understand the files, unresolved issues and next steps without reconstructing the whole conversation.

- [ ] Provide the agreed files or links, a short completion note and any usage instructions.
- [ ] List unresolved decisions, missing inputs and follow-up owners explicitly.
- [ ] Review the result against the brief before expanding the assignment or setting a recurring schedule.
- [ ] At the end of access-dependent work, agree which permissions should be removed or retained for ongoing tasks.

## Field definitions

### Deliverable

A concrete output and its intended user.

Example: A reviewed company list with source URLs for the sales team's assessment.

### Approval boundary

Actions that must wait for an explicit decision.

Example: Prepare outreach drafts; do not send messages without approval.

### Working arrangement

Agreed deadlines, overlap and update channel.

Example: Confirm the review time and time zone before starting.

### Acceptance criteria

Checks used to decide whether the agreed task is ready.

Example: Required fields present, uncertainties flagged and source links included.

## Illustrative decision log

Illustrative situation: a task says to update CRM contacts, but two records conflict and no conflict rule was supplied.

- Action: Pause the conflicting changes, preserve the records and ask the named reviewer for a decision.
- Reason: Administrative support does not imply permission to guess which business information is current.
- Follow-up: Record the agreed rule, apply it to the relevant records and include the change in the handover.

## Acceptance checklist

- [ ] The first assignment has a clear outcome and scope.
- [ ] Required inputs and an available reviewer are identified.
- [ ] Access and approval boundaries are agreed.
- [ ] Review points, time zones and deadlines are confirmed directly.
- [ ] The handover includes outputs, limitations and next actions.

## Limitations

This guide supports project enquiries for independent freelance assistance; it is not a job board or staffing service. Tool access, availability, communication arrangements and commercial terms must be agreed for the actual assignment.

## Remote VA task brief

- Business context and intended user: [ ]
- First task and desired result: [ ]
- Source files / tools / authorized access: [ ]
- Volume and exclusions: [ ]
- Deadline, time zone and required overlap: [ ]
- Review owner and communication channel: [ ]
- Actions requiring approval: [ ]

| Task | Deliverable | Priority | Review point | Acceptance criteria |
| --- | --- | --- | --- | --- |
| [ ] | [ ] | [ ] | [ ] | [ ] |

## Handover

- Completed outputs and links: [ ]
- Checks performed: [ ]
- Questions / blockers / next owner: [ ]
- Approval: [Pending / reviewer and date]
- Access to remove or retain by agreement: [ ]

Reuse this template for your own work. Keep source references and uncertainties visible; do not treat unchecked boxes as completed checks.