A backlog number by itself can be misleading.

An operation with 10,000 open cases may be completely under control.

Another operation with only 3,000 open cases may already be facing serious SLA risk.

The difference is often not the size of the backlog.

It is the age, priority, complexity and available capacity behind it.

For managers running claims, verification, servicing, KYC, document processing or other case-based operations, backlog should therefore never be managed as a single number.

A stronger approach looks at:

  • Total open workload
  • Case aging
  • SLA and TAT
  • Work type
  • Priority
  • Pend and hold status
  • Follow-up dates
  • Incoming volume
  • Processing capacity
  • Productivity
  • Expected backlog burn-down

Together, these measures provide a much clearer picture of operational risk.

What Is Backlog?

Backlog is the amount of work that has been received but has not yet reached its required completion state.

A simple formula is:

Closing Backlog = Opening Backlog + New Work Received − Work Completed

For example:

Opening backlog: 5,000 cases

New cases received: 1,200

Cases completed: 1,000

Closing backlog becomes:

5,000 + 1,200 − 1,000 = 5,200 cases

The operation added 200 cases to backlog during the day.

That information is useful.

But it still does not tell management whether the situation is serious.

For that, we need aging.

Why Total Backlog Is Not Enough

Consider two operations.

Operation A

Backlog: 10,000 cases

  • 8,000 received within the last 2 days
  • 1,500 aged 3–5 days
  • 500 aged more than 5 days
  • SLA target: 10 days

Operation B

Backlog: 3,000 cases

  • 500 received within the last 2 days
  • 700 aged 3–5 days
  • 1,800 aged more than 10 days
  • SLA target: 10 days

Operation A has more than three times the backlog.

Yet Operation B has the much greater service risk.

This is why management should always ask:

How old is the backlog?

not simply:

How large is the backlog?

What Is Case Aging?

Case aging measures how long a case has remained open.

At its simplest:

Case Age = Current Date − Received Date

If a case was received on 1 August and is still open on 11 August, its age is approximately 10 days, depending on the business calendar being used.

Organizations may calculate aging using:

  • Calendar days
  • Business days
  • Working hours
  • SLA-specific business calendars

The correct approach depends on the process and customer commitment.

Whatever method is selected, it should be clearly defined and used consistently.

Use Aging Buckets

Managers should not have to inspect every case individually.

Aging buckets provide a much faster view of workload health.

For example:

0–2 days — New workload
3–5 days — Normal processing
6–8 days — Needs attention
9–10 days — SLA risk
10+ days — Breached

Another process may use:

0–7 days
8–14 days
15–21 days
22–30 days
30+ days

The bucket design should reflect the SLA and normal processing cycle.

The objective is to make risk visible immediately.

SLA and TAT Are Related but Not Identical

Two terms frequently used in case operations are TAT and SLA.

Turnaround Time — TAT

TAT generally measures how long a transaction takes from a defined starting point to completion.

For example:

TAT = Completion Date − Received Date

Service Level Agreement — SLA

SLA represents the required service commitment.

For example:

95% of cases completed within 5 business days

or:

100% of cases completed within 30 calendar days

TAT describes actual performance.

SLA defines the expected performance.

A good case-management environment should help management understand both.

Do Not Wait Until the SLA Is Breached

One of the biggest mistakes in operational management is treating SLA as a historical metric.

A report may say:

92% SLA achieved yesterday

That tells management what already happened.

A stronger system should also answer:

Which currently open cases are likely to breach next?

For example:

SLA target: 10 days

Case age: 9 days

Status: Open

That case should attract more attention than another case received yesterday.

The system should therefore distinguish between:

  • Within SLA
  • Approaching SLA
  • At risk
  • Breached

This makes SLA management proactive rather than retrospective.

Remaining SLA Time Can Be More Useful Than Age

Case age tells you how old the case is.

But managers may also want to know:

How much time remains before breach?

For example:

SLA target: 15 days

Current case age: 12 days

Remaining SLA time:

15 − 12 = 3 days

This makes prioritization easier.

A queue containing thousands of cases can be sorted based on remaining SLA time rather than simply received date.

FIFO Is Useful — But Not Always Enough

FIFO means:

First In, First Out

The oldest eligible case is processed first.

FIFO is a strong default when:

  • Cases are similar
  • Priority is equal
  • Aging control is important
  • Service commitments are based largely on received date

But pure FIFO may not be appropriate in every operation.

Consider:

Case A — 8 days old, standard priority

Case B — 2 days old, critical customer escalation

A pure FIFO model would always select Case A.

The business may require Case B to be handled first.

That is why many operations need controlled prioritization.

Combine Priority, Skills and Aging

A more mature allocation sequence might look like:

Skill Eligibility
↓
Critical Priority
↓
SLA Risk
↓
Oldest Case

This prevents employees from manually deciding what they want to process while still respecting business priorities.

It also reduces the risk of older or more difficult cases being continuously avoided.

Watch for Cherry-Picking

When employees select cases manually, backlog aging can become distorted.

Processors may naturally prefer:

  • Easier cases
  • Familiar work
  • Newer cases
  • Transactions that can be completed quickly

