--- title: "Automating Deadline and SLA Tracking" description: "An agreed response time is just a number in a contract until somebody tracks it. And it can only be tracked once it is clear when the clock starts." canonical: "https://interfase.sk/en/news/automating-deadline-and-sla-tracking" lang: "en" last_updated: "2026-11-13" --- # Automating Deadline and SLA Tracking > An agreed response time is just a number in a contract until somebody tracks it. And it can only be tracked once it is clear when the clock starts. Published: 2026-11-13 - An SLA dispute is almost always a dispute about when the clock started — defining start and stop matters more than the number itself. - Waiting on the customer has to be pausable, or the agreed time is missed even with perfect work. - Tracking without escalation is just after-the-fact statistics; the alert has to arrive before the deadline passes. - Measure time to first response separately from time to resolution — they are two different promises and get conflated most often. The customer says they waited three days for a reply. You say you responded within four hours. You are both right — they count from their Friday evening email, you from Monday morning, when the request reached the system. An SLA dispute is almost always a dispute about definitions, not about performance. ## Definitions first, measurement second Before anything can be automated, it has to be clear in writing: - **When the clock starts.** On email delivery, on ticket creation, or on triage? The difference is usually hours. - **When it stops.** At the first reply, at a proposed solution, or at the customer's confirmation? - **What counts as working hours.** 8–17 on business days is not the same as 24/7, and the contract has to say which. - **Which public holidays apply.** With a customer in another country that is not obvious. - **How priority is set** and who may change it. If any of this is unagreed, automation solves nothing — it will simply measure, very precisely, something the parties never agreed on. ## First response and resolution are two promises Conflating them is the most common reporting mistake. **Time to first response** says how quickly somebody got back. **Time to resolution** says how long the customer had a problem. They are independent metrics with independent targets, and a company can hit one while missing the other. An average of the two means nothing. And one more thing: track **a percentile, not an average**. A 4-hour average against an 8-hour target looks excellent even when every tenth request waits three days. Those are exactly the customers who call. ## Pausing the clock is a necessity If a request is waiting on material from the customer, the clock should not run. Without that option the SLA is missed even with perfect work, and the numbers stop being credible. To keep it from being abused, pausing needs three things: **a comprehensible reason**, **visibility to the customer** (they should know they are the ones being waited on, and for what) and **a history entry**, so it can be checked afterwards who switched it on. ## Tracking without escalation is after-the-fact statistics A system that colours the row red once the deadline has passed is useless. What has value is an alert **before** the time runs out: - at **half** the agreed time, an alert to whoever is handling it, - at **80%**, an alert to their manager, - on **breach**, a record and a message to the customer before they get in touch. That last point makes the biggest difference to how a customer perceives a delay. An admitted delay is an annoyance; a concealed one is grounds for terminating the contract. Escalation also has a precondition — it needs an addressee. The same rule as with [document records and deadlines](/blog/automatizacia-evidencie-dokumentov-a-lehot): without an owner, an alert moves nobody. ## Priority is not a feeling "Urgent" is a word that loses its meaning over time, because everything is urgent. Priority is therefore set by **impact** (how many people are blocked) and **urgency** (by when it has to be done), not by the tone of the email. And one rule companies tend to underestimate: if customers set their own priority at no cost, within a month everything is top priority. ## Reporting that survives scrutiny An SLA report will one day be the basis of a contract negotiation or a dispute. It therefore has to come from the same data the customer sees, and it has to break down to individual cases. A number you cannot look behind will not convince the other side. We wrote about the data underneath this kind of reporting in [where time is really lost in a business application](/blog/rychlost-firemnej-aplikacie-kde-sa-realne-straca-cas) — you can only measure what you record. ## Where to start By writing the definitions down on one page and agreeing them with both sales and the customer. Only then set up the measurement. The reverse order produces a system that measures the wrong thing very accurately. If you are working on service processes or customer-facing reporting, [get in touch](/kontakt). We handle it under [custom development](/riesenia/vyvoj) — examples in our [case studies](/referencie). --- Web version: https://interfase.sk/en/news/automating-deadline-and-sla-tracking llms.txt: https://interfase.sk/llms.txt