A prospect sends a spreadsheet.

A hundred and fifteen questions. Architecture, security, backups, encryption, subcontractors, business continuity, data protection.

Nobody is surprised. It isn't the first. It won't be the last.

And yet, the moment you open the file, the same hesitation comes back.

Either you start everything from scratch: you reopen the documentation, dig through the configurations, chase the technical team again.

Or you pull out the previous client's questionnaire and copy whatever looks similar.

The first option wears you out.

The second reassures you.

Both lose what the company knows.

Every questionnaire, back to square one

The first questionnaire of this kind that I handled in a structured way had forty-three questions.

Answering it meant pulling together seven technical sources and going back and forth with the team that ran the service. On top of that came the writing itself:

• understanding what the prospect was really asking;
• finding the information;
• verifying it was still true;
• deciding what we could disclose;
• putting the answer back into the expected format.

Somewhere between three and six hours of work. Several people pulled in. No guarantee the prospect would become a client.

This was not an exceptional situation.

Every prospect sends its own document. A spreadsheet one time, a Word file the next, a PDF after that. The frameworks change. The numbering changes. The wording changes.

But the topics keep coming back.

That is what makes it so frustrating: you feel you are answering the same question for the tenth time, and yet you have to rebuild it every time.

Then the document goes out.

And all the research stays locked inside the file that was sent.

Copying looks like the sensible solution

Faced with this repetition, the reflex is obvious.

You keep the old questionnaires. You look for the one that resembles this one most. You reuse the answers.

The same reflex exists inside the company. One team needs a rule that belongs to another team: the mandatory fields of a form, a backup policy, a contractual limit. It copies the passage into its own documentation, to have it at hand.

In the moment, it works.

You save time. You avoid bothering the same people. You build on something that has already been written, and often approved.

The problem is that the gain is immediate, while the cost comes later.

And it comes without warning.

An old answer looks like knowledge

In one of the questionnaires we received, an answer was already filled in.

It stated that our ISO 9001 certification dated from 2017.

The sentence looked perfectly usable. It was precise, already written, placed next to the right question.

The correct date was 2018.

One year off. Nothing serious, on the face of it.

But that error made me understand something more important.

An old answer looks like knowledge. It has the shape of a statement. It is well written. It is reassuring.

Yet it is silent on what matters:

• who wrote it;
• what it rests on;
• when it was true;
• whether it still actually describes the product.

An old answer can come from a template, from another vendor, from an exchange nobody remembers anymore. It may have been right when it was sent and wrong today.

And with AI, that risk grows.

When an AI comes across an answer already written in a document, it happily picks it up. It has no reason to be wary of it. The sentence is assertive, well placed, consistent with the question.

The AI then only speeds up the spread of an error nobody has seen.

The copy diverges without a sound

The same mechanism exists between teams, and it is even quieter.

Take a very ordinary situation.

A product team is working on the quality of service reports. It relies on a rule that belongs to another team: the list of information required when closing a work order. It has read it, copied it into its own documents, and kept going.

Six weeks later, the work goes into review.

Someone spots a discrepancy.

The rule had changed in the meantime. The other team had changed the product. That was legitimate. It was even planned.

But nobody flagged it.

Nobody lied. Nobody made a gross mistake. The rule simply went on living where it was born, while its copy stayed frozen elsewhere.

That is what makes the problem so hard to spot: a copy that diverges makes no noise. It stays clean, well worded, credible. It has just stopped being true.

Faced with this, there are two ways to get it wrong, and they are symmetrical.

Pointing to the original avoids the copy. You consult the rule where it lives. But if nothing signals that it has changed, you keep relying on what you read six weeks ago.

Copying makes you independent. The copy no longer depends on the other team. But if nothing says where it came from, a year later you have a note that is right, or wrong, and nobody knows what it rests on.

So each move carries its own debt:

• a reference requires knowing when its source changes;
• a copy requires saying where it came from, how old it is, and what was reworded along the way.

The problem isn't copying or referencing.

The problem is doing it without writing down what each move requires.

Keep the facts, not the documents

For the questionnaires, I ended up changing my starting point.

I no longer wanted to build a library of answers to copy.

I wanted to build a memory of what we actually knew how to answer.

It started with a simple decision: file by topic, not by client.

A question labelled "14.6.l" by one prospect and a question labelled "CL-072" by another were about the same thing: backups. Filed by client file, they stayed strangers to each other. Filed by topic, they came together.

