Demand aggregation signal

The model groups similar requisitions across business units inside a rolling time window. It does not combine them into a PO.

A cluster is a short decision with the category owner: hold the non-urgent lines, source once against the combined volume, or let a line through because waiting would cost more than a better unit price. If nobody owns that conversation, the queue expires into five separate buys.

Do not book savings when the cluster appears. Nothing is saved until a human chooses to buy once and the PO issues that way. Treating clustered volume as already-won cost reduction is how intake teams lose the next finance review.

The intake lead keeps the window honest and keeps plant-down, safety, and patient-facing requests out of any hold. The category owner makes the commercial call. Neither role is replaced by an auto-bundled order.

Clustering on shared words is how you bundle unlike items. "Gloves" is not a SKU. Nitrile exam gloves, cut-resistant mechanics gloves, and insulated winter gloves do not move on the same RFQ, even when they share a taxonomy family.

Use spend category auto-classification as an input, not as the cluster key. Family or class is useful for routing the queue to the right owner. Spec, unit of measure, grade, size, and pack size decide whether two lines can actually be one buy. Noisy historical coding produces tidy clusters of junk, and the owner stops opening them.

Put in similarity: description and captured spec fields, category as a hint, unit of measure and pack size, and manufacturer or part number when present. Need-by date constrains the hold. Site is logistics only. Do not let the same requester, cost center, or the word "urgent" in a comment dominate. Those signals hide cross-BU demand or fake a plant-down.

Prefer a smaller, spec-tight group. When in doubt, split and let the owner merge. A cluster labeled "IT hardware" that mixes laptops, docks, and a printer will not get a second look.

Fragmented demand often sits next to off-contract buying. A cluster of similar requests naming three suppliers is a coverage problem as much as a timing problem. Use off-contract spend prediction on the live request, and maverick spend detection on what already posted, so the owner is not guessing whether the scatter is policy leakage or a missing contract.

The time window is policy, not a silent clustering knob. Too short and you never see the second plant. Too long and you delay people who waited through intake.

Write it so a requester can hear it: non-urgent stocked items in this category may be held for a stated number of days if a similar request is open elsewhere. Production-stop, safety, and patient-facing lines are never held. Set the days per category.

Route a proposal. Do not auto-hold, and never auto-bundle. The system shows a cluster and a suggested action. The category owner or intake lead chooses:

• Let through. One line is time-critical, or the items are not the same buy. Release it. Leave the rest of the cluster intact.
• Hold. Pause the non-urgent lines until the window closes or a volume threshold is hit, then source once.
• Source once now. Combined volume is already enough, or a contracted catalog can take the bundle today.

An automatic combined PO is how a plant-down request waits behind a stationery buy, and how two plants receive the wrong grade. If a line is marked production-stop, it leaves the window the same hour.

If the same cluster shape repeats every quarter, stop treating it as an intake trick. That pattern belongs in category opportunity identification: a catalog item, a blanket, or a contracted volume band. Intake clustering is for demand you did not already plan.

When the owner does choose to source once, the next artifact is a single RFQ or catalog event, not five mini-POs. RFP/RFQ auto-drafting can assemble that package from the clustered lines. A human still confirms the spec before anything goes to suppliers.

Show the owner the lines, sites, need-by dates, matched and unmatched spec fields, combined quantity, and contract coverage. Add a suggested action with a one-line reason. Leave estimated savings off the card. The invoice is the score.

This walkthrough is illustrative, not a case study, and claims no measured savings.

A category manager covers PPE and MRO for a manufacturer with three plants and a small HQ. Over ten days, intake shows:

• Plant A: nitrile exam gloves, 9-inch, powder-free, ten cases, stock replenishment, needed in three weeks
• Plant B: nitrile exam gloves, same grade, six cases, needed in two weeks
• HQ EHS: nitrile exam gloves, same grade, two cases, for a training week next month
• Plant C: cut-resistant mechanics gloves, a stated cut-resistance rating, twenty pairs, line down after a tear-down, needed now
• A contractor on Plant A: "gloves" with no spec, four cases, needed Friday

A noun cluster puts all five in one bucket titled Gloves. That bucket is wrong.

A spec-aware cluster puts the three nitrile exam lines together. Plant C is a different commodity and a plant-down request: let it through the same day. The contractor line is incomplete: send it back for spec. Do not let it dilute the nitrile buy or ride the plant-down PO.

The category owner holds the three exam-glove lines to Plant B's two-week date, then places one catalog or contracted buy. They do not write a savings percentage into the monthly report because the cluster appeared. They record a combined buy when the PO is one order instead of three, at the price that invoiced.

Auto-bundling would have parked Plant C behind a stationery-speed RFQ and shipped the contractor's mystery gloves in the same lot: unlike items, a plant-down hold, and a cluster treated as money already saved.

Run the model in observation on one fragmented category first. PPE, IT peripherals, or MRO consumables are the usual candidates because the same item shows up under different descriptions. Do not start on engineered-to-order parts, where "similar" is almost never "the same buy."

For a defined period, log every proposed cluster and the human decision: hold, source once, let through, or split as unlike. You are measuring cluster precision and hold-rule sanity, not a savings rate. If the owner keeps splitting clusters, tighten spec matching before you widen the window.

Only then publish the hold rule. Plant-down, EHS, and any line a plant manager marks as production-stop skip the window without a debate in the queue.

Guardrails once it is live:

• A named owner for every cluster. Unowned clusters expire and the lines release.
• Record unlike-item splits in the first weeks as training labels.
• No savings booked from "identified consolidation." Finance should see realized price or avoided extra POs after the fact.
• Recurring shapes graduate to a contract or catalog, then leave the intake queue.
• Requesters can see the hold, how long it lasts, and how to flag production-stop. A quiet hold is how people route around procurement.

Success looks like fewer duplicate POs for the same spec in the same fortnight, and a category owner who still trusts the list. Failure looks like a plant waiting on gloves, or a monthly report full of aggregation opportunities with no combined buys.

Coupa, SAP Ariba, Zip, and Jaggaer are where requisitions already live. Use them as the system of record for the line, the approver path, and the eventual PO. Demand aggregation is a signal on top of that intake, not a second buying channel and not a substitute for a category owner.

Do not expect those platforms to invent your similarity rules or your hold policy. Those are category choices. The platform can show a queue, notify the owner, and keep a line from converting to a PO while it is on hold. The owner still decides hold, source once, or let through.

Keep the signal inside procurement. Broadcasting clustered demand to every requester trains people to game the window or to route around intake. The conversation stays with the category owner.