Adding Threshold Exceptions
As part of the Advisor threshold and alert management capabilities, you can configure threshold exceptions. Exceptions are useful when certain periods of time perform differently than others. These differences are specific to the impact on threshold violations. For example, even though call volume fluctuates significantly throughout the day, expected performance should be maintained throughout the day. Typically a metric target used for alerting (SL% for example) does not change just because other conditions change. However, certain conditions warrant exception usage as they are expected, understood and managed. Many Advisor users have certain peak periods that the organization does not try and staff. For example, every Monday from 09:00 to 11:00 a call spike occurs following the weekend. Since that spike is not staffed to deliver typical SL% performance, there is a weekly expected period where normal thresholds are consistently violated. An Advisor threshold exception is useful in this case to lower the targets for SL% and thus avoid color-coded violations on the dashboard, alerts triggering to the map and the Action Management console as well as e-mail distributions going out. Used correctly, threshold exceptions can avoid false alarms notifying people of a problem that does not really exist. If the situation is expected, known and accepted, than there should be no reason to alert on it. Alerting should be isolated to the intended purpose of bringing attention to an issue that requires action.
You can add exceptions to override baseline threshold rules. When the exception is in effect, the values for the thresholds specified in the exception are used in all calculations and display of alerts. Multiple thresholds may affect the same moment in time. In general, thresholds and exceptions behave as follows when multiple thresholds affect the same moment in time:
- The threshold that started later and ended earlier is the one in effect.
- Non-repeating exceptions override repeating ones.
Specifically, when multiple thresholds affect the same moment in time, thresholds and exceptions behave as follows:
- If more than one threshold affects the same moment in time, the threshold that started later applies.
- If more than one threshold starts at the same time, then the one that ends the earliest applies.
- If more than one exception starts and ends at the same time, then the single instance exception supersedes the repeating exception.
- If more than one single instance exception starts and ends at the same time, then the exception created most recently applies.
- If more than one repeating exception applies, then the repeating exception created most recently applies.
The example in the following table describes which of the multiple thresholds apply at a given period of time.
|Baseline Rule and Exceptions||Time Period||Threshold Applied|
|Baseline (00:00 - 24:00)||00:00–07:59||Baseline|
|A: 1/11/2006 08:00 - 10:00;
created 1/10/2006 09:00:02 AM EST
|B: 1/11/2006 09:00 - 11:00; created 1/10/2006 10:00:02 AM EST||08:45–08:59||Exception A|
|C: 1/11/2006 08:00 - 08:45; created 1/10/2006 11:00:02 AM EST||09:00–10:59||Exception B|
|D: Repeat Weekly 09:00 - 13:00; created 1/8/2006 11:00:02 AM EST||11:00–12:59||Exception E|
|E: Repeat Monthly 09:00 - 13:00; created 1/9/2006 09:22:13 AM EST||13:00–23:59||Baseline|
Threshold violations are raised as soon as they exist, but not before. For instance, from 07:55–08:50, assume a metric value is not a violation of the baseline threshold; however, it is a warning (yellow) violation according to Exception C. Therefore, the warning violation will occur at 08:00 and persist until 08:44 (assuming that Exception A is not a violation). To determine when alerts are generated and displayed on the map and when e-mails are sent, the threshold trigger delay begins counting when the violation is raised. If the violation disappears before the threshold trigger delay because either the actual metric came back into compliance or the threshold changed, then an alert is not raised. If the violation changes (from yellow to red or red to yellow), either because the actual metric moved or the threshold changed, the trigger delay is calculated from when the metric first passed out of compliance (into yellow or red) and the alert, if generated, reflects the current state of the violation. For exceptions, the start and stop time fields are relative to the contact center. The time zone is used to determine the times. For example:
- For contact centers in PST, typing the start time 6:00 AM and stop time 8:00 AM is 6:00 AM to 8:00 AM PST (that is, 14:00 -16:00 GMT).
- For contact centers in EST, typing the start time 6:00 AM and stop time 8:00 AM is 6:00 AM to 8:00 AM EST (that is, 11:00–13:00 GMT).