Working with 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 for which the organization does not try to 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 threshold violations on the dashboard, alerts on the map, and email notifications being sent.

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, then 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.

Operation

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 to detect violations and create alerts.

Multiple thresholds may affect the same moment in time. 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	08:00–08:44	Exception C
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. For instance, from 07:55–08:50, assume a metric value is not in 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 emails are sent, the Alert Creation Delay Interval 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).

Important

You cannot delete an exception, or delete or reset its values, if the exception is causing an active alert, or caused an alert that is now expired but has not been deleted from the Advisors database. To end the alert and make it inactive, change the exception's values so that the metric will no longer causes a violation. When the alert ends, and CCAdv or WA has deleted it from the Advisors database, you can reset the threshold or delete its values.

Procedure: Adding or editing an exception

Steps

1. From the Application Thresholds or Contact Groups Threshold tabs, click a live (blue underlined) link in the # of Exceptions column.
   Note that there must be a threshold rule before an application or contact group can have an exception to the rule.
2. To add an exception, click New.
   To edit an existing exception, select it, or search for and then select it in the upper pane.
3. Type or edit the name for the exception in the Name field.
4. Select the time zone from the drop-down field.
   The values are converted to UTC prior to being saved in the database.
5. Enter the start time of the exception.
   The start time must be less than the end time and range from 00:00 to 23:59.
6. Enter the end time of the exception.
   The end time must be greater than the start time and range from 00:00 to 23:59.
7. Specify the date the exception applies from the Effective Date calendar.
8. Select the frequency that the exception repeats from the Frequency drop-down list. The default is None.
9. If the exception repeats weekly, select which day of the week the exception repeats.
10. If the exception repeats monthly, select which day of the month the exception repeats.
11. Add the lower-bound and upper-bound warning and critical threshold limits.
12. To save the exception, click Save.
    A confirmation message displays. The exception displays in the table.