Implementing Components for a Custom Metric or Event

Sub Banner

The CloudSET SLA Management extension framework provides the ability to setup and configure the timing specifications to measure many alternative metrics or events.

For some of these metrics there is a naturally occurring event in Zendesk, e.g. an agent is assigned, a public comment is applied, the ticket is solved...

However, the CloudSET SLA Management extension framework enables support for the measurement of additional metrics that aren't identified by an event that occurs naturally as part of the standard Zendesk behavior.

For example:

  • Identify when a response or update has been given externally to Zendesk, e.g. during a phone call, or via an external messaging service, such as when a ticket has been created by an agent on behalf of the customer and the ticket description includes the initial response
  • Measure the amount of time within which a workaround is provided
  • Measure the time taken for an on-site engineer to arrive at the customer premises
  • etc....

Implementing Support for an Initial Response or Update Externally to Zendesk (e.g. by Phone)

Implementing Support for an Initial Response or Update Externally to Zendesk (e.g. by Phone)

Having selected the option to include the Respond event and/or the Update event in your model (3, 4 & 5) all components necessary to automatically start the corresponding event timer will be generated.
The components used to identify when a public comment has been applied to the ticket will also be generated to automatically stop the timer and identify the event has occurred.

*Note: depending upon the model in use as part of your setup the labels for these options might differ slightly.

However, if there is a requirement to identify when a response or update has been given externally to Zendesk it will also be necessary to select the appropriate option in the your model configuration (6).
The selection of these options will generate all components required to manually control when the event timer stops using additional rules to identify when the event has occurred.

Additional Checkbox Ticket Fields are Generated

Additional Checkbox Ticket Fields are Generated

Once the appropriate options are selected and the configurations are saved, a corresponding Checkbox ticket field will be generated (2).

If the SLA3 Respond Phone box or the SLA3 Update Phone box is checked then the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

However, as with all SLA3 generated ticket fields these Checkbox fields will be hidden and unavailable for direct use in the ticket form.
It is therefore necessary to implement additional custom components to determine the rules and circumstances under which the box should be checked, as outlined in the following steps.

Deploy the Configuration to Install the Required Macro and Trigger

Deploy the Configuration to Install the Required Macro and Trigger

An example macro and trigger combination is available for deployment into your Zendesk account as a template for refinement or use as is.

Locate the configuration containing the macro and trigger required to provide an initial response or update via a phone call (4) - within the Shared Configurations with migration.zendesk.com (3).

Select the deploy link (5) to start the deployment process.

*Note: Please raise a ticket via support@cloudset.zendesk.com should the configuration not be available to your Zendesk account.

Otherwise the following steps describe how to create the macro and trigger manually, and also how to make use of the macro and trigger.

Apply a Private Comment using a Macro

Apply a Private Comment using a Macro

In the absence of a naturally occurring Zendesk event to identify when a response or update has been given during a phone call or via another external messaging service, a Zendesk Macro can be provided for use by an agent to identify when the event has occurred.

It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event has occurred, when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has stopped and the SLA has been marked as passed even though a public response hasn't been given to the customer.

However, it is also recommended that the macro doesn't check the box used to indicate to the SLA Management solution that the event has occurred.
Otherwise in the event that the macro was applied in error although the comment can be removed, it won't be possible to reset the hidden Checkbox without refreshing the page and the update could be applied inadvertently.
The use of a corresponding trigger is therefore recommended for this purpose.

Respond to the Macro using a Trigger

Respond to the Macro using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so checks the box to indicate the occurrence of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

Implementing Support for an Auto Starting Custom Metric or Event (e.g. Workaround)

Implementing Support for an Auto Starting Custom Metric or Event (e.g. Workaround)

Depending on the model in use a number of options will be available for the use of timers that don't have a naturally occurring event in Zendesk to indicate if and when the SLA pass criteria event has been met.

For many of these events, if selected, all components necessary to automatically start the corresponding event timer will be generated.
At the time of writing this article these types of event timer include the following:

  • Workaround Event
  • Custom Event
  • Linear1 Events
  • Linear2 Events
  • Linear3 Events

