# 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.

## Agent adaptation contract

- Canonical human page: https://agentry.sh/workflows/churn-survey
- Execution mode: human_review
- Immutable automation template: none
- Applies to: b2c-saas, b2b-saas, devtools-api
- Required example events: subscription_canceled
- Required Agentry resources: signal_map, onboarding_state, surveys, analytics
- Do not use when:
  - Do not create or activate a survey when the cancellation event, targeting semantics, consent, or rendering path is unverified.
  - Do not claim generic response-rate benchmarks or invent a public survey URL.
  - Do not automatically email respondents, identify quote authors, or turn free-text responses into outreach targets.
- Ask before using:
  - Which observed event represents a completed cancellation, and when should the survey be eligible to render?
  - Who approves the questions, targeting, consent language, response window, and minimum theme count?
  - Which fields are necessary for analysis, and which personal or sensitive data must be excluded?

This is an adaptable workflow example, not an API recipe. Map event and property names to the project's saved signal map, require status: "verified" from GET /v1/projects/:project_id/onboarding, and confirm the required signals through live event/property metadata and rows. Fetch current OpenAPI or query-blueprint details before making calls. Do not infer unattended authority from this page.

## 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.

```http
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:

```http
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

```text
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."*