PROCESS

Here is How to Build

Design

Exceptions

The honest touch-point

Some cases cannot be pre-approved, because their answer is not knowable in advance or cannot be safely fixed in writing. For these, the way forward is not a guide but escalation: the case is carried beyond the Performer to someone who can handle it. This is not a failure of the design. It is what honesty requires when a case genuinely needs what the Performer does not have. Better an honest escalation than a false guide that pretends a certainty the case lacks. The Performer, meeting a case they cannot resolve alone, is not stranded; they are carried, by a designed route, to whoever can.

Why can the Performer not resolve it alone? The reasons fall into two kinds, and naming them tells the designer where the case must go. The first kind is authority to decide. The Performer could act, but should not make the call alone, because the case turns on a Financial decision, how much to spend or concede, a Goodwill decision, how much the customer relationship and the brand's standing are worth protecting, or a Regulatory one, where a legal or compliance obligation dictates what must be done. Financial and Goodwill are trades to be weighed; Regulatory is usually not a trade at all but an obligation to meet, carrying the highest accountability and often reaching outside the organisation altogether. The second kind is capability to act. Here the Performer cannot execute, not for want of authority but for want of means: either the competence to resolve the case, a technical or financial expertise they do not hold, or the tool access or rights to perform the action, the permission they lack even when they know exactly what to do.

These are the main reasons, not the only ones, and a single case may carry more than one at once, needing both an authority it lacks and a capability it lacks. What matters is that the designer, looking at a case that cannot be pre-approved, can name what it needs, an authority or a capability, and which, because that is what decides where it goes. Escalation is not a vague "send it up." It is the precise act of carrying a case to whoever can supply the exact thing the Performer is missing.

The highest possible standard is to treat escalation as the honest way forward for cases that cannot be safely pre-approved, naming precisely what each case needs, an authority to decide (Financial, Goodwill, or Regulatory) or a capability to act (the competence or the access to resolve it), so it can be carried to whoever can supply that and no Performer is left to improvise.

Key Takeaway: Some cases cannot be pre-approved, and for them the way forward is escalation, carrying the case beyond the Performer to whoever can handle it. This is honest, not failure: better an honest escalation than a false guide. The reasons fall into two kinds: authority to decide, when the case turns on a Financial, Goodwill, or Regulatory matter the Performer should not decide alone, and capability to act, when the Performer lacks the competence or the access to resolve it. A case may carry more than one at once. Naming what the case needs is what decides where it goes.

Escalation is the honest way forward when the Performer lacks an authority to decide, Financial, Goodwill, or Regulatory, or a capability to act.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 6: Escalate · Section: The honest touch-point

MarvinPro | June 2026

marvinpro.com

Routing, not a ladder

It is tempting to picture escalation as a ladder, up one rung at a time to the top. That picture is too simple, and following it wastes time and strands cases at the wrong place. Escalation is routing, not climbing. The single rule is this: carry the case to whoever can supply what it is missing, the authority or the capability, wherever they are, and if that place does not resolve it, route it on to the next that can. The direction, up, sideways, or outside, follows from where the missing thing is, not from a fixed order of rungs.

The possible destinations are more varied than a ladder allows. A case needing a decision may go to a team lead; one needing technical work may go sideways to a specialist tier; one needing both may go to both at once. Organisations wire this differently, in one, a lead may hold the Financial decisions while a specialist tier holds the technical work and sometimes the Financial too. The top of the internal path is whoever holds final authority for the area, and who that is depends on the organisation's size. In a small, young organisation it is often the designer, who is also the Owner, and the path is short. In a large, settled one it is a senior role, a department manager or the area's Owner, distinct from the designer, and the path is taller. And the top of the internal path is not always the end of it. Some cases exceed what the organisation can resolve alone, a fix that depends on a vendor's software, a matter that turns on a partner's agreement, a Regulatory obligation that needs legal counsel or the regulator itself, and then the case is carried outside, to an external party. Sometimes the very first move is outward, when the case plainly belongs to the vendor from the start, and if that external party does not resolve it as they should, the case comes back inward, to the lead or the specialist tier, to be chased, worked around, or handled another way. The route bends to the case.

Two things also change the shape of the internal path, and they are worth keeping apart. One is the life of the design. In the brief hypercare just after go-live, the path is short and direct, the designer close at hand, feedback fast; once the design settles, the designer withdraws toward the top and the standing tiers carry most of the load, so the path lengthens. The other is the maturity of the organisation, which sets how tall the path is to begin with, flat where a few people hold every role, layered where the roles have separated across many levels. Through all of these shapes, one thing holds: most cases are resolved low, at the first tier that can handle them, and only the few that need more climb further. The top is a ceiling, reached rarely, not a first stop.

The highest possible standard is to route each case to whoever can supply what it needs, by the shortest path that reaches them, inside the organisation or beyond it, in whatever order the case requires, re-routing when a destination does not resolve it, so that most cases are handled at the lowest level that can and only the genuinely hard few reach the top or pass outside.

Key Takeaway: Escalation is routing, not a ladder: carry the case to whoever can supply what it is missing, wherever they are, and route it on if they do not resolve it. Destinations vary, a lead for a decision, a specialist tier for technical work, both at once, and organisations wire the roles differently. The internal ceiling is whoever holds final authority for the area, often the designer-Owner in a small organisation, a department manager or Owner in a large one. Some cases go outside, to a vendor, partner, or regulator, and external can even be the first stop, looping back inward if it is not resolved. Most cases are handled low; the top is reached rarely.

Escalation routes the case to whoever can supply what it needs, inside or outside, in whatever order, re-routing on failure; most cases resolve low.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 6: Escalate · Section: Routing, not a ladder

MarvinPro | June 2026

marvinpro.com

The designed path

Given how many shapes escalation can take, one conclusion follows above all: the escalation path must be designed. A Performer who meets a case they cannot resolve cannot be expected to work out, under pressure, whether it needs a Financial or a Regulatory decision, whether it goes to the lead or the specialist tier, whether it belongs inside or with the vendor, and where it goes next if the first place fails. If the path is left undesigned, they guess. Cases land in the wrong place, time is lost, and the promise that no Performer is ever stranded quietly breaks, because a route no one designed is a route no one can follow. So the designer designs the escalation path in advance: for the kinds of case that will arise, where each goes, in what order, to whom, and where it re-routes if a destination does not deliver.

And a designed path, like a pre-approved answer, is agreed and written before it is needed. It is signed off by those who hold the relevant authority, so that when a case is routed to a lead, an Owner, or an external party, that routing is sanctioned in advance and not invented in the moment. And it is documented in the instructions the Performer follows, so the Performer does not improvise where a case goes; they look it up and route it. This is the quiet likeness between escalation and pre-approval. In both, the way forward is designed, written, and pre-cleared. The difference is only in what is written. For a pre-approved case, what is written is the answer. For an escalated case, what is written is the route, where the case goes to be answered. The Performer meeting a case that needs a live decision still has a written way forward; it is not the answer, but it is the path to whoever holds it, and that is enough to keep them from ever being stranded.

There is one more reason the designed path matters, and it looks past this discipline to the next. Every escalation is a signal. A case that must be escalated is a case the design did not yet cover, and a case that must be escalated often is a case whose answer, once known, belongs lower down, written into a guide, or lower still, folded into the rules. So the designer reads the record of escalations not as the system working but as a list of answers waiting to be moved down, and over time drives them there, until fewer and fewer cases need to climb at all. The deeper reading of what escalations reveal about the whole system belongs to another domain; here it is enough that a well-designed path not only carries today's hard cases but shows the designer exactly which ones to design away next.

The highest possible standard is to design the escalation path in advance, agreed and signed off by those with the relevant authority and documented in the instructions the Performer follows, so that no case is routed by guesswork, every Performer has a written way forward even for a live decision, and the record of escalations becomes the designer's guide to what must next be pushed down.

Key Takeaway: Because escalation can take so many shapes, the path must be designed in advance, agreed and signed off by those with the relevant authority, and documented in the instructions the Performer follows, so no one routes by guesswork. Escalation is like pre-approval in being designed, written, and pre-cleared; the difference is only what is written, for pre-approval the answer, for escalation the route to whoever holds it. So the Performer always has a written way forward, the path if not the answer. And every escalation is a signal, the designer reads the record as the list of cases to push down next.

Because escalation can take many shapes, the path must be designed, signed off, and documented, so the Performer follows a written route and is never stranded.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 6: Escalate · Section: The designed path

MarvinPro | June 2026

marvinpro.com

A real example

Return to the software company and the unknown issue, the case that could not be pre-approved because its answer was not yet known. When a Performer met it, they escalated, and the reason was capability: the trouble needed a technical competence the Performer did not hold. The case was carried to the Owner, who brought in the Technical Team that could work it. Most such cases were handled there and never rose higher. But when the trouble turned out to lie in a supplier's software, the Technical Team escalated again, outward, to the vendor, and had the vendor been slow to fix it, the case would have come back inward, to hold the customer with shaped updates and a work-around while the vendor was pressed. The route bent to what the case needed, first to a specialist, then outside, and back if the outside did not deliver.

Other cases escalated for other reasons. A customer asking for something that touched a promise escalated for authority, a Financial and Goodwill decision only the Owner could make, weighing what to concede against what the relationship was worth. A case that touched how customer data or communication was handled escalated for a Regulatory reason, rising high and, where the obligation was serious, reaching outside to legal counsel, because no lead and no Performer could decide alone what the law required. Each case went to whoever could supply what it needed, a specialist's competence, an Owner's authority over a Financial or Goodwill trade, a lawyer's reading of a Regulatory duty, and most were resolved well below the top.

None of this was improvised. Before any of it went live, the designer had drawn the escalation path, which cases went to the Technical Team, which to the Owner, which straight to the vendor, which to legal, and where each turned next if the first place did not resolve it. It was signed off by those who held the authority over each route, and written into the instructions the Performer followed. So the Performer meeting an unknown issue did not stand wondering where to send it; they read the path and routed it. And the designer, watching the escalations mount, saw which kinds recurred, and wrote their answers down as they became known, dropping them from escalation to pre-approved, so that each month a few more cases stopped needing to climb. The path carried the hard cases today and showed which to design away tomorrow.

The route was designed before it was needed, so the Performer followed it rather than guessed, and the escalations showed the designer what to push down next.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 6: Escalate · A real example

MarvinPro | June 2026

marvinpro.com

Escalate

Some cases cannot be pre-approved, because their answer is not knowable in advance or cannot be safely written. For these the way forward is escalation, carrying the case beyond the Performer to whoever can handle it. This is honest, not failure: better an honest escalation than a false guide. The Performer cannot resolve the case alone for one of two kinds of reason. Either it needs an authority to decide, over a Financial matter, how much to spend or concede, a Goodwill matter, what the relationship and the brand are worth, or a Regulatory one, an obligation the law dictates. Or it needs a capability to act, the competence to resolve it, technical or financial, or the tool access or rights to execute it. A case may carry more than one at once, and naming what it needs is what decides where it goes.

Escalation is routing, not a ladder. The rule is to carry the case to whoever can supply what it is missing, wherever they are, and route it on if they do not resolve it. A case may go to a lead for a decision, sideways to a specialist tier for the work, or to both at once; organisations wire the roles differently. The internal ceiling is whoever holds final authority for the area, often the designer, who is also the Owner, in a small organisation, and a department manager or the Owner, distinct from the designer, in a large one. Some cases pass outside, to a vendor, a partner, or a regulator, and external can even be the first stop, looping back inward if it is not resolved. The path's shape shifts too: short and direct in the brief hypercare when the designer is close, longer once the design settles, and taller in a mature organisation than a young one. Through all of it, most cases are resolved low, and the top is reached rarely.

Because escalation can take so many shapes, the path must be designed in advance, not worked out under pressure. The designer decides, for the cases that will arise, where each goes, in what order, and where it re-routes if a place does not deliver; has it agreed and signed off by those who hold the relevant authority; and documents it in the instructions the Performer follows. This is the likeness between escalation and pre-approval: both are designed, written, and pre-cleared, and the only difference is what is written, for pre-approval the answer, for escalation the route to whoever holds it. So the Performer meeting a live-decision case still has a written way forward, the path if not the answer, and is never left to guess.

And every escalation is a signal. A case that escalates is one the design did not yet cover, and one that escalates often is an answer waiting to be written down and moved lower, to a guide, or lower still, into the rules. So the designer reads the record of escalations as the list of what to push down next, and over time drives them there, until fewer cases need to climb at all. So the discipline is this: give the Performer an honest route when no written answer fits, route each case to whoever can supply what it needs, design that path, sign it off, and document it, and then read the escalations it produces as the map of what to design away, so escalation carries the hard cases today and grows quieter tomorrow.

Escalation is the honest, designed route to whoever can supply what a case needs, followed not guessed, and read as the map of what to push down next.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 6: Escalate · Chapter Outcome

MarvinPro | June 2026

marvinpro.com

Think Simple.