In this article we will cover of the most common scenarios of routing rules you will need for your Router.
Think of Queue rules as "buckets" that will catch your inbound leads. You will likely need to create various types of Queues so that you have a bucket for every scenario you want to allow someone to schedule, such as East Territory US vs West Territory US, or Mid-Market vs Enterprise.
Your Queues are not working for you until you enable them on your Router. Once you have all your Queues created, you can choose the ones you would like to enable on your Router and arrange the order that we evaluate them in. By default, we will always group and check Ownership Queues first, followed by Queues with rules then Queues without rules.
We will create examples for the following:
- Route to an existing Owner
- Route to a named Account Owner using a custom field
- Route using data from your form
- Exclude public domains
- Catch All Queue
Route to an existing Owner
Depending on your Salesforce flow, you may or may not choose to route to the Owner of existing records.
To Route to an Existing Owner you will first want to make sure you have chose Algorithm type: Prioritize Routing Based on Ownership in your Queue settings.
Object: Choose any for [Object] Owner
Field(s): Email or UserId
Value: Assignee Email Address or AssigneeId
Here we have rules for Lead, Contact, and Account Owner:
Notice how the logic was adjusted to reflect: 1 OR 2 OR 3. Another version of this logic based on common routing scenarios could state: 2 OR (1 AND 3)
Route to a named Account Owner using a custom field
It's common to have a custom field in Salesforce for Named or Target accounts. In most cases, this is a checkbox field with a value of TRUE/FALSE or a Lookup field to the User populated with the Owner of the Account.
Object: Account/Account Owner
Field(s): Custom field(s)
Value: Full Assignee Email Address or AssigneeId
Here is an example of Queue configured to route to Liz if the account is marked as a Target Account and the Account is owned by liz@chilipiper.com. Both of these things must be true to match to this queue or the Account SDR Owner must be a specific SDR - as denoted by their 18-digit Salesforce UserId.
Note: If you have the 15-digit UserId, this will need to be converted to their 18-digit UserId.
These queues reference specific assignee emails so once you have a version created for one user, you will need to Duplicate this queue and create one per sales rep. Make sure to prioritize them first on the Router!
Route using data from your form
This step will require you to map your form to Chili Piper first. In this example, we have this form mapped, and we want to route based on Company Size:
Our routing plan will be as follows:
- 1-10: Disqualify
- 11-50: Disqualify
- 51-250: Route to Alex
- 251-1K: Route to Amanda
- 1K-5K: Route to Nate
Values 1-10 and 11-50 we want to Disqualify, so we will exclude them from our queue rules. Let's create Alex's Queue:
Object: Related Lead
Field(s): Custom field mapped to the Lead in your form mapping
Value: API name as shown in the form code
We are using Company_Size__c in the form mapping so we will choose this Field here as well:
We used Related Lead for the object because this is what Chili Piper defaults to for routing net new Leads. We will automatically check for an existing record in Salesforce prior to routing it based on an email match - if none of your other queues match, we'll route it according to your Related Lead rules. If it's an existing Lead, we'll use the Lead rules as well.
Be sure to copy the API names of the values from your form, specifically what appears after value= in the form code. In some cases the value matches the label, but not always:
We can Duplicate Alex's Queue and change the Value to create Amanda's Queue:
And Nate's:
Since these Queue's do not have any overlapping criteria, the order on the Router will not matter.
Exclude public domains
Should you decide to filter out leads with a @gmail.com, @yahoo.com, @comcast.net, etc. domain from scheduling, add a rule per domain you would like to exclude in your queues using the not contains operator, like this:
Notice how the logic says: 1 AND 2 AND 3 AND 4, since a business email domain will not contain all of the public domains listed in Rules 3-4.
Catch All Queue
A Catch All Queue, alternatively known as a No Criteria queue, does not have any rules. Creating a Catch All is best practice for your initial Router configuration to rule out any routing errors when testing the integration.
Comments
0 comments
Please sign in to leave a comment.