Skip to content

GroundWorks · Intake Management

Every request arrives complete, routed and owned, without manual triage.

Give every request a guided front door, gather the facts that decide its route and hand it to the right policy, person or Workblock.

The Workblock

Intake Management · GroundWorks Gateway

The buyer question
Can we improve the request experience without replacing the systems that execute procurement?
System of work
Intake and demand system of work
Maturity
1 reference / 1 defined / 3 roadmap

Modules

  • Procurement service catalogue: Publish the available procurement services, eligibility, evidence, routes, owners and operating contracts.
  • Procurement request intake: Capture demand conversationally, enrich the request and route it through the correct flow.
  • Procurement request enrichment and routing: Reuse permitted context, run required checks and commit the correct execution path with its decision trace.
  • Procurement request coordination: Coordinate multi-domain tasks, approvals and handoffs from one intake record.
  • Demand consolidation and portfolio planning: Surface related demand, form reversible bundles and track capacity, ageing, dependencies and outcomes.

The question, answered

Once routed, the request is recreated in one or more downstream systems. Each specialist team asks its own questions and records its own decision. Dependencies travel in meeting notes and spreadsheets. The requester holds a case number and chases status, while the parent request reads in progress and nobody owns the next decision.

The cost accumulates in the gaps. Wrong routes surface late, after a specialist returns the work. Urgent requests bypass review without a named exception. Parents close when a coordinator believes the work is done, not when the evidence confirms it, and months later nobody can reconstruct why a route was valid at the time.

  • Can we improve the request experience without replacing the systems that execute procurement?

    Today a request starts in email, chat, a portal or a form. An analyst reads it, asks for what is missing, then searches policies, contracts, suppliers, catalogues and budgets by hand before anyone can say what happens next.

What changes

The route arrives as a proposal: the policy cited, the source facts with their freshness, what is missing, the alternatives considered and the named owner who accepts or corrects it.

One parent plan links each specialist's record. A failed step shows as blocked with an owner. The parent cannot report complete while material child work stays open.

  • Routing becomes a decision package

    A form or chat captures the request. An analyst still rebuilds the case by hand across policy, contracts, suppliers, budget and prior requests before anyone can route it.

  • One parent outcome

    One request becomes four queue entries. Procurement, legal, risk and buying each track their own piece, and nobody can say when the whole thing is done.

The principles it holds to

  • Proposal is not commitment

    A machine may classify a request and propose a route. The accepted route carries the name of the person or policy that committed it, and the two states never blur.

  • No state is inferred from silence

    Expiry, timeout, access denial and a failed write are explicit states with owners. A waiting request says what it waits for, who resolves it and what reopens it.

  • Complete means ready for the route

    Completeness is defined by the selected path and its consequence, not by a universal form. A question is asked only when its answer changes the route, the required evidence, the owner or the authority.

The records it authors

Demand case. A durable orchestration record that moves one qualified business demand through the selected procurement route, dependencies, commitments, exceptions and handoffs.

Demand portfolio. A versioned grouping of compatible current and forecast demand with timing, value, confidence, consolidation logic and an executable portfolio disposition.

Intake request. The canonical statement of a business need captured once, with requester intent, outcomes, constraints, evidence and consent for procurement processing.

Enriched request. A versioned, machine-proposed and evidence-linked augmentation of an intake request with normalized taxonomy, duplicates, supplier or contract context, policy results and route candidates.

Procurement service offering. A versioned, audience-scoped description of a procurement service, its eligibility, required inputs, policy route, service expectation and owning Workblock.

  • Case records

    Durable, owned units of work. Each one holds the condition that opened it, the evidence gathered against it, the proposed action and the committed disposition, and it stays open until the condition is answered.

  • Decision records

    Determinations and the proposals that precede them, each pinned to the exact policy, rule and evidence versions it was made against, and each kept structurally distinct from the action it authorises.

  • Reference records

    Shared descriptors the whole estate reads. One canonical service owns each of them, and policy filters what any Workblock is shown.

The roles it serves

Execution flow and task definitions are not published. The dossiers name what each Workblock owns and how much of it there is; the definitions themselves travel with a delivery.

Workblocks can be versioned and changed independently, enabling continuous client tailoring.

  • Requester

    Explain the business need, supply the facts they hold and confirm the requested outcome. Where is my request, who owns it and what do you still need from me?

  • Procurement intake owner

    Qualify demand, resolve route ambiguity and own the parent request until it is accepted, redirected or declined. Which requests wait on a decision, and what evidence clears each one?

  • Demand owner

    Keep an accepted request moving across specialist owners and systems until the agreed outcome is complete. What is the next valid action on each open request, and what is it waiting for?

  • Process and policy owner

    Define the intake rules, thresholds, evidence requirements and exception ownership, and change them safely. Which rules are being overridden, and is the rule wrong or the case exceptional?

  • Module maturity

    1 reference / 1 defined / 3 roadmap, of this Workblock's five business modules.

The rest of the register

  • Previous

    Category Management

    A live category agenda where every opportunity has an owner and a source.

    Open the Workblock
  • The map

    The GroundWorks map

    Five stages and nine domain Workblocks, summarised once, each linked to the register page that holds it.

    Back to the map
  • Next

    Sourcing & Negotiation

    Sourcing decisions you can defend line by line: every score opens the response behind it.

    Open the Workblock

Let's talk

Once you start, you're ahead.

In the enterprise, real execution matters. That's where we lead.