/eol-internal-enablement

name: eol-internal-enablement
argument-hint: "[product being sunset, replacement, and key dates]"
description: "Build the support FAQ, sales talking points, and objection handling teams need before an EOL announcement. Use when customer-facing teams must be ready before customers hear."
intent: >-
  Generate the internal enablement materials customer-facing teams need before an EOL announcement
  goes out: a support FAQ, sales comparison talking points, objection-handling scripts using
  Acknowledge-Reframe-Offer, and an escalation playbook. Right-sized so a feature deprecation gets a
  one-page support note while a major sunset gets a full role-specific enablement pack.
type: component
theme: eol-transition
best_for:
  - "Arming Support and Sales before the announcement, not five minutes after it"
  - "Turning predictable EOL objections into honest, non-defensive responses"
  - "Giving escalations a named path before the churn-risk calls start"
scenarios:
  - "We announce the sunset in three weeks and Support has nothing — what do they need?"
  - "Sales keeps getting ambushed on our EOL; build them talking points and objection handling"
estimated_time: "25-45 min"

EOL Internal Enablement

Purpose

Build what customer-facing teams need **before** the EOL announcement goes out: a support FAQ, sales talking points with honest comparison data, objection handling, an escalation ladder, and — when the sunset warrants it — a channel partner brief and a training outline.

The cardinal sin of EOL communication is handing Support and Sales the announcement five minutes before customers get it and wishing them luck. This skill exists to prevent that. Internal readiness is a prerequisite for announcing, not a follow-up task.

Input

**Works best with:** The product being sunset, what replaces it (if anything), and the key dates.

**Also useful:** The objections you expect, which accounts are at risk, what continues versus what stops, and whether channel partners are in the picture.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

**Arriving empty-handed? That works too.** The skill asks up to three questions — what's being sunset and what replaces it, the dates for stopping sale/support/service, and the top objections you expect — then builds the pack. If you don't know the objections, it drafts the predictable ones and you edit.

**Example invocations:**

• `Build the enablement pack for our legacy module sunset — replaced by the new dashboard, EOL Dec 31.`
• `Support FAQ only, feature deprecation, no replacement, three weeks notice.`

---

Key Concepts

Right-Size the Pack

**Not all EOLs play out the same.** Most land in the middle:

| | **Level 1 — Light** | **Level 2 — Standard** | **Level 3 — Heavy** | |---|---|---|---| | Typical scope | Feature, internal tool, API | Commercial product, active customers | Revenue-critical, hardware, regulated | | Produces | Support FAQ only (10-15 Q&A) | + Sales talking points, objection handling, escalation playbook | + Channel brief, account escalation tiers, training outline | | Audience | Support | Support, Sales, CS | + Partners, execs, field service | | Prep time | An afternoon | A week | Several weeks with live training |

**Level 2 is the default.** Recommend a level, say why in one line, and let the user move it. **Never default to Level 3** — a full training program for a feature deprecation teaches teams that EOL enablement is bureaucracy, and they'll tune out the one that matters.

If someone dials down to a Support FAQ only, name what's dropping: usually the objection handling, which is what Sales needs when a customer says "we renewed last quarter."

Enablement Precedes Announcement — Always

Set an explicit "enablement complete by" date that falls **before** the announcement date. If those two dates aren't separated on the plan, they will collapse in practice, and Support will learn about the sunset from an angry customer.

Organize the FAQ by What Customers Ask

Not by internal category. Lead with the questions that will generate the most call volume. The six that always come, in roughly this order:

1. **What is happening?** 2. **What does this mean for me?** 3. **What are my options?** 4. **What about my data?** 5. **What about my contract?** 6. **When does support end?**

Answers are one to two sentences, honest and specific. "We're evaluating options" is not an answer; it's a deferral that the customer will hear as evasion.

Acknowledge — Reframe — Offer

Every objection response follows the same three-beat pattern:

1. **Acknowledge** — validate the frustration as legitimate, without hedging or apologizing twice 2. **Reframe** — give the honest reason or the genuine upside, without pretending the loss isn't real 3. **Offer** — a concrete accommodation, option, or next step the rep can actually deliver

**Why the order matters:** teams under pressure skip straight to Offer, which reads as a bribe, or straight to Reframe, which reads as a lecture. Acknowledging first is what makes the other two land — and it costs nothing.

**The offer must be real.** An objection handler that ends in "I'll see what I can do" trains reps to make promises the company hasn't agreed to. Get the accommodation approved *before* it goes in the pack.

The Predictable Objections

Five show up in nearly every sunset. Draft these before asking what else might come:

1. **"We just bought this / renewed last quarter."** 2. **"The replacement doesn't have feature X."** 3. **"We're going to leave entirely."** 4. **"Why should we trust your next product?"** 5. **"Can you make an exception for us?"**

The fourth is the one teams answer worst, because the honest answer is about *how you're handling this transition* — the current sunset is the evidence for the next promis