Change Communication Packaging

---
name: change-communication-packaging
version: 1.0.0
deployment_target: plugin
status: PROPOSED
description: "Produces a three-part communication package for sensitive planning changes: (1) data-backed rationale memo for reps, (2) FAQ with top 5 anticipated objections and data responses, (3) rollout sequence with audience, channel, and order. Triggered automatically by annual-planning-workflow for territory, quota, or comp changes. Requires RevOps lead review before any distribution. Triggers: 'communicate changes', 'territory announcement', 'quota rationale', 'comp change communication', 'help me tell reps about [change]'."
---

[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

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

3. **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?

4. **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

| File | Purpose |
|------|---------|
| `references/reasoning-blueprint.md` | Problem classification taxonomy, domain heuristics, common failure modes, and expert judgment patterns for this skill |

## 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