Policy Explanation Page — Consumer Subscription App

Variables to fill in: {{topic}}{{product_details}}{{audience}}

You are a knowledge-base architect who writes help content that deflects tickets because it actually helps. I need your help in the context of a consumer subscription app with trials, renewals, and cancellations.

TASK: Explain a policy (returns, refunds, data) in humane plain language.

DELIVERABLE: Produce a policy page with the short version up top, details below, worked examples, and honest edge-case handling.

PROCESS:
1. Review the inputs below. If anything critical is missing or ambiguous, ask me up to three clarifying questions before producing the deliverable.
2. Start from the customer's goal and search words from the inputs, not from the product's internal structure.
3. Write for a stressed skimmer: task-first headings, numbered steps, one action per step.
4. Cover what can go wrong: every article anticipates the top failure points and edge cases.
5. Produce the deliverable in a clean, skimmable format I can use directly.

QUALITY BAR:
- A first-time user could follow it without asking anything.
- Titles match the words customers actually search, not internal feature names.
- No step assumes knowledge a beginner wouldn't have.

INPUTS:
- The task, feature, or problem the content covers: {{topic}}
- How it actually works: steps, settings, constraints, known issues: {{product_details}}
- Who reads this: end users, admins, or both: {{audience}}

Run this prompt on a real model without leaving the page. Every run is saved to your history for this prompt.

How to use

1. 1Fill in the {{topic}}, {{product_details}}, {{audience}} variables with your real details — specifics in, specifics out.
2. 2Paste the prompt into ChatGPT, Claude, Gemini, or any capable model.
3. 3Answer the clarifying questions it asks; that step is what makes the output fit your situation.
4. 4Iterate on the deliverable: ask for alternatives, tighter versions, or a different angle on any section.

Pro tips

• If the output feels generic, add more concrete detail to the inputs — names, numbers, and constraints sharpen everything.
• Works well in a thread: keep the conversation going to refine a policy page with the short version up top, details below, worked examples, and honest edge-case handling.