Writing the RFP as the Buyer

Is an RFP Even the Right Instrument?

An RFP is expensive for everyone. It costs your team weeks of drafting and evaluation, and it costs each vendor real money to respond, which is why good vendors decline to bid on RFPs that look like fishing expeditions. Running one when a lighter process would do is a way to get worse proposals from fewer suppliers.

Use a full RFP when the purchase is large enough to matter, when the requirements are complex enough that price alone cannot decide, when you genuinely do not know which vendor is best, and when a documented competitive process is required by a funder or your own policy. Multi-year software platforms, audit services, construction, and substantial consulting engagements usually qualify.

Use something lighter otherwise. A request for quotes works when you know exactly what you need and are comparing price and terms. A request for information is the right tool when you are still learning what the market offers and are not ready to buy. Direct negotiation with a preferred supplier is legitimate for many purchases, provided your policy permits it and you document why. Cooperative purchasing agreements and nonprofit technology consortium pricing can beat anything you would negotiate alone, and checking those first is often the highest-return hour in the whole process.

If federal award funds are involved, your procurement is governed by the federal procurement standards that apply to your organization, and those set thresholds determining when competition and specific documentation are required. Micro-purchases and small purchases have lighter requirements than larger procurements. Know which threshold your purchase falls under before you design the process, because retrofitting compliance onto a procurement you have already run is unpleasant and sometimes impossible. Our guide to AI procurement for nonprofits covers the wider policy frame.

Writing Requirements That Can Actually Be Scored

A requirement is scoreable when two different evaluators reading the same response would give it the same score. Most nonprofit RFP requirements fail that test badly, which is why evaluation meetings turn into debates about what a requirement meant rather than about which vendor met it.

The most common defect is asking whether a system can do something. Every vendor answers yes, because with enough configuration and services almost anything can be done. Ask instead how the system does it, and ask about your specific case. Not "can the system handle recurring gifts" but "describe how a monthly donor changes their gift amount and payment method themselves, and what staff involvement is required."

The second defect is asking questions whose answers are already public. If the answer appears on the vendor's website, you have spent a question learning nothing and received a polished paragraph in return. This has become more acute now that responses are drafted with AI assistance. Reserve your questions for things that are specific to you, that require the vendor to make a commitment, or that expose how they work rather than what they sell.

The third is failing to ask for evidence. A claim becomes checkable when you require a demonstration, a reference from an organization of similar size and type, a named person who will do the work with their availability, or a written commitment in the contract. Asking who specifically will staff your engagement, and what happens if that person leaves, produces more useful differentiation than most feature questions.

Ask about the difficult parts explicitly. What data migration will require from your team, what the implementation timeline assumes about your staff availability, what happens when you want to leave and how your data comes out, what has gone wrong in comparable implementations and how it was handled. Vendors answer these questions revealingly, and a candid answer about a past failure is worth more than a flawless narrative. The warning signs described in our guide to red flags in vendor pitches often first appear in these responses.

Require pricing in a fixed format you specify. Vendors present cost structures that are difficult to compare, sometimes deliberately. A mandatory table covering one-time costs, recurring costs by year for five years, per-user or per-record pricing at your projected volumes, implementation, training, support tiers, and the cost of common changes makes comparison possible. State that responses that do not use the format may be scored as incomplete, and mean it.

Where AI Helps the Buyer

Vendors have been using AI on the response side for a while. The buyer's side has more to gain, because the buyer's bottleneck is a small team doing an unfamiliar task under time pressure alongside their day jobs.

Turning discovery notes into structured requirements. You will finish discovery with interview notes, a workflow inventory, and a list of complaints. Converting that into a categorized, deduplicated requirements list organized by function and priority is exactly the kind of structuring work that takes a person two days and produces a first draft in minutes. The team then edits, which is far easier than starting from a blank page.

Rewriting weak requirements. Given a list, a model can flag requirements phrased as capability questions, requirements with no measurable answer, and requirements that duplicate each other, then propose scoreable rewrites. Treat these as suggestions to review, because the model does not know which of your requirements is the one that quietly matters most.

Generating the scoring rubric from the requirements. Producing a consistent rubric that describes what a low, adequate, and strong response looks like for each requirement is tedious and it is what makes independent scoring reliable. Draft it before responses arrive, review it as a team, and freeze it.

Normalizing responses for comparison. This is the largest single time saving. Six proposals in different formats, of different lengths, answering in different orders, can be reorganized into a matrix of requirement by vendor so evaluators read comparable answers side by side rather than reading six documents sequentially and forgetting the first by the time they reach the last. Always link each cell back to the source text so evaluators can read the original.

Finding what was not answered. Proposals frequently address a requirement with adjacent, confident text that does not answer it. Identifying requirements where a vendor's response is evasive, generic, or absent gives you a precise list of follow-up questions, and the follow-ups are usually where the real information is.

Reading the contract terms. Extracting auto-renewal clauses, price escalation, data ownership, termination rights, liability caps, and what happens to your data on exit is high-value review work that small organizations routinely skip. This supports counsel rather than replacing them, as we covered in our guide to contract review for nonprofits.

Drafting the answers to vendor questions. During the question period vendors ask clarifying questions that must be answered consistently and shared with all bidders. Drafting those responses from your requirements document keeps the answers aligned with what you actually wrote.

What AI should not do is score. A summary that says a response is weak is an evaluation, and if evaluators read that summary before forming their own view, the model has anchored the decision. Use it to organize what vendors said. Let people judge what it means. The record of who scored what, and why, is also what makes the decision defensible later.