Automated Playbook Use Cases, Tips, & Tricks Overview
Playbook automations can be used in so many different ways to achieve different goals. You can trigger drip campaigns, assign key roles based on specific data, update traits, and much more. The many options can be overwhelming, but don't fret, we've got you covered on strategic ways to achieve your goals. Below, we go over 2 of the most commonly asked questions on Playbooks:
How to manually enroll a customer in a Playbook (start video at 1:44)
How to set up a recurring Playbook (start video at 7:30 min)
Creating a Recurring Playbook
Recurring Playbooks off an Activity Object
If you're creating a recurring playbook off activity (notes, tasks, and projects) then you can follow the steps below. We're using Projects as the example, but these are the same steps for Tasks or Notes:
Create Categories:
Create a category, for example, "Collaborative."
Create Templates:
Assign the appropriate category, such as "Collaborative," to relevant project templates like QBR (Quarterly Business Review).
Defining Playbook Trigger for Playbooks: You can trigger off Next Due Task or Last Completed Task, depending on what you want. Select the appropriate option!
Establish the logic for playbook triggers based on key activities. For example:
Trigger off the last completed project within the "Collaborative" category.
Set the timeframe for triggering the playbook (e.g, 90 days)
Add Playbook Actions:
Add an action to create a new project (and any other actions you want)
Once a project is completed, individuals will be removed from the current playbook. Upon completion of the new project, individuals will be added back into the playbook for the next cycle.
By following these steps, you can effectively configure project categories, trigger playbooks based on key activities, and automate project creation within your system. This enables seamless management and execution of recurring tasks or projects, such as Quarterly Business Reviews.
Recurring Playbooks off non-Activity Objects
If you want to create a recurring playbook that is not targeting Notes, Tasks, or Projects, there is another method, which would be based on an actual date. This method involves creating custom traits and setting specific date criteria for triggering actions:
Creating Custom Traits:
Create a DATETIME custom trait, such as "Last QBR Date."
Please note that a datetime trait is highly recommended, as date traits can fluctuate with UTC. So if it's a daily playbook, a date trait will not work, but if it's a 30, 60, or 90-day playbook, it will probably work ok.
Defining Trigger for Playbooks:
Establish the trigger condition based on the custom trait. For example:
Define the trigger condition as "Last QBR Date greater than 90 days ago."
Consider including additional filters as needed.
Handling Nulls:
Include a condition to handle null values, ensuring individuals are included if the event has not occurred previously.
Automating Actions:
Determine the actions to automate within the playbook, such as creating a new QBR project or Vitally Doc
Add a Wait action:
Incorporate a wait step to hold the process until the completion of the QBR event.
Utilize available data to detect the completion of the QBR, such as activity objects or specific indicators.
Update a Trait Action:
Add an action to update the custom trait with the current date to mark the event's occurrence.
This update ensures individuals are removed from the playbook until the next cycle.
As time progresses, individuals will cycle in and out of the playbook based on the date criteria. The playbook will automatically adjust based on the specified time frame, in this case, ninety days.
Setting a Trait to a Specific Value When a Playbook Exits
The Update a Trait undo strategy offers only Nothing - maintain its current value or Delete the trait's value (i.e. set it to null), so there is no native option to set a trait to a specific value when an object exits a Playbook. You can get the same result by writing the value just before the object exits:
Set the Playbook's exit strategy to Only once they've completed the Playbook and no longer match the rules.
Add a Wait step before the end of the automation.
Set the Wait condition to proceed once the object no longer matches the Playbook's trigger rules.
Add an Update a Trait step after the Wait and set the trait to the value you want.
Set the undo strategy on that step, and on every other Update a Trait step in the Playbook, to Nothing - maintain its current value. If any of them is set to delete the value, the value written in step 4 is cleared when the object exits.
The object then un-enrolls carrying the value that was set after the trigger rules stopped matching.
This only works when the Playbook lets the automation finish. With the exit strategy Once they no longer match the rules, the run stops as soon as the object stops matching and the Wait step never completes.