Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (Metrics Tab) (SLA4)

Sub Banner

The following are instructions for the use of the Metrics tab to refine the behaviour of events to be measured in your solution.

If required, please see the article named Configure SLA Metrics for an explanation of when and why to configure metrics, including examples.

Defining Rules and Behaviour for SLA Events

Defining Rules and Behaviour for SLA Events

Generic Event Names

The Metric Type (4) is used as the generic reference to the corresponding event in generated ticket fields using capitalization  (e.g. SLA3 Solve Measure), although this name is often replaced in Labels using the Policies tab (also see Monitoring SLA Performance using Zendesk Views for more information regarding the use of these ticket fields).

Pausing & Stopping Timers for Events

Pausing & Stopping Timers for Events

For each event included in your implemented model template, it is possible to indicate if the associated timer should be paused or stopped under the following circumstances:

  • Check the Pending box (4) if the timer should be paused when the ticket is placed in a status of 'Pending' while waiting for more information from the customer
  • Check the Hold box (5) if the timer should be paused when the ticket is placed in a status of 'On-hold' while waiting for action by a third party or department other than the Customer Support team
  • Check the Pass box (6) if the timer should be stopped when the conditions for passing the SLA have been met, including when the ticket is placed in a status of 'Solved'

If the event timer is paused or stopped for any of the reasons above, the timer will be restarted if and when the conditions causing the pause or stop are no longer in place.

When the timer is restarted the due date/time for completion of the event is recalculated taking into account the period of time during which the timer was paused or stopped.

Configuring SLA Notifications

Configuring SLA Notifications

By default, when the CloudSET SLA Management App is first installed, a standard email notification will be issued to the assigned agent if the SLA for an event violates (9), or to warn of an impending violation (10).

It is possible to override the recipient of these email messages with one or more alternative Agents or Groups (11) (see below) and change the content of the email subject (12) and email message body (13).

Standard Zendesk placeholders can be used in the subject and email body as outlined in the following article: Zendesk Support placeholders reference

Removing all recipients from the Sent To field (11) to an empty value (-) will prevent the email message being sent when the violation or warning occurs.

*Note:

It is possible that there will be a need to perform alternative actions if and when an SLA violation or warning occurs.

Under these circumstances it will be necessary to manually develop a Zendesk trigger to fire when a violation or warning occurs (see Develop Hybrid Triggers for more details)

Configuring Alternative, Additional Notifications

Configuring Alternative, Additional Notifications

There is often a requirement to send out additional or alternative notifications if and when an SLA violation or warning occurs.

Any number of additional notifications can be configured (1) to send an email with a different subject or email body to alternative recipients (2).

Rules can be configured to determine the conditions under which a notification should be sent (3) (see below for full details).

A notification can be removed if no longer required (4).

The original 'default' notification configuration (5) must always remain in place, but if required the email notification can be suppressed by removing all recipients.

When defining an notification rule (1) it is possible to specify All of the field values that must be set (2) in order for the email notification to be sent.

In addition or alternatively, it is also possible to specify a list of values Any of which could be set for a field in order for the notification to be sent (3).

So in the example above the notification will be sent if the Priority is 'Urgent' AND the Type is either 'Incident' OR 'Problem'.

*Note: the rule definitions work in much the same way as the conditions defined for Zendesk Triggers and the following article provides more detail should a further explanation be required: Understanding trigger conditions and actions

Enter an appropriate label (4) to describe the purpose of the notification rule and select 'OK' to save the rule (5).

Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (Metrics Tab) (SLA4)

Sub Banner

Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (Metrics Tab) (SLA4)

The following are instructions for the use of the Metrics tab to refine the behaviour of events to be measured in your solution.

If required, please see the article named Configure SLA Metrics for an explanation of when and why to configure metrics, including examples.

Defining Rules and Behaviour for SLA Events

Defining Rules and Behaviour for SLA Events

Generic Event Names

The Metric Type (4) is used as the generic reference to the corresponding event in generated ticket fields using capitalization  (e.g. SLA3 Solve Measure), although this name is often replaced in Labels using the Policies tab (also see Monitoring SLA Performance using Zendesk Views for more information regarding the use of these ticket fields).

Pausing & Stopping Timers for Events

Pausing & Stopping Timers for Events

For each event included in your implemented model template, it is possible to indicate if the associated timer should be paused or stopped under the following circumstances:

  • Check the Pending box (4) if the timer should be paused when the ticket is placed in a status of 'Pending' while waiting for more information from the customer
  • Check the Hold box (5) if the timer should be paused when the ticket is placed in a status of 'On-hold' while waiting for action by a third party or department other than the Customer Support team
  • Check the Pass box (6) if the timer should be stopped when the conditions for passing the SLA have been met, including when the ticket is placed in a status of 'Solved'

