SLA (Service level agreement)

A usable SLA has three parts, and most arguments about SLAs are really arguments about the first one. It needs a clock definition that says when the timer starts, when it pauses, and what calendar it runs on. It needs a target, usually a first reply within some number of hours and a resolution within some larger number. And it needs a consequence, which for an internal target is "we look at why" and for a contract is often a service credit.

The clock definition is where the money is. Calendar hours and business hours give wildly different answers to the same question, and a target that pauses while you are waiting on the customer behaves nothing like one that does not. Most SLAs also tier by priority, so an outage gets a one-hour first reply while a general question gets a full business day. Write all of that down before anyone agrees to a number, because "four hours" without a clock definition is not a commitment, it is a future disagreement.

Worked example, first reply within 4 business hours, business hours 9am to 5pm Monday to Friday. A message lands at 4:30pm on Thursday. Thirty minutes of the window burn before you close for the day, leaving 3.5 hours. The clock restarts at 9am Friday, so the reply is due by 12:30pm Friday. Run the same message against a 4 calendar-hour SLA and it was due at 8:30pm Thursday, which you missed while asleep. Same words, opposite outcome.

Compliance is the percentage of tickets that met the window. Say 120 conversations came in last month and 111 got their first reply in time. That is 111 divided by 120, or 92.5 percent, against 9 misses. The useful move at that scale is not to chart the percentage, it is to open all nine and look. In a small team they are almost always one of two shapes: it arrived after hours on a Friday, or everyone assumed someone else had it. Those have different fixes, and neither fix is a dashboard.

Which is the honest advice for a team of two to ten people. You probably should not sign a contractual SLA, because at your size one person being sick is enough to breach it and the credits are real money. What you should have is a published expectation and an internal target: say on your contact page that you reply within one business day, then meet it. A promise you keep beats a faster promise you miss, and customers calibrate to the promise rather than to the clock.

When a larger customer demands an SLA as a condition of the deal, negotiate the clock before the number. Business hours in your timezone, the timer pausing while you await their reply, and a tight definition of what counts as critical will each do more for you than shaving an hour off the target. Also agree how it is measured, because if neither side can produce the number, the SLA is decorative.

AcornReply has no SLA feature, and it is worth being blunt about that. There are no due dates, no response targets, no countdown on a conversation, and no breach alerts. It also does not report first response time. What it does have is a snooze that puts a conversation back at the top of the inbox at a chosen time and notifies whoever it is assigned to, and an analytics view showing median time from first message to resolution, split between the conversations the AI handled and the ones a person did, measured as wall clock including nights and weekends rather than adjusted to business hours. If you need contractual SLA tracking, you need a help desk built for it.