Exception Ageing

An exception is a case that does not follow the normal process and may need investigation or approval, and ageing shows how long it has waited without resolution. A fictional accounts team flags an invoice mismatch and keeps the case open while it checks the purchase order, so after ten days the exception appears in an older age band.

The start timestamp might be when the problem arose, was detected or was formally logged, and the dashboard should state which one it uses. Those dates can differ: a fictional warehouse notices damage on Monday but logs it on Wednesday, so reporting from Wednesday hides two days of elapsed time, and the team records both dates.

The end point should reflect verified resolution, not simply a status change, and closing and reopening a case should not erase history. A fictional support agent who closes a dispute because it was assigned to billing has not resolved it, so the report should not reset its age at transfer and the original issue identifier should be kept.

Age buckets make a long list easier to scan, for example new, moderately old and overdue, with boundaries that depend on the process, since a one-day safety issue can be urgent while a week-old routine query is not. Business days and calendar days can produce different numbers, and pause rules may matter when waiting for a customer or regulator.

A fictional team awaiting a supplier document for five days keeps the case visible even if an internal SLA (service level agreement, the promised response time) timer is paused, logs the reason, and reports both total elapsed and active internal time if useful. An ageing report should show case ID, owner, category, open date, current status, last action and next step, because an old case without an owner needs attention and a high count alone does not explain why.

A fictional manager sees twelve aged invoice exceptions, eight of which await one supplier's corrected tax document, and resolves that bottleneck instead of chasing each analyst. Accounts-payable tools group unpaid invoices into ageing bands, which is related but not identical, since an invoice can be old without an unresolved process error, as with a fictional invoice that is overdue for payment but correctly approved and belongs in payables ageing, while another has a new duplicate-charge dispute.

Case-management systems can set time-based service targets and escalation rules that should reflect customer or operational impact, but automation does not decide whether the underlying issue is truly fixed. A fictional delivery exception crossing an at-risk threshold alerts a supervisor who assigns a next action, and the alert itself is not resolution.

Sort by severity as well as age with a visible priority field and clear rubric, since a critical case opened this morning, like a fictional product safety exception only two hours old, may outrank a minor issue from last month. Analyse why cases age, whether from missing data, unclear ownership, external dependencies or repeated rework, so the dashboard guides process changes rather than pressure to close tickets; a fictional billing team finds cases bouncing between sales and finance and sets a single accountable owner and decision path.

Backlog size and age distribution reveal different issues, and averages can mislead when old outliers linger, so use median and percentile ages plus buckets and state whether the calculation covers open or closed cases, as a fictional report showing average closure time had fallen only because it excluded still-open cases. Some exceptions need legal or specialist input and may justifiably age if they are updated and owned, duplicates or missing timestamps can make an old issue look young, and exception ageing is most useful when the clock, owner, severity and next step are all trustworthy.