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. Two 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).
Autonomy and approval
Every playbook has an autonomy setting that decides what happens when it fires:
- Send automatically: the agent composes the message and sends it within the guardrails above.
- Draft for my approval: 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.
Drafts appear in the Pending outreach panel on the Activation page, the human checkpoint before anything reaches a customer. A common pattern is to start the high-stakes plays (a failed payment, a churn-risk save) in Draft for my approval, watch the agent get it right a few times, then flip 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.