Most SLA documentation reads like a configuration manual: here are the settings, here are the buttons, here are the database tables. Useful if you already know what you're trying to do. Not very useful if you're staring at a fresh install wondering what would a sensible setup even look like for us?
So this piece does the opposite. Four fictional service delivery managers, four very different organisations, walking through how each of them would actually configure FreeITSM. None of them are right or wrong — they're four different shapes of "fair" depending on what their team looks like.
The four building blocks they're working with are the same in every case:
- Business calendars — when the desk is open, in which timezone, with which holidays.
- Priorities with targets — how long each band gets for response and resolution.
- Pause-SLA statuses — which ticket states stop the clock.
- Breach notifications — who gets emailed when something approaches breach or actually breaches.
That's it. Everything else is a knob that takes a sensible default if you don't touch it. The interesting bit is how four people read the same set of options and arrive at four genuinely different setups.
Sarah runs the IT service desk at a UK midsize logistics firm. Single head office in Birmingham, three depots, all customers UK businesses, twelve analysts on the desk Monday to Friday, 09:00 to 17:00. The team's been informally meeting SLAs for years — everyone basically knew the targets — but now Sarah wants them tracked so she can report compliance to the board without spending Sunday evening building a spreadsheet.
What makes Sarah's setup straightforward
One office, one timezone, one calendar. All her customers are in the same country. Nobody is asking for 24/7 or weekend cover. There is no offshore team. This is the textbook simple case, and FreeITSM's defaults will get her most of the way there.
How Sarah configures FreeITSM
Europe/London, Mon-Fri 09:00–17:00, with the eight UK bank holidays for the year added as holidays.What happens when a P2 lands at 16:30 on a Friday
If the analyst hadn't replied by 09:30 Monday, the response would have breached. Sarah's analysts learn quickly that an end-of-day Friday ticket eats most of its budget overnight — by the time they sit down on Monday morning, they don't have a full hour, they have whatever's left from Friday evening's accumulation.
Marcus runs customer operations at an Edinburgh SaaS company. Eighty staff, six on the support desk, customers across the UK and Western Europe. Two tiers of customer: Standard on a monthly plan with best-efforts response, and Enterprise on annual contracts with contractually-binding SLAs. His SaaS integrates with Stripe, Auth0, and AWS — all of which can have outages that Marcus's team can't do anything about.
What makes Marcus's setup more interesting
Three things. He needs different SLA targets for different customers, because his Enterprise contracts are tighter than his Standard ones. He needs a vendor-pause story for the days when Stripe goes down and his team is sitting on tickets they genuinely can't progress. And he needs different escalation paths — an Enterprise breach should wake somebody up; a Standard breach is a polite "we'll get to it" email.
How Marcus configures FreeITSM
Europe/London, Mon-Fri 08:00–18:00 (slightly extended to cover early European morning + late UK afternoon), with English and Scottish bank holidays.What happens when Stripe goes down during a P2
Without the vendor pause, this ticket would have consumed three and a half hours of wall-clock time it had no control over. With it, the SLA reflects what Marcus's team can actually be held to. When he reports compliance to the Enterprise customer in their quarterly review, he can show the audit log: clock started, paused at Awaiting Vendor, resumed at In Progress, met. The customer sees the story, not just the number.
Anna runs the global IT service desk at a shipping company with vessels at sea around the clock. Her support team is split across three offices to provide follow-the-sun coverage: Stockholm picks up at 06:00 UTC, hands over to Singapore at 14:00 UTC, who hand to Houston at 22:00 UTC, who hand back to Stockholm at 06:00 UTC the next morning. There is no "office closed". The clock never stops.
What makes Anna's setup unusual
Her organisation operates 24/7, so the entire concept of "business hours" goes out the window. A P1 raised at 03:00 UTC matters exactly as much as one raised at 14:00 UTC — somebody, somewhere, is at a desk to deal with it. Her SLA clock should never pause for "office closed" reasons; it should only pause when there's a genuine block (awaiting the vessel master to respond, awaiting a parts shipment).
How Anna configures FreeITSM
UTC (a neutral choice that avoids favouring any region), with every weekday checkbox ticked and hours set to 00:00–23:59. No holidays — even Christmas Day, the ships are still sailing.What happens on a follow-the-sun handover
The interesting thing in Anna's setup is that no analyst notices the handover from the SLA's perspective. The clock keeps ticking through the Stockholm-to-Singapore handoff at 14:00 UTC because there's no "office closed" moment to pause for. The ticket just moves between assignees as the day rotates. Anna's job is to make sure the per-region notification rules mean nothing falls in a gap — a ticket assigned to a Stockholm analyst who's just gone off-shift will still trigger a breach email to the Singapore lead.
David is the entire IT team at a UK charity that provides classroom technology to 200 partner schools. Three people total: David, one full-timer, one part-timer Tuesday and Thursday. Their customers are teachers and school office staff, so support demand follows the academic calendar — flat during term, near-zero during the holidays. They run on a shoestring budget and their server is an Intel NUC in the cupboard.
What makes David's setup pragmatic
He doesn't need fancy. He needs sensible defaults that match the reality of his three-person team and his teacher customer base. Aggressive SLAs would just stress everyone out for no good reason — if a teacher emails on Friday afternoon, they don't expect Saturday-morning support, and David's team would burn out fast if they tried to provide it. He also has the wrinkle that his desk effectively closes during school holidays, which complicates the calendar.
How David configures FreeITSM
Europe/London, Mon-Fri 08:00–16:00 (matches school hours). The holidays list contains every UK school holiday day for the academic year — half-terms, two weeks at Christmas, two weeks at Easter, six weeks of summer, three INSET days. About 75 entries total, added once a year in August.What happens when a P2 lands during half-term
This is the thing that David's setup gets right that a simpler config wouldn't. Because the school-holiday days are entered as calendar holidays, the SLA engine treats them as "closed" and the clock simply doesn't tick. A teacher who emails during half-term gets a response when school resumes — and the SLA report shows compliance, because the target was met against the actual working calendar. Nobody is unfairly held to a target that doesn't match the contractual reality.
The common thread
None of these four setups are doing anything that the others couldn't — they're all just dialling the same building blocks to different values. Sarah uses one calendar with bank holidays. Anna uses one calendar with no holidays at all. David uses one calendar with 75 holiday entries. None of them is more "correct" — they're each correct for their team.
Some patterns worth noticing across the four:
- Almost everyone uses one calendar. Multiple calendars get useful when you have meaningfully different working windows for different priorities (a VIP calendar with extended hours, for example), but most teams don't need them.
- Everyone has a pause-SLA story. What the pause statuses are called varies wildly — Awaiting Vessel, Awaiting Teacher Response, Awaiting Vendor — but the principle is the same: when the ticket is genuinely blocked on something outside the team's control, the clock should stop.
- Three of the four deliberately don't have a generic "On Hold". Sarah and David both replaced it with specific blocked-on-what statuses, and Anna doesn't have one at all. The reason is the same in each case — generic On Hold tends to get used as an SLA escape valve, and specific statuses force a real reason.
- Notification complexity scales with team size, not company size. Anna has six notification rules because she has six routing combinations (3 regions × warning/breach). David has one rule because he has one routing combination (everything goes to everyone).
- The enforcement cutoff is everyone's friend. All four would use it the same way — set it to "now" when they first turn SLAs on, so existing tickets aren't retroactively breached overnight.
Configure for how your team actually works, not how you wish they worked.
Sarah's setup is probably about ninety minutes of work to stand up. Marcus's is closer to half a day, because of the tier split and the four notification rules. Anna's took longer — not because of the SLA module, but because she had to think through the on-call routing properly before she could express it as rules. David's was the simplest of all and was done in an afternoon, dates and all.
None of them needed a developer. None of them needed the source code. None of them needed to file a feature request. The SLA module gives them the building blocks; the configuration is theirs.
For the full reference on each setting, see the in-app SLA Management help page (linked prominently from the Tickets help guide once you're inside FreeITSM). For setup instructions on the cron worker, the docs/sla-cron-setup.md file in the install directory has Windows Task Scheduler and Linux cron walkthroughs.