Where deal teams lose answers, and how a questions log fixes it

Somebody reads the management accounts at nine in the evening and notices that gross margin moved four points in H2. They write it down somewhere — a notebook, a Slack DM, the corner of a spreadsheet — and go home.

Where that observation goes next is one of the least designed parts of most diligence processes, and it is where a surprising amount of value leaks out.

A question is its own thing

It is tempting to treat questions as either tasks or checklist items. Both collapses cause problems.

Treat it as a checklist item and the list fills with speculative lines that may turn out to need nothing from anybody. The list stops being a list of things that must be true and becomes a list of things somebody wondered, which is the beginning of a list nobody trusts.

Treat it as a task and it becomes work assigned to a person, when quite often the honest answer is that nobody needs to do anything — the answer is already in the file and needs finding rather than doing.

A question is a third thing: a gap in what the team knows. Some gaps close themselves, some need a person, and only a minority need the counterparty.

The four things that can happen to a question

Worth being explicit about, because a process that has only one path takes that path every time — and the one path is almost always "email the borrower".

It is answerable from the file. Somebody already sent something that answers it, in a document nobody has re-read. This is the most common outcome and the one most often missed, because checking is more expensive than asking.

It was answered before. On this deal, or on the last deal with the same counterparty eighteen months ago. Worth surfacing with its date, because an old answer is evidence with a shelf life rather than a fact.

It is answerable without them. Filing history, directorships, charges, sanctions, anything on the public record. Establishing it yourself costs nothing and spends no credibility. It should also be labelled as externally sourced — a figure you found and a figure they told you are different kinds of fact, and blending them in the file is how a soft number ends up in a committee paper looking hard.

It needs them. Now you ask, and the ask should say what you checked. Not at length — one line. It is the difference between a question that reads as diligent and one that reads as the first thing that occurred to someone.

Why it should be visible to the whole team

The second-worst outcome for a question is that it gets lost.

The worst is that two analysts ask the borrower the same thing on the same day. That is a specific, recoverable-from-but-embarrassing event, and it happens for a structural reason: the question lived in one person's head, so nobody else could see it had already been asked.

A shared log fixes that for the price of writing questions down where other people can read them, which is not a technology problem.

Answers are an asset

The part most teams underrate.

An answered question is not finished business. It is a fact about a counterparty that will be asked again — by someone else on this deal, or by you on the next facility to the same borrower in eighteen months.

Kept, it compounds. By the second deal with a counterparty, a meaningful share of the questions have already been answered once, and the deal is quietly faster for a reason nobody can point at. Not kept, every deal starts from nothing and the borrower gets asked things they answered for you last year, which they remember even when you don't.

Promotion

Some questions turn out to be material. "Why did gross margin drop four points" can end up being the deal.

When that happens the question should become a requirement on the checklist, carrying its history — who asked it, what was checked, what the counterparty said. Starting a fresh item and losing the trail is how the reasoning behind a requirement gets separated from the requirement itself.

And a question that gets promoted on three deals running is not three questions. It is a line missing from your template, and the process should say so out loud rather than leaving somebody to notice.