Without a naturally occurring Zendesk event the SLA Management solution will not know when the event has occurred and so when to stop the timer and mark the SLA measurement as passed.
However, the selection of these events will also generate all components required to manually control when the event timer stops using additional rules to identify when the event has occurred.

Additional Checkbox Ticket Fields are Generated

Additional Checkbox Ticket Fields are Generated

Once the appropriate options are selected and the configurations are saved, a corresponding Checkbox ticket field will be generated (2).

If the box is checked (e.g. SLA3 Workaround Supplied) then the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

However, as with all SLA3 generated ticket fields these Checkbox fields will be hidden and unavailable for direct use in the ticket form.
It is therefore necessary to implement additional custom components to determine the rules and circumstances under which the box should be checked, as outlined in the following steps.

Deploy the Configuration to Install the Required Macro and Trigger

Deploy the Configuration to Install the Required Macro and Trigger

An example set of macro and trigger combination is available for deployment into your Zendesk account as a template for refinement or use as is.

The macros and triggers can be used to indicate that a workaround has been provided so the event timer should be stopped and also how to indicate that the workaround was rejected in which case the event timer should be restarted.

Locate the configuration containing the macro and trigger required to provide an initial response or update via a phone call (4) - within the Shared Configurations with migration.zendesk.com (3).

Select the deploy link (5) to start the deployment process.

*Note: Please raise a ticket via support@cloudset.zendesk.com should the configuration not be available to your Zendesk account.

Otherwise the following steps describe how to create the macro and trigger combinations manually.

Confirm the Event Occurrence using a Macro

Confirm the Event Occurrence using a Macro

In the absence of a naturally occurring Zendesk event to identify when event occurred (e.g. when the workaround was provided), a Zendesk Macro can be provided for use by an agent to identify when the event has occurred.

It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event has occurred, when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has stopped and the SLA has been marked as passed.

However, it is also recommended that the macro doesn't check the box used to indicate to the SLA Management solution that the event has occurred.
Otherwise in the event that the macro was applied in error although the comment can be removed, it won't be possible to reset the hidden Checkbox without refreshing the page and the update could be applied inadvertently.
The use of a corresponding trigger is therefore recommended for this purpose.

Process the Pass Criteria using a Trigger

Process the Pass Criteria using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so checks the box to indicate the occurrence of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

Reverting the Event Occurrence using a Macro

Reverting the Event Occurrence using a Macro

It is possible that the macro used to indicate the event occurrence in the above step was applied in error, or that there is some disagreement that the pass criteria has been met.
For example it might transpire that the provided workaround didn't sufficiently resolve the issue and so has been rejected by the customer.

Since there is not a naturally occurring event to identify when this situation occurs it might be appropriate to provide an additional macro for use by the agent to ensure the timer is restarted and the SLA pass measurement is removed for the event.

As for the macro used to indicate the occurrence of the event, It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event was reverted (e.g. the workaround was rejected), when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has restarted and the SLA pass has been removed.

Also for the reasons outline in the previous steps, it is recommended that the macro doesn't uncheck the box used to indicate to the SLA Management solution that the event has occurred.
The use of a corresponding trigger is therefore recommended for this purpose.

Process the Event Reversion using a Trigger

Process the Event Reversion using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so unchecks the box to indicate the reversion of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by restarting the corresponding timer and remove the SLA pass, provided the SLA hasn't previously been violated.

Possible Alternative Event Reversion Technique

The above procedure relies on the agent deliberately restarting the timer and removing the SLA pass which could easily be forgotten or avoided.

It might therefore be possible to agree a standard reply from the customer, in which case a trigger could look for the standard reply in the comment rather than using a macro applied by the agent.

In this case the trigger should be constructed as in the previous step, but would rather check for the presence of an agreed string in a public comment.

Implementing Components for a Custom Metric or Event

Sub Banner

Implementing Components for a Custom Metric or Event

