Cases from the MBA and the Vanguard · MBA module — fix the exception or change the process, when one customer journey crosses two companies
Subtitle: When protecting the existing process becomes the risk
The process was quite simple. When a customer had an insurance claim and the insurer needed photographs, an employee entered the claim into InScope and sent the customer a link. The customer opened the link, followed the instructions and took the required photographs. Once the customer completed the process, InScope sent the photographs to the insurance company by email.
The important part was what happened next. The email subject contained the claim number in square brackets, which allowed the insurer's system to recognise the claim and automatically attach the photographs to the correct case. This meant that employees did not have to download the photographs, search for the correct claim or attach the files manually. It was not a direct integration between two systems, but from an operational perspective, it worked like one.
This distinction was important to me because I often work with processes where technology has to fit into existing business operations. The technically most advanced solution is not necessarily the best business solution, especially if it requires another company to change its systems, allocate development resources and redesign a process that already works. In this case, email was more than just a communication channel. It had become an important part of the automated process.
The problem appeared when some claims started failing. The customer had completed the process correctly, the photographs were available and the claim number was correct, but the email did not reach its destination. We discovered that the reason was very simple: in some cases, the customer submitted enough photographs for the total size of the attachments to exceed the email limit.
Several possible solutions immediately came to mind. Instead of sending attachments, we could send a link, use SFTP, compress the photographs or develop a direct integration between the two systems. From a technical perspective, some of these options would certainly be cleaner. However, they would also change the existing process. The insurer's system does not simply receive the email. It uses the claim number in the subject to recognise the case and automatically saves the attached photographs to it. If we replaced the attachments with a link, for example, we could solve the email size problem while at the same time losing the automation that makes the current process useful.
This led to a much simpler idea. Instead of changing the entire process, InScope could split the photographs into several emails whenever the total attachment size exceeded the limit. Each email would contain the same claim number in the subject, with an additional indication such as 1/3, 2/3 and 3/3. If the insurer's system can correctly process several emails with the same claim number, the photographs should still be automatically attached to the correct claim. The change would happen on the InScope side, while the insurer could continue using the existing process.
At first, this seemed like the obvious solution. It would require relatively little development, it would not change the customer journey and, most importantly, it would not require the insurer to start a new integration project. At the same time, I started questioning whether solving the problem in this way was actually the right decision.
Many business processes develop gradually. A practical solution is introduced because it solves a specific problem, and over time it becomes part of the infrastructure. When a new problem appears, another adjustment is added because changing the entire process would take more time, money and coordination. Each individual decision can be completely reasonable, but after several such decisions, the organisation may realise that it is no longer improving the process. It is simply maintaining a process that was never designed for everything it is now expected to do.
This left me with two rational options. The pragmatic option was to solve the problem where it occurred, split oversized deliveries into several emails, preserve the existing automation and avoid unnecessary development on the insurer's side. The structural option was to treat the failed emails as an indication that the current way of connecting the two systems had reached its limit and that it might be time to redesign how information is exchanged.
The first option could potentially be implemented quickly and with very little disruption. The second could result in a better long term solution, but it could also turn a relatively small operational issue into a much larger project involving two companies, different systems and additional resources. Neither option guarantees that another limitation will not appear in the future.
While thinking about these alternatives, I realised that there was another question behind the technical problem: who actually owns the entire process? InScope controls the collection and transmission of the photographs, while the insurer controls what happens once they arrive. The email infrastructure sits between the two. From the customer's perspective, however, none of these boundaries exist. The customer sees one process and expects it to work. When everything works correctly, the organisational boundaries are almost invisible. When something fails, those boundaries suddenly become very visible.
The immediate failure was caused by the size of the photographs, but the decision I had to make was much broader. Should we improve the process we already have because it works well in most situations, or should we treat this relatively small failure as a signal that the process itself needs to change?
I would open with one question: Would you fix the exception or redesign the process? I would ask someone in an operational role first. The fact that could change the room’s answer is that the workaround requires changes only on the InScope side, while a direct integration requires development and coordination on both sides.
Sometimes the real question is not how to fix what failed, but whether the failure is telling us that the process itself needs to change.
A live case: every round can be improved, and the author's feedback is the next one.
The same four questions, answered twice: first without the mentor's corpus, then from it — his decision doctrine, the Diagnostic Layer and the Command Layer, VIS, the NCTE article and the agent charter.
Without the mentor's corpus
1. Fix the exception, but in a way that keeps the failure visible. The split is cheap, reversible and keeps the insurer's automation, so waiting buys nothing. The danger is what a working patch does to learning, and the case's title names it. Anita Tucker and Amy Edmondson spent 239 hours observing 26 nurses in nine hospitals. For 93% of the problems they met, the nurses did what it took to carry on and no more: they told no one and did not look for the cause. Only 7% of their responses even drew attention to the problem. The patches worked, and that is exactly why the hospitals did not learn. So count every split from the first day, and watch for three signals that the workaround has become a reason to change the process:
Ask yourself: which of our processes works only because someone keeps quietly patching it?
2. The insurer owns the promise; InScope should own the proof. The claim and the customer belong to the insurer, and if it operates in the EU, the law already says so. Under DORA, which has applied since January 2025, an insurer that runs its business on contracted ICT services remains "at all times" fully responsible for its obligations, and the rights and obligations of both parties must be "clearly allocated and set out in writing", service levels included. But the party best placed to watch the whole journey is InScope, for a reason computer scientists spelled out in 1984. Jerome Saltzer, David Reed and David Clark showed that knowing a message was delivered matters little; what matters is whether the receiving application acted on it. The acknowledgement that counts can come only from the far end: "I did it" or "I didn't." An email accepted by the insurer's mail server says nothing about whether the photographs reached the claim. So:
Ask yourself: in our process, who would be the first to notice that a customer's work never arrived?
3. Yes: it changes the order, not the question. In his 2015 letter to shareholders, Jeff Bezos separated two-way doors, reversible decisions that "can and should be made quickly" by individuals or small groups, from one-way doors that need slow deliberation and consultation. The split is a two-way door that InScope can open and close alone. A joint integration commits two companies' budgets and roadmaps, so it earns the slower process. But "only on the InScope side" is less true than it sounds. The internet's own standard for splitting a large message into numbered parts, message/partial in RFC 2046 of 1996, leaves the reassembly to the receiving side. So does this fix: the insurer's system has never been asked to attach three emails to one claim. The limit may not be InScope's either. Microsoft's Exchange Online, for example, lets each organisation set its own anywhere from 1 to 150 MB, and attachments grow by about a third when they are encoded for email. So ship the split, with one piece of coordination that costs an afternoon:
Ask yourself: what does our one-sided fix assume about the other side, and who has checked it?
4. Let the agent fix the instance and report the pattern; never let it decide the pattern. Raja Parasuraman, Thomas Sheridan and Christopher Wickens argued in 2000 that automation is not one setting. At level 4 the computer suggests one option and the human decides; at level 6 it acts unless the human vetoes in time; and one system can run at different levels for different functions. So give this agent two levels. It may apply an approved fix on InScope's side and report it, if the fix is reversible and the far end confirms that it worked. Anything that changes what the insurer or the customer receives, it proposes and waits. Then add the lesson of the hospital study: an agent is the perfect first-order problem solver. It patches every failure at three in the morning and tells no one, unless it is built to count. So it stops and asks when:
The first is the process question, and it belongs to people in both companies. Lisanne Bainbridge warned in 1983 that the more advanced the automation, the more crucial the human contribution may become. Here that contribution is deciding when fixing has become the wrong answer. Ask yourself: does our automation tell us how often it rescues us?
Sources: A. L. Tucker and A. C. Edmondson, "Why Hospitals Don't Learn from Failures", California Management Review, 2003; J. H. Saltzer, D. P. Reed and D. D. Clark, "End-to-End Arguments in System Design", ACM Transactions on Computer Systems, 1984; Regulation (EU) 2022/2554 (DORA), Articles 28 and 30; J. Bezos, 2015 letter to Amazon shareholders; N. Freed and N. Borenstein, RFC 2045 and RFC 2046, 1996; Microsoft, "Exchange Online limits"; R. Parasuraman, T. B. Sheridan and C. D. Wickens, "A Model for Types and Levels of Human Interaction with Automation", IEEE Transactions on Systems, Man, and Cybernetics, 2000; L. Bainbridge, "Ironies of Automation", Automatica, 1983.
From the mentor's corpus
1. Fix it, and let a threshold set in advance decide the redesign. The mentor's decision doctrine will not take an A-or-B menu as given. It tests the menu first, and if both options are bad, it changes the sequence. Tested, this menu turns out to be a sequence: fix first, then let evidence decide whether to redesign. The Diagnostic Layer of his second volume says what that evidence must watch. Institutions keep operating on assumptions that have silently become false, because no one named them and no one tracks them. InScope's process rested on one: a claim's photographs fit in one email. The split replaces it with another: the insurer's system attaches several emails to the same claim. His VIS framework is built to reduce exactly this kind of silent failure. Each assumption goes into a register with a confidence, an impact if wrong and an owner, and the most dangerous becomes a kill indicator: an observable signal, a threshold, a monitoring cadence and an action agreed in advance, GO, LEARN or STOP. For example: if more than one claim in twenty needs a split for two months running, LEARN, and open the redesign with the insurer. So a workaround becomes a reason to change the process when a threshold set in advance is crossed, not when someone finally feels it. And pre-registration stops anyone explaining the evidence away: an override must be declared in writing, with its reason. Ask yourself: which assumption does our process rest on, and who is watching it?
2. The mentor's Command Layer divides this ownership rather than handing it to one party. Authorising initiative, it says, does not dissolve the chain of responsibility: the subordinate is responsible for the action, the commander for the intent, the boundary conditions and the authorisation, and both are on the record. Here the insurer holds the intent, because the claim, the customer and the need for photographs are its own. InScope holds the action: collecting the photographs and delivering them. What the case lacks is the record. His field research finds that delegation becomes good only when intent is clear, boundaries are visible, accountability is real and follow-up exists. The case shows two of those missing: the boundaries stayed invisible while everything worked, and no follow-up told anyone that photographs had not arrived. His article on NCTE, the trust layer he proposes for commerce between firms, names the gap: across company lines, message exchange is not the same as shared truth, so trust is rebuilt after the fact, through investigation and exception handling. Its remedy is a record of the event itself that both parties sign. Here that is one line per claim:
A line with one signature is the alarm, and both owners see it the same day. Ask yourself: if my company and the other each wrote down what happened to one customer yesterday, would our records agree?
3. Yes, because it makes the decision reversible, and the mentor's decision doctrine treats reversible decisions differently. Roughly 80 percent confidence can be enough for them. But the same doctrine separates decision confidence from engineering safety: critical infrastructure still advances through isolated tests, bounded live users and progressively wider deployment, for as long as the evidence requires. A process that carries customers' claims is infrastructure for both companies. So InScope can decide at 80 percent and still ship like an engineer. The doctrine also asks for the epistemic status of every material claim: case fact, doctrine, thesis, inference or unknown. The author states the key one honestly, as a condition: "If the insurer's system can correctly process several emails with the same claim number". Today that is an unknown, not a case fact. In the doctrine even a thesis may justify a reversible experiment, but it may never be presented as measured evidence. So the one-sided fix begins on the other side:
The integration, with its two budgets and two roadmaps, is not rejected. It waits for the kill indicator from the first answer. Ask yourself: in my last decision, which claims were facts, and which were conditions nobody had tested?
4. Its authority should end where the pattern begins. The mentor's decision doctrine treats neither people nor AI as a trusted root: power must be limited by scope, time, evidence, independent review and revocation. His Command Layer issues intent to an agent through a declared HAI5 level, and this agent needs two. For the approved fix it works at "AI Executes with Human Exceptions": it splits the delivery, checks that the claim received every part, and reports. For the process it works at "AI Identifies Patterns and Human Provides Strategic Judgment": it shows the trend, and people in both companies decide. It cannot cross a boundary without producing a receipt that flags the crossing for human review. His Agent Charter puts the rest on one page:
The case's question is the third. Whether the process should change is not an exception to handle but a trigger to revise, and revision belongs to people. The mentor's NCTE article warns against the opposite error too: brittle autonomy, in which every exception falls back to humans. So the agent never asks about a single split, only about the pattern. Ask yourself: which of our automations would tell us that the process it runs is wearing out?
Sources: the mentor's decision doctrine of 22 August 2026 (frame before choice; no trusted root, human or AI; the epistemic status of every claim; 80 percent for reversible decisions); Vanguard Leadership, vol. 2, the Diagnostic Layer, the Command Layer (the chain of responsibility; HAI5) and the chapter on the field evidence (the conditions of delegation); the mentor's VIS framework (the assumption register and kill indicators); the mentor's article on the NCTE trust layer for the International Leadership Journal; the Vanguard Task-to-Agent Mapping Protocol (the Agent Charter).
A question for the table, a disagreement, what you would have done. The case lead reads every comment; the ones the table takes up enter the chapter as questions from the room, with your name.