🎧 Support desk & SLA

Your customers write in and a ticket is created. What turns that into a service you can stand behind is the SLA layer: for each priority you promise a first response time and a resolution time, TSync works out the deadline for every ticket, warns you before it's missed, and shows you how you're doing.

Nothing here changes how tickets themselves work — it adds the clock, the warning and the score.

The support dashboard

Support dashboard in the sidebar (/admin/tsync_support_dashboard) is the board a support lead opens in the morning:

Tile What it tells you
Open tickets How much is on the desk right now.
First-response breaches Open tickets that missed the promised first reply.
Resolution breaches Open tickets past their resolution deadline.
SLA compliance Of the tickets you resolved, the share resolved within the promise — with a bar, so a slipping month is visible at a glance.
Avg first response How long, on average, a customer waits for the first human reply.
Open by priority Where the load sits — urgent vs low.
Recent tickets The latest tickets with their status, so you can jump straight in.

If your install hasn't run the database upgrade that adds the SLA fields yet, the board says so plainly instead of showing empty numbers.

Set your promises (administrators)

Setup → Support → SLA (/admin/tsync_ticket_sla) is where the promise is written. It's admin-only.

Per priority

For each priority that exists in your install you set two numbers, in minutes:

  • First response — how quickly someone must reply for the first time.
  • Resolution — how quickly the ticket must be closed.

Leave a number at 0 and that leg simply isn't tracked for that priority. The list of priorities comes from the priorities you actually use, so a three-priority desk sees three rows — no invented tier that nobody can select on a ticket.

The working calendar

Deadlines are counted in working time, not wall-clock time, so a ticket that arrives on Friday evening isn't "late" by Monday morning:

  • Business hours — a start and an end time.
  • Working days — tick the days you actually work.
  • Round the clock — tick this if you support 24/7; the business hours and working days are then ignored.

Two more settings

  • Warning threshold (%) — how far into the allowed time counts as approaching. At 80 %, a 5-hour promise starts warning after 4 hours.
  • Closed statuses — which ticket statuses mean "this is done". A ticket in one of these no longer counts as open and stops accruing SLA time.

What happens on a ticket

  1. A ticket is created → TSync computes its first-response and resolution deadlines from the priority's policy and your working calendar.
  2. The first staff reply → the first-response clock stops, stamped on the ticket.
  3. The ticket is closed (a status you marked as closed) → the resolution clock stops.
  4. In between, a regular sweep (it rides on your cron job) checks the open tickets and flags each one as approaching or breached — once, not repeatedly.

On the tickets list the subject carries a small SLA dot: fine, approaching, or breached — so you can see where the pressure is without opening anything. Hover it for the detail.

In automations: SLA warning and SLA breached are ordinary system events, so TSync Automations can act on them — notify the team lead, escalate the ticket, post to a channel. Nothing is escalated behind your back; you decide what happens.

Practical advice

  • Start loose, then tighten. Put in the times you can actually meet today, watch the compliance tile for a month, then shorten them. A promise nobody meets teaches the team to ignore the dot.
  • Only track what you'll act on. If you never measure resolution time for low-priority tickets, leave that number at 0 rather than carrying a breach you don't care about.
  • Check the calendar first when something looks wrong. A "breach" that makes no sense is nearly always a working calendar that says you work Saturdays (or 24/7) when you don't.

Where to go next