Map process owners before centralising software

Some companies start a centralisation project with a list of tools to replace. CRM, task management, files, internal requests, invoicing. The intention is good. The team already works with too many open tabs and information is scattered.

Then the new platform arrives. In the first few days, everyone logs in. A few weeks later, part of the team is back on WhatsApp, spreadsheets and private messages. The data is incomplete. Nobody knows which version of a document is the right one. And the owner concludes that the chosen tool failed.

Before discussing software, there is a less comfortable question: who is responsible for each process when something stalls, goes wrong or gets no answer? If that answer is unclear, centralisation will only organise the confusion inside a new system.

• A process without an owner always depends on someone remembering.

• The person who does a task does not have to be the person who answers for the result.

• The tool should follow a process already decided, not force an invented structure.

• The first map can be simple, as long as it shows who decides and who unblocks.

Start with the processes that cause friction today

Start where work gets lost, delayed or keeps raising the same questions. Do not make an inventory of everything the company does.

The first goal is to see where the lack of ownership is already costing the team time. Pick processes that cross people, departments or tools. Those are the ones that tend to get worse when software changes without preparation.

Look for concrete signs of missing ownership

Some phrases give away processes with no defined owner:

• “I thought you were handling that.”
• “Who approves this?”
• “The client sent it, but I don't know where it ended up.”
• “Maria knows how it's done, ask her.”
• “Is this sales or operations?”

You do not need a heavy audit to begin. Get the area leads together and ask them to point out the flows where these phrases come up. It might be onboarding a new client, preparing proposals, handling leads, dealing with complaints, approving purchases or passing information to invoicing.

Pick a few processes. If you try to map the whole company in the first round, you will get long meetings and a document nobody opens. Start with the processes that directly affect revenue, clients, delivery or financial control.

Make one important distinction

A process is a repeated sequence with a start, an end and an expected result. “Answering emails” is not a process. “Answering a sales enquiry received through the website and booking the next step” can be.

This distinction prevents vague maps. It also stops you from looking for an owner for a whole department when what you need is someone responsible for one specific flow.

Name the result before choosing the owner

Define what has to be finished. Only then choose who answers for it.

Many teams assign a person to a process without knowing what result that person must guarantee. The job title becomes the automatic answer: sales gets sales, operations gets operations, admin gets admin. But real processes cross functions.

Take one process and write a simple sentence: “This process is done when…”.

For example:

• A new sales enquiry is logged, qualified and has a next step booked.
• A new client has received the information request, the team has the context it needs and the first delivery has a date.
• An invoice has been checked, issued and sent with the correct details.

This sentence forces you to close ambiguities. If you cannot say when it ends, you will hardly know who failed or where the work stopped.

Separate responsibility from participation

The process owner answers for the final result. They do not have to carry out every step. One person may receive requests, another may prepare a proposal and a third may approve terms. Even so, one person should follow the flow and act when it gets stuck.

The owner should be able to answer four questions without searching too hard:

1. What goes into this process? 2. What has to come out? 3. Where does it usually get stuck? 4. Who can decide when there is an exception?

If the same person does, approves and checks everything, flag it. It is not always wrong in an SME. It may be the right measure at this stage. The risk appears when nobody sees the whole process, or when the company depends on one person who keeps everything in their head.

Separate the job from the occasional favour

An owner can only answer for the result if the team's time is where the map says it is. In some companies, a marketing person answers sales messages, packs orders when the warehouse is under pressure and still publishes content at the end of the day. It looks like teamwork. Sometimes it is. But when it becomes the normal way of working, nobody can tell whether marketing is bringing in opportunities, whether sales is closing deals or whether the warehouse is shipping well.

You may also conclude, possibly unfairly, that this person does not deliver. Perhaps they do not deliver because you asked them to do tasks that are not part of their job.

Any task outside someone's usual responsibility should answer four questions:

• Who asked for it?
• Why is it needed now?
• How much time will it take?
• What work from the main job gets pushed back?

It can live on a task board or in a tool the team already uses. What matters is not letting these detours become invisible. A real emergency can justify help. A recurring emergency points to a lack of capacity, a poorly designed process or an area with no real owner.

Build the map in a spreadsheet, not a presentation

Create a simple table for each process. The map should serve the people doing the work, not impress anyone in a meeting.

A spreadsheet is enough for the first version. If the team already uses a work management tool and everyone uses it well, you can record it there. But do not switch platforms just to draw the process.

Use these minimum fields

For each process, record:

| Field | Question to answer | | --- | --- | | Process name | Which flow are we describing? | | Final result | How do we know it is done? | | Process owner | Who answers when the flow fails or stalls? | | Who does it | Who carries out the main tasks? | | Who approves | Who decides on cases that need sign-off? | | Input | What starts the process? | | Output | What is delivered, recorded or communicated at the end? | | Current tools | Where does the information live today? | | Known blockers | Where are time, context or decisions lost? |

Do not confuse this map with a detailed manual. At this stage, you do not need to document every click or every exception. You need to make visible the path of the work and the people holding it together.

Draw the real path, not the desired one

Talk to the people who do the work every day. The owner knows the intention and the big picture. The people on the ground know the shortcuts, the failures and the requests that arrive outside the expected route.

Ask: “When a request comes in, what happens next?” Then keep going: “And then?” Keep the conversation on real situations. Ask for the last example, not the ideal version.

You will often find that a task supposedly logged in the CRM first arrives by phone, then sits in a note, and only enters the system if someone has time. Or that an approval depends on an informal message to someone who is out of the office. That is important material for the map. Do not clean it up to look more organised.

Appoint an owner with enough authority

Choose someone who can keep the process running and ask for changes when they are needed.

