Precoro's Intake Agent turns a description into a usable requisition

When an employee needs to buy something, they usually know what they need it for. They may have no idea which supplier agreement applies, how the purchase should be coded or which form procurement expects them to use. If the process requires that knowledge upfront, procurement can end up teaching people to complete a form before helping them buy anything.

Precoro's Intake Agent addresses that starting problem. Its product article, dated 22 October, describes turning an ordinary-language request into a prepared requisition for the employee to check and confirm. For teams spending time correcting requests and explaining the same purchasing rules, that is a practical application worth looking at.

Disclosure: I work for Pactum, which also provides procurement automation. This article uses Precoro's public product information, checked on 25 October 2026. The assessment is my own, not a hands-on product test.

In Precoro's product description, the requester starts in its AI Assistant. The agent asks follow-up questions, uses purchasing records and policy to select the supplier and item, completes the coding and presents the requisition for confirmation. It then enters the configured approval process.

The company describes setting up the policy with the customer and testing it on examples before launch. That preparation is worth paying attention to. The quality of the conversation matters, but so does the purchasing knowledge the product is working with.

Take a hypothetical maintenance supervisor who needs replacement air filters for a site. They know the equipment, quantity and date. Asking them to memorise the preferred supplier list or choose a general ledger code is unlikely to improve their maintenance work.

A good intake process should use the information they do have, ask about anything important that is missing and apply the purchasing decisions already made by the business.

That might mean identifying the agreed item and pack size, checking which site needs delivery and using the correct account. It should also make the proposed purchase understandable enough for the supervisor to spot an error before confirming it.

This is the standard I would test the product against, rather than treating it as a promised outcome for every request. The scenario is illustrative, not a reported Precoro deployment.

There is a useful distinction between asking someone to confirm “these are the filters you need” and asking them to validate a procurement classification they do not understand. A confirmation button only adds value when the person can reasonably judge what they are confirming.

Before putting an intake agent in front of employees, I would look at a sample of requests the team regularly has to fix.

Some problems will be missing information. Others may expose an unclear policy, duplicate catalogue entries, an outdated supplier record or an agreement whose scope nobody can readily establish. Those need different remedies. Asking the employee more questions will not repair an expired price list.

For the filters example, test what happens when the description is incomplete, the requested item is unavailable or the familiar supplier is no longer approved. Does the process find a valid alternative, explain what is missing or get the exception to someone who can resolve it?

The goal is to make normal buying straightforward while keeping unusual requests visible. An attractive conversation followed by the same email exchange with procurement would leave much of the problem intact.

Precoro's AI Crews page currently marks the named Approval, Purchasing and Payment Agents as coming soon. That does not mean the platform lacks ordinary approval, ordering or payment capabilities. It means buyers should distinguish the current workflow from those additional agents when agreeing a project scope.

For this intake application, I would first measure how many requests reach the correct approval route without procurement repairing them. Pair that with employee effort, the reasons requests come back and time to an approved purchase order.

The last measure matters because a better request can still get stuck later. If approval is the main delay, reducing form-filling time alone will not solve it. It may still be a worthwhile improvement, but the business case should say what it actually improves.

My view is that procurement should make its agreements and buying decisions easy for colleagues to use. Helping someone produce a usable requisition without becoming a procurement expert is a sensible part of that job. The test is whether the effort falls for both sides and the purchase is still right.

The business need and the details required to explain it. The process should establish missing information at the point it matters and avoid asking people to guess specialist purchasing or accounting answers.

No. Preparing a request and authorising it are different steps. Check the configured approval workflow and show the employee a clear status rather than implying that submission guarantees a purchase.

Representative everyday requests and genuine exceptions, with expected outcomes agreed in advance. Include incomplete descriptions, unavailable items and conflicting purchasing information. Record corrections and failures as well as successful requests.

Product descriptions are vendor claims. The worked example and evaluation recommendations are WOP analysis. Sources checked on 25 October 2026.