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.

• ITFlow 26.08 or newer (database version 2.5.1)
• The Ticketing module enabled
• The ticket_sla.php cron script scheduled - see 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

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.

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.

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

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.

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.

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.

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 24×7.

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.

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.

A ticket that had already missed its target stays missed if no budget remains. Reopening cannot turn a recorded miss into a met - only genuinely unused time earns a clean window.

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

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.

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.

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

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.

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

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 raised through the client portal, the e-mail parser, the API and recurring tickets all get targets in the same way.

• 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