Playbooks and triggers
Automate the customer lifecycle with playbooks that fire on milestones, health, and renewals.
Playbooks are how Airhop acts across the lifecycle. A playbook has a trigger (when to fire), a channel (where to reach the customer), and a message. They cover onboarding nudges, win-backs, churn-save plays, and renewal reminders, all driven by the product events and health you already feed in.
Trigger types
There are nine trigger types:
| Trigger | Fires when |
|---|---|
milestone | A contact reaches a milestone you defined. |
stalled | A contact reached one milestone but has not reached another after a delay. |
inactive | An activated contact goes quiet for a number of days. |
health_dropped | A contact's health band genuinely worsens. |
negative_call | A connected call is recorded with negative sentiment. |
renewal_approaching | An account's renewal date falls within a configured window. |
payment_failed | A payment fails for the account. |
invoice_overdue | An invoice goes overdue. |
usage_over_plan | Usage exceeds the plan entitlement (an expansion signal). |
The milestone and stalled triggers run off activation milestones; inactive, health_dropped, and negative_call run off health and activity; renewal_approaching runs off the account's renewal date; and payment_failed, invoice_overdue, and usage_over_plan run off connected revenue (Stripe or Measure).
Channels
A playbook can reach the customer through:
widget: a proactive message that appears in the chat widget, with an unread badge on the launcher when it is closed.email: an email from your workspace's support address.both: widget and email.
Message bodies support simple variables like {{name}} so each message is personalized.
Guardrails
Airhop is built to stay helpful, not spammy. A few limits keep the message set coherent:
- Per-playbook cooldown: a playbook will not message the same contact again within its cooldown window (7 days by default; longer defaults for health-dropped and renewal plays).
- Weekly frequency cap: across all playbooks combined, a contact will not receive more than a set number of playbook messages in a rolling 7 days (3 by default).
- Quiet hours: your workspace can set a quiet window — a start, an end, and a timezone. During it, automatic sends hold and draft for approval instead, then go out once the window closes, so a 2am milestone never pings a customer at 2am. Quiet hours is configured by our support team today, not yet a self-serve toggle.
The workspace outreach mode below sits on top of all of these: whatever a playbook's own autonomy, Review all still routes every message to the approval queue and Paused stops the agent proposing anything at all.
Autonomy and approval
Two settings decide whether a playbook sends on its own or drafts for a human first: a workspace-level outreach mode and each playbook's own autonomy.
Workspace outreach mode
The outreach mode switch on the Activation page governs every playbook at once:
- Active: each playbook acts on its own autonomy — sending or drafting as configured.
- Review all: every outreach drafts into the approval queue, regardless of a playbook's autonomy. Nothing reaches a customer without a person approving it.
- Paused: the agent proposes nothing — no sends, no drafts. A kill-switch for the whole workspace.
A new workspace starts in Review all. Automatic sending is something you turn on deliberately, once you have watched the agent draft a few times and trust it.
Per-playbook autonomy
In Active mode, each playbook falls back to its own autonomy:
- Draft for my approval (the default for a new playbook): the agent composes the message and parks it in an approval queue instead of sending. You review it, edit it if you want, then approve to send or dismiss.
- Send automatically: the agent composes the message and sends it within the guardrails above.
A new playbook always starts on Draft for my approval — auto-send is an explicit choice you make, never a default. Drafts appear in the Pending outreach panel on the Activation page, the human checkpoint before anything reaches a customer. A common pattern is to leave the high-stakes plays (a failed payment, a churn-risk save) on Draft for my approval, watch the agent get it right a few times, then switch them to Send automatically once you trust them.
Internal alerts to your own team (flagging an account that needs attention) are always immediate and never need approval; only customer-facing messages go through the queue.
Milestones and the Activation page
Playbooks build on milestones, which you define on the Activation page. A milestone is a rule over your events, for example "reached when the project_created event fires", and one of them can be marked as your activation milestone (the aha moment). The page shows your activation funnel, the events Airhop has actually received from your app, the SDK snippet, and the milestone and playbook editors.
Design your lifecycle with AI
Rather than start from blank rules, you can have Airhop propose them. The Design my lifecycle agent reads your knowledge base and the real events your app sends, then proposes activation milestones (mapped to your actual events) and a set of good and bad lifecycle touchpoints with drafted messages. You review the proposals with checkboxes, and applying them creates the milestones and playbooks for you.
Because the design agent reads the events you actually send, the more complete your product events are, the better its proposals. Send the few actions that signal real value first.