The shadow system

A quote went out last week on a recurring account. The rep did not read the price from the system. The rep opened the spreadsheet kept for that account, checked the figure against the last credit memo and the override that had protected the renewal, and quoted from that. The matrix was on the second screen the whole time. It was one input, and not the one the rep trusted.

Four files, one fact each

The same morning, in three other parts of the business, three other people were doing the same kind of thing.

Four people. Four files. Four facts the system of record was built to hold and does not. The rep’s account price. The branch’s real stock. The account’s rules. The period’s margin. Each person is doing extra work, and each is right to. The price in the spreadsheet is more current than the price in the matrix. The count on the floor is truer than the count on the screen. The rule in the notebook is the rule the customer will hold the business to. The hand-built margin is the one the controller can defend.

None of this is carelessness, and none of it is going away with a memo. These are not four bad habits. They are four people keeping the answers the business actually uses, in plain sight, in files of their own, because the official answer is wrong often enough that the file is the safer place to look.

It is one system

Put the four files beside each other and a system appears.

This is the move worth slowing down for, because it is the thing none of the four people can see from inside their own file. The rep knows the spreadsheet is doing real work. The controller knows the month-end join is doing real work. Neither of them is looking at the other three. Set the four side by side and they stop reading as four separate accommodations and start reading as one thing: a second system of record, complete where the official one is not, and the one the business actually transacts on.

The four files are not redundant copies of what the system already holds. Each is the only complete record of one kind of operating truth. Price lives in the rep’s file. Availability lives on the branch floor. Account rules live in the notebook. Realized margin lives in the controller’s reconstruction. They are split across people and files for the same reason the truth is split across the official systems in the first place: the price is in one place, the account context in another, the inventory in a third, and no single record was ever made to carry all of it. The recorded version is incomplete or stale or disputed often enough that the version kept by hand is the one that is safe to act on.

So the first reflex is worth naming and setting aside, because it is the most common one. The reflex is that this is a discipline problem: get the reps off the spreadsheets, ban the side files, tighten the behavior. But the spreadsheet is not indiscipline. It is the only place the real account price is complete. Ban it and the price does not move into the matrix; the order just gets priced from memory instead, which is worse. Take the files away and the work stops. The rule does not appear in the system because it was never in the system to begin with. The shadow system is not the symptom of weak people. It is the business’s real operating manual, written by the people who keep it running.

Why the truth lives there

The reason the truth ended up in the files, and nowhere else, is the part that turns this from a complaint into a diagnosis.

A new platform, when one is installed, asks the business for its rules. It asks for the pricing rules, the availability rules, the account rules, the rules that decide what can be promised and to whom. And the business discovers, at that moment, that it does not have rules to hand over. It has history. This account has shipped complete since a dispute four years ago that nobody wrote down. That account gets the override because a salesperson who has since left promised it during a renewal. The price on this line is what it is because a cost moved and the matrix never caught up. None of these were ever decided as rules. They accumulated as events, one at a time, each handled by whoever had to honor it.

A rule that was never designed cannot be encoded, because there is nothing to encode. So it stays where it was made, in the hands of the person who has to act on it. The senior CSR remembers the account because the account was never reduced to a record. The branch walks the row because the system was never given a count it could stand behind. The controller rebuilds the margin because no report was ever made to produce it whole. The local branch knows things the central system does not record, and it knows them because it was the only one present when they happened.

This is also why the second reflex misses, the one that says: just document it. Write the rules down and put them in the system. But documentation is not the hard part, and it is not the part the business is missing. The hard part is deciding. You cannot write down what you cannot read, and the business cannot yet read its own files well enough to say which of the rules in them are worth keeping and which are not. Write them all down as they stand and all you have done is move the ambiguity into a binder. An undecided rule, written down, is still an undecided rule. It is just longer.

The legibility cost

Here is the cost, and it is not the one most people name.

Take one record that lives in the rep’s file: a standing price exception on a large account, a number that sits below the matrix and has held for years. Look at it from outside the file, which is the only place anyone but the rep ever sees it from, and ask what it is. It could be any of these, and from where the business stands it cannot tell which:

It could be real complexity the business should encode and keep, a genuine account-specific rule the customer is paying for and would leave over. It could be a funded accommodation, a discount the business chose to give to protect a renewal, something it should either price deliberately or stop funding. It could be a system limitation, a price the matrix simply cannot hold cleanly, so it was parked in the file as the only workable place. Or it could be a stale habit, an override that protected a renewal three years ago, where the renewal closed, the reason expired, and the override was never removed, so it is now just margin handed back every month to no one’s benefit.

