What Breaks in Community Support in the First Week After You Go Viral

Timing, not volume

Spikes get described as a capacity problem. They are closer to a timing problem. Six months of questions land inside a day, through a process built for the ordinary rate, handled by whoever is at a keyboard.

What makes that workable is that the failure sequence does not vary much between companies. Knowing what lands on which day is most of the preparation.

During a surge nobody lacks answers. What they lack is somewhere to put an answer so the question stops coming back.

The first two hours

Repetition arrives first. The same small set of questions fills your inbox, your community, and the comments under whatever went viral.

Every instinct says answer them. Each is a real person, each takes ninety seconds, and four hours later there are four hundred more waiting.

The post does not have to be well written. It has to exist, be findable, and be linkable. Pin it in the community, put it at the top of the viral thread, and attach it to the auto-reply on your support inbox. Then keep feeding it: anything asked twice goes in.

Later the same day

Next comes impersonation.

Attention attracts accounts copying your name, your avatar and your job title, then messaging your newest members privately with offers of help, access or a fix. New members are the target exactly because they have no idea yet how your team behaves.

Turn off member direct messages for recent joins Post a standing notice that your team never messages first Publish a short list of the accounts that are genuinely yours

This is the one item worth doing before a spike rather than during, because the cost of skipping it falls on your members rather than on your team.

Day two, when the questions change

The character of the questions shifts on day two, and it is easy to miss because the volume looks unchanged.

Day one is identity. What is this, what does it do, is it free, is it safe.

Day two is use. They have signed up, they are inside, and they are stuck at a particular step. The pinned post cannot help, because these questions are procedural rather than factual.

Recordings beat written documentation here and it is not close. Five screens, two minutes apiece, unedited, each showing exactly the step people are stuck on. Somebody stuck mid-sequence needs to watch the sequence, and prose describing a series of clicks is slower to follow than the clicks themselves.

Choose the five by counting what your inbox actually contains, not by guessing which ones seem hardest.

The backlog, day four onward

The wave slows around day four and the backlog becomes the work. Two days of messages are still unopened.

Handling them in order is wrong, because much of that pile has been answered publicly since it was written.

Sort on one question: does the answer already exist?

• Already in the pinned post. Send the link and name the part that answers it.
• Already in a recording. Send the recording, with a timestamp if it runs long.
• Genuinely new. Write a reply, then add it to the pinned post.
• Not support at all. Route it to whoever owns it and say where it went.

That single sort typically moves more than half the backlog into piles that take seconds per message, leaving a far shorter list of things that need real attention.

Week two and the person

The final failure is a person, and it carries the longest tail.

Whoever ran the first week has held surge pace for seven days, and traffic has not returned to its old level. It settles well above the previous baseline, which quietly converts the emergency staffing arrangement into the permanent one.

Teams lose their best operator here, not in week one when adrenaline is doing the work, but in weeks two and three once it is clear that the new level is the level.

The decision is about staffing rather than support, and it needs making in week two. Either the load comes down through documentation and automation, or headcount goes up. Waiting to see how things settle means the decision gets made without you.

The one thing to build first

It is not software.

A place where answers live, plus a habit that anything answered twice goes into it. That is the whole preparation, and it is what determines whether hour one of a spike produces an artefact or four hundred separate replies.

Without it, everything is answered by hand indefinitely, and hand-answering scales precisely with attention. Attention is supposed to make a company stronger, not proportionally busier.

Surviving a spike is not about speed or headcount. It is about having stopped repeating yourself on the first morning.

The layer this belongs to

Support routing and documentation form one layer of a community operating system, covered here fully enough to install unaided. The neighbouring layers are separate builds: onboarding and the first forty eight hours, response time, role and channel architecture, moderation load, escalation paths, automation coverage, engagement rhythm, and leadership reporting.

Documentation is the layer that determines whether the others survive a surge. A spike invents no new problems. It leans hard on whichever layer was already thinnest, fast enough that there is no time to build one while it happens.

No one is warned before the week that changes the size of their community. How that week goes was settled months earlier, by whether somebody was writing answers down while there was still time to do it without hurry. More at danieljeong.org.