The CloudSET SLA Management extension framework provides the ability to setup and configure the timing specifications to measure many alternative metrics or events.

For some of these metrics there is a naturally occurring event in Zendesk, e.g. an agent is assigned, a public comment is applied, the ticket is solved...

However, the CloudSET SLA Management extension framework enables support for the measurement of additional metrics that aren't identified by an event that occurs naturally as part of the standard Zendesk behavior.

For example:

  • Identify when a response or update has been given externally to Zendesk, e.g. during a phone call, or via an external messaging service, such as when a ticket has been created by an agent on behalf of the customer and the ticket description includes the initial response
  • Measure the amount of time within which a workaround is provided
  • Measure the time taken for an on-site engineer to arrive at the customer premises
  • etc....

Implementing Support for an Initial Response or Update Externally to Zendesk (e.g. by Phone)

Implementing Support for an Initial Response or Update Externally to Zendesk (e.g. by Phone)

Having selected the option to include the Respond event and/or the Update event in your model (3, 4 & 5) all components necessary to automatically start the corresponding event timer will be generated.
The components used to identify when a public comment has been applied to the ticket will also be generated to automatically stop the timer and identify the event has occurred.

*Note: depending upon the model in use as part of your setup the labels for these options might differ slightly.

However, if there is a requirement to identify when a response or update has been given externally to Zendesk it will also be necessary to select the appropriate option in the your model configuration (6).
The selection of these options will generate all components required to manually control when the event timer stops using additional rules to identify when the event has occurred.

Additional Checkbox Ticket Fields are Generated

Additional Checkbox Ticket Fields are Generated

Once the appropriate options are selected and the configurations are saved, a corresponding Checkbox ticket field will be generated (2).

If the SLA3 Respond Phone box or the SLA3 Update Phone box is checked then the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

However, as with all SLA3 generated ticket fields these Checkbox fields will be hidden and unavailable for direct use in the ticket form.
It is therefore necessary to implement additional custom components to determine the rules and circumstances under which the box should be checked, as outlined in the following steps.

Deploy the Configuration to Install the Required Macro and Trigger

Deploy the Configuration to Install the Required Macro and Trigger

An example macro and trigger combination is available for deployment into your Zendesk account as a template for refinement or use as is.

Locate the configuration containing the macro and trigger required to provide an initial response or update via a phone call (4) - within the Shared Configurations with migration.zendesk.com (3).

Select the deploy link (5) to start the deployment process.

*Note: Please raise a ticket via support@cloudset.zendesk.com should the configuration not be available to your Zendesk account.

Otherwise the following steps describe how to create the macro and trigger manually, and also how to make use of the macro and trigger.

Apply a Private Comment using a Macro

Apply a Private Comment using a Macro

In the absence of a naturally occurring Zendesk event to identify when a response or update has been given during a phone call or via another external messaging service, a Zendesk Macro can be provided for use by an agent to identify when the event has occurred.

It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event has occurred, when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has stopped and the SLA has been marked as passed even though a public response hasn't been given to the customer.

However, it is also recommended that the macro doesn't check the box used to indicate to the SLA Management solution that the event has occurred.
Otherwise in the event that the macro was applied in error although the comment can be removed, it won't be possible to reset the hidden Checkbox without refreshing the page and the update could be applied inadvertently.
The use of a corresponding trigger is therefore recommended for this purpose.

Respond to the Macro using a Trigger

Respond to the Macro using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so checks the box to indicate the occurrence of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

Implementing Support for an Auto Starting Custom Metric or Event (e.g. Workaround)

Implementing Support for an Auto Starting Custom Metric or Event (e.g. Workaround)

Depending on the model in use a number of options will be available for the use of timers that don't have a naturally occurring event in Zendesk to indicate if and when the SLA pass criteria event has been met.

For many of these events, if selected, all components necessary to automatically start the corresponding event timer will be generated.
At the time of writing this article these types of event timer include the following:

  • Workaround Event
  • Custom Event
  • Linear1 Events
  • Linear2 Events
  • Linear3 Events