The record looks identical in all four cases. It is the same line in the same spreadsheet. Nothing on its face says which it is. The rep may know, or may half-know, or may have inherited the file from someone who knew. But the business cannot sort the four apart without going account by account, file by file, and reconstructing a history that was never written down. So it does none of it. The valuable rule never gets encoded into something the company can scale, and the costly one never gets retired, because both are wearing the same face. They look like several different problems. They behave like one.

This is what the four files cost when you set them in a single view. The official system holds a version of each fact, and in every case it is the wrong version to act on.

Read down the right column. That is the system the business runs on. Read down the middle. That is the system it bought. The work the four people do every day is the distance between the two columns, closed by hand, one order at a time.

The one layer no project carries

Most businesses in this position have a plan for it already, and the plan is a new system. The new ERP, the new CPQ engine, the customer portal that is coming. Once the platform goes in, the thinking goes, the shadow files go away.

This is the refusal worth landing hardest, because it is the move most of these businesses are making right now. The next system will not fix this, and not because the system is weak. It is because the one layer a system project never migrates is the layer that was never recorded. The migration is faithful to the records. The shadow system is everything that is not in the records. A new platform inherits the official files and runs the old logic on top of them, and the parallel system rebuilds itself around the new interface within weeks. The portal makes this sharper, not softer: it publishes the split truth straight to the customer on a cleaner screen, and it removes the people who used to quietly fix the data before the customer saw it.

There are two ways this compounds, and both are worth following without raising an alarm about either.

It compounds with growth. At a smaller size, the four files were a workaround around a gap in the systems. At this size they are the operating model, the thing the business actually runs on. Every new account adds a rule to someone’s file. Every new branch adds a floor someone has to count. Every acquisition arrives with its own files and its own undecided history. The parallel system grows with the business, and it grows faster than the official one, because adding a record to the official system requires a decision and adding a line to a spreadsheet does not.

And it compounds in people. The operators who are the shadow system, the senior CSR who carries the accounts, the branch manager who knows the floor, the analyst who can rebuild the price, become the thing the business cannot lose. They are the asset and the single point of failure at the same time. The bench beneath them is thinner than the org chart suggests, because what they know was never written down for anyone to inherit. The most expensive line item here is the one nobody books: the senior time spent holding the parallel system together by hand, every week, instead of building the next phase of the company. The same untrusted stock file that lives on the branch floor also quietly builds defensive inventory, capital tied up to cover promises the business does not trust its own records to make, which is a cost on the balance sheet for another piece to trace.

There is one more reflex to name here, because the reader has likely tried it: stand up a commercial operations function, or a pricing council, to govern the exceptions. It is a real improvement and it does real things. A council catches an exception earlier and shows the pattern more clearly than four scattered files ever could. But governing the exceptions is not owning the records that produce them. A council cannot change the customer master, rewrite the pricing logic, or move the decision right that sent the truth into the file in the first place. It becomes one more place the shadow system is managed, and managed well, while still living in the files.

The question the shadow system asks

The decision the business has been avoiding is not the one it thinks it is. It is not which system to buy, and it is not how to get the reps off the spreadsheets. It is the prior, harder thing.

That is a different kind of work than a system project, and it comes before one. It means reading the four files as what they are, the real operating manual, and going through them account by account: this rule is real and the customer pays for it, so encode it and keep it; this one is a funded accommodation, so price it on purpose or stop funding it; this one is the matrix failing, so fix the matrix; this one expired three years ago, so retire it. It means deciding, for each kept rule, where it should live so that the next quote uses it and the next override does not erase it. Whatever bills under exception is the real rule, and the work is to make the real rules legible enough to decide, then true enough to hold.

The proof that this work happened is not a new dashboard, and it is not a system that went live on schedule. The proof is that the workarounds retire. The rep stops pricing from the spreadsheet, because the price the matrix gives is now the price the rep trusts. The branch stops walking the row, because the count on the screen is one it can commit a date to. The CSR’s notebook stops being the only place the account’s rules live, because they live on the account. The controller’s month-end join closes on its own, because the three reports finally agree. When those four files go quiet, the system the business runs on and the system it bought have become the same system. Until then, every new platform inherits the old one.