PROCESS

Here is How to Build

Design

Principles

What supporting is

A live process is not left to itself. From the moment it goes live, it is tended, and that tending is supporting. Support begins where running begins, at go-live, and unlike the other disciplines, it does not end when the change beds in. It continues for the whole life of the process, until the process is made redundant or the organisation closes. Of all the disciplines, support is the longest-lived.

Support has two layers, and they differ in how close and how fast they are. The first is hypercare, the intense, direct support right after go-live, when the change is new and the small things real use reveals are caught and fixed quickly. The second is normal support, the steady support that follows, running through a set path for as long as the process lives. Hypercare is brief and close; normal support is long and standing. The first settles the change in; the second keeps it tended thereafter.

These two layers mirror running, and for good reason. Running had a heightened moment at go-live that settled into steady operation; supporting has a heightened layer at go-live, hypercare, that settles into steady support. The two disciplines begin together, at go-live, and run alongside each other: running carries the change live and keeps it going, while supporting tends what the running reveals. Where they are closest is hypercare, the first days, when the change is newest and needs the most care. After that, both ease into their steady forms.

The highest possible standard is to understand supporting as the tending of a live process from go-live for the whole of its life, in two layers, the intense, direct hypercare that settles the change in, and the steady, standing normal support that keeps it tended until the process ends.

Key Takeaway: A live process is tended, not left to itself, and that tending is supporting. Support begins at go-live and, unlike the other disciplines, lasts the whole life of the process, until it is made redundant or the organisation closes, making it the longest-lived discipline. It has two layers: hypercare, the intense, direct support right after go-live that settles the change in, and normal support, the steady, standing support that follows for as long as the process lives.

Supporting is the tending of a live process, from the moment it runs until the day it no longer does.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 7: Support · Section: What supporting is

MarvinPro | June 2026

marvinpro.com

Hypercare: the direct connection

Hypercare is the close support of the first days. Its defining feature is a direct connection between those doing the work and those responsible for each part of it, so that whatever surfaces can be raised and fixed at once. This connection can be physical, the leader on-site with the team, or it can be a channel made for the purpose, a chat group that holds the team and the people who own each deliverable together in one place. Either way, the point is the same: closeness, so that nothing waits.

Through this connection comes everything that real use reveals, and it reveals what no preparation could fully foresee. A step in a system is named one way in the tool and another in the documentation, and people are confused. A step needs an option it was not given. Someone has access to everything but one step, and is stuck there. A guide is harder to follow than it looked, or a template, the standard wording staff use so that everyone communicates the same way, reads awkwardly, or carries an error, or is wrongly translated in one of the languages. A partner is unsure of something in the new flow. None of these is large. They are the small, unforeseeable residue that only live use exposes, and they are small precisely because the complex things were caught in preparing. Hypercare is not where big problems appear. It is where the last small ones are found and fixed.

And they are fixed at once. Because the people responsible for each part are directly reachable, a confusing label is corrected, a missing option added, a permission granted, a template reworded or retranslated, a guide clarified, then and there. The documentation is alive in these days: as questions come, the guides, the templates, and the answers to common questions are updated fast, so that the next person to ask finds the answer already there. This is where having documentation that can be changed quickly proves its worth, the more it is fixed now, the less is asked later. The direct connection turns the flood of small frictions into a quickly improving process.

The highest possible standard is to support the first days through a direct connection between those doing the work and those responsible for each part, so that the small things real use reveals, across systems, access, guides, templates, and partners, are caught and fixed at once, and the documentation is improved fast as the questions come.

Key Takeaway: Hypercare is the close support of the first days, built on a direct connection, on-site or a chat group, between those doing the work and those who own each part, so whatever surfaces is fixed at once. What surfaces is small, a mislabelled step, a missing option, a permission gap, an awkward or mistranslated template, a partner's uncertainty, because the complex things were caught in preparing. Fixes happen on the spot, and the documentation is updated fast as questions come, so the next person finds the answer already there.

Hypercare is closeness, so that nothing waits. The small things real use reveals are caught and fixed at once.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 7: Support · Section: Hypercare: the direct connection

MarvinPro | June 2026

