Operational Due Diligence Guide for Smarter Deals
Learn operational due diligence end-to-end — process, checklists, red flags, metrics and how custom software and AI reduce ODD risk before close.
You're three days from signing. The financial model assumes the acquired team can handle more customers, the legal review has found no blocking issue, and the integration plan says the systems will connect after close. Then someone asks a basic question: who owns the workflow when an alert arrives, which system contains the source record, and what happens if the AI classifier sends a high-risk case to the wrong queue?
No one has a reliable answer. The business may still be attractive, but its operating model hasn't been tested under new ownership, higher volume, or automation. That's the gap operational due diligence is designed to close.
Table of Contents
- Introduction Why Operational Due Diligence Decides Deal Outcomes
- What Operational Due Diligence Really Means
- When and Why to Run Operational Due Diligence
- Inside the Operational Due Diligence Process and Timeline
- Core Domains Checklists Metrics and Red Flags to Test
- How Custom Systems Integrations and AI Reduce ODD Risk
- Next Steps Sector Playbooks and Handoff Deliverables
Introduction Why Operational Due Diligence Decides Deal Outcomes
A buyer can inherit a company with strong revenue and still discover that every important process depends on one founder, one engineer, or a chain of manual handoffs. A support team may know how to resolve incidents, but only because experienced employees recognize patterns that never made it into the software. An AI workflow may appear efficient in a demonstration, yet lack approval rules, audit trails, or a human escalation path.
Financial diligence can test reported performance. Legal diligence can examine obligations, rights, and exposures. Commercial diligence can challenge market assumptions. None of these, by itself, proves that the operation can execute the plan after closing.
Operational due diligence is the execution test. It asks whether people, processes, technology, data, controls, and AI-enabled workflows can produce the promised outcome consistently. It also identifies what must be rebuilt, integrated, documented, or governed before growth turns a small weakness into a deal problem.
The discipline became mainstream rather than niche by the mid-2010s. In a 2014 operational due diligence survey, institutional investors reported conducting operational due diligence an average of three times for new investments during the prior twelve months. Approximately three quarters said they had conducted some form of ODD on half or more of their investments during the prior two years. The same industry review described ODD as expanding beyond traditional diligence into carve-outs, build-ups, and value-creation analysis.
A useful ODD handoff doesn't end with a list of red flags. It gives the COO a ranked view of operational risk, a practical architecture direction, named owners, and a build sequence for the first 100 days. The result is a deal team that knows not only what could fail, but what to design before failure becomes expensive.
What Operational Due Diligence Really Means
Think of a business as an aircraft. Financial diligence checks the fuel and the flight economics. Commercial diligence tests whether passengers want to fly the route. Legal diligence checks the permissions, contracts, and obligations. Operational due diligence inspects the engine, cockpit, maintenance procedures, and crew coordination. A profitable route still fails if the aircraft can't operate reliably.
In plain language, ODD evaluates whether the company's operating system can deliver its business plan. That operating system includes people and decision rights, recurring workflows, internal software, integrations, data quality, security controls, service providers, compliance routines, and the way teams respond when something goes wrong.
Three jobs of operational due diligence
ODD has three practical jobs:
- Validate operational reality: Compare documented procedures with what employees do. A process map may say that every high-risk customer receives a review, while interviews reveal that staff bypass the review when the queue becomes busy.
- Size risk and remediation: Identify the control gap, its likely operational consequence, and the cost or effort required to address it. “The workflow is fragile” isn't useful unless the team can show where it breaks and what replacement is feasible.
- Find value-creation levers: Locate opportunities where integration, automation, or custom software can improve throughput, decision speed, visibility, or resilience without rebuilding the whole company.
The boundaries matter. ODD isn't a second financial model, a legal opinion, or a generic technology audit. It may use financial, legal, and commercial findings as inputs, but its central question remains operational: can the business execute the plan with the systems and controls it has?
For a growth-stage company, that question changes again. The buyer isn't only looking for misconduct or missing documentation. The buyer needs to know whether the operating model can survive scale, ownership change, and AI adoption. A manual approval chain that works for a small team may fail when intake volume rises. An AI agent that summarizes cases may create hidden risk if nobody owns the final decision.
Practical rule: Treat every operational finding as a design question. Ask which workflow, control point, integration, or decision right needs to change before close.
When and Why to Run Operational Due Diligence
A deal can look financially attractive yet fail after closing because the operating model cannot absorb new ownership, volume, or automation. Run ODD when an acquisition, private equity platform investment, add-on, strategic investment, or pre-sale preparation changes how the business must operate. It matters most when growth has outpaced documentation, decisions depend on a founder, coordination remains manual, or core workflows are about to change.
Match the trigger to the question
In an M&A transaction, ask whether the combined business can operate as one system. Can the buyer connect customer intake, service delivery, reporting, and approvals without duplicate records or interrupted work? A custom M&A buyer scoring engine shows the kind of workflow ODD should examine. The review should test whether scoring logic is understandable, source data is reliable, exceptions reach a human, and someone owns the process after closing.
For a private equity platform or add-on, repeatability becomes the test. Can the operating model support another acquisition, or does each transaction create another collection of manual workarounds? ODD should identify processes suitable for shared services, systems that need to connect, and controls that must be consistent before the platform expands.
A strategic investment creates a different operating question. The investor may rely on the target's technology, data, or delivery capability without taking full control. The review should define dependency boundaries, service expectations, access rights, and escalation paths when something fails. In a pre-sale exercise, the seller uses the same examination to reduce uncertainty before buyers turn operational weaknesses into a lower price, delayed closing, or heavier conditions.
Scope early because budget and timing can constrain the review. One private equity report estimates that acquirers typically spend about 1% of total deal value on due diligence, representing roughly $80 billion over the next five years, as described in Accenture's private equity diligence report. The report's referenced industry context places operational diligence costs at approximately $100,000 to $300,000 per private equity transaction, with mid-market diligence budgets reaching $250,000 to $500,000.
The spend earns its place when findings alter the deal terms or determine the first post-close build sequence. Average private equity holding time remains above six years, while exits fell 17% in 2023 compared with 2022. A longer hold and fewer exits make late discovery more expensive. ODD therefore works like a pre-integration design review, testing whether people, process, technology, and AI workflows can survive scale, ownership change, and automation.
Inside the Operational Due Diligence Process and Timeline
A focused ODD process should create visible progress each week. The exact duration depends on scope, access, and complexity. For a business in the $500K to $20M revenue range, a tightly defined review can be organized around a short diagnostic and working session. A larger platform needs broader evidence, more stakeholders, and deeper testing. Avoid promising a fixed duration before the team understands the operating surface.
Start with hypotheses
The first phase defines the transaction context and the questions that matter. Examples include:
- Can the current customer onboarding workflow handle the planned growth?
- Which processes depend on one employee or undocumented knowledge?
- Where do systems lose data between intake, decision, delivery, and reporting?
- Which AI opportunities are safe to automate, and which require stronger controls?
Request the current organization chart, process maps, architecture diagrams, system inventory, KPI definitions, incident records, automation descriptions, and integration documentation. Don't ask for every document available. A narrow evidence request produces better interviews and faster course correction.
Test the stated process against the real process
Interview executives, operations leads, frontline users, engineers, data owners, and anyone who handles exceptions. Ask each person to walk through a recent case from intake to completion. Then compare the stated workflow with the actual sequence of clicks, handoffs, approvals, overrides, and rework.
A good walkthrough ends with evidence. That may include event logs, sample records, access settings, workflow configurations, incident tickets, or audit trails. If an AI classifier is used, inspect representative inputs, outputs, confidence handling, escalation rules, and the record of human overrides.
Review systems and controls together
Technology review shouldn't sit apart from operations. Trace the data through the systems that create, transform, approve, and report it. Test whether integrations are bidirectional where needed, whether failed syncs generate alerts, and whether users can identify the authoritative record.
Then test control points. Who can approve a high-risk action? Who can change a model prompt or routing rule? Can the business recover if a key service, vendor, or internal system becomes unavailable? Kroll's operational due diligence framework specifically identifies business continuity measures such as documented RTO and RPO targets and the date of the last disaster-recovery test as actionable review areas.
Synthesize into decisions
The final output should distinguish immediate deal risks from post-close improvements. Each finding needs an owner, evidence, operational consequence, recommended action, dependency, and decision status. A finding that says “replace the system” is incomplete. A useful finding says which workflow fails, why the current architecture causes the failure, what a safe interim control looks like, and what build sequence removes the underlying dependency.
Use the final working session to challenge assumptions with the people who'll own the operation after close. That meeting often reveals whether a proposed remediation is deployable or merely attractive on paper.
Core Domains Checklists Metrics and Red Flags to Test
A useful ODD review treats the company as one connected operating system. People create and approve work, processes define the sequence, technology moves information, data supports decisions, controls constrain risk, and KPIs reveal whether the system is performing. A weakness in one layer often increases pressure on the others.
| Domain | Evidence to Request | Sample Metric | Red Flag |
|---|---|---|---|
| People and organization | Organization chart, role definitions, succession notes, access ownership, interview notes | Decision queue age or escalation volume | One founder, engineer, or operator owns a critical workflow |
| Process and controls | Workflow maps, approval rules, audit logs, exception records, operating procedures | Cycle time or rework rate | Staff rely on undocumented tribal knowledge |
| Technology and integrations | Architecture diagram, system inventory, integration settings, failure alerts, ownership records | Incident volume or failed handoff count | Fragile automation breaks without clear alerts |
| Data and reporting | Data dictionary, source definitions, report logic, sample records, reconciliation evidence | Duplicate record rate or reporting variance | Leaders use conflicting versions of the same metric |
| Security and compliance | Access matrix, policy set, incident history, vendor reviews, recovery documentation | Recovery target performance or unresolved control gaps | Broad access, weak separation, or untested recovery |
| Operational performance | KPI definitions, trend reports, service queues, exception analysis, customer-impact records | Throughput, backlog, or resolution time | Metrics reward activity while hiding quality problems |
People and process
Start with the handoffs. Ask who receives an item, who decides what happens next, who can override the rule, and who notices when the item stalls. A process is not mature because it has a diagram. It's mature when the team can execute it consistently, measure exceptions, and transfer ownership without losing context.
Technology and data
Inspect integrations at the failure boundary. A successful happy-path demo doesn't prove resilience. Ask what happens when a source system changes a field, an API call fails, a duplicate arrives, or an AI output falls below the required confidence. For reporting, trace a KPI back to its source record and confirm who can alter the definition.
Security, compliance, and resilience
The CAIA operational due diligence white paper summarized 109 hedge fund failures from 1994 to 2005 and attributed 54% to fraud, 33% to financial issues, and 13% to operational risks. It identified misappropriation of assets or theft and misrepresentation of asset existence among the most common operational failure modes. For custom systems, the practical implication is clear: test custody and authorization chains, independent verification, segregation of duties, and cash movement approvals rather than trusting performance history or polished dashboards.
Control test: Verify who can create, change, approve, and release a high-impact action. Then confirm that an independent record shows what happened.
Operational materiality should rank findings by both likelihood and consequence. A minor interface inconvenience may be easy to tolerate. A single-person dependency that controls customer access, cash movement, model rules, or incident escalation deserves immediate attention even if it hasn't caused a visible failure.
For teams assessing insurance operations, a connected insurance operations dashboard can be a remediation pattern, but the diligence question comes first. Which source systems feed it, who owns the definitions, how are exceptions routed, and what happens when the underlying data is incomplete?
How Custom Systems Integrations and AI Reduce ODD Risk
ODD becomes valuable when findings turn into a practical remediation design. The choice isn't always “buy a new platform” or “do nothing.” Often, the better path is to connect the systems already in use, automate the fragile handoffs, and add targeted decision support where the risk is understood.
Choose the right discovery model
Use fixed-price delivery when the workflow, users, data sources, acceptance criteria, and boundaries are clear. That approach works well for a defined internal dashboard, a known integration, or a scoped admin panel.
Use paid discovery when the diagnosis is incomplete. If stakeholders disagree about the process, the source data is inconsistent, or the AI use case is still exploratory, forcing a fixed build price creates false certainty. The discovery should produce an architecture document, prioritized workflows, risks, and a recommended sequence. A useful comparison of building versus buying AI tooling can help frame that decision without treating generic software as a substitute for operating-model fit.
Design for failure, not just speed
System integrations should create a single working surface for the team. A case can move from intake to classification, routing, approval, and reporting without repeated copy-paste. Reliable orchestration should include retries, duplicate handling, clear ownership, monitoring, and alerts when a handoff fails.
AI can support narrow, auditable tasks:
- Classification: Sort inbound documents or requests into known categories, with uncertain cases routed to a person.
- Routing: Send a high-severity incident to the correct owner based on explicit rules and relevant context.
- Summarization: Prepare an incident history or client file for a reviewer, while preserving links to source records.
- Prediction: Flag likely delays, operational risk, or lead fit for human review rather than making an irreversible decision.
AI deployment has measurable operational potential. A 2026 industry summary on AI in IT operations reports 31% fewer critical incidents and 28% faster mean time to resolution among organizations using AI in IT operations. A separate AI workflow automation analysis reports potential operational cost savings of 20% to 30% and an average ROI of 235% within three years.
Those figures don't remove the need for diligence. Another 2026 enterprise AI summary reports that only 39% of organizations see any enterprise-level EBIT impact from AI, with most of those reporting a contribution below 5%. The lesson is to govern the workflow, not celebrate the model. Test EU AI Act exposure where relevant, document data lineage, monitor model bias, preserve human approval for material decisions, and assign an owner for prompt, model, and policy changes.
Next Steps Sector Playbooks and Handoff Deliverables
The right ODD output is a working package, not a presentation that disappears after signing. Ask for a findings memo, a ranked risk and opportunity register, an architecture document, a build sequence, and an ownership plan. The client team should know what to change, why it matters, who owns it, and how to operate it without depending permanently on the builder.
Sector context changes the emphasis:
- Private equity: Prioritize repeatable platform processes, add-on integration, management capacity, and value-creation sequencing.
- SaaS: Test customer onboarding, support routing, product telemetry, revenue operations, and the handoffs between sales, implementation, and renewal.
- Real estate: Examine asset-level data, approval chains, vendor coordination, and reporting across properties or projects.
- Energy: Focus on field operations, service dependencies, incident response, regulatory evidence, and data from distributed assets.
Choose an Operations Diagnostic when you need a brief intake that identifies the three highest-ROI builds and one to avoid. Choose an Operations Audit when recurring workflows require a deeper, fixed-price assessment with ROI ranking, an architecture document, and a recommended build sequence. After ODD, use the first 30 days to assign owners, establish interim controls, connect the most important data flows, and start the highest-ROI build that removes a material dependency.
Operational due diligence should leave the business more designable than it found it. The strongest teams don't stop at “this could break.” They decide which workflow must change, which system should own the decision, and how the operation will remain reliable when volume, ownership, and automation all change at once.
Internal Systems offers operational diagnostics, fixed-price operations audits, custom internal software, system integrations, resilient automation, and AI-powered workflows for teams that need to turn ODD findings into owned operating systems. Visit Internal Systems to assess your highest-ROI builds and create a practical sequence from diagnosis through independent handoff.