Operational Maturity Before a Sale: What to Document First

Jeff Lontoc August 17, 2026

Nine months before a planned sale is a difficult time to discover that the business runs on explanations only the founder can give.

The numbers may be clean. The org chart may be current. The data room may be filling up. Then an operating question arrives: Who decides when a quote falls outside the standard margin? How does a customer complaint move from a location manager to leadership? Which report tells you whether service delivery is slipping?

If the answer begins with “It depends,” followed by a call to the owner, the documentation problem is not a missing binder. It is that the business cannot yet show how work moves without one person reconstructing it.

That is the practical purpose of operational maturity before a sale. It gives a buyer, investor, or new executive enough evidence to see that recurring work can be understood, repeated, and managed by the team that will remain.

Operational maturity is evidence, not volume

Operational due diligence looks beyond historical results to test whether the operating model can support what comes next. Deloitte describes it as a forward-looking process that assesses the robustness of operations and helps shape an actionable value-creation plan (Deloitte, October 30, 2023).

That does not mean every process needs a polished procedure before a transaction begins. A company can have hundreds of pages of documentation and still depend on the founder for pricing judgment, priority calls, customer exceptions, and the final interpretation of the weekly numbers.

A more useful test is transferability:

Can another person see what should happen?
Can they tell who owns the decision?
Can they handle the normal exceptions?
Can leadership see whether the process is working?
Can the work continue when the founder is unavailable?

The first documentation should make those five questions easier to answer in the parts of the business that matter most to revenue, margin, customer continuity, and management control.

What to document first before a sale

1. The operating rhythm behind the numbers

Start with the recurring meetings, reports, and decisions that management uses to run the business.

A buyer can review revenue, margin, backlog, utilization, callbacks, or customer retention. The operating question is how those numbers become action. If the weekly meeting depends on the founder knowing which locations need attention, the report is producing data without producing management control.

For each critical measure, record:

the exact definition
the source system or file
who prepares it
who reviews it
how often it is reviewed
what threshold requires action
where the action and owner are recorded

This is not a reporting inventory. It is the bridge between a number and a management response.

Pay particular attention to measures that require manual adjustment or explanation. If two managers calculate the same KPI differently, document the definition before improving the dashboard. A clean visualization cannot resolve an unstable measure.

2. Decision rights for routine operating calls

Founder dependency is often described as a workload problem. Before a sale, it is better understood as a decision-rights problem.

Routine work routes upward when the team does not know who has authority, what criteria to use, or when a decision becomes an exception. The owner may answer quickly, but the business leaves no reusable record of the judgment.

Document the recurring decisions that most often reach senior leadership. Pricing exceptions, service recovery, purchasing approvals, scheduling conflicts, staffing changes, and customer commitments are common places to look.

For each decision, name:

the role that owns it
the guardrails they use
the financial or customer threshold they may approve
the conditions that require escalation
the person who handles the escalation
where the final decision is recorded

The important part is not the approval limit by itself. It is the reasoning the team can reuse. “Ask Jeff” transfers no capability. “The location manager may approve service recovery up to this amount when these conditions are present” gives the decision a home.

If approvals still collect in the owner’s inbox, the owner bottleneck is already visible. The next step is to separate the decisions that need founder judgment from those that only arrive there because no one else has a clear lane.

3. One value-critical workflow from trigger to result

Do not begin by documenting every department. Choose one workflow that materially affects revenue, margin, cash, customer experience, or compliance, then map it from the event that starts the work to the evidence that it finished.

For a service business, that might be lead-to-scheduled-job, quote-to-approval, completed-work-to-invoice, or complaint-to-resolution. For a professional services firm, it might be proposal-to-staffing or deliverable-to-billing.

Capture:

What starts the work?
What information must be present before it moves?
Who owns each handoff?
What system records the status?
Where does the work commonly wait?
What proves the workflow is complete?

Write what happens today, not what the policy says should happen. A buyer testing execution capacity will care more about the real handoffs than the preferred version described in a manual.

This is also where tools, assistants, and automations should be documented. Name the operational job the tool performs, the inputs it uses, the person who checks the output, and what happens when it fails. A software list shows what the company bought. A workflow record shows how the company operates.

4. The exception path

Normal work is easy to document because it follows the expected sequence. Operational maturity becomes visible when something does not.

A missing part delays a job. A customer asks for a concession outside policy. A location is short-staffed. A report does not reconcile. An automation produces an uncertain result. The question is whether the exception has a defined route or becomes an emergency that travels through personal messages until the founder resolves it.

For each value-critical workflow, record:

what stops the normal path
who sees the exception first
what information must travel with it
who can resolve it
when it must move higher
how the resolution returns to the workflow
whether the cause should change the standard process

Keep a simple exception log for 30 days. The purpose is not to count mistakes. It is to identify where the operating system is asking a person to compensate for missing rules, weak inputs, or an unclear handoff.

Repeated exceptions usually point to better documentation priorities than a broad request for every department to write its SOPs.

5. The backup test for critical roles

A process is not transferred because a document exists. It is transferred when another person can use it.

Choose the roles that hold important customer relationships, operating knowledge, financial controls, system access, or approval authority. For each role, identify the recurring work that would stop if that person were unavailable for two weeks.

Then run a practical test:

Give the backup person the current workflow record.
Let them complete one normal cycle of the work.
Do not let the primary owner fill gaps verbally as they appear.
Record every question, missing input, unclear decision, and unavailable system access.
Update the operating record from what the test revealed.

The gaps are not evidence that the team failed. They are the work. A document written by the expert will usually omit the judgment the expert no longer notices they are applying.

West Monroe’s April 2026 exit-readiness guidance makes the broader point directly: buyer-ready operations, data, and technology foundations should be built before diligence starts, not treated as a last-mile exercise (West Monroe, April 30, 2026). The backup test turns that principle into something a founder-led company can begin this month.

What not to document first

Three efforts create activity without producing much evidence of transferability.

A company-wide SOP campaign. It spreads attention across low-risk and high-risk work at the same time. Begin with the workflows and decisions that carry economic or customer consequences.

A software inventory without operating context. Knowing which systems exist does not show whether they are used consistently, who owns the data, or what happens when information disagrees.

A polished process map that no one has tested. A diagram can hide missing judgment behind clean boxes and arrows. Put the record in another person’s hands and watch where the work stops.

The goal is not to make the operation look complete. It is to make the current operation legible enough that risks, dependencies, and improvement priorities can be addressed before a buyer finds them under time pressure.

A 30-day operational maturity test

You can make meaningful progress without pausing the business for a documentation project.

Week 1: Choose one value-critical workflow and define the operating measures connected to it.

Week 2: Record decision rights, handoffs, and the normal path as it runs today.

Week 3: Log exceptions and update the record with the information and judgment each exception required.

Week 4: Ask a backup owner to run one cycle using the record. Capture where they still need the founder or primary expert.

At the end of 30 days, you should have more than a procedure. You should have evidence of how work moves, where it depends on one person, and what to fix next.

Daloy’s operational due diligence checklist covers the broader areas a deal or operating team should examine. If you are preparing one company for investment or exit, the Private Equity page explains how Daloy approaches operating readiness. When the symptoms are visible but the highest-value starting point is not, an Operations Review can help isolate the workflows, decisions, and dependencies worth addressing first.