How to plan your inbox for a product launch week

Launch week is the one week your inbox matters most and the one week you'll have the least time for it. New users have questions, press wants answers, partners want to coordinate, and somewhere in the noise is the bug report that tells you the signup flow is broken.

The fix is to do most of the email thinking before launch day. This playbook splits the work into three phases: the week before, the week of, and the days after.

Phase 1: The week before launch#

Map what's coming#

List the kinds of email you expect. For a typical SaaS launch, that's something like:

• New users with setup questions
• Bug reports and "is this working?" messages
• Pricing and plan questions
• Press and blogger inquiries
• Partner and integration requests
• Vendor pitches triggered by your announcement
• Congratulations from friends, investors and past customers

Each type needs an owner and a rough response target. Write them down.

Assign roles#

Even a team of three benefits from explicit roles during launch week. A simple split:

The point isn't hierarchy. It's making sure nobody assumes someone else is answering the journalist.

Write snippets in advance#

You can predict most launch-week questions. Write short, editable replies for them now while you have time to think:

• "How do I import my existing data?"
• "Is there a free trial, and how long is it?"
• "Do you integrate with [tool]?"
• "I found a bug" (acknowledgment plus the questions you need answered)
• "Can I get a demo?"
• A polite decline for vendor pitches

Keep each to a few sentences with a clear place to personalize. Snippets make you fast; personalization keeps you from sounding like a bot.

Set up labels for launch mail#

Create a small set of labels just for launch week, such as launch/bug, launch/press, launch/feedback and launch/partner. Tagging as you go makes the post-launch review possible. Without labels, the feedback disappears into the archive.

Prepare a status line#

If something breaks on launch day, you'll get the same email fifty times. Draft a short "we know, we're on it" reply in advance that you can adapt to the actual problem. It's far easier to edit a calm draft than to write one while things are on fire.

Phase 2: Launch week itself#

Run two triage passes a day#

Instead of watching the inbox all day, schedule two or three focused passes. A pass looks like this:

1. Scan for anything blocking. Signup failures, payment errors, data loss. These go straight to the engineer on call.
2. Route by type. Press to the comms owner, partners to whoever owns them, user questions to support.
3. Answer quick wins. Anything a snippet covers gets answered now.
4. Label everything. Even if you don't reply yet.
5. Note patterns. If five people ask the same thing, that's a docs fix, a product fix, or a new snippet.

Between passes, the support lead can watch for urgent issues while everyone else works on the launch itself.

Protect the press and partner threads#

Press and partner emails are low in volume but time-sensitive and high-value. Have the comms owner check them at least twice a day, even if everything else waits. A journalist on deadline won't wait until Thursday.

Escalate bugs with context#

When support forwards a bug to engineering, include the customer's exact words, the steps they took, their account, and a link to the thread. Engineers can't fix "user says it's broken". They can fix "signup fails with an error after entering a card, on two accounts, both on mobile Safari".

Keep a running log#

A shared doc with one line per notable issue or theme helps enormously at the end of the week:

Day 1 - CSV import times out for files with many rows (3 reports) - fixed day 2
Day 1 - Two users confused by trial length on pricing page - copy updated
Day 2 - Press request from a newsletter - founder replied
Day 3 - Request for an integration we don't have (4 reports) - logged