Skip to main content
Manager ApplicationRobots

Robot Strategy

By April 22, 2020November 25th, 2020No Comments



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


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:

  1. Call Disposition Robots. These will trigger immediately once the call log is saved.
  2. Email Tracking Robots. For the same reason, next group email tracking robots because they will trigger immediately.
  3. 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.
  4. CRM Field Update Robots.
  5. 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
Note: The example above uses the default 10 minute query runtime interval. Make sure you know which interval your organization is using when you calculate your API usage. If your Robots are set to run queries every 20 minutes, your API usage will be half of what it would be at 10 minutes. For more information on changing Robot query runtime, contact your CSM.  
Related Article: API Call Utilization
Click this message for more information on API Calls.

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.

Note: Any examples in this article are intended to illustrate concepts and may not apply to your specific CRM or sales process. We recommend you complete the Play Maker Course entirely before attempting to create a Robot.

For more information, check out the other Robot Articles and the Play Maker Course on XANT University.

Related Course: Play Maker Course
For more information on Robots, take the Play Maker Course at XANT University.



Was this article helpful?