HaloITSM

HaloITSM Guides

Documentation to assist with the setup and configuration of the HaloITSM platform

Guides > Advanced SLA Settings

Advanced SLA Settings

In this lesson we will cover:

- Preventing the Priority of a Ticket Being Edited

- Extending/Delaying Response and Resolution Targets

- Justifying a Breached Target

- Override SLA Targets with Ticket Fields (Ad-hoc SLA)

- Re-setting the Respond by Target after an Event



Associated Guides:


Admin Guides:


Preventing the Priority of a Ticket Being Edited

Agents

To restrict agents being able to edit the SLA (service level agreement) and priority on a ticket you can revoke this permission on their agent profile/role.


Head to Configuration > Teams & Agents > Agents > select an agent > Permissions tab, here set 'Can Edit Advanced Ticket Details' to 'No' to prevent the agent being able to edit SLAs.


Note: This also prevents them being able to edit workflows and delete to-do items on tickets. 


Fig 1. Can Edit Advanced Ticket Details permission


This will prevent the agent being able to edit SLAs and priorities on all tickets, however this can also be restricted for specific users.

 

Users

You can prevent the priority of a ticket being edited if the user has 'Priority Escalation'. Priority escalation allows for this user to always have a set priority level on the tickets they log, typically used for important customers who require a high priority service. If you have users using this you may want to prevent agents being able to change the priority on a ticket for this customer to ensure the SLA agreement is always met.  


To set priority escalation head to the user profile > Preferences tab > Miscellaneous Settings, see setting 'VIP/Priority Escalation'.

Fig 2. VIP/Priority Escalation


Here set the numerical value for the priority you would like this user's tickets to have. This priority will be applied to all their tickets for all SLAs. 


Once set, head to Configuration > Tickets > Service Level Agreements > General Settings. Here, enable the setting 'Prevent editing of the Priority field if a User VIP escalation policy is in use'.


Fig 3. Setting to prevent editing of the priority field if a user VIP escalation policy is in use


Now on each of these users' tickets no one will be able to change the priority level on the SLA. 


Extending/Delaying Response and Resolution Targets

Under each priority level on an SLA there are some settings to delay and extend resolution and response targets.


Head to Configuration > Service Level Agreements > Service Level Agreements > select an agreement > Priorities tab > edit a priority, see the highlighted settings in Fig 4. 


Fig 4. Extend/Delay response and resolution target settings


Automatically extend the response target to the end of the working day - When enabled this will set the response target for the priority to be the end of the working day regardless of the response target hours/days set on the priority. This may result in the response target being longer than the set target time. This is used when you would like all tickets to be responded to before the end of the working day. If a ticket is logged at a time of day where the target time is longer than the hours left in the working day, the response target will extend to the end of the next working day. 


Delay starting SLA until the next working day after a particular time- When checked, should a ticket be logged after the time of day set below, the response timer will not start ticking until the beginning of the following workday. When a ticket is logged with this priority, on this SLA, after this time, the ticket will be put on SLA hold until the following day, at which point it is taken off SLA hold and the SLA time begins to count down. This can be used in cases where your work hours do not always reflect the time are working on tickets, that is you may have 9-5 working hours, but you are in meetings between 3-5 so cannot respond to tickets.


Automatically extend the resolution target to the end of the working day - When enabled this will set the resolution target for the priority to be the end of the working day regardless of the resolution target hours/days set on the priority. This is used when you would like agents to always have until the end of the working day to resolve tickets with this priority. If a ticket is logged at a time of day where the target resolution time is longer than the hours left in the working day, the resolution target will extend to the end of the next working day. 


Delay starting SLA until the next working day after a particular time - When checked, should a ticket be logged after the time of day set below, the resolution timer will not start ticking until the beginning of the following workday. When a ticket is logged with this priority, on this SLA, after this time, the ticket will be put on SLA hold until the following day, at which point it is taken off SLA hold and the SLA time begins to count down. This is useful for when you would like to extend the resolution target for tickets that are logged late in a working day.


Justifying a Breached Target

