SLA Tracking for Small Teams: A No-Fluff Setup Guide

A shared Gmail inbox works until it does not. Usually that moment arrives somewhere around 50-80 tickets a week, when two people have replied to the same customer, three tickets have gone dark for four days, and nobody can agree on what counts as urgent. SLA tracking sounds like an enterprise thing. It is not. It is just writing down what good looks like before things get bad.

Why this matters when your team is still small

Most teams I have talked to hit the same wall. Below 20 tickets a week, a shared inbox with labels is fine. Above 50, it starts breaking. The symptoms are always the same: the squeaky wheel wins, meaning whoever emails again gets answered first. Quiet customers with real problems get buried. And because there is no explicit priority, every ticket feels equally urgent, so the team is constantly triaging in their heads instead of just working.

SLAs are not a compliance exercise. They are a promise to yourself about what good looks like. First response under four hours. Resolution under 48 hours for standard issues. Written down somewhere. That is it. Two to five people handling support is exactly the stage where building this habit now saves you from retrofitting it later when volume doubles and you are scrambling.

If you want to see how this fits into the bigger picture of keeping support costs manageable at this stage, the post at /blog/cost-of-support-rep-vs-ai is worth reading alongside this one. A single CX rep costs $3-4K a month all-in. Getting your ticket workflow right before you hire is worth the hour it takes.

The two SLA numbers you actually need to define first

First response time and resolution time. They sound similar. They are not. First response is a promise that a human saw the ticket and acknowledged it. Resolution is a promise that the problem is closed. Conflating them is one of the most common mistakes small teams make.

A customer who emails about a billing error and gets a reply within two hours saying 'we see this, we are looking into it' is in a very different emotional state than a customer who hears nothing for 24 hours. First response buys goodwill. Resolution closes the loop. You need targets for both.

Realistic starting benchmarks for a team of two to five: first response under four hours during business hours, resolution under 48 hours for standard issues. Do not copy enterprise SLA tables with six tiers. You will never maintain them with three people. Start simple and tighten after 30 days.

How to define priority levels without an ops person

Four priority levels is one too many when you are small. Start with three: urgent, normal, low. The goal is that any team member can triage a new ticket in under 30 seconds without asking anyone.

Urgent means the customer cannot do something revenue-blocking right now. Account access lost. Billing error. Outage-related. Something that, if you ignore it for four hours, you might lose the customer or the deal.

Normal is everything else that needs a real answer. Feature questions. How-to requests. General complaints. The bulk of your volume will land here.

Low is feedback, feature requests, and nice-to-have clarifications. Real tickets, but nobody is blocked. They can wait a day or two without consequences.

Mapping priority to SLA targets

Once you have three priority levels, you need a target for each. Here is a starting point:

These are starting numbers. Adjust after 30 days based on what you can actually hit. A missed SLA you are tracking is better than a perfect SLA you ignore. If you are missing more than 20% of your urgent targets in the first month, either the targets are too aggressive or too many tickets are being tagged urgent. Both are fixable.

Do not set SLAs to impress yourself. Set them to reflect what good actually looks like for your customers and your team size.

The mechanics: how to actually track this without a spreadsheet

A color-coded spreadsheet works for about two weeks. Then someone forgets to update it, the formatting drifts, and you are back to guessing. What you actually need is a system that tells you when a ticket is about to breach before it breaches, not after.

The minimum viable setup has four things: priority levels you can set on a ticket, assignment to a specific person, internal notes for handoff context, and overdue alerts that fire before the SLA window closes.

Trigli's built-in ticketing handles all four. You can set priority (high, medium, low), assign tickets to specific team members, leave internal notes that the customer never sees, and get overdue alerts before SLA breach. It also converts incoming emails and chat conversations into tickets automatically, so nothing falls into a void. You do not need a separate ticketing tool on top of your email tool. See the full feature breakdown at /use-cases/small-business.

The internal notes piece matters more than people expect. If you are handing a ticket to a teammate without writing a note, you are creating a Slack thread that will disappear. The note lives on the ticket. The context travels with the work.

Setting up your first automation rules to route by priority

Once your priority definitions exist, you can start automating the routing. The idea is simple: billing complaints should never sit in a general queue waiting for someone to notice them. Feature requests should not clog the urgent pile.

Trigli's automation rules work on categories. You define a category (billing, feature request, general how-to, feedback), then assign one of four actions: auto-send a reply, draft a reply for review, flag for human review, or skip. You can stack rules with priority ordering so more specific rules fire first.

For a small team just starting out, I would set it up like this: billing and access issues go to human review immediately, no auto-send. General how-to questions get a draft reply pulled from your docs, which a human approves before it sends. Feature requests and feedback get drafted and queued for a low-priority batch review. Start in draft mode for everything until you trust the categories. The /blog/automate-customer-support-without-losing-human-touch post goes deeper on where to draw the automation line.

Avoiding the three most common ways tickets fall through the cracks

First: no owner. A ticket sitting in a queue with no assignment is nobody's problem. Fix this with a default assignee rule. Someone owns every ticket the moment it comes in. Reassignment is fine. Unowned is not.

