Actions
Playbooks are the rules that decide what your team should work on. A playbook watches your connected data, and when it fires it generates an action: a specific, do-this-today item like a feature release that matches what 37 customers asked for, an account whose usage just dropped 40%, or a champion who switched companies last week.
Your actions stack up into one ranked list. Instead of opening five tools to figure out where to spend the morning, you open Sonora and work the queue top to bottom. Each action carries the context behind it and — when the right move is outreach — a drafted email built from the customer’s actual history.
The mental model is two layers. You configure playbooks once. They run continuously and produce actions as conditions are met. You spend your day in the actions, not the playbooks.
What an action looks like
Section titled “What an action looks like”“37 customers requested SSO. It shipped yesterday.” The action includes a draft announcement email referencing each customer’s original ask. Review, edit if you want, send — or push it to your email sequencer.
“Product usage at Acme Corp dropped 40% over the last two weeks.” Context shows which features stopped being used, when the drop began, and three related support tickets about login issues that opened the same week.
“Sarah Johnson, your champion at TechStart Inc., updated her LinkedIn to a new company.” Engagement from other contacts dropped 60% over the last month. The action suggests scheduling a call to identify replacement stakeholders before the renewal cycle starts.
How playbooks generate actions
Section titled “How playbooks generate actions”A playbook is a rule with three parts: what it watches, the conditions it checks, and the action it creates when those conditions hold. Sonora watches connected data for the patterns you care about — feature requests trending across customers, usage declines past your threshold, support ticket spikes, champion job changes, sentiment shifts, renewals approaching with falling health, competitors mentioned on recent calls. When a playbook fires, the action it generates carries the data backing it: links to the calls, tickets, or trend lines you’d want to see before reaching out.
You can start from a template — renewal prep, low health score, support ticket surge — or build a playbook from scratch. Each one targets a customer, contact, or meeting and sets the priority that ranks its actions in the queue.
Actions fall into three buckets:
- Outreach opportunities — feature releases that match prior asks, re-engagement for accounts that have gone quiet, intro requests when a contact joins a new account.
- Risk signals — usage declines, champion departures, negative sentiment trends, escalation watches.
- Growth signals — accounts hitting plan limits, expansion into new departments, sustained champion advocacy.
Drafted emails
Section titled “Drafted emails”When the right action is outreach, the playbook can draft the message using the customer’s history — past requests, recent tickets, usage trajectory — and your team’s tone from prior emails. Drafts are starting points: edit them before sending, and Sonora learns from edits over time.
Working through the queue
Section titled “Working through the queue”Actions are ranked by estimated impact. Open one, scan the context, send or skip the draft, then mark it done. Dismiss anything that doesn’t apply — you can tune the playbook that generated it so similar actions stop appearing. Completed actions archive for reference, including what you ended up sending, so the team can reuse phrasing that worked.
You can act from inside Sonora, or push outward: send mail directly through Gmail (with Google Workspace configured), create Salesforce or HubSpot tasks, drop reminders into Slack, or push to an outbound sequencer.
Where the signals come from
Section titled “Where the signals come from”Playbooks draw on the same enrichment pipeline as agents, so when you tune a health signal or escalation threshold, the playbooks that watch it respect the change immediately. Activity from People Graph — champion departures, sentiment shifts — feeds in directly.
Keeping a playbook private
Section titled “Keeping a playbook private”A private playbook is one only you can see — useful while you build, test, and tune it (and the enrichments behind it) before showing unfinished work or sensitive signals to your workspace. Playbooks start private by default and run normally while private: they evaluate triggers, fire on schedule, and generate actions, but only you see those actions.
Actions inherit their playbook’s visibility and can’t be published on their own. They go public when the playbook does, and the full history comes with them.
Enrichment configs can be private too. A private enrichment is visible only to you — it stays out of the enrichment picker for other users and won’t auto-link to playbooks they create. You can publish an enrichment on its own, separate from any playbook.
Going public
Section titled “Going public”Publishing is permanent: once a playbook or enrichment is public, it stays public.
When you publish a playbook, it becomes visible to everyone in your workspace, and every action it has ever generated appears at once — your team sees the full history, not just future actions. A playbook can only go public once all of its linked enrichments are already public; Sonora tells you which ones to publish first. Publishing those enrichments is a separate step and doesn’t publish the playbook.
Publishing an enrichment makes its entire version history public and lets workspace members find it in the picker and link it to their own playbooks. It doesn’t publish any playbook that uses it — each owner still decides when, or whether, their playbook goes public.
Combining private and public
Section titled “Combining private and public”As long as you own both, you can link a private enrichment to a private playbook and build the whole workflow privately — enrichment, playbook, and actions — then publish it all when it’s ready. A public playbook can only reference public enrichments, so a workspace-visible playbook never exposes data that still belongs privately to another user.