SKILL·0126CF

eol-internal-enablement

deanpeters
更新于 Today
6,403
773
6,403
在 GitHub 上查看
design

关于

This Claude Skill generates internal enablement materials for customer-facing teams before a product End-of-Life (EOL) announcement. It creates support FAQs, sales talking points, objection-handling scripts, and escalation playbooks, scaling from a one-page note to a full enablement pack. Use it to prepare Support and Sales teams with ready responses before the public announcement goes out.

快速安装

Claude Code

推荐
主要方式
npx skills add deanpeters/Product-Manager-Skills -a claude-code
插件命令备选方式
/plugin add https://github.com/deanpeters/Product-Manager-Skills
Git 克隆备选方式
git clone https://github.com/deanpeters/Product-Manager-Skills.git ~/.claude/skills/eol-internal-enablement

在 Claude Code 中复制并粘贴此命令以安装该技能

技能文档

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 — LightLevel 2 — StandardLevel 3 — Heavy
Typical scopeFeature, internal tool, APICommercial product, active customersRevenue-critical, hardware, regulated
ProducesSupport FAQ only (10-15 Q&A)+ Sales talking points, objection handling, escalation playbook+ Channel brief, account escalation tiers, training outline
AudienceSupportSupport, Sales, CS+ Partners, execs, field service
Prep timeAn afternoonA weekSeveral 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 promise.

Escalation Is a Ladder With Names

Four rungs, each with a named owner and a trigger:

  • Level 1 — standard questions (Support)
  • Level 2 — unhappy customers (Support lead or CS)
  • Level 3 — churn-risk accounts (CS lead or account exec)
  • Executive — named accounts, press, legal threats

An escalation path without names is a diagram. Reps need to know who to call at 4pm on a Friday.

The Sticky-Note Rule

Bullets are 4 to 8 words. FAQ answers are one to two sentences. A rep reads this between calls, not in a training room.

Anti-Patterns (what this is NOT)

  • Not the customer announcement. This is what teams know before customers hear.
  • Not a script to read aloud. It's preparation, not a teleprompter.
  • Not spin. Defensive talking points survive one call and then get abandoned.
  • Not optional at Level 1. Even a feature deprecation needs Support to know what to say.

Application

Step 1: Set the level and the dates

Recommend a level from blast radius, present all three, let the user choose. Then pin two dates: the announcement date and the enablement-complete date that precedes it.

Step 2: Build the support FAQ (all levels)

Ten to fifteen Q&A pairs, organized by the six customer questions above. Write the answer a customer would accept, then check it against what's actually true. If those differ, the problem is the plan, not the wording — flag it.

Include the escalation ladder at the end of the FAQ, with names.

Step 3: Build sales talking points (Level 2+)

  • Positioning: how to frame it, what language to avoid, what to lead with
  • Comparison table: sunset product vs. replacement, capability by capability — including the gaps. A comparison table with no gaps is a marketing sheet, and reps stop trusting it the first time a customer finds one.
  • Pipeline guidance: deals in progress, pending renewals, bundled pricing, new prospects asking
  • Competitive response: what to say when a competitor raises your EOL, and when a customer asks whether anything else is getting killed

Step 4: Build objection handling (Level 2+)

Start with the five predictable objections. Add two or three specific to this product and customer base. Each gets Acknowledge-Reframe-Offer, with the offer pre-approved.

Step 5: Channel brief and training (Level 3)

Channel brief covers three things: what partners need to know, what they may tell their customers, and what they must not do. The third is the one that prevents a partner from freelancing a migration promise you can't honor.

Training outline is 60-90 minutes: context and rationale, timeline walkthrough, FAQ review, objection role-play, escalation paths, open questions. The role-play is the part that works — reading objection handlers silently doesn't build the reflex.

Step 6: Assumptions

Close with what you assumed: which objections you predicted rather than heard, which accommodations you believe are approved, which dates you treated as firm.

Final Step: Offer what comes next

"Where next?

  1. Draft the customer announcement — see eol-message (Recommended)
  2. Build account-specific talking points for your top at-risk customers
  3. Write role-play scenarios for the training session
  4. Create a 30-day post-announcement monitoring checklist

Reply with a number, a combination ('1 & 2'), or your own path."


Examples

  • examples/sample.md — Fieldlight Classic Dispatch (SaaS, Level 2 pack)
  • examples/sample-industrial.md — NFA-200 controller line (industrial, Level 3 with channel brief)

Common Pitfalls

Pitfall 1: Enablement After Announcement

Symptom: The FAQ is drafted the week the email goes out.

Consequence: Support improvises for three days. Their improvisations become your de facto policy, and some of them contradict each other.

Fix: Put "enablement complete" on the plan as a date that gates the announcement.


Pitfall 2: The Gapless Comparison Table

Symptom: Every row shows the replacement matching or beating the sunset product.

Consequence: The first customer to name a real gap discredits the whole table, and the rep has nothing to fall back on.

Fix: Name the gaps, with the workaround or parity date next to them. Reps who can concede a point keep credibility for the rest.


Pitfall 3: Defensive Objection Handling

Symptom: Responses that explain why the customer shouldn't feel that way.

Consequence: The customer escalates, because being told your reaction is wrong is worse than the original news.

Fix: Acknowledge first, always. The frustration is legitimate even when the decision is correct.


Pitfall 4: The Unfunded Offer

Symptom: Objection handlers end with accommodations nobody approved — discounts, extensions, custom migrations.

Consequence: Reps promise them, Finance refuses them, and the customer now has two grievances.

Fix: Every offer in the pack is pre-approved with a limit. If it isn't approved, it isn't in the pack.


Pitfall 5: Nameless Escalation

Symptom: "Escalate to the appropriate team."

Consequence: The churn-risk call sits in a queue for two days.

Fix: Four rungs, each with a name and a trigger. Test it by asking a rep who they'd call.


References

Related Skills

These stand on their own — none is a prerequisite for this skill, and this skill isn't a prerequisite for them. If you already picked a level elsewhere, say "Level 2" and this skill builds to it.

External Frameworks

  • Acknowledge-Reframe-Offer — objection handling pattern
  • Customer success playbooks — retention plays during transitions

Provenance

  • Adapted from prompts/eol-internal-enablement.md in the https://github.com/deanpeters/product-manager-prompts repo.

GitHub 仓库

deanpeters/Product-Manager-Skills
路径: skills/eol-internal-enablement
0
ai-agentsai-product-managementclaude-skillspm-frameworksproduct-management
FAQ

常见问题

什么是 eol-internal-enablement Skill?

eol-internal-enablement 是一个 Claude Skill,作者为 deanpeters。Skill 将 Claude 按需加载的说明和资源打包,让 Claude 无需额外提示即可执行与 eol-internal-enablement 相关的任务。

如何安装 eol-internal-enablement?

使用本页的安装命令:将 eol-internal-enablement 作为插件添加到 Claude Code,或将其仓库克隆到 skills 目录,然后重启 Claude 以加载该 Skill。

eol-internal-enablement 属于哪个分类?

eol-internal-enablement 属于元分类。

eol-internal-enablement 可以免费使用吗?

可以。eol-internal-enablement 已收录在 AIMCP,可免费安装。

相关推荐技能

content-collections

Content Collections 是一个 TypeScript 优先的构建工具,可将本地 Markdown/MDX 文件转换为类型安全的数据集合。它专为构建博客、文档站和内容密集型 Vite+React 应用而设计,提供基于 Zod 的自动模式验证。该工具涵盖从 Vite 插件配置、MDX 编译到生产环境部署的完整工作流。

查看技能
polymarket

这个Claude Skill为开发者提供完整的Polymarket预测市场开发支持,涵盖API调用、交易执行和市场数据分析。关键特性包括实时WebSocket数据流,可监控实时交易、订单和市场动态。开发者可用它构建预测市场应用、实施交易策略并集成实时市场预测功能。

查看技能
creating-opencode-plugins

该Skill帮助开发者创建OpenCode插件,用于接入命令、文件、LSP等25+种事件。它提供了插件结构、事件API规范和JavaScript/TypeScript实现模式,适合需要拦截操作、扩展功能或自定义事件处理的场景。开发者可通过它快速构建响应式模块来增强OpenCode AI助手的能力。

查看技能
sglang

SGLang是一个专为LLM设计的高性能推理框架,特别适用于需要结构化输出的场景。它通过RadixAttention前缀缓存技术,在处理JSON、正则表达式、工具调用等具有重复前缀的复杂工作流时,能实现极速生成。如果你正在构建智能体或多轮对话系统,并追求远超vLLM的推理性能,SGLang是理想选择。

查看技能