Installation @rocket.svg

You've loaded an old revision of the document! If you save it, you will create a new version with this data.

====== SLAs ======

Service Level Agreements (SLAs) put response and resolution targets on tickets, warn you before a target is missed, and record whether each target was met.

SLAs are entirely optional. Until you assign one, nothing about ticketing changes - no targets are set, no colours appear and no notifications are sent. You can also switch them off for a single client, a single priority, or a single ticket.

===== Requirements =====

* ITFlow 26.08 or newer (database version 2.5.1)
  * The Ticketing module enabled
  * The ''ticket_sla.php'' cron script scheduled - see [[cron|Cron]]. Without it, targets are still calculated and displayed, but you get no warnings, no breach alerts and no row colouring
  * ''mail_queue.php'' running, if you want SLA alerts by e-mail as well as in-app

===== Concepts =====

An **SLA plan** is a named pair of targets, for example //Gold// with a 30 minute response and 240 minute resolution. Plans are reusable.

An **assignment** connects a plan to a priority. Assignments exist at two levels:

* **Global defaults** - apply to every client, set in **Admin** > **SLAs**
  * **Client overrides** - apply to one client, set on that client

When a ticket is created, ITFlow looks for an assignment matching the ticket's client and priority. A client override wins if one exists, otherwise the global default applies. If neither exists, the ticket simply has no SLA.

Targets are calculated once, when the ticket is created, and stored on the ticket. They are counted in **business minutes**, so only time inside your configured business hours is consumed.

===== Setting up =====

==== Step 1 - Create your SLA plans ====

Navigate to **Admin** > **SLAs** and select **New SLA**.

Most MSPs need two or three plans. A common starting point:

* //Priority// - 30 minute response, 240 minute resolution
  * //Standard// - 120 minute response, 480 minute resolution
  * //Best effort// - 480 minute response, no resolution target

Plans can be **archived** later rather than deleted, which preserves the history on tickets that used them.

==== Step 2 - Set your business hours ====

On the same page, fill in **Business Hours & Notifications**.

^ Setting ^ Notes ^
| Business days | Days the SLA clock runs. Defaults to Monday-Friday. Unchecking every day makes SLAs count 24x7 |
| Business hours start / end | Defaults to 09:00 and 17:00 |
| Warn at % of target | How far through a target a warning fires. Defaults to 75, meaning a 60 minute response target warns at 45 minutes |
| Notification email | Optional address that receives every SLA alert, e.g. a dispatch or helpdesk distribution list |

These settings apply to the whole install and use your ITFlow timezone.

Changing business hours recalculates targets on all open tickets that have an SLA, because the underlying maths has changed. The number of tickets updated is shown after saving.

==== Step 3 - Assign global defaults ====

Under **SLA Assignments**, choose a plan for each priority - **Low**, **Medium**, **High** and **Urgent** - then select **Save Defaults**.

Leave a priority set to **None** if it should not carry an SLA at all. Many MSPs set None for Low so that long-running, low-urgency work is never counted as breached.

Saving defaults re-evaluates every open ticket against the new assignments.

==== Step 4 - Add client overrides where needed ====

Client overrides live on the client, not in the admin area. Edit a client, open the **Notes** tab and use the **Ticket SLAs** selectors.

Each priority offers three choices:

* **Default** - follow the global default for that priority
  * **None** - this client gets no SLA at that priority, even if a global default exists
  * A named plan - this client uses that plan at that priority

The same selectors appear when creating a client. They are only shown once at least one active SLA plan exists.

Saving a change re-evaluates that client's open tickets. Saving a client with the SLA selectors untouched changes nothing.

===== How targets are calculated =====

Targets count business minutes from the moment the ticket was created. Time outside business hours does not count.

With business hours of 09:00-17:00 Monday to Friday and a 60 minute response target:

If no usable business calendar is configured - no days selected, no hours set, or an end time earlier than the start - the clock runs 24x7.

===== The two clocks =====

==== Response ====

Starts when the ticket is created and stops at the first response. A first response is recorded by:

* A **public** reply to the ticket
  * Resolving the ticket, if no reply was made first
  * Merging the ticket

Internal notes do //not// count as a response. This applies to bulk replies as well as single replies.

==== Resolution ====

Starts when the ticket is created and stops when the ticket is resolved, or closed without being resolved. It can also be paused - see below.

Reopening a resolved ticket puts it back on the resolution clock with whatever budget was left when it was resolved. A ticket resolved after two hours of an eight hour target comes back with six hours, not with its original deadline.

===== Pausing the resolution clock =====

Time spent waiting on someone else does not have to count against a resolution target. Any ticket status can be set to pause the clock.

Navigate to **Admin** > **Ticket Statuses**, edit a status, and set **SLA** to **Pause the resolution clock**. Statuses that pause are marked //Paused// in the SLA column on that page. Nothing pauses by default, so this is entirely opt-in.

A typical setup is to pause on statuses like //Waiting on client//, //Waiting on vendor// or //Scheduled//, and leave //Open// and //In progress// running.

While a ticket sits in a paused status:

* Its resolution clock stops, and the time already spent is kept
  * It cannot warn or breach on resolution, so it is never coloured on the ticket list or kanban board
  * The ticket shows //Paused// in place of its resolve-by date

