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

Sub Banner

The following are instructions for the use of the SLA Events tab to refine the behavior of events involved in your solution.

If required, please see Configure Events for an explanation of when and why to configure events, including examples.

Defining Rules and Behavior for SLA Events

Defining Rules and Behavior for SLA Events

Generic Event Names

The Event Name (3) is used as the generic reference in generated ticket fields using capitalization  (e.g. SLA3 Respond Measure), although this name is often replaced in Labels using the SLA Plans tab.

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.

Counting SLA Violations and Passes

Counting SLA Violations and Passes

Certain events will involve a the use of a timer that is repeatedly restarted each time the timer ends and/or each time the conditions required to pass the SLA are met, until the ticket is solved.

For example, a regular progress update each day until the ticket is solved.

When this is the case it is possible that the event will violate and pass the SLA multiple times during the life of the ticket.

  • Check the Violations box (7) to maintain a count of the number of times the SLA is violated, i.e. the timer ends and is restarted
  • Check the Passes box (8) to maintain a count of the number of times the SLA is passed, i.e. the SLA pass conditions are met before the timer ends and the timer is then restarted

The following ticket fields will be used to record the counts:

  • SLA3 eventname ViolateCount - where eventname is the name of the associated event, e.g. SLA3 Update ViolateCount
  • SLA3 eventname PassCount - where eventname is the name of the associated event, e.g. SLA3 Update PassCount

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 (11) and change the content of the email subject (12) and email message body (13).

Setting 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 send email notifications to a Group and/or determine the recipient based on special rules and conditions.

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)

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

Sub Banner

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

The following are instructions for the use of the SLA Events tab to refine the behavior of events involved in your solution.

If required, please see Configure Events for an explanation of when and why to configure events, including examples.

Defining Rules and Behavior for SLA Events

Defining Rules and Behavior for SLA Events

Generic Event Names

The Event Name (3) is used as the generic reference in generated ticket fields using capitalization  (e.g. SLA3 Respond Measure), although this name is often replaced in Labels using the SLA Plans tab.

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.

Counting SLA Violations and Passes

Counting SLA Violations and Passes

Certain events will involve a the use of a timer that is repeatedly restarted each time the timer ends and/or each time the conditions required to pass the SLA are met, until the ticket is solved.

For example, a regular progress update each day until the ticket is solved.

When this is the case it is possible that the event will violate and pass the SLA multiple times during the life of the ticket.

  • Check the Violations box (7) to maintain a count of the number of times the SLA is violated, i.e. the timer ends and is restarted
  • Check the Passes box (8) to maintain a count of the number of times the SLA is passed, i.e. the SLA pass conditions are met before the timer ends and the timer is then restarted

The following ticket fields will be used to record the counts:

  • SLA3 eventname ViolateCount - where eventname is the name of the associated event, e.g. SLA3 Update ViolateCount
  • SLA3 eventname PassCount - where eventname is the name of the associated event, e.g. SLA3 Update PassCount

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 (11) and change the content of the email subject (12) and email message body (13).

Setting 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 send email notifications to a Group and/or determine the recipient based on special rules and conditions.

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)

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

Sub Banner

The following are instructions for the use of the SLA Events tab to refine the behavior of events involved in your solution.

If required, please see Configure Events for an explanation of when and why to configure events, including examples.

Defining Rules and Behavior for SLA Events

Defining Rules and Behavior for SLA Events

Generic Event Names

The Event Name (3) is used as the generic reference in generated ticket fields using capitalization  (e.g. SLA3 Respond Measure), although this name is often replaced in Labels using the SLA Plans tab.

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.

Counting SLA Violations and Passes

Counting SLA Violations and Passes

Certain events will involve a the use of a timer that is repeatedly restarted each time the timer ends and/or each time the conditions required to pass the SLA are met, until the ticket is solved.

For example, a regular progress update each day until the ticket is solved.

When this is the case it is possible that the event will violate and pass the SLA multiple times during the life of the ticket.

  • Check the Violations box (7) to maintain a count of the number of times the SLA is violated, i.e. the timer ends and is restarted
  • Check the Passes box (8) to maintain a count of the number of times the SLA is passed, i.e. the SLA pass conditions are met before the timer ends and the timer is then restarted

The following ticket fields will be used to record the counts:

  • SLA3 eventname ViolateCount - where eventname is the name of the associated event, e.g. SLA3 Update ViolateCount
  • SLA3 eventname PassCount - where eventname is the name of the associated event, e.g. SLA3 Update PassCount

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 (11) and change the content of the email subject (12) and email message body (13).

Setting 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 send email notifications to a Group and/or determine the recipient based on special rules and conditions.

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)

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

Sub Banner

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

The following are instructions for the use of the SLA Events tab to refine the behavior of events involved in your solution.

If required, please see Configure Events for an explanation of when and why to configure events, including examples.

Defining Rules and Behavior for SLA Events

Defining Rules and Behavior for SLA Events

Generic Event Names

The Event Name (3) is used as the generic reference in generated ticket fields using capitalization  (e.g. SLA3 Respond Measure), although this name is often replaced in Labels using the SLA Plans tab.

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.

Counting SLA Violations and Passes

Counting SLA Violations and Passes

Certain events will involve a the use of a timer that is repeatedly restarted each time the timer ends and/or each time the conditions required to pass the SLA are met, until the ticket is solved.

For example, a regular progress update each day until the ticket is solved.

When this is the case it is possible that the event will violate and pass the SLA multiple times during the life of the ticket.

  • Check the Violations box (7) to maintain a count of the number of times the SLA is violated, i.e. the timer ends and is restarted
  • Check the Passes box (8) to maintain a count of the number of times the SLA is passed, i.e. the SLA pass conditions are met before the timer ends and the timer is then restarted

The following ticket fields will be used to record the counts:

  • SLA3 eventname ViolateCount - where eventname is the name of the associated event, e.g. SLA3 Update ViolateCount
  • SLA3 eventname PassCount - where eventname is the name of the associated event, e.g. SLA3 Update PassCount

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 (11) and change the content of the email subject (12) and email message body (13).

Setting 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 send email notifications to a Group and/or determine the recipient based on special rules and conditions.

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)