If you would like to have agents provide a reason when they have breached a response/resolution target, this can be set on each priority level on an SLA. Head to Configuration > Service Level Agreements > Service Level Agreements > select an agreement > Priorities tab > edit a priority.


Here you have the settings 'Prompt for a reason to be entered if the resolution/response target is breached'. 


Fig 5. Settings to have an agent justify a breached target


When enabled, if a resolution target on a ticket has been breached a text box will appear when the agent does respond to the ticket. Here they will be prompted to provide a justification for the breach. Similarly when resolving a ticket that is past the resolution SLA they will be asked for a justification. 


Fig 6. SLA breach justification prompt


The 'SLA Excuses' agents provide can be viewed and analysed using the reporting suite. This can be used to create a weekly report on agents who have breach SLA and their justifications. 


Note: If you report on SLA breaches, tickets with justifications will show as excluded from resolution SLA in the report instead of breaching.


Override SLA Targets with Ticket Fields

This is used in cases where you would like to choose the SLA targets for a ticket manually, creating an ad-hoc SLA. 


To set this up you will need to enable the override on the SLA priority. Head to Configuration > Service Level Agreements > Service Level Agreements > select an agreement > Priorities > edit a priority. Here you have the settings highlighted in Fig 7. 


Fig 7. Settings to override SLA targets with start date/target date fields 


Override fix by date with Start Date when Start Date is set - Allows you to override the resolution target using the 'start date and time' field on a ticket (this will not work using just the 'start date' field). 


Override fix by date with Target Date when Target Date is set - Allows you to override the resolution target using the 'target date and time' field on a ticket (this will not work using just the 'target date' field).


Note: You will only need one of these two settings enabled, depending on which field you would like to use. 


Once enabled ensure the ticket type you are using/would like to apply this to, has the 'Target date and time' or 'Start date and time' field enabled. Head to Configuration > Tickets > Ticket Types > select the ticket type > Field List tab, add the field in here and save.

 

Fig 8. Target Date and Time field added to ticket


Once added, the field will appear against the ticket type and when populated the resolution target will change to be this date, as shown in Fig 9. 


Fig 9. Using target date and time field to override resolution target


When you enable this functionality this will apply to all new tickets that are logged with this SLA and priority. If you would like it to apply to existing tickets, you will need to re-set the SLA by changing the SLA that is on the ticket and then setting it back. This will not re-set the timer. 


Re-setting the Respond by Target after an Event

By default the 'respond by' target on an SLA is met after the first response to a user, follow up responses do not have 'response' targets. However, SLAs can be configured so that each time the user responds to the ticket the respond by target is re-set and the agent must meet this again. 


To do this head to Configuration > Service Level Agreements > Service Level Agreements > select an agreement > Details tab, see the setting highlighted in Fig 10. 





Fig 10. Reset the Respond-By target each time an End-User updates a Ticket setting


When enabled, this setting will re-set the respond by target each time a 'user update' comes in to the ticket. A user update is classified as any update from the user, that could be the end user sending an email to the ticket, or updating the ticket through the portal.


For example, if the ticket has a 1 hour response target, when the ticket is logged the agent will have one hour to reply to the user. Once the agent has replied the user may send another email update, at which point the response target will re-set and the agent will have an hour to respond to the user. This ensure end users always receive a prompt response to their queries on tickets, rather than just receiving a prompt response after they first log the ticket. 


You will see an additional setting in Fig 10, 'Reset the Respond-By target when an Approval Process is completed'. This will start the response timer when the ticket is logged as usual and the response target will be met once the agent had responded to the user. If the user sends more updates into the ticket the response target will not re-set. However, if the ticket is submitted for approval, once the approval process is complete (i.e. the approval is accepted/rejected) the response target will re-set and the agent will have a set time to update the user that their request has been approved. This is useful during approval processes as it ensure the user remains updated on their approval as soon as it is complete. 


Note: If you are reporting on response targets (hit/missed target) the target that will be reported on will be the most recent target on the ticket. 


Popular Guides

Pin It on Pinterest