## TL;DR
Support's sunset plan is a campaign, not an announcement: segment the affected users, message each segment on a timeline, arm agents with macros for every question variant, and staff shutdown week like an incident. The announcement is 10 percent of the work. The other 90 percent is the six weeks of confused tickets between announcement and removal.

## The query

```text
sunsetting a feature: support communication plan
```

## Use this when

- A deprecation is approved and support must execute
- The announcement went out and tickets are coming
- Planning support staffing around a removal
- Writing the sunset runbook

## Not for

- The product decision to sunset
- Engineering removal work
- Marketing the replacement
- Pricing changes

## Steps

### 1. Segment the affected users

Heavy users, occasional users, API users, enterprise accounts. Pull the lists from product data. Each segment gets different messaging and different support attention: API users get migration help, occasional users get a notice.

Expected output: four segments with counts.

### 2. Build the timeline working backward from removal

Removal day minus 90: announcement. Minus 60: direct outreach to heavy users and enterprise. Minus 30: in-app warnings. Minus 7: final notice. Removal day: staffed like an incident. Work backward so nothing is late.

Expected output: a dated timeline.

### 3. Write macros for every question variant

"Why is this going away," "what do I use instead," "can I get an extension," "what happens to my data," "I never saw the announcement." Five macros minimum, written before the announcement lands.

Expected output: a macro pack, reviewed and live.

### 4. Staff shutdown week explicitly

Removal day plus three days get extra coverage and a dedicated queue tag. Someone owns the "sunset" tag full-time that week. Plan it now, not the week before.

Expected output: a staffing plan for shutdown week.

### 5. Run the post-removal sweep

Week after removal: check for stragglers (usage that should be zero), close the loop with enterprise accounts, archive the macros, and write the lessons note. Sunsets end; support weeks should too.

Expected output: zero remaining usage confirmed, macros archived.

## Template: the plan

```text
SUNSET PLAN: [feature] - removal [date]
Segments: heavy [N] / occasional [N] / API [N] / enterprise [N]
Timeline:
  T-90: public announcement (all channels)
  T-60: direct outreach to heavy + enterprise
  T-30: in-app warnings live
  T-7: final notice email
  T-0: removal, extra staffing, dedicated tag
  T+7: sweep for stragglers, archive macros
Macros: why / alternative / extension / data / missed-announcement
Owner: [name]
```

## Variant phrasings

### feature removal support plan

Steps 1, 2, and 4. Segments, timeline, staffing.

### deprecation communication timeline

Step 2. Work backward from removal day.

### handling sunset support tickets

Step 3. The macro pack is the whole answer.

## Why it works

Sunsets fail in support because teams treat them as announcements with a long tail, when they are really campaigns with a deadline. Segmentation focuses effort where the pain is, the backward timeline prevents last-minute scrambles, and staffing shutdown week acknowledges reality: removal day is an incident you scheduled.

## Edge cases

- The timeline slips: announce the new date as loudly as the old one. Silence reads as cancellation.
- Enterprise needs an extension: have a policy ready (who approves, how long, what it costs). Do not improvise it per request.
- Data retention questions: answer before they are asked. "Your data is [deleted/exported/archived]" belongs in the announcement.
- The feature will not actually die (zombie sunset): kill the plan loudly or commit to it. Limbo is the worst outcome.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-qfMbQ_IDivA90v8a_veGg