Async communication for distributed teams: stop hopping on a quick call

The Slack thread starts with someone in Berlin asking how to do a thing. Someone in Toronto replies “easier to hop on a quick call.” The call gets booked for tomorrow because of timezones. The call runs 45 minutes instead of 15. Halfway through, the Toronto person screen shares; the Berlin person can't quite see the URL bar because of compression. Afterwards Toronto sends a follow-up Slack with a screenshot. Two days later Berlin forgets a step and asks again.

Multiply that across a distributed team and you have the meeting load most remote workers complain about. Microsoft's 2025 Work Trend Index put the average at 11.3 hours per week in meetings, with remote workers attending 80% more meetings than their in-office peers. 64% of remote workers say they'd prefer async — recorded video, written docs, collaborative docs — over a synchronous meeting for status updates. Only 29% of organizations actually offer async as a formal option.

This post is about closing that gap for one specific category: the “hop on a quick call” that should have been a doc. Not because every meeting is bad, but because a meaningful share of them are answering a question that has the same answer this month as it had last month, and the call is the wrong shape for an answer that's going to get asked again.

Three categories of “quick call”

Not every quick call is a candidate for replacement. The ones that are have a recognizable shape. Three categories.

The “show me how” call. One person walking another through a procedure. Onboarding the new hire on the deploy process. Showing the support rep how to refund a customer. Walking finance through the quarterly close in your dashboard. The caller is asking for steps; the callee is going to share a screen and click through them while talking.

The “quick question with context” call. The question is short but the context is visual. “Why is this dashboard showing the wrong number?” or “is this right?” The caller could type the question, but they need to point at something on a screen, and Slack screenshots feel insufficient.

The “status update” meeting. The standing standup, the weekly check-in, the project update. Most attendees are listeners. The information transmitted is roughly “here's what I did, here's what I'm doing,” with a screenshot or two of progress.

The first two are the ones a walkthrough replaces best. The third is mostly a culture problem (and a separate post). For now the focus is on the first two — the calls that exist because the right shape of answer didn't already exist.

What the “quick call” actually costs

The math is uglier than it looks.

Take the “show me how” call. The caller typed their question, waited for a reply, agreed to a call, opened their calendar, found a time that works across timezones, joined the call, watched a screen share, took notes, and asked clarifying questions. The callee blocked 30 minutes (because nobody books 15), joined the call, screen shared, talked through the steps, fielded questions, and went back to focus work.

For a single answer that gets given once, that's maybe 60 person-minutes total. The numbers from the meeting-cost calculations everyone in the productivity space cites land around $300 in salary cost for a one-hour meeting with six people at $50/hour, plus prep. A one-on-one quick call is cheaper, but the principle holds: the time isn't free, and most of it is going into a transmission that'll need to be repeated next time.

Repeated is the key word. The same answer often gets given five or ten times across a team — every new hire, every cross-functional project, every customer support handover. Each instance is its own quick call. None of them produce an artifact future instances can use.

What replaces the call

The format that fits the “show me how” category is a walkthrough: an ordered sequence of steps, each with a screenshot, the URL at capture time, the visible text on the clicked element, and a short description. The caller opens a link. They see the steps. They follow them on their own screen. Where they get stuck, they leave a comment on the specific step.

The walkthrough has properties the call doesn't.

It's indexable. Six months from now, when a different person asks the same question, the answer already exists. Search finds it. The second instance of the question costs nothing.

It's pause-and-resumeable. The recipient follows the steps at their own pace. They can pause to try the steps on their actual systems without slowing anyone down, and they can come back tomorrow if they get interrupted. A live call doesn't support either move without rescheduling.

It's scopeable to a single step. When the recipient gets stuck, they don't Slack “the thing isn't working.” They comment on step 7. The original author sees exactly which step the failure happened on, and the back-and-forth is one or two messages instead of a debugging session.

It survives the timezone. The Berlin person opens it at 9am Berlin time. The Toronto person sees the comment when they wake up. No calendar Tetris, no “next available” window, no 9pm-Toronto compromise.

The “quick question with context” case

The second category — “is this right?” with a screenshot — is shorter but has the same shape. The asker doesn't need to record a full procedure; they need to capture the state they're looking at and ask one specific question about it.

A walkthrough tool for a single step is a heavier hammer than the question requires. The lighter version: a screenshot capture that includes the URL and the clicked element automatically, paired with a one-sentence question. In UIHike that's a region capture or fullscreen capture inside an existing project; the URL and the element metadata come along for free, and the resulting step gets a shareable link.

