## TL;DR
During a launch, triage by blast radius, not by arrival order. Tag every incoming ticket in under two minutes: launch-related or not, then severity. Pull one person off normal queue duty to own the launch bucket full time. Launches break your usual pattern matching, so a fast sort beats a thorough one.

## The query

```text
how to triage tickets during a product launch
```

## Use this when

- Launch day ticket volume spikes 3x or more
- The release changed onboarding, billing, or a core workflow
- You have a small team and no dedicated launch war room
- Bug reports and "is this new" questions are mixed together

## Not for

- Bug prioritization inside the engineering sprint (that is for devs)
- Post-launch retrospectives and blameless reviews
- Ongoing ticket queue management on a normal day
- Deciding which features ship in the launch itself

## Steps

### 1. Split the queue into two buckets first

Everything that touches the new launch goes in bucket A, everything else in bucket B. Do this before reading any ticket in full. A keyword filter on the new feature names usually catches 80 percent.

Expected output: a saved view or tag that isolates launch-related tickets.

### 2. Score bucket A by blast radius, not feelings

Ask: how many customers could this hit, and is there a workaround? Many customers plus no workaround means top of the queue. One customer with a workaround waits.

Expected output: every bucket A ticket has a severity score within two minutes of arrival.

### 3. Assign one agent to own the launch bucket

Not three people dipping in. One person reads, tags, and routes everything launch-related until volume normalizes. They become the pattern detector.

Expected output: a named owner on the launch tag, announced to the team.

### 4. Build the known-issues list as you go

Every time the owner sees the same report twice, it becomes a macro reply with a one-line workaround. This list is also what you send to the product team at the end of the day.

Expected output: a living doc of known launch issues with status.

### 5. Protect bucket B with a skeleton crew

Old bugs still matter, and customers with unrelated billing questions cant wait three days. Keep at least one agent on the normal queue with a longer-than-usual reply target, communicated up front.

Expected output: no non-launch ticket sits untouched for a full business day.

### 6. Call the triage at a fixed time each day

Twice a day during launch week, the team spends fifteen minutes re-scoring bucket A. Something that was minor at 9am is critical by 4pm when fifty more reports land.

Expected output: a short daily summary with counts by severity.

## Ready-to-use template

```text
LAUNCH TRIAGE TAGS
[sev-1-launch]: blocks core workflow, no workaround, many customers affected
[sev-2-launch]: broken but workaround exists, or few customers affected
[launch-question]: "is this new?" / how-to questions about the new release
[not-launch]: unrelated to the launch, route to normal queue

SCORING (answer in under two minutes):
1. Does it touch the new release? (yes/no)
2. How many customers could this hit? (many/some/one)
3. Is there a workaround? (yes/no)
4. many + no workaround = sev-1. Everything else = sev-2.
```

## Variant phrasings

### how to handle a ticket surge on release day

Same steps. Step 1, the two-bucket split, is the move that keeps the normal queue from drowning.

### prioritizing support tickets during a launch

Step 2, blast-radius scoring, is the prioritization engine. Write the score into a ticket field so everyone sees it.

### launch support triage process for small teams

Step 3, one dedicated owner, matters most when you cant spare two.

## Why it happens

Launches break the pattern matching agents rely on. On a normal day you know which tickets are quick and which are hard. On launch day, a ticket that looks like a confused user is actually a real bug, and a ticket that looks urgent is a cosmetic glitch in the new UI. Triage has to sort by impact precisely because your instincts are miscalibrated for the first two weeks.

## Edge cases

- False launches: marketing announces before the code is live. Bucket A fills with "I cant find it" tickets. Answer with one macro pointing to the rollout schedule.
- Partial rollouts: some customers have the feature, some dont. Add a "which version do you see" question to step 2 scoring.
- Launch plus unrelated outage: bucket B becomes a fire too. Split into three buckets and staff both fires; dont pretend one owner can do both.
- Enterprise launch customers: one loud enterprise account can hijack the owner. Route their tickets through the normal escalation path, not around triage.
- The launch goes fine: then bucket A is mostly how-to questions, which is a good problem. Convert the top questions into help docs after day three.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Dw_e_N-NJ9OL4j2egXkZag