# Track waitlist to activation

> See which waitlist cohorts convert after invite, where they stall, and whether invite timing changes activation quality.

## Agent adaptation contract

- Canonical human page: https://agentry.sh/workflows/waitlist-to-activation
- Execution mode: on_demand
- Immutable automation template: none
- Applies to: b2c-saas, b2b-saas, content-media, games, mobile-app
- Required example events: waitlist_joined, invite_accepted, activated
- Required Agentry resources: none declared
- Do not use when:
  - Do not use until the example events are mapped to observed project signals, the current onboarding state is verified, and live event/property reads prove the required data is present.
- Ask before using:
  - Which observed events map to waitlist_joined, invite_accepted, activated? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
  - Which live properties provide waitlist_joined.source, waitlist_joined.cohort, invite_accepted.invite_id, activated.source, and which stable user or account identifier joins the signals?

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

Waitlists create demand, but delayed access can cool intent. This workflow shows whether your invite cadence turns demand into activation.

## What you get

- Waitlist cohort conversion
- Invite acceptance and signup rate
- Activation after invite
- Source quality and timing effects

## Walk through it

**You:**
> How well does our waitlist convert after invites?

**Agent:**
> I'll build a waitlist-to-activation funnel by cohort and source.

```text
Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT properties.cohort AS cohort, properties.source AS source, countIf(event = 'waitlist_joined') AS joined, countIf(event = 'invite_accepted') AS accepted, countIf(event = 'activated') AS activated FROM events WHERE event IN ('waitlist_joined','invite_accepted','activated') GROUP BY cohort, source ORDER BY joined DESC"
```

## The output

The agent returns cohort conversion and recommends whether to invite faster, change messaging, or segment by source.

## Setting it up

Emit waitlist and invite lifecycle events. Preserve source and cohort through signup and activation.

## Variations

- *"Compare invites sent within 7 days vs after 30 days."*
- *"Find sources with high waitlist joins but low activation."*
- *"Publish this for launch planning."*