When business processes depend on people, they also depend on their absence

A Manual Process Can Work for a Long Time. Until It Starts Slowing Down the Entire System

In many companies, processes appear to work at first glance. A document is created, forwarded, reviewed by someone, supplemented with data by someone else, and another person calls the client. The task is eventually completed.

This is exactly why the manual model is often tolerated for a long time. It does not seem like a major problem, but rather a practical way of working that the team has become accustomed to.

Why do companies accept this model for so long?

With a smaller workload, a manual process can seem flexible:

• people know who to contact,
• they know where to look for a document,
• they know the informal rules,
• they know what needs to be done as the next step.

The process therefore “works.” Not because it is well managed, but because people continuously keep it together.

Where is the real problem?

The weakness of the manual model is not that it is not fully digital. The problem lies elsewhere: the process logic is not embedded in the system but in people.

In practice, this means that the workflow relies on:

• manually moving tasks forward,
• the memory of specific people,
• informal agreements,
• emails, Excel spreadsheets, and phone calls,
• personal experience instead of clear rules.

Such a model may be operational, but it is also fragile.

When does the problem become fully visible?

Most often in four situations:

1. When volume increases

What works with dozens of cases starts creating delays, duplication, and downtime when there are hundreds.

2. When complexity increases

More departments, more approval steps, more clients, or more branches mean more room for uncertainty.

3. When a key person is missing

Vacation, sick leave, or an employee leaving the company quickly reveals how much know-how exists only in people's heads.

4. When the process needs to scale

A manual model can only be maintained up to a certain point. After that, it starts consuming more energy than the value it actually creates.

Why is a manual process risky?

If a process depends primarily on people, the company loses:

• predictability - it is unclear where delays will occur,
• replaceability - the process is difficult to hand over,
• resilience - the absence of one person slows down the entire workflow,
• scalability - as volume grows, so does chaos,
• visibility - the status of the process is determined through people rather than through the system.

What should you take away from this?

A manual process is not a problem because it involves paper, Excel, or email. The problem is that it is:

• difficult to predict,
• vulnerable when people are unavailable,
• poorly transferable,
• and more dependent on individuals than is healthy.

As a company grows, such a model is no longer sufficient. The process must stop relying on the memory and initiative of individuals and begin operating according to a clear system logic.

Why does this matter?

Manual processes usually do not stop all at once. Much more often, they gradually become slower, less transparent, and harder to coordinate.

And that is their main risk: the company feels that the process is still working, while in reality it is being kept in motion only through the additional effort of people.

Where the problem actually originates

The bottleneck is not just paper. The bottleneck is a process that operates outside the system

When people in a company say that a process is still “on paper,” the problem is often reduced to the format. To the fact that Excel, email, or printed documents are being used. In reality, however, these tools themselves do not necessarily have to be the main cause of inefficiency.

The real problem arises when the company uses them to manage the entire process:

• without clear rules,
• without a single source of visibility,
• and without system logic that determines what should happen next.

The problem is not the tool. The problem is the approach

Paper, Excel, or email can serve their purpose within a process. The weakness appears when they begin replacing the workflow itself.

This means that:

• tasks are assigned verbally or ad hoc,
• status is determined through phone calls or messages,
• documents are moved forward by forwarding emails,
• spreadsheets substitute for process logic,
• the next step depends on what someone happens to remember.

At that point, the company is no longer working with a managed process, but with an informal flow of information.

How does a parallel informal workflow emerge?

In many companies, a second, unofficial layer of operation develops alongside the official systems. The process formally exists, but in reality it moves outside the system.

Typically, it looks like this:

• a document is stored in one tool,
• its status is tracked in a spreadsheet,
• the next step is handled via email,
• an escalation is made by phone,
• an exception is explained verbally,
• the final decision is known only by a specific individual.

The result is a process that functions, but is neither transparent, consistent, nor easily transferable.

Typical signs of a manual model

Most often, this situation manifests itself very similarly across departments and industries.

Paper, Excel, Emails, and Phone Calls as the Main Process Driver

Tools that were supposed to support the process begin effectively managing it.

Every step must be handed over manually

The process does not move forward automatically according to rules, but only when someone consciously forwards it, reminds others, or communicates it.

The process has no single source of truth

Information about status, document versions, responsibility, and the next step is scattered across multiple people and tools.

Exceptions are handled improvisationally

Instead of a clear scenario, there are individual agreements, operational interventions, and ad hoc decisions.

No one knows exactly what happens when a person is unavailable

If the person who knows the process best is absent, the organization often discovers that the system records documents but cannot reliably manage their movement.

Why is this model so deceptive?

Because from the outside it can appear functional. Documents move, tasks get completed, and the team manages to cope. The real weakness only becomes visible when the process needs to be:

• accelerated,
• transferred,
• scaled,
• audited,
• or shared across multiple people and departments.

That is when it becomes clear that the organization's process know-how is not owned by the organization as a whole, but by the individuals who keep it in their heads.

So where is the real bottleneck?

Not in the fact that the company uses paper, spreadsheets, or email. The biggest problem lies elsewhere: the process is not embedded in the system but in the human transfer of information.

This means that the organization depends on:

• people's memory,
• their availability,
• their personal experience,
• and their ability to keep the process moving manually.

And that is precisely why a normally functioning model eventually becomes an operational risk.

Why does this matter?

As long as a process is managed primarily through people, the company may continue operating, but only at the cost of greater dependency, lower predictability, and weaker replaceability.

If a workflow is to be fast, controllable, and scalable, it is not enough to simply record documents. The company must also have embedded in the system what should happen to them next, who is responsible for the next step, and how the process moves forward without manual intervention.

Operational Impact

When a process depends on specific people, the company loses both speed and resilience

The biggest problem with manually managed processes is not just that they are slower. The problem is that their performance changes depending on who is available, who remembers what, and who is still holding the entire process together in their head.

Such a model may work for a certain period of time. In the long term, however, it weakens two things that are critical for a company: speed and resilience.

What does the company actually lose?

The process moves more slowly

Every subsequent step has to be manually handed over, reminded, or verified. This means more waiting time between tasks, more downtime, and a weaker ability to maintain pace as volume increases.

Continuity depends on individuals

If the person who “knows how things work” is absent, the process slows down or stops. Not because the task is objectively complex, but because the process logic is not sufficiently understandable to others.

People coordinate the process instead of doing their work

Teams then deal not only with the content of tasks but also with moving them between steps. They call each other, check statuses, search for documents, explain exceptions, and manually connect what should be connected by the system.

The risk of errors increases

The more manual interventions there are, the greater the risk that a step will be skipped, a document will be sent in the wrong version, or a decision will be delayed simply because information did not reach the right person at the right time.

Management loses visibility

If process know-how remains informal within the team, company leadership has less visibility into where workflows are actually slowing down, where recurring exceptions occur, and which bottlenecks are systemic rather than accidental.

The company's external perception also weakens

Clients, candidates, or partners do not perceive internal staffing circumstances. They only perceive that responses take too long, the process is unclear, or the result does not arrive within a predictable timeframe.

The highest-risk moment comes during growth

As long as the workload is lower, a company can compensate for many things through team experience and operational communication. As the company grows, however, it becomes increasingly expensive to keep processes moving through human effort alone.

That is when it becomes fully apparent that the problem is not just people’s workload, but the workflow design itself.

In practice, it usually looks like this

• more people ask about the status of the same case,
• handover and substitution are slow and inaccurate,
• management learns about a problem only when delays occur,
• the process relies on improvisation for every exception,
• performance fluctuates depending on the availability of specific individuals.

At that point, it is no longer just an administrative issue. It is an operating model that reduces process throughput across the entire organization.

Why does this matter?

Companies often explain this situation as a natural consequence of growth, increased volume, or employee workload. In reality, however, it is a process setup that makes the workflow unnecessarily dependent on individuals.

And that is a crucial difference. An overloaded team is one problem. A process that can function only when specific people manually hold everything together is a much deeper problem.

From individual know-how to system logic

A business process cannot depend on individual memory but on clear rules

When a company starts hitting the limits of manually managed workflows, a common reaction is to “improve communication,” introduce more control, or add another checklist. However, this usually addresses only the symptoms. Real progress happens only when process logic stops relying on the memory, experience, and initiative of individuals and is transferred into the system.

One distinction is important: the goal is not to remove people from the process. People remain essential wherever decisions, evaluations, approvals, or exception handling are required. What a modern company needs to eliminate is the excessive dependence of processes on people for routinely moving tasks to the next step.

In other words, the value of people should lie in decision-making, not in manually holding workflows together.

What does a System-Driven process look like?

The fundamental difference is that the process is no longer “guided” by whoever remembers what comes next. Instead, it has clearly defined logic that governs its movement.

This means the system knows:

• what should happen in the current step,
• who is responsible for it,
• what should happen after it is completed,
• and how the process should behave if an exception occurs.

A workflow configured this way is far more transparent, stable, and less dependent on individual experience.

Three pillars of a System-Driven process

1. Process logic embedded in the system

Every step must have clear rules. It is not enough for the team to “roughly know” how things work.

The process should be designed so that it is clear:

• which task is currently being performed,
• who should perform it,
• what follows after completion,
• which conditions move the process forward,
• and what happens if a deviation or exception occurs.

This is precisely what separates a managed workflow from an informal circulation of tasks.

2. Visibility and Replaceability

A well-designed process must not be understandable only to the person who has been keeping it “in their head.” It must also be understandable to a colleague, manager, or substitute employee.

For a workflow to be resilient, the company needs to know:

• what state the process is currently in,
• who is next,
• where delays have occurred,
• which steps have been completed,
• and what still needs to be done.

Visibility is the foundation of replaceability. Without it, every absence becomes a risk.

3. Automation of routine transitions

If the next step can be triggered automatically, it should not depend on whether someone sends an email, makes a phone call, or remembers the task.

Typically, these are situations where the system can:

• automatically assign the next task after approval,
• send a notification to the right person,
• move a document to the next stage,
• activate a follow-up step without manual intervention.

This is where the greatest time savings and the greatest reduction in process friction occur.

What actually changes for the company?

When process logic is embedded in the system, the organization stops depending on individual improvisation. This does not mean less flexibility. It means less chaos in recurring and routine activities.

In practice, the main changes are:

• the process moves more predictably,
• substitution becomes easier,
• onboarding of new employees is faster,
• exceptions are handled within a clear framework,
• management gains better visibility into the actual state of workflows.

All of this happens without the company constantly increasing pressure on people to “be more careful.”

System logic does not mean rigidity

A common concern regarding workflow automation and formalization is that the process will lose flexibility. In reality, the opposite is true. The more a process depends solely on informal information transfer, the worse it handles changes, exceptions, and absences.

A system-driven workflow does not mean that everything must be fixed and inflexible. It means that the organization has a clear framework within which it can safely move the process forward even when conditions change.

This is exactly why such a model increases:

• resilience to employee absences,
• the ability to handle greater volume,
• control over exceptions,
• and stability during company growth.

What should you take away from this?

A business process should not depend on a specific person knowing what needs to happen next. It should depend on the system knowing it, while people participate in the process where they provide real value.

That is a fundamental shift. Not from people to technology, but from improvisation to management. And it is precisely this shift that separates a process that is merely operationally manageable from one that is ready to grow together with the company.

From improvisation to orchestration

What a well-designed process looks like in practice

The difference between a manual and a well-managed process is best seen in day-to-day operations. Not in a presentation, but in how quickly the process moves when a new document arrives, the status of a case changes, or the person who normally handles it is absent.

In a manual model, the workflow is held together mainly by people. In a managed model, it is held together by rules, visibility, and automatically connected steps.

What does a manual model look like?

In practice, this model is usually well known. The process continues, but only because the team keeps moving it forward through its own effort.

Typically, this means that:

• the process is moved forward manually,
• status is checked through people,
• the next step depends on the initiative of a specific person,
• exceptions are handled operationally,
• replaceability is weak,
• know-how remains scattered across the team.

At first glance, such a model may seem flexible. In reality, however, it creates a lot of unnecessary friction, which increases further as volume grows.

What does a managed model look like?

In a well-designed process, the team does not need to keep reminding itself what should happen next. The workflow has its own logic, and the system knows what should happen next

This means that:

• steps are defined in the system,
• tasks are assigned automatically,
• notifications move the process forward,
• status is continuously visible,
• documents and decisions are traceable,
• the process is replaceable and less vulnerable.

Such a model does not reduce the role of people. On the contrary, it frees them from routine process coordination and allows them to focus on decision-making, control, and working with content.

What is the practical difference?

The biggest difference is not that the company uses a different tool. The difference is in who or what keeps the process moving.

In a manual model, the movement of the workflow depends on human initiative. In a managed model, the process moves according to clear logic.

This has a direct impact on:

• processing speed,
• replaceability,
• the number of downtimes,
• management’s ability to see a problem in time,
• and the overall predictability of the process.

Area	Before	After
Process management method	The process "sticks" between people and moves forward mainly thanks to individual initiative and informal coordination.	The process is governed by clearly set rules and system logic.
Process status overview	The overview is scattered across emails, spreadsheets, documents, and individual team members.	The process status is readable and continuously visible in one managed workflow.
Assignment of tasks	The next steps are moved manually depending on who remembers what or who needs to be addressed.	Tasks are clearly assigned and follow each other according to a defined procedure.
Dependence on a specific person	The absence of one person creates a problem because know-how and context are often tied to an individual.	The outage of one person will not stop the entire workflow, because the process is replaceable and readable for others.
Ability to detect a problem early	The manager only sees a problem when the process is already delayed or someone starts asking about the status.	The organization has a better overview of the status of the process and can identify delays and bottlenecks earlier.
Degree of control	Control over the process is weaker and depends on individual information from people in the process.	The organization has greater control over the course of the process, its status, and individual steps.
Process predictability	The process is less predictable and its course may change depending on the availability of people and the current situation.	The process is more predictable, stable, and less vulnerable to change, growth, or absence.

 

Where is this shift most visible?

Most quickly in processes that are repeated, have multiple steps, and involve more people or departments. That is exactly where improvisation stops being enough.

A well-designed workflow helps especially where it is necessary to:

• meet deadlines,
• ensure replaceability,
• reduce dependence on specific people,
• improve traceability,
• handle higher volume without increasing confusion.

What should you take away from this?

Improvisation can keep a process running. Orchestration, however, makes it stable, readable, and scalable.

And that is the difference between a workflow that works only when the “right people are in the right place” and a workflow that is ready to function reliably even during growth, change, or absence.

Why is this shift important?

Many companies today still try to improve process performance mainly through people: more consistent communication, stricter control, more detailed spreadsheets, or higher expectations of individuals. However, this approach has a clear limit. The more a process depends on individual discipline, the more vulnerable it is during growth, change, or the absence of a key person.

Real progress therefore does not happen when a company adds another email, another checklist, or another Excel file. It happens when it can transfer process know-how from people’s heads into a system that is:

• readable,
• managed,
• replaceable,
• auditable,
• scalable.

This kind of model creates a stronger foundation for growth. The process is no longer dependent on who is currently available, who remembers the exception, or who knows “how it is done.” Instead, it is built on rules that are understandable to both the team and management and that can keep the workflow moving even under higher workload

What does the company gain?

Companies that can manage this shift gain more than just higher efficiency. Above all, they gain a more stable and more resilient operating model.

Specifically, this means:

• higher process continuity,
• lower operational vulnerability,
• faster onboarding and substitution,
• better control over performance,
• less chaos during growth.

This is especially important in an environment where the volume of work is increasing, processes are connected across departments, and pressure on both speed and accuracy is growing. At that point, it is no longer enough for a process to “somehow work.” It must be manageable at a larger scale without opacity and dependence on individuals automatically increasing along with growth.

What should you take away from this?

The future therefore does not belong to companies that simply have more disciplined people or more detailed spreadsheets. It belongs to those that can embed process logic in the system so that it is transferable, readable, and resilient even when the team, volume, or conditions change.

And that is precisely the difference between a company that manages processes operationally and an organization that can manage them in the long term.

Companies will always have people. What matters is whether the entire process will also depend on them

People will remain key in every company. They are the ones who make decisions, evaluate, communicate with clients, handle exceptions, and take responsibility for the result. However, that does not mean that the mechanics of the process itself must also depend on them.

This is exactly where operationally mature companies differ from those that function, but only at the cost of high individual effort. If know-how is scattered in the heads of individuals, the company is more vulnerable during absence, growth, and change. If, on the other hand, process logic is shared and embedded in the system, the organization gains higher stability, better replaceability, and greater control over what is actually happening in the process.

Today, competitive advantage therefore does not arise only from the quality of the team. It also arises from the quality of the process model on which that team works. A company that can function predictably even with higher volume, personnel changes, or growing complexity is simply more operationally mature.

If processes in your company are still moved forward manually and their functioning depends on specific people, the problem often does not lie in the need to add another control mechanism or another spreadsheet. Much more often, it is necessary to properly set up the logic of the workflow itself.