A clear target on every ticket.

An SLA, or service level agreement, is the response or resolution time your support team commits to. In a help desk it usually comes down to two promises: how quickly someone replies, and how quickly the ticket is resolved. Solves turns both into live timers on each ticket so the commitment is visible, not just written down somewhere.

The point of an SLA is to make a vague promise measurable. "We aim to reply quickly" is not something you can manage. "First reply within four hours, resolution within two days" is, because you can put a clock on it and see when the clock is running out. Solves attaches that clock to the ticket the moment a customer's email arrives and keeps it visible until the target is met.

How first-response and resolution timers work

Each ticket carries two independent timers. The first-response timer counts down from the moment the customer's email lands until your first public reply goes out, so it measures how long a customer waits to hear back from a human. The resolution timer runs until the ticket reaches Resolved, so it measures how long the whole problem took to put right. Both show their state on the ticket and in the queue, so nobody has to open a ticket to know whether it is on track.

Targets in minutes, per brand

Each target is a number of minutes, set per brand or for the whole organisation. When a ticket arrives, Solves works out its due time and shows it on the ticket and in the queue, so a brand that promises a fast first reply and a brand with a longer target each measure against their own figure. One workspace can run several brands with different commitments without their targets getting muddled.

See what is overdue at a glance

You do not have to open each ticket to know where it stands. The first-response and resolution timers show their state on the ticket and in the queue, and the breaching view gathers everything that is overdue or close to its target in one place. So the work that is slipping is always visible, rather than hidden among newer mail that feels more urgent than it is.

A breaching view that sorts the worst first

Knowing a target exists is not enough; you need to see what is about to miss it. Solves has a breaching view that gathers every ticket at risk and sorts the worst first, so the most overdue and soonest-to-breach tickets sit at the top. Instead of scanning a flat inbox and hoping, your team opens one list and works down it. Nothing important hides at the bottom of a long queue.

Ageing, so nothing quietly gets old

Alongside the timers, every ticket shows its ageing: how long it has been open. Ageing catches the tickets that are technically within target but have been drifting for days, and the ones that bounced between Waiting for Customer and Open without ever closing. Between SLA timers, the breaching view and ageing, the queue answers the only question that matters on a busy morning: what should I pick up next?

A vague promise is impossible to manage. "We aim to reply quickly" cannot be tracked, but "first reply within four hours, resolution within two days" can, because every ticket gets a due time and the breaching view shows you the moment work is slipping. For a small team answering email between other jobs, that is the difference between knowing where you stand and finding out only when a customer chases.

Promises you can actually keep

The honest version of dependable support, for an email-first team, is a queue that never loses a message and a target you can point to. You can tell customers a clear first-response time, work the breaching view to stay ahead of it, and prove your first-response and resolution figures from your own reports rather than guessing. That is dependable support without pretending to run a night shift you do not have.

SLAs and the rest of the queue

SLA timers do not work alone. They sit on owned tickets with a clear state (New, Open, Waiting for Customer, Snoozed, Resolved, Closed), a priority and an owner, so the breaching view and ageing draw on the same information the team already uses to triage. The reports on first response and resolution reflect what really happened, so the figures you read match the work the team actually did.