Turn a customer complaint into a new offering.
A complaint can contain the outline of something customers would want to buy: a result they cannot get, a workaround they resent or a job nobody seems to own. Investigate the need, then make the possible offer concrete.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Trace the complaint through support, sales and product records to understand the need, recurrence and failed workarounds.
- Use separate investigations for similar needs, alternatives and delivery feasibility, then develop an offer, a sample customer experience and a small demand test.
What to have ready
- A complaint in its original form if available: a support ticket, email, call excerpt or rough account.
- Relevant customer or product context and access to support, sales and product records; no polished brief is required.
Where you come in
- Clarify consequential uncertainty and choose the opportunity to develop.
- Review the proposed customer experience and test assumptions before any customer outreach or launch.
What you'll get
A concrete offering hypothesis with a worked example of the customer experience and a ready-to-run demand test, clearly separating observed need from unproven willingness to pay.
You're done when
You have an evidence-grounded offering hypothesis, a concrete example of the customer experience and a reviewed demand-test package; actual demand remains untested until the test is run.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. Help me turn a customer complaint into a concrete new offering hypothesis. Investigate the unmet need, create an offer and example customer experience, and prepare a small demand test. Keep observed evidence distinct from inferred opportunity and demonstrated willingness to pay. ### 1. Read the complaint and reconstruct the situation Begin with the actual complaint I supplied. Identify what the customer was trying to accomplish, what happened, the consequence and the workaround or remedy they sought. Preserve meaningful wording and emotional stakes without turning an angry phrase into a general market claim. If I supplied only an account, label it as recollection and seek the original record when accessible. Inspect and try relevant connections. Search linked support tickets, customer emails, chats including WhatsApp where accessible, sales and renewal call transcripts, calendar-linked account discussions, product documentation and issue histories. Look for the original promise, product version, sequence of events, attempted fixes and eventual outcome. Identify the customer’s role, use case, purchaser and affected users from records rather than a guessed persona. Track dates and changes: a resolved defect, changed product or later agreement may alter the opportunity. Distinguish event dates from the date someone reported them. Ask one useful question when a consequential ambiguity remains, and wait on dependent interpretation. If records are inaccessible, investigate permitted connections, exports or uploads before asking me for specific material. Rough notes are welcome, but explain early that missing support history or customer evidence prevents establishing recurrence and resolution. An interview can orient a hypothesis, not establish an unseen customer history. ### 2. Find the need beneath the requested fix Separate the customer’s desired result from their proposed solution. Describe the situation, obstacle, current workaround and cost in time, money, effort or lost opportunity, using sourced evidence where available. Distinguish a broken promise requiring a remedy from an additional valuable service someone might choose to buy. Do not assume every complaint should become a chargeable offering. Search adjacent tickets, account notes, lost-deal reasons, sales questions and product feedback for similar situations. Group records by underlying need rather than repeated keywords. Record how many distinct customers appear, the period and corpus searched, duplicates and counterexamples. A cluster in accessible tickets is not a market prevalence estimate. Identify plausible audiences from observed customers and roles. Separate the user experiencing the pain from the buyer with authority and budget. Mark any proposed broader segment as a hypothesis. ### 3. Run separate opportunity investigations Use separate agents where available for three bounded questions: similar needs in the customer record; existing internal and external alternatives; and delivery feasibility in our organization. Give each exact sources, the original complaint, its question, deliverable fields and completion criterion. Require source-linked findings, counterevidence, unknowns and a coverage account. Keep their first findings independent until reconciliation, and use waves as capacity requires. The alternatives investigator should examine existing products, service descriptions and current official pricing where relevant, plus workarounds customers actually use. The feasibility investigator should inspect product constraints, staffing, processes, delivery costs and dependencies in available internal records. Do not invent capabilities or quote unsupported margins. If agents are unavailable, use bounded passes or fresh sessions with explicit source, decision and coverage handoffs. Disclose shared-context review. Reconcile the investigations into a few materially different opportunity directions only if the evidence supports them; explain the need served and main unresolved assumption for each. ### 4. Choose and make the offer tangible Recommend a promising direction based on evidence, including a remedy or improvement rather than a new paid offer when appropriate. Ask which direction I want developed and wait, unless I have already chosen it. Do not treat your selection as mine. For the selected direction, write a concrete offer: - Who it serves and the situation that makes it useful. - The outcome promised, what is included and what falls outside it. - How the customer starts, what they provide, what happens and what they receive. - Delivery responsibilities, plausible timing and operational dependencies. - A proposed price or commercial model when appropriate, labeled as a hypothesis with its basis. Create a worked example of the customer experience: the invitation or offer description, the first interaction, a sample deliverable or service exchange, and how the customer judges the result. Use illustrative details openly; do not invent testimonials, customer quotes or validated outcomes. Make the central experience sufficiently concrete that I can react to it. ### 5. Design a small test and review the package Design a bounded demand test that probes the riskiest assumption. Specify eligible participants based on observed roles, a recruitment draft, exact offer or prototype they would see, the commitment being requested, success and failure criteria, time window and how findings would change the offer. Distinguish interest, willingness to try, budget authority and willingness to pay. A simulated customer reaction cannot validate demand. Give an independent reviewer the actual offer, example, test materials and source evidence without the author’s rationale. Ask it to check fidelity to the complaint, evidence for the audience, feasibility assumptions, clarity of the experience and whether the test measures the claimed demand. Repair material findings. Use a fresh session where possible and identify a shared-context fallback honestly. Deliver the offering brief, worked customer experience, source-linked need evidence and ready-to-run test materials. Label what is observed, inferred and still to be tested. Stop before outreach, charging, launching or claiming validation. The completed result is a concrete hypothesis and a test design, ready for a separate decision to run it. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
View full AI instructions
Turn a customer complaint into a new offering.
What the AI will do
- Trace the complaint through support, sales and product records to understand the need, recurrence and failed workarounds.
- Use separate investigations for similar needs, alternatives and delivery feasibility, then develop an offer, a sample customer experience and a small demand test.
What you can provide
- A complaint in its original form if available: a support ticket, email, call excerpt or rough account.
- Relevant customer or product context and access to support, sales and product records; no polished brief is required.
Where you'll take part
- Clarify consequential uncertainty and choose the opportunity to develop.
- Review the proposed customer experience and test assumptions before any customer outreach or launch.
What you'll get
A concrete offering hypothesis with a worked example of the customer experience and a ready-to-run demand test, clearly separating observed need from unproven willingness to pay.
Activity context
A complaint can contain the outline of something customers would want to buy: a result they cannot get, a workaround they resent or a job nobody seems to own. Investigate the need, then make the possible offer concrete.
For the user
Bring a complaint that caught your attention. The AI will investigate what happened and whether similar needs appear elsewhere, then help you choose and develop a specific offer. It will write the customer experience and test materials. Missing customer records make the hypothesis weaker, and designing the test does not demonstrate demand.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Help me turn a customer complaint into a concrete new offering hypothesis. Investigate the unmet need, create an offer and example customer experience, and prepare a small demand test. Keep observed evidence distinct from inferred opportunity and demonstrated willingness to pay.
1. Read the complaint and reconstruct the situation
Begin with the actual complaint I supplied. Identify what the customer was trying to accomplish, what happened, the consequence and the workaround or remedy they sought. Preserve meaningful wording and emotional stakes without turning an angry phrase into a general market claim. If I supplied only an account, label it as recollection and seek the original record when accessible.
Inspect and try relevant connections. Search linked support tickets, customer emails, chats including WhatsApp where accessible, sales and renewal call transcripts, calendar-linked account discussions, product documentation and issue histories. Look for the original promise, product version, sequence of events, attempted fixes and eventual outcome. Identify the customer’s role, use case, purchaser and affected users from records rather than a guessed persona.
Track dates and changes: a resolved defect, changed product or later agreement may alter the opportunity. Distinguish event dates from the date someone reported them. Ask one useful question when a consequential ambiguity remains, and wait on dependent interpretation.
If records are inaccessible, investigate permitted connections, exports or uploads before asking me for specific material. Rough notes are welcome, but explain early that missing support history or customer evidence prevents establishing recurrence and resolution. An interview can orient a hypothesis, not establish an unseen customer history.
2. Find the need beneath the requested fix
Separate the customer’s desired result from their proposed solution. Describe the situation, obstacle, current workaround and cost in time, money, effort or lost opportunity, using sourced evidence where available. Distinguish a broken promise requiring a remedy from an additional valuable service someone might choose to buy. Do not assume every complaint should become a chargeable offering.
Search adjacent tickets, account notes, lost-deal reasons, sales questions and product feedback for similar situations. Group records by underlying need rather than repeated keywords. Record how many distinct customers appear, the period and corpus searched, duplicates and counterexamples. A cluster in accessible tickets is not a market prevalence estimate.
Identify plausible audiences from observed customers and roles. Separate the user experiencing the pain from the buyer with authority and budget. Mark any proposed broader segment as a hypothesis.
3. Run separate opportunity investigations
Use separate agents where available for three bounded questions: similar needs in the customer record; existing internal and external alternatives; and delivery feasibility in our organization. Give each exact sources, the original complaint, its question, deliverable fields and completion criterion. Require source-linked findings, counterevidence, unknowns and a coverage account. Keep their first findings independent until reconciliation, and use waves as capacity requires.
The alternatives investigator should examine existing products, service descriptions and current official pricing where relevant, plus workarounds customers actually use. The feasibility investigator should inspect product constraints, staffing, processes, delivery costs and dependencies in available internal records. Do not invent capabilities or quote unsupported margins.
If agents are unavailable, use bounded passes or fresh sessions with explicit source, decision and coverage handoffs. Disclose shared-context review. Reconcile the investigations into a few materially different opportunity directions only if the evidence supports them; explain the need served and main unresolved assumption for each.
4. Choose and make the offer tangible
Recommend a promising direction based on evidence, including a remedy or improvement rather than a new paid offer when appropriate. Ask which direction I want developed and wait, unless I have already chosen it. Do not treat your selection as mine.
For the selected direction, write a concrete offer:
- Who it serves and the situation that makes it useful.
- The outcome promised, what is included and what falls outside it.
- How the customer starts, what they provide, what happens and what they receive.
- Delivery responsibilities, plausible timing and operational dependencies.
- A proposed price or commercial model when appropriate, labeled as a hypothesis with its basis.
Create a worked example of the customer experience: the invitation or offer description, the first interaction, a sample deliverable or service exchange, and how the customer judges the result. Use illustrative details openly; do not invent testimonials, customer quotes or validated outcomes. Make the central experience sufficiently concrete that I can react to it.
5. Design a small test and review the package
Design a bounded demand test that probes the riskiest assumption. Specify eligible participants based on observed roles, a recruitment draft, exact offer or prototype they would see, the commitment being requested, success and failure criteria, time window and how findings would change the offer. Distinguish interest, willingness to try, budget authority and willingness to pay. A simulated customer reaction cannot validate demand.
Give an independent reviewer the actual offer, example, test materials and source evidence without the author’s rationale. Ask it to check fidelity to the complaint, evidence for the audience, feasibility assumptions, clarity of the experience and whether the test measures the claimed demand. Repair material findings. Use a fresh session where possible and identify a shared-context fallback honestly.
Deliver the offering brief, worked customer experience, source-linked need evidence and ready-to-run test materials. Label what is observed, inferred and still to be tested. Stop before outreach, charging, launching or claiming validation. The completed result is a concrete hypothesis and a test design, ready for a separate decision to run it.
Done when
You have an evidence-grounded offering hypothesis, a concrete example of the customer experience and a reviewed demand-test package; actual demand remains untested until the test is run.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.