skip to content

← back to the plays

independenceone source · 3 more authors in those circles
standing

contested · 3 claims against 2

applies to

b2b, no audience needed

mixed results

confidence

medium

evidence

8 claims · 6 articles · 4 receipts

window

2014-08-23 → 2024-07-12

a single source, nothing corroborates it · contested

Set the support policy before the queue sets it

Decide deliberately how fast you answer and how much of the day support may take, keep some days clear of it entirely, and close each ticket with a small product change so the same question is less likely next time. Rank the media by what resolves fastest, doing the task in their account first and falling back to written instructions last, and mute the low value error notifications that are stealing your attention.

What both sides agree on

  • Rank your support media: perform the task in their account first, otherwise send an annotated screenshot or a quick screencast, and fall back to written instructions only when nothing else will do.
  • Close the loop on every ticket by making one small product change that makes the same question less likely next time, so each friction point decays.
  • Expect support requests and bug reports to keep arriving even with all paid acquisition switched off, which is a sign of organic reach but also a standing interruption.

Where this splits

One builder answers chat within seconds and treats immediacy as the product, while another keeps support in a separate inbox, logs in rarely, clears it every few days and accepts losing a few customers for it.

  1. side 01 · 3 claims

    Batch support, cap the hours, accept slower replies

    Arvid Kahl · Tyler Tringas

    1. 1Do not try to compete on support response time early on; keep support in a separate inbox, log in rarely and clear the queue every few days in one sitting.
    2. 2Put a daily ceiling on support hours, keep some days clear of the queue entirely, and do product work in the morning before you open support at all.
    3. 3Suppress low value error notifications so only critical issues or critical volumes reach you. Kahl muted a network error occurring about once in a thousand requests that had been derailing his focus for days.

  2. side 02 · 2 claims

    Answer immediately and treat responsiveness as the product

    Arvid Kahl · Justin Jackson

    1. 1Answer support chat within seconds. Kahl made a point of replying to Intercom conversations almost immediately, and most of the time could solve the problem right there.
    2. 2Do not let the fear of support load rule out an individual-customer market; live chat at that scale is manageable with a very small team.

What it returned

  • The author accepts he lost a few customers this way, and found that a high proportion of tickets resolve themselves because customers work out their own answers

  • Recommends Skitch for marked-up screenshots and Screenflow for screencasts, which are reusable in a way that a typed email is not; most such questions concern something the customer only ever needs to do once

  • The author's name for this is automating empathy: understanding where people struggle, then surfacing the answer automatically in the right context

  • Roughly one failure per thousand requests, muted with a threshold so it only resurfaces past a thousand occurrences

Sources

the second source

Three plays a week, for the phase you are in

No roundup of links, no news. Three tactics more than one builder arrived at separately, with the numbers each one returned and the disagreements left in.

One email a week. Unsubscribe in one click, and the address is used for this and nothing else.

More in product

all product plays

the second source

Three plays a week, for the phase you are in

No roundup of links, no news. Three tactics more than one builder arrived at separately, with the numbers each one returned and the disagreements left in.

963 corroborated plays to draw from · 3 a week

One email a week. Unsubscribe in one click, and the address is used for this and nothing else.