From Purchase Request to PO Without the Pain
Procurement is one of those processes where employees frequently get stuck not because the rules are unreasonable, but because they are hard to find. Someone needs to buy something, they are not sure which approval path applies, they pick the wrong one, and the request stalls. A context-engineered Procurement Navigator gives employees the guidance they need to move a purchase request through the right channels the first time.
Rather than routing every procurement question through a finance partner or letting requests stall in the wrong queue, employees can get step-by-step guidance based on what they are buying, how much it costs, and who needs to approve it.
RAG #7 in the Kendall Project's 100 Essential Enterprise AI Assistants is the Procurement Navigator. This post walks through what one looks like and what you need to build it.
What a Procurement Navigator Does
The Procurement Navigator is a context-engineered AI assistant built on a RAG model. It guides employees and managers through the procurement process from initial request to purchase order, based on the specific purchase they are making.
At its most useful, it handles questions like:
- Do I need to run an RFP for a software purchase at this price point?
- Which vendors are on the preferred vendor list for marketing services?
- My purchase requires legal review. At what contract value does that kick in?
- Who approves a purchase over $25,000 in my department?
- Can I sole-source this vendor, and what documentation do I need to justify it?
- What are the required contract terms for any new vendor we bring on?
The difference between a generic AI assistant and a context-engineered one shows up immediately in approval routing. A general-purpose AI can describe what procurement processes typically look like. A Procurement Navigator built on your organization's context can tell a marketing manager exactly which approval tier their $18,000 software subscription falls into, whether the vendor is on the preferred list, and what paperwork they need before the request moves forward.
The Context Blocks That Make It Work
Processes
The Processes block is the backbone of the Procurement Navigator. It captures the end-to-end purchase workflow: how to initiate a request, how requests are routed by dollar amount and category, what documentation is required at each stage, and how exceptions are handled.
The most important work here is mapping the decision tree that determines which process applies to which purchase. A $500 software tool, a $50,000 consulting engagement, and a multi-year enterprise contract all follow different paths. That branching logic needs to be explicit so the assistant can route an employee to the right process based on what they are actually buying rather than giving them the full policy to interpret themselves.
Rules
The Rules block captures the thresholds and requirements that govern procurement decisions: approval limits by dollar amount, RFP requirements by purchase category, sole-source justification criteria, preferred vendor usage rules, and contract requirements by vendor type.
Rules in procurement tend to be highly conditional, and that conditionality is where generic AI fails most visibly. Whether an RFP is required often depends on both the dollar amount and the category. Whether a vendor needs a security review depends on what data they will access. Capturing those conditions explicitly is what allows the assistant to give accurate guidance rather than a general description of how procurement rules work.
Vendors
The Vendors block is what makes the Procurement Navigator genuinely useful for day-to-day purchasing decisions. It captures the preferred vendor list, approved vendor categories, vendors that have been through security or legal review, and any vendor-specific terms or restrictions that apply.
When an employee asks whether they can use a particular vendor, the answer often depends on more than just whether the vendor exists. Are they on the preferred list? Have they signed the required agreements? Are there pricing terms already negotiated? A well-structured Vendors block means the assistant can answer those questions accurately and steer employees toward approved options before they get attached to a vendor that will not pass review.
Roles
Approval authority in procurement is almost always role-dependent. A department head may approve purchases up to a certain threshold that requires a VP for anything above it. A manager may initiate requests but not approve them. The Roles block maps those approval authorities so the assistant can tell an employee exactly who needs to sign off based on their role and the purchase amount, not just describe the approval hierarchy in general terms.
This block also covers who can initiate different types of requests. Some procurement categories are restricted to certain roles or require a designated requestor. Having that structured here prevents employees from starting a process they are not authorized to initiate.
Assets
The Assets block captures the tools, templates, and reference documents that support the procurement process: request forms, RFP templates, contract templates, vendor evaluation scorecards, and approval submission instructions. This is what allows the assistant to hand an employee exactly what they need to move their request forward rather than telling them to find it themselves.
Building this block is a good opportunity to audit whether the right templates actually exist and are current. Procurement processes often accumulate outdated forms and fragmented documentation over time. Consolidating and updating that material as part of the Assets block build benefits the process regardless of the AI layer on top.
Where to Start
The Processes block is the right place to begin, specifically by mapping the decision logic that determines which procurement path applies to a given purchase. That map does not need to be exhaustive on the first pass. Starting with the most common purchase categories and the thresholds that trigger different approval requirements covers the majority of questions employees actually ask.
The Vendors block typically requires coordination with the procurement or finance team to pull together accurate, current information. Preferred vendor lists, approved vendor statuses, and negotiated terms are often maintained informally or in systems that were not designed for this kind of structured reference. Getting that content into a usable form is where a meaningful share of the build effort goes.
The Procurement Navigator is a way to make purchase guidance available at the point of decision. Getting the context right is what makes the difference between an assistant that describes how procurement works and one that tells an employee exactly what to do next with their specific request.
This is Blog 7 of 100 in the series. Next week: Budget & Forecast Assistant (#8).