In most organizations, procurement is not unstructured.
There are defined processes, approval hierarchies, and systems in place to ensure control and compliance. On paper, it is designed to work efficiently.
And yet, in practice, it often feels slower than it should.
This is not usually because the process itself is flawed.
It is because the process is distributed across too many touchpoints.
One request, many touchpoints
A single procurement request rarely lives in one place. It typically moves through:
a requisition, raised by the person or team that needs the goods or service
approvals from a line manager, a budget holder and sometimes a finance or category lead
sourcing, where suppliers are identified, quotes are compared and terms are agreed
a purchase order, issued to the chosen supplier
receipt, where someone confirms that the goods arrived or the service was delivered
invoice matching and payment, handled by finance
Each of these steps serves a clear purpose. But they are not always connected in a way that supports continuous flow.
The requisition might start as an email or a form. Approvals happen in someone's inbox. Quotes sit in a spreadsheet or a shared folder. The purchase order is created in the ERP, and the invoice arrives through yet another channel. Each of these tools may work well on its own. The trouble lies in the handoffs between them.
The small inefficiencies that add up
This creates a set of small, recurring inefficiencies:
the same details re-entered from one document or system into the next
approvals waiting in inboxes because the approver does not have enough context to decide
back-and-forth emails to confirm specifications, quantities or budget codes
requesters chasing updates because they cannot see where their request has got to
supplier quotes and terms held in separate files that procurement has to piece together
differences between the purchase order, the delivery and the invoice that have to be checked by hand
Individually, these are minor interruptions. Collectively, they slow down the entire procurement cycle.
Why the delays are hard to see
Most of this lost time is waiting, not working. A request may only need a few minutes of attention at each step, yet take days to move from start to finish because it sits between steps: in a queue, in an inbox, or with someone who is waiting for a reply.
Because no single step looks broken, the slowness is easy to accept as normal. Each team sees its own part of the process running reasonably well. Nobody sees the whole journey.
The people who do feel it are at the edges. The requester waits without knowing why. The supplier receives an order later than expected, or with details that change after it was placed. Finance meets the problem last, when the invoice does not match what was ordered.
Following one request from start to finish
Consider an illustration. A site manager needs 200 pairs of safety boots for a new team that starts next month.
The site manager emails procurement with the quantity and a short description.
Procurement replies to ask for sizes, the safety standard required and which budget the cost belongs to.
Once the details are confirmed, procurement asks a few suppliers for quotes and records them in a spreadsheet.
The request goes to the budget holder, who asks why the recommended supplier is not the cheapest. The explanation is forwarded from an earlier email thread.
Procurement re-keys the agreed details into a purchase order.
The boots arrive in two deliveries, and the invoice does not quite match the order, so finance checks with the site and with procurement before paying.
None of these steps is unreasonable, and each one exists for a good reason. But the request has passed through several inboxes, a spreadsheet and more than one system, and the same information has been typed, checked and explained more than once. The delay comes from the gaps, not from the steps themselves.
Why more structure is not always the answer
Many procurement platforms attempt to solve this by introducing more structure—more defined workflows, stricter controls, and additional checkpoints.
While this improves governance, it can also make the process feel heavier, particularly for operational teams who need to move quickly.
Each new checkpoint is another handoff, and another place where a request can wait. When the formal route feels slow, people find ways around it. They raise requests at the last minute, split orders to stay under approval limits, or buy from a familiar supplier and sort out the paperwork afterwards. The result is less control, not more, which is the opposite of what the extra structure was meant to achieve.
Control and speed are not opposites. The aim is to keep the checks that matter while removing the friction around them.
Reduce fragmentation, not add layers
A more effective approach is not to add more layers, but to reduce fragmentation. That means ensuring that the core elements of procurement:
requests and requisitions
approvals and budget checks
supplier and catalog information
quotes and sourcing decisions
purchase orders, receipts and invoices
exist within a connected, continuous workflow.
In practice, this means information is captured once and carried forward. The approver sees the same context the requester provided. Procurement can see supplier history alongside the request. Finance can trace an invoice back to the order and the receipt without having to ask anyone.
When this alignment is in place:
requests move to the next step without being re-keyed or re-sent
approvers have the context they need to decide the first time
requesters can check progress without chasing
procurement spends more time on sourcing and less on clarification
finance receives orders, receipts and invoices that already line up
The process itself does not change dramatically—but the experience of moving through it becomes significantly smoother.
The same request, connected
Go back to the safety boots. In a connected flow, the site manager raises the request with sizes, the safety standard and the budget captured at the outset, because the request itself asks for them. The budget holder sees the quotes and the reason for the recommended supplier alongside the request, so there is nothing to forward. The purchase order is created from the approved request rather than typed again. Each delivery is recorded against the order, so when the invoice arrives, finance can see what was ordered, what was received and what is being billed.
Every step still happens. The approvals and checks are all still there. What disappears is the chasing, re-keying and explaining in between.
Where to start
Reducing fragmentation does not have to begin with a large project. A few practical steps can show where the gaps are:
Map a real request. Pick a recent purchase and trace every step it took, including the emails, calls and spreadsheets that sat outside the formal process.
Count the handoffs. Note each time the request moved between people or tools, and each time information had to be typed again.
Separate waiting time from working time. For each step, compare how long the request sat idle with how long someone actually spent on it.
Find the repeat questions. If approvers or procurement keep asking for the same missing details, capture those details at the start instead.
Agree one place for status. Requesters, approvers and finance should be able to see where a request is without having to ask.
The answers usually point to a small number of gaps that account for much of the delay. Closing those gaps tends to do more for speed than adding new rules.
It also helps to involve the people at each step in this exercise. Requesters, approvers, buyers and finance each see a different part of the journey, and the gaps are often most obvious at the points where one group hands over to the next.
How Swyftflo's Smart Procure fits
Swyftflo's Smart Procure reflects this direction.
Rather than treating procurement as a series of isolated steps, it brings them together into a unified flow—so that requests move forward without unnecessary handoffs or rework.
Better connected, not simpler
Procurement does not need to be simplified to become faster.
It needs to be better connected.
Because in most cases, delays are not caused by complexity.
They are caused by the gaps between otherwise well-defined steps.
