Intake & requisitions

Every purchase starts as a request, and every request is a record.

The front door of the system. A request picks up its own value, category, cost centre and criticality, and from then is traceable to whatever it becomes — an order, a quote, a tender, a contract.

The request itself

One form, and it collects what every later decision needs.

Nothing downstream can be automatic if the request does not carry the facts. The form asks for them once, in plain language, and explains why each one matters.

  • WhatDescription, quantity and unit — with a non-standard unit field so nobody rounds a requirement to fit a dropdown
  • How muchThe estimated whole-life value in the workspace's currency, which decides the route and the approval band
  • How criticalRoutine, Important or Critical — criticality drives the policy ladder alongside value, so a cheap but critical purchase is not treated as trivial
  • Where it landsDepartment, category and cost centre, so spend analysis and the budget are right without anyone re-keying anything
.../requests/new
New request — The intake form as a requester sees it, with the guidance panel above it.
New requestThe intake form as a requester sees it, with the guidance panel above it.
For the requester

No training, and no guessing what happens next.

A requester never has to know the procurement rules. The system reads them out at the point they matter, then says where the request has got to.

  • SimpleCheck the catalogue first — where an item is on an active arrangement it is ordered at agreed prices and no buyer is involved
  • ThenRead the one-page summary of what happens at what value before writing anything, so the answer is not a surprise afterwards
  • ThenFill the form; where the assistant is switched on, describe the need in a sentence and it drafts the fields for editing
  • ComplexTrack it from the same screen — the guidance panel names the stage it is at and what is holding it
.../requests
My requests — A requester's own list: what is open, and what each one waits on.
My requestsA requester's own list: what is open, and what each one waits on.
For the buyer

Demand arrives structured, not as an email.

The buyer's problem with intake is usually that it is not intake at all — it is a mailbox. Here every request is valued, categorised and coded before it is seen.

  • SimpleWork the queue by value and need-by date rather than by who shouted
  • ThenRead the computed brief — purpose, value, criticality, and whatever the system has flagged about it
  • ThenSend it down the route the value and category call for; a purchase order cannot exist without the requisition behind it
  • ComplexGroup related requests into one sourcing project rather than running four small competitions in the same category
.../sourcing
Sourcing pipeline — Where requests become competitions, with the route already decided.
Sourcing pipelineWhere requests become competitions, with the route already decided.
The other question

Approval asks who may spend. This asks whether it may be bought at all.

A handful of questions when the request is raised: personal data? our systems? our premises? something staff and the public will use? The right specialist is then asked automatically, on WHAT is bought rather than what it costs.

  • RaisedPrivacy, security, accessibility, health and safety, legal. Each routed to whoever owns that risk, showing the question that triggered it, so nobody has to guess why they were asked
  • ParallelThey run ALONGSIDE the approval ladder, not behind it. Holding an approver behind a privacy review makes the two look like one queue, and then neither gets read properly
  • BlockingA blocking review stops the request being sourced or ordered until decided; an advisory one never does. A control that can be neither waived nor ignored just teaches people to answer no to everything
  • WaivedA waiver is a decision, not an escape — it carries a name, a reason and a time, exactly like a clearance
.../reviews
Reviews waiting on you — Real reviews, why each was asked, and what clears them.
Reviews waiting on youReal reviews, why each was asked, and what clears them.
For the approver

Decide on the facts, in the queue, in seconds.

Approval is where most systems leak: a forwarded email with no context and no record. Here the decision is made against a brief the system computed.

  • SimpleOpen the dashboard — requests waiting on you and awards waiting on you, and nothing else
  • ThenRead the brief rather than the request: purpose, who asked, value, and every flag raised against it
  • ThenApprove, or reject with a note saying what would make it approvable
  • ComplexHand your authority to a named colleague before leave — the delegation is recorded and they are told they are acting under it
.../
Approver's queue — The approver's first screen: what is waiting, in order of urgency.
Approver's queueThe approver's first screen: what is waiting, in order of urgency.
For a procurement director

A forward plan built from demand, not from memory.

Intake is where the pipeline comes from. What has been asked for, at what value, in which category, becomes the plan of what is coming to market and when.

  • SeesThe forward plan — what is going out, roughly when, whose it is, at what value
  • SeesWhere demand is concentrating, and where one category is bought repeatedly in pieces small enough to avoid competition
  • DoesPulls work forward or groups it, before a deadline forces a single-source
  • ProofEvery purchase order traces to a requisition — a check that used to be a sampling exercise is now a property of the data
.../pipeline
Procurement plan — The forward plan: what is coming, when, and at what value.
Procurement planThe forward plan: what is coming, when, and at what value.