Step 1: Confirm you need an RFP and name the team
An RFP is worth the effort when the spend is significant, the requirements are complex, or policy requires competitive bidding. For a simple, low-value purchase, a short quote request or a direct negotiation is usually faster and just as effective.
Before drafting, agree on:
- Owner: one person who runs the process and is the single point of contact for vendors.
- Evaluation panel: usually a business owner, an end-user representative, IT or security, finance, and legal. Keep it small enough to schedule.
- Budget range: an internal figure, even a rough one. It keeps requirements realistic.
- Decision authority: who signs off on the final choice, and what spend thresholds apply.
Write this down in a one-page brief. It prevents scope arguments halfway through.
Step 2: Define the problem before the requirements
Start with the business problem, not a feature list. Vendors propose better solutions when they understand what you are trying to fix.
Your background section should cover:
- What you do today and what is not working.
- The outcomes you need, in measurable terms where possible.
- Volumes and scale: users, locations, transactions, data size, hours of coverage.
- Current systems the solution must connect to.
- Constraints: deadlines, regulations, data residency, internal policies.
Example wording:
We process about 4,000 supplier invoices per month across three entities using email and spreadsheets. Approval cycles are slow and we lack visibility into committed spend. We are looking for a solution that routes approvals automatically, integrates with our ERP, and gives finance a real-time view of open liabilities. Go-live is required before the start of our next fiscal year.
For services RFPs, describe the scope of work, the deliverables, and what your team will still handle internally. Unclear boundaries are the main source of change orders later.
Step 3: Write requirements vendors can actually answer
Put requirements in a table, not in prose. Give each one an ID, a priority, and a response format.
Suggested columns:
- Requirement ID (for example, FUN-012)
- Requirement description
- Priority: Must have, Should have, Nice to have
- Vendor response: Available now, Configurable, Requires custom work, Roadmap, Not available
- Vendor comments or evidence
Rules that keep responses useful:
- One requirement per line. "Supports SSO and role-based permissions" should be two rows.
- Ask how, not whether. "Describe how approval rules are configured and who can change them" beats "Do you support approval rules?"
- Limit Must haves to true dealbreakers. If everything is mandatory, nothing is.
- Group by category: functional, technical and integration, security and compliance, support and service levels, implementation, and commercial.
- Ask for evidence on critical items: demo, documentation, certifications, or references.
For security, attach your standard questionnaire or ask for the vendor's existing one plus relevant audit reports, rather than writing a new list from scratch.
Step 4: Build a pricing template so bids are comparable
If you let vendors price in their own format, you will spend days normalizing numbers. Provide a pricing sheet and require vendors to use it.
Include:
- One-time costs: implementation, configuration, data migration, training.
- Recurring costs: licenses or subscriptions by unit (user, seat, transaction, entity), support, hosting.
- Services rates: day or hourly rates by role, if applicable.
- Pricing for your stated volumes plus one or two growth scenarios.
- A total cost over the expected contract term, commonly three to five years for software.
Also ask vendors to state:
- Annual price increase terms or caps.
- Minimum commitments and what happens if you fall below them.
- Anything not included that you would likely need.
- Payment terms and billing frequency.
Asking for total cost across the full term exposes low first-year pricing that climbs later.
Step 5: Set scoring criteria before you send the RFP
Agree on how you will evaluate responses before you see them. It keeps the decision defensible and reduces bias toward the vendor with the best presentation.
Example weighting (adjust to your priorities):
- Functional fit: 35%
- Technical, integration and security: 20%
- Implementation approach and team: 15%
- Total cost: 20%
- Vendor viability and references: 10%
Use a simple scale, such as 0 to 5, with written definitions for each score. For example: 0 means not met, 3 means met as described, 5 means exceeds with strong evidence.
Treat Must haves as pass or fail gates before scoring. A vendor that misses a true dealbreaker should not stay in contention because of a strong price. Have panelists score independently first, then meet to discuss large gaps.
Step 6: State the process rules and contract terms up front
Include a clear timeline. A typical sequence:
- RFP issued
- Intent to respond due
- Vendor questions due
- Answers published to all vendors
- Proposals due
- Shortlist notified
- Demos or presentations
- Final negotiation and award
Give vendors enough time to respond well. Two to four weeks is a common window for software and services, longer for complex scopes.
Process rules to state:
- Single point of contact and a ban on contacting other staff during the process.
- How questions are submitted and that answers are shared with all bidders anonymously.
- Required response format, page limits, and file naming.
- Confidentiality terms and whether an NDA is required.
- That you are not obliged to award, and may negotiate with one or more vendors.
Contract terms: attach your key terms or template agreement and ask vendors to list exceptions in their response. Common items include liability caps, data ownership and return on exit, service level credits, termination rights, renewal notice periods, and price increase limits. Surfacing objections now saves weeks of legal back-and-forth after you have picked a winner and lost your leverage.
Step 7: Issue, manage and shortlist
Send the RFP to a focused list. Three to six qualified vendors is a common range. More than that creates evaluation work without improving outcomes.
During the response period:
- Log every question and publish answers to all vendors on the same date.
- If you change scope, issue a formal addendum and adjust the deadline if needed.
- Do not share one vendor's pricing or approach with another.
After proposals arrive, check compliance first, then score. Shortlist two or three vendors for scripted demos, where each vendor walks through the same scenarios using your data or realistic examples. Call references who run a similar scale and scope to yours. Then negotiate with your preferred vendor, keep a second option warm, and notify unsuccessful bidders with brief, factual feedback.
Let pingpong run it for you
pingpong drafts the RFP, finds and invites vendors, collects proposals through a private portal, scores them with five AI models and flags the gotchas above. It drafts every negotiation message for your approval, then keeps watching the market so you renegotiate before renewal. $100 for the first month, then $799 a month.
Common questions
How long should an RFP be?
Long enough to describe the problem, requirements, pricing format and process, and no longer. Many software and services RFPs fit in 10 to 25 pages plus a requirements spreadsheet and pricing template. Length usually grows from repeated or vague requirements, so trimming those improves response quality.
Should I include my budget in the RFP?
It depends on your goals. Sharing a range helps vendors propose a realistic scope and screens out options that are far outside it. Withholding it can encourage sharper pricing but risks proposals that are over or under scoped. Many buyers share a range for services and withhold it for standard software.
What is the difference between an RFI, RFQ and RFP?
An RFI gathers information when you are still learning what the market offers. An RFQ asks for prices on a clearly defined product or service where the main differentiator is cost. An RFP asks vendors to propose a solution and pricing for a defined problem, and is evaluated on fit, approach, and cost together.