Change impact report

## Change impact report

Use before introducing a breaking change, a deprecation, a pricing or packaging update, or a major workflow change, and during release readiness reviews.

## Definitions

Use these meanings consistently in every step.

- **Proposed change:** What the team intends to change about an existing feature, stated in two to three sentences
- **Impact criteria:** The factors the analysis covers: dependent records, customers who voted on linked ideas, and knowledge base documentation in the workspace
- **Audience:** Who the communication plan is written for. Default to the leadership team unless the user names a different audience.
- **Severity:** How much the change costs the customer. High means work is lost or a workflow breaks. Medium means a workflow changes and needs relearning. Low means the change is additive.

## Workflow

1. Identify the proposed change from the feature. When a feature is provided, use its overview, desired user experience, requirements, comments, and linked records to define the proposed change. State any material assumptions in the report. Ask a follow-up question only when the feature contains multiple competing changes and the analysis cannot be scoped from the record.
2. Review the feature to understand its current scope, effort, and status
3. Identify related records that may be affected. Review dependent records on the **Related** tab, review linked ideas to understand customer impact and name the organizations that voted, and review linked documentation that would need updating.
4. Assess severity for each affected group and state the reasoning behind each rating
5. Summarize potential impact across every area the impact criteria cover. Separate what is certain from what is likely.
6. Recommend mitigations. Each one names the risk it reduces and who would own it.
7. Draft a communication plan for the audience, sequenced by when each group needs to know and what each group needs to do

## Rules

- Treat a provided feature as the default source of truth for the proposed change. Do not ask for a separate proposal when the feature describes a coherent change.
- Ask a short follow-up question only when the feature is missing, or when it contains multiple competing changes that cannot be scoped from the record
- Write for product managers, change managers, and leadership
- Name the organizations affected rather than reporting a count alone
- Highlight risks, unknowns, and assumptions in their own section. Do not bury material findings.
- When impact is severe or customer-visible, propose mitigations and a communication timeline by default
- Reference every record by reference number and name, and call out missing links or ambiguous mappings
- Do not change records, statuses, or documentation. Recommend the action and let the user apply it.
- Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
## Proposed change  
<two to three sentences>  
  
## Current scope  
<what the feature does today, its status, and its effort>  
  
## Affected records and documentation  
| Record | Relationship | Severity | What changes for them |  
  
## Customer impact  
| Organization | Evidence | Severity | What they lose or relearn |  
  
## Risks, unknowns, and assumptions  
- <item, and what would resolve it>  
  
## Mitigations  
| Risk | Mitigation | Owner |  
  
## Communication plan  
| Audience | When | Message | Channel |  
  
## Recommended next steps  
1. <highest value action>
```

## Quality checks

- Every severity rating states the reasoning behind it
- Customer impact names organizations, not just counts
- Certain impact is separated from likely impact
- Every mitigation names the risk it reduces and who owns it
- The communication plan is sequenced by need to know, not by convenience