The standard criteria to determine if and when an Initial Response or subsequent Update has been provided to the customer is the presence of a public comment made on the ticket by the agent.
However, depending upon the way in which your Customer Support process operates and how you communicate with your customers there might be a need to implement alternative rules to determine when an initial response or update has been given, and so avoid an SLA violation without the need to apply a public comment.
The CloudSET SLA Management extension framework provides enablers that allow for the specification of custom rules for this purpose and the following steps describes how to achieve this type of custom behavior.
Configure your Model Options to support Respond or Update by Phone or Proxy
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.
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.
*Note: depending upon the model in use as part of your setup the labels for these options might differ slightly.
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 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.
Apply a standard Private Comment using a Macro to determine the Pass Criteria
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
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.
*Note: the above example shows the action necessary to indicate an initial response, but if indicating an update it will be necessary to check the box for the field named SLA3 Update Phone.
Apply Trigger based rules to determine the Pass Criteria (e.g. Ticket created by and Agent)
A Ticket Created by an Agent represents an Initial Response
It is often the case that a ticket is created by an agent on behalf of the customer following a phone call or a message received via an external service unknown to Zendesk.
Under these circumstances the initial response to the customer request or issue will have been given during the phone call or communication thread and the ticket description will include a record of the response.
Since the initial response has already been given the need for a subsequent public comment to stop the clock and pass the response SLA can be avoided using a trigger such as that shown in the screenshot above.
Implementing additional Custom Rules
Depending upon the way in which your Customer Support process operates and how you communicate with your customers, there might also be a requirement to implement support for additional custom rules and conditions that determine when an initial response or update has been given.
These rules can be implemented using a trigger to check the appropriate box (SLA3 Respond Phone or SLA3 Update Phone).
Please also see the article named Ignoring Public Comments for an Initial Response or Update.