Kennisbank

What a chain of consecutive steps asks of your organization

A chain is something different from a task. With a task, someone, or something, performs an action and delivers a result. With a chain, one step logically follows another: the outcome of step one is the input for step two, and an error that arises there travels along to everything that comes after. A quote that starts with an incorrectly entered customer detail, a file that reaches the next department in the wrong status, a signal that wasn't followed up before it escalates. Chains are everywhere in an organization, and they can rarely be assigned to a single department or a single system.

That makes chains attractive and difficult for AI at the same time. Attractive, because the promise of automation lies precisely in linking together steps that are currently handed over manually. Difficult, because a chain only works if every link is sufficiently reliable and the handover between links is clearly defined. One weak link, and the chain breaks — often only visible a few steps further along, when no one knows anymore where it went wrong.

What happens beneath the chat window

A chat window shows a single interaction: a question, an answer. A chain plays out at the layer beneath that, where systems pass on data, change statuses, and decisions trigger the next step. For a chain to work, that layer needs to be capable of a number of things.

First, it must be clear when a step is completed and the next one may begin. That sounds obvious, but in many organizations that isn't fixed anywhere — it lives in the head of the employee who knows when a file is "complete enough" to pass on. Second, there must be something that lets step one know about an error in step two, instead of the error silently traveling on to step three. Third, there must be some form of ownership over the entire chain, not just over the individual steps — someone or something responsible for the whole, not only for their own part.

These three points lie close to what is treated separately elsewhere. Coordination between departments is about the handover itself: who passes something on to whom, and what can get lost in the process. Monitoring and signaling is about the moment at which it must become clear that a step is completed or, conversely, stuck. A chain pulls these separate elements together into one whole, and is thereby more vulnerable than the sum of its parts.

What this asks of the organization

To hand over a chain to AI, or part of it, something else must first be in place: the chain must exist as a described process, not merely as a habit. As long as the handover between step two and step three only exists because two colleagues have known each other for years and know what to expect from one another, there is nothing a system can take over. The organization must make explicit what is now implicit.

That calls for data management that goes beyond storing data. It is about recognizable, consistent handover points: the same fields, the same statuses, the same definition of "done" at every link. Without that consistency, a chain works only as well as the people who keep the exceptions in their heads — and that is precisely the fragility that stands in the way of a pilot. A chain that runs flawlessly in a test environment stumbles in practice over the file that was filled in just slightly differently than expected, or the department that applies its own interpretation of a status.

There is also an organizational side to this. Who owns a process that runs through three departments? Who decides what happens when a step gets stuck: send it back, escalate, or something else? These questions already exist before AI comes into the picture, but chains that run partly or wholly automated make them unavoidable. A system does not improvise when the rules are missing; it stops, or it proceeds on the basis of an assumption no one has checked.

Two themes that are often hidden within chains deserve separate attention: reading and summarizing documents as a frequently recurring step within a larger chain, and recording and following up on conversations as the link where many chains practically begin — a phone call, an intake, a report that sets the rest in motion.

Why this cannot be tested in a corner

A chain is difficult to capture in a small pilot, precisely because its value lies in the connection between steps that usually belong to different teams. A pilot that only looks at step two, without including the handover from step one and to step three, tests something different from what needs to happen in practice. Why a pilot that only works in its own corner delivers nothing is worked out on this page, and it may apply even more strongly to chains than to standalone tasks.

What precedes this

Before an organization can assess whether it is ready to entrust chains to AI, it is useful to know how mature the organization is on the fundamental dimensions: organization, IT infrastructure, and data management come first, because a chain that rests on shaky data or unclear responsibilities does not become sturdier by running a system through it. The maturity assessment from hybridresourcing maps this out across five levels and seven dimensions, with a plotting round in which multiple people score separately, so that it becomes visible where perceptions within the organization diverge. The tool is under construction; those who want to get started with this can sign up for the waiting list.

Where this page is about whether the organization can carry a chain, the work scan from FTE TO AI is about something different: it calculates per task which part of the work can be taken over by AI. That distinction becomes relevant as soon as you know which chains your organization has — the work scan shows, per step in that chain, where the potential for takeover lies, without saying anything about whether the organization is already ready for it.