SLA and turnaround time
Objective. Define turnaround time and SLA attainment, show how the clock is defined and bounded, and separate a timing measure from a volume or quality claim.
A dictionary entry. Turnaround time (TAT) measures how long work takes from a defined start to a defined finish; SLA attainment measures the share of work completed inside the agreed time target. Both depend entirely on how the clock is defined.
See it in the demo
What it is
Turnaround time is the elapsed time a unit of work takes between a defined start event and a defined completion event. SLA attainment is the proportion of work completed within the contracted or agreed time threshold. TAT describes duration; SLA attainment describes how often the duration target was met. Neither says anything about how much work there was or how good it was - they are timing measures only.
How it is calculated
At app-logic level: TAT is completion time minus start time for each item, often reported as a distribution (median and tail), not just an average; SLA attainment is the count completed within the threshold divided by the count in scope. Included: items whose start and completion events are both captured, within the chosen scope (payer, client, queue, work type). Excluded or adjusted: items outside scope, and - critically - any clock-stop rules (waiting on a third party, on hold, out-of-hours calendars). What starts and stops the clock, which calendar applies, and how backlog ageing is treated are configurable and materially change the number - confirm with product. Elapsed time here is wall-clock duration, not active effort (MET-07).
How to read it and the common misread
Read TAT as a distribution and SLA attainment against the agreed threshold and scope. A good average TAT can still hide a long tail that breaches SLA for a minority, so read the tail, not only the mean. Targets are the customer's contracted thresholds. The common misread is comparing TAT or SLA figures across teams, payers or periods without confirming the clock definition and scope are the same - different start/stop and hold rules make the numbers incomparable. A second misread is confusing turnaround (elapsed wall-clock) with active effort or handle time; a fast handle time can coexist with a slow turnaround if work waits in a queue.
Where it appears
In RCM Operations (SLA and Risk, and the outcome briefings) and in Work Output (backlog and SLA). It also connects to Capacity Planning and Intraday where backlog and TAT drive staffing decisions. Demo figures are seeded illustrations.
Interpretation check
TAT and SLA attainment mean nothing without the clock definition and scope. Read TAT as a distribution, not an average, and never compare across teams or payers until the start/stop and hold rules match.
In the field
For an RCM customer such as KnackGlobal, turnaround on denials and appeals is only comparable across payers once each payer's clock-stop and hold rules are aligned - otherwise a 'slow payer' may simply have more waiting time outside the team's control.
Practical task
In the Work Output or RCM Operations demo, find a TAT or SLA figure and write down: what event you believe starts and stops the clock, whether a tail is visible behind the average, and what you would confirm with product before quoting it against a customer's contract.
Self-check
What is the difference between turnaround time and SLA attainment?
Turnaround time is the elapsed duration from a defined start to a defined completion; SLA attainment is the share of work completed within the agreed time threshold. One is duration, the other is how often the target was met.
Why can a good average TAT still mean SLA breaches?
An average can hide a long tail. A minority of items can breach the threshold while the mean looks healthy, so the distribution and tail must be read, not just the average.
Why is turnaround time not the same as active effort or handle time?
Turnaround is wall-clock elapsed time including waiting; active effort is time actually worked. Work can have a short handle time but a long turnaround if it waits in a queue or on hold.
What must you confirm before comparing SLA figures across payers or teams?
That the clock definition (start/stop events), the hold/clock-stop rules, the calendar and the scope are identical - all configurable. Different definitions make the figures incomparable.
Verified vs demo. The demo shows TAT and SLA on seeded data. A customer's figures depend on their clock definitions, hold rules, calendars and scope, which must be validated in their instance before any SLA claim is made.