Address all customer complaints. Every one.

What the AI will do

• Discover where complaints arrive and reconstruct their path through messages, systems and people.
• Study delayed and unresolved cases alongside successful ones to locate missing handoffs and unnecessary waits.
• Design and test a faster process that accounts for every complaint in the agreed scope.

What you can provide

• The business, product or customer group you want to investigate.
• Access to relevant support systems, email, chat and case histories, or usable exports; the AI will identify missing sources.

Where you'll take part

• Explain gaps in how complaints arrive or move when the record cannot establish them.
• Confirm who can resolve different issues and choose the redesigned process to test.

What you'll get

A sourced complaint-to-resolution map and tested redesign when case histories are available. If you choose to proceed without them, a clearly provisional map and proposed process, with the missing verification identified.

Activity context

A customer complains. Where does that complaint go? Who sees it? How long before it reaches someone who can actually fix the problem—and how many complaints never get that far?

Have AI follow the trail. Start with recent complaints that took far too long or were never resolved, then use what happened to design a faster, more comprehensive route from “something is wrong” to someone doing something about it.

For the user

Name the area of the business. The AI will investigate the current process before asking you to reconstruct it. You help with missing context and consequential choices. Testing a redesigned route on historical cases can show whether it catches known failures; faster real-world resolution requires a live trial.

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 make the customer-complaint process much faster and more comprehensive. Begin by understanding how customers complain, where those complaints go and what happens until someone with the ability to resolve the issue sees and handles it. Reconstruct actual cases, identify why complaints are delayed or lost, then design and test a better process. Do not begin by drafting generic customer replies.

Discover how complaints enter the organization

Use the business, product or customer group I supplied to inspect available tools and source access. Search customer-service procedures, help-center contact routes, support-platform configuration, CRM records, account notes, customer emails, chats including WhatsApp where accessible, social-response records, contact forms, call transcripts, meeting notes and escalation guidance. Establish which channels customers actually use, including complaints initially received by salespeople, account managers or other people outside the formal support system.

Follow references from those records into related systems. Identify how a complaint becomes a case, who sees it, whether it gets an identifier, how responsibility is assigned and how the customer hears back. Search internal email and chat exchanges about forwarding, ownership, overdue cases and escalations. Use role records, actual handoffs and documented decisions to identify who can acknowledge a complaint versus who can authorize or perform a remedy.

Maintain an inventory of channels, systems, accessible records, date coverage and important gaps. Try connections before asking for exports. Investigate supported access routes and then ask a precise question about what you cannot establish. For example: “These cases begin when support opens a ticket. Where do complaints emailed directly to account managers go before that?” Explain which missing step the answer would clarify. Ask one question at a time while continuing unaffected investigation.

If the message trail is unavailable, explain early that recollection will produce an incomplete process hypothesis, not verified routing or timing. Help obtain targeted exports or linked examples. If adequate case trails remain unavailable, ask whether I want that explicitly limited reconstruction and wait before substituting it. With my agreement, produce a provisional map and proposed redesign, cite the supplied accounts, and name the records needed to verify each important step. Test only what the available evidence supports; label a synthetic walkthrough as such, never as a historical case replay. Carry this limited result through the remaining analysis, overview and final report. Do not say every complaint was examined when entire channels remain inaccessible.

Trace slow, lost and successful complaints

Agree a useful recent period and manageable scope using the available volume. Identify complaints with long resolution times, repeated follow-ups, reopened cases, unresolved status, customer escalation or apparent disappearance. Also select promptly resolved cases for comparison, including similar issue types when possible. Explain the selection and avoid drawing company-wide rates from a deliberately difficult-case sample.

For each case, join the original customer message to tickets, forwarded emails, internal chat, meeting discussions, engineering or operations work, remedy decisions and subsequent customer correspondence. Keep stable case and source identifiers. Preserve separate issues within one complaint, and link duplicate records without treating them as separate customers.

Construct a traceable timeline: customer first reports the issue; company receives it; someone notices; someone acknowledges it; ownership is assigned; it reaches a person able to resolve it; diagnosis and remedy work occur; a remedy is delivered; the customer is informed; and resolution is confirmed or remains unknown. These are investigative landmarks, not a presumed sequence. Record actual detours, reversals and reopenings.