Without a naturally occurring Zendesk event the SLA Management solution will not know when the event has occurred and so when to stop the timer and mark the SLA measurement as passed.
However, the selection of these events will also generate all components required to manually control when the event timer stops using additional rules to identify when the event has occurred.

Additional Checkbox Ticket Fields are Generated

Additional Checkbox Ticket Fields are Generated

Once the appropriate options are selected and the configurations are saved, a corresponding Checkbox ticket field will be generated (2).

If the box is checked (e.g. SLA3 Workaround Supplied) then the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

However, as with all SLA3 generated ticket fields these Checkbox fields will be hidden and unavailable for direct use in the ticket form.
It is therefore necessary to implement additional custom components to determine the rules and circumstances under which the box should be checked, as outlined in the following steps.

Deploy the Configuration to Install the Required Macro and Trigger

Deploy the Configuration to Install the Required Macro and Trigger

An example set of macro and trigger combination is available for deployment into your Zendesk account as a template for refinement or use as is.

The macros and triggers can be used to indicate that a workaround has been provided so the event timer should be stopped and also how to indicate that the workaround was rejected in which case the event timer should be restarted.

Locate the configuration containing the macro and trigger required to provide an initial response or update via a phone call (4) - within the Shared Configurations with migration.zendesk.com (3).

Select the deploy link (5) to start the deployment process.

*Note: Please raise a ticket via support@cloudset.zendesk.com should the configuration not be available to your Zendesk account.

Otherwise the following steps describe how to create the macro and trigger combinations manually.

Confirm the Event Occurrence using a Macro

Confirm the Event Occurrence using a Macro

In the absence of a naturally occurring Zendesk event to identify when event occurred (e.g. when the workaround was provided), a Zendesk Macro can be provided for use by an agent to identify when the event has occurred.

It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event has occurred, when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has stopped and the SLA has been marked as passed.

However, it is also recommended that the macro doesn't check the box used to indicate to the SLA Management solution that the event has occurred.
Otherwise in the event that the macro was applied in error although the comment can be removed, it won't be possible to reset the hidden Checkbox without refreshing the page and the update could be applied inadvertently.
The use of a corresponding trigger is therefore recommended for this purpose.

Process the Pass Criteria using a Trigger

Process the Pass Criteria using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so checks the box to indicate the occurrence of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

Reverting the Event Occurrence using a Macro

Reverting the Event Occurrence using a Macro

It is possible that the macro used to indicate the event occurrence in the above step was applied in error, or that there is some disagreement that the pass criteria has been met.
For example it might transpire that the provided workaround didn't sufficiently resolve the issue and so has been rejected by the customer.

Since there is not a naturally occurring event to identify when this situation occurs it might be appropriate to provide an additional macro for use by the agent to ensure the timer is restarted and the SLA pass measurement is removed for the event.

As for the macro used to indicate the occurrence of the event, It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event was reverted (e.g. the workaround was rejected), when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has restarted and the SLA pass has been removed.

Also for the reasons outline in the previous steps, it is recommended that the macro doesn't uncheck the box used to indicate to the SLA Management solution that the event has occurred.
The use of a corresponding trigger is therefore recommended for this purpose.

Process the Event Reversion using a Trigger

Process the Event Reversion using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so unchecks the box to indicate the reversion of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by restarting the corresponding timer and remove the SLA pass, provided the SLA hasn't previously been violated.

Possible Alternative Event Reversion Technique

The above procedure relies on the agent deliberately restarting the timer and removing the SLA pass which could easily be forgotten or avoided.

It might therefore be possible to agree a standard reply from the customer, in which case a trigger could look for the standard reply in the comment rather than using a macro applied by the agent.

In this case the trigger should be constructed as in the previous step, but would rather check for the presence of an agreed string in a public comment.

Implementing Components for a Custom Metric or Event

Sub Banner

The CloudSET SLA Management extension framework provides the ability to setup and configure the timing specifications to measure many alternative metrics or events.

For some of these metrics there is a naturally occurring event in Zendesk, e.g. an agent is assigned, a public comment is applied, the ticket is solved...

