Practical perspectives
How to Write an RFP for AI Procurement Software
A buyer-ready RFP structure that separates the procurement job, evidence, controls and implementation work before vendors respond.
On this page
An RFP that asks vendors to “describe your AI capabilities” invites polished but incomparable answers. A useful procurement AI RFP starts with the work your team needs to complete, the information available, and the decisions a person must still make.
This article is a drafting framework for teams selecting software, not a universal legal template. Adapt its questions to your process, markets, data policies and approval rules. The aim is to get responses you can test on the same terms.
1. Define the job before naming the technology
Write one problem statement with a start, finish and current pain. For example: “Our sourcing team receives supplier quotations in different formats. We need to compare price, quantity, delivery and exceptions before a buyer recommends an award.” This says more than a request for an “agentic sourcing platform.”
State the volume and variety you can substantiate: typical requests, participating teams, countries, supplier types and systems. Mark estimates as estimates. Explain what is inside the RFP and what is outside it. If you need bid comparison but not supplier outreach, say so; otherwise vendors may price and demonstrate different jobs.
The UK guidelines for AI procurement ↗ recommend expressing the challenge and desired outcomes, assessing data early and asking about limitations. Those principles are useful beyond public procurement, while your organisation’s own rules still govern its RFP.
2. Give every vendor the same response matrix
Separate mandatory conditions from scored capabilities. For each requirement, ask for the current product behaviour, supporting evidence, configuration or integration needed, and any limitation. “Available today” and “planned” should be different answers.
| Question to ask | Evidence to request | How to assess it |
|---|---|---|
| Workflow result | A walkthrough using the same redacted request and supplier responses for every vendor. | Can the team complete the named task, including missing or conflicting information? |
| AI output and traceability | The source record behind each extracted value, recommendation and exception. | Can a buyer check and correct consequential statements? |
| Human control | A demonstration of review, approval, stopping and audit history. | Who may send a supplier message or approve an award, and how is that enforced? |
| Data and access | Data-flow diagram, sample export, retention terms and role permissions. | Can IT and procurement explain what enters the system, who sees it and what leaves it? |
| Implementation | Named integrations, customer-side work, timeline assumptions and support model. | Is the proposed deployment feasible with the systems and people in scope? |
| Commercial terms | A fee schedule for setup, seats, transactions, support, exports and renewal. | Can finance compare total cost for the same usage scenario? |
Ask vendors to complete the matrix in a consistent format. A yes/no feature grid alone is weak evidence: two “yes” answers may refer to different configurations, manual services or roadmap items.
3. Specify a common demonstration and exception
Attach a short, appropriately redacted scenario and ask each vendor to show the same input-to-output path. Include one ordinary case and one exception. For bid comparison, the exception might be a quote with a pack price but no pack quantity, or a lower price with a delivery date that misses the need. The acceptable answer may be “cannot compare until clarified.”
Tell vendors what they may preconfigure, how much preparation time they have and whether a person will intervene during the demonstration. Ask them to identify any data transformation or manual correction made before the session. A scripted result is still informative when its boundaries are visible; it is not proof of unattended performance.
For a post-RFP hands-on method, use our real-workflow evaluation article. The RFP sets the common questions; the pilot tests the answers.
4. Put approval gates ahead of feature scores
Before responses arrive, decide which conditions are mandatory for this use. Examples include permissible trial data, documented supplier-facing authority, an audit trail for consequential changes and an export path. A read-only discovery tool and a system that sends or awards on your behalf need different controls.
Ask where the vendor’s system can act without a person, where it recommends, and where it only drafts. Require a demonstration of those boundaries in your proposed configuration. The NIST AI Risk Management Framework ↗ offers a general structure for governing, mapping, measuring and managing AI risk; it does not prescribe one approval design for every buyer.
5. Compare evidence and record open questions
Give reviewers one sheet with each requirement, its importance, the vendor’s answer, evidence observed and unresolved follow-up. Keep a separate column for implementation dependencies. Do not award a full score to a feature that requires an unpriced integration or a future release.
- Pass: a mandatory requirement is demonstrated in the proposed configuration.
- Open: the vendor describes a solution, but the required evidence or integration design is missing.
- Fail: the current product or proposed service cannot meet the requirement.
An RFP should narrow the field, not pretend to replace a controlled pilot, security review or contract review. If you are still identifying relevant providers, start with the AI procurement software guide or describe your need in Solution Matcher. A listing or match is a research starting point, not an endorsement.