Sourcing intake today is a maze of static forms - and a stream of clarifying emails to patch what the forms missed. The demand we keep hearing: one conversational entry point that builds the request while the requester describes the need, so it reaches a buyer complete.
A single conversational entry point for sourcing. The requester describes the need in their own words; the assistant asks the follow-up questions a good buyer would ask and enriches the request as the conversation runs - category, spec, volume, dates, site. By the time the thread ends, the request is complete and ready to route.
The people who asked for this put a number on the pain themselves: by their own estimate, around 40% of buyer time goes to intake back-and-forth - requesters and buyers ping-ponging just to establish what is actually needed. The forms were supposed to prevent that. They are where it starts.
Heard from a senior procurement-solutions leader at a global consumer-goods manufacturer. Paraphrased, like everything on this map.
Requesters do not speak procurement. They know what they need - "same as last time, but sooner, and for the new site" - not which category it belongs to, which spec fields matter or which policy applies. A static form hands them a wall of fields and lets them guess.
We do not attach figures to demand signals. The estimate above came from the people who live with the problem - everything else stays directional, as it should.
Every hour a buyer spends establishing what a requester actually meant is an hour not spent sourcing. The back-and-forth is where the working week quietly goes.
The clarifying questions get asked and answered inside the intake conversation instead of over email afterwards. The same team covers more categories with more attention, and the headcount conversation never needs to start.
Incomplete requests bounce: intakes get rejected, threads get reopened, and some needs are quietly abandoned because the form defeated the requester before a buyer ever saw them.
A request that arrives complete does not bounce. Rejection, reopening and silent abandonment stop being standard stages of the process.
The clock starts long before sourcing does: a need becomes a usable request only after the back-and-forth ends, and the sourcing event waits on the slowest email in the chain.
The request is enriched while the requester is still describing the need, so the gap between asked and understood closes inside the conversation itself. Sourcing starts when the need shows up.
Two engines run in production today - Analytical Lab Reports and account Knowledge Twins. Everything else on this map is an extension on the same foundation.
This entry maps to the Knowledge Twin - scoped to your sourcing categories, policies, suppliers and purchasing history instead of a customer account. That scoping is the same hyper-contextualization work that makes the production engines answer correctly, and it is precisely the domain context a generic chat lacks. The conversation is just the interface. The twin is why it asks the right next question.
How Knowledge Twins workAll of it runs inside your infrastructure, within your boundary. Categories, policies and supplier history stay under your control - and so does your freedom of action: which models drive the conversation, where the workload runs, what the economics look like.
Back to the AI ROI MapPull one recent sourcing request and count the messages it took to establish what was actually needed. Then look at what already runs in production - and test it. No form, no gate.
On-prem. Your data never leaves your boundary.