PROCESS

Here is How to Build

Design

The Example

Before the chapters begin, here is the case they return to. One process, met once in full, and then turned, chapter by chapter, so that each thing a rule is made of can be seen in something real. Read it as a story first. The lessons come later.

A company sells software by subscription. Like any such company, it has customers with problems: something does not work, or works wrongly, or has stopped working at all. How the company answers those problems, what it says, to whom, when, and how, is the work this example is about. Not how the software is repaired. That is the engineers' craft, and a different book. This is about the process around the fix: how the trouble is understood, sorted, and communicated, inside the company and out to the customer. Because a company can have the finest engineers alive, and still lose its customers, and sometimes its life, by communicating badly when something goes wrong.

The customer might be a single person on a personal plan, or a business client whose own administrator looks after many users. The difference matters, and the example holds both. With a single person, the company speaks to the one affected. With a business client, it often speaks to the administrator, who stands between the company and their own people, and who helps narrow down what is actually wrong before it ever reaches the company.

When a problem arrives, the first real work is not fixing it. It is sorting it. Is this one customer's trouble, or many? If one, it is handled as a single case, worked through with the customer or the administrator until it is resolved. If the same trouble starts showing up across many customers, and either Support or the system notices the pattern, it is treated as something larger. A recognised industry framework would call the single case an incident and the larger one a problem. This book calls them an issue and an emerging issue. The words matter less than the thinking, and the thinking is the same in any sector and any seat.

A larger issue is one of two kinds: known or unknown. A known issue is one the company has seen before. It already has instructions for handling it and templates for explaining it, and it comes in two forms, one where a solution exists and can be given, and one where the cause is understood but the fix is not ready, so the customer is told that too. Some known issues are large or serious enough to earn their own dedicated templates, written with special care, rather than the general wording. An unknown issue is the new one, the emerging issue, the trouble nobody has met yet. It has no ready template, because you cannot template what you do not yet understand. It is handled by a process built for exactly this: an escalation path that carries it to the people who can work it, and a way of communicating that is shaped as the issue is understood, a little more certain with each update.

And here is the quiet engine of the whole thing. An emerging issue does not stay emerging. As the Technical Team works it and provides the steps to resolve it, the Owner turns those steps into troubleshooting Support can follow, and into templates the customer will receive. At that moment the unknown becomes known. The emerging issue has become a known issue, with its own instructions and its own templates, ready for the next time it appears. So the process does not just resolve trouble. It manufactures its own future rules. Every emerging issue, once solved, leaves behind a permanent piece of process.

Through all of it run the templates, and they are the heart of this example. There are templates for the customer and templates for the Teams inside. They carry the escalation paths and the standard words for each kind of issue. They exist so that good communication does not have to be reinvented, anxiously, in the middle of a crisis, by whoever happens to be there. A good message is built into them in advance: written in the receiver's own language and to their own level, technical for the technical, plain for the plain; complete enough to satisfy, but not so heavy with detail that it worries the reader for no reason; carrying the etiquette and the small political care that lets a message land well in the place it lands; and always, always, ending with the next step, even when the next step is simply to wait.

Making such templates is itself a process, with its own rules. A Writing team drafts them. They are translated into each language the customers read. Each is signed off before it can be used, by the people responsible for the words, for what is promised, and for the process: Communication, the Offer Owner, and the Designer. Once approved, they are loaded into the systems, so the right one can be chosen by a Performer, or sent by the system itself, at the moment it is needed. And all of it must be ready before the Performers are trained, so they can be trained on the real thing.

That is the case. A software company answering trouble: sorting it, working it, and above all communicating it, inside and out, through a structure of templates and rules that turns chaos into something a customer can trust, and an unknown into a known. The chapters that follow take this one process and turn it, so that each face of a rule, what is done, how, when, why, and by whom, can be seen at work in it.

Principles is built on principles, structured ways of thinking about processes, systems and transformation. Each Discipline builds on the one before, moving from the simplest ideas to the complex realities of real operations. It follows the way organisations actually grow, from single steps to large operations that run on systems and hold at scale.

This is not a theoretical guide. It comes from real work across global operations, system migrations and process design. The ideas here were observed, applied and refined in complex environments involving many countries, many systems and many people.

All examples are anonymised and abstracted. They are based on real situations, but names, organisations and identifying details have been removed on purpose. The point is not to show where the experience was gained, but to show how the thinking can be applied in any large, international environment.

This is not a book about what should work. It is a book about what works, consistently, when processes are designed to scale, systems are aligned to support them, and organisations are ready to change.

IMPORTANT NOTE

Readers are strongly encouraged to access and share the original content through marvinpro.com. MarvinPro is a continuously evolving body of work, with content regularly updated to reflect new insights, improved frameworks and enhanced learning materials. Material copied or reproduced elsewhere may no longer represent the latest version, whereas the live site will always provide the most current and complete learning experience.

© COPYRIGHT 1990-2026 MarvinPro

All rights reserved. Content is free to read and share via link. You are welcome to share quotes from this work provided the complete attribution is reproduced exactly as it appears in the text, including the quote, author name, year and marvinpro.com. Copying or reproducing other parts, complete sections or chapters without prior permission is not permitted.

Think Simple.