Putting a person's name on a row in a table solves nothing if that person cannot act. The process owner needs access to the information, time to follow the flow and room to ask for decisions.

In a small company, one person may own several processes. That happens. The question is whether the accumulation is temporary, deliberate and manageable, or whether it happened only because nobody else was asked to step up.

Test the owner with simple situations

Before you settle on a choice, walk through concrete scenarios:

• A request has gone two days without an answer. Who notices and decides what to do?
• Details are missing to issue an invoice. Who asks for the correction and follows it through?
• The client accepted a proposal with an unusual condition. Who approves it and updates the team?
• Someone is on holiday. Who takes over follow-up without losing context?

If the answer is “it depends”, ask what it depends on. There may be legitimate exceptions. What you should avoid is using “it depends” to hide a decision that was never made.

It is also worth separating the process owner from the line manager. A director can remain responsible for an area without being the right person to follow every operational blocker. Choose based on closeness to the work and the decision-making ability required.

Define decisions, deadlines and handover points

Write down the rules that stop the process from waiting. Without them, the owner gets a title and still has no means to act.

Three things deserve attention: what the owner can decide, when they should step in and how the work passes to another person or team.

Agree decision limits

Each process should have decisions the owner can make alone and decisions they need to escalate. Record this in a practical way.

For example, whoever handles sales enquiries can decide that a contact is not a fit and close the request. But they may need approval to offer special terms. Whoever runs onboarding can move a meeting date, but may not be able to promise a feature that does not exist yet.

When these limits are unclear, everything goes up to the owner of the company. The team waits. The owner becomes the bottleneck without meaning to. And centralisation turns into a system full of tasks waiting for approval.

Define visible handover points

A process that passes from one person to another needs a clear signal. It might be a status change, an assigned task, a required field filled in or a notification. The form depends on the team's maturity and the tool it already uses.

What matters is that nobody has to guess whether it is their turn to act.

A good handover also includes a way back. If sales receives a contact without enough details, it should not guess: it sends it back to marketing with a concrete reason. If the warehouse finds a discrepancy in an order, there should be a way to fix it before shipping. That way the error does not travel from area to area until it reaches the client, and repeated problems get a visible source.

Before you automate a handover, make sure it happens consistently. If there is still doubt about who receives the work, automation will only route the doubt faster.

Measure each process without mixing tasks

You can only manage with data when you know what each figure measures and who influences it. If everyone does everything, the indicators get contaminated.

Say you want to track the sales conversion rate. Marketing answers some contacts. A partner answers others by phone. A salesperson picks up requests that arrive by email. Some are logged, others stay in WhatsApp conversations. In the end, the rate looks low or high, but nobody knows whether it reflects reality.

Start with what you need to decide and what the team can confirm. Each record needs an owner and a clear definition. “Contact handled”, for example, has to mean the same thing to everyone: a call made, a reply sent and the next step booked. On that basis, you can also assess each person on the work that is theirs, rather than on how available they are to put out fires.

Only then choose what to centralise and automate

Choose software based on the map the team has approved and tested.

At this point, you can ask useful questions of a tool or a supplier. Do you need to see the status of each process? Link client information to tasks? Control approvals? Make sure a request does not move forward without data? Keep a history available to whoever picks up the case?

Without the map, these questions get replaced by feature lists. You end up buying capacity the company does not need yet, or configuring flows nobody can maintain.

Build maturity before automation

If the team does not yet log requests in a shared place, start by building that habit. If client data is incomplete, define useful fields and make someone responsible for keeping them up to date. If nobody tracks conversions or response times, create a simple view before asking for complex reports.

Automation makes sense when the process is already repeated, understood and followed. It can then cut manual steps, remind owners, create tasks or move information between systems. Before that, it can hide failures for a while and make them harder to fix.

At Seamless Doubt, this diagnosis comes before the proposal. Quickly configuring a poorly defined process only postpones, and makes more expensive, the conversation that has to happen.

Run a short test with one process

Pick a process with enough volume to observe, but without the risk of blocking the whole company. Define the owner, the steps, the single place for information and the handover signals. Try it with the team for a short period and collect the real problems.

Review with direct questions: where were there doubts? What information stayed outside the system? Which step was skipped? Was the owner able to step in? Only then adjust and roll it out to other processes.

Frequently asked questions

Does the process owner have to be the manager?

No. The manager can own the processes that need their frequent decisions, especially early on. But they should not get that role by default. Many processes work better with someone closer to the operation, as long as they have clear decision rules and support when they need to escalate.

What if two areas are responsible for the same process?

Both can take part. One must answer for the final result. Define where each area's responsibility starts and ends. For example, sales can be responsible until the proposal is accepted and operations from the formal handover to delivery. The handover point has to be visible and carry the information needed.

Should we document every exception?

Not at the start. Record the exceptions that happen often, that create risk or that block decisions. Rare exceptions can be dealt with when they come up. A useful map has to be easy to maintain.

How do we know we are ready to change software?

When you can show the path of the process, name an owner, explain the main decisions and identify the information that needs to be centralised. The team should also confirm that the map describes the real work. If there is still disagreement on these points, changing software will expose the problem, not solve it.

Conclusion

Start by choosing two or three processes where the disorganisation is already visible. Talk to the people who run them. Define the final result of each one. Appoint an owner who is able to follow and unblock the work. Record the handovers, decisions and blockers in a simple spreadsheet.

Then test the map in daily work. Fix what does not match reality. Only at that stage decide what information should live in a shared place and which tasks deserve automation.

Centralising tools can bring order. But order starts when each person knows what they have to guarantee, when they should act and who to ask for a decision.