This async communication policy template is for small agencies and studios that work with clients: which channel to use for what, how fast you reply, how to send a client video, and what never to record. Copy each block with its Copy button, replace the parts in square brackets like [Agency name], and adjust the numbers until the whole team agrees they’re realistic.
The policy is deliberately short. A rule nobody remembers is worse than no rule.
How to use this template
- Copy the sections you need. Each block below is a section of the policy. Skip what doesn’t apply to you.
- Replace the brackets. Names, channels and numbers in square brackets are examples, not recommendations.
- Agree on the numbers together. Response times only work if the people answering think they’re fair.
- Send the short version to clients. The last block is written for them, for your onboarding email or your contract.
- Review it after a month. Change what people kept ignoring.
Purpose and principles
Start with why. It’s the part people read when a situation isn’t covered by the rules.
Purpose and principles
Top of the policy · 5 lines
This policy describes how [Agency name] communicates inside the team and with clients. The goal is fewer interruptions, fewer meetings, and decisions that are written down.
- We write or record first, and meet when writing isn’t enough.
- We don’t expect instant replies. If something is urgent, we say so and use the urgent channel.
- Every decision that affects scope, price or dates is confirmed in writing.
- We respect working hours: [9:00–18:00, Monday to Friday, CET].
Which channel for what
The most useful part of the policy is a simple map from situation to channel. Here’s the one we suggest as a starting point:
| Situation | Channel | Why |
|---|---|---|
| Design review, walkthrough of work, bug report | Short video | Showing beats describing, and the client watches when it suits them |
| Kickoff, decision between options, bad news, a disagreement | Call | Needs a conversation, not a broadcast |
| Approvals, scope, prices, dates | Needs a record you can find in six months | |
| Quick questions, scheduling, “it’s live” | Chat | Short, and fine to answer later |
| Something is broken in production | Phone call, then [chat channel] | Urgent means a human answers |
Not every update should be a video: our guides on meeting or video and when not to send a video help with the edge cases.
Channels
Policy section · 6 lines
- Video: design reviews, walkthroughs, handovers, bug reports and status updates. Keep it under [5] minutes and send the link with one line of context.
- Call: kickoffs, decisions between several options, bad news and disagreements. Every call ends with a written summary by [the project lead] within [one working day].
- Email: approvals, scope changes, prices and dates. If it was decided on a call or in a video reply, confirm it by email.
- Chat ([Slack / WhatsApp]): quick questions and scheduling. No approvals in chat.
- Urgent: [phone number or channel], only when something is broken or a deadline is at risk today.
Response times
Pick times you can keep on a bad week. The values in brackets are examples.
Response times
Policy section · 5 lines
- Chat: we reply within [4 working hours].
- Email: we reply within [1 working day].
- Video from a client or for review: we watch and reply within [1 working day].
- Urgent channel: we respond within [1 hour] during working hours.
- Outside working hours, nobody is expected to reply. [Out-of-hours support is covered by the support contract, if any.]
How to structure a client video
A client video works when the client knows in the first ten seconds what it’s about and what you need from them. Our client video scripts have openings for reviews, quotes and handovers, and how long a client video should be helps you decide when to split one in two.
Client videos
Policy section · 6 lines
- One topic per video. Two topics, two videos.
- Open with context: who it’s for, what it’s about, how long it is. “Hi [name], this is round two of the [page], about three minutes.”
- Show, don’t read. Point at what changed and say why.
- Close with the ask: what you need from the client and by when.
- Send the link with one line that repeats the ask, so the client can reply without rewatching.
- Turn on subtitles, so the client can watch on mute.
Naming videos and files
Consistent names make a video findable six months later, by you and by the client.
Naming
Policy section · 3 lines
- Video titles: [Client] · [Project] · [What it is], for example “Acme · Homepage · Review round 2”.
- Files kept after sharing: [YYYY-MM-DD] [Client] [What it is], in [the client’s project folder].
- Don’t put personal data or internal opinions in titles. The client sees them, and so does everyone they forward the link to.
Privacy rules for recordings
A screen recording shows more than you think. These rules prevent most mistakes; the screen recording privacy checklist explains each one.
Privacy
Policy section · 7 lines
- Before recording, close email, chat and other clients’ tabs, and turn on Do Not Disturb.
- Never record passwords, API keys, payment details or health data.
- Use demo data instead of real customer records whenever possible.
- Send links to the person who needs them, not to group chats.
- Shared links expire after [7] days for reviews and [30] days for handovers. Withdraw a link straight away if it went to the wrong person.
- Keep originals in [location] and delete them [6 months] after the project ends, unless the contract says otherwise.
- If a recording shows a client’s customer data, check it is covered by our agreement with that client.
For the data protection side, including who is the controller when a video shows a client’s customers, read GDPR and client videos.
The short version for clients
Clients don’t need the whole policy. Paste this into your onboarding email, your proposal or the first page of the project doc.
How we work with you
For clients, in onboarding or the proposal · About 120 words
Here’s how we’ll keep in touch during the project.
- For reviews and updates we’ll often send a short video instead of booking a call. Watch it when it suits you and reply by email or in [chat channel].
- We’ll book a call for the kickoff, for decisions between options, and whenever you ask for one.
- Approvals, scope changes, prices and dates are confirmed by email, so we both have a record.
- We reply to email within [1 working day] and to [chat channel] within [4 working hours], [Monday to Friday, 9:00–18:00 CET].
- If something is urgent, call [phone number].
- Video links expire after [7–30] days. If you need one again, just ask and we’ll send a new link.
Rolling it out
Introduce the policy at the start of a project, not halfway through. With existing clients, send the short version with a note that nothing changes about how they reach you, only how you send updates. For the bigger picture of moving an agency to async video, see async video for agencies and the guide to async video for client communication. If you’re choosing a recorder for the team, the screen recorder for agencies page explains what JustRec does and doesn’t do.
Frequently asked questions
What is an async communication policy?
A short written agreement on which channel to use for what, how quickly people reply, and when a meeting is worth it. It saves everyone from guessing, inside the team and with clients.
Should we share the policy with clients?
Share a short version. Clients don't need your internal rules, but they do need to know where to write, how fast you reply and what to do when something is urgent.
What response times are reasonable for an agency?
There is no standard: it depends on your size and your contracts. One working day for email and a few working hours for chat is a reasonable starting point, as long as you can keep it every week, not only on your best week.
Does async communication mean no meetings?
No. It means meetings are kept for what really needs them: kickoffs, decisions with several options, bad news and disagreements. Updates, reviews and walkthroughs move to video or writing.
How often should we update the policy?
Review it after the first month, then whenever the team or the client mix changes. If people keep breaking a rule, the rule is probably wrong.