This can make productivity appear healthy while old or complicated cases continue accumulating.

The result may look like:

High completed volume

but also:

Increasing aged backlog.

This is one reason managers should monitor backlog aging alongside productivity.

High productivity does not automatically mean the workload is being processed in the right order.

Separate Backlog by Work Type

Another common mistake is treating all cases as equivalent.

Suppose an operation has:

6,000 open cases

That total may consist of:

  • 3,500 simple requests
  • 1,500 medium-complexity cases
  • 800 complex cases
  • 200 escalations

The capacity required to clear this backlog may be very different from what the headline number suggests.

Aging should therefore be analyzed by dimensions such as:

  • Department
  • Queue
  • Work type
  • Product
  • Priority
  • Complexity
  • Customer
  • Team

This helps management identify where the problem is actually concentrated.

Pended Cases Need Separate Attention

A pended case is not necessarily the same as an actively processable case.

For example, a case may be waiting for:

  • Customer documentation
  • Provider information
  • Another department
  • System availability
  • External verification

Management should distinguish between:

Actionable backlog

and

Waiting backlog

Otherwise, the operation may appear to have more immediately processable work than it actually does.

However, pended cases should not disappear from management attention.

They still need monitoring.

Pend Aging Matters Too

Suppose a case has been pended for 20 days because supporting documentation is missing.

That may be legitimate.

But management should still ask:

  • Was the required information requested?
  • When was the last follow-up?
  • Is another follow-up due?
  • Has the case exceeded a maximum pend period?
  • Should it be escalated or closed?

This creates two useful aging concepts:

Overall Case Age

and

Pend Age

Both may matter.

Follow-Up Backlog Should Be Visible

Follow-ups are one of the easiest categories of work to lose in manual environments.

An employee may set an Outlook reminder.

Another may use a spreadsheet.

Someone else may keep personal notes.

This makes organization-level visibility difficult.

Managers should be able to identify:

  • Follow-ups due today
  • Overdue follow-ups
  • Future follow-ups
  • Follow-ups by owner
  • Follow-ups by work type
  • Cases repeatedly followed up without resolution

Follow-up work is still workload.

It should be included in the operational view.

Backlog Growth Is a Capacity Signal

Backlog generally grows when incoming demand exceeds effective processing capacity.

At a basic level:

Net Backlog Change = Incoming Volume − Completed Volume

Suppose an operation receives:

1,500 cases per day

but completes only:

1,300 cases per day

Daily backlog growth is:

1,500 − 1,300 = 200 cases

If nothing changes, approximately 1,000 additional cases may accumulate over five working days.

This can quickly turn into aging and SLA risk.


See how long your backlog will take to clear

Use the free Praevexa Workforce Planner to model opening backlog, incoming monthly volume, AHT or CPH, working days, shrinkage, automation and available HC.

The planner projects ending backlog, breached inventory, SLA attainment and the additional headcount required to stabilize or clear the workload.

Build a Backlog Burndown Plan

Link that to:

https://www.praevexa.com/WorkforcePlanner.aspx

Forecast Whether the Backlog Will Grow or Shrink

A useful management question is:

At our current capacity, is backlog going up or down?

Suppose:

Current backlog: 8,400 cases

Expected daily incoming volume: 1,500

Expected daily completions: 1,800

Net burn-down capacity:

1,800 − 1,500 = 300 cases per day

If all assumptions remain stable:

8,400 ÷ 300 = 28 working days

The operation would require approximately 28 working days to eliminate the existing backlog while continuing to absorb new incoming work.

That number immediately gives management a much more useful planning view.

But Backlog Burn-Down Is Rarely Perfectly Linear

The simple calculation above is useful for planning, but real operations are more complicated.

Capacity may change because of:

  • Leave
  • Training
  • Attrition
  • New hires
  • Ramp-up
  • System downtime
  • Changing case complexity
  • Volume spikes
  • Weekends or holidays
  • Priority work
  • Rework
  • Quality interventions

So backlog forecasts should be updated regularly.

The objective is not to predict the future perfectly.

It is to identify whether the current operating model is sustainable.

Connect Backlog to CPH and AHT

Backlog can also be translated into workload.

Suppose:

Backlog = 12,000 cases

Expected productivity = 6 CPH

Required productive hours:

12,000 ÷ 6 = 2,000 productive hours

Now management can compare that workload against available capacity.

Alternatively, when AHT is more appropriate:

Backlog = 12,000

Average handling time = 10 minutes

Total handling requirement:

12,000 × 10 = 120,000 minutes

or:

2,000 hours

This helps convert a case count into a staffing requirement.

For more detail on these measures, see:

CPH, AHT, Productivity and Utilization: A Practical Guide for Operations Teams

https://www.praevexa.com/insights/cph-aht-productivity-utilization-guide

A Practical Capacity Example

Suppose a processing team has:

24 productive FTE

Average productive time per FTE:

7 hours per day

Expected productivity:

6 CPH

Daily processing capacity is approximately:

24 × 7 × 6 = 1,008 cases