However, the CloudSET SLA Management extension framework enables support for the measurement of additional metrics that aren't identified by an event that occurs naturally as part of the standard Zendesk behavior.

For example:

  • Identify when a response or update has been given externally to Zendesk, e.g. during a phone call, or via an external messaging service, such as when a ticket has been created by an agent on behalf of the customer and the ticket description includes the initial response
  • Measure the amount of time within which a workaround is provided
  • Measure the time taken for an on-site engineer to arrive at the customer premises
  • etc....

Implementing Support for an Initial Response or Update Externally to Zendesk (e.g. by Phone)

Implementing Support for an Initial Response or Update Externally to Zendesk (e.g. by Phone)

Having selected the option to include the Respond event and/or the Update event in your model (3, 4 & 5) all components necessary to automatically start the corresponding event timer will be generated.
The components used to identify when a public comment has been applied to the ticket will also be generated to automatically stop the timer and identify the event has occurred.

*Note: depending upon the model in use as part of your setup the labels for these options might differ slightly.

However, if there is a requirement to identify when a response or update has been given externally to Zendesk it will also be necessary to select the appropriate option in the your model configuration (6).
The selection of these options will generate all components required to manually control when the event timer stops using additional rules to identify when the event has occurred.

Additional Checkbox Ticket Fields are Generated

Additional Checkbox Ticket Fields are Generated

Once the appropriate options are selected and the configurations are saved, a corresponding Checkbox ticket field will be generated (2).

If the SLA3 Respond Phone box or the SLA3 Update Phone box is checked then the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

However, as with all SLA3 generated ticket fields these Checkbox fields will be hidden and unavailable for direct use in the ticket form.
It is therefore necessary to implement additional custom components to determine the rules and circumstances under which the box should be checked, as outlined in the following steps.

Deploy the Configuration to Install the Required Macro and Trigger

Deploy the Configuration to Install the Required Macro and Trigger

An example macro and trigger combination is available for deployment into your Zendesk account as a template for refinement or use as is.

Locate the configuration containing the macro and trigger required to provide an initial response or update via a phone call (4) - within the Shared Configurations with migration.zendesk.com (3).

Select the deploy link (5) to start the deployment process.

*Note: Please raise a ticket via support@cloudset.zendesk.com should the configuration not be available to your Zendesk account.

Otherwise the following steps describe how to create the macro and trigger manually, and also how to make use of the macro and trigger.

Apply a Private Comment using a Macro

Apply a Private Comment using a Macro

In the absence of a naturally occurring Zendesk event to identify when a response or update has been given during a phone call or via another external messaging service, a Zendesk Macro can be provided for use by an agent to identify when the event has occurred.

It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event has occurred, when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has stopped and the SLA has been marked as passed even though a public response hasn't been given to the customer.

However, it is also recommended that the macro doesn't check the box used to indicate to the SLA Management solution that the event has occurred.
Otherwise in the event that the macro was applied in error although the comment can be removed, it won't be possible to reset the hidden Checkbox without refreshing the page and the update could be applied inadvertently.
The use of a corresponding trigger is therefore recommended for this purpose.

Respond to the Macro using a Trigger

Respond to the Macro using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so checks the box to indicate the occurrence of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

Implementing Support for an Auto Starting Custom Metric or Event (e.g. Workaround)

Implementing Support for an Auto Starting Custom Metric or Event (e.g. Workaround)

Depending on the model in use a number of options will be available for the use of timers that don't have a naturally occurring event in Zendesk to indicate if and when the SLA pass criteria event has been met.

For many of these events, if selected, all components necessary to automatically start the corresponding event timer will be generated.
At the time of writing this article these types of event timer include the following:

  • Workaround Event
  • Custom Event
  • Linear1 Events
  • Linear2 Events
  • Linear3 Events

Without a naturally occurring Zendesk event the SLA Management solution will not know when the event has occurred and so when to stop the timer and mark the SLA measurement as passed.
However, the selection of these events will also generate all components required to manually control when the event timer stops using additional rules to identify when the event has occurred.

