Service Level Agreements (SLAs)


Service Level Agreements (SLAs) are used by organizations to manage the levels of service expected of the IT and to ensure optimal maintenance of critical business systems and services. SLAs are documents that are negotiated between the Service Provider and Customer departments, to identify expectations and clarify responsibilities.


This tab is used to create and modify Service Level Agreements that provide request management capabilities.


SLAs include the following elements:



Creating a Service Level Agreement

To create a new Service Level Agreement:

  1. Select Service >SLAs

  2. Click New
    The screen defaults to the Details tab of the SLA Editor screen.


  1. Complete the fields, including any custom fields, as required:

    SLA Editor



    The name to identify the SLA.

    Review Date

    Details are completed based on the Admin default settings but can be edited by the User. An Alert is sent based on the default days set in the Review SLA Alert field in Admin>Setup>Privileges>Requests.

    On Breach

    Notification can be set to Carbon Copy (CC) an email to the Team Leader when the Warning or Escalation alert is sent to the Technician assigned to the request. It should be noted that the Service Level Manager is also notified when an SLA is breached.

    Pause on Holiday

    **This option is only displayed if the Observe  Public Holidays option has been enabled within the Administrator>Setup>Privileges>User tab.

    Enable this option, if the SLA is to be adjusted on designated Public Holidays. The Public Holidays are defined within the Administrator>Setup>Public Holidays screen and associated with requests via the assigned Technician and their associated Country.

    Customer Timezone

    When enabled,  SLA times displayed within the Technician request view uses the Customer timezone.


    This is visible when Customer Timezone is not set and all SLA dates are calculated based on the Timezone set within this field. This is especially applicable for User Work Hours, Blackouts, which also impacts the SLA Reports.



    Used to state the time an Item under the SLA is required to be online. The default value is set to 97%.

    Interval Measured in

    Defines the number of days over which the Availability requirement is calculated.


    Process Name

    The field is displayed when Workflows have been assigned to the SLA.

    If multiple Workflows have been assigned for each Process, this field allows the User to assign a default Workflow for the SLA. When a request is created using the SLA, the default Workflow is assigned to the request.

    SLM (Service Level Manager)



    Use the Find Service Level Manager search option, to enter the contact details of the Manager who will monitor the performance of the SLA.

    This is also the  User who is assigned responsibility for managing the performance of external support providers when a request moves into a Workflow State that is supported by an Underpinning Contract .

     Internal Cost ^

    Annual Cost ^

    The SLA cost is calculated on the basis of what is costs the service organization to provide the service agreement, as applied on a yearly basis per User. The figure is associated with Items and used to calculate the cost of supplying a Service. This figure can be used as the basis for setting the Annual Price.


    The figure entered should be on a Annual Cost per User basis.

    Request Cost ^

    Indicates the cost applied on a Per Request basis. This figure can be used as a reference for setting the Incident Price.

    Hourly Cost ^

    Indicates the cost applied on an Hourly basis. This figure can be used as a reference for setting the Hourly Price.

    Customer Pricing ^

    Annual Price ^

    This is the charge applied to the SLA on a yearly basis and paid by the customer consuming the Service associated with the SLA. (It should be greater than the SLA Cost, as it would  include the cost of servicing the SLA plus a profit  margin, if relevant.) The figure is associated with Items and used to calculate the price paid by the customer for consuming a Service.

    The figure entered should be on a Annual Price per User basis.

    Request Price ^

    Indicates the price paid by the customer when the SLA is applied on a Per Request basis.

    Hourly Price ^

    Indicates the price paid by the customer when the SLA is applied on an Hourly basis.

* Denotes a mandatory field

^ Only applicable when SLA Prices are enabled in Setup>Billing


The Targets tab is used to configure the SLA's priority Response, Restoration and Resolution Times.