Now suppose average incoming demand is:

950 cases per day

The theoretical backlog reduction capacity is:

1,008 − 950 = 58 cases per day

If current backlog is:

2,900 cases

Estimated burn-down time is:

2,900 ÷ 58 = approximately 50 working days

Management now has a much more useful question to consider:

Is 50 working days acceptable?

If not, possible interventions include:

  • Additional temporary capacity
  • Overtime
  • Cross-training
  • Productivity improvement
  • Process simplification
  • Automation
  • Prioritization
  • Work redistribution

The backlog number has now become an operational decision.

Quality Should Not Be Sacrificed to Clear Backlog

When backlog rises, organizations often respond by pushing productivity.

That can work.

But it can also create another problem.

Employees may process faster and produce more defects.

The organization then creates rework, which adds further workload.

So backlog reduction should be monitored alongside:

  • Quality
  • Error rates
  • Rework
  • Customer impact
  • Compliance risk

Clearing work quickly is not useful if the work needs to be processed again.

Create a Backlog Management Dashboard

A practical management dashboard should ideally show more than the total open cases.

Useful indicators include:

Workload

  • Opening backlog
  • Received volume
  • Completed volume
  • Closing backlog
  • Net backlog movement

Aging

  • Cases by aging bucket
  • Average case age
  • Oldest case
  • Cases approaching SLA
  • Breached cases

Workflow Status

  • Assigned
  • In progress
  • Pended
  • On hold
  • Follow-up due
  • Rework

Capacity

  • Available FTE
  • Productive hours
  • CPH
  • AHT
  • Estimated daily capacity

Service Performance

  • TAT
  • SLA
  • SLA at risk
  • Breach rate

This helps managers understand workload, risk and capacity in the same view.

Use Backlog Trends, Not Just Daily Snapshots

A daily backlog figure can fluctuate.

Trend information is more useful.

Management should ask:

  • Is backlog increasing week over week?
  • Is aged backlog increasing?
  • Are SLA-risk cases growing faster than total backlog?
  • Has completion capacity changed?
  • Did a volume spike cause the issue?
  • Is one work type responsible?
  • Is AHT increasing?
  • Has absenteeism reduced available capacity?

Trends help distinguish temporary variation from structural problems.

Management Should Have an Intervention Threshold

Organizations should define when action is required.

For example:

Green

Less than 70% of available SLA window consumed.

Amber

70–90% consumed.

Red

More than 90% consumed or SLA breached.

Similar thresholds can be established for:

  • Backlog days
  • Aging buckets
  • Capacity gap
  • Pend age
  • Follow-up overdue rate

This makes operational governance more consistent.

Avoid Managing Only the Average

Average age can also hide risk.

Consider five cases aged:

1 day
1 day
1 day
1 day
26 days

Average age:

6 days

That sounds manageable.

But one case has already become significantly aged.

Management should therefore monitor:

  • Average age
  • Median age
  • Oldest case
  • Aging distribution
  • SLA-risk population

The distribution often matters more than the average.

From Backlog Reporting to Backlog Management

There is an important difference between reporting backlog and managing backlog.

Backlog reporting says:

“We have 7,500 open cases.”

Backlog management asks:

  • Which cases should be worked first?
  • Which are approaching SLA?
  • Which cannot currently be processed?
  • Which work types are creating the problem?
  • Do we have enough capacity?
  • When will the backlog return to normal?
  • What action is required today?

That is the shift operational teams should aim for.

How Case Management Software Helps

A structured case-management system can make backlog control much easier because the workload already contains information such as:

  • Received date
  • Work type
  • Priority
  • Owner
  • Status
  • SLA target
  • Follow-up date
  • Pend status
  • Completion time
  • Case activity

Management no longer has to reconstruct this information from multiple trackers.

Instead, the operating data itself becomes the source of backlog intelligence.

How Praevexa CaseFlow Can Help

Praevexa CaseFlow is designed for back-office and case-based operations where work allocation, aging, SLA and operational performance need to be controlled together.

CaseFlow can support capabilities such as:

  • Configurable Departments, Queues and Worktypes
  • Received-date and case-aging visibility
  • Skill-based case eligibility
  • Priority and FIFO/LIFO allocation
  • Exclusive case ownership
  • Pend and hold workflows
  • Follow-up management
  • Rework and reassignment
  • TAT and SLA monitoring
  • AHT and CPH
  • Productivity and utilization
  • Backlog reporting
  • Role-based Operations Intelligence

The objective is not simply to show managers how much work remains.

It is to help them understand where the risk is, what should be worked next and whether available capacity is sufficient to meet demand.

Backlog should not be managed as a static number. The Praevexa Workforce Planner lets you see how inventory changes month by month as demand, productivity, staffing and automation assumptions change.

Model your backlog and SLA risk →

https://www.praevexa.com/WorkforcePlanner.aspx

Learn more about Praevexa CaseFlow:

https://www.praevexa.com/CaseFlow.aspx

You may also find this guide useful:

What Is Case Management Software for Back-Office Operations?

https://www.praevexa.com/insights/case-management-software-back-office-operations