In September I wrote about the RFP Scoring / Evaluation Process (including why it's the thing every buyer hates most about an RFP) - I didn't get any screaming feedback so I'll assume I'm not alone in this feeling. You get a spreadsheet with 25 questions to score and five to ten completely differently formatted 50-page proposal decks in which you are supposed to find the answers. Some are in the appendix. Some are in a diagram. Some aren't answers, but the vendor has used enough words that you feel obligated to check again.
Good RFP managers ask vendors to put their answers in a standard template, then line them up so the client can compare them side by side. It isn't glamorous. It is, however, considerably more useful than another slide about how excited everyone is to partner with us, or the storybook history of the vendor's path from scrappy startup to global behemoth.
AI can now do much of the work involved in finding those answers, comparing them, and preparing a score. More interestingly, it can help fix what happens when an evaluator rushes through the spreadsheet, misses half the presentation, or has already decided which vendor they want to win regardless of the solutions and capabilities you’ve just spent a shit load of time and money investigating.
If I were running an RFP today, here's how I'd use it. The goal would be to automate as much of the manual evaluation work as possible AND improve the decision. One caveat: this assumes my company actually allows me to use the tools with our proposals and meeting recordings. From speaking with hundreds of buyers over the past year, that is still far from a given.
First, what do I mean by "AI" here?
A year ago I was spending HOURS a day moving files between AI tools. Upload, download, reattach, explain the context again. I was apparently the integration layer. Now I mostly use an AI workspace connected to the files and applications I work in, so I can ask it to find the material and do the work. I'll get into how I built that setup next week.
For this article, the important distinction is access. An approved chat tool that can read uploaded documents can help with a proposal comparison. A connected workspace can also retrieve current files, assemble the evidence, and update working documents. A sourcing platform may manage the event itself. The amount of file wrangling left to you will depend on what your company has connected and permitted, not simply which model's logo is on the screen.
Access is still uneven. In Gallup's Q2 2026 survey, 47% of U.S. employees said their organization had integrated AI tools, and one in five didn't know whether it had. That measures reported organizational adoption, not permission to upload confidential bids or give an agent access to company systems. "We have AI" is not a particularly detailed implementation plan. [5]
Use the steps below with the tools your organization allows. You can start with one approved folder of proposals and a scoring template; you don't need to build my entire business operating system to find out whether Vendor B actually answered question seven.
THE RFI - Request for Information (i.e. the pre-RFP RFP)
Most procurement / outsourcing professionals have their own definition of what an RFI vs. an RFP entails. Beyond that, most companies don't have a clear policy on when, if, or how to run one either. But the primary goals of the RFI are twofold.
First, perform a broad provider market scan for the category you are outsourcing (in other words CYA - cover your ass). Every good sourcing leader knows an RFP can get railroaded by a simple "did you look into this tiny new vendor I saw in some random whitepaper / advertisement / some dude told me about?" at the 11th hour. Often from someone who has been invited to every meeting and attended approximately none of them. Providers enter new categories, get acquired, and occasionally appear in the news for reasons their salespeople would prefer you didn't notice. You want a documented list of credible candidates and a reason for including or excluding each one.
Second, reduce the amount of heavy provider evaluation work. Find the dealbreakers before wasting everyone's time. Your executive sponsor / business team should have established the must-haves: relevant industry experience, a presence in Manila AND Krakow, a specific hosting environment, or a delivery capability you cannot compromise on. A focused RFI lets you narrow the field before doing detailed solution evaluation, pricing normalization, and negotiations. "Must be cheaper than the incumbent" is harder to establish here than it sounds, because you probably haven't made the solutions comparable yet.
I'd give AI the scope, those must-haves, and the suppliers we already know, then ask it to expand the market scan and build a screening matrix. For each provider: evidence against each requirement, source and date, the gaps, and the questions we need answered. It can also draft the RFI and compare the responses when they arrive.
The important distinction is "doesn't meet the requirement" vs. "we haven't established whether they meet it." A website that doesn't mention Krakow isn't proof the vendor can't deliver there. AI should turn that into a question, not quietly eliminate a potentially good provider. The output is a defensible shortlist for the RFP lead to approve.
RFP step 1: create the scope package
At Google we ran a literal RFP machine. There was an army of vendor-provided analysts you could request to manage the administrative and financial work, with templates and process flows for doing things the "Google way." Once you had a few under your belt, it was a very different experience from the intense two- or three-month process I was accustomed to in consulting. I'm going to assume you don't have an army waiting for your spreadsheet. AI can help with a lot of that work.
The first step in the detailed RFP was the scope package, or what we called the "spec docs." In my process at Google, that meant two files.
The first was a document describing the scope of services: what we wanted the provider to do, service levels and targets, operating hours, security requirements, and whatever else would help them understand the job. If the service was already outsourced, we'd start with the existing contract. Whether that contract described the operation anyone was actually running was a separate and occasionally exciting discovery.
The second was a spreadsheet, or a "trix" in Google speak, containing the pricing template and the specific RFP questions we needed vendors to answer. In almost every case I dealt with at Google, pricing started with a time-and-materials rate card: we specified the roles and vendors supplied rates. That included frontline staff and the people supporting them, such as team leads, quality analysts, and SMEs. Support roles might be defined by a staffing ratio, for example one team lead for every 15 frontline agents.
That pricing structure matters. If one bidder includes QA and another assumes you're providing it, comparing the frontline rates won't tell you which solution costs less. We'll come back to that.
AI can help build both files, starting with whether we understand the workflow ourselves. Give it the current contract, operating procedures, volume and service-level reports, and transcripts of interviews with the people doing the work. Ask it to map the process: inputs, activities, handoffs, systems, exceptions, outputs, and owners. Keep the current operation separate from the proposed future state. Otherwise "how we'd like it to work" quietly becomes "what the vendor has agreed to do."
Then have it identify the gaps. Who handles an exception? What happens outside business hours? Is that three-day turnaround a contractual commitment, a business target, or something Dave said in a meeting? Dave may be right. We should probably find out before putting it in the RFP.
The output should be a draft scope document, a requirements-to-question map, and a pricing template with clear units, volumes, billing assumptions, and included support roles. Require each requirement to point back to its source, or be explicitly marked as a proposal for the business to approve. AI can suggest an improved workflow and draft the interview questions; the operations team needs to confirm that the workflow is feasible and the requirements are real.
You used to spend a substantial amount of consulting time assembling this picture. AI can accelerate that discovery and drafting, but it can't interview people you never involve or discover an undocumented workaround nobody mentions. Get the people who actually run the service to review the package. They are usually the ones who know where the beautifully documented process stops and the shared spreadsheet begins.
Build the scoring model before the proposals arrive
The September article walked through the mechanics: business priorities become Criteria, each Criteria has detailed Questions, Scorers evaluate the answers, and the category scores roll up using weights that total 100%. Pricing might account for 25%, 40%, or more. The model should reflect what the business is actually trying to buy.
I'd use AI to translate the requirements into that first draft, then challenge it. Have we asked the same question three different ways? Is transition risk supposedly critical but worth almost nothing in the score? Can a vendor fail a must-have and still win because the other categories average it away?
I'd also ask it to define what a strong, acceptable, and weak answer looks like for each question. "Rate their transition plan out of ten" leaves a lot to the imagination. "Evaluate the named transition team, dependencies, milestone dates, acceptance tests, and fallback plan" gives everyone something specific to evaluate. Otherwise one scorer's eight means "credible plan" and another's means "I liked the guy." We are about to average those together and put a decimal point on the result.
The business owners approve those definitions and weights before we see the proposals. If they change later, record why and apply the revised model to every bidder. AI makes rerunning that work much easier, so "it's too late to change the spreadsheet" becomes a less convincing excuse.
Before scoring: make it show its work
Prompt writing matters here. Caitlin Sullivan's piece in Lenny's Newsletter on trustworthy AI analysis draws on more than 2,000 hours testing customer-discovery workflows. That's her testing experience, not a requirement that everyone put in 2,000 hours. There is no ceremony at hour 2,001 where the chatbot stops making shit up. [4]
I've spent an unreasonable amount of time using these tools since starting ScaleX. The useful habit is to inspect the sources, assumptions, and intermediate output before trusting the final answer. "I'll assume these rates are monthly." No, you absolutely will not. The workbook says annual. Please put the calculator down.
Start with a small sample you understand. Ask it to list the files it read, identify unreadable material, cite the evidence, and mark what it couldn't establish. Check that the citations actually support the answer. Save the corrections as reusable instructions: "Missing evidence is unresolved, not a three." "A roadmap feature isn't available at go-live." A persuasive explanation is useful, but it doesn't get to certify itself.
Give AI the proposals AND the presentations
This is where I would expect the biggest improvement in the scoring exercise itself.
I'd record and transcribe the vendor presentations, with the appropriate permissions, and put those transcripts alongside the written proposal, pricing workbook, appendices, and subsequent clarifications. Give every document a vendor, date, and version. Then ask AI to work through EVERY Criteria Question against that complete set of material.
AI isn't answering emails while the delivery lead explains the staffing model. It doesn't get bored halfway through the third presentation and enter a "3" because it can't remember whether anyone answered the question. Properly set up, it can search for the relevant details each time and show us what it found.
The deliverable should be a scoring worksheet with the proposed score, the reason, the supporting page or transcript timestamp, any conflicting statements, and the follow-up question. Ask for a coverage check too: did it actually review every question for every vendor, and were any files unreadable? If the evidence isn't there, mark it "not evidenced" and leave the score unresolved. A three is a score. "I have no idea" is a different piece of information, even if our spreadsheets have historically struggled with that distinction.
For example, the proposal says a dedicated transition team is included. In Orals, the delivery lead says those people will be shared with two other clients until month three. The pricing workbook assumes your team will perform the data migration. A useful AI evaluation brings all three statements into the same row. Now the operations lead can decide whether that still meets the requirement, and procurement can ask what a genuinely dedicated team would cost.
Written follow-ups matter too. In the original article I used the example of a vendor being asked about setting up an MPLS line in Ghana. If their answer is "never," but they later provide a relevant comparable project, that evidence needs to reach the score. AI can identify which questions the clarification affects and propose the corresponding changes, while keeping the earlier answer visible.
This gets us closer to consistent, comprehensive scoring. I wouldn't call any model automatically unbiased. The criteria can be biased, the prompt can be leading, and polished vendor language can still fool it. I'd use the same instructions for every bidder, require evidence for every score, and have the relevant SMEs review the recommendations. Keep the AI assessment separate from the human scores so it doesn't become an extra vote in the average or the answer everyone copies.
Now the review meeting can focus on the actual disagreements: "You gave this a nine, but which part of their answer supports that?" A lot more useful than asking six people whether they managed to finish the spreadsheet.
Normalize the solution before comparing the price
Every vendor is very good at making its own proposal sound comprehensive against your stated requirements. The problem is that each vendor has a different definition of both "comprehensive" and, occasionally, "your stated requirements."
One includes 24/7 staffed coverage. Another includes someone on call overnight. A third includes round-the-clock ticket intake, with resolution beginning the next business day. Put "24/7 support" beside all three and you've made a very tidy, very misleading comparison. One of those vendors is promising to fix your problem at 2 a.m. Another is promising to acknowledge that you have one.
I'd ask AI to map each proposal to one common scope: service hours, locations, languages, volumes, staffing and productivity assumptions, technology, transition responsibilities, SLAs, exclusions, and work retained by the client. For every difference, identify whether it changes service quality, client effort, cost, or risk. Then draft the clarification needed to close it.
That last part is crucial. AI shouldn't invent the price of something the vendor left out. It should identify the omission and get it into the clarification list. Keep the original offer alongside the normalized comparison so we can see exactly what changed.
Then build an apples-to-apples pricing model
In the biz, we call this creating an apples-to-apples commercial comparison, or "pricing normalization." It deserves its own master class, but the basic question is straightforward: what will we actually spend to get the complete service we need under each proposal? The cheapest rate and the cheapest solution are frequently different things.
Take a simplified, fictional example. Vendor A charges $25 per productive hour and estimates 12,000 hours to deliver the scope. Vendor B charges $30 and estimates 9,000 hours for the same scope and service levels. A costs $300,000; B costs $270,000. B's higher rate produces the lower total, provided its productivity assumption holds. Now add a required $50,000 technology license that B excluded from the quote. B costs $320,000, and A is cheaper by $20,000. Nobody changed their rate. We just finished reading the proposal.
What I want is a total cost of ownership (TCO) view for each vendor, broken out by year and across the full contract term. Make the vendors populate a common pricing template wherever you can. Then use AI to extract and reconcile the rates and assumptions, identify what they left out, and help build the comparison. Keep transition fees, recurring charges, licenses, management costs, minimum commitments, annual increases, overtime, and currency assumptions visible. Preserve the original quote next to the normalized model and use checked spreadsheet formulas for the arithmetic.
The retained / internal cost is where this gets particularly interesting. Suppose one vendor includes quality assurance, while another expects your team to do it. The second proposal needs the cost of that retained work added to its TCO. Those people don't become free because their salaries sit in a different cost center.
And it isn't always a new cash expense. Maybe the employees are already on your payroll, but now half their week is committed to checking the vendor's output. Show that capacity requirement separately from incremental spend so finance can see both the budget impact and the operational burden. "We already employ them" is not the same as "they have nothing else to do."
This is the "plug" in the business case: an explicit, supported adjustment for what you would have to provide or purchase to get the complete solution. Get the vendor to price missing scope where possible. Use internal cost assumptions approved by the business where the work stays with you. If a cost is still unknown, show the gap instead of slipping a zero into the model and hoping nobody asks.
AI can help find and organize these differences across all the proposals, then keep the model aligned as the vendors clarify their offers. It shouldn't invent the missing costs. If you are still comparing straight rate cards at this stage, you are going to have a bad time next year. Possibly while explaining why the "cheapest" vendor needs three more of your people.
Now ask the useful questions. What if volume falls 20% but we are stuck with a minimum commitment? What if the promised automation is six months late? At what volume does the transaction-based proposal become cheaper than the FTE model? Which provider looks best in year one but costs more over the full term? That attractive year-one discount deserves to meet years two and three before we get too attached.
AI can help build and rerun those scenarios without someone rebuilding six workbooks by hand. The commercial team still needs to validate the numbers and assumptions. Compare each option with a current-state baseline built on the same scope and cost definitions, and distinguish savings we can actually realize from costs that remain on our books. Otherwise we're celebrating the removal of a cost that payroll intends to keep paying.
Turn the evaluation into negotiation prep
By now we should have much more useful material than "Vendor B needs to sharpen its pencil." I have nothing against that phrase, but it is doing a remarkable amount of work for something that contains no actual negotiation strategy.
I'd ask AI to build a negotiation brief for each finalist using the scored gaps, normalized pricing, incumbent baseline, and our internal priorities. For every issue: what we want, why it matters, the evidence supporting the ask, the target outcome, the fallback, and what we could offer in exchange.
If one provider's transition fee is high, are they taking on work the others have left with us? If a vendor wants a three-year commitment in exchange for a lower rate, what are we giving up in volume flexibility? If their savings depend on automation, when does the price actually fall and who pays if it doesn't work? "We expect to automate 30% of this" is a useful starting point for a conversation. It is a terrible place to end the pricing discussion.
AI can also role-play the supplier's response and help the team prepare its next move. Ask it to argue the other side: why would the vendor reject our proposed trade, and what might be more valuable to them? A longer term, a more predictable ramp, or a volume commitment may matter more than another round of asking for 5% off. Model what each concession costs us before offering it. Keep unsupported market benchmarks out of the brief, and keep competitor-confidential prices and our walk-away points out of anything sent to suppliers.
After the best and final offers (BAFO), rerun the cost model and affected scores. Ask AI to compare the final terms with the commitments that made the vendor attractive in the first place. Did the dedicated team survive? Is the automation saving now a contractual price reduction or still an enthusiastic slide? Carry the approved commitments into the contract and transition plan, with an owner and an acceptance measure. The delivery team cannot operate a service against "but your salesperson seemed very confident."
Don't these sourcing platforms already do this?
Some of it, yes. And the answer to "are these orchestration platforms or tools that actually do the sourcing work?" is increasingly BOTH. I won't pretend I've personally tested every platform; we built a lot of our own software at Google. But there are products that coordinate the process and products that perform detailed analysis inside it, with plenty of overlap.
The orchestration layer manages the process: intake, routing, approvals, supplier participation, deadlines, and handoffs to legal, security, finance, and contracting. There is real value in not needing an archaeological expedition through Outlook to find the latest proposal. The detailed sourcing capabilities handle the work inside those steps: generating questions, evaluating responses, comparing bids, modeling awards, or negotiating within agreed limits.
Omnea is a useful example of the overlap. Its sourcing product describes policy-triggered RFx events at intake, AI-generated questions, supplier responses, AI scoring, and weighted evaluation in the same workflow. That goes beyond telling you whose approval is overdue. Its current positioning emphasizes tail spend; I'd still want it to demonstrate the detailed services evaluation described here using my own example. [1]
Keelvar combines autonomous sourcing with sourcing optimization. Its published offering includes intake-to-award automation and scenario analysis for complex bids. That is relevant when the decision involves combinations of suppliers, volumes, capacity, and award constraints that are painful to evaluate manually. [2]
Pactum is an example of AI going beyond negotiation prep into conducting supplier negotiations within buyer-defined limits. That is a different capability from asking a general-purpose model to draft your negotiation brief. [3]
These are examples of published capabilities, not a claim that I've tested all three against this workflow. Nor does "AI scoring" on a product page establish that it can reconcile a presentation transcript, a pricing workbook, and a revised proposal at the level of detail we need.
My demo request would be simple: here are three messy proposals, the Orals transcripts, and our scoring model. Show me the evidence for each score. Show me what is missing. Normalize the commercial assumptions, then change the volumes and show me what happens. Finally, show me how the approved changes get into the award record. Tell me which steps are native, which need another tool, and which still depend on a person doing the analysis. If the demo ends with "and then you export it to Excel and compare the proposals," we need to revisit which part of the job I thought I was buying.
That exercise will tell you more than a very impressive slide with the word "agentic" on it.
Try it on the RFP you already finished
I've put together two companion tools: a prompt bank covering the scope package through award and transition, and an outsourcing RFP swimlane showing the activities, decisions, handoffs, and clarification loops across the buyer team, vendors, and AI. The prompts specify the inputs, outputs, and review points so you can use them with an approved AI tool or as requirements for a sourcing platform.
Start with a completed RFP. Pick a few Criteria Questions, provide the proposals and transcripts you are permitted to use, and run the evaluation again. Compare the evidence and proposed scores with what your team recorded. Then try the pricing normalization on the same deal.
Did it catch an answer you missed? A contradiction between the presentation and the proposal? A cost excluded from the supposedly cheaper bid? Those are much better tests than whether it can summarize a deck.
We have spent years trying to get busy people to do this work thoroughly. AI gives us a practical way to make the thorough version easier, and to spend the review meeting on the questions that actually change the decision. I'd like the time back. I'd be even happier if "we scored every vendor fairly" meant we checked the answers, rather than gave everyone a three and went to lunch.
Sources
[1] Omnea, AI Sourcing Software: https://www.omnea.co/products/sourcing
[2] Keelvar, Agentic Sourcing and Sourcing Optimizer overview: https://www.keelvar.com/
[3] Pactum, What Are Agentic Negotiations in Procurement?: https://pactum.com/blog/agentic-negotiations-procurement?hs_amp=true
[4] Caitlin Sullivan, How to do AI analysis you can actually trust, Lenny's Newsletter, February 17, 2026: https://www.lennysnewsletter.com/p/how-to-do-ai-analysis-you-can-actually
[5] Gallup, Organizational AI Adoption Jumps Six Points, July 20, 2026: https://www.gallup.com/workplace/712736/organizational-ai-adoption-jumps-six-points.aspx
