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

What breaks in community support after you go viral is not capacity, it is that every question arrives at once through a door built for a trickle. In the first two hours, write one pinned post with the five repeated answers. Expect impersonation by the evening, and expect the questions to change from what is this into how do I use this by day two.

---

The order is predictable, which is the useful part

A traffic spike is usually described as a volume problem. It is more accurately a timing problem. Every question that would normally have arrived over six months arrives inside a day, through a support process designed for the normal rate, staffed by whoever happens to be awake. The encouraging part is that it fails in the same order every time, so it can be prepared for by anybody who knows what arrives on which day.

Nobody is short of answers during a surge. They are short of somewhere to put the answer so it stops being asked.

Hours one and two: the same five questions

The first thing that happens is repetition. Your inbox, your community, and the comments on whatever went viral fill with the same handful of questions. The instinct is to answer them, one at a time, quickly, because each one is a real person and each one takes ninety seconds. Four hours later there are four hundred more.

⚠ The moment a question arrives for the second time, stop replying and start writing. One pinned post carrying the five repeated answers removes more load in ten minutes than a full day of individual replies.

The post does not need to be good. It needs to exist, be findable, and be linkable. Pin it in the community, put it at the top of the thread that went viral, and link it in the automated reply on your support inbox. Then keep adding to it all day. Every question that arrives twice goes in.

The rest of day one: impersonation

The second thing that arrives is people pretending to be you. Attention draws accounts that copy your name, your avatar and your role, then message your new members privately offering help, access, or a fix. Your newest members are the target precisely because they do not yet know how your team behaves. Three actions, none of which take long:

• Turn off direct messages between members for people who have just joined.
• Post a standing notice stating that your team never messages first, kept visible rather than posted once.
• Name the accounts that are real. A short list of who on your team actually contacts members, in a place everyone can check. This is worth doing before the spike, because it is the one item on this list that has a cost to your members rather than to you.

Day two and three: the questions change

By the second day the nature of the questions shifts, and teams frequently miss the shift because the volume looks the same. Day one questions are about identity. What is this, what does it do, is it free, is it safe. Day two questions are about use. People have signed up, they are inside the product, and they are stuck on something specific. The pinned post that carried day one cannot answer these, because these are procedural rather than factual. Short recordings outperform written documentation here by a wide margin. Record five screens, two minutes each, each one showing the thing people are stuck on, no editing and no production. Someone stuck on a step needs to watch the step happen, and a written explanation of a sequence of clicks is slower to follow than the clicks. Pick the five by counting, not by guessing. The five things asked most on day two are visible in your own inbox.

Day four to seven: the backlog

By the fourth day the immediate wave has slowed and the backlog is the problem. Everything from the first forty eight hours is still sitting there. Working through it chronologically is the wrong move, because a large share of it has already been answered publicly since it was sent. Sort by one question instead: does the answer already exist?

Sorted pile	What you send
Covered by the pinned post	The link, and a line saying which part answers it
Covered by a recording	The recording, timestamped if it is long
Genuinely new	A written reply, then add it to the pinned post
Not a support question	Route it to whoever owns it and say so

That sort usually clears more than half the backlog into two piles that take seconds each, and it leaves a much shorter list of things that actually need thought.

Week two: the person who carried it

The last thing to break is a person, and it is the failure with the longest consequences. Whoever handled the first week has been working at surge pace for seven days, and the traffic has not returned to what it was. The spike settles at a level well above the old baseline, which means the temporary staffing arrangement that got you through the week is now the permanent one by default. This is where teams lose the person who was best at it. Not during the spike, when adrenaline covers it, but in the second and third week when it becomes clear that nothing is going back to normal. The fix is a staffing decision rather than a support decision, and it has to be made in week two rather than week six. Either the load comes down through documentation and automation, or headcount goes up. Waiting to see how it settles is how the decision gets made for you.

What to build before any of this happens

One thing, and it is not a tool. A place where answers live, and a habit that any question answered twice goes into it. That is the entire preparation. A community with that habit absorbs a spike, because the first hour of the spike produces an artefact instead of four hundred individual replies. A community without it answers everything by hand, forever, and the volume of hand-answering scales exactly with attention, which is the opposite of what anyone wants attention to do. The team that survives a traffic spike is not the fastest one or the largest one. It is the one that stopped answering the same question by hand on the first morning.

Where this sits in the bigger picture

Support routing and documentation are one layer of the operating system a community runs on, and this article covers that layer completely enough to install without help. The layers around it 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 the reporting that tells leadership what changed this month. Documentation is the layer that decides whether every other layer survives a surge, because a spike does not create new problems. It applies pressure to whichever layer was already weakest, at a speed that leaves no time to build one. Nobody gets a warning before the week that changes the size of their community. What determines how that week goes was decided months earlier, by whether somebody was writing answers down while there was still time to do it calmly. More at danieljeong.org.