What Happens When the Person Who Set It Up Leaves
The system was configured by one person, and configuration is knowledge. Which decisions were written down, which were tacit, what a support handover has to capture, and why the answer is a list rather than a yes.
The system works. That is the thing to hold on to at the start, because the version of this story where it does not work is easier and less useful. Reports come out. Day-end closes. Invoices number correctly. The system works because one person made a long series of decisions — about numbering, about ceilings, about what counts as the business day, about what happens when a quote is revised — and most of those decisions were never written down anywhere except in the way that person does the work.
Then it is Friday, and on Monday they are not there. Not through misconduct, not through a dramatic falling-out. Through a resignation, an illness, a relocation, a promotion that took them somewhere else. The records are all intact and the business is now operating on a set of rules that exist in exactly one place, and that place is no longer reachable.
This is the third of four articles on data trust. The first was about the shared login that makes attribution impossible, the second about the difference between a recorded action and a reconstructable one. This one is about a different kind of loss: not the loss of a fact but the loss of the reasoning that produced it. The last is about the difference between a backup and a file you hold.
Why this is a knowledge problemConfiguration is knowledge, and knowledge is perishable
A configuration decision looks like a setting. It is not. It is a judgement that has been frozen into the behaviour of a system, and the judgement contains at least four things that the setting itself does not store: why this value was chosen rather than a plausible alternative, what it was chosen to prevent, who agreed to it, and what should happen when it turns out to be wrong.
This is why configuration survives a person leaving and still causes damage. The setting continues to function perfectly. Nothing breaks. The business just starts making decisions according to a rationale that nobody can reconstruct, and the first person to notice usually notices because the setting is wrong for a situation that has now arisen — at which point there is no way to know whether it was chosen deliberately for this exact situation or by accident months ago.
There is a second-order effect that is worth naming, because it is the one that hurts. Once the reasoning is gone, the setting stops being a decision and becomes a superstition. Somebody changing it later feels like they are risking something, because they do not know what it was protecting. So it stays. And the business keeps running on an inherited constraint that nobody would choose if they were choosing today.
The 18% GST figure used in the worked example in this article appears only to keep the arithmetic checkable so you can verify it by hand. It is not a statement about the rate that applies to your business, and nothing here is tax advice. What rate applies, how it is treated, and how it is presented on your documents are questions for your own chartered accountant.
The inventoryWhich decisions were written down, and which were tacit
Take a counter billing deployment. The following inventory is constructed for this article to show the shape of the problem, not to describe any particular installation. The count of twelve is a constructed count chosen to make the arithmetic checkable.
Of those twelve decisions, suppose four are written down somewhere a new person would actually find. The remaining eight are tacit — held in the setup person's habits, in their memory, in the order they click things. Twelve less four is eight, and those eight are the ones that stop existing when the person does.
Illustrative: a configuration inventory, split by whether the reasoning survives. Constructed for this article.
| Decision | Usually written down | Usually tacit, and why it matters |
|---|---|---|
| Who may cancel an invoice | Yes — the permission itself is configured and visible. | Why cancellation is allowed at all rather than only a credit note. A new person may read the permission as a design decision rather than an oversight. |
| Discount ceiling per role | Partly — the number is configured. | Why that number. Whether it was set from a margin floor, a competitive position, or a single difficult conversation three years ago. |
| Whether quotes are tax-inclusive or tax-exclusive | Rarely written down. | This changes what every number in the business means. Getting it backwards silently changes the value of every quote ever issued. |
| Whether invoice numbering is continuous or restarts per shift | Rarely written down. | The consequence differs sharply: continuous numbering leaves gaps if a shift restarts, and per-shift numbering makes year-end numbering meaningless. |
| Duplicate-customer match rules and merge policy | Partly — the rules are configured. | Match rules and merge behaviour are a setup decision, and the reasoning behind the thresholds is rarely recorded. Detection flags candidates and a person reviews them; nothing merges automatically. |
| What counts as the business day, and when it closes | Rarely written down. | The close time determines which transactions land in which period. Every period comparison inherits this choice. |
| What a scope change produces | Rarely written down. | In NoxOrigin there is no change-request record and no milestone or deliverable record. A scope change is a NEW QUOTE raised against the same project, and that convention has to be known or the business will look for a feature that does not exist. |
| Which payment methods appear at close, and who reconciles UPI | Partly — the methods are configured. | Who does the reconciliation, when, and against which source. Shift close and day-end reconciliation are assisted-setup maturity rather than self-serve switches, so this lives with the person who set it up. |
Read that table for its pattern rather than its contents. The decisions that are written down tend to be the ones with a visible setting in an interface. The decisions that are tacit tend to be the ones about what a value means, what follows from it, and what to do when it turns out to be wrong. The first kind is discoverable by looking. The second kind is only discoverable by asking, and asking has to happen while the person is still there.
The deliverableWhat a support handover has to capture
A handover is not a settings dump. Exporting the current configuration tells the next person what the system does, which they can largely work out by looking at it. What they cannot work out is what it should do, and why the difference matters. A handover that captures only the first is a handover that transfers the settings and leaves the knowledge behind.
For each decision, five things are worth writing down. What was decided. The alternatives that were considered and rejected. What it is protecting against. What it would look like if it were wrong. And who agreed to it, including the fact that nobody agreed if that is the case — an unratified default that has been running for three years is a real and common finding, and it is much better to know it.
The handover question, and the honest answer to it
The question that gets asked is usually can someone else run this? The honest answer is almost never yes. It is a list, and the shape of the list is more useful than a false reassurance would have been.
The list has three kinds of item, and they are not equally urgent.
Written down and findable. The setup is documented. Anyone can pick this up. Treat it as done and do not spend handover effort here.
Written down somewhere nobody would think to look. The knowledge exists but is filed somewhere implausible — a comment in a spreadsheet from two years ago, a message to one person. This is the cheapest to fix and the most commonly missed, because it feels like documentation exists.
Never written down. This is the real handover. It has to be extracted by asking, while the person is still there, and it will take longer than you expect. The questions that work best are not what is this setting. They are what were you afraid of when you set it, what have you wanted to change but not got round to, and what will break first if we do nothing.
A constructed count, to show the arithmetic. Take the twelve decisions in the inventory above. Suppose a handover document covers four of them. Twelve less four leaves eight with no written answer anywhere. Now suppose each of those eight needs one question to resolve and each question takes ten minutes of someone's attention. That is eight times ten, which is eighty minutes. That is a real, bounded, one-afternoon exercise — and it is the entire cost of preventing a discovery that would otherwise happen during an absence, at the worst possible time, with no reference to consult.
The uncomfortable partWhy the honest answer to can someone else run this is a list
Because a system that one person can run and nobody else can is not fully configured — it is partially documented in a human being. Those are different states, and only one of them survives contact with a holiday.
There is a version of this article that ends with reassurance about how most businesses get by fine. That version is not true. The businesses that get by fine are the ones where the tacit knowledge is less load-bearing than it appears, usually because the operation is simple enough that a competent new person would make the same choices. That is a real and common situation and it deserves to be said. But it is a situation, not a guarantee, and the test of which one you are in is simple: could a competent person who has never seen this business make the same decisions, for the same reasons, without asking?
If the answer is no, the knowledge is load-bearing and the handover is the work. There is no version of the product that removes that, and any product page implying otherwise is describing a feature rather than a transfer of judgement. What a system can do is make the tacit explicit — put the decision in front of a person at the moment it matters, force a reason on the handful of actions where a wrong answer is expensive, and keep the value before the change so that a later question has an answer. Those are the mechanisms this site keeps returning to, and they are mechanisms rather than guarantees.
One practical suggestion that costs nothing. Ask the setup person to write down the three settings they would change first if they were starting again today, and the reason for each. It is a short, concrete question, it is easy to answer, and the answers are disproportionately valuable, because those are the settings that are working by accident rather than by decision. The shift handover sheet is a useful model for the shape of the output even where the content is different: who owned the period, what was expected, what was found, what the variance was, and what the next person has to know.
A handover exercise that fits in one afternoon
- List every configuration decision you can find, without judging whether it is documented. Twelve is a plausible count for a counter deployment; the number matters less than the list.
- Mark each one as written down and findable, written down somewhere implausible, or never written down. The third column is the handover.
- For each tacit decision, ask the three questions that work: what were you afraid of, what would you change first, and what will break first. Write the answers down verbatim.
- Record the reason next to each discount ceiling, and check it against the margin you need. Divergence here is the most common single finding.
- Write down whether quotes are tax-inclusive or tax-exclusive, and confirm it with your chartered accountant against what you actually issue. Getting this backwards changes the meaning of every historical number.
- Note who set up shift close, day-end reconciliation, and the duplicate match rules, and mark them assisted setup rather than self-serve. That person's knowledge is the handover.
- Name the absences — no timesheets, no payroll, no e-signature, no change-request record, expenses in one place and purchasing in another, no statutory returns filed for you.
- Book the review. A handover document that is written once and never revisited becomes a second piece of tacit knowledge about a document.
Frequently asked questions
Our setup person is still here. When is the right time to do this?
Before they leave, and before they are distracted by leaving. The exercise that works is asking what they would change first if they were starting again today, and what they were afraid of when they set each threshold as they did. Both questions produce specific, useful answers that a settings export cannot contain.
Is exporting the current configuration enough?
No, because it captures what the system does rather than what it should do. A new person can largely infer the current behaviour by looking at the system. What they cannot infer is the reasoning, the alternatives rejected, and what should happen if the setting turns out to be wrong. That is the part that disappears.
Which decisions are most worth documenting?
The ones that are tacit and load-bearing: whether quotes are tax-inclusive or tax-exclusive, whether invoice numbering is continuous or restarts per shift, what counts as the business day, why a discount ceiling has the value it has, and what a scope change is meant to produce. These change the meaning of other records, so getting them wrong is expensive and quiet.
Should a handover be a document or a session?
Both, in that order. The session is where the tacit knowledge comes out, and the document is where it survives. A document written from memory afterwards is a second piece of tacit knowledge about a document, which fails in exactly the same way and is harder to notice.
Is shift close something we can just switch on ourselves?
Not as a self-serve switch. Shift close and day-end reconciliation are assisted-setup maturity in NoxOrigin, as is the reasoning behind duplicate-detection match rules and merge policy. Detection flags candidates and a person reviews them; nothing merges automatically. That is worth recording in the handover, because it means the setup knowledge is a person, not a setting.