Robot Strategy
How to manage multiple robots
Before creating your own Robots, it is important to map out your Play and Robot process.
Start by identifying the following areas:
- Evaluation points and qualification criteria to prioritize the best records
- When records will enroll and unenroll from certain Plays or be removed from Playbooks entirely
- Potential breaking points when the record changes ownership
- Instances of qualifying or disqualifying criteria being ambiguous
Once these factors have considered, identify actions that can be automated with Robots. Always keep in mind that you don’t have to make a Robot just because you can.
Robot Dos and Don’ts
Robots should be used where they will save time on administrative tasks or keep Playbooks from becoming cluttered. Before employing a Robot, consider the following Do’s and Don’ts:
| Do | Don’t |
|---|---|
| Auto-enroll only your highest priority records | Auto-enroll all records in a Sales Reps name |
| Judiciously update CRM fields that are relevant to your Playbooks process | Mass update records in a data cleanse motion |
| Select a few users to test Robots and provide feedback | Launch Robots to every user without testing |
Prioritization
It’s possible for a record to qualify for multiple Robots. Pay attention to the priority of the Robots in the Robot tab as that is the order in which records will be evaluated and actioned. While you are creating filter criteria and Robot prioritization, be on the look-out for records that could potentially fall into multiple robots.
It’s recommended you group your robots into buckets by the primary action it will take and prioritize as follows:
- Call Disposition Robots. These will trigger immediately once the call log is saved.
- Email Tracking Robots. For the same reason, next group email tracking robots because they will trigger immediately.
- Enrollment Robots. If the primary action is to enroll records in a Play list those next so that further Robot actions can be taken like updating CRM records.
- CRM Field Update Robots.
- Removal Robots. These should be last because once a Robot is removed from Playbooks it can no longer be actioned, unless added back into Playbooks.
API Usage
Robots use API calls to complete their queries and should be closely monitored. The following is a sum calculation example of API calls for one Robot.
One Enrollment Robot for a Business Development Team with 15 users:
- One Robot runs 144 timer per day (every 10 minutes)
- 144 API calls X 15 users = 2,160 API calls to look for qualifying records
- +200 API calls to enroll new records
- +200 API calls to update records with the Play Name and Play Status
- TOTAL = 2,560 API call
Multi Robot Strategy Example
The following example illustrates how multiple Robots may work together in a Sales Process.
A Robot can use the filtering criteria to identify new lead records, add them to Playbooks, and enroll them in the “New Lead” Play. Depending on how you’ve set up your Play and Robot strategy, you may not need to use the “Remove From Play” action. In this example, another Robot is on the lookout for qualifying records and will move the record into the next Play without needing to remove it from the current play first.
When the lead record’s status changes from new to working, the “Working” Robot essentially un-enrolls the record from the current Play into the “Working” Play.
When the lead status is changed to “Demo Scheduled,” the “Demo Scheduled” Robot pulls it into the “Demo Scheduled” Play. The same change will happen when the lead status is changed to Demo-Held and the “Demo-Held” Robot pulls the record to the “Demo-Held” Play.
For more information, check out the other Robot Articles and the Play Maker Course on XANT University.