Second: replied but not resolved. The customer got an answer, the agent moved on, and the ticket was never closed. Now it sits in an ambiguous state. Fix this with a resolved status gate - the ticket does not close until someone explicitly marks it resolved, not just replied.

Third: buried by volume. Low-priority tickets pile up and never get touched. Fix this with a weekly low-priority sweep. Friday afternoon, 30 minutes, clear the low queue. It is not glamorous but it works. Customers who sent a low-priority question two weeks ago and heard nothing are not staying customers.

What to do when you only have one person on support that day

Single-person days are real for small teams. Vacations, sick days, part-time schedules. The answer is not heroics. The answer is triage.

On thin days, touch urgent tickets only. Anything normal or low gets a holding reply that buys you 24 hours without making the customer feel ignored. Something like: 'Thanks for reaching out - we have received your message and will get back to you by [time]. If this is urgent, reply with URGENT and we will prioritize.' It is not fancy. It works.

This is also where AI drafts give you a real speed advantage. One person reviewing and sending 40 drafted replies is faster than one person writing 10 from scratch. The AI does not replace the judgment call. It removes the blank-page problem. See /blog/reduce-customer-support-response-time for more on this specific workflow.

How to review your SLAs after the first 30 days

Pull your breach rate. If you are missing more than 20% of SLAs, either the targets are wrong or the team is under-resourced. Both are useful signals. Look at which categories breach most - that is where you need better automation or more coverage.

Also check whether urgent is getting over-used. SLA inflation is real. If 40% of your tickets are tagged urgent, the definition has drifted. Go back to the written definition and retrain the team.

The goal is not 100% SLA compliance. The goal is knowing where you stand and improving month over month. A team that misses 15% of SLAs and knows it is in a much better position than a team that has no idea.

Where a full helpdesk like Zendesk or Intercom wins

I am not going to pretend Zendesk is bad. It is not. If you are at 20-plus agents and need manager-level reporting, a full helpdesk is probably worth the cost and the setup time.

Per-agent productivity dashboards are genuinely useful at scale. Zendesk shows you tickets resolved per agent per week, handle time, first contact resolution rate. If you have a support manager whose job is to coach agents, that data matters. Trigli does not have that yet.

Skill-based routing is another real advantage. If you have 10 agents with different specialties - billing experts, technical specialists, enterprise account handlers - Zendesk can auto-assign tickets to the right person based on tagged expertise. Trigli routes by category to an action, not to a specific agent based on skills.

Zendesk's trigger and macro system is also genuinely deep. If you have complex multi-step workflows with conditional branching, it can handle things that a lighter tool cannot. At 3-5 people, you probably do not need that. At 20-plus, you might.

What Trigli does not do (honest version)

No per-agent productivity dashboards. You cannot pull a report showing tickets resolved per agent per week. If that metric is important to your team right now, that is a real gap.

No skill-based agent routing. Tickets route by category to an action. They do not auto-assign to a specific agent based on tagged expertise. You can manually assign to anyone, but the routing logic does not know that one person is your billing specialist.

No phone or SMS support. Email and chat only. If your customers call you, Trigli does not touch that channel.

No native Shopify actions. The AI can reference your refund policy and draft a reply explaining next steps, but it does not process the refund inside Shopify. A human still does that.

No multi-brand routing inside one tenant. One Trigli account equals one brand. If you run two separate storefronts that need separate support identities, you need two accounts.

A practical starting setup for a team of two to five

Here is the actual sequence I would follow if I were setting this up from scratch today:

1. Connect Gmail or Outlook via OAuth. Takes about five minutes. Replies still send from your real address.
2. Before touching any settings, write down your three priority definitions in a shared doc. Urgent, normal, low. One sentence each. Make sure every person on the team agrees.
3. Set your SLA targets for each priority using the benchmarks from this post as a starting point. Urgent: 1 hour first response, 8 hours resolution. Normal: 4 hours, 48 hours. Low: 24 hours, 5 business days.
4. Create three automation rules. One for billing and access issues going to human review. One for general how-to questions getting a draft reply from your docs. One for feedback and feature requests getting drafted and queued for the weekly low-priority sweep.
5. Assign a default owner so no ticket is ever unowned the moment it comes in.
6. After 30 days, pull your breach rate. If you are missing more than 20% of any tier, the target or the coverage needs to change.
7. Also check urgent volume. If urgent tickets are over 25% of total volume, the definition has drifted. Go back to the written definition and reset the team.

The full pricing breakdown is at /pricing if you want to see what tier fits your current volume. The free plan covers 50 emails, 25 chats, and 10 tickets a month, which is enough to test the workflow before committing.

Is this overkill for a team of two?

Honest answer: if you are getting fewer than 20 tickets a week, a shared inbox with a label system might still be fine. No shame in that. The inflection point is usually 40-60 tickets a week, or when two people have replied to the same customer in the same day and neither knew the other did it.

SLA tracking at this stage is less about compliance and more about building the habit before you need it. Starting simple now means you are not scrambling to retrofit process when volume doubles. The teams I have seen struggle most are the ones who waited until they were at 200 tickets a week to think about any of this. By then it is a crisis, not a setup.

Be honest with yourself about where you are. If you are already stepping on each other's replies or losing tickets in a pile, that is the signal. You do not need to wait for it to get worse.