1. Introduction
This article explains how quotas can be used in NCS. The first section provides a technical overview of the concepts related to quotas. The second section shows how it appears in the NCS administration tool while the last section illustrates the use of quotas through a practical example.
2. Basic concepts
In this article, when we talk about quotas, we refer to the action of defining targets and limits in terms of handled contacts. These settings are related to campaigns. A typical example would be to contact 50 males and 50 females for an inquiry.
In NCS, every quota is translated in a field. In the previous example, that would mean two fields: one identifying males and the other identifying females. The quota target can then be rewritten as a condition to contact 50 records identified by the first field and 50 records identified by the second field.
3. Quotas fields
A NCS campaign defines a user table that includes the fields related to customer data. That table (using “Data” as default name) can include fields with a quota meaning. Only Numeric or Boolean fields are eligible as quota fields.
The following drawing shows the campaign database related to the previous example:
This table defines, among others, a field with meaning “phone number” and two fields with meaning “Quota”. “Qmale” is the quota field specifying if the record is related to a male while “QFemale” is the one specifying if the record is related to a female. In this example, the field is of Boolean type. A null value indicates that the information is not known.
The content of quota fields can be filled directly as any other field. For example, the “QMale” and “QFemale” fields can be included in the file to import. Of course the fields can be updated at any time (using the agent script for example).
Another approach is to base the content of quota fields on other fields using formulas. In the example, “Qmale” and “Qfemale” are (persistent) computed fields based on the content of the “Title” field.
The exact formula for “Qmale” in this example is:
(case when [title]='Mr' then (1) else case when [title]='Ms' then (0) end end)
In this case, the quota fields cannot be updated except by modifying the content of the field(s) they are based on.
4. Quotas progression table
To be able to define quota targets and limits, progression counters on quotas must be kept. This is achieved using an extra table in campaign’s database. The default name of this table is “Quotas”. Here is an overview of its content in the context of the previous example:
The table contains one record for each quota field. The two first columns identifies the field and its target. “Progress” specifies the absolute progression of the quota. “TargetDistance” specifies the absolute number of contact needed in order to reach the target. The two last fields provide the same information scaled to percentage. In this example, we see that two records associated to a male customer have been contacted, making a relative progression of 4%.
A remark is needed here about the progression itself. Until now, we always have specified that a quota limit was based on the number of contact. This is not entirely correct as the condition to count a progression can be more precise than that. Indeed, the system allows the user to specify the following options:
• Count qualified: this is the default behavior. The progression moves forward if the contact is qualified.
• Count positive: the progression only moves forward when the contact is qualified using a positive qualification.
• Count negative: the progression only moves forward when the contact is qualified using a negative qualification.
• Count neutral: the progression only moves forward when the contact is qualified using a neutral qualification.
• Count argued: the progression only moves forward when the contact is qualified using a qualification marked as argued.
• Sum qualification values: the progression moves forward of an amount specified by the qualification value.
• Sum positive values: the progression moves forward of an amount specified by the qualification value only if the qualification is positive.
5. Quotas based activity filters
In the context of quotas, activity filters can be used to ensure the system respects the configured limits. With the previous example in mind, activity filters will prevent calling a female when 50 females have already be contacted.
Basic filtering on quotas can be done using aggregations on quotas fields. The following aggregation schemes are available:
• Absolute progression: this is the progression value read from the quotas progression table for the selected quota field.
• Absolute target distance: this is the target distance value read from the quotas progression table for the selected quota field.
• Relative progression: this is the relative progress value read from the quotas progression table for the selected quota field.
• Relative target distance: this is the relative target distance value read from the quotas progression table for the selected quota field.
To illustrate the use of these aggregation mechanisms, consider again the previous example. An activity filter can be built on field “QMale”. If the filter requests “QMale” to be true, we will limit the dialing to male only. No quota limit will be checked in that case. However, if aggregate “Relative progression” is used and we request that its value is less than 100, we limit the amount of male customers contacted to be restricted to 50. For completeness, the full filter to achieve the correct behavior on the example would be: “Relative progression” on QMale is inferior to 100 OR “Relative progression” on QFemale is inferior to 100.
It is usually possible to describe the same criterion using different aggregations. For example, using “Relative progression” less than 100 is equivalent to “Relative target distance” bigger than 0.
To achieve optimal quota handling, new kind of objects have also been added to activity filters. These objects are combination of quotas value as described in the following list:
• Maximum absolute progress: maximum of the absolute progressions of quotas related to the campaign.
• Maximum absolute target distance: maximum of the absolute progression remaining of quotas related to the campaign.
• Maximum relative progress: maximum of the relative progressions of quotas related to the campaign.
• Maximum relative target distance: maximum of the relative progression remaining of quotas related to the campaign.
• Minimum absolute progress: minimum of the absolute progressions of quotas related to the campaign.
• Minimum absolute target distance: minimum of the absolute progression remaining of quotas related to the campaign.
• Minimum relative progress: minimum of the relative progressions of quotas related to the campaign.
• Minimum relative target distance: minimum of the relative progression remaining of quotas related to the campaign.
Relative progression combinations are usually used in a criteria requesting that the value is inferior to 100 (%).
Relative target distance combinations are usually used in a criteria requesting that the value is bigger than 0(%).
Absolute values combinations can be useful but is not a common approach. It allows to easily target a quota limit different than the one specified on the campaign.
Using aggregated combinations in filters is an efficient way of ensuring quotas limits without having to consider each quota fields one by one. For example, activity filter for the example we are following can be rewritten using “Minimum relative progress” is inferior to 100 (instead of the “OR” criterion on “QMale” and “QFemale”).
6. Quotas based activity sort order
Activity sort order is quite important in terms of quotas: it allows to control how the various quotas are progressing to their target. Most of the time, it is requested to have a similar relative progression on all quotas but in some cases, it could be useful to first complete one specific quota target before the others: both options will be available thanks to a proper sort order.
In the well-known example we are studying, the goal is probably to try to progress on male and female at the same time. This would be translated in NCS terms by adding an ascending sort order based on “Minimum relative progress” aggregated combination.
7. Time constraints
Until now, time dependencies on quotas have been ignored to facilitate the explanations. We will now explain how time considerations have been taken into account with the NCS solution.
When configuring a campaign for quotas the user has the option to specify that quotas are time based. In that case, a field (from user or system table) must be chosen to specify the timing related to a particular record in a campaign database. Moreover, to complete the minimum settings in order to use time constraint, a granularity must be specified.
For example, if the goal is to put in place a configuration resulting in selling each day at least 5 products of type A and 10 products of type B, the administrator has to ensure there is a field able to contain the time of the sale and that the granularity is set to “day”.
When working with time related quotas, the field “Sequence” in quotas progression table is used. This field contains a numeric value representing an identifier in the time sequence made of all time values according to the granularity. For example, the time ’21-03-2010 13:30’ will receive sequence identifier 40256 when the granularity is set to “day”. The time ’23-03-2010 18:30’ receives sequence identifier 40258 using the same granularity. This is quite straight forward as these two dates are spaced by 2 days (40258-40256).
The following picture shows a sample content of the quota progression table.
The displayed values suggest that the quota has been reached both for product A and B for a specific time range (that sequence does correspond to ‘Jun 19 2015 12:00AM - Jun 20 2015 12:00AM’ when granularity is set to ‘day’).
In addition to the granularity, the user is able to specify the allowed time range: this defines a window for eligible sequences values. In the described example, these limits would have no meaning as the time value related to a record is the time of the contact. Nevertheless, these constraints can be very useful, for example when quotas are related to appointment taking: in that case, the appointment date can be in the future and it make sense to limit the date of the appointment to the near future.
As described before, a null value for a quota field means that the relation between a record and the associated quotas value is unknown. This case receives a particular handling: the system gives him a value allowing it to be eligible for selection (activity filter) with low priority (activity sort order). For example, a quota field with a null value will have a virtual relative progress of 99%. That values both guarantee selection (because 99% is inferior to 100%) and correct sort order. In the same way, the absolute target distance for a null quota field will be 1 (to ensure the same mechanism).
When all quotas fields on a record indicates that it is unrelated to any quota, aggregated combinations return values ensuring it should not be selected and providing a low priority in terms of sorting. For example, if a record has values 0 for both fields “QMale” and “QFemale”, “Minimum related progress” would return 100%, preventing record selection (and putting it at end of sorted list if sort order is ascending).
Here is a snapshot of the content of campaign’s database during its progression.
The diagram shows the content of the database at a moment in time where quota Q1 is at 50% of its target and Q2 at 60% of its target. The array on the bottom right shows the computed values (aggregated combination “Minimum relative progress”) that will be used for sort order. As expected, we see that the next record that will be selected is a record related to Q1. Again the sort order seen is a snapshot; as soon as records get contacted, the values stored in the quotas progression table will be adapted, influencing the resulting sort order.
9. NCS Administration
This section will present how the previously explained concepts appear in the NCS administration tool.
First things first, here is a screen capture showing how a quota field can be specified. As explained before, quota fields can only be defined on numeric or Boolean fields. That means that the dropdown list will not contain the “Quota” meaning for fields having incompatible types.
The following screenshot shows te dialog used to create a new field. The same remark applies here too: the type of field controls the availability of the “Quota” meaning.
Once at least one field has been associated to a “Quota” meaning, the “Quota” tab is visible in the administration tool. This property page displays in its top part the list of quota fields and their basic settings.
On the bottom, the page allows editing the settings of the selected quota field.
In the screenshot, one can notice that the “Computation method” dropdown list is disabled. This is because the computation method can only be chosen once. One reason of that behavior is to avoid any data loss due to method change. Without that restriction, a change from “Direct value” to “Formula” would delete the content of the field, which is generally not a good idea.
On the top part of the property page, a checkbox allows the user to specify that quotas are asscoaited to time. Here is a screenshot showing the related settings:
In this example, the displayed settings indicate that the quotas are related to the date field labelled “AppointmentDate”. There is no prior knowledge of the value of this field as “Field is related to present time” is not selected. The granularity is set on week, indicating that quota targets are “per week”. Finally, the available time window for quotas is only 30 days skipping the next day.
The following two screenshots show the activity data filter creation based on a quota field. The left pictures shows a “standard” filter on a field while the right one shows a filter based on aggregated values. More precisely, the filter on the left would allow dialing on records having their “QMale” field value smaller than 100. The filter on the right, however, allows dialing on records related to male quota for which the quota progression is less than 100%.
The next screenshot displays the creation of a data filter based on combination of quotas values. The created filter would allow dialing on records having a minimum progression smaller than 100%.
Here is the result on the “Data filter” property pane when the creation is finalized:
The “Sort order” dialog and property panes are very similar to the ones of data filtering. Here are screenshots showing how they appear in the administration:
10. Example
On a particular campaign, the target definition is:
“Contact at least 500 males, with at least 100 of them subscribed to service A and 200 (male or female) subscribed to service B”
The campaign’s data includes a Boolean field “Male” defining if a record is a male and string field “Service” containing the list of services subscribed by the customer.
From the business description, we can infer that 3 quota fields will be needed:
- Quota Male (>500)
- Quota Male subscribed to A (>100)
- Quota Male or female subscribed to B (>200)
Here is how these 3 fields are defined in the administration:
As the “Male” field is already of the proper type, the “Quota” meaning could have been added to it, removing the need to create an extra field. In this example, new fields have been created for all quotas, to clearly split what comes from the import file and what has been added for the quota purposes.
The three added fields of this example will obviously be computed using formulas. Pay particular attention to the formulas being used, especially about the handling of null values. Indeed, it is important to keep the null aspect of a field as it indicates that nothing is known forehand about its value. Not paying attention to that would cause the record to be wrongly categorized.
The activity filter is set to ensure that a record will be dialed out only when it is related to the quotas that are not yet reached.
In the same fashion, the records will be selected in ascending order of their progression:
The example presented above describes one way to achieve quota implementation. Other options can of course be taken; the choices are up to you, depending on what your preferences.
Let’s suppose we want to contact 2 males and 5 females per hour. This can be easily achieved using the NCS quotas. Firstly, quotas related fields must be available:
In this example, “QuotaFemale” and “QuotaMale” are the fields that will be used as criteria. These fields are formula based on “Title”. The property page upper part defines the time dependency according to customer specifications: hour granularity on the system field “Last handling time”.
Please note that “Field is related to present time” is selected, allowing the system to know that the field will contain current time when dialed. On the outbound activity, the following filter ensure the limits are taken into account:
With these settings, the initial constraints will be respected and the system will stop dialing as soon as the target are reached. Nevertheless, this setup does not cause both quotas to progress at the same time. In order to achieve this, it is required to specify the appropriate sort order:
These settings are achieving the expected results but the attentive reader has noticed that this not prevent the limits to be exceeded. Indeed, if “QuotaMale” and “QuotaFemale” are not known at dial time (“Title” is null), the system will take records “at random” until the quotas target are reached: the sort order does not help at all under these conditions as at dialing time, a record is not more related to one quota than to the other.