How to create a procurement process
How to design a procurement process from need to contract: set the make-or-buy and sourcing routes, define when a tender is required, and put the single-source justification in writing.
A procurement process runs from a defined business need to a signed contract and a reviewed supplier, with the sourcing route chosen deliberately rather than by whoever is available.
The short version
- Make or buy is a real decision and belongs at the front, before any sourcing effort.
- Choose the route to market explicitly: call-off, single source, or tender.
- Single source is legitimate and must be justified in writing.
- Decide whether funding is approved before or after sourcing strategy, and stick to it.
- The process does not end at signature: supplier performance review closes the loop.
Sourcing route is the decision that matters
Most procurement processes are documented as a linear sequence (specify, source, evaluate, award) and most procurement problems come from the one decision that sequence hides: which route to market this particular need should take. Call-off against an existing agreement, single source with a written justification, or a competitive tender. Getting that decision made explicitly, early, by someone accountable, is worth more than any amount of rigour applied afterwards.
The other structural choice is where the funding gate sits. Approve budget before sourcing and you spend approval effort on things that may not proceed; approve after and you run tenders for money you do not have. Most organisations settle on a strategy-then-budget order, which is what the example uses, but the point is to decide, because the ambiguous version produces suppliers who have bid for work that was never funded.
The example below is a source-to-contract process across five lanes and seven phases, including the supplier. It contains the three routes that a real procurement function needs: call-off, single source with a recorded justification, and full tender, each rejoining at contract award.
Source to contract, three routes
From a business need to a reviewed contract. Watch the sourcing route decision and where each branch rejoins.
Specify, then ask whether to buy at all
A requirement specification and a make-or-buy decision with a real internal-resource ending. Procurement processes that assume buying skip the cheapest possible outcome, and the specification written before that decision is what makes it answerable.
Strategy, then funding
Sourcing strategy agreed, then a budget gate that can decline or defer. The order is a design choice: this way the funding conversation happens once the approach and rough cost are known, rather than on a number someone guessed.
The route-to-market decision
Existing supplier routes straight to a call-off; otherwise a single-source justification is recorded, or an RFQ goes out and bids are evaluated against stated criteria. Three routes, one decision, and the justification written down rather than assumed.
Award and contract
Selection and negotiation in procurement, contract review and signature with legal, then a purchase order. The legal lane exists because contract review is where a fast procurement process most often stalls, and hiding it inside procurement makes the delay invisible.
Close the loop after delivery
Delivery, an acceptance decision that can reject back to the supplier, then a performance review feeding renewal or retender. A procurement process ending at signature cannot tell you whether the award was any good.
How it works
Define the need before the solution
Write the requirement as an outcome rather than a product name. Specifications written as "renew the current tool" foreclose the make-or-buy decision and the sourcing route at the same time, which is how organisations end up renewing things nobody has evaluated in five years.
Set the route-to-market rules
Write down what triggers a call-off, what qualifies as legitimate single source, and at what value a competitive process becomes mandatory. Put the thresholds on the decision node. Rules that live in a policy get applied from memory and inconsistently, which is exactly the exposure a procurement process exists to close.
Decide where the budget gate sits
Before sourcing strategy or after: either is defensible, ambiguity is not. Draw it once and hold it, because the failure mode is a supplier who has bid, negotiated and been selected for work that turns out to be unfunded.
Require the single-source justification in writing
Single source is a legitimate route and the most audited one. Name what the justification must contain (why no alternative meets the need, how the price was tested, who approved it) and make it a document step so the record exists rather than being reconstructed later.
Give legal and finance their own lanes
Contract review and funding confirmation are where a procurement timeline actually goes. Burying them inside a procurement lane makes the process look faster on paper and removes any pressure to resource them.
Add the performance review and the renewal trigger
End the process with a review against the award criteria and a decision to renew or retender, with a date on it. Contracts that auto-renew unreviewed are the most common and least visible procurement failure, and they are invisible precisely because the process ended at signature.
Mistakes to avoid
Sourcing route by default
Whoever is available picks the approach. Making it an explicit decision with written criteria is the single highest-value change to most procurement processes.
Specification written around a supplier
A requirement that only one vendor can meet has already made the award decision, and no amount of subsequent process rigour undoes that.
Legal review invisible
It is frequently the longest step. Give it a lane and a service level or it will be blamed for delays it cannot influence.
Ending at signature
Without a performance review and a renewal decision, the process cannot learn, and contracts roll on unexamined.
Create your own procurement process
Open the source-to-contract example as your own chart and set your own thresholds, routes and approval levels.
Related guides
Frequently asked questions
What is the difference between procurement and purchasing?
Purchasing is the transactional part: raising the order, receiving the goods, paying the invoice. Procurement is the wider cycle around it: defining the need, choosing a route to market, evaluating and selecting suppliers, negotiating and contracting, then managing performance. A purchase order process is essentially the execution half; a procurement process is the decision half, and most of the value and most of the risk sit in the decisions.
When is single sourcing acceptable?
When no realistic alternative meets the need (proprietary technology, an incumbent whose replacement cost exceeds the benefit, a genuine emergency) and when the reasoning is written down before the award rather than after. The written justification is what distinguishes a defensible single source from an avoided competition, and it is the first document any auditor or procurement review will ask for. Public-sector rules go further and set explicit thresholds and permitted grounds.
What should trigger a competitive tender?
A value threshold taken from your delegation of authority, plus judgement about market complexity and switching cost. Set the threshold high enough that tendering is reserved for spend where competition can realistically change the outcome: running a full process for low-value purchases costs more in internal effort than it saves, and it trains people to split orders to stay underneath the limit.
How long should a procurement process take?
A call-off against an existing agreement should be days. A single-source award with a contract review is typically two to four weeks, most of it legal. A competitive tender is six to twelve weeks and is dominated by supplier response time and evaluation scheduling, neither of which is compressible by working harder. If your process takes materially longer, measure how long the file sits in each lane rather than the elapsed total: the answer is usually one queue.
