Procurement-side pain is real — and underserved
Buyers also hate the category. Three quotes from public procurement blogs and what they tell us about how the industry has under-served the buyer side of the RFP relationship.
The proposal-software category writes almost exclusively to sellers. Most blogs, most product features, most pricing pages assume the reader is the vendor responding to RFPs. Buyers — procurement leads, evaluation panels, security teams reviewing vendor questionnaires — are an underserved audience even though their pain shows up in plain text on public blogs.
Three quotes from public procurement-side writing and what they tell us.
”Operational teams draft RFPs that read like wish lists”
Fairmarkit’s post on RFP pain points describes the buyer-side problem clearly: operational teams write requirements lists with every feature they have ever heard of, vendors respond by inflating prices or promising features they cannot deliver, and the procurement office is left mediating between an unrealistic request and a defensive response. The RFP becomes a document neither side trusts.
The implication is that buyer-side tooling — RFP drafting that pressure-tests the requirements list before publication — is as undeveloped as vendor-side tooling was in 2015. There are a small number of buyer-focused tools (RFP360, Olive, Fairmarkit itself) but the category is much smaller than the seller-side category and most of the public conversation about AI-assisted procurement is still framed around the vendor.
”An engineer spent his entire week responding to questionnaires rather than securing systems”
Safe Security’s piece on vendor security questionnaires describes the buyer-side cost of the security-questionnaire-industrial-complex from the buyer’s own employees’ perspective. Enterprise security teams now process 500-plus questionnaires a year. The same engineer who would otherwise be hardening the production environment is, in practice, reviewing answers to 200- to 400-question DDQs from vendors. Vendors recycle stale answers, buyers collect reassuring “yes” responses that don’t reflect actual security posture, and both sides know the artifact is theater.
The pain on this side is symmetrical to the vendor-side complaint we covered in the DDQ anatomy series. The vendor’s engineer is also doing this instead of building. The buyer’s engineer is doing it instead of defending. Both costs are real. Neither side is happy. The questionnaire format itself is the artifact under-serving both.
”200 to 350 questions across finance, legal, IT, security, ops, compliance”
Loopio’s research on DDQ software puts numbers on the buyer-side review burden too. A 200-to-350-question DDQ that takes a vendor 15 to 40 hours to answer also takes a buyer’s evaluation panel hours to read. Across 50 vendors a year, the buyer’s review burden compounds. Most buyer-side teams use the same approach the vendor-side teams use — copy-paste from prior reviews, light triage, deeper dives only on specific clauses.
The implication: the same retrieval-and-citation pattern that helps a vendor draft an answer would help a buyer review one. A buyer reading a vendor’s 200-question response could benefit from the same per-claim verification surface — every assertion grounded, every certification linked to its attestation, every numeric claim sourced. The buyer would read fewer pages and trust more of what they read.
What this implies for us
Three things, in order.
Most of our writing has been seller-facing. That reflects who the product currently serves — the vendor side. But the buyer side is real, the pain is documented, and the structural fixes are similar enough to the seller-side fixes that we should be writing to both audiences.
Procurement-side teardowns and analyses are content gaps in the category. Most public writing on RFPs treats the buyer as the abstract audience the document is addressed to, not as a working professional with their own toolchain and their own backlog. We should write some of that missing content.
The product roadmap has a buyer-side surface that we have under-invested in. The grounded-AI pattern that verifies a vendor’s drafted claims is the same pattern that could help a buyer evaluate them. We are looking at this. We will write more about it as the surface develops.
The category writes to sellers. Buyers read what we write because they are forced to be in this conversation. Writing to them directly is overdue. This post is a small start; it is not enough. More to come.