Prepare a cancellation survey for human review

Verify the cancellation signal, review a minimal survey and targeting rule, and summarize bounded responses without inventing benchmarks or contacting customers.

Updated · published

markdown for agents →

difficulty intermediate · time to value 15 minutes · execution human review required
#analytics #surveys #churn #customer-research #privacy #human-review

Start from this 

Prepare a short cancellation survey for review. Verify the real cancellation event and targeting boundary, minimize personal data, show the exact survey definition before creation, and summarize only a bounded response window after a human approves it.

Why this matters

Cancellation feedback can explain gaps that behavioral data cannot, but survey creation, targeting, and response review are human-governed operations. Poor targeting can prompt the wrong users; leading questions produce weak evidence; and free text can contain personal or sensitive information.

Use Agentry to verify the cancellation signal, prepare a minimal definition, and read a bounded response window in an authenticated interactive session.

What you get

  • A verified cancellation targeting signal
  • A concise, neutral survey definition for review
  • Explicit activation, audience, consent, and stop conditions
  • A bounded aggregate/theme summary with privacy and sample caveats

Walk through it

You

Prepare a cancellation survey, but do not create it until I review the definition.

Agent

I will verify the cancellation signal and fetch the current cohort and survey schemas. I will stop with a reviewable candidate.

GET /v1/projects/:project_id/signal-map
GET /v1/projects/:project_id/onboarding
# Require status: "verified"; use live event/property reads for the selected signals.
GET /v1/projects/:project_id/event-names
GET /v1/openapi.json?tag=Surveys

The candidate should state the exact eligible event, lookback, display location, dismissal behavior, questions, allowed answer types, consent text, owner, and deactivation condition. Example questions:

  1. What was the main reason you canceled?
  2. What, if anything, would have made the product more useful?
  3. May we contact you about this response? yes/no—never assumed.

After a human reviews the current OpenAPI-defined request, cohort and survey creation are separate explicit mutations. Do not claim the survey is live until the API confirms the created resource and the real application rendering path has been exercised.

When responses exist, read only an approved bounded window:

GET /v1/projects/:project_id/surveys/:survey_id/responses

Keep response distribution separate from bounded raw responses. Do not place owner credentials or raw feedback in a scheduler; no current versioned automation template grants survey-response or messaging authority.

The output

Cancellation survey review

Definition
- target signal and eligibility window
- questions, consent, display and stop behavior

Readiness
- event observed: yes | blocked
- app rendering verified: yes | blocked
- owner approval: pending | approved

Bounded response summary, after launch
- response window and count
- themes meeting the minimum count
- contradictory/minority themes
- privacy and sample caveats

Human decisions
- edit | create | activate | pause | investigate

Setting it up

Emit the cancellation outcome from the trusted billing webhook or server using AGENTRY_SERVER_API_KEY. Include only necessary plan or tenure context and a stable pseudonymous identity. Never copy card data, invoice details, support messages, or cancellation free text into analytics properties.

Verify the browser survey-rendering path with the selected consent and redaction policy before broad activation. Keep question changes versioned so responses from materially different wording are not combined silently.

Variations

  • “Prepare a downgrade survey with a different, reviewed target event.”
  • “Summarize only themes with at least five responses and list the rest as sparse.”
  • “Compare response themes by plan without exposing individual respondents.”
  • “Pause the exact survey after the owner confirms its ID and reason.”

Related workflows

growth 15 minutes

Identify behavioral churn-risk signals

Compare pre-renewal behavior for retained and canceled customers, quantify associations, and prepare a reviewed risk hypothesis without claiming prediction.

ops 10 minutes

Review account-health evidence before outreach

Combine verified account usage, revenue context, and support-friction signals into a review queue without pretending a universal score proves churn or intent.

growth 7 minutes

Detect lifecycle email fatigue

Correlate email volume, opens, clicks, unsubscribes, activation, and churn to find where lifecycle messaging helps or hurts.

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access
5.5 Extra High
  1. 1. Open your repo in Codex, Claude Code, Cursor etc.
  2. 2. Paste the install prompt.
  3. 3. Your agent reads the install doc and shows you an implementation plan for approval.
← all workflows