How to brief a remote team so the first batch comes back right
A good brief shows the team exactly what goes in, what should come out and how you will judge it: a real input sample, a finished example, five good results and three mistakes, the rules and known edge cases, the volume and deadline, and the error rate you will accept. Then answer questions quickly in the first week.
Build your brief
Fill in the six parts below. Each empty part shows an example, so your brief always reads as a whole. Copy it when you are done.
Brief for the remote team
The task
Check about 500 new product listings a week against our style rules and fix what is wrong.
What goes in
A spreadsheet export of new listings. Sample of 20 rows attached.
What should come out
The same sheet with fixes in column F and notes in column G. One finished row attached.
Rules and examples
Style guide linked. Five corrected rows, and three common mistakes with a line on why each is wrong.
Volume and deadline
About 100 listings a day, back within one working day.
How you will judge quality
No more than 2 in 100 rows need fixing, and our review takes under 20 minutes a day.
Opens your own email app, addressed to hire@herworkcircle.com, with your brief filled in. Nothing is sent until you press Send.
Write down what good looks like
"Good" means different things to different people until it is written down. Pick the measures that matter for your task and put a number on each one.
| Measure | Example target | How you check it |
|---|---|---|
| Accuracy | No more than 2 in 100 pieces need a fix | Check a random 20 from each batch |
| Format | Every row fills the same columns, in the same style | Scan the sheet, or filter for blanks |
| Completeness | Every piece in the batch is done, or flagged with a reason | Compare counts in and out |
| Turnaround | Back within one working day | Note when you sent it and when it returned |
| Questions | Anything unclear is flagged, never guessed | Look for notes on the pieces that were hard |
Examples teach faster than rules
Rules describe the task, and examples show where the line between right and wrong falls. Send around five results you are happy with and three mistakes, each with one line on why it is wrong. Choose mistakes that really happen, such as the ones your own team makes when it is in a hurry.
If you only have time for one thing, send the examples. Good examples answer many questions before the team has to ask them.
Keep one shared list of edge cases
Every task has cases the rules don't cover. Keep one shared list, with the question, your answer and the date, and add each answer to the brief. After a few batches, most questions are already answered there.
| Question from the team | Your answer | Added to the brief |
|---|---|---|
| The product has no colour in the name. Leave it blank? | Yes, leave it blank and add a note. | Rule 7 |
| Two listings look like duplicates. Delete one? | Never delete. Flag both in column G. | Rule 8 |
The first two weeks
- Walk through the brief together on a short call, with the input sample open.
- Start with a small first batch, small enough that you can check every piece yourself.
- Send your corrections within a day, while the batch is still fresh.
- Add every correction and answer to the brief or the edge-case log.
- Run a second batch on the updated brief and compare the numbers.
- Once the numbers hold, move to checking a sample of each batch instead of every piece.
The UK government's sourcing rules recommend the same shape for any work outsourced for the first time: run a pilot, and set performance measures that fit the size of the work.
Brief mistakes that cost a batch
| Mistake | What happens | Fix |
|---|---|---|
| The rules live in one person's head | The team guesses, and the guesses differ | Write the rules down before the first batch |
| No real input sample | The first real file looks different from what the team expected | Send 20 rows exactly as they will arrive |
| "Use your judgement" | Each person judges differently | Give the rule, or ask them to flag the case |
| Rules change without a note | The old rule keeps being followed | Date every change in the brief |
| Quality measure agreed after the batch | Nobody agrees whether it passed | Agree the measure before work starts |
| Sending data the task doesn't need | More risk, no benefit | Remove the columns the task doesn't use |
That last point is also the law in the UK and EU: personal data must be limited to what the purpose needs. Our guide on what to hand off first covers how to split a task so less data leaves your team.
How we use your brief
When you send us a brief, a person on our team reads it before a free 20-minute call. On the call we go through your examples, agree what good looks like and give you a clear price for a trial batch. The team does the batch, we check every piece, and you judge it before anything bigger starts.
Questions
What should a brief for a remote team include?
The task in one sentence, a real input sample, the output format with a finished example, five good results and three mistakes, the rules and edge cases, the volume and deadline, and how you will judge quality.
How long should a brief be?
As short as it can be while still answering those points. One page plus the examples is often enough for a repeatable task.
How big should the first batch be?
Small enough that you can check every piece yourself in one sitting, and large enough to include the usual edge cases.
How do I measure the quality of outsourced work?
Agree the measure before the first batch, for example the share of pieces that need a fix and how long your review takes. Compare the first and second batches.
What if the team keeps asking questions?
In the first week, that is a good sign: questions mean they are checking instead of guessing. Add every answer to the brief so the same question isn't asked twice.
Sources
- The Sourcing Playbook: pilots and performance measures GOV.UK, Cabinet Office
- Principle (c): data minimisation Information Commissioner's Office (UK)