---
id: financeiros/sla-esteiras-operacionais
industry: Financial services
usage: widely used
effort: medium
grain: Task x assignee (pass); customer waiting event (messages until the first reply); ticket
---

# SLA for operational pipelines

How long each review, calculation, claim and ticket stays in each person's hands, who holds the queue right now and what blew the deadline, in business hours and without treating a send-back as a delay.

## Executive summary

**For:** Operations leaders in lending, claims, calculation, formalization and support who answer for the team's deadlines and productivity.

**What it solves**

- The leader sees each analyst's queue right now, with what came in today, what is left over and what is overdue.
- Time is measured in the team's business hours, with the right target for each process type and severity.
- Send-backs and reopenings show up as rework, separate from execution time.

**Why it matters:** In lending, insurance and BPO the pipeline is governed by documents and checks, and the time spent in each stage is the main management metric: it sets how long the customer waits, how much the team produces and where to hire. Measured in calendar hours or only by the average, the dashboard blames the wrong analyst and hides the case that has been stuck for days. With the queue and the SLA on the same yardstick, the leader acts before the customer complains.

**Business questions it answers**

- Which calculation team tasks have been pending for more than 2 business days?
- Which analyst has the largest overdue queue right now?
- How many claims are waiting for an operations reply past the deadline?
- What is the typical triage time and the worst case this week?
- Which pipeline stage concentrates time and rework?
- How many tickets did each partner open this month and how many were resolved on time?

**What you need**

- The pipeline or support tool connected to Nekt: Zeev, Pipefy, Zendesk, ClickUp or the platform database
- The team list with each person's role and period, and the deadline targets per process and severity
- The team calendar: working hours, local holidays and special days

**What you get**

- A queue table per analyst, refreshed throughout the day
- A table of passes with business time, deadline and SLA status
- Median, p90 and % on time by stage, severity and week
- Deadline alerts and an AI agent that answers about the queue

## Detailed

### The problem

The pipeline tool stores each task with start, end and assignee, but it does not say who is overloaded now or how many business hours each stage took. Whoever subtracts dates in UTC counts nights, weekends and holidays as delay; whoever adds the sent-back task punishes the analyst for another team's mistake. In claims and support the clock is the conversation, and without separating the customer's message from the operations reply there is no response SLA.

### Business rules

1. **The team is a table, with periods and people at zero.** Keep the list of members by the tool's user id, with team, role and start and end dates. The queue starts from this list and shows people without tasks at zero. Shared inboxes (the team's scheduling inbox, for example) appear apart from people. Never derive the team only from who showed up in the tasks. (Avoid: A hard-coded list of emails, edited by hand at every hire.)
2. **Today's, carried-over and overdue queue.** Consider only active tasks. Started today (date in America/Sao_Paulo) is today's queue; started earlier is carried over; with the tool's expected end date less than or equal to now is overdue. Count distinct processes, not rows: a task with two assignees appears twice in the source. Separate main tasks from subtasks. (Avoid: Counting rows in the task table and comparing the deadline with a UTC clock.)
3. **Business hours are computed day by day.** Walk through each day between start and end and add only the part inside working hours (for example, 9am to 6pm, or 8am to 6pm in customer service), skipping weekends, national, state and municipal holidays and company-wide vacations, with half days where they exist. Moving only the start and end into business hours and subtracting still counts the nights and the weekend in between. (Avoid: Clamping start and end to business hours and subtracting them.)
4. **One time basis per metric.** Zendesk and other tools provide business time and calendar time for wait, first reply and resolution. Pick one per metric and use the same in the target, the percentage and the average. (Avoid: % resolved within 24h on calendar time and average time on business time in the same dashboard.)
5. **Each pass through a team is measured on its own.** Consecutive tasks from the same team form a pass, opened by one of that team's initiating tasks. When the case goes to another team and comes back, a new pass opens. Inside a pass, each change of assignee opens a sub-pass, to measure who did each part. Flag passes with a review step (double check). A team task without an initiating task before it is orphaned and stays out of the time. (Avoid: Adding all the case's time in the team and dividing by the number of cases.)
6. **Response SLA starts at the customer's message.** Order messages by process (claim, rent guarantee, ticket). An event starts at the customer's first message after an operations reply, and consecutive customer messages belong to the same event. The event ends at the first operations message after the start. No reply is a status of its own, not zero. Who counts as operations comes from the sender's id or role (claims analyst, brokerage admin), not from the name. (Avoid: Measuring from the claim's opening to the last message, or counting each customer message as an SLA.)
7. **The target depends on process and severity.** Keep targets in a table: by process (for example, claims 24 business hours and other processes 48) and by ticket severity (for example, critical 60 minutes, high 4 hours, medium 8, low 16). Change a target with a start date, so the past is not reclassified. (Avoid: A single target for claims, registration and questions, written inside the code.)
8. **Send-backs and reopenings are rework.** A task closed with the result of sending the request back leaves the stage time and enters the rework rate of the team that got it back. A reopened ticket counts as rework for the analyst who closed it. Show rework by analyst and by severity over the last 30 days. (Avoid: Adding the sent-back task to the average time of whoever received it.)
9. **Median and p90, only among those who passed.** Stage time has a long tail. Show median and 90th percentile per week, as well as the average. A stage's time considers only cases that went through it; a case that did not go through it does not count as zero. (Avoid: Average of all cases, with zero for those that skipped the stage.)
10. **Backlog only with customer work.** Remove from the support queue internal development subtasks without a company, test cards and duplicates. Tickets without a company or partner filled in stay in the queue but become a metric of their own (% without company), because they hide volume per customer. When the partner comes in the field name as "[code] name", extract the code to join with the registry. (Avoid: Counting dev subtasks and tests in the support backlog.)

### Deadline targets used in practice

Examples of targets real operations adopted. Each goes into the targets table with time basis and validity.

- **Claim: first operations reply** → 24 business hours (`working hours 8am to 6pm`)
- **Other platform processes** → 48 business hours (`working hours 8am to 6pm`)
- **Critical ticket (Sev1)** → First reply in 60 minutes (`sla_resposta_min = 60`)
- **High ticket (Sev2)** → First reply in 4 hours (`sla_resposta_min = 240`)
- **Medium ticket (Sev3)** → First reply in 8 hours (`sla_resposta_min = 480`)
- **Low ticket (Sev4)** → First reply in 16 hours (`sla_resposta_min = 960`)
- **Partner ticket in Zendesk** → Resolved within 24 hours (`first_resolution_time_in_minutes`)
- **Pipeline task (Zeev, Pipefy)** → The task's own expected deadline (`expectedEndDateTime`)

### Definitions

| Metric | Definition |
|---|---|
| Today's queue | distinct processes with an active task started today (America/Sao_Paulo), per analyst |
| Carried-over queue | distinct processes with an active task started before today, per analyst |
| Overdue queue | distinct processes with an active task whose expected deadline is less than or equal to now, per analyst |
| Business time of the pass | sum of hours inside working hours, on the team calendar's business days, between the start of the first and the end of the last task of the pass, without sent-back tasks |
| Time to first reply | business hours between the customer's first message in the event and the first operations message after it |
| % on time | events or tasks completed within the target / events or tasks completed in the period, by process, severity and analyst; no reply stays out of the denominator and is shown apart |
| Rework rate | passes or tickets with a send-back or reopening / passes or tickets completed in the last 30 days |
| % without company | tickets without a company or partner filled in / tickets opened in the period |

### Pitfalls

- **Outdated team list.** The team's email list lived in the code; new hires did not appear in the queue and people who left stayed at zero until someone edited the transformation. How to avoid: Members table by user id, with start and end dates.
- **Task replaced mid-year.** A pipeline task was replaced by another from July on, and the stage's history dropped to zero from one month to the next. How to avoid: Task-to-stage mapping with validity, updated together with the workflow.
- **Nights counted as delay.** A dashboard only clamped start and end to business hours and subtracted; a claim opened Friday afternoon and answered early Monday looked like it took more than 60 hours. How to avoid: Add business hours day by day on the team calendar.
- **Internal comment as a reply.** The first-reply SLA used the team's first comment in ClickUp, which can be an internal note; the customer still had no answer. How to avoid: Use the message sent to the customer; when only the proxy exists, say so on the dashboard.
- **Dates in UTC.** Tasks started after 9pm fell into the next day's queue, and the expected deadline was compared with a now in another time zone. How to avoid: Convert everything to America/Sao_Paulo before comparing with today and now.
- **Another team's mistake on the analyst's tab.** Tasks sent back for a missing document entered the average time of whoever got the case back. How to avoid: Send-backs out of the stage time and into the rework rate.

### Acceptance test

- [ ] Every active team member appears in the queue, including at zero tasks.
- [ ] For 5 randomly chosen tasks, the computed business time matches a manual count on the team calendar (difference below 0.1 hour).
- [ ] Today's + carried-over queue = distinct processes with an active task for the analyst in the tool, at the same moment.
- [ ] No task with a send-back result enters the stage's average time.
- [ ] Every response SLA event has a status: within SLA, outside SLA or no reply.

### Context document

```text
SLA for operational pipelines
- Time zone: America/Sao_Paulo for today, now and every date shown.
- Team: use table <members_table> (user id, team, role, validity). An analyst without tasks appears at zero.
- Queue: active tasks only. Today = started today; carried over = started earlier; overdue = expected deadline <= now. Count distinct processes.
- Business time: hours inside working hours <start> to <end>, on business days, without national and local holidays, company-wide vacations, and with half days where they exist.
- Response SLA: an event starts at the customer's first message after an operations reply and ends at the first operations reply. No reply is a status of its own.
- Targets: claims <24> business hours, other processes <48>; tickets by severity according to <targets_table>.
- A task with result "devolver solicitação" (send request back) and a reopened ticket are rework, never stage time.
- For times, report median and p90 as well as the average, only among cases that went through the stage.
- Internal dev subtasks, tests and duplicates are not in the backlog.
Exceptions per client:
- <client>: task <new> replaced <old> from <date>; both map to stage <stage>.
- <client>: Ash Wednesday is a business day only from 2pm; municipal holiday on <date>.
```

### Variations

- **Sales stock:** The same reasoning for stalled requests: stock per SDR and loan officer, average aging and follow-up overdue, on time or missing.
- **Tickets by partner:** Real estate agency, correspondent or firm extracted from the ticket field, with volume, reopenings and % resolved on time per partner.
- **Stage accuracy:** Add to the SLA the rate of reviews that found errors (double check) to see whether the fastest team is also the most accurate.