If the event timer is paused or stopped for any of the reasons above, the timer will be restarted if and when the conditions causing the pause or stop are no longer in place.

When the timer is restarted the due date/time for completion of the event is recalculated taking into account the period of time during which the timer was paused or stopped.

Configuring SLA Notifications

Configuring SLA Notifications

By default, when the CloudSET SLA Management App is first installed, a standard email notification will be issued to the assigned agent if the SLA for an event violates (9), or to warn of an impending violation (10).

It is possible to override the recipient of these email messages with one or more alternative Agents or Groups (11) (see below) and change the content of the email subject (12) and email message body (13).

Standard Zendesk placeholders can be used in the subject and email body as outlined in the following article: Zendesk Support placeholders reference

Removing all recipients from the Sent To field (11) to an empty value (-) will prevent the email message being sent when the violation or warning occurs.

*Note:

It is possible that there will be a need to perform alternative actions if and when an SLA violation or warning occurs.

Under these circumstances it will be necessary to manually develop a Zendesk trigger to fire when a violation or warning occurs (see Develop Hybrid Triggers for more details)

Configuring Alternative, Additional Notifications

Configuring Alternative, Additional Notifications

There is often a requirement to send out additional or alternative notifications if and when an SLA violation or warning occurs.

Any number of additional notifications can be configured (1) to send an email with a different subject or email body to alternative recipients (2).

Rules can be configured to determine the conditions under which a notification should be sent (3) (see below for full details).

A notification can be removed if no longer required (4).

The original 'default' notification configuration (5) must always remain in place, but if required the email notification can be suppressed by removing all recipients.

When defining an notification rule (1) it is possible to specify All of the field values that must be set (2) in order for the email notification to be sent.

In addition or alternatively, it is also possible to specify a list of values Any of which could be set for a field in order for the notification to be sent (3).

So in the example above the notification will be sent if the Priority is 'Urgent' AND the Type is either 'Incident' OR 'Problem'.

*Note: the rule definitions work in much the same way as the conditions defined for Zendesk Triggers and the following article provides more detail should a further explanation be required: Understanding trigger conditions and actions

Enter an appropriate label (4) to describe the purpose of the notification rule and select 'OK' to save the rule (5).

Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (Metrics Tab) (SLA4)

Sub Banner

The following are instructions for the use of the Metrics tab to refine the behaviour of events to be measured in your solution.

If required, please see the article named Configure SLA Metrics for an explanation of when and why to configure metrics, including examples.

Defining Rules and Behaviour for SLA Events

Defining Rules and Behaviour for SLA Events

Generic Event Names

The Metric Type (4) is used as the generic reference to the corresponding event in generated ticket fields using capitalization  (e.g. SLA3 Solve Measure), although this name is often replaced in Labels using the Policies tab (also see Monitoring SLA Performance using Zendesk Views for more information regarding the use of these ticket fields).

Pausing & Stopping Timers for Events

Pausing & Stopping Timers for Events

For each event included in your implemented model template, it is possible to indicate if the associated timer should be paused or stopped under the following circumstances:

  • Check the Pending box (4) if the timer should be paused when the ticket is placed in a status of 'Pending' while waiting for more information from the customer
  • Check the Hold box (5) if the timer should be paused when the ticket is placed in a status of 'On-hold' while waiting for action by a third party or department other than the Customer Support team
  • Check the Pass box (6) if the timer should be stopped when the conditions for passing the SLA have been met, including when the ticket is placed in a status of 'Solved'

If the event timer is paused or stopped for any of the reasons above, the timer will be restarted if and when the conditions causing the pause or stop are no longer in place.

When the timer is restarted the due date/time for completion of the event is recalculated taking into account the period of time during which the timer was paused or stopped.

Configuring SLA Notifications

Configuring SLA Notifications

By default, when the CloudSET SLA Management App is first installed, a standard email notification will be issued to the assigned agent if the SLA for an event violates (9), or to warn of an impending violation (10).

It is possible to override the recipient of these email messages with one or more alternative Agents or Groups (11) (see below) and change the content of the email subject (12) and email message body (13).

Standard Zendesk placeholders can be used in the subject and email body as outlined in the following article: Zendesk Support placeholders reference

Removing all recipients from the Sent To field (11) to an empty value (-) will prevent the email message being sent when the violation or warning occurs.

*Note:

It is possible that there will be a need to perform alternative actions if and when an SLA violation or warning occurs.

Under these circumstances it will be necessary to manually develop a Zendesk trigger to fire when a violation or warning occurs (see Develop Hybrid Triggers for more details)

