Support SLA Policy: Priorities, Targets and Clock Rules

Define priorities by customer impact, not by how loudly someone asks. Four levels are enough for most teams, each with examples that agents can match to a ticket:

• Critical: the service is down or a major function is unusable for many customers, or there's a security or data issue.
• High: an important function is broken or badly degraded, with no reasonable workaround.
• Normal: something isn't working as expected, but there's a workaround, or a single user is affected.
• Low: questions, how-to requests and feature suggestions.

Say who sets the priority at the start and who can change it. A common rule is that the customer suggests a level, the agent confirms it against the definitions, and any change is explained to the customer. Without definitions, every ticket becomes critical.

For each priority, state two things: how fast you'll first respond and how often you'll update. Add a resolution or workaround target only where you control the outcome. Response is a promise about your team's attention, and resolution depends on the problem.

Present it as a small grid, priorities down the side and the commitments across. Set the numbers from your own history, as described in first response and resolution time, and leave room between your internal goal and what you promise customers. A critical issue might carry a fast first response and regular updates until restored, while a low-priority ticket might get a next-business-day reply. Choose figures your staffing can meet at peak, and don't promise around-the-clock coverage you can't staff.

State the hours the targets apply to, with time zone and holidays, and say how out-of-hours contacts are handled. Then define the clock precisely:

1. The clock starts when the ticket is created through a supported channel.
2. It pauses when you're waiting on the customer, and resumes when they reply.
3. It measures business hours unless the priority is critical, where it may run continuously.
4. Response stops the clock when a person sends a substantive reply, not an automatic acknowledgment.
5. Reopened tickets restart the clock at the level they had when closed.

Define supported channels too. If a customer sends a request through an unmonitored channel, such as a personal message to an employee, the clock doesn't start. Say so, and tell customers where to go.

If your contract includes a service-availability commitment alongside support times, treat it as a separate section, since it measures the product and not the support team. Convert the percentage into time so everyone understands it. A 99.9 percent availability target allows about 8.76 hours of downtime in a year, and 99.99 percent allows about 52.6 minutes¹.

Then define what counts as downtime, how it's measured, what's excluded, such as scheduled maintenance, and how customers report a problem. Don't promise a target you can't measure. Any remedy for missed commitments, such as service credits, is a contract term, so have an attorney review that wording and confirm it matches your customer agreements.

Decide in advance what happens when a target is at risk or missed. Add a warning trigger at about three quarters of the response window, which alerts the assignee and the team lead. Define escalation paths: who steps in for a stuck critical ticket, and when management is told.

When you miss a target, do three things: tell the customer plainly, fix the ticket, and find the cause. Review misses weekly, looking for patterns such as a particular time of day, category or missing staffing. Report performance against the policy monthly, with the percentage of tickets meeting each target, so leadership sees the trend.

If you serve business customers in shared chat channels, adapt the policy as described in B2B support in shared chat channels, and use the help desk comparison for B2B or this support tool comparison to check that your tool can enforce the clock rules.