Why Procurement Requests Disappear Into Email and Chat

The problem in plain language

A manager needs a supplier, software subscription, contractor or piece of equipment. The request begins in an email or chat message. Procurement asks for a specification, budget code, supplier details or approval. Some information arrives in a spreadsheet. A senior manager approves in a reply thread. Later, someone asks for status and nobody can answer without searching the conversation.

At that point procurement has become a human workflow engine. The team is not merely buying; it is manually creating the record, routing, state management, evidence trail and exception handling that a proper operating process should provide.

What people search for

Problem-aware searches often look like “procurement request workflow”, “purchase requisition approval process”, “automate purchase approvals”, “procurement intake form”, “how to track purchase requests” or “procurement request stuck in email”. The searcher is rarely asking for a grand procurement transformation. They want a request to enter one controlled path and move.

Evidence: procurement platforms treat the request as a governed business record

ServiceNow's current sourcing and procurement documentation models a purchase requisition as an internal request for goods or services, with defined information, approvals and lifecycle states. Its approval rules can route purchase requisitions according to managerial hierarchy, specified users or groups, cost centres, limits and trigger conditions. The documented state model separates review, approval, task completion, final review and submission.

Again, the product is not the point. The operating principle is. Procurement work is easier to govern when the request has a durable identifier, structured fields, explicit states, ownership, conditions and a traceable approval path. Email is excellent for communication; it is weak as a source-of-truth workflow database.

Buyer ownership

Procurement usually owns the process, but the CFO or COO often owns the economic consequence. Budget owners approve, employees request, finance validates spend and suppliers receive the final order. If the intake layer is weak, every downstream team pays for the ambiguity.

Why the problem becomes urgent

It becomes urgent when spend grows, approval policies tighten, audit evidence is requested, supplier volume increases or procurement headcount cannot scale with the number of requests. A business can tolerate informal buying at low volume. At higher volume, the same informality becomes delay, maverick spend and repeated administrative work.

Economic consequence

• Cycle-time cost: requests wait because the next decision or missing field is not visible.
• Procurement labour: specialists spend time reconstructing context rather than negotiating or managing suppliers.
• Maverick spend: employees bypass the process when the formal route feels slower than buying directly.
• Duplicate effort: request details are re-entered into sourcing, purchasing and finance systems.
• Audit effort: evidence must be assembled from messages rather than retrieved from a transaction history.
• Supplier friction: orders arrive late or with incomplete information after internal delays.

The root cause is usually intake design, not approver laziness

Organisations often blame managers for slow approvals. Sometimes that is true. But the deeper causes are usually missing information, unclear routing rules, no purchase categories, an approval matrix that is not encoded, and no visible state model. A manager cannot make a fast decision on a request that arrives without cost, business reason, supplier, budget owner or timing.

A practical intervention

1. Create one front door for procurement requests.
2. Capture only the information needed to classify and route the request; do not turn intake into a 60-field punishment.
3. Define request types such as routine catalog purchase, non-catalog purchase, new supplier, sourcing event, renewal and emergency purchase.
4. Encode approval rules using value, cost centre, category, risk and authority rather than manually forwarding every request.
5. Give every request an explicit state and owner.
6. Create escalation and delegation for absent approvers.
7. Integrate approved requests with purchasing and finance so data is not re-keyed downstream.
8. Measure cycle time by stage and exception reason.

Diagnostic questions

• Can an employee see where to submit a purchase request without asking procurement?
• Does every request receive a durable ID?
• Can procurement tell which requests are waiting for information versus approval?
• Are approval limits encoded in a system rather than remembered by staff?
• Can an approved request create the next purchasing record without re-entry?
• Can auditors reconstruct who approved what, when and under which rule?

What good looks like

Good procurement intake is boring in the best sense. A requester knows where to go. The form adapts to the type of request. The right owner receives it. Approvals follow policy. Status is visible. Clarification is captured against the same record. Approved information flows downstream. Exceptions are explicit instead of becoming invisible side conversations.

Where Mellorca fits

Mellorca can map the request-to-purchase flow, simplify intake, define decision and approval logic, implement workflow automation and integrate purchasing records with finance or supplier systems. The commercial objective is not “more workflow software”; it is lower coordination cost with stronger control.

Commercial path

Discovery article → procurement-intake diagnostic → request/approval map → workflow redesign → platform/integration implementation → cycle-time and exception monitoring.

Sources and further reading

• ServiceNow: Purchase requisition.
• ServiceNow: Create an approval rule.
• ServiceNow: Purchase requisition, purchase order and sourcing request states.