There’s a question that comes up in almost every diligence process, asked in different ways by different buyers: where does this company actually run?
Not where the org chart says it runs. Where the data lives. Where decisions get made. Where you’d look if you needed to know whether a customer was healthy, whether a vendor contract was current, whether the company could close the quarter without three people manually reconciling four spreadsheets.
The answer tells you everything about whether the company is exit-ready. And the answer almost always comes down to one thing: who owns the tools.
The Function Ownership Problem
In most PE-backed software companies, the application landscape got built the same way the org chart did — function by function, problem by problem. Sales needed a CRM, so they picked one and configured it for deals. CS needed a ticketing system, so they stood one up and built it around ticket resolution. Finance needed a billing platform. HR needed an HRIS. Product needed a roadmap tool. Each function solved its own problem, on its own timeline, with its own configuration logic.
The result is not a business operating system. It’s a collection of departmental tools that happen to coexist inside the same company.
This matters for three reasons. First, the tools don’t share data in any meaningful way — which means every cross-functional question requires a human to bridge the gap. Second, the tools are configured for functional activity, not for business outcomes — the CRM is built for deals, not for Customer Lifecycle visibility. Third, when personnel changes happen, the institutional knowledge about how each system actually works walks out with the person who built it.
Buyers see all three of these things in diligence. They don’t always name them. But they feel them — in the time it takes to answer basic questions, in the number of people who have to be in the room to produce a single number, in the shadow spreadsheets that exist alongside every “system of record.” And most visibly, in the headcount. Every employee whose job is to move data between systems that should be integrated, reconcile reports that should match, or translate between tools that don’t share a data model — that’s human middleware. It shows up in the EBITDA bridge. Buyers discount for it.
The CRM Is the Most Visible Example
Sales owns the CRM. This is the norm across the industry and it produces the same failure mode every time.
Sales configured the CRM for pipeline management. Stages, deal value, close date, owner. It works well for that. It is nearly useless for everything else.
CS can’t see the full customer history — or they can see some of it, filtered through a view that Sales built for their own reporting. Finance reconciles the CRM against their billing system at close every quarter, which is a manual process that takes three days and produces a slightly different number each time. The new CRO comes in, looks at the CRM, and immediately starts reconfiguring it — which breaks the reports CS and Finance built workarounds for.
The underlying issue isn’t the CRM. It’s that the CRM is being asked to serve Lead to Cash — a process that touches sales, CS, finance, and operations — while being owned and configured by one function that only cares about the sales portion.
The fix isn’t a better CRM. It’s governance. Who decides what the CRM tracks? Who owns the data model? Who has to sign off before a field gets added or a stage gets renamed? In an exit-ready company, the answer to those questions is Business Systems — not Sales.
What Business Systems Actually Does
Business Systems is not IT support. It’s not the team that handles software licenses and user provisioning. It’s the function responsible for making sure the company’s application landscape serves the company’s processes — not the departments.
That means a few specific things. First, Business Systems owns the architecture: which system is the system of record for each process, how data flows between systems, what the integration logic is. Second, Business Systems governs configuration: functions can request changes, but they don’t make changes unilaterally. Third, Business Systems builds for handoff — every system should be navigable by someone who didn’t build it, which means clean data models and configuration logic that doesn’t depend on one person’s memory.
When Business Systems is functioning as designed, you get one system of record per process. Lead to Cash runs through the CRM and the billing platform with a clean integration. Customer Lifecycle has a home — a system that tracks the full arc from onboarding through renewal, owned by the company rather than by CS or Sales. Employee Lifecycle lives in an HRIS that managers can actually use, not just HR administrators.
The process owners set the requirements. Business Systems builds and maintains the infrastructure. The result is an application landscape that serves the operating model, not the org chart.
What This Looks Like in Diligence
Exit-ready companies answer the “where does this live” question the same way every time: one system, one owner, clean data.
“Where do you track customer health?” — Customer Lifecycle platform, owned by Business Systems, visible to CS, Sales, and Finance with role-appropriate access.
“How do you close the quarter?” — Finance runs the close process through the ERP, which is integrated with the CRM and the billing system. Reconciliation is automated. Three days becomes three hours.
“What happens if your VP of CS leaves?” — the process keeps running. The system doesn’t depend on her knowing where things are.
Companies that aren’t exit-ready answer the same questions with a room full of people, three different answers, and a follow-up email two days later with a spreadsheet attached. That’s not a data problem. That’s a governance problem. And buyers model it as risk — in the multiple, in the earnout structure, in the retention requirements they put on key personnel.
How to Build Toward It
The shift from function-owned tools to company-owned infrastructure doesn’t happen in one sprint. But it starts with a few decisions.
First, name a system of record for each of the six processes. Not the tool each function prefers — the system that owns the data for that process end to end. Gaps between what you have and what you need are your implementation backlog.
Second, move configuration governance to Business Systems. Functions retain input and access. They lose unilateral control over the data model. This is a political conversation in most companies. It is also the conversation that determines whether you exit clean.
Third, build for the buyer. Every quarter, ask: if a new team showed up tomorrow with no context, could they run this process using just the system of record? If the answer involves a spreadsheet, a Slack channel, or a specific person’s institutional knowledge — you have work to do.
Exit readiness is not a 90-day prep exercise. It’s a state the company either is or isn’t in. The companies that exit at the number they deserve built the system before the banker showed up — not because they knew they were selling, but because they were running the company like a product.
A product built to be sold looks clean on any given Tuesday. So does an exit-ready company.