You've been building for 6 months. The product launches Tuesday. Marketing is ready. Engineering is nervous. Nobody asked the support team if they're ready.

Launch week support is different from normal support. The volume is higher. The questions are different (about the new product, not the existing one). The urgency is higher (bugs on day one get amplified). And the audience includes people who've never used your product before (first impressions matter enormously).

If your support team is scrambling during launch week, you've failed at preparation. Here's the playbook.

2 Weeks Before: Knowledge Transfer

Your support team needs to know the new product as well as any internal user. Schedule a full demo. Give them accounts on the staging environment. Let them use it, break it, and find the confusing parts.

Every confusing thing a support agent encounters during pre-launch testing is something a customer will encounter during launch. Document it now. Write the help article. Add the response template.

Create a launch-specific internal document: "What's new, what changed, and what's going to generate tickets." Be honest. If you know the onboarding flow is confusing, say so. If you know the mobile experience has rough edges, say so. Your support team can only handle what they're prepared for.

1 Week Before: Pre-Write Everything

Write response templates for every predictable launch question:

"How does [new feature] work?" "I can't find [thing that moved]." "Is [old feature] still available?" "I'm getting an error on [new flow]." "What's the pricing for [new product]?"

Pre-write 10 to 15 templates. Your agents won't need to compose novel responses during the highest-pressure week of the year.

Set up AI responses for the most common anticipated questions. If you're launching a new pricing plan, configure Supp to auto-respond to "how much does it cost?" with the correct pricing info. If you're launching a new feature, configure auto-responses for "how do I use [feature]?" with a link to the guide.

Launch Day: All Hands

Launch day is not the day for your support lead to be in a product strategy meeting. Every available support person should be online, responding.

Monitor all channels: email, chat, social media, app store reviews, Reddit, your own community forum. Launch-day feedback comes from everywhere. Have someone watching each channel.

Set up a real-time issue tracker. A shared Google Doc or Slack channel where agents post emerging issues as they see them: "5 customers reporting checkout error on mobile Safari." "3 people can't find the new settings page." This gives engineering real-time bug reports from the front line.

Prioritize by impact. Launch-day bugs that block core flows (can't sign up, can't purchase, can't access the main feature) are all-hands emergencies. UI glitches and minor issues get logged but don't interrupt the team's focus.

The First 48 Hours

After launch day, the ticket composition shifts. Day 1 is "I can't figure this out." Days 2 to 3 are "I found a bug" and "I don't like this change." Days 4 to 7 are "I've been using it for a few days and here's my feedback."

Each phase needs different responses. Day 1 responses are navigational (helping people find things). Days 2 to 3 responses are investigative (determining if it's a bug or user confusion). Days 4+ responses are conversational (absorbing feedback, routing it to product).

Track which launch-specific intents are driving the most volume. If 30% of launch week tickets are "how do I find [feature that moved]," that's a UX signal. If 20% are "this is broken on mobile," that's a bug priority signal. This data should flow to the product team daily during launch week.

Post-Launch: The Retro

One week after launch, run a support retro. What went well? What were the top ticket categories? What were we unprepared for? What templates need to be permanent?

Use the launch ticket data to improve the product. The tickets from launch week are the most concentrated product feedback you'll ever get. Every "I can't find X" is a UX issue. Every "this doesn't work" is a bug or a documentation gap. Every "I wish it could do Y" is a feature request from someone actively trying to use your product.

Launch week support is a data goldmine that tells you exactly what to improve in the weeks that follow.