Additional Checkbox Ticket Fields are Generated

Additional Checkbox Ticket Fields are Generated

Once the appropriate options are selected and the configurations are saved, a corresponding Checkbox ticket field will be generated (2).

If the box is checked (e.g. SLA3 Workaround Supplied) then the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

However, as with all SLA3 generated ticket fields these Checkbox fields will be hidden and unavailable for direct use in the ticket form.
It is therefore necessary to implement additional custom components to determine the rules and circumstances under which the box should be checked, as outlined in the following steps.

Deploy the Configuration to Install the Required Macro and Trigger

Deploy the Configuration to Install the Required Macro and Trigger

An example set of macro and trigger combination is available for deployment into your Zendesk account as a template for refinement or use as is.

The macros and triggers can be used to indicate that a workaround has been provided so the event timer should be stopped and also how to indicate that the workaround was rejected in which case the event timer should be restarted.

Locate the configuration containing the macro and trigger required to provide an initial response or update via a phone call (4) - within the Shared Configurations with migration.zendesk.com (3).

Select the deploy link (5) to start the deployment process.

*Note: Please raise a ticket via support@cloudset.zendesk.com should the configuration not be available to your Zendesk account.

Otherwise the following steps describe how to create the macro and trigger combinations manually.

Confirm the Event Occurrence using a Macro

Confirm the Event Occurrence using a Macro

In the absence of a naturally occurring Zendesk event to identify when event occurred (e.g. when the workaround was provided), a Zendesk Macro can be provided for use by an agent to identify when the event has occurred.

It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event has occurred, when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has stopped and the SLA has been marked as passed.

However, it is also recommended that the macro doesn't check the box used to indicate to the SLA Management solution that the event has occurred.
Otherwise in the event that the macro was applied in error although the comment can be removed, it won't be possible to reset the hidden Checkbox without refreshing the page and the update could be applied inadvertently.
The use of a corresponding trigger is therefore recommended for this purpose.

Process the Pass Criteria using a Trigger

Process the Pass Criteria using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so checks the box to indicate the occurrence of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

Reverting the Event Occurrence using a Macro

Reverting the Event Occurrence using a Macro

It is possible that the macro used to indicate the event occurrence in the above step was applied in error, or that there is some disagreement that the pass criteria has been met.
For example it might transpire that the provided workaround didn't sufficiently resolve the issue and so has been rejected by the customer.

Since there is not a naturally occurring event to identify when this situation occurs it might be appropriate to provide an additional macro for use by the agent to ensure the timer is restarted and the SLA pass measurement is removed for the event.

As for the macro used to indicate the occurrence of the event, It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event was reverted (e.g. the workaround was rejected), when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has restarted and the SLA pass has been removed.

Also for the reasons outline in the previous steps, it is recommended that the macro doesn't uncheck the box used to indicate to the SLA Management solution that the event has occurred.
The use of a corresponding trigger is therefore recommended for this purpose.

Process the Event Reversion using a Trigger

Process the Event Reversion using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so unchecks the box to indicate the reversion of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by restarting the corresponding timer and remove the SLA pass, provided the SLA hasn't previously been violated.

Possible Alternative Event Reversion Technique

The above procedure relies on the agent deliberately restarting the timer and removing the SLA pass which could easily be forgotten or avoided.

It might therefore be possible to agree a standard reply from the customer, in which case a trigger could look for the standard reply in the comment rather than using a macro applied by the agent.

In this case the trigger should be constructed as in the previous step, but would rather check for the presence of an agreed string in a public comment.

Implementing Components for a Custom Metric or Event

Sub Banner

Implementing Components for a Custom Metric or Event

The CloudSET SLA Management extension framework provides the ability to setup and configure the timing specifications to measure many alternative metrics or events.

For some of these metrics there is a naturally occurring event in Zendesk, e.g. an agent is assigned, a public comment is applied, the ticket is solved...

