Operational due diligence when the target has no documentation

You document a target's processes in three weeks by reading what the company already produced: the spreadsheets, wikis, email threads and meeting notes. Generate the process description from those artifacts, then use management interviews to confirm it and to chase the gaps. Interviews alone do not fit the timeline, and they describe the process as designed.

The clock is always the same. Signed LOI, a few weeks of exclusivity, and a report that somebody will use to move money. Nobody has time to be thorough, so the work is deciding what to be thorough about.

What does operational diligence actually need to see?

Not an org chart and not a policy binder. It needs to see how the revenue gets produced and collected, and how fragile that is.

For a services target, that comes down to a short list:

The handful of processes that touch revenue: onboarding a client, delivering the work, billing, collections, month-end close
Which of those run on a system and which run on a person with a spreadsheet
Who the person is, and whether anyone else could do it
Where a manual step sits between the source data and a number in the financials
What breaks when volume doubles, which is the whole thesis behind most deals

That last bullet is the one the investment committee cares about. A process that works at forty clients and falls over at eighty is a cost line the model does not have.

It also feeds the quality of earnings work directly. If a QofE provider is adjusting revenue and nobody can say how the revenue schedule gets built, the adjustment rests on a number nobody can reproduce. Process documentation is what turns "management says" into "here is how it is computed."

Why does the data room never contain it?

Because it does not exist, and nobody is hiding it.

The data room is built by counsel and finance. They upload what is already a document: contracts, financial statements, the cap table, a SOC 2 report if the company has one. A SOC 2 report is useful, and it covers controls. It does not describe how an analyst gets from a client's raw file to an invoice.

Then there is the folder called "Processes" that somebody created in a hurry. It holds a Confluence export from 2021, a SharePoint page with three of nine steps filled in, and a PowerPoint with the word "workflow" in the title. Every document is accurate about a process that has since changed.

The real procedure lives in an Excel workbook with a macro, and in the head of the person who knows not to touch column R. That is not a failing of this particular target. It is how a lot of companies between ten and two hundred people work.

How do you document a target's process in three weeks?

You flip the order. Instead of interviewing first and writing second, you read first.

Week one, you get read access to what exists. Not the code, not the production systems. The working material: the wiki, the shared drive, the Smartsheet projects, the email threads between the delivery team and the finance team, recordings of the meetings where people walk through the work. Ask for it in the first request list, because the target will say yes more readily to "send us your existing process documents" than to "let us watch."

Then you generate a draft procedure for each of the five or six processes that matter. Zipper Blueprint for Operations is built for this job: reading those sources and drafting the process as it appears to run, including the steps, systems, handoffs and exceptions people keep mentioning in email.

A draft is not the deliverable. It is what makes the interviews worth having.

Week two, you interview, and the questions change. You are no longer asking an operations manager to describe billing from scratch. You hand her a page and ask what is wrong with it. People correct a document in ten minutes that they would never have volunteered in an hour. And when she says "that is how it is supposed to work, but in practice," you have found the thing you were paid to find.

Week three, you reconcile. The gaps between the generated process and what management tells you are the findings.

Why does generating beat interviewing, inside a deadline?

Two reasons, and neither is about the technology.

Interviews do not scale. Each one is an hour of calendar time from someone with a day job, plus the hours to write it up. With three weeks and a target who is nervous about the deal, you get a handful of interviews and you spend them on the loudest people.

And people describe the process as designed. This is not dishonesty. It is how memory works, and it is how incentives work when the person across the table knows the report decides the price. The email thread from last March, where someone reran the whole reconciliation by hand because the export was broken, does not have an opinion about the deal.

Artifacts are the record of what happened. That is the argument, and it is not a subtle one.

What should go in the report?

Keep it short enough that the investment committee reads it.

A process map for each revenue-critical process. One page each, steps and owners.
Source for every claim. A step that came from a spreadsheet says which spreadsheet. A reader should be able to check you.
A key-person table. Process, the person who runs it, whether a backup exists.
Manual touchpoints. Every place a human re-keys, copies or adjusts a number between source and ledger.
What you could not determine. Say it plainly. A gap in the documentation is a finding about the target, and honesty here is what makes the rest credible.

The last item matters more than it looks. A diligence report with no stated unknowns reads as either naive or padded. A generated draft that says "approval step inferred from two emails, no owner confirmed" is doing its job.

One boundary to respect: generated documentation tells you what the process is. It does not tell you whether the people running it are any good, or whether management will cooperate on the transition. That is still interviews and judgment. This shortens the time to the point where those conversations are informed.

What does this change at integration?

It means you do not start day one at zero.

The usual post-close story is ninety days of the new owner learning how the business actually runs, usually from the same two people who are now deciding whether to stay. If the diligence work already produced source-linked process documentation, that package is the first draft of the integration plan. Someone can see which processes to automate, which to leave alone and which person is not allowed to take a long vacation.

It also gives the target's own team something to react to. Documentation they did not have to write, and can correct, is the version that actually gets maintained.

Frequently asked

Is generated process documentation defensible in a diligence report? It is as defensible as its sources. Every step should trace to a named document, thread or recording that a reviewer can open. A claim with no source goes in the unknowns section, not the findings.

What if the target will not share their wikis and email? Then you scope down to what they will share, and the refusal is itself information. Most targets will share an export of a shared drive or a wiki space long before they share a mailbox, and a draft built from that alone is still better than a blank page.

Does this replace management interviews? No. It replaces the first half of each interview, the part where you ask someone to recite a process from memory. You still need the conversation to learn what the artifacts cannot show.