Who can use this feature?
- All roles with access level "high"
- Available on all plans
Playbooks allow you to create pre-built workflows to automatically assign new tasks, send personalized emails, and update field values. Customers enter a playbook based on custom criteria or journey stage.
Refer to this video to see playbooks in action.
Suggested uses
Playbooks provide powerful automation to help your team maximize efficiency and provide a consistent customer experience:
- Accelerate implementation and onboarding: Sequence tailored communications to drive adoption among new customers and/or new users
- Mitigate churn risk: Proactively identify risk based on usage drops, and automatically engage customers
- Strengthen adoption: Monitor changes in customer health and alert the account team to investigate.
- Standardize renewal management: Re-engage customers ahead of their upcoming renewal and automate critical tasks at each step
- Maximize account growth: Identify upsell opportunities sand automatically engage customers when nearing license utilization
- Customer journey action plans: Provide consistent action plans across the customer journey to help customers attain goals within each journey stage
Create a new playbook
You can create playbooks for account, opportunity, contact, or additional objects. Once created, playbooks are saved as drafts until you enable them.
- From the sidebar, click Playbooks.
- Click Create Playbook.
You can also duplicate another playbook so you don't have to start from scratch! Everything is duplicated except the object type.
- Add a name for the playbook and provide a description (optional). A description helps your team understand the purpose of the workflow when they are assigned playbook actions.
- From the "Playbook Type" drop-down, choose the object for the playbook.
The object selected determines the type of triggers available. - Click Create.
The playbook is created and the Flow Builder appears. Use this screen to set entry conditions, actions, and branching logic to create a workflow.
Define playbook entry conditions
Entry conditions tell Catalyst when a participant (record) qualifies for the workflow (e.g., license utilization is 80% or health is at risk). As you apply conditions, the number of matching records is indicated in real-time.
- Within the playbook Flow Builder, click Add Conditions.
- Choose to add individual filters, add a filter grouping, or duplicate the filters from an existing segment. You can use any existing data point on the object.
- If the playbook should run as a result of a customer entering a particular journey stage, click +Attach Journey to select the stage to associate. Attaching a journey applies the selected stage's goals and duration criteria to the playbook's entry conditions.
Avoid using additional playbook triggers that conflict with the goals applied to the associated stage. Do not apply a "stage" filter to the playbook that is used by the customer journey (e.g., Stage = Foundation).
If a journey stage is applied, you can optionally use unique journey filters for "Days left in stage" and "Stage goal."
- Choose whether to allow manual entry into the playbook, even if conditions aren't met.
- Click Save.
Once entry conditions are set, you can start adding playbook actions and logic. Changes are updated as you work (automatic save).
Add playbook actions
Playbook actions tell Catalyst what automation to execute along the sequence. Within the Flow Builder, you can choose from the following automated actions to apply anywhere in the flow:
- Task: Create a task and assign to a Catalyst user
- Email: Send an email to the customer
- Field update: Update a field with a new value
Each stem of the workflow creates a new "step" (shown with a dotted line). You can have up to 10 actions per step.
- From within your playbook flow, click the + button.
You can re-order an action once you add it, as long as it is not used as part of branch logic later in the flow (applies to tasks and emails). You can also duplicate actions so you don't have to start from scratch.
- Choose the action you want to configure (see related articles for more details).
- Click Add.
Add playbook logic
Playbook logic tells Catalyst when and how to proceed through the sequence. Within the Flow Builder, you can choose from the following logic to apply anywhere in the flow:
- Delay: Wait for a period of time or another playbook action fires before advancing. Delays are critical to ensuring a workflow runs smoothly. Add them between actions and branches.
- Branch: Create different paths based on specific customer data (e.g., health is at risk) and action data (e.g., email not opened)
Each delay or branch creates a new "step" in the workflow. Each branch can have a maximum of 30 steps; multiple actions within the same step count as one.
Add a delay
Add a delay anywhere in your flow, but you cannot stack delays on top of each other. Catalyst also prompts you to add a delay after adding a playbook action (recommended).
- From within your playbook flow, click the + button.
You cannot re-order a delay once you add it, so be sure to verify the location.
- Choose Delay.
- Choose between the following:
-
Wait until a specific condition is met (recommended). Choose an existing playbook action (task or email) and related results. Additionally set a maximum time limit to wait for the condition, before proceeding in the flow even if the condition is not met.
- Task filter options: Is marked complete
-
Email filter options: Any recipient has replied, opened, clicked, been delivered to, bounced, dropped, been approved, been rejected
Catalyst checks conditions on responsive delays every 10 minutes. Email filters based on "reply" requires senders to have their email account authenticated.
-
Wait for a fixed amount of time. Set the defined time period to wait before advancing to the next step (days or months).
Days are calculated by calendar days, not business days.
-
Wait until a specific condition is met (recommended). Choose an existing playbook action (task or email) and related results. Additionally set a maximum time limit to wait for the condition, before proceeding in the flow even if the condition is not met.
- Click Add.
Add a branch
Add a branch anywhere in your flow, but certain branch types can only be used once an action is present in the flow (see details below). You can add branches within branches.
Deleting a branch step deletes everything below it; deleting a specific branch (within a branch step) deletes only that specific branch and everything below it. If you want to preserve actions within a branch, drag-and-drop them to another step prior to deleting a branch.
- From within your playbook flow, click the + button.
You cannot re-order a branch once you add it, so be sure to verify the location. You can re-order multiple checks within a branch.
- Choose Branch.
- Choose how to set up the branch:
- Branch based on customer filters. Create paths based on customer fields, like industry or product usage. You can apply multiple filters and advanced logic within a check. You can also add multiple checks (up to 10 additional).
-
Branch based on playbook action filters. Create paths based on action results, like if an email is opened or task completed. (Placement of the branch requires actions in the flow to exist above the branch node.)
- Based on: Choose the action type upon which all checks in this branch are based.
-
Check if: Choose from the available actions for the selected type. You can add multiple checks for the same action type, with one filter per check. Re-order as needed to determine priority. Be sure to name each check so you can see them in the Flow Builder.
- Task filter options: Is marked complete, is incomplete
-
Email filter options: Any recipient has replied / not replied, not authenticate, opened / not opened, clicked / not clicked, been delivered to, bounced, dropped, been approved, been rejected, not been actioned
Email filters based on "reply" requires senders to have their email account authenticated.
- Click Save.
If no condition of the branch checks are met, the sequence continues.
Configure playbook settings
The Settings tab within each playbook is where you can define key behaviors for effectiveness and entry/exit parameters.
- Name and description: We recommend providing a description so that your teams have context on the purpose of the play and why their customer entered.
-
Objective: Set an objective based on a customer field to measure the impact of your playbook (e.g., objective is met when account % seat utilization is greater than 40).
You can set one objective per playbook, one field per objective. Once configured, you can:
- Automatically exit customers from a playbook once an objective is met (see exit logic below)
-
Track overall objective performance and participant breakdown. Visualize performance trends up to 30 days post-exit to assess impact
Think about the purpose for creating this playbook—what are you trying to achieve? We recommend setting the objective before you build out your flow, so you can anchor on this metric as you define the process and actions to drive it.
-
Additional playbook eligibility: Specify the eligibility of participants to enter additional playbooks.
- All participants to enter all other playbooks (default): Participants enter all additional playbooks while they are participants of this one.
- Do not allow participants to enter ANY other playbook: Participants do not enter any additional playbooks while they are participants of this one.
- Do not allow entry to specific playbooks: Participants do not enter any of the playbooks specified here, as long as they are participants of this one.
-
Re-entry: Choose the frequency at which a participant can re-enter the playbook.
-
Allow multiple re-entry (default): Participants can re-enter the playbook if they qualify, but only if they stopped qualifying first (e.g., entry conditions change at least once in between their last exit and next re-entry). Optionally set a timeframe to specify the number of days or months after which the participant can re-enter the playbook.
Example: A customer enters a renewal playbook with the criteria "Renewal is within the next 90 days." The customer goes through the flow, and exits the playbook 5 days before renewal. The customer technically still qualifies for the playbook, since they’re within 90 days from renewal; however, the customer won't re-enter the playbook once entry conditions have changed at least once.
-
Allow unlimited re-entry: Participants can continuously re-enter the playbook if they qualify, even if entry conditions have not changed between the previous exit and re-entry. Use this option to create recurring workflows. Optionally set a timeframe to specify the number of days or months after which the participant can re-enter the playbook.
Example: You want to send a monthly customer an overage notice any time they have an overage or you want a particular task to occur every x amount of days)
-
Do not allow re-entry: Participants can only enter this playbook once, even if entry conditions are met more than once.
Example: A customer enters a renewal playbook with the criteria "Renewal is within the next 90 days." The customer goes through the flow, and exits the playbook 5 days before renewal. The customer technically still qualifies for the playbook, since they’re within 90 days from renewal; however, the customer won't re-enter the playbook once entry conditions have changed at least once.
Re-entry is calculated based on the exit date of the last playbook run. If you edit re-entry conditions after a playbook is enabled, all in the playbook customers will abide by the new re-entry criteria upon exit. If the customer had previously exited, Catalyst uses the exit date to calculate re-entry (if applicable). Let's say you edited a playbook that had no re-entry and changed it to allow re-entry after 90 days. Customers who already exited would re-enter based on the date the change was made (e.g., if at day 1-90 post-exit when the setting changed, they would re-enter at day 90; if at day 100 post-exit when the setting was changed, they would re-enter immediately).
-
Allow multiple re-entry (default): Participants can re-enter the playbook if they qualify, but only if they stopped qualifying first (e.g., entry conditions change at least once in between their last exit and next re-entry). Optionally set a timeframe to specify the number of days or months after which the participant can re-enter the playbook.
-
Exit logic: Choose when a participant should be removed from the playbook, if an objective is set (see above).
- Exit playbook when the objective is met: Participants exit the playbook as soon as the objective is met.
- Stay in playbook after the objective is met: Participants remain in the playbook until the end of the flow, even if the objective has been met.
-
Exit overrides: Use filter logic to determine when a customer should be removed from this playbook, regardless of their place in the flow. Use filters with advanced logic to set your preferred conditions.
Example: If a customer is in a renewal playbook but they renew early, remove them from the remaining sequence in the flow.
Enable a playbook
When you are done configuring your playbook, you can launch it to start the flow processing. A playbook can be enabled once there is at least one entry condition and one action. Once enabled, you can see the number of customers in a delay from within the Flow Builder and click to view details. You can also see playbook action insights.
- From within the playbook, click Enable.
- Choose the launch options:
- Run the playbook now for all qualifying customers as well as customers that qualify in the future.
- Do not run the playbook immediately; only for contacts that qualify in the future. (This cannot be changed after enabling the playbook.)
- Click Enable & Launch.
Once enabled, it may take several minutes for actions to execute. Going forward, playbooks continue to run on a regular interval.
Editing a live playbook
Once a playbook is enabled, you can edit existing steps, but you cannot add or remove steps.
- Within the playbook, click the Enabled drop-down.
- Choose from the following:
- Pause new entries: Do not allow new customers to enter, but existing customers in the flow will remain until finished.
-
Disable: The playbook will stop running. All customers in the flow will be exited, and you can begin making changes.
Refer to the following table for detailed actions. Structural Change = creation or deletion of a step (branch, action, delay). Non-structural change = editing of *entry conditions, action templates, delay time frame, branch names and criteria.
State | Description | Edit capabilities |
---|---|---|
Draft | Playbook is in a draft state when it is first created and has not yet been enabled. Once enabled, a playbook cannot return to the draft state. | Any step and make any type of edit to the playbook. |
Enabled | Playbook can be enabled once there is at least one entry condition and one action. Playbook is live and customers are actively entering it. | Structural changes are not allowed. Non-structural changes are allowed. Edits apply to both current customers in the PB who haven’t yet reached that step and new customers who will enter the playbook. |
Paused | Pausing prevents any new customers from entering, but allows existing customers to go through the remainder of the flow and then exit. Purpose of pausing is to finish the run for existing customers (so they don’t get kicked out), then disable the playbook to make structural changes. | No structural changes can be made, but non-structural changes can be made. Edits apply to current customers in the playbook who haven’t yet reached that step. |
Disabled |
Disabling removes all customers from the playbook. If playbook is re-enabled, customers previously removed mid-flow will re-enter (depending on re-entry conditions set) at the beginning, not where they left off. |
Structural and non-structural changes are allowed. Changes are auto-saved as you work. |
*Edits made to entry conditions won’t impact customers currently in the playbook