However, the CloudSET SLA Management extension framework enables support for the measurement of additional metrics that aren't identified by an event that occurs naturally as part of the standard Zendesk behavior.

For example:

  • Identify when a response or update has been given externally to Zendesk, e.g. during a phone call, or via an external messaging service, such as when a ticket has been created by an agent on behalf of the customer and the ticket description includes the initial response
  • Measure the amount of time within which a workaround is provided
  • Measure the time taken for an on-site engineer to arrive at the customer premises
  • etc....

Implementing Support for an Initial Response or Update Externally to Zendesk (e.g. by Phone)

Implementing Support for an Initial Response or Update Externally to Zendesk (e.g. by Phone)

Having selected the option to include the Respond event and/or the Update event in your model (3, 4 & 5) all components necessary to automatically start the corresponding event timer will be generated.
The components used to identify when a public comment has been applied to the ticket will also be generated to automatically stop the timer and identify the event has occurred.

*Note: depending upon the model in use as part of your setup the labels for these options might differ slightly.

However, if there is a requirement to identify when a response or update has been given externally to Zendesk it will also be necessary to select the appropriate option in the your model configuration (6).
The selection of these options will generate all components required to manually control when the event timer stops using additional rules to identify when the event has occurred.

Additional Checkbox Ticket Fields are Generated

Additional Checkbox Ticket Fields are Generated

Once the appropriate options are selected and the configurations are saved, a corresponding Checkbox ticket field will be generated (2).

If the SLA3 Respond Phone box or the SLA3 Update Phone box is checked then the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

However, as with all SLA3 generated ticket fields these Checkbox fields will be hidden and unavailable for direct use in the ticket form.
It is therefore necessary to implement additional custom components to determine the rules and circumstances under which the box should be checked, as outlined in the following steps.

Deploy the Configuration to Install the Required Macro and Trigger

Deploy the Configuration to Install the Required Macro and Trigger

An example macro and trigger combination is available for deployment into your Zendesk account as a template for refinement or use as is.

Locate the configuration containing the macro and trigger required to provide an initial response or update via a phone call (4) - within the Shared Configurations with migration.zendesk.com (3).

Select the deploy link (5) to start the deployment process.

*Note: Please raise a ticket via support@cloudset.zendesk.com should the configuration not be available to your Zendesk account.

Otherwise the following steps describe how to create the macro and trigger manually, and also how to make use of the macro and trigger.

Apply a Private Comment using a Macro

Apply a Private Comment using a Macro

In the absence of a naturally occurring Zendesk event to identify when a response or update has been given during a phone call or via another external messaging service, a Zendesk Macro can be provided for use by an agent to identify when the event has occurred.

It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event has occurred, when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has stopped and the SLA has been marked as passed even though a public response hasn't been given to the customer.

However, it is also recommended that the macro doesn't check the box used to indicate to the SLA Management solution that the event has occurred.
Otherwise in the event that the macro was applied in error although the comment can be removed, it won't be possible to reset the hidden Checkbox without refreshing the page and the update could be applied inadvertently.
The use of a corresponding trigger is therefore recommended for this purpose.

Respond to the Macro using a Trigger

Respond to the Macro using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so checks the box to indicate the occurrence of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

Implementing Support for an Auto Starting Custom Metric or Event (e.g. Workaround)

Implementing Support for an Auto Starting Custom Metric or Event (e.g. Workaround)

Depending on the model in use a number of options will be available for the use of timers that don't have a naturally occurring event in Zendesk to indicate if and when the SLA pass criteria event has been met.

For many of these events, if selected, all components necessary to automatically start the corresponding event timer will be generated.
At the time of writing this article these types of event timer include the following:

  • Workaround Event
  • Custom Event
  • Linear1 Events
  • Linear2 Events
  • Linear3 Events

Without a naturally occurring Zendesk event the SLA Management solution will not know when the event has occurred and so when to stop the timer and mark the SLA measurement as passed.
However, the selection of these events will also generate all components required to manually control when the event timer stops using additional rules to identify when the event has occurred.

Additional Checkbox Ticket Fields are Generated