To modify a Priority:

  1. Select Service > SLAs

  2. Select an SLA

  3. Select the Targets tab to display the following fields:

    SLA Editor



    Common: Select Common if the SLA is to apply across Incidents, Requests, Problems and Change Management.


    Per Process: If the SLA is specific to a Process, select Per Process and choose a Process displayed in the drop-down list.


    Define if the time is to be calculated in Hours or Minutes.

    Service Time


    Urgent, High, Medium and Low.


    Initial Response

    The maximum time the Customer would wait from the point of request creation before receiving a Note update for a Technician. The Response trigger is stopped when a Note has been added to the request by the assigned Technician and an email is sent to the Customer. If the Response Time is reached, without a Note being added, the request will be escalated.

    Restoration Time

    The maximum time the Customer would wait from the time the request was created until a workaround or temporary fix has been implemented. The Restoration trigger stops by assigning the request a Workflow State that has to  the SLA Restoration option set to Yes.  By default, this Workflow State  is Open - Restored.

    Resolution Time

    The taken time from the point of request creation until it the request is moved to a Workflow State with the SLA Resolution option set to Yes.  Any of the default Workflow Exit States stop the Resolution Timer.

    Notify Override

    If the system is to override the default notification method set for a request when the Priority being edited is assigned to a request, check this option.

    Notification Type

    Set Email or SMS as the type of notification when the override action is applied to a Priority.



    Sends a reminder email to the Technician when the defined percentage of time elapses for a  Response, Restoration or Resolution target that has not been met on a request. Can be set up to 200% of the SLA. Note, Alert intervals are not cumulative.


    Sends a warning email to the Technician when the defined percentage of time elapses for a  Response, Restoration or Resolution target that has not been met on a request. Can be set up to 200% of the SLA.


    Escalates the request to a higher escalation layer when the defined percentage of time elapses for a  Response, Restoration or Resolution target that has not been met on a request. Can be set up to 200% of the SLA. It should be noted that the Service Level Manager is also notified when an SLA is breached.


    24 x 7

    Do not amend if the SLA is to apply 24 hours a day, 7 days a week.

    Normal Support

    Select if service hours are to be defined for the SLA. When checked, define the service hours by either selecting a template (Templates are configured by the Administrator in the Setup>Localization>Hours tab) or manually define the days and time by making selections within the drop-down lists.

  4. Click Edit, if not already in Edit mode


  5. Define if the SLA applies across all Processes or to a specific Process

  6. Define if the SLA is to be calculated in minutes or hours

  7. Select the Priority link to customize Milestones, Alerts and Support hours


  8. Modify the Milestone intervals for the Response Time, Restoration Time and Resolution Time, as required
    The time will be set in minutes or hours, as defined for the SLA.

  9. Milestone intervals are not cumulative
    For example, for the default Warranty SLA, the Priority of Urgent has the default Milestone times of 6, 12 and 24 hours. This means a User has 6 hours to send a response to a Customer before the Response time is breached, 12 hours from the point of request creation to meet the Restoration time, and 24 hours from the point of request creation to meet the Resolution time. It should be noted that requests may be moved to non-SLA timed States during these Milestone periods, so the 12 or 24 hours may not be consecutive hours.

  1. Check the Notify Override option, if relevant
    Set the type of notification, email or SMS, that is to be used to contact the User assigned to the request with this Priority.

  2. Create one or multiple Reminder, Warning or Escalation Alerts, if relevant
    Enter the percentage of time to elapse for an Alert to be triggered for a Milestone. Selecting Warning as the Alert will cause a warning e-mail to be sent to the request's Technician when the specified percentage of a milestone has been reached.  

    Selecting Escalation will trigger a request escalation to the next support layer of the Team. The escalation system will also fire if the SLA threshold is breached.

  3. It is recommended that reminders be sent at 50% of elapsed time and escalations at 75-80%
    These figures are advisory only. The internal processes of your organization will dictate the appropriate values. The Reminder percentage must be less than the Warning or Escalation percentages.

  4. Alerts can be set to 200% of the SLA time, which ensures notifications can be still be received against breached requests

  5. If Alerts are not customized, the application will automatically escalate the request when the Priority milestone is breached

  1. Click Save

  2. Modify other Priorities as necessary.


Configuring Support Hours

After the Priority times and Alerts of an SLA have been configured, Support Hours can be defined. These can be set to 24 hours by 7 days a week (24 X 7), or manually adjusted to reflect the support operation open hours.


Under 24 X 7 mode, if the SLA's urgent Initial Response field is set to six hours, and an urgent request that uses the SLA is created at midnight in the assigned Technician's time zone, those six hours will expire by 6:00 AM. This is the option to use if a support operation is staffed 24 hours a day.


