Every procurement team we work with has the same RFP problem. The cycle takes 60 to 120 days. Most of it is not negotiation, evaluation, or strategy. It is typing. Typing the brief. Typing the supplier shortlist. Typing the scorecard. Typing the fourteen follow-up emails. Then re-typing the executive summary three times because the CFO wants a different cut.
We started running RFPs with Claude in late 2025 and the bottleneck disappeared. Not because Claude is magic. It is not. The typing layer goes away. The procurement work is still ours. What changes is that the cycle becomes hours of human decisions instead of weeks of human paperwork.
This is the workflow. We use it ourselves and we deploy it inside our clients'' procurement teams.
What Claude actually replaces in an RFP
An RFP is six steps and most of them are not procurement work:
- Define the requirements. This is procurement work. Stays human.
- Write the RFP document. Mostly typing. Goes to Claude.
- Build the supplier longlist. Half research, half formatting. Claude helps.
- Distribute, track, and chase responses. Pure admin. Claude drafts the cadence.
- Score the responses. This is procurement work. Claude prepares the scaffolding, the human scores.
- Produce shortlist plus executive memo. Formatting and re-cuts. Goes to Claude.
The pattern: Claude takes the parts that are templated, repetitive, or formatting-heavy. Humans keep judgment, relationships, and decisions. Get that boundary right and Claude is an obvious win. Get it wrong and you produce a slop RFP that no supplier wants to respond to.
Step 1: Brief Claude with the right context, not the longest context
The mistake most teams make on their first Claude RFP is pasting in a wall of unstructured context. Old RFPs, internal wiki pages, Slack threads, supplier emails, all dumped in with a request to "write us a great RFP." The output is generic because the input is generic.
We feed Claude three things, in three buckets.
Category context. What spend category is this, what is the addressable market, who are the typical players, what are the standard commercial terms in this category. One paragraph, sometimes two.
Buyer context. Our company, our scale, our existing tech stack, our compliance requirements, our risk tolerance, who the executive sponsor is, what success looks like in twelve months. This is the part most teams skip and it is the part that makes the output non-generic.
RFP intent. What we are actually trying to learn. Are we comparing incumbents to a new entrant? Replacing a tool? Consolidating three vendors into one? Each of these produces a different RFP. Naming the intent up front prevents Claude from producing a generic catch-all document.
Concretely, we put this in a "Procurement OS" Claude project so the same context is available across every RFP we run. The category context gets updated quarterly, the buyer context is updated on company changes, and the RFP intent gets typed fresh for each cycle.
Step 2: Use Claude Skills, not free-form prompts
Free-form prompts are how people first use Claude. They work, kind of, for one-offs. They do not work for running an actual procurement function because the outputs drift. Different format every time, different sections every time, different rigor every time.
We use Claude Skills. A Skill is a saved set of instructions that tells Claude how to do one specific RFP task, the same way every time. The Skills we run on every RFP cycle:
- RFP drafter. Takes the three context buckets above and produces a structured RFP document with sections for company background, requirements, commercials, evaluation criteria, and timeline.
- Supplier longlist builder. Takes the category and buyer context and returns a ranked longlist with each supplier''s positioning, geographic coverage, typical deal size, and reasons to include or exclude.
- Response scorer. Takes the evaluation criteria and a supplier''s response and returns a structured scorecard with evidence quotes from the response. The human reviewer either accepts or overrides each score with one click.
- Shortlist memo writer. Takes the scorecards and produces a three-page executive memo with three recommended suppliers and three reasons each.
We have published the underlying Skill set as a free Claude plugin at Procurement OS: 7 Claude AI Skills for Procurement. If you want to skip building these from scratch, install it.
Step 3: Score responses with Claude as the scaffold, humans as the judges
This is the step where Claude users either get it right or quietly screw up. The instinct is to let Claude score the supplier responses end-to-end. Do not do that. Scoring is procurement judgment. Outsourcing scoring to Claude produces decisions you cannot defend in front of a procurement committee or an internal auditor.
What we do instead is have Claude produce a scoring scaffold, not a score:
- Claude pulls the relevant quotes from each supplier response that map to each evaluation criterion.
- Claude pre-fills a suggested score with a one-sentence rationale.
- The human reviewer reads the evidence quote, accepts or overrides the score, and types a one-line justification.
Scoring drops from three to four hours per supplier to 30 or 45 minutes, because the reviewer is reading curated evidence instead of hunting through a 60-page response. Every score has a defensible audit trail: the quote, the criterion, the rationale.
We wrote up the full version of this with timing benchmarks in We Drafted a Real RFP in 20 Minutes Using Claude.
Step 4: Produce the executive memo last, not first
Most procurement teams write the executive memo at the end of the cycle, by hand, under pressure, on a Friday. The result is uneven. Some memos are five pages, some are one. Some have commercial summaries, some do not. The CFO gets a different format every time.
Claude solves this in about ten minutes. We have a memo Skill that takes the scored shortlist and produces a three-page memo with a fixed structure: situation, three options, recommendation, commercial impact, risks. Same structure every time. The CFO learns where to look.
The memo gets a human pass for tone and a stakeholder pass for political nuance. That takes another twenty minutes. Total memo time goes from a Friday afternoon of cursing to a 30-minute review on Thursday.
What this does to cycle time
We have run this workflow inside our own deals and inside clients'' teams for the last six months. The honest numbers:
- A simple category RFP (single function, three to five suppliers) goes from 45 days to one day of focused work.
- A complex category RFP (multi-function, ten to fifteen suppliers, multi-region) goes from 90 or 120 days down to five or seven days.
- The biggest gain is not the typing time saved. It is that procurement leaders run more RFPs per year, because the cost of running one drops. We have clients who used to run two RFPs a quarter and now run six.
The real ROI is not time saved on one RFP. It is more RFPs per year, better suppliers per category, and tighter commercial outcomes, because the unit cost of running one collapses. The full Claude cowork playbook for procurement teams covers the broader operating model behind this.
What Claude does not do, and probably never should
A few things we have deliberately kept out of the Claude loop:
- Supplier negotiation calls. Claude does not negotiate. It can prepare a negotiation playbook, BATNA analysis, and concession ladder. The actual conversation is human. Suppliers can tell.
- Final supplier selection. Claude can recommend. It does not decide. The procurement committee decides and signs.
- Anything where the evaluation criterion is "fit" or "trust." Claude is bad at those. Humans are better. We do not even ask.
How to start
If your team has never run a Claude RFP, start with one specific RFP that is already on your calendar in the next 60 days. Pick a category you know well so you can sanity-check the outputs. Run the four steps above using the Procurement OS Claude Skills as a starting kit. Time yourself against your normal cycle. The first RFP will probably feel slower than usual because you are learning the workflow. The second one will be the breakthrough.
Want help installing this workflow inside your function rather than figuring it out alone?
Book a 30-minute call