Additional Checkbox Ticket Fields are Generated

Once the appropriate options are selected and the configurations are saved, a corresponding Checkbox ticket field will be generated (2).

If the box is checked (e.g. SLA3 Workaround Supplied) then the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

However, as with all SLA3 generated ticket fields these Checkbox fields will be hidden and unavailable for direct use in the ticket form.
It is therefore necessary to implement additional custom components to determine the rules and circumstances under which the box should be checked, as outlined in the following steps.

Deploy the Configuration to Install the Required Macro and Trigger

Deploy the Configuration to Install the Required Macro and Trigger

An example set of macro and trigger combination is available for deployment into your Zendesk account as a template for refinement or use as is.

The macros and triggers can be used to indicate that a workaround has been provided so the event timer should be stopped and also how to indicate that the workaround was rejected in which case the event timer should be restarted.

Locate the configuration containing the macro and trigger required to provide an initial response or update via a phone call (4) - within the Shared Configurations with migration.zendesk.com (3).

Select the deploy link (5) to start the deployment process.

*Note: Please raise a ticket via support@cloudset.zendesk.com should the configuration not be available to your Zendesk account.

Otherwise the following steps describe how to create the macro and trigger combinations manually.

Confirm the Event Occurrence using a Macro

Confirm the Event Occurrence using a Macro

In the absence of a naturally occurring Zendesk event to identify when event occurred (e.g. when the workaround was provided), a Zendesk Macro can be provided for use by an agent to identify when the event has occurred.

It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event has occurred, when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has stopped and the SLA has been marked as passed.

However, it is also recommended that the macro doesn't check the box used to indicate to the SLA Management solution that the event has occurred.
Otherwise in the event that the macro was applied in error although the comment can be removed, it won't be possible to reset the hidden Checkbox without refreshing the page and the update could be applied inadvertently.
The use of a corresponding trigger is therefore recommended for this purpose.

Process the Pass Criteria using a Trigger

Process the Pass Criteria using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so checks the box to indicate the occurrence of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by stopping the corresponding timer and if this has occurred before the calculated due date/time, the SLA measurement will be marked as passed.

Reverting the Event Occurrence using a Macro

Reverting the Event Occurrence using a Macro

It is possible that the macro used to indicate the event occurrence in the above step was applied in error, or that there is some disagreement that the pass criteria has been met.
For example it might transpire that the provided workaround didn't sufficiently resolve the issue and so has been rejected by the customer.

Since there is not a naturally occurring event to identify when this situation occurs it might be appropriate to provide an additional macro for use by the agent to ensure the timer is restarted and the SLA pass measurement is removed for the event.

As for the macro used to indicate the occurrence of the event, It is recommended that this macro is used to apply a suitable private comment to the ticket (2), since this gives a clear indication that the event was reverted (e.g. the workaround was rejected), when the macro was applied and by whom.
The presence of this private comment (3) will also explain why the event timer has restarted and the SLA pass has been removed.

Also for the reasons outline in the previous steps, it is recommended that the macro doesn't uncheck the box used to indicate to the SLA Management solution that the event has occurred.
The use of a corresponding trigger is therefore recommended for this purpose.

Process the Event Reversion using a Trigger

Process the Event Reversion using a Trigger

For the reasons outlined in the previous step it is recommended that a trigger is used to identify when the macro has applied the private comment (2) and if so unchecks the box to indicate the reversion of the event (3).

This ensures that the box is only ever checked if and when the macro has been deliberately applied, in which case the SLA Management solution will respond by restarting the corresponding timer and remove the SLA pass, provided the SLA hasn't previously been violated.

Possible Alternative Event Reversion Technique

The above procedure relies on the agent deliberately restarting the timer and removing the SLA pass which could easily be forgotten or avoided.

It might therefore be possible to agree a standard reply from the customer, in which case a trigger could look for the standard reply in the comment rather than using a macro applied by the agent.

In this case the trigger should be constructed as in the previous step, but would rather check for the presence of an agreed string in a public comment.