If a support operation is not open 24 hours a day, the request timers are not required to run when Technicians are not available. For instance, if the support hours are 9:00 AM to 5:00 PM and the SLA hours reflect this, the SLA timers of the urgent request created at midnight would not start ticking until 9:00 AM the following business day and would expire at 3:00 PM.


To define the SLA support hours:

  1. Select Service > SLAs

  2. Select an SLA

  3. Click the Priority link
    This will display the Details tab with Support Hours options of 24x7 and Normal

  4. The default setting is 24 X 7, to amend the support hours select the Normal Support option


  5. Select a template from the Apply Template drop-down options or customize Weekdays manually.
    Note that the SLA timers become inactive when the support desk is closed.

  6. Click Save.



Blackouts are used as part of Change and Configuration Management to advise Users about the appropriate periods of time that an Item associated with an SLA should be scheduled to be taken off-line if an Outage is needed. Within the system, when an Outage is being scheduled (Item>Details>Outages) the Blackout period is displayed, informing the User of the best time to schedule a Planned Outage.


A Blackout Period is based on an agreement between the Customer and the Service Desk regarding set times that the Customer has no service expectations. This can also be the preferred time for Item upgrades and maintenance as they will not affect service availability.


A Blackout Period is specified within an SLA. During this time the SLA is viewed as inactive and its measuring time is stopped. OLAs that underpin a Workflow State that apply an SLA with a Blackout Period, also adopt the Blackout Period.

Specifying an SLA Blackout

To specify an SLA Blackout:

  1. Select Service >SLAs

  2. Click an SLA hyperlink

  3. Click Edit

  4. Move to the Blackouts tab

  5. Tick the Windows option


  6. Set the Interval of weekly or monthly

  7. Apply a Template or define the day and time period for the approved Blackout manually, then click inline_add.png

  8. Define the preferred Timezone
    This is required information to save the Blackout information.


  9. Click Save.


See: Item Planned Outages using Blackout Periods


To remove time-frames from the Blackout Period:

  1. Select Service >SLAs

  2. Click an SLA hyperlink

  3. Click Edit

  4. Move to the Blackouts tab

  5. Check the box next to the Day to be deleted from the Blackout


  6. Click Remove.



Workflows are associated with an SLA through the Workflows tab of the SLA Editor screen or within the Workflow itself. All SLAs assigned to the SLA are listed within this tab and Workflows can be added or removed within this tab, as required.


Assigning a Workflow

To assign a Workflow:

  1. Select Service>SLAs

  2. Click the relevant SLA link

  3. Move to the Workflows tab

  4. Click Edit

  5. Select Add
    The Available Workflow drop-down list will be displayed.


  6. Select a Workflow

  7. Click Save.


To remove a Workflow assignment, use the checkbox next to the relevant Workflow and click the Remove button.


Default Warranty SLA

The system includes a default SLA that does not include costs, called Warranty. The Warranty SLA can be used or edited as required.


Integration with Request Creation and the Billing System

The prices specified in the SLA provide the basis for fees charged for support on both a Per Request basis and on a subscription basis. The hourly rate is included for reporting purposes. Rather than an Item using an SLA, Items can be covered by maintenance contracts. A contract can cover a particular request, or exist as a subscription.


Maintenance Contracts form part of the request creation process. Requests can be entered into the system without a valid contract, but are flagged as unpaid, and are unable to be worked on until the invoice is processed. There is also a control (configured in the Billing Preferences) for the length of time an unpaid request can exist in the system.


See: Assigning an SLA to a Customer

See: Assigning an SLA to an Organizational Unit when Contracts are Disabled


Assigning a Default Workflow to an SLA

If more than one process Workflow is assigned to an SLA, it is required to select a default Workflow. This default Workflow will be the Workflow assigned to a request when the SLA assigned supports more than one Workflow.


To assign a Default Workflow:

  1. Select an SLA from the Service > SLA tab

  2. Click Edit
    Note that the system automatically assigns a default Workflow to an SLA, as Workflows are being assigned.

  3. Within the Priority Field, use the drop-down lists to update the relevant Incident, Problem, Change and Service Request default Workflows


  4. Click Save to apply the change.