Ticket SLA & Escalation Monitor

The problem this kills

You find out a ticket blew its SLA the same way everyone does: the customer escalates, or the weekly report turns red, or your boss forwards you an angry email. By then it's too late - the breach already happened, and now you're explaining it instead of preventing it. Meanwhile the ticket that's about to breach right now is sitting quietly in a queue because nobody's watching the clock on it.

In most service desks, "managing SLAs" means a manager eyeballing a ticket list a couple of times a day and hoping they catch the dangerous ones in time. The math is fuzzy: does the 8-hour target mean 8 clock hours (so a Friday-5pm ticket is breached by Monday morning) or 8 business hours? Stuck tickets - the ones bouncing between "waiting on customer" and nowhere - slip through. And when a ticket finally does need to move to a lead, it happens over a tap on the shoulder or a Slack ping, with no record of who decided what or why.

This tool flips it from reactive to proactive. It watches every open ticket against its SLA target, warns the agent before the breach, flags the ones already over, and routes the genuinely stuck ones to a lead for a real, recorded escalation decision - so SLAs are managed on purpose, not discovered after the fact.

What you'll build

A small internal web app, just for your team, that:

• Imports your open tickets - created time, priority, status, and assignee - from a CSV/Google Sheet export or your ticket tool, and your SLA targets by priority.
• Computes time-to-breach for every open ticket using your real business hours (so a target doesn't tick down overnight, on weekends, or on holidays unless you say it should).
• Sorts every ticket into tiered warnings: at-risk (getting close to the target) and breached (already over), with a clear countdown.
• Warns the assigned agent when their ticket goes at-risk, so they can act before it breaches.
• Flags breached and stuck tickets and routes them up your escalation chain to the right lead.
• Puts a human approval gate in front of every escalation: the lead reviews the suggested action - reassign, raise priority, or add resources - and approves it before anything is recorded or reassigned.
• Dedupes on ticket ID so the same ticket can't be ingested twice or escalated twice.
• Keeps a living escalation log and a SLA dashboard (how many at-risk, breached, escalated; breach rate by priority and by agent).
• Exports the SLA status and the escalation log as CSV - in the exact columns your reporting or ticket tool expects.

What's inside the Implementation Plan

The plan is a single markdown file you paste into Claude Code (a free AI coding agent). It walks the agent through building the whole tool, step by step, each step ending with a ready-to-paste prompt.

The most important part: the plan opens by interviewing you about your business. Before it writes a single line, the agent asks how tickets reach you and what your export looks like, what your SLA targets are by priority, exactly which hours count as "business hours" (and your holidays), what makes a ticket "stuck," who escalates to whom, what an escalation action actually does, and your messy edge cases (a ticket with no assignee, a paused ticket, a re-opened ticket, a priority change mid-life). It reads a short tailored spec back to you, you confirm it, and only then does it build - so you get a monitor shaped to your desk and your SLA rules, not a generic template you have to bend to fit.

Inside you'll find:

• The discovery interview and how the agent turns your answers into the data model and the SLA math.
• The full build: database, login, the ticket + SLA-target import, the business-hours time-to-breach engine, the at-risk/breached classifier, the agent warnings, the escalation routing, the lead's approval screen, the escalation log, the SLA dashboard, and the exports.
• The hard human-in-the-loop gate and the dedupe/double-escalation guards.
• Verification steps so you can prove it works, and the CSV-in/CSV-out fallback so it's fully usable even before you connect it to your ticket tool's API.

The governance it includes (this is the point)

This isn't a toy. The plan builds in the controls a service-desk leader actually needs:

• Login so only your team can see or touch anything.
• Row-level security so people only ever see their own organization's tickets and escalations.
• A complete audit trail - every import, classification, warning, escalation proposal, approval, reassignment, and export is logged with who and when.
• A hard human-in-the-loop gate - the AI proposes the escalation action, but a real lead must approve it; nothing is recorded as an escalation and no reassignment happens automatically.
• Duplicate guards - dedupe on ticket ID so the same ticket is never imported twice, and a no-double-escalation rule so an already-escalated ticket isn't escalated again.

Who it's for

Help-desk and service-desk managers, team leads, and operations leaders who are tired of finding out about SLA breaches after they happen. If your team runs on tickets and you manage SLAs by squinting at a queue and hoping, and you want a real, auditable early-warning and escalation system without buying an enterprise ITSM suite or hiring a developer - this is for you. You don't need to write code. You need a ticket export, your SLA targets, your business hours, your escalation chain, and an afternoon-to-a-weekend.

You've got this - paste the first prompt and let the agent interview you.