If your team handles incoming requests, whether that’s customer support tickets, IT helpdesk issues, contract reviews, or internal approvals, you probably have an informal sense of what acceptable response time looks like. A Critical issue needs attention within the hour. A billing question from a client matters more than a general question. A ticket that came in yesterday morning and hasn’t been touched is a problem.
You carry all of that in your head. So does everyone else on the team. The trouble is, when it only exists in people’s heads, it’s invisible on the board. A ticket that’s been sitting unanswered for four hours looks exactly the same as one that just came in. You have to read every item to know what’s actually on fire. Things get missed. And when something does get missed, the conversation is always the same: “Why didn’t anyone flag this sooner?”
That’s what SLA tracking is supposed to solve. And most tools technically offer it. But the setup process has always been the thing that stops teams from actually using it.
The configuration wall
When you go looking for SLA in a typical enterprise tool, you find a settings panel that assumes you already know what you’re doing. Business hours. Escalation chains. Priority matrices. Custom breach rules per tier. Linked notification workflows. It is genuinely powerful if you have a dedicated IT administrator to set it all up, and genuinely unusable if you don’t.
So most teams skip it. They use due dates and hope for the best. Some build tracking in spreadsheets. A few give up and just run a morning check-in to see what’s been waiting too long, which means adding a meeting to a problem that should have a technical solution.
We wanted to change that. Not by making the configuration easier. By eliminating most of it.
Start with a template, not a blank slate
The first thing we built was a library of SLA templates organized by industry and team type. IT support, customer success, HR helpdesk, legal review, facilities, software engineering, and more. Each template comes pre-loaded with the response targets and resolution targets that are standard for that type of work. First response within 1 hour for Critical issues, 4 hours for High priority, 24 hours for Normal. Numbers that match real-world expectations rather than numbers you have to research and justify yourself.
You pick the template closest to your situation, adjust anything that doesn’t fit, and you’re done with configuration. The whole thing takes a few minutes.
That might sound like a small thing, but it removes the biggest barrier: the blank slate. Most teams don’t skip SLA because they don’t want it. They skip it because starting from nothing feels like a project in itself.
One column. Three things happen.
Here’s the part that still surprises people when they first see it.
You go to the board where you want to track SLA. You add the SLA column. That’s it.
Gript automatically creates three linked columns: Status (SLA), Priority (SLA), and the SLA timer itself. They’re connected to each other and to your template. When you set a ticket’s priority to Critical, the timer knows it has a 1-hour response window. When someone changes the status to Awaiting User, the clock pauses automatically. When the status moves to Resolved, the timer stops and the result is recorded.
You don’t configure any of that. It’s built into the relationship between the three columns.
What the board actually tells you
Once the SLA column is running, your board communicates in a way it couldn’t before. You can see at a glance which tickets are new and untouched, which are waiting on the customer, and which have already breached their window. The SLA cell shows a live timer and a color-coded bar at the bottom. Dark means the clock is still running. Red means the window has passed.
The Priority (SLA) column handles the logic of which target applies. A Critical (P1) ticket has a tighter window than a High (P2). The same board can handle both at the same time, and the system knows the difference without you doing anything extra.
The Status (SLA) column is separate from your regular task status, and that’s intentional. When a ticket moves to Awaiting User, the clock pauses. That time shouldn’t count against your response target. When it’s Closed, it’s out of the queue entirely. These states have specific meaning in the SLA context, and the three columns work together to track them correctly.
Error Budget and Watermelon Detector
Error Budget comes from software reliability engineering. It represents how much room you have left before you miss your SLA target for the period. If you commit to resolving 95% of tickets on time and you’re currently at 91.2%, your error budget tells you how many more misses you can absorb before you fall below that threshold. Teams with a healthy budget can take on more volume. Teams running near zero need to either slow down or add capacity. Most teams don’t have visibility into this until it’s too late. We put it front and center.
Watermelon Detector is different. The name comes from a common saying in business: green on the outside, red on the inside. A watermelon metric is one where the numbers look good but the underlying reality is different.
In the context of SLA, the classic watermelon situation is this: your score shows 96% of tickets resolved on time, but your customer satisfaction rating is low. What usually happens is that teams optimize for the reported metric. If the metric is “did we technically close this within 4 hours,” people find ways to technically close things within 4 hours, even when the actual issue isn’t resolved.
Watermelon Detector flags that gap. When your SLA score is high but satisfaction signals are low, we surface it as a warning. Not as an accusation, and not as a definitive answer about what went wrong. Just as a signal worth paying attention to.
Not for IT departments. For everyone.
We built this for support teams first, because that’s the obvious use case. But some of the teams that have gotten the most out of it weren’t support teams at all.
Internal IT request queues. Legal contract review. Finance approval workflows. Anywhere that requests come in and someone needs to respond within a defined time, SLA tracking helps. And because Gript lets you view multiple boards together in the analytics page, you can see how SLA is going across different teams and projects from one place.
The goal was never to build something for SLA specialists. It was to make it work for the team that knows they need response time tracking, looked at the existing tools, and closed the browser tab. Pick a template, add one column, start measuring.
That’s it.