Recurrence and Escalation Tracker: See the Improvement Slipping Before the Numbers Do

The Recurrence and Escalation Tracker does one job. In the product's own words, it exists to track recurring issues and their escalation path to prevent repeat problems and drive resolution.

It belongs in Sustain, the last phase of RDMAICS. By the time you reach Sustain, the control plan is signed, the team has moved on, and the project page is closed. What remains is the quiet question nobody asks out loud: is the improvement still holding?

Control charts tell you when a metric drifts. They do not tell you that the same issue has been raised three times by three different people and that it has now reached a director. That is the gap this tool fills. Use it in the first six to twelve months after handover, when the original team is no longer in the room and goodwill is doing more work than the control plan is.

Reach for it at your monthly or fortnightly process review. Open it, add anything new, and look at two things: how often issues are coming back, and how high they are climbing.

Everything in this guide uses the sample data built into the tool. The case is fictional. It is there so you can see the mechanics without having to load your own data first.

The scenario is an accounts payable process that has been through an improvement cycle. Invoice capture was automated, approval routing was tightened, and a duplicate payment check was added. The project closed. Then the issues started coming back.

Four issues are on the register. Approval delay over twenty four hours. OCR template drift. Duplicate payment flag. Master data mismatch. Each has a recurrence count, a first seen date, a last seen date, an escalation level, an owner and a status.

Read as a set, these four issues describe a process that is not broken but is not holding either. That distinction is the whole point of the Sustain phase.

The input table is deliberately narrow. Eight columns, three of them mandatory. Issue, Owner and Status carry an asterisk. The rest are optional but you lose most of the value if you leave them blank.

Enter one row per distinct issue, not one row per occurrence. This is the mistake most teams make on the first pass. The recurrence count column is what carries occurrence volume. In the sample, Approval delay over twenty four hours has a recurrence count of three. That is one row representing three events, not three rows.

First seen and last seen are the dates that give the count its meaning. Approval delay was first seen on 3 June 2025 and last seen on 18 June 2025. Master data mismatch was first seen on 8 June 2025 and last seen on 22 June 2025, the latest date on the register.

Escalation level records how far the issue has travelled, not how far you think it should travel. The sample uses Supervisor, Manager and Director. Owner records the person or role accountable for resolution now, which may not be the person who raised it. In the sample, owners range from an AP Clerk to a Process Owner.

The tool rolls the table into four headline figures. Issues: four. Recurrences recorded: eight. Open or escalated: three of four. Highest escalation level: Director.

Take those in order. Four issues is the size of your register. Eight recurrences is the amount of rework and interruption those four issues have generated, which is double the issue count. That ratio matters more than either number alone. A register of four issues that have each happened once is a list of incidents. A register of four issues that have happened eight times between them is a pattern.

Three of four open or escalated is the resolution figure. Only one issue, OCR template drift, is closed. It also happens to be the only issue with a recurrence count of one, and the only one where first seen and last seen are the same date, 10 June 2025. One occurrence, caught at Supervisor level, closed. That is what a working control plan looks like.

Highest escalation level of Director is the one figure you should never skim. It is set by Master data mismatch, which is marked Escalated and owned by the Process Owner. An issue has left the process and is now a management matter.

Below the headline figures, the tool lists each issue as a card with its own counts and dates. The tool also offers an AI review that explains the result in plain language if you want a second read before you take it to a review meeting.

Three signals sit in this sample data, and all three are visible without any extra analysis.

The first is recurrence count climbing above one. OCR template drift sits at one and is closed. Duplicate payment flag and Master data mismatch sit at two. Approval delay sits at three. A count of one with a closed status is a healthy system absorbing a fault. A count of three with an open status is a control that is not doing its job.

The second is the gap between first seen and last seen. Approval delay has been recurring across fifteen days, from 3 June to 18 June. Duplicate payment flag spans 5 June to 20 June. Master data mismatch spans 8 June to 22 June. When last seen keeps moving forward and status stays Open, nothing has been fixed. Someone has been handling each occurrence instead.

The third is escalation level rising while recurrence count also rises. Master data mismatch has only two recurrences but has reached Director. That combination says the issue is not high volume, it is high consequence, and the process no longer has the authority to resolve it on its own. Compare that with Approval delay, which has the highest recurrence count of three but has stopped at Manager level.

The register does not make decisions. It makes three decisions easier to argue for.

Reopen or do not reopen. Approval delay over twenty four hours has recurred three times and is still open at Manager level. On this register it is the strongest candidate for reopening a Define or Analyse step, because repeated occurrence with an unchanged status suggests the root cause was never removed.

Change the owner. Duplicate payment flag is owned by an AP Clerk and has recurred twice, with the last occurrence on 20 June 2025. Ownership at clerk level with recurrence at two is worth testing. If resolution requires a system change, the owner cannot deliver it, and the issue will keep returning regardless of effort.

Accept the escalation. Master data mismatch is already at Director level with the Process Owner as the accountable party. The decision here is not to escalate further. It is to put a date on resolution and bring it back to the next review.

Close with confidence. OCR template drift is closed on a single occurrence. Leave it on the register anyway. If it reappears, the first seen date of 10 June 2025 gives you history that a fresh entry would lose.

The most common error is logging occurrences as separate rows. Do that and your issue count inflates while your recurrence counts all stay at one. The register then looks like a stream of unrelated incidents and the pattern disappears.

The second is leaving status stale. Status is the figure that drives three of four open or escalated. If nobody updates it, the register tells you about the past and nothing else. Set a review cadence and hold to it.

The third is treating escalation level as a plan rather than a record. Entering Director because an issue feels serious, before it has actually gone to a director, breaks the highest escalation level figure. That figure is only useful if it reflects what has happened.

The fourth is abandoning the register once the counts look bad. A register with eight recurrences across four issues is doing exactly what it should. Deleting rows to make the summary look calmer removes the only early warning you have.

This is a register and a summary. It is not a diagnostic. It will not tell you why Approval delay over twenty four hours has recurred three times. It records that it has.

It does not weight issues by cost, risk or customer impact. On this register, Master data mismatch at Director level and Approval delay at Manager level are both just rows. The tool will not rank them for you. You decide which of three open issues matters most, and the tracker gives you the recurrence counts and dates to defend that call.

It does not detect issues. Nothing arrives on this register unless somebody puts it there. A register showing four issues may mean four issues exist, or it may mean four issues were reported and others were absorbed quietly. The tool cannot distinguish between those.

It also has no sense of time elapsed since the last occurrence. Last seen dates in this sample range to 22 June 2025. The tool reports those dates but does not tell you whether an issue has gone quiet or has simply stopped being logged. You bring that judgement.

Used honestly, the tracker gives you a short, factual page you can put in front of a process owner months after handover. Four issues. Eight recurrences. Three of four still open or escalated. One at Director level. That is enough to start the right conversation, which is all a Sustain tool needs to do.