The question was no longer: "what did we answer to that client?"

It became: "what do we know how to answer about backups?"

And for each topic, we kept a verified fact, along with what makes it trustworthy:

• its origin: official documentation, a verified configuration, a test, confirmation from the team in charge;
• the date it was approved;
• the limits of what we can state.

The client's questionnaire kept its value. It showed what the market wanted to know, in its own words and with its own priorities.

But it no longer proved anything.

The request came from the client. The evidence came from us.

We also separated two things the old questionnaires mixed together: what serves to verify an answer, and what can be sent. The detail of a configuration can be essential to the internal reviewer without belonging in a document handed to a prospect.

The wording meant for the client was prepared on one side.

The evidence and the caveats stayed alongside it, for whoever had to approve.

Leave knowledge with whoever is responsible for it

The same principle holds between teams.

A rule has an owner. That is the team that maintains it, knows why it exists, and answers for it.

The first way to use it is to consult it where it lives, rather than keep a personal version of it. You rely on it without claiming to own it.

Sometimes that isn't enough. You need to freeze the exact version a decision rests on. You want to reword it for a particular use. You want it to stay available even if the original team reorganizes.

In that case, you can copy it.

But the copy has to keep its history: where it came from, on what date, and what was changed.

The difference between the two lies less in the move than in the responsibility:

• when I consult, the knowledge still belongs to the other team;
• when I copy, an independent version comes into my space, and I become responsible for how it is used.

That leaves a temptation everyone knows.

You often read another team's documentation. You spot an error. You know what to fix. It would take thirty seconds.

It is better to propose the correction than to make it.

Whoever spots an error does not decide where the knowledge ultimately belongs. It is the team responsible for it that judges whether the correction really describes its scope, or only the particular case of the person proposing it.

That is what stops a local result from quietly becoming a general truth.

A visible gap beats a plausible sentence

Filing facts by topic had an effect I didn't expect.

It exposed the gaps.

When a piece of information was missing, it was no longer possible to hide it behind an old wording. The topic was there, the question too, but no verified fact made it possible to answer.

The gap became visible.

And a visible gap can become an action.

Rather than filling the box with a reassuring sentence, you prepare a precise question for the team concerned. You note which lines of the questionnaire the answer will let you complete. You know whom to ask, and why.

That is probably the most important change.

A plausible sentence hides a risk.

An explicit gap turns it into identifiable work.

The fourth questionnaire

The fourth questionnaire had a hundred and fifteen questions. Almost three times as many as the first.

This time, we were no longer starting from a set of scattered files. The recurring topics were known, and for each one we knew where the verified facts were.

Ninety-six complete answers could be produced directly, without gathering anything new.

The rest of the document was sorted:

• solid answers, to be verified one last time;
• uncertain answers;
• a few questions impossible to handle with the information available.

The outstanding issues had changed in nature. We were no longer hunting at random for who knew what. What remained were commercial decisions, such as the length of a commitment, and a few one-off technical confirmations.

The remaining work was visible, assignable and bounded.

In my own practice, preparing a questionnaire went from three to six hours to about ten minutes to produce 80 to 90% of the document.

That figure can mislead.

It doesn't mean that 80 to 90% of the answers are certain and ready to commit the company. It means the document is largely prepared: the known answers are in place, their sources have been found, the weak points are flagged, the missing information has become precise requests.

Human review remains essential.

But it finally lands in the right place. The reviewer no longer spends their time digging through old files and asking the same people yet again. They verify the commitments, decide what can be said, and focus on what is new or uncertain.

What the company keeps

Starting from scratch and copying look like two opposite attitudes.

One wastes past work. The other reuses it without verifying it.

In fact, they rest on the same confusion: taking the document for the knowledge.

The document is made for one client, one moment, one format. It is necessary. But it is not where a company should keep what it knows.

What it knows lives in facts that keep their origin, their date and their limits, consulted where they live or copied with a note of where they came from.

The first questionnaire had required an investigation.

The ones that followed benefited from everything that investigation had taught us. A date error became a precautionary rule. A confirmation obtained from a team became a reusable fact. A question with no answer became a known gap rather than an oversight.

The prospect still gets their document.

The company, for its part, finally keeps what it learned while preparing it.

---

A note on the examples

The examples in this article draw on more than thirty years of practice in IT and team management, and on many conversations with peers. I have modified, generalized or recombined them: none describes a real client, product or organization, nor reflects my employer's data or positions. The opinions expressed are mine alone.