Create a customer defection predictor.

What the AI will do

• Examine customer history, usage, support and correspondence to identify plausible early signs of departure.
• Build a repeatable prototype and, when the history permits, test whether it identifies departures early enough to help.
• Create a reviewable list of current accounts and a way to improve the predictor as outcomes arrive.

What you can provide

• The customer group or business you want to understand.
• Available customer, renewal, usage and relationship records; an incomplete history can support an early prototype.

Where you'll take part

• Agree what counts as a departure and how much advance notice would be useful.
• Review flagged accounts and practical follow-up choices, then contribute outcomes and corrections to improve later versions.

What you'll get

A working, repeatable customer-risk prototype with evidence behind each flag, an honest account of its validation and a path to refinement with more information.

Activity context

A customer rarely goes from delighted to gone in a single moment. Your records may contain earlier clues: a change in usage, a recurring complaint, a sponsor who stops showing up. Start with a useful prototype that brings those clues together, then refine it as you collect more information and see what actually happens.

For the user

Tell the AI which customers or business you have in mind. It will discover and inspect the relevant records before asking you to gather anything. You'll help define the outcome and useful warning period, then review what it builds. Sparse data is a reasonable starting point: the first version may be an explicitly unvalidated set of signals that gets better with real outcomes.

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

Build a customer defection predictor for my business. A useful early prototype is welcome. Make it increasingly refined as more information becomes available, and distinguish a working prototype from a predictor whose performance has been validated.

Establish the customers, outcome and available history

Use my starting context to identify the business, customer group and account identifiers. Inspect and try access to customer and renewal records, contracts, invoices, product or service usage, support tickets, customer emails and chat, account notes, meeting transcripts and calendar records of customer meetings. Search relevant internal correspondence and reports for explanations of earlier losses, relationship changes, expected renewals and previous risk measures. Use these sources to understand the business and discover candidate signals; a retrospective explanation of a departure is not automatically an early predictor.

Build a compact coverage map showing date ranges, accounts, fields, source access and missing history. Check identity matching, definitions, duplicate accounts, update times and whether historical states exist. If access fails, investigate usable connections or permitted exports before asking me for one specific access action or sample. Do substantive work with what is available while explaining what it cannot establish.

From the records, propose the customer group, a precise outcome such as cancellation or nonrenewal, and a warning horizon that would allow useful action. Distinguish defection from downgrade, a late invoice, an inactive user or a contract still awaiting its outcome. Ask me to resolve the consequential definitions one at a time. Agree these and the practical capacity for reviewing flagged accounts before testing or producing a current list.

Build an honest first version

Create an account history with observation dates, later outcomes where known and features available at each observation date. Inspect plausible signals such as changes in usage, unresolved support problems, sponsor changes or reduced engagement, using definitions that fit this business. Identify whether each signal is an observed measurement, a sourced relationship observation or an inference from text. Keep source references and dates.

Exclude information that would not have been known when the warning was supposed to occur. Cancellation messages, fields updated after departure and summaries written with hindsight must not leak the answer into a supposed early prediction. If historical records cannot reconstruct what was known then, state that limitation rather than using current snapshots as past evidence.

Choose the simplest method that fits the available data and can be inspected and rerun. With little labeled history, build an explicitly unvalidated rule-based prototype that flags accounts for human review, explains the signals and records missing information. Don't invent risk percentages. With enough examples and usable history, compare a simple existing or transparent baseline with any more complex method; complexity needs demonstrated value. Inspect available analysis tools and implement the chosen approach yourself. If code execution is unavailable, seek an available runnable alternative or prepare a transferable implementation and state the execution blocker.

Test whether it gives useful early warning

When the history permits, develop the method on earlier periods and evaluate it on a later period held out from development. Preserve account boundaries as appropriate and keep tuning away from the held-out results. Check that each evaluated account has had enough time for the chosen outcome to become known. Record the number of departures, nondepartures and unresolved outcomes.

Compare the method with the agreed baseline at a review volume the team can actually handle. Show how many flagged accounts later departed, how many departing accounts were caught, false alarms, missed departures and useful lead time. Report quantities and denominators, not an impressive accuracy figure detached from how rare departures are. Check materially different customer groups and explain when samples are too small for a reliable comparison. If providing probabilities, examine whether predicted levels match observed outcomes; otherwise use clearly explained review priorities.

Inspect apparent successes for timing leakage and data-quality artifacts. Use a separate reviewer where available to examine feature timing, outcome definitions and the actual evaluation evidence. For large source collections, divide extraction or account review into bounded assignments with sources, definitions, dates and explicit coverage; reconcile centrally. If agents are unavailable, use distinct passes and record what they cover. Repair material findings before reporting validation. If there is too little suitable history, deliver the working prototype with an explicit statement that predictive performance is unknown and specify the observations needed for a future evaluation.

Produce a current review list and make it usable

Run the chosen version on the agreed current customer group using only information available as of a stated date. Deliver the accounts meriting review, evidence and dates behind each flag, missing information and the intended warning horizon. Distinguish explanatory associations from established causes. Show a few accounts against their underlying records, including one with little information, so I can judge whether the output is intelligible and relevant.

Ask me to review a manageable sample. Incorporate factual corrections and identify sensible next questions for account owners. Keep proposed customer outreach separate from the analysis; don't contact customers on my behalf without authorization. A flag is a reason to examine an account, not a finding that the customer has decided to leave.

Create the refinement loop

Save a versioned, rerunnable implementation, input definitions and each scoring date. Provide a simple way to record corrections, eventual outcomes and any intervention after a flag. Keep interventions visible because they can change later outcomes. Define the refresh and evaluation cadence with me and identify who will maintain access and receive the review list.

As new information arrives, assess missing-data improvements, add justified signals and compare candidate versions with the existing method on appropriate later data. Preserve earlier versions and evaluations so improvement can be demonstrated. Implement and test automatic refresh if the available tools and agreed scope support it; otherwise provide a tested manual run and clearly state that scheduled operation is not active.

Hand over the working artifact, current review list, validation evidence or its explicit absence, and concise instructions for rerunning and supplying corrections. Explain what this version can do now and which additional information would most improve the next version. The completed result can be an early prototype; do not describe it as validated until the evidence supports that claim.

Done when

You have a working, repeatable prototype, a current account review list and an evidence-based account of its performance—or an explicit statement that it is unvalidated—plus a practical way to add outcomes and improve 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.