A collective memory. How good is that?

A collective memory. How good is that?

Not a database. Not a directory with a home-made structure only you can navigate, however hard you tried. Not another place where we store everything because it might come in handy one day.

But an actual memory.

What an organisation really is

An organisation consists, in large part, of things people know.

Why a particular customer chose us in the first place. Why a process runs the way it does. What was agreed three years ago. Why that one exception exists. Which colleague knows exactly how that old system works. What was said on a phone call and never made it into the CRM.

An enormous share of that is not really written down anywhere.

We know how it should go, we know the process. But success is not always the result of a process. It sits in people’s heads.

In mailboxes. Chat threads. Documents. Tickets. Minutes. Applications. And sometimes simply in the memory of somebody who happens to have been here twelve years.

We call that institutional knowledge, but it is actually rather fragile. People forget. People leave. Systems get replaced. Context disappears.

And meanwhile we keep producing new data as though storing were the same as remembering.

It is not.

Record, Retrieve, Understand

Look at what we have asked computers to do over time. Three steps, and we have only just started the third.

Record. For decades we used computers to put information somewhere. The gain was in the storage itself: it was there, and it did not burn down.

Retrieve. Then it was about search. Indexes, filters, search boxes, and eventually one search box across everything. The gain was speed.

Understand. And now we are reaching the point where technology can also understand information in context. Not that something is there, but how it relates to everything else.

That is a bigger difference than it sounds, because a memory is not made of information. It is made of connections.

I do not only remember that something happened. I remember who was there, what I was wearing, what I ordered for lunch, why it happened, what came before it and what changed afterwards. It is that coherence that gives a memory meaning.

Why should an organisation not have the same?

A collective memory that does not only record that customer X raised a hundred and forty tickets last year, but that also understands those tickets came out of a migration, that agreements were made about it, that satisfaction improved afterwards, and that the same customer is now facing another major change.

Then data suddenly becomes history. Context. Perhaps even experience.

That means an organisation can, for the first time, genuinely learn from everything it has ever been through. Not because every employee knows everything. Precisely because nobody has to.

And then the uncomfortable side

Because a memory that never forgets sounds fantastic as long as it remembers what you need.

Until there is something you would rather have forgotten.

And here it gets concrete, in a way you do not see in a demo. Some things you are not even allowed to remember. A retention period is not a suggestion. A deletion request is not a preference. And “we did not keep it, it only exists in the system’s memory” is not a defence.

At Record and Retrieve that was still manageable. You knew where something was, so you could take it out.

At Understand you cannot. Once the model has learned the connections, removing the source document is not the same as forgetting what was inferred from it. The system still knows there was something about that customer and that employee, after you deleted the email.

That is not a reason not to do it. But it is the question you have to ask before you build rather than after: what is this memory allowed to forget, and how do you prove that it did?

I know few organisations with an answer. I am not sure I have one either.

Where to start

Not with a platform. With one question.

What is the sort of thing where you always think: now how did that go again?

That is where we start. Not because it is small, but because that one example shows you exactly how many connections are needed to answer it. And whether you actually want those connections made.