At this point the senior team acts. It does not ignore the condition. It changes leadership, funds systems, builds operating cadence, and stands up teams to catch what keeps leaking through. Each response is real, and each improves what sits around the order. None of them, by itself, changes what the next order inherits.
The first response is usually a new leader. A new CRO, a new COO, sometimes a CFO or CEO, someone who has done this before. The leader makes real changes within the role’s authority. Territories get realigned. Compensation changes. Pricing approvals tighten. Forecast reviews sharpen. Credit discipline gets more attention. Decisions move faster where the role can enforce them.
Those changes are real, and they can lift behavior within a quarter or two. But six quarters later the working capital is still climbing, the pricing matrix is still drifting, and the side spreadsheet is still on the analyst’s desk. The leader has not failed. The leader changed the levers the role controls, and the next order still depends on the records, rules, and handoffs underneath them: the item masters, the customer rules, the freight assumptions, the substitution logic, the billing treatments that were never encoded cleanly. Rebuilding those crosses functions, systems, and branches, and it has to happen while the business still sells, ships, invoices, and collects every day.
The second response is a new system. A new ERP, a CPQ, a CRM, a BI platform, a customer portal, any of them, or several at once. The business gets mapped. Workflows get documented. Master data gets reviewed. Approval paths get designed.
Then the blueprint meets the real business. The standard configuration wants clean item masters, stable units of measure, structured customer rules, and disciplined exception paths. Forcing that design too fast would break service, disrupt accounts, or strip out the local treatments customers already rely on. So the build makes room for the exceptions instead. Custom fields get added. Middleware connects what does not connect on its own. Exception tables hold the account treatments the standard model cannot. The pricing matrix comes back with a cleaner interface and the same inherited overrides. The portal exposes the same availability and documentation gaps in a cleaner screen.
The system does not fix the operating logic. It runs whatever logic it is given, and it asks the business to supply the decisions it has not made: which exceptions are valid, which rules should change, which records can be trusted. Where those decisions are still open, the system encodes the ambiguity or pushes the work back outside the platform. The business gains control in one place, and in another it builds a new dependency: simple changes now have to move through custom fields, middleware, and approval paths wired around the old workarounds. It is harder to change than before.
The third response is to stand up commercial operations. A deal desk, a pricing council, forecasting routines, dashboards, exception tracking. The visibility is real, and this is the closest of the three to the actual work, because commercial operations sits right next to the rules, the handoffs, and the decisions that shape the order before it moves.
But governing the exceptions is not the same as owning the records that produce them. The team can catch an exception earlier, route it better, and show the pattern more clearly. If it cannot change the customer record, the pricing logic, the freight assumption, the substitution rule, or the decision right that created the exception, it becomes one more place where the workaround is managed well.
So the dashboard improves and the council meets. Exceptions get tagged. Deals run through review. Reps learn which parameters trip an escalation and which ones can be worked around. The analyst keeps the side spreadsheet alive because the quote window still has to be protected. The critical order still gets pushed through by hand when the formal route cannot move fast enough. The team adds discipline and the first real view of the condition, but standing it up does not install the logic it was created to govern.
The leader improves the behavior. The system improves the control. The team improves the governance. None of the three, on its own, changes what the next order inherits. That is why the conditions continue. The responses are not wrong, and they are often necessary. They simply leave the same records, rules, handoffs, and decision rights sitting in the path, waiting for the next order to run through them.
The work is not one more response built around the order. It is changing what the order has to rely on in the first place.