When it moves back to a running status the clock restarts and the resolve-by date moves out by whatever budget is left. A ticket that had used six hours of an eight hour target comes back with two hours, whether it was paused for an afternoon or a fortnight.

Two things worth knowing:

* The **response clock is never paused**. A ticket that has not been replied to yet will still breach its response target, on the grounds that nobody can be waiting on the client before anyone has answered them
  * Pausing only applies to statuses. Closing, resolving and archiving stop the clock regardless

===== Reporting =====

Two reports live under **Reports** > **Technical**, and both need read access to the support module.

* **SLA Summary** - overall response and resolution compliance for a year, broken down by priority and by month
  * **SLA by Client** - the same figures per client, with average time to respond and average time to resolve. Useful for a QBR pack

Percentages count only tickets whose targets have been judged. A ticket still awaiting a response is neither a hit nor a miss and is left out until its outcome is known, so the figures do not swing about as open work ages.

Tickets raised before you assigned any SLA carry no SLA at all and never appear in these reports. Compliance figures therefore start from the day you set SLAs up, not from the beginning of your ticket history.

On **SLA by Client**, time to respond is wall-clock from when the ticket was raised, while time to resolve counts only business hours with the clock actually running - paused spells are excluded, matching what the SLA itself judged on.

===== Day to day use =====

==== On a ticket ====

The ticket view shows the SLA name alongside the priority, and the two target dates under the ticket details. A green tick means the target was met, a red warning triangle means it was missed.

Selecting the SLA name opens a modal where you can pin the ticket to a different plan, or to **None** to remove its targets entirely. This needs support module write access, and is unavailable once the ticket is closed. Changing the SLA recalculates both targets from the ticket's creation time.

==== On the ticket list ====

* **Yellow** - a target is approaching, at the warning percentage you configured
  * **Red** - a target has been missed

Closed tickets are never coloured, and neither are paused ones - though a breach recorded before a ticket was paused still stands.

The **SLA state** filter narrows the list to tickets that are breached, at risk, paused, met, or have no SLA at all. It only appears once you have at least one active SLA plan.

Kanban cards carry the same states: a coloured border plus a stopwatch badge, amber when a target is approaching and red when one has been missed.

==== Notifications ====

Once the cron script is scheduled, each ticket generates at most one warning and one breach alert per clock. Alerts are sent in-app and by e-mail to the SLA notification address and the assigned agent - if these are the same person, only one e-mail is sent.

===== Behaviour worth knowing =====

==== Priority and client changes recalculate targets ====

Changing a ticket's priority or client re-runs the assignment lookup and recalculates both targets **from the ticket's creation time**. This also clears a per-ticket SLA you pinned manually.

This matters for a common pattern: an outage raised as Urgent, then downgraded to Low and left open for a week of monitoring. After the downgrade, the resolution target is measured from the budget already spent, so it may be missed almost immediately. Options, best first:

* Move the ticket to a status that pauses the clock while it is only being monitored - this is what pausing is for
  * Resolve the outage ticket when the outage ends and monitor on a separate ticket, which gives the most accurate reporting
  * Downgrade the priority //first//, then pin the ticket's SLA to **None** - order matters, because changing priority afterwards clears the pin
  * Assign **None** to Low, so downgrading to Low drops the SLA automatically

==== Editing plans and settings restamps open tickets ====

Editing a plan's targets recalculates open tickets using that plan. Changing business hours recalculates all open tickets with an SLA. Closed and archived tickets are never touched.

==== Archived plans ====

Archiving a plan leaves existing tickets with the targets they already have, but any assignment pointing at it stops applying, so new tickets get no SLA. Restore the plan to undo this.

==== Tickets created outside the agent interface ====

Tickets raised through the client portal, the e-mail parser, the API and recurring tickets all get targets in the same way.

===== Troubleshooting =====

^ Symptom ^ Likely cause ^
| No colours, warnings or breach alerts | ''ticket_sla.php'' is not scheduled |
| In-app alerts appear but no e-mail | ''mail_queue.php'' is not running, or the notification address is empty and the ticket has no assigned agent |
| Tickets have no SLA at all | No assignment matches their client and priority, or the assigned plan is archived |
| Targets look hours out | Business hours, business days or the ITFlow timezone are set incorrectly |
| A ticket shows a red missed response but you replied quickly | The reply was an internal note - only public replies count |
| Targets moved unexpectedly | Someone changed the ticket's priority or client, edited the plan, or changed business hours |
| A ticket shows Paused but you expected a countdown | Its status is set to pause the resolution clock, under Admin > Ticket Statuses |
| A resolved ticket shows no met or missed verdict | It was resolved before 26.08 through the kanban board or the client portal, where the verdict was not being recorded |
| Reports show fewer tickets than you expected | Only tickets carrying an SLA are counted, so anything raised before you set SLAs up is excluded |

===== Current limitations =====

* The response clock cannot be paused - only the resolution clock can
  * Changing a ticket's priority or client clears an SLA that was pinned to that ticket by hand
  * Logged clock time keeps the business hours that were in force when it was recorded, so changing business hours does not rewrite history

Please type our project name in the box to prove you're human (it***w): Please keep this field empty:

Edit summary

Note: By editing this page you agree to license your content under the following license: CC Attribution-Share Alike 4.0 International

Tools

menus and quick search

quick search

site status

location indicator

Page Tools

meta data for this page