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

Sub Banner

Depending upon the complexity and scope of your Customer Support process there might be a need to capture the completion of an event for which there isn't a naturally occurring event in Zendesk to indicate if and when the SLA pass criteria event has been met.

Examples of this type of event might be the need for a workaround until a full resolution or fix can be provided, or the need for an initial triage or diagnostic.

These types of event are measured from the point at which the ticket was submitted or created, but in the absence of a naturally occurring event in Zendesk there is a need for an alternative mechanism to identify the criteria under which the timer should be stopped and the SLA can be marked as passed.

This can be achieved as outlined in the following steps:

*Note: Please see also Implementing Support for a Manually Starting Custom Metric or Event (e.g. On-site Engineer, RMA, Vendor Response) if there is a need to measure from a point some time after the ticket is created.

Configure your Model options to include Custom Events

Configure your Model options to include Custom Events

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 model 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.

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 Support for an Auto Starting Custom Metric or Event (e.g. Workaround, Triage, Diagnostic)

Sub Banner

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

Depending upon the complexity and scope of your Customer Support process there might be a need to capture the completion of an event for which there isn't a naturally occurring event in Zendesk to indicate if and when the SLA pass criteria event has been met.

Examples of this type of event might be the need for a workaround until a full resolution or fix can be provided, or the need for an initial triage or diagnostic.

These types of event are measured from the point at which the ticket was submitted or created, but in the absence of a naturally occurring event in Zendesk there is a need for an alternative mechanism to identify the criteria under which the timer should be stopped and the SLA can be marked as passed.

This can be achieved as outlined in the following steps:

*Note: Please see also Implementing Support for a Manually Starting Custom Metric or Event (e.g. On-site Engineer, RMA, Vendor Response) if there is a need to measure from a point some time after the ticket is created.

Configure your Model options to include Custom Events

Configure your Model options to include Custom Events

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 model 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.

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 Support for an Auto Starting Custom Metric or Event (e.g. Workaround, Triage, Diagnostic)

Sub Banner

Depending upon the complexity and scope of your Customer Support process there might be a need to capture the completion of an event for which there isn't a naturally occurring event in Zendesk to indicate if and when the SLA pass criteria event has been met.

Examples of this type of event might be the need for a workaround until a full resolution or fix can be provided, or the need for an initial triage or diagnostic.

These types of event are measured from the point at which the ticket was submitted or created, but in the absence of a naturally occurring event in Zendesk there is a need for an alternative mechanism to identify the criteria under which the timer should be stopped and the SLA can be marked as passed.

This can be achieved as outlined in the following steps:

*Note: Please see also Implementing Support for a Manually Starting Custom Metric or Event (e.g. On-site Engineer, RMA, Vendor Response) if there is a need to measure from a point some time after the ticket is created.

Configure your Model options to include Custom Events

Configure your Model options to include Custom Events

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 model 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.

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 Support for an Auto Starting Custom Metric or Event (e.g. Workaround, Triage, Diagnostic)

Sub Banner

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

Depending upon the complexity and scope of your Customer Support process there might be a need to capture the completion of an event for which there isn't a naturally occurring event in Zendesk to indicate if and when the SLA pass criteria event has been met.

Examples of this type of event might be the need for a workaround until a full resolution or fix can be provided, or the need for an initial triage or diagnostic.

These types of event are measured from the point at which the ticket was submitted or created, but in the absence of a naturally occurring event in Zendesk there is a need for an alternative mechanism to identify the criteria under which the timer should be stopped and the SLA can be marked as passed.

This can be achieved as outlined in the following steps:

*Note: Please see also Implementing Support for a Manually Starting Custom Metric or Event (e.g. On-site Engineer, RMA, Vendor Response) if there is a need to measure from a point some time after the ticket is created.

Configure your Model options to include Custom Events

Configure your Model options to include Custom Events

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 model 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.

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.