Distinguish timestamps present in records from inferred events and missing evidence. A ticket being created does not prove a resolver read it. A closed status does not prove the customer received a remedy. Separate waiting time, active work time and time that cannot be classified. Where systems use different clocks or definitions, reconcile them before calculating elapsed intervals.

Find why the path breaks

For a substantial set of cases, assign bounded groups to investigators. Give them complete case trails, the same timeline fields, source requirements and the questions about handoffs and resolution. Use waves if necessary, track cases and channels covered, and have the lead reconcile shared incidents or duplicate threads. Without agents, use manageable passes with saved evidence and remaining coverage.

Compare failures and successful paths. Examine unmonitored channels, forwarding without ownership, repeated triage, missing customer information, authority limits, unclear escalation, queue capacity, cross-department dependencies and premature closure only where the records support them. Locate the exact step where the complaint waited, disappeared or reached someone unable to act. Distinguish an observed delay from a hypothesis about why it occurred; ask the relevant clarifying question rather than attribute motives to employees.

Produce the current process map and a few source-backed failure stories. Quantify coverage and timing only where comparable records support them. Show the route to a capable resolver as well as the route to a reply. Identify what must change to catch complaints that never become tickets.

Design the better route

Develop a practical redesign using the company's actual systems and decision rights. Specify intake across the agreed channels, a stable case record, accountable ownership, the information needed for a useful handoff, routing to a capable resolver, acknowledgment, escalation when progress stalls, customer follow-up and evidence required to mark resolution. Preserve a route for unusual or uncertain cases.

Explain which steps AI can perform: recognizing a complaint in a message, linking related records, assembling the useful context, suggesting or applying agreed routing, flagging overdue handoffs and preparing updates. Distinguish automation from work that still requires a person with technical expertise or remedy authority. Verify product-dependent capabilities against current official documentation before relying on an integration.

Offer meaningful alternatives only where the company faces a real choice. For the recommended design, show a worked example using a delayed case: what would arrive, what the system would notice, where it would go, who would act and what happens if nobody responds. Explain how each change addresses an observed failure. Have me confirm consequential ownership and process choices; do not assign colleagues new duties through an inferred agreement.

Test the redesign and deliver the usable process

Create the routing rules, reusable prompts, case-record fields, escalation conditions and sample outputs needed to try the design. Build an executable pilot where the environment permits. Where usable historical trails are available, test against held-back historical cases, including a complaint outside the main support channel, an ambiguous owner and a reopened case. On the agreed limited reconstruction path, use supported examples and explicitly labeled hypothetical walkthroughs; historical validation remains unfinished until the missing records are obtained. Check whether every case is accounted for, relevant evidence reaches the resolver, duplicates are linked and unresolved states remain visible. A fabricated event is a test fixture, not a historical observation.

Give a separate reviewer the proposed process, test cases, outputs and source evidence without your defense. Ask it to look for lost channels, unsupported routing authority, unnecessary handoffs and false closure. Repair substantive findings and rerun affected cases. Use a fresh session or clearly identified shared-context check if independent review is unavailable.

A historical replay can establish that the route handles known cases; it cannot prove how quickly real people will respond. Define a bounded live trial with baseline measures, channel coverage, time to a capable resolver, resolution evidence and an owner for exceptions. Start it only if the necessary operational authorization and access are actually given. Otherwise deliver the tested design and runnable trial materials, with the live results still unmeasured.

Deliver the current and proposed maps, the consequential case histories, supported findings, working pilot or complete process artifacts, test results and the specific unresolved access or ownership questions. State exactly what scope is covered. The aim is a complaint process that notices more, loses less and gets issues to people who can fix them; do not claim every customer problem is solved because every ticket has a status.

Done when

With usable case histories, you have traced actual complaint journeys and tested a concrete redesign. If you explicitly chose a limited reconstruction, you have a provisional map and proposed redesign with hypothetical walkthroughs distinguished from historical validation and the missing records identified. Any live performance improvement remains measured or explicitly untested.

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.