Customer concern scenarios

# Customer concern scenarios

Use before a launch, once the support materials are live, to prepare the team for the concerns customers will raise about a new feature.

## Definitions

Use these meanings consistently in every step.

- **Feature:** The feature being launched, or the feature whose record link the user pasted into the chat.
- **Concern:** An objection or worry a customer raises, stated in the customer's own words rather than as a category.
- **Proof point:** Specific evidence that supports the response: a capability that exists, a documented limit, a customer result, or a dated commitment.
- **Follow-up question:** A question that keeps the conversation moving and surfaces what is actually behind the concern.
- **Audience:** Who is being prepared, such as sales, customer success, or support. Default to customer-facing teams generally.

## Workflow

1. Read the feature, its description, its linked ideas, and the comments on them. The comments carry the objections customers have already raised.
2. Confirm the audience and the customer segment. An enterprise buyer and a single-team customer raise different concerns.
3. Draft five likely concerns. Cover the range: capability gaps, migration and effort to adopt, pricing and packaging, security and permissions, and how it affects existing workflows.
4. Write each concern the way a customer would say it, not as a category label.
5. Write the response. Acknowledge the concern honestly, then give the accurate position. Where the answer is a real limitation, say so and give the workaround or the timeline.
6. Attach proof points to each response, drawn from what exists rather than what is planned.
7. Add a follow-up question for each, aimed at learning what is actually driving the concern.
8. Flag the concerns with no good answer yet, and name what would be needed to answer them.

## Rules

- If the feature or its supporting materials are missing, ask short follow-up questions before drafting
- Never overstate availability, performance, or a roadmap commitment
- When the honest answer is a limitation, say so plainly and give the workaround rather than deflecting
- Proof points cite something real. Do not present a plan as a capability.
- Reference the feature and linked ideas by reference number and name
- Do not update records or publish the material. Present the draft and let the user apply it.
- Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
## Audience and segment  
<who this prepares, and for which customers>  
  
## Concerns  
### <concern in the customer's words>  
\*\*Response:\*\* <acknowledge, then the accurate position>  
\*\*Proof points:\*\*  
- <specific evidence>  
\*\*Follow-up question:\*\* <what to ask next>  
  
## No good answer yet  
- <concern, and what would be needed to answer it>
```

## Quality checks

- Every concern is phrased the way a customer would say it
- Every response is accurate and states limitations plainly
- Every proof point cites something that exists today
- Concerns without a good answer are flagged rather than papered over