marvinpro.com

How long hypercare lasts

Hypercare does not have a fixed length. It lasts as long as the process needs to settle, and the leader's task is to judge that. A common default is around two weeks, but it is only a default. What truly sets the length is how long it takes for enough real cases to run that the small issues have surfaced and been fixed.

That depends on the process, and it can pull in either direction. A low-volume process needs longer, not shorter. When few cases come through, issues surface slowly, and you must stay close longer to catch them. A new process is often low-volume, it is one of many a person performs, so this is common and not strange. At the other extreme, a high-volume process worked by many people also needs longer, but for the opposite reason. With many people, there are many questions, the same uncertainty asked a dozen different ways, and it takes time to work through them all. Here the way to keep up is to update the live documentation fast, turning each question into an answer the next person will find, so the questions subside as the guidance improves. Between these extremes sits the ordinary case, and the two-week default.

There is also a reason to keep hypercare no longer than it must be. The person running it, when that person is the owner of the area, is a costly and stretched resource, carrying vendor meetings, stakeholders, reporting, and other changes in flight, and is needed back among them and on the next thing. So you stay close long enough to settle the process, and then you step away. It is different when the change is run by someone dedicated to it, a project resource assigned to that process alone may stay through the whole of hypercare, a month or two, until it fully runs, because they have nowhere else they must be. Either way, the owner brings one advantage to these days: having designed the process, they recognise a problem the moment it is described, and place it against the design at once. And each time, they learn. A class of issue found in one go-live is designed out of the next, so preparing improves with every change, though every change still brings its own new small things.

The highest possible standard is to keep hypercare as long as the process needs to settle and no longer, judging the length by how fast real cases surface the issues, extending it for low volume or for high volume with many people, and releasing a costly owner back to their work once the process is settled.

Key Takeaway: Hypercare lasts as long as the process needs to settle, with around two weeks as a default. Low volume extends it, because issues surface slowly; high volume with many people extends it too, because of the many and varied questions, met by updating the live documentation fast. It is kept no longer than it must be, because an owner is costly and needed elsewhere, though a dedicated project resource may stay a month or two. The owner diagnoses fast, having designed the process, and learns from each go-live.

Stay close as long as the process needs to settle, and no longer. The costly owner is needed elsewhere, and learns something from every go-live.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 7: Support · Section: How long hypercare lasts

MarvinPro | June 2026

marvinpro.com

Normal support: the standard path

When the process runs happily and the issues have stopped surfacing, hypercare ends. The end is marked plainly: the direct connection is closed, the chat group shut, the leader no longer on-site. From here, support changes character. It becomes normal support, the steady, standing support that carries the process for the rest of its life.

What changes is the channel, and with it the speed. In hypercare, anything could be raised directly and fixed at once. In normal support, there is no direct line. Issues follow a set escalation path, laid out in advance, that says who is contacted, and in what order, when something cannot be resolved where it arose. The matured documentation, the guides, templates, and answers perfected during hypercare, now serves as the first resource, and people work from it as it stands. Corrections to it still happen, but they are harder and slower to make than before, because they go through the standard path rather than a direct fix. This is why hypercare matters so much: it is the window when the documentation can be perfected cheaply, before that friction sets in.

A well-made escalation path does more than route problems. It also protects the relationships it runs through. When the path is designed and agreed in advance, including its higher reaches, using it is simply the normal procedure, not an act of going over anyone's head. So when a level does not resolve something and the matter must rise, even to a partner's headquarters, it can rise without damaging the relationship at the level below, because everyone understood from the start that this was how the path worked. The path that is agreed beforehand is the path that can be used cleanly when it is needed.

Through all of this, the measures of the process, its key indicators and service levels, continue to be owned as they always were. They are not a feature of support but of ownership: the team and its managers are accountable for them, and the owner watches them across the area, explaining both the dips and the strengths. A change may move them for a time, and that movement is allowed for and explained by the change. Support sits within this standing ownership, not above it.

The highest possible standard is to hand over from hypercare by closing the direct connection, to run normal support through a set escalation path with the matured documentation as its first resource, and to design that path, and its higher reaches, in advance and by agreement, so that it can be used cleanly without damaging the relationships it runs through.

