Marketing scheduled the announcement for a Thursday morning. We found out Monday at 2 PM. In roughly 72 hours, we handled close to three times our normal daily ticket volume and did not miss a single SLA. Not because we were fast. Because we had written the answers before the questions arrived.
Most support teams find out about product launches the same way their customers do: the announcement email hits the inbox and the queue starts moving. The difference in how launch day feels when you have two days of prep versus none is not subtle. This is the playbook I actually run.
Get the Brief Before They Send the Email
Marketing copy is written to excite, not to support. It uses phrases like "seamlessly integrated" and "powerful new workflow" that tell you nothing useful when a customer asks why they can't find the new button. The first thing I do after learning about a launch is ask the product team six specific questions, in writing:
- What exactly is new and how does it work? Not the pitch, the mechanism. Walk me through the user flow.
- What is NOT included in this release? Scope reductions generate more tickets than new features. Customers expect something that was cut and ask why it is missing.
- What are the known limitations or edge cases? If there is a situation where the feature will not work, I want to know before a customer tells me.
- What is the pricing, and does anything change for existing customers? Billing questions are the highest-stakes tickets. I need to understand the pricing exactly, not approximately.
- Who gets access and when? Phased rollouts are the single biggest source of confused support tickets. "I don't see the new feature" is almost always a rollout timing question.
- What is the escalation path if we hit a launch-blocking bug? I need a name and a channel before launch, not during it.
I ask for these answers in writing, not in a meeting or a Loom. If the product team cannot answer them in writing, they have not finished thinking through the launch. That friction is useful to surface before Thursday, not after.
Write the Answers Before the Questions Arrive
Once I have the brief, I write five canned responses before launch day. The same five questions show up in every launch, regardless of what you are shipping:
- "How do I use the new feature?" Your most common ticket. Write a clear step-by-step reply and link it to the KB article you are about to publish.
- "I can't see it." Almost always a phased rollout or a permission issue. The reply should acknowledge the rollout schedule and give a timeline if one exists.
- "The pricing changed." Be exact here. Customers notice discrepancies between what the email said and what the agent says. If there is any ambiguity, escalate rather than guess.
- "It is not working the way it was described." The template for this one is short: acknowledge, log it as a known issue if it is one, or escalate if it is new.
- "I didn't know about this change." Some customers will miss the announcement entirely. A brief summary of what changed and why helps, without making them feel blamed for not reading the email.
In Help Scout, I create a saved-reply folder named after the launch. In Zendesk, a dedicated macro group. The point is that on a high-volume day, nobody writes fresh from scratch: they select, personalise briefly, and send. I also publish the KB article before the launch email goes out, not after, so day-one replies include a real link instead of a promise that documentation is coming.
Configure the Queue Before You Need To
Three configuration steps, done the day before launch:
First, create a launch tag. Something simple: launch-aug2026 or launch-[feature-name]. Apply it automatically to any ticket that mentions the feature name in the subject line (most helpdesks have a keyword rule for this). This lets you filter, report, and monitor launch-specific volume without touching your normal reporting.
Second, route tagged tickets to your strongest agents for the first 48 hours. Not because the others cannot handle it, but because the first day of a launch surfaces the edge cases and bugs you did not anticipate. You want your most experienced people reading those tickets in real time.
Third, set a volume alert. I use a simple Zapier trigger: count new tickets with the launch tag per hour, send a Slack message if the count is above a threshold that would indicate something has gone wrong. On a normal day this alert will not fire. On launch day it is the early-warning system for a bug you did not know about.
Run the Desk Differently on Launch Day
One person is the launch support lead. They own escalation decisions, communicate directly with product if a bug surfaces, and keep a real-time log of novel issues in a shared document, two columns: "issue" and "count." When the same unexpected question appears from three separate customers, that is the signal to escalate or write a new canned response on the spot.
For the first hour, I read every incoming ticket personally before it gets routed. On most days, triage is useful. On a launch day, the thing you most need to catch is the pattern that three customers reported in the first 40 minutes. Triage slows that signal.
The metric that matters on launch day is not how fast you respond. It is how quickly you spot the thing you did not prepare for.
One more thing: brief your team the morning of the launch, even if you briefed them the day before. Five minutes, the whole team together. Walk through what is going out, what the most likely questions will be, and who to escalate to. The person who skipped the pre-launch prep session will be grateful. The people who attended it will feel anchored and ready.
Capture the Debrief at 48 Hours
Forty-eight hours after the announcement, I pull five numbers and write a one-page summary:
- Total tickets tagged with the launch in the first 48 hours
- Which canned responses were used most (these are your validated FAQs; update the KB article to reflect them)
- Any questions that came in that you had not prepared for (add these to the playbook template for next time)
- Whether any bugs were surfaced via support before engineering knew about them, and how long the gap was between the first ticket and the escalation
- Average resolution time on launch-tagged tickets vs. your normal baseline
I share this with product and marketing. Product teams appreciate it because it is structured customer feedback they did not have to collect. Marketing appreciates it because it tells them which parts of the announcement confused people, which is information they can use for the next one.
The playbook itself gets updated after every launch. What questions did we not anticipate? Which configuration step saved us time? What would we do earlier next time? After three or four launches, this document is the most useful operational artifact your support team has.
The Part Most Teams Skip
The biggest gap is the brief. Most support leads find out about launches the same way their customers do: when the announcement email lands. By then it is too late to prepare, and you are reacting instead of executing.
A standing agreement that support gets a written brief five days before any customer communication goes out is the single highest-leverage change a support lead can push for. Everything else in this playbook depends on having that brief in hand before the announcement goes out. If you are preparing for an upcoming launch and want to compare notes, reach out here.
Comments