KognitaKognita.

Blog

First Response SLA: Met. Resolution SLA: Blown. The Gap Is in the Handoff.

9 min read

The dashboard shows two numbers. First response SLA: green, 98% compliance. Resolution SLA: red, 61% compliance. These two metrics measure different things, and the gap between them tells you exactly where the SLA problem lives. First response is handled by automation — an auto-reply within seconds. Resolution requires a qualified engineer to actually fix the issue. Everything between the auto-reply and the engineer having the ticket is the handoff gap, and it's where resolution SLAs disappear.

Atlassian's community has documented this as "the most overlooked support metric." The ticket had an assignee. The ticket had a status. But it sat in "waiting for review" for six hours while the SLA clock ran because the handoff between L1 support and the correct engineering team had no defined time target and no alert when it exceeded it. The first response was instant. The resolution was late. These are different problems with different fixes.

Anatomy of the gap

Every ticket goes through a chain of handoffs before it reaches the engineer who can resolve it. L1 support reads it and decides it's technical. It goes to technical support, which routes to engineering. Engineering routes to the correct team. The correct team assigns it to an available engineer. Each of these stages has queue time, decision time, and assignment time. In aggregate, this chain routinely consumes the entire resolution SLA window before the resolving engineer sees the ticket.

The auto-reply that satisfies first response SLA is sent immediately on ticket creation. It has nothing to do with the ticket being routed correctly or being in the right queue. First response SLA compliance is a function of automation. Resolution SLA compliance is a function of routing speed. Optimizing the former does nothing to improve the latter.

Where a resolution SLA breach actually happens in the ticket lifecycle
A support ticket's journey from creation to resolution:

  T+0s: Ticket created. Resolution SLA clock: starts.
  T+3s: Auto-reply sent. First response SLA: ✓ MET.

  [The gap nobody measures]
  T+1h: L1 support reads ticket, decides it needs engineering.
  T+2h: Ticket enters engineering support queue.
  T+4h: Queue review. Routed to backend team (guess).
  T+6h: Backend team rejects. Routes to exports team.
  T+8h: RESOLUTION SLA BREACHED.
  T+9h: Exports engineer picks up ticket.
  T+9h 15m: Issue identified, fix deployed.

  First response SLA: ✓ green.
  Resolution SLA: ✗ red, 2 hours over.
  Root cause of breach: the 8 hours between auto-reply and engineer pickup.
  Actual resolution time once correct engineer had it: 15 minutes.

Operational Level Agreements — the SLA within the SLA

Well-designed SLA architectures include Operational Level Agreements (OLAs): internal commitments that specify how long each handoff stage takes. L1 to technical support: 30 minutes. Technical support to engineering: one hour. Engineering to correct team: 30 minutes. When OLAs exist, each stage has a measurable time target and an owner. When they don't exist, handoff stages are invisible gaps that consume SLA time without accountability.

Most teams don't have OLAs. They have a resolution SLA target and no mechanism to track whether the intermediate handoff stages are respecting it. The resolution SLA breach is discovered after it happens, attributed vaguely to "engineering capacity," and addressed by asking engineers to work faster — which is the wrong lever because engineering time wasn't the bottleneck.

The cumulative handoff time that consumes resolution SLA windows
Every handoff stage is an SLA risk:
  Stage 1: Customer → L1 support (queue wait: 30min–2h)
  Stage 2: L1 → technical support (decision time: 30min–1h)
  Stage 3: Technical support → engineering queue (queue wait: 1h–4h)
  Stage 4: Engineering queue → correct team (triage time: 1h–3h)
  Stage 5: Correct team → individual engineer (assignment time: 30min–2h)

  Total handoff time: 3h30m–12h
  For a 4-hour resolution SLA: breach is almost guaranteed through normal routing.
  The only way to meet the SLA is to collapse the handoff chain.

Collapsing the handoff chain

The structural fix for handoff-caused resolution SLA breaches is not faster handoffs — it's fewer handoffs. If a ticket can route directly from creation to the correct engineer, stages 1 through 4 of the handoff chain are eliminated. The resolution SLA window is available entirely for resolution work.

The SLA clock starts at ticket creation, and triage eats the window. Collapsing triage to a webhook-triggered codebase query eliminates that consumption. The agent identifies the correct team at creation, routes directly, and the first human who sees the ticket is the one who can resolve it.

What the ticket lifecycle looks like with direct webhook routing
What the same ticket looks like with Kognita webhook agent:
  T+0s: Ticket created. Resolution SLA clock: starts.
  T+3s: Kognita webhook fires. Agent queries codebase.
  T+5s: Agent identifies: exports team owns affected service.
  T+5s: Ticket routed directly to exports team queue with context.
  T+5s: Auto-reply to customer: "Routed to exports team. Priority: P2."
  T+10min: Exports engineer sees ticket. (No queue delays, direct routing.)
  T+25min: Issue resolved.

  First response SLA: ✓ 5 seconds.
  Resolution SLA: ✓ 25 minutes on a 4-hour window.
  Handoff stages eliminated: 4 of 5.

Kognita's role in eliminating the gap

Kognita provisions a webhook that fires at ticket creation. The managed agent queries the live codebase for service ownership and attaches the routing decision before any human touches the ticket. The ticket goes directly to the correct team's queue — not through L1, not through a generic engineering queue, directly to the team that owns the service. The auto-reply to the customer includes the routing action and the priority, so the customer has more information than the generic acknowledgment they would have received otherwise.

First response SLA: still met in seconds. Resolution SLA: now achievable because the SLA window is spent on resolution work instead of routing chain navigation.

Final take

First response SLA and resolution SLA measure different things. Meeting one doesn't help the other. Resolution SLA is won or lost in the handoff chain — the gap between the auto-reply and the correct engineer seeing the ticket. Collapsing that gap requires routing by service ownership at ticket creation, not by keyword matching through a multi-stage triage chain.

First response SLA is an automation problem. Resolution SLA is a routing problem. Solving routing means eliminating handoff stages, not adding OLAs to a broken chain. Direct codebase-based routing at ticket creation is how the chain disappears.