"What time works for you?" is the most expensive sentence in customer success. Every time a CSM sends it, a chain reaction starts: a reply 11 hours later because the customer is in Singapore, a counter-proposal that lands on a day you're on PTO, a third email loop, and two weeks later the check-in that should have taken nine minutes still hasn't happened. Multiply that by a book of 40 accounts and your CSMs are spending a fifth of their week just negotiating the meeting before the meeting.
Async-first scheduling flips the default. Instead of "when can we talk," the default becomes "here's the update โ watch it when you can, and let's only meet if there's something to decide." For global teams where customers span ten time zones, it's the difference between coverage and collapse.
Here's the playbook: which touchpoints go async, how to run them so they actually work, and where async fails and you should never try it.
Step 1: Sort your touchpoints by decision density
Not every meeting can be a Loom. The rule is simple: if nothing needs to be decided together, it doesn't need to be synchronous. Walk through your recurring touchpoints and sort them into three buckets.
Async-first (record or write): Monthly check-ins, product usage reviews, QBR pre-reads, onboarding milestone updates, "here's what shipped" summaries. These are information-transfer meetings wearing a calendar invite's clothing.
Sync-first (real meeting): Renewal negotiations, executive business reviews with a decision on the agenda, escalation triage, anything involving conflict or disagreement. High emotional bandwidth needs real-time interaction.
Hybrid (async prep, sync decision): QBRs where the customer reviews the data async and the live time is 20 minutes of decisions instead of 45 minutes of slides. This is where the real time savings live.
Most CSMs discover that 60โ70% of their recurring meetings land in bucket one. That's two or three hours a week per rep, immediately returned.
Step 2: Build the Loom-first check-in template
The number one reason async check-ins fail is that they're improvised. The CSM records a rambling nine-minute video with no structure, the customer skims 40 seconds, and nobody learns anything. A tight template fixes that.
Record a 5-minute video, max, following this exact structure:
- The headline (30 seconds). One sentence: the most important thing about this account this month. "Usage is up 34% since you turned on the onboarding workflow."
- What's changed (90 seconds). Three bullets: metrics movement, new features relevant to them, anything that shipped that affects their setup. Screen-share the dashboard โ show, don't describe.
- What needs attention (60 seconds). The one or two things you're watching. Be honest about risks; sugar-coated async updates destroy trust faster than bad news.
- The ask (60 seconds). One clear question or request. "Do you want me to loop in your data team about the API change?" End with the reply mechanism: "Drop me a voice note or email โ no meeting needed unless you want one."
Post the video with a written summary underneath โ three bullets, timestamps, and the ask in bold. Half your customers will read the summary and never watch the video. That's fine. The point is the information reached them, not the format they consumed it in.
Step 3: Make async replies actually happen
The fear every CSM has: "If I don't get them on a call, they'll go dark." In practice, the opposite is true. Live meetings are the thing that gets skipped; a three-minute video watched at 8pm in the customer's own timezone gets watched.
Set expectations explicitly. In the email or Slack message that delivers the video, write: "Quick update below โ 4 minutes. No meeting needed. Reply here or drop me a voice note when you can; if there's nothing urgent, your silence means we're on track." That last line matters. It gives the customer permission to treat a healthy account as low-touch, which is exactly what busy champions want.
Track engagement the same way you'd track meeting attendance. If a customer hasn't opened or replied to two consecutive async check-ins, that's the trigger to convert the third one back to a live meeting. Async isn't set-and-forget โ it's a channel with its own no-response escalation rule.
Step 4: Timezone-proof your handoffs
Global teams die on handoffs. The CSM in Toronto leaves notes; the customer pings at 2am Toronto time with an urgent question; by the time the follow-the-sun coverage kicks in, the context is stale and the customer is frustrated. Async-first fixes this if you build the handoff correctly.
The handoff artifact is a short recorded brief: 2 minutes, every time coverage transfers. What it covers: the account's current state in one sentence, what's actively in flight, what the customer is likely to ask about, and what must not be said or promised. The CSM finishing their day records it; the CSM starting theirs watches it before checking messages.
This beats a written note for one reason: tone. "They're frustrated about the timeline" reads differently than hearing the frustration in your colleague's voice. On escalations and sensitive accounts, the recorded handoff preserves the emotional context that a Slack message drops.
Pair it with a shared async thread per account โ not email, a persistent thread in Slack or your comms tool of choice โ so any covering rep can read the last two weeks of context in five minutes without digging through inboxes. The rule: nothing customer-relevant lives only in a DM or a call. If it isn't in the thread, it didn't happen.
Step 5: Know where async fails (and never force it)
Async-first is a default, not a religion. Three situations require a live conversation every time, and trying to make them async will cost you the account.
First: conflict and bad news. A missed SLA, a price increase that stings, a feature being deprecated that the customer depends on โ these need real-time human presence. Delivering bad news as a video the customer watches alone at midnight is how you get a churn notice by email the next morning.
Second: ambiguity you can't script. If you genuinely don't know what the customer wants or what the problem is, a 15-minute live conversation resolves more than a week of async messages. Async is for transmitting known information; discovery is still synchronous work.
Third: relationship moments. New champions, new exec sponsors, the first meeting after an escalation โ these are trust-building events, and trust is built face-to-face (even on a screen). Once the trust exists, you can run async. Until then, show up live.
The test is simple: if the outcome depends on how the customer feels at the end of the interaction, meet live. If the outcome depends on what the customer knows, send it async.
The weekly async operating rhythm
Put it together and the week looks like this. Monday morning: record your check-in videos for the accounts in their check-in week โ batch them, 20 minutes total for four accounts. Tuesday through Thursday: monitor replies, respond async, and convert any thread with real ambiguity or tension into a 15-minute live call. Friday: review which async touchpoints got engagement and which didn't; anything with two no-replies goes back on the live calendar next week.
Teams that run this rhythm report the same result: the number of meetings drops by half, response times from customers actually improve (because async is easier to say yes to), and CSMs get their deep-work mornings back. The calendar stops being the job and goes back to being a tool.
Start with five accounts this week. Sort their touchpoints, record one batch of videos, and watch what happens. The scheduling chaos you've normalized isn't the cost of global coverage โ it's the cost of defaulting to meetings for things that were never meetings.
Tomorrow: The Impact/Effort Matrix, Rebuilt for Customer Outcomes โ swap "business value" for "customer outcome value," with a worked example.
