Kennisbank

Recording and following up on conversations: what lies beneath

A conversation with a language model produces an answer. What happens to that answer after the window is closed is a different question. Recording means that a conversation, a summary, or a decision ends up somewhere that someone — or something — can pick up later. Following up means that a next step is attached to it: a task that gets created, a colleague who receives a signal, a file that gets updated. Both sound simple. Both ask more of an organization than the conversation itself.

What recording concretely involves

Recording is not saving a chat log. It is converting something that arose in free-form language into a form a system can read: a field in a CRM, a line in a logbook, a status in a project tool. That conversion requires a structure that is already in place. A language model can summarize a conversation, but it cannot decide which system that summary belongs in if the organization has not established that itself. Where files, customer contacts, or decisions are already registered somewhere, a foothold exists. Where that registration happens verbally, by email, or nowhere at all, nothing is created automatically.

What following up concretely involves

Following up is the step after recording: someone or something has to respond to what has been recorded. That could be a notification to an employee, a task in a schedule, or a follow-up question to another system. Here, recording touches on other forms of AI use. A recorded conversation that triggers a task borders on what agents that carry out work independently require. A recorded conversation that calls for a judgment — is this signal important, should this be passed on to someone — touches on what decision support requires of an organization. And a recorded conversation that needs to be picked up across multiple departments touches on what coordination between departments requires. Recording by itself has limited value; the value lies in what happens afterward, and that is rarely just technical.

What this requires before it works

Three things determine whether recording and following up produce anything of value.

The first is a place to write to. A system, a database, a structure that already exists and that can absorb new information without someone having to transfer it by hand. Organizations that still keep customer contact, decisions, or statuses mainly in people's heads and loose emails do not yet have that place. Recording without a destination is an export that no one opens.

The second is an agreement about who follows up on a recorded signal. A conversation that results in "customer wants to cancel this" is only useful if it is clear who picks that up and within what timeframe. Without that agreement, the organization collects notes instead of actions.

The third is a way to check whether the recording is accurate. A summary that says something slightly different from what was actually discussed is a risk that grows as more conversations are recorded without checks. This does not necessarily require a person who reviews everything, but it does require some form of spot-checking or feedback that catches errors early enough.

Where this connects within the organization

Recording conversations rarely stands on its own. A customer conversation that gets recorded is often part of a chain of steps that follow — an application that needs to move forward, a file that needs to be completed. What that requires is described at chains where steps follow one another. Recording can also be a form of signaling: a conversation in which something unusual is said should produce a notification somewhere. That touches on what monitoring and signaling requires of an organization. And where a conversation is essentially a document that needs to be read and summarized — an intake, a complaint, a long phone call that has been transcribed — it touches on what reading and summarizing documents requires. In practice these forms overlap; an organization that has one of them in order is often better positioned with the others.

What this does not answer

This page describes what recording and following up involve and what needs to be in place for them. It does not answer the question of which part of a specific conversation, file, or process can actually be taken over by AI. That depends on the type of conversation, the systems already in place, and the work behind each task. Anyone who wants to know this for their own work can find, at the work scan from FTE TO AI, a way to have it calculated per task which part of it can be taken over — not as an estimate made in advance, but as a calculation based on the work as it is currently done.