Escalation Tracker

What this tool does

CM8-248 tracks escalations between the tiers of a daily management system. You record what was raised, by whom, from which tier to which, what production impact it was having, when a response was due and when one arrived, when it had to be resolved by and when it was. The tool then works out response and resolution times, flags the escalations that have passed their response date without an answer, and prints a report you can put in front of the next tier meeting.

It is deliberately narrow. This is not a general list of problems: it is the record of the handful that had to cross a level of the organisation because the level below could not settle them. Everything runs inside this single file — no account, no upload, no network request of any kind.

The tier structure

Tiered daily management is a chain of short, fixed-time meetings that starts at the machine and finishes in the boardroom, each one feeding the next on the same morning. Tier 1 is the cell or team: the operators and their leader, five to ten minutes at the board at the start of shift, looking at yesterday's output, today's plan and anything in the way. Tier 2 is the area or shift: the cell leaders and their area manager, half an hour later, taking what Tier 1 could not close plus a view across several cells. Tier 3 is the plant: area managers with the plant manager and the support functions — engineering, quality, planning, procurement, human resources — where cross-functional decisions and plant-level resources live. Tier 4 is site leadership or the group above it, usually meeting once a day or a few times a week, where capital, headcount, customer commitments and anything with a legal or reputational edge are decided. The times are fixed and published, and the gap between them is short — that cadence is what makes an escalation useful rather than a delay. If Tier 1 meets at 07:00 and Tier 3 at 09:00, a problem found at the start of shift can have a plant-level decision before mid-morning.

When to escalate

There is one test, and it has three parts. Escalate when you cannot resolve the problem with your own authority, your own resources or your own information. You cannot approve the spend. You do not have the person, the part or the machine. You do not know whether the deviation is acceptable, and the people who do sit somewhere else.

That test is deliberately narrow, and it excludes the most common reason people actually escalate: because they are annoyed, or because they want it on record that they said something. Escalating because you are frustrated moves the frustration up a level; it does not move the problem. If you have the authority, the resources and the information, the escalation is not an escalation — it is a task you have not done yet.

The test also cuts the other way. If you genuinely cannot fix it, escalate immediately, not at the end of the shift and not after one more attempt. The cost of an hour lost while somebody tries again out of pride is real, and it is usually larger than the embarrassment they were avoiding.

An escalation is a request for a decision, not a complaint

This is the cultural point that makes or breaks the whole system, and no amount of tracking software will substitute for it. An escalation that says "the maintenance department is useless and we have been down for two hours" gives the receiving tier nothing to act on except a grievance. An escalation that says "the drive motor is burnt out, we have checked the contactor and the overload, there is no spare on site, the maker quotes four days, and we need either authority to hire one in today or a decision to move the build to line 3" gives them a decision they can take in ninety seconds.

The difference is not politeness. It is that the second version has done the thinking and left exactly one thing — the choice that requires authority the raiser does not have — for the person receiving it. Teams that learn to escalate this way find their escalations answered quickly, which teaches them to escalate again. Teams whose escalations arrive as complaints find them ignored, which teaches them to stop escalating and start hiding problems instead. That is how a tier system dies: not with a decision to abandon it, but with everyone quietly agreeing that raising things is a waste of breath.

Two habits keep it on the right side. First, the receiving tier should never punish the raiser for the content of an escalation — the only thing worth criticising is escalating too late. Second, every escalation gets an answer, even when the answer is "we are not doing anything about that, and here is why". Silence is the one response that guarantees the next problem stays where it is.

Response and resolution

The tracker keeps two service levels because they measure different promises. The response is the receiving tier saying "I have it, here is who owns it and here is the plan". The resolution is the problem actually going away.

Response matters more, and it is the one to hold people to. A fast response with a slow fix is a team that knows what is happening and has made a choice about it. A slow response with a fast fix is luck. And a slow response with no fix is how an organisation discovers, three weeks later, that the line has been running short the whole time and nobody upstairs knew. Where tiers meet daily, one day is the usual response target: raised at the Tier 1 board this morning, answered by the Tier 2 board tomorrow at the latest. Set both targets on the Settings tab; the response-performance tile and the breach flag both key off them.

Note what response performance does not include: escalations nobody has responded to yet are excluded from the percentage entirely, because they have no response time to measure. Read it alongside the breaching now tile, which counts exactly those — the ones past their response date with silence against them. A high response percentage and a growing breach count means people are answering the easy ones promptly and letting the hard ones rot.

What a good escalation contains

• The impact, in production terms — stopped, degraded, at risk, or no production impact. This is what sorts the receiving tier's morning, so it has to be honest in both directions. Calling a paperwork query "line stopped" to get attention works exactly once.
• What you already tried — the checks you made, who you called, what you ruled out. This stops the receiving tier repeating your last hour, and it is the evidence that the escalation passed the authority-resources-information test.
• What you need — the specific decision, person, part or budget. Not "help", not "urgent attention". If you cannot name what you need, spend another five minutes before you escalate.
• A named person at the receiving tier. "Escalated to maintenance" is escalated to nobody. One name, recorded, so the response has an owner.

De-escalation is a good outcome

Sometimes the receiving tier looks at an escalation and hands it straight back — not out of unhelpfulness, but because the lower tier turns out to have had the authority or the capability all along, and simply had not used it. The sample register contains one: a press cycling slowly, escalated for a maintenance engineer, solved in twenty minutes by the shift technician changing a blocked air filter.

Record those as de-escalated rather than resolved. Two reasons. First, they are not a failure of the raiser and should not be counted as a resolution the upper tier achieved. Second, a pattern of de-escalations in one area is one of the most useful signals in the whole tracker: it says that team is escalating things it could handle, which is a training and confidence problem, and a cheap one to fix. A tier system with zero de-escalations is usually a tier system where handing something back is treated as a rebuke.

Reading the trend honestly

The escalations-per-month chart is the one most likely to be misread, because both directions are ambiguous. A rising line can mean the lower tiers are losing the capability to solve their own problems — or that people have started trusting the system and recording escalations they used to handle by corridor conversation. A falling line can mean the tiers are genuinely getting stronger — or that people have stopped bothering because the last three escalations went unanswered.

The chart cannot tell you which. Only asking can. Look at the response-performance figure and the breach count alongside it: a falling escalation count with strong response performance is probably real improvement, while a falling count with a poor response record is almost certainly resignation.

The Tier 3+ figure

The tile showing the share of escalations that reached Tier 3 or above is a capability signal, not a workload measure. In a healthy plant most problems are settled at Tier 1 and Tier 2, because that is where the knowledge is and the response is fastest. When a large share climbs to plant level or beyond, ask why: is the spend limit at area level set so low that routine repairs need a plant decision? Is there no engineering cover on shift? Are area managers not allowed to move labour between cells? Each of those is a delegation problem with a specific fix, and each of them is cheaper to fix than to keep escalating around.

The stacked chart breaks the same figure down by category. A tall Tier 3 bar that is almost all "cost" says something quite different from one that is almost all "quality" — the first is about authority limits, the second about where technical decision-making sits.

Where this sits alongside your other records

This tracker is about the movement of a problem between tiers, and nothing else. The general record of project or operational problems — everything raised, whether or not it ever crossed a tier, with severity, priority and a fix owner — belongs in an issue log, which is a separate tool and a separate discipline. The day-by-day visual record of safety, quality, cost, delivery and people performance that the tier meetings actually stand in front of is the SQCDP board. Use all three together: the board shows the day went red, the issue log holds the detail of the problem, and this tracker records that it had to go up a level and how long the level above took to answer.

FAQ

Should every problem be escalated so it is on the record? No. If it is fixed at the tier where it was found, it is not an escalation and recording it here adds noise. Log it wherever you log problems, and keep this register for the ones that had to cross a level.

Can an escalation skip a tier? Yes, and sometimes it must — a serious safety matter should go straight to whoever can act, regardless of the structure. Record the tiers honestly when it happens; a pattern of skipped tiers is worth a conversation about whether the middle tier is adding anything.

What if the escalation is answered but the answer is "no"? That is a resolution. Record the decision and the reason in the resolution field and close it. An answered "no" is enormously better than silence, and the record of it stops the same request coming back every fortnight.

Why are response and resolution measured in whole days? Because that is what people can record reliably at a board. If your tiers work to hours, put the clock time in the time field and read the day counts as a coarse measure; the tool will not pretend to a precision the data does not have.

How many escalations should we expect? There is no right number, and comparing between plants is meaningless because the recording thresholds differ. What matters is your own trend, your response performance and how far up the escalations travel.

Saving your work

Escalations, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work. Reset asks twice, then erases everything this tool has stored. There is no undo. Escalations name individuals and sometimes record conduct and absence, so treat exports as confidential.

Accuracy & disclaimer

The arithmetic here is subtraction between dates, and the tool does it faithfully. Everything that matters sits underneath it. This tracker measures the escalations that were written down; the ones solved by a quiet phone call between two supervisors never appear, and that is usually a good thing rather than a gap to close. Response and resolution figures cannot tell whether the response was any use, whether the fix held, or whether the impact recorded was honest.

Read the numbers as a description of how the tier system behaves, not as a score for the people in it. The moment escalation counts become a performance measure for a team, the counts stop being true — and you lose the only early warning you had. This is an internal record-keeping and prioritisation aid, not management advice and not a compliance record.