Compared to a Snagit screenshot pasted into Slack, the difference is small but real: the recipient sees the URL, can click through to the live page, and can comment on the specific step instead of starting a thread that loses the screenshot two messages later.

The “send a Loom” alternative

The other answer to the quick-call problem is to send a video. Loom built a category around it, and for one-off async communication a Loom is often the right call.

Where it lands well: tone-heavy explanations. “Here's how I'd frame this PR feedback.” “Here's why we chose option B.” A 90-second Loom carries the speaker's emphasis and pacing in a way text struggles to. The recipient watches once and moves on.

Where it falls down: procedures that get repeated. Roughly two thirds of users abandon a video tutorial when they can't scan for the specific written step they need (an industry number cited across the documentation-tool space). Update cost is worse — the UI changes, the button moves, your video is wrong, and there's no edit. You re-record the whole clip, or you live with a doc that drifts.

The split most async-mature teams converge on:

• Loom for one-off, tone-heavy, won't-be-asked-again explanations.
• Walkthroughs for procedures anyone might follow more than once. The onboarding doc, the runbook, the cross-functional handoff.
• Slack threads for the actual back-and-forth. The walkthrough or Loom is the answer; the thread is where the follow-up questions land.

The async-by-default culture move

Tooling alone doesn't replace the quick call. The norm has to shift, too. Three patterns that tend to land cleanly:

The first response is async, the second is a call. When someone asks “can we hop on a quick call?” the default reply is “send me a screenshot or the URL — happy to record a walkthrough or Loom if it's a procedure.” If the question survives that, it's probably worth a call. Most don't.

Recurring questions become walkthroughs immediately. If you've answered the same question twice, the third answer is a walkthrough link. The cost of recording the walkthrough is the same as the cost of giving the answer once more, and now the fourth and fifth askers self-serve.

Status meetings get a written alternative. The standing weekly becomes optional. Attendees who want it attend; everyone else reads the summary in a channel. The Microsoft data is consistent here: organizations that adopted meeting management tools reduced total meeting time by 18% while improving follow-up completion rates by 42%. The reduction comes from making the meeting itself optional, not from running shorter meetings.

What async doesn't replace

An honest list, because async maximalism produces its own backlash.

Decisions that need consensus among people who disagree. A walkthrough can't resolve a debate. A doc thread with five disagreeing comments doesn't get resolved by a sixth comment; it gets resolved by 30 minutes on a call where the disagreement is named and a decision is made. The call is the right shape for the work.

Conversations where rapport is the point. One-on-ones with reports. Hiring conversations. The weekly with a skip-level. Async doesn't carry the relational signal. It's also not trying to.

Crisis calls. Production incident. Customer escalation. Anything where multiple people need to coordinate in real time on a moving situation. The call is the right shape; the walkthrough comes afterwards as the doc.

The right framing isn't “async replaces sync.” It's “async replaces the sync that should have been async,” and the sync that's left gets to be higher quality because it isn't carrying the load it shouldn't.

What this looks like on a real team

A concrete pattern from teams that have made the shift.

The senior engineer onboarding a new hire records two walkthroughs in the first week: the deploy process and the on-call handoff. Total time spent recording: about an hour. Total time the new hire would have asked for over the next three weeks if those walkthroughs didn't exist: roughly four quick calls totaling 90 minutes of senior time, plus the new hire's waiting time for those calls to get scheduled. The walkthroughs paid back in the first month. They keep paying back for every subsequent new hire.

The customer support team records a walkthrough for each common refund/escalation flow. New reps shadow walkthroughs instead of senior reps. The senior rep's time freed up goes to the cases the walkthroughs don't cover, which is the work the senior is genuinely the right person for. The team's time-to-competency for new reps drops because the new rep has a library of procedures instead of a queue of questions.

The IT admin documents the contractor onboarding in Microsoft Entra ID once. The walkthrough goes in a shared folder. Whenever a new contractor joins, the hiring manager opens the walkthrough, follows the steps, and onboards the contractor without paging IT. IT's time goes to the harder cases.

In all three the structure is the same. The senior records the answer once. The answer becomes a link. The link replaces the call. The senior's calendar opens up for the work where the senior is actually irreplaceable.

The first walkthrough to record

Pick the question you've been asked most often this quarter. The one that gets you to say “easier to hop on a quick call.” Record the answer once. Send the link the next time the question comes in. See whether the back-and-forth shrinks.

That's the smallest possible test of async-by-default. If the link works, the next walkthrough is the next-most-common question. Within a quarter the team has a library of the questions that were eating its calendar.

Try UIHike on the question you'll get asked again next week. The walkthrough you record this afternoon is the call you don't take the rest of the year.

— The UIHike team