Key Takeaway: When the process runs happily, hypercare ends, marked by closing the direct connection, and normal support takes over for the life of the process. The channel changes: no direct line, but a set escalation path, with the matured documentation as the first resource and corrections now made through the standard path. A path designed and agreed in advance, including its higher reaches, can be used cleanly, even up to a partner's headquarters, without damaging the relationship below it. The process's measures are owned continuously, as part of ownership, not as a feature of support.

Normal support runs through a set path, not a direct line. A path agreed in advance, all the way up, can be used without damaging the relationships it runs through.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 7: Support · Section: Normal support: the standard path

MarvinPro | June 2026

marvinpro.com

Until the process ends

Support is the discipline that does not finish. The others complete: a process is seen, and the seeing is done; designed, and the design is done; signed, prepared, run. But support, once begun, continues. It runs for as long as the process runs, which is to say until the process is no longer needed, replaced by something better, made redundant, or until the organisation it serves is no longer there.

This is what makes support the longest-lived of the disciplines, and it changes how to hold it. Hypercare is a burst; normal support is a presence, quiet, standing, lasting years. It is not intense, and most days it asks little, the escalation path handles what arises, the documentation answers what it can. But it is always there, the standing assurance that a live process is not abandoned to itself, that there is a way for what goes wrong to be put right, for as long as the process lives.

To support a process to its end is simply to keep tending it, lightly, faithfully, until it is no longer there to tend. A process that is well supported is one a person can rely on, not because nothing ever goes wrong, but because when something does, there is a known way to set it right. That assurance, held steadily over the whole life of the process, is what supporting finally is.

The highest possible standard is to sustain support for the whole life of the process, lightly and faithfully through its long steady years, so that the process is never abandoned to itself and there is always a known way to put right what goes wrong, until the process is no longer there to tend.

Key Takeaway: Support is the discipline that does not finish. The others complete; support continues for as long as the process runs, until it is made redundant or the organisation closes, making it the longest-lived discipline. Normal support is not intense but standing, a quiet presence over years, the assurance that a live process is not abandoned and that what goes wrong has a known way to be put right. To support a process to its end is to keep tending it, lightly and faithfully, until it is no longer there to tend.

Support is the discipline that does not finish. It is the standing assurance that a live process is never left to itself.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 7: Support · Section: Until the process ends

MarvinPro | June 2026

marvinpro.com

The discipline that completes the cycle

With support, the cycle is whole. A process was seen, designed, signed, prepared, run, and is now supported. Each discipline did its part, and support is the one that holds what all the others built, keeping the live process tended so that the work of seeing, designing, signing, preparing, and running endures rather than decays.

There is a quiet symmetry to it. Seeing began against reality, the true picture of what was happening. Support ends against reality too, the live process meeting real use, day after day, and being tended through it. Between them lies the whole arc of building a change: from understanding what is, to designing what should be, to securing it, readying it, running it, and keeping it. Support is where that arc comes to rest, not because the work stops, but because the change has become simply how the work is done, and support is what keeps it so.

And the cycle turns. A supported process runs until a new need is seen, and then it begins again, a new seeing, against the reality the current process now meets. So support does not only complete the cycle; it feeds the next one, because the live process it tends is the reality the next change will be seen against. The end of one arc is the ground of the next.

The highest possible standard is to recognise support as the discipline that completes and preserves the cycle, holding what the others built so the change endures, and to tend the live process knowing it is both the resting place of one arc and the ground on which the next will be seen.

Key Takeaway: With support, the cycle is whole: seen, designed, signed, prepared, run, supported. Support holds what the others built, keeping the live process tended so the work endures. There is a symmetry, seeing began against reality, and support ends against reality, the live process meeting real use and being tended through it. And the cycle turns: the supported process is the reality the next change will be seen against, so support both completes one arc and grounds the next.

Support completes the cycle and holds what the others built. It is also the ground the next change will be seen against.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 7: Support · Section: The discipline that completes the cycle

MarvinPro | June 2026

marvinpro.com

A real example

