Support Inbox Simulation

Use this skill to simulate the messy human exhaust of a launch: vague bug reports, annoyed reviews, refund requests, and exhausted follow-up threads.

This skill is for answering:

• What will users actually say when this breaks?
• Which failures become expensive to diagnose?
• Which support issues compress into the public story of the product?

When to Use

Use this skill when reviewing:

• launch readiness
• onboarding and activation
• support tooling and diagnostics
• pricing or packaging changes
• status and failure messaging
• any feature likely to produce “not working” tickets

Use trust-audit instead when the question is whether the product feels safe (permissions, privacy, billing, file changes); use status-copy-trust-audit instead for CLI/status wording fixes. This skill predicts the support load those problems create.

Core Principle

A support burden is not just the number of issues. It is:

• how vague the first report is
• how many rounds it takes to diagnose
• how emotionally charged the issue feels
• whether the same confusion repeats across users

Step 1: Gather the likely support context

Read enough context to understand:

• target user sophistication
• launch channel
• product promise
• likely failure points
• what diagnostics/support summary currently exist
• what support actions are currently easy vs annoying

Then list:

• the 5-10 most likely reasons someone would contact support
• the 3-5 most likely reasons they would not contact support and instead churn, refund, or complain publicly

Step 2: Simulate the inbox

Generate a realistic mix of artifacts:

• 4-8 support emails or chat messages
• 3-5 App Store / public reviews
• 2-4 refund requests or cancellation notes
• 2-3 “this is probably user error but still your problem” complaints

All artifacts are fabricated illustrations derived from the product's real failure points. Label them as simulated and never present them as actual user feedback. Ground each one in a specific flow or message you actually read.

Make them feel real:

• incomplete facts
• emotional language
• wrong assumptions
• screenshots described badly
• contradictory details
• users blaming the product, themselves, or the platform

Step 3: Triage each artifact

For each simulated item, add:

• What really happened
• Why the user described it this way
• What facts are missing for diagnosis
• How many back-and-forths it would probably take
• How fixable the support burden is — product fix / copy fix / diagnostics fix / docs fix / unavoidable

Step 4: Find the support sinkholes

Identify the issues that are worst because they are:

• frequent but vague
• rare but emotionally explosive
• difficult to distinguish from user error
• impossible to resolve without diagnostics the product does not collect
• repetitive enough to become maintenance drag

Step 5: Present the simulation

Use this format:

# Support Inbox Simulation: [Product / Feature]

## Executive Read
- Most likely support subject line:
- Most expensive recurring ticket:
- Most likely refund reason:
- Public review story most likely to spread:

## Simulated Inbox

### Support Emails
#### 1. Subject: ...
[message]
**What really happened:**
**Missing facts:**
**Estimated support rounds:**
**Best fix type:**

### Public Reviews
#### 1. ★★☆☆☆ “...”
[review]
**Underlying issue:**
**What story this reinforces:**

### Refund / Cancellation Notes
...

## Support Sinkholes
- [Issue] — why it will eat time
- [Issue] — why diagnostics fail

## Highest-Leverage Support Fixes
1. [ ]
2. [ ]
3. [ ]

## Support Summary / Diagnostics Missing Today
- [missing field]
- [missing field]
- [missing field]

Success Criteria

The simulation is successful when it makes support feel painfully concrete and identifies:

• what users will actually say
• what facts support will be missing
• which issues become maintenance drag
• which single diagnostics or UX fix would cut the burden most