Look back through the messages between your agency and a remote partner over the last month and you will probably find the same pattern. Half the threads are clear and finished in one exchange. The other half drag on: a question asked in Slack, answered in email, followed up on WhatsApp, and finally settled in a call nobody wrote down. The work was not hard. The communication was scattered.
When the people involved are awake at different times, each message has to do more work, because there is no quick “what did you mean?” a minute later. This post is about the everyday habits that make asynchronous communication work: which channel to use for what, how to write a message that needs no follow-up, and the small conventions that stop things getting lost. It applies whether your partner is down the road or on the other side of the world, but it matters most when a large time difference sits between you.
Give every channel one job
The single most useful rule is that each channel has a purpose, and everyone knows it. When anything can go anywhere, people check everything, miss something anyway, and the record of a job ends up spread over four apps. A simple split that many agencies settle on:
| Channel | Use it for | Avoid using it for |
|---|---|---|
| Ticket or task tool, or a dedicated email thread per job | Briefs, scope, approvals, finished-work notes | Casual chat |
| Anything that is a decision or a record: estimates, sign-offs, changes to scope | Quick yes/no questions mid-task | |
| Slack or similar team chat | Questions during a job, quick clarifications, status updates | Credentials, final approvals |
| WhatsApp or phone | Urgent problems only: a site down, a payment failure, a security concern | Routine requests, files, long instructions |
The exact tools matter less than agreeing the split and writing it down. If WhatsApp is reserved for emergencies, a WhatsApp message carries weight. If it is used for everything, an emergency looks like every other ping.
Write messages that do not need a reply to be understood
In a shared office, a half-formed message is fine because the follow-up is instant. Across time zones, every unclear message costs a round trip, and a round trip can cost a working day. A few habits fix most of it.
Lead with what you need
Put the ask in the first line. “Need your decision: keep the old slider or replace it with a static image?” is better than three paragraphs of background ending in a question. Background goes underneath, for anyone who needs it.
One message, one topic
A message that mixes a bug, a new request and a billing question gets one of the three answered. Split them. In chat, start a separate thread for each; in email, a separate subject line.
Say what happens if there is no answer
This is the habit that most changes the pace of remote work. “If I do not hear back by your morning, I will go with the static image” lets the other person proceed rather than wait. Use it for low-risk decisions only, and be clear when you genuinely need a yes before anyone acts.
Include the link, always
Every message about a page should contain its URL. Every message about a ticket should link the ticket. “The page we talked about” forces the reader to search, and on a busy day they may find the wrong one.
Prefer written words to voice notes for anything technical
Voice notes are quick to send and slow to receive. They cannot be skimmed, searched or copied into a ticket, and a URL spoken aloud is easy to mishear. They are fine for a friendly hello; use text for instructions.
Small conventions that prevent confusion
- Status words in subject lines or first lines. Something like QUESTION, FYI, NEEDS DECISION or URGENT tells the reader how to treat the message before they open it. Agree the list once; keep it short.
- Acknowledge with a reaction or a word. A tick or “seen, on it” tells the sender the message landed. Read receipts are not the same thing; they show the message was opened, not that anyone has taken it on.
- Close threads explicitly. “Done, notes in the ticket” at the end of a thread means nobody has to wonder whether it is still open.
- Use scheduled sending for the other side’s morning. Most email and chat apps let you schedule a message. A note that arrives at the start of someone’s day gets read properly instead of sitting under the night’s notifications.
- Keep time references unambiguous. “By end of day” means different things in two time zones. Say whose end of day, or give a date and a time zone.
Keep the record in one place
Chat is good for conversation and poor for memory. Anything decided in chat should be copied to the ticket or the job’s email thread in a line or two: “Agreed in Slack: static image replaces slider, client approved.” When someone looks back in three months, they will look in the record, not scroll through chat history.
The same goes for site knowledge. If a question about a client site has been asked twice, its answer belongs in that site’s notes, not in a message. Our post on keeping runbooks and notes for every client site explains what to capture so that answers live somewhere permanent.
What never goes in chat
Passwords, API keys and full credit card or customer details should never be pasted into Slack, WhatsApp or email, however convenient it is at the time. Messages are backed up, synced to phones and kept long after a project ends. Use a password manager’s sharing feature or create a temporary user for the job, then remove it afterwards. The details are in our guide to handling access to client sites.
Updates that save the other side from asking
The most frustrating message in remote work is “any update?” It usually means the other person has been left without information. Short, regular updates remove the need for it. For a task running over more than one day, a three-line note at the end of each working session is enough:
- Done: what was finished.
- Next: what happens in the next session.
- Blocked: anything waiting on the other side, or “nothing.”
That third line is the important one. If it is empty, the reader knows they can leave the job alone. If it names a question, they know exactly what to answer first. For a fuller treatment of how work passes between time zones at the end of each day, see our post on making a large time difference work for an agency; this piece stays on the messages themselves.
Translating partner updates for clients
Messages between you and your partner can be technical and brief. Messages to your client should not be. Resist forwarding a partner’s notes straight to the client; rewrite them in the client’s language, focused on what changed for their visitors and what, if anything, they need to do. Our post on explaining technical problems in plain language has examples of that translation.
Knowing when to stop typing and talk
Asynchronous does not mean never speaking. Some conversations go faster live, and part of good async practice is recognising them early instead of trading a dozen messages. Book a short call when:
- A thread has gone back and forth several times and the two of you still describe the problem differently.
- The job is large or unfamiliar and a few minutes of screen sharing would replace a long written brief.
- Something has gone wrong between you, such as a missed expectation or a frustrated client, and tone matters more than detail.
- A decision needs several people, and collecting their views by message would take days.
With a large time difference, calls need planning. Find the slot at the edge of both working days, keep it short, and agree an agenda in writing beforehand. Afterwards, one person writes up what was decided and posts it in the ticket. A call nobody summarises leaves the same gaps as a chat nobody copied across, and the person who missed it has nothing to read.
A starter agreement you can share with a partner
Paste something like this into your onboarding notes and adjust it:
“Briefs and approvals go in the ticket. Questions during a job go in the job’s Slack thread, all at once where possible. Decisions made in chat get a one-line note in the ticket. WhatsApp is for urgent problems on live sites only. Every message about a page includes its URL. If a low-risk question has no reply by the start of your next working day, use your judgement and note what you chose. No credentials in any message, ever. End each working session on a multi-day job with Done, Next, Blocked.”
It is short enough that people will actually read it, and specific enough that nobody has to guess.
Review it after a month
Habits drift. After the first month with a new partner, or whenever communication starts to feel messy, look at a few recent jobs and ask: where did the delays come from? Usually it is one or two things, such as questions sent one at a time, or decisions left in chat. Fix those, update the agreement, and leave the rest alone.
Good async habits are one of the less glamorous parts of running outsourced WordPress work well, and one of the most important. If you want ongoing care of client sites from a team used to working this way while you are offline, our maintenance work done under your agency’s name is built around written updates you can read in the morning.
Next in this series: Offshore Developer Red Flags: What Agencies Should Watch