A team had been handling a particular kind of return for customers, the sending back of property left behind, recovered and returned across borders. They had been doing it informally, without an official process, helped along by a partner who already handled the organisation's standard shipping and was willing to support these returns too. It worked, but it was unofficial. The point came when it needed to be made proper: a real process, with its own accounting, so the costs were tracked and paid correctly. A separate ledger account and order were set up for this one service, while everything else kept to the existing ones, and the process was designed and agreed with the partner and with finance.

The work itself was not hard, but getting the request right was, there were particular requirements to meet, so a checklist was provided for staff to follow, to make sure every step was done. The process went live across all the supported countries at once. Because it touched staff and the partner in every country, the owner supported both, directly, through the early days. The overall alignment was held with the partner's headquarters, but the real incidents happened locally, so the owner supported each local partner office case by case as things came up. This was low-volume work, returns of this kind are occasional, so the close support ran longer than it would for a busy process, because the issues surfaced slowly, a few cases at a time.

What surfaced was small. Some of the standard messages staff used needed rewording, and those corrections were made on request as they came. The checklist and the guidance were refined as real cases tested them. The bigger moment came when some local partner offices did not perform as they should. The issue rose through the path, from the staff, to the partner's local people, to their team leader, and finally to the owner. The owner took it up with the local partner manager directly, but it could not be resolved there. So it rose further, to the partner's headquarters, who then addressed it with that manager, and it was put right. What mattered was that this did not damage the relationship between the owner and the local manager, because rising to headquarters was the agreed, normal procedure, understood by everyone from the start. The path was used exactly as it was built to be.

Once the returns were running smoothly, the close support ended. The direct contact gave way to the standard path: the matured checklist and messages served the staff, and anything that arose followed the escalation route, level by level. The process settled into its quiet, standing life, tended lightly, for as long as it was needed.

The path that is agreed in advance, all the way to the top, is the path that can be used when it is needed, without breaking what it runs through. That is what makes support hold.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 7: Support · A real example

MarvinPro | June 2026

marvinpro.com

Support

Supporting is the tending of a live process, from the moment it goes live until the day it is no longer there. It is the longest-lived of the disciplines, beginning with running and continuing for the whole life of the process, until that process is made redundant or the organisation closes. It comes in two layers: hypercare, the intense, direct support of the first days, and normal support, the steady, standing support that follows.

Hypercare is closeness. Through a direct connection between those doing the work and those responsible for each part, on-site or a channel made for it, the small things real use reveals are caught and fixed at once: a mislabelled step, a missing option, a permission gap, an awkward or mistranslated template, a partner's uncertainty. They are small because preparing caught the complex ones, and they are fixed on the spot, while the documentation is improved fast as the questions come. Hypercare lasts as long as the process needs to settle, around two weeks by default, longer for a low-volume process whose issues surface slowly, or a high-volume one whose many people raise many questions, and no longer than it must, because a costly owner is needed elsewhere, though a dedicated project resource may stay through it.

When the process runs happily, the direct connection is closed, and normal support takes over for the life of the process. The channel changes: no direct line now, but a set escalation path, with the matured documentation as the first resource, and corrections made, more slowly, through the standard path. A path designed and agreed in advance, all the way to its highest reaches, can be used cleanly when it is needed, even up to a partner's headquarters, without damaging the relationships it runs through. Through all of it, the measures of the process are owned as they always were, as part of ownership, not as a feature of support.

You can now support a process for the whole of its life. You hold the first days close, through a direct connection that catches and fixes the small things at once and perfects the documentation while it is easy. You judge how long to stay, by how fast the process settles, and you step away when it has, releasing a costly owner to their other work. You hand over to a standing escalation path, designed and agreed in advance so it can be used without harm, with the matured documentation behind it. And you keep the process tended, lightly and faithfully, until it is no longer there to tend. The process is seen, designed, signed, prepared, run, and now supported. The cycle is whole, and the live process it leaves behind is the reality against which the next change will be seen.

A live process is never left to itself. Hold the first days close, hand over to a path agreed in advance, and tend the process faithfully for as long as it lives. With that, the cycle is whole.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 7: Support · Chapter Outcome

MarvinPro | June 2026

marvinpro.com

Think Simple.