The third section is where you create your time blocks, and each block's associated database queries. If this is a new Initiative, there won't be any visible information. If you're editing an existing Initiative, you should see the existing setup.
The first step is to establish the Time Ranges. As mentioned earlier, the time range(s) should coincide with when your reps are actually making calls, not with the location of the records being dialed (the queries themselves control which locations / time zones are being targeted).
Click Add Time Range to add a block of time to the Initiative. For purposes of this training, set the start range to 8:00 AM, and the end range to 8:00 PM.
As soon as you add the time range, the system will immediately pop up the Query Builder screen.
For this training, change the name of the query to "Eastern Time Only - All Day."
Next, (as shown below) you can choose a value for the Limit Calls to field. This field determines which users get to call the results of the query. This is the same as the Limit Calls To setting on the Dialer Initiative Information page, but is instead specific to individual queries. Choosing settings other than "Initiative Settings" from this dropdown will override the Limit Calls to setting on Dialer Initiative Information page. By taking advantage of this, you are able to have different queries within utilized different Limit Calls To settings if you so choose.
You can choose from these settings:
Queries use two components to generate the call queue—Filters and Sorting rules. Filters control which Leads appear in the queue; sorting rules control what order they appear. This is a key distinction, especially for new Sysadmins, to better manage Initiatives—"Are my users getting the right records to call, and are they getting them in the correct order?"
Start by adding a Filter to the query
Notice you can use any data field you want as a query filter, but most Sysadmins tend to focus on just a few key options.In the dropdown, choose the field on which you want the filter to be based. In this case, select "Time Zone" as the filter field.
Once the field filter is chosen, the next step is to set our logical options, or Boolean Operators. The First option is the IS/IS NOT option checkbox. Most of the time you'll use the IS option, so leave the checkmark blank.
Next, we need to decide if we want to limit our choice to just one option, a select set of options, or everything at once. This is represented by the Equal To, One Of, or Set to Any Value options in the dropdown.
In this case, we are only going to set one option, Eastern Time, so choose the (=) equal to.
Then in the last dropdown, we need to select Eastern Standard Time (America/New York).
So to sum up so far: we've instructed the query for this Dialer Initiative, that between the hours of 8:00 AM and 8:00 PM, we only want to call Leads located in the Eastern time zone. However, that's still fairly broad in scope, so we might want to add a couple more filters, and a sorting rule or two before we move on.
Click the Add Filter button again, and select Lead Status as the controlling field.
Now in our Boolean operators, select One of in the dropdown.
Let's assume that we wanted to call all Leads in Eastern time zone (because that's the filter we set previously), but only those whose Lead Status was not set (i.e., blank), or still marked as New. To do this, click Not Set in the dropdown menu so that it's highlighted. Then, while holding down the CTRL key, select New as a second option for our filter.
Great! We've narrowed down our entire database of Leads to only those that match the specified Time Zones and Lead Statuses.
For our third filter, we're going to limit the Leads in the queue to only those who have been dialed less than three (3) times (i.e., they've been called 0, 1, or 2 times). Click Add Filter once again, and select Dial Attempts as the controlling field.
Now notice that for this filter, we have quite a few more Boolean operators than for our Time Zone and Lead Status filters. This is because unlike Time Zone and Lead Status, which have a finite number of options, the Dial Attempts field could theoretically be any number (obviously no one is going to get called 2,500 times or anything, but as far as the dialer server knows, the number could be anything).
In this particular case, we could use either of two options: Less Than, or Between. For simplicity, we'll set the Dial Attempts filter to "Less than 3." In other situations, the "between" option might have been more appropriate; for example, "Less than 6" and "Between 2 and 5" are clearly not the same. In this case though, "Less than 3" and "Between 0 and 2" would accomplish the same thing.
At this point, your hypothetical query filters are set and ready. However, we're going to assume you want to sort the Leads to be called as well.
Click Add Sort to add a sorting rule.
Just like our filters, the first step is to choose the controlling field. We've already filtered our leads according to the number of dial attempts made; now we're going to sort them as well, because we want the Leads with the fewest number of dial attempts to get called first.
Select Dial Attempts as the controlling field for our sort. Now we need to choose the direction of the sort.
Most of the time, understanding "ascending" and "descending" order is pretty straightforward; "sort by ascending" means that records with the smallest values get called first, those with the highest values get called last. Descending order reverses that.
The only time this gets tricky is with dates. Remember: Dates sorted by Ascending order puts those with the smallest "chronological" value (read: oldest) first in the display. Dates sorted by Descending puts the largest "chronological" value (the most recent) first.
In our sample Initiative we're going to set Dial Attempts to Ascending order, meaning those with the fewest attempts get called first.
However, we're also going to add a second sorting rule of Created Date, and set it to descending so that it will list the newest leads within each subset of dial attempts.
With our two sorting rules combined, we're now going to call the Leads with the fewest number dial attempts, that are the newest in the system, first.
So to recap:
This basic process—select criteria (filters), select the range (Boolean operators), and select the sorting order—never changes.
Some wonder if "stacking" additional time blocks, or additional queries in a single time block, changes things. The answer is, "Not really."
The only real change is that if you have multiple stacked queries running in the same block, you have to prioritize them. You must dial through all of the resulting leads in the first query before you will access the secondary query, and so on. If you never reach the end of a list of names in one stacked query, you'll never see any of the other Leads in the other queries. If it's important to reach all of the leads in ALL of your queries, you'll need to program that into your current Initiative, or you may need to create an entirely separate Initiative to account for it.
If you want to create multiple queries that are similar in nature, you can use the Clone button to create a copy of an existing query. Then simply edit the elements that differ.
Cloned queries connect and function with the query preview tool once added and saved to the time block.