Purchasing Should Not Begin With "Someone Asked in a Chat"
Purchasing can look like a simple process: someone needs something, a responsible person finds a supplier, and the company buys it.
In reality, many decisions may happen between "we need this" and "we received it".
Is it really unavailable in stock? Is another supplier order already open? Does the budget allow the purchase? Which supplier should be selected? Who must approve the amount? Is prepayment required? When should the goods arrive? Who verifies quantity and quality after receipt?
When those decisions live across separate chats, even a simple question becomes difficult: what is happening with this purchase right now?
What I Would Capture at the Request Stage
Not every purchase needs the same number of fields, but the reason and context should be clear before someone starts searching for a supplier.
What Is Needed
A product, material, equipment item, or service described well enough that purchasing does not need to rediscover the requirement.
How Much Is Needed
Quantity, unit of measure, and acceptable variation if one is allowed.
Why It Is Needed
A production order, specific customer, stock replenishment, repair, or another reason.
When It Is Needed
Not simply "urgent", but a date or business event after which a delay becomes a problem.
Who Requested It
Who created the need and who can clarify the requirement when necessary.
What Constraints Apply
Budget, brand, technical requirements, approved suppliers, or other important conditions.
How I Would Design the Main Purchasing Flow
Not every company needs every stage. But I would clearly separate the need itself, the decision to purchase, the selected terms, and the actual receipt.
Request Created
The requester describes what is needed, how much, by when, and why.
Request Checked
The company checks existing stock, duplicate requests, open supplier orders, or another way to fulfill the need without a new purchase.
Purchase Approved
If the amount or category requires a responsible person’s decision, that decision and its result are recorded.
Supplier and Terms Selected
Price, lead time, payment terms, delivery, and other meaningful conditions become part of the purchase.
Supplier Order Created
The supplier receives a clear order while the company knows exactly what is expected and by which date.
Financial Condition Met
If prepayment or another financial condition is required, its state becomes visible in the process.
Delivery Expected
There is an expected date and visibility into which active needs depend on this delivery.
Delivery Received
Actual quantity, receipt date, and responsible information are recorded separately from what was expected.
Discrepancies Reviewed
Shortages, excess quantity, damage, or incorrect items follow a clear workflow instead of disappearing into messages.
Purchase Completed
The original need is fulfilled, receipt is confirmed, and financial and document-related actions have a clear state.
| Situation | Is Approval Needed? | What I Would Check |
|---|---|---|
| Normal replenishment within defined rules | Possibly not | Limit, need, approved supplier |
| Amount above an established threshold | Yes | Who has authority for that amount |
| New supplier | May be required | Terms, company details, risk |
| Urgent purchase | Standard path may be too slow | Reason for urgency and responsible person |
| Price changes after approval | Depends on the change threshold | Whether another decision is required |
| Recurring purchase under contract | Can often be simplified | Whether it remains within approved terms |
I also would not force employees to run a formal supplier competition every time if the business does not need it.
For an important or high-value purchase, comparing several offers may be useful: price, lead time, payment terms, delivery, quality, or previous experience.
For recurring purchases under an already approved agreement, the same procedure may only create extra work.
The rule should therefore come from actual risk and decision value, not from a desire to make the process look formally correct.
I would not make a list of every purchase the primary management control tool.
More useful questions are: which requests are waiting for a decision? Which deliveries are late? Where did the price change after approval? Which purchases depend on one supplier? What has been paid for but not yet received? Which needs remain unfulfilled?
Control therefore begins not with the number of tables, but with the ability to quickly see deviations from the normal process.
A Few Questions About the Purchasing Process
Purchasing can vary widely, but visibility into the need, decision, and actual receipt is useful almost everywhere.
Does every purchase need approval?
Do we always need multiple supplier quotes?
What about urgent purchases?
Should purchasing be linked to inventory?
What about partial deliveries?
Where should improvement begin?
How I Would Design This Business Process
In this series, I take one real business process and break it down step by step: what should be visible, where human decisions matter, and which repetitive manual work can be removed.
Does Your Purchasing Process Also Live Between Messages and Spreadsheets?
You do not need to begin with a large system replacement. Start by following one real purchase: where the need appeared, who made decisions, where people waited, what was entered more than once, and where context was lost.
