Intake & orchestration: how it works and what to require
Proconomy intake and orchestration gives employees across every plant one place to raise a procurement need. Agents interpret the request, collect the missing information, apply category, value and entity rules, then launch the correct sourcing, contract or purchasing workflow. Buyers receive decision-ready work instead of incomplete email.
Every way a need reaches you. One governed front door.
Breakdown spares, prototype material, IT renewals, emergency purchases — captured in one place and routed by your policy.
Plant and maintenance
- Breakdown spares against a machine reference
- Planned shutdown material lists
- Consumables and tooling replenishment
- Contractor and labour requests
- Calibration and inspection services
- Safety and PPE requirements
Engineering and NPI
- Prototype and sample material
- New part introduction with a drawing
- Tooling, jigs and fixtures
- Test, validation and homologation services
- Engineering change driven re-sourcing
- Supplier development requests
Corporate and indirect
- IT hardware, software and renewals
- Professional and consulting services
- Marketing and events
- Facilities, utilities and site services
- Travel, fleet and logistics
- Recruitment and contingent labour
Exceptions and escalations
- Emergency purchases outside the approved route
- Single-source justification requests
- Requests above a delegated authority band
- Purchases against an expired agreement
- Requests from an entity with different rules
- Anything a requester cannot categorise themselves
Plain language in. A structured, routed request out.
Eight mechanisms that turn a description of a problem into work a buyer can act on.
| Mechanism | What it has to do |
|---|---|
| Free-text and conversational capture | A requester describes the need in their own words, in the channel they already use. No category tree to navigate and no form vocabulary to learn. |
| Extraction and classification | Category, entity, plant, cost centre, value band, required date and equipment reference are read out of unstructured text and presented for correction. |
| Completeness rules per category | Each category defines what a request must carry before it may progress. Drawings, specifications, delivery points and budget references are requested from the requester, not chased by a buyer. |
| Policy-driven route selection | Value, category, entity and risk decide between catalogue, contracted purchase, sourcing event and supplier onboarding. The rule that fired is stored against the request. |
| Sequential, parallel and conditional approvals | Approval chains configured by value, cost centre and entity, with reminders, overdue escalation to the next authorised approver, and delegation during absence. |
| Duplicate and consolidation detection | Requests for the same material across plants inside a window are surfaced together, so three separate orders can become one event. |
| Requester-visible status | The person who raised the need can see where it is without emailing anyone, which removes most of the status traffic procurement absorbs. |
| Full request history | What was asked, what was inferred, what was corrected, which rule applied, who approved and what it became. |
A description of what the practice requires, not a feature list.
Same front door. Different rules behind it.
What a request has to carry before it can progress, by industry.
Automotive
Programme and part references captured at intake, so a request routes against launch milestones rather than arriving as generic spend.
Medical devices
Device family and controlled-document references required before a request touching a qualified supplier can progress.
Aerospace and defence
Export-control and approved-supplier-list checks applied at the point of capture, with exceptions routed to named authority.
Semiconductor and OSAT
Qualification status of the requested source checked before an event opens, not after a quote arrives.
Five questions. Answered in the session, not the RFP.
Each takes minutes and each is difficult to stage.
- Show a free-text request that is genuinely ambiguous, not a clean demo request. What does the system do when it cannot classify it?
- What happens when a required field is missing — does it stop, or does it pass an incomplete request to a buyer?
- Show the record of which rule selected the route. If that is not stored, policy adherence cannot be evidenced later.
- Can two entities have different approval matrices for the same category without two separate configurations?
- What does the requester see, and does that reduce the status enquiries reaching your team?
Definitions. Asked and answered.
The agent interprets what it can, then asks the requester for the specific fields it still needs. The request does not enter procurement until the required information is present, which is why buyers receive decision-ready work rather than partial email.
No. Your approval matrix is what the platform executes. Roles, thresholds, sequences and escalation paths are configured to match your policy, and the applied rule is recorded against every request.
Yes. Group-level rules define what must be common, while entity and plant rules define thresholds, approvers, required documents and local buying routes. Both levels are visible in the same operating view.
The policy decides. A request above the competitive threshold opens a sourcing event; a request covered by an existing contract becomes a requisition; a request naming an unknown supplier starts supplier onboarding first.
No. They describe the business need in their own words. The interpretation, category mapping and process selection are handled by the platform, which is how adoption improves without weakening governance.
The original request text, the data the agent extracted, the rule that selected the route, every approval and the resulting downstream transaction remain linked as one record.
Procurement intake management is the practice of capturing every purchase request through one governed entry point, classifying it, checking it is complete and routing it to the correct buying process automatically. It replaces the mix of email, calls, spreadsheets and ad hoc forms through which needs typically reach a procurement team.
A requisition is a structured record that already assumes the requester knows the category, supplier and cost centre. Intake sits before that: it accepts an unstructured need in plain language and produces the structured requisition. In most manufacturers the work between the need and the requisition is done by a buyer, which is the effort intake removes.
Intake-to-procure describes the span from the moment a need is raised to the point a purchase is committed — capture, classification, policy routing, sourcing or contracting where required, approval and purchase order creation. It is a subset of source-to-pay that excludes invoicing and payment.
Because the need arrives unstructured and the routing decision requires knowledge of policy, categories, entities and thresholds. That knowledge usually sits with experienced buyers, so every request consumes buyer attention before any procurement work begins.