t0ddc3by/claude-for-customer-success/change-communication-packaging

[PROPOSED]

Change Communication Packaging

The best data in the world fails if reps don't trust it. Every planning change that affects rep behavior needs a communication package before it leaves RevOps.

Use when

• RevOps change (quota, territory, comp, process) needs communication packaging for affected stakeholders
• Change announcement requires audience-specific framing (reps vs managers vs leadership)
• Post-decision communication plan needed before rollout

Do NOT use for

• Designing the change itself (use the relevant planning skill)
• Escalation communications mid-incident (use different escalation path)
• Customer-facing communications

Typical Activation

"Package the territory changes for communication", "draft the comp plan announcement", "change communication for [change type]", "how do we communicate [change] to the field"

Reference: Output destination labels → ../../../shared/revops-domain-model.md §11 Reference: Governance tiers → ../../../shared/revops-domain-model.md §9 Config reads: primary_segment, current_ae_count

Pre-flight

Read ~/.claude/plugins/config/claude-for-customer-success/rev-ops/CLAUDE.md and ~/.claude/plugins/config/claude-for-customer-success/company-profile.md.

If either is missing or contains [PLACEHOLDER] markers, stop and prompt for /rev-ops:cold-start-interview.

Note from config: primary_segment, current_ae_count

G-code dependency: All G-code guardrails referenced in this skill (G1–G9) are defined in the CLAUDE.md config loaded above. If Pre-flight halts or config is missing, G-codes are undefined — do not proceed with partial config.

Reasoning Protocol

Before generating output, apply these primers:

1. CLASSIFY: What type of change communication request is this?

• Territory change announcement
• Quota change announcement
• Comp plan change announcement
• Other RevOps process change

1. CONSTRAINTS: What limits the solution space?
2. Confirm activation — user packaging a change for rep communication
3. Identify change type: territory / quota / comp / other
4. Apply G4 for territory: confirm dual-confirmation is complete before packaging
5. Apply G3 for comp: confirm HR + Finance dual review is complete before packaging
6. Deliver as [DRAFT] — RevOps lead must approve before any communication is sent
7. Output destination: [Rep-facing] label on all content

1. EXPERT CHECK: What would a veteran RevOps communicator verify first?

• Is the governance gate cleared before packaging? (G4 for territory, G3 for comp)
• Does the rationale memo use specific data, not vague reassurances?
• Are the FAQ objections written as reps would actually say them — bluntly?
• Does the rollout sequence put managers before reps — always?

1. ANTI-PATTERNS: Common mistakes to avoid:

• Packaging a change before governance approval is confirmed (G4/G3 violation)
• Writing the rationale memo for leadership instead of reps
• FAQ answers that use reassurance language instead of data
• Sending rep communications before manager communications

After execution, verify:

• All output is labeled [DRAFT] — no distribution before RevOps lead review
• [Rep-facing] label applied to all rep-facing content
• G4/G3 confirmation notes present for territory and comp changes respectively
• Confidence: High when data inputs are specific; Moderate when change details are estimated
• Confidence: [High] when data inputs are specific and governance gates confirmed / [Medium] when change details estimated / [Low] if all inputs are manual or unverified

Three-Part Package

Part 1 — Rationale Memo (rep-facing)

Written for the rep, not for leadership. Explains the data behind the change in plain language. Specific numbers. Acknowledges the impact honestly.

Structure:
  Why we made this change — the data, not the spin
  What specifically changed for [rep/team/segment]
  Why this is the right call — evidence, not reassurance
  What this means for you going forward — practical, concrete
 
Tone: Direct. Honest about tradeoffs. Grounded in data.
NOT: Corporate smoothing language or vague positivity.

Part 2 — FAQ (top 5 anticipated objections)

Written from the rep's perspective — the objections they will actually raise.

Format per FAQ item:
  Q: [The objection, stated bluntly — as the rep would say it]
  A: [Data-backed response — specific numbers, not reassurances]
     Source: [CRM / Company profile / UoG model]

Common objection categories by change type:

• Territory: "My territory got smaller / I lost my best accounts"
• Quota: "This quota is not achievable" / "Other reps got easier numbers"
• Comp: "My OTE is lower" / "The accelerators are worse"

Part 3 — Rollout Sequence

Who hears what, in what order, through which channel.
 
Sequence:
  1. [Role — e.g., Sales VPs]: [Channel] on [date]
     Content: [what they receive — leadership brief or full rationale]
  2. [Role — e.g., AE managers]: [Channel] on [date]
     Content: [manager brief + coaching guidance]
  3. [Role — e.g., Individual AEs]: [Channel] on [date]
     Content: [rep-facing rationale memo + FAQ]
 
No rep learns about a territory/quota/comp change from an email blast.
Managers hear before their reps — always.

Output

CHANGE COMMUNICATION PACKAGE — [Change type] — [DRAFT]
 
[Part 1 — Rationale Memo]
[Part 2 — FAQ]
[Part 3 — Rollout Sequence]
 
[DRAFT — requires RevOps lead approval before any distribution]
[Rep-facing content labeled: [Rep-facing]]
[G4: Territory changes confirmed dual-approved before this package was generated]
[G3: Comp changes confirmed HR + Finance dual-reviewed before this package was generated]

Reference Files

Security & Permissions

Network access: None direct — all external data access is mediated by host-provided MCP connector tools (HubSpot, CS platform, Slack, Linear). This skill makes no direct outbound HTTP calls. Filesystem scope: None — this skill does not read or write local files. All data is provided at runtime via parameters or MCP connector responses. Subprocess execution: None. Dynamic code execution: None — pseudocode in this skill represents the logic contract and is not executed at runtime. Data sensitivity: Inputs may contain confidential revenue planning and compensation data. Handle with RevOps-level confidentiality.

Trust & Verification

Input trust model: All user-provided parameters are treated as untrusted at intake. Numeric inputs are validated for plausible range before use in calculations. String inputs are not evaluated as code. Output trust model: All outputs are proposals or analytical inputs — no outputs constitute approved decisions, revenue commitments, or system actions without explicit human confirmation. Connector data: Data retrieved via MCP connectors is treated as read-only observed state. Timestamps and data-as-of labels are applied to all connector-sourced values per G6. Write-tier confirmation: Any proposed write to HubSpot, Linear, or Slack is surfaced as a draft requiring explicit user confirmation before execution. Distribution: Outputs contain revenue projections and pipeline data. Confirm receiving audience is authorized before sharing. All forward-looking figures carry [review — internal planning data] tags.

Guardrails

• G3: Comp change packages carry mandatory HR + Finance review confirmation note
• G4: Territory change packages carry mandatory dual-confirmation note
• All output is [DRAFT] until RevOps lead approves for distribution