Processes Are the Glue of an Organization
Every organization has a written ambition. Goals are announced, structures approved, titles handed out, committees convened. Then one customer walks in with an ordinary request, and within three days it turns out nobody knows where it is, who owns the next step, or when an answer will come. The strategy was fine. The work simply had no road to travel on.
This article argues that what holds an organization together is not its structure, its policies or its software. It is the process: the agreed way work moves from start to result. Where no clear process exists, people quietly fill the gap, and the organization ends up hanging on their relationships, memory and goodwill.
We will follow one case from beginning to end: Salma, operations manager at a service company, and a customer activation request that got lost among three departments. In each section you will see what changes for her and try a short exercise on work in your own organization. You will leave with a working definition of a process, five steps that turn a path living in people's heads into one that works for a stranger, and a way to test the result before you announce it.
“Salma, her company and the figures in this article are a hypothetical case for illustration and do not refer to any real organization.”
Salma looks for a lost request
Salma runs operations at a company that serves other businesses. On Sunday morning she received an angry message from the head of a client firm: their service activation request had been filed nine days ago and nobody had called. She opened the system and found the request logged under the sales representative, status «in progress». That status says nothing. It fits a request that arrived yesterday and one that has been forgotten for a week.
She called the representative, who said he had handed the papers to finance last Monday. Finance said the contract lacked a company stamp and that they had asked a sales colleague for it verbally. The colleague said she had been on leave and never received anything. Meanwhile the operations team was asking whether the activation order had been issued. Nobody knew.
Salma spent three hours moving between phones and chat threads to piece the story together, and the fix finally came from one man. Majed, a long-serving finance officer, told her: «I know this kind of case. Send me the papers and I will walk it through.» He closed the request in two days. Salma thanked him, but she left the meeting with a question she could not set aside: what if Majed had been on leave?
“Nobody failed in this story, and yet the customer waited nine days.”
Look at what actually happened. Sales did its part, finance did its part, operations was ready. Every department did what it knew to be its job. What was missing was whatever links those jobs into one chain: who receives from whom, with which document, within how many days, and what we do if something is missing.
What did the company lose in those nine days?
- Time: three hours of an operations manager spent chasing one request, hours that could have gone into improving the path itself.
- Trust: a corporate client began its relationship with waiting and no answer.
- Clarity: the question «where is the request?» was answered by phoning people, not by looking at a path.
- Resilience: Majed was never part of the design, yet he became its only safety valve.
“Think of the last request that ran late in your organization. Who rescued it in the end? Was it a clear path, or someone who simply knows how to get things moving?”
“Five minutes, now: pick one request that ran late this month. List everyone who touched it, in order, with when each received and passed it on. If you cannot finish the list without phoning someone, you have found your first signal.”
Why did the path not work without Majed?
Ask Salma about the activation path and she will say: «We have a procedure.» It does exist, in a file written four years ago with a simple drawing of four boxes: sales, finance, operations, customer. The trouble is that the drawing shows who takes part. It does not show how work moves between them.
The difference is large. The drawing says finance reviews the request. It does not say what exactly it reviews, within how many hours, what it does on finding a gap, or to whom it sends the request back. People fill those blanks from experience. Majed filled them skillfully for years, until the blank itself became the source of his value, and so nothing changed.
How do organizations end up tied together by people instead of processes?
It happens without anyone deciding it. When a company is small, work moves on relationships: I know who to call, so I call them. It works because people are few and know each other. Then the company grows, the method stays, and the number of people multiplies. Years later the link between departments is the address book on employees' phones.
That arrangement is brittle, and its brittleness shows up in moments every manager knows. A skilled employee leaves and takes with them a whole path that was never written down. A new manager arrives and the way of working changes because nothing anchors it. Pressure rises and shortcuts appear, because the official path is unclear or does not match reality.
Three signs that people, not processes, are your glue:
- Answering «where is the request?» takes a phone call.
If you cannot tell where work stands from a single look at a path, the path does not really exist.
- One name keeps surfacing in every crisis.
Majed, in our case. A capable person is not the problem. The problem is that the organization cannot function without them.
- Two departments produce the same thing.
When handoffs are not drawn, each side rebuilds what it assumes the other did not.
If you recognize one of these, the answer is neither hiring more Majeds nor writing a longer document. The answer is first to understand what a process really is, which is where we turn next.
What is a process, and why call it glue?
Here is a plain definition. A process is a series of agreed activities that begins with a known event and ends with a result someone benefits from. Each activity has an owner, and each move between two activities has a clear document or signal. Those four elements are what make a path a process: a start, a result, owners and handoffs.
Salma's activation request begins when the customer signs the contract and ends when the service works at the customer's site. Between those points it passes sales, finance and operations. If all of it is described in a way every party knows, the process exists. If each department knows only its own piece, the process is incomplete, however handsome the drawing.
Why call it glue?
Departments are like bricks and the process is the mortar between them. A brick alone does not make a wall, and however good the bricks, a wall without mortar collapses under its first load. In the same way an excellent department alone does not produce good service, because the customer does not see your departments. The customer sees what passes between them.
A process joins five things people usually keep apart. It joins strategy to execution, so a goal like «the fastest activation in the market» becomes a path with a duration. It joins policy to behavior, so what the policy says shows up in a particular step. It joins departments through handoffs. It joins decisions to whoever holds the authority. And it joins performance to measurement, because only a defined path can have its duration and quality measured.
“Structure tells you who works with whom. A process tells you how work moves between them.”
Step one: draw the path from event to result
The problem this step solves is that each department sees only its share, so nobody sees the whole picture. The representative knows the moment of signing, finance knows the moment of review, operations knows the moment of activation. The customer lives the entire journey, and nobody inside the company shares that view.
Start from the two ends, not the middle. Write the event that starts the path in a specific phrase: «the customer signed the contract». Then write the result that ends it in a phrase the customer can verify: «the service works and the customer has received confirmation». Only then fill in what lies between, in short verbs: the request is logged, documents are checked, the activation order is issued, the service is installed, confirmation is sent.
Gather the activity owners in one session and let them describe what they actually do, not what they should do. You will usually find a gap between the two, and that gap is the most valuable thing the session produces. If an activity turns up that only one person knows, mark it. It is the heart of the hidden dependency.
In the case now: Salma put the sales representative, Majed and an operations delegate in one room for two hours. They found the path had seven steps, not four, and that three of them were in no file. One was Majed's: he checks that the company name on the contract matches the commercial register. Nobody ever asked him to, but he has done it for years because he once saw a contract stopped over a misspelled name.
“Apply it now: choose one path in your organization. Write its starting event and its result on a sheet of paper, then ask two people who work on it to fill in the middle separately. Compare the two sheets. Every difference is ambiguity your organization is paying for today.”
Step two: name one owner for the whole path
The problem here is that every step has an owner but the path as a whole has none. When the customer's request ran late, nobody had the standing to say: «this one is mine.» Everyone had done their part and nobody was responsible for the road. So Salma had to trace the request herself, even though she holds no authority over any of the three departments.
A process owner is not a manager above the managers, and not the person who performs every step. It is the person who answers for the path from end to end: does it work, how long does it take, where does it stall. Three things belong to the owner. The right to convene step owners when the path stalls, the right to propose changes to the steps, and the right to present the path's performance to senior leadership.
Pick this person by one test: who suffers most if the path fails? In our case that is operations, which receives the customer's complaint first. Then write the name at the top of the path itself, not in a side file, so that everyone who opens the path sees it.
In the case now: Salma was named owner of the path «activating service for a corporate client». Finance's first reaction was: «Are you going to monitor us?» Salma answered that what she wanted was for someone to speak for the path when it stalls, and that Majed himself would be the first to feel relief, because he would no longer be summoned to rescue the situation every time.
“Apply it now: write one sentence: who gets asked in your organization when a whole path runs late, not a single step of it? If no name comes to mind, or two names do, you have found a path without an owner.”
Step three: design the handoffs
Where did the customer's request get lost in our case? Not inside a department but between two. When the representative passed the papers to finance, nothing defined what a complete handoff was. Is an email enough? Must finance confirm receipt? What if a stamp is missing? And when finance asked for the stamp verbally from an absent colleague, the request vanished from everyone's sight.
A handoff is the moment responsibility moves from one party to another. To work, it needs four things in writing: exactly what is handed over, in what form, within how many hours the receiver must confirm or return it, and what happens if it is returned. The last point matters most, because a return with no clear address leaves the request hanging in mid-air.
Make the handoff visible. Instead of verbal messages or side chats, use a small checklist that travels with the request, with specific items ticked as they are met. The receiver checks the list first: if it is complete they take responsibility, and if it is not they send the request back, with the reason in writing, to the sender.
In the case now: Salma and the team wrote a six-item handoff card between sales and finance, including: the contract is signed and carries the client's stamp, the company name matches the commercial register, contact details are complete. They fixed that finance confirms receipt within four working hours, and that any gap returns to the representative in writing, with the request marked «incomplete, awaiting representative» instead of «in progress». The vague status no longer exists.
“Apply it now: choose one handoff on the path you drew. Write four sentences for it: what is handed over, in what form, when the receiver must confirm, and where the request goes if something is missing.”
Step four: tie the policy and the decision to a specific step
Salma's company has a policy stating that every contract with a corporate client must have the company's details checked before activation. The policy is sound and has been approved for two years, yet it appears in no step. Nobody was assigned to apply it, so its application depended on Majed, who does it out of experience. This is a policy that exists but is not practiced, because no process turns it into work.
The fix is to ask of every policy and decision that touches the path: in which step does this happen, who checks it, and what is the evidence that it happened? Then place the answer inside the step itself, not in a separate document. When «company details are checked against the commercial register» becomes part of the path and of the handoff card, the policy becomes daily behavior without anyone having to remember it.
The same goes for authority. Some requests need an exception, such as activating before the stamp arrives for a major client. Who may decide that? If it is not written, whoever happens to be in the room will decide. Write the exception into the path: who approves, within how many hours, and what gets recorded.
In the case now: Salma added an explicit commercial-register check to the path and assigned it to whichever finance officer is on duty, not to Majed alone. She also wrote the exception rule: early activation for a corporate client is allowed with the finance director's approval, provided the representative completes the stamp within three days. And she added to a simple board the number of exceptions each month, so she can tell whether the exception has become the rule.
“Apply it now: pick one policy that touches your path. Write the name of the step where it is applied and the name of whoever checks it. If you find no step, you have a policy suspended in mid-air.”
Step five: measure the path, then test it on a real case
A path can look lovely on paper and still not work, and you cannot know until you measure it. The problem this step solves is that organizations tend to improve by feel: they sense a path is slow, change something, then sense it is better. Without measurement you do not know whether it truly improved, or where.
Choose only two measures at first. The first is the path's duration from event to result, which is what matters to the customer. The second is the number of times a request is returned because something is missing, which reveals the quality of the handoffs. Record both weekly in a simple line, and do not build an elaborate dashboard before the path has proven itself.
Then test the path on a real case before you announce it. Take a fresh request and walk it through the steps exactly as written, with nobody stepping in with their experience. If it takes a phone call, you have found a gap not yet closed. The best test is to hand the request to a new employee who has never worked in the company and ask them to follow the path using the paper alone.
In the case now: Salma asked a new operations employee to follow an actual request from the start. The employee found one gap: nothing said what happens if the customer does not answer the confirmation message. Salma added the step: a reminder after two days, then a call after three. As for measurement, two months later the average duration had fallen from nine days to three, and returned requests had roughly halved. Those are the hypothetical case's figures, offered to show the kind of effect you are looking for.
| # | Element | Question | Met | Partly met | Not met |
|---|---|---|---|---|---|
| The definition | |||||
| 1 | Start event | Does the path begin with an event stated in a clear phrase? | |||
| 2 | Result | Does it end in a defined result the customer benefits from? | |||
| 3 | Activity owners | Does every activity on the path have a known owner? | |||
| The five steps | |||||
| 4 | Path owner | Is one person named responsible for the path end to end? | |||
| 5 | Handoffs | Does every handoff have a written four-item card? | |||
| 6 | Policy and decision | Is each policy tied to a step, an owner and evidence? | |||
| 7 | Measurement | Are duration and number of returns measured weekly? | |||
| 8 | Testing | Was the path tested on a real case before it was announced? | |||
Assess the path your customers complain about most.
“Apply it now: define the two measures for your path and write their value today, even as an estimate. Then pick a new employee, or someone from another department, and ask them to trace one request using only the written path. Note every time they have to ask.”
Salma, three months later
At the end of the quarter Salma returned to the question that had worried her: what if Majed is on leave? It happened in the third month. Majed was away for two weeks, and twelve requests went through without anyone noticing his absence. Nobody phoned Salma and nothing was rescued at the last minute. The path did its job.
Nor did Majed lose anything. He came to see the path as his own achievement, because his long experience had moved from his head onto the handoff card, and he is now invited to improve the path, not to rescue it. What Salma did was not replace people with procedures. She gave their expertise a place to accumulate, so it does not vanish when they are away.
What do you take with you?
A process is not a drawing, a file or an audit requirement. It is the agreed way work moves from an event to a result, with known owners and clear handoffs. It is the glue that makes departments behave as one organization, so the customer sees one service rather than three departments.
The five steps in brief:
- Draw the path from event to result
As people actually do it, and mark the steps only one person knows.
- Name one owner for the whole path
Whoever suffers most if it fails, with the right to convene the parties.
- Design the handoffs
What is handed over, in what form, when the receiver confirms, and where a request returns.
- Tie policy and exception to a step
Every policy has a step, an owner and evidence, and every exception has someone who holds it.
- Measure and test
Two measures first, then a real case walked through by someone who knows nothing.
Start this week with one path only, the one your customers complain about most. Draw it, name its owner and write one handoff card. Then see what changes. And if you want to build this on a method, RAISO's process management practice courses lead you through these steps on a path from your own organization, with exercises and ready-made tools. Get in touch and we will help you choose the right path to begin with.