Configuring Alternative, Additional Notifications

Configuring Alternative, Additional Notifications

There is often a requirement to send out additional or alternative notifications if and when an SLA violation or warning occurs.

Any number of additional notifications can be configured (1) to send an email with a different subject or email body to alternative recipients (2).

Rules can be configured to determine the conditions under which a notification should be sent (3) (see below for full details).

A notification can be removed if no longer required (4).

The original 'default' notification configuration (5) must always remain in place, but if required the email notification can be suppressed by removing all recipients.

When defining an notification rule (1) it is possible to specify All of the field values that must be set (2) in order for the email notification to be sent.

In addition or alternatively, it is also possible to specify a list of values Any of which could be set for a field in order for the notification to be sent (3).

So in the example above the notification will be sent if the Priority is 'Urgent' AND the Type is either 'Incident' OR 'Problem'.

*Note: the rule definitions work in much the same way as the conditions defined for Zendesk Triggers and the following article provides more detail should a further explanation be required: Understanding trigger conditions and actions

Enter an appropriate label (4) to describe the purpose of the notification rule and select 'OK' to save the rule (5).

Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (Metrics Tab) (SLA4)

Sub Banner

Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (Metrics Tab) (SLA4)

The following are instructions for the use of the Metrics tab to refine the behaviour of events to be measured in your solution.

If required, please see the article named Configure SLA Metrics for an explanation of when and why to configure metrics, including examples.

Defining Rules and Behaviour for SLA Events

Defining Rules and Behaviour for SLA Events

Generic Event Names

The Metric Type (4) is used as the generic reference to the corresponding event in generated ticket fields using capitalization  (e.g. SLA3 Solve Measure), although this name is often replaced in Labels using the Policies tab (also see Monitoring SLA Performance using Zendesk Views for more information regarding the use of these ticket fields).

Pausing & Stopping Timers for Events

Pausing & Stopping Timers for Events

For each event included in your implemented model template, it is possible to indicate if the associated timer should be paused or stopped under the following circumstances:

  • Check the Pending box (4) if the timer should be paused when the ticket is placed in a status of 'Pending' while waiting for more information from the customer
  • Check the Hold box (5) if the timer should be paused when the ticket is placed in a status of 'On-hold' while waiting for action by a third party or department other than the Customer Support team
  • Check the Pass box (6) if the timer should be stopped when the conditions for passing the SLA have been met, including when the ticket is placed in a status of 'Solved'

If the event timer is paused or stopped for any of the reasons above, the timer will be restarted if and when the conditions causing the pause or stop are no longer in place.

When the timer is restarted the due date/time for completion of the event is recalculated taking into account the period of time during which the timer was paused or stopped.

Configuring SLA Notifications

Configuring SLA Notifications

By default, when the CloudSET SLA Management App is first installed, a standard email notification will be issued to the assigned agent if the SLA for an event violates (9), or to warn of an impending violation (10).

It is possible to override the recipient of these email messages with one or more alternative Agents or Groups (11) (see below) and change the content of the email subject (12) and email message body (13).

Standard Zendesk placeholders can be used in the subject and email body as outlined in the following article: Zendesk Support placeholders reference

Removing all recipients from the Sent To field (11) to an empty value (-) will prevent the email message being sent when the violation or warning occurs.

*Note:

It is possible that there will be a need to perform alternative actions if and when an SLA violation or warning occurs.

Under these circumstances it will be necessary to manually develop a Zendesk trigger to fire when a violation or warning occurs (see Develop Hybrid Triggers for more details)

Configuring Alternative, Additional Notifications

Configuring Alternative, Additional Notifications

There is often a requirement to send out additional or alternative notifications if and when an SLA violation or warning occurs.

Any number of additional notifications can be configured (1) to send an email with a different subject or email body to alternative recipients (2).

Rules can be configured to determine the conditions under which a notification should be sent (3) (see below for full details).

A notification can be removed if no longer required (4).

The original 'default' notification configuration (5) must always remain in place, but if required the email notification can be suppressed by removing all recipients.

When defining an notification rule (1) it is possible to specify All of the field values that must be set (2) in order for the email notification to be sent.

In addition or alternatively, it is also possible to specify a list of values Any of which could be set for a field in order for the notification to be sent (3).

So in the example above the notification will be sent if the Priority is 'Urgent' AND the Type is either 'Incident' OR 'Problem'.

*Note: the rule definitions work in much the same way as the conditions defined for Zendesk Triggers and the following article provides more detail should a further explanation be required: Understanding trigger conditions and actions

Enter an appropriate label (4) to describe the purpose of the notification rule and select 'OK' to save the rule (5).