How Do You Run a Software RFP and Vendor Selection Process?
Run a software RFP by defining outcomes and weighted evaluation criteria before you approach the market, then test shortlisted vendors with scripted scenarios, reference checks and a negotiated contract. A fair, documented process produces a better decision and a stronger commercial position.
Written and reviewed by The Technology Office ยท Independent technology advisory
Key takeaways
- Set outcomes, scope and weighted evaluation criteria before any vendor sees your requirements.
- Keep the RFP focused on business scenarios and outcomes rather than hundreds of yes/no feature questions.
- Evaluate vendors with scripted demonstrations, reference calls and commercial due diligence, not sales presentations.
- Negotiate the contract before final commitment while you still have competitive leverage.
The short answer
A good software RFP is decided before it is issued: outcomes, scope and weighted evaluation criteria are agreed internally first, then vendors are tested against real business scenarios rather than their own sales story. Shortlist two or three, run scripted demonstrations, check references properly, and negotiate the contract while you still have competitive leverage. The process should leave a clear record of why the winner was chosen.
When do you need a formal RFP?
Not every software purchase needs one. A formal request for proposal makes sense when the system is business-critical, the spend is material, several credible vendors could meet the need, or governance requires a documented and defensible decision. Core platforms such as ERP, CRM, payroll, practice management or industry systems usually qualify.
For a low-value, easily reversible tool, a lighter comparison is often enough. Our guide on choosing a new business system covers the broader selection decision; this article focuses on running the formal process well.
The RFP process at a glance
| Stage | Key activities | Output |
|---|---|---|
| 1. Prepare | Outcomes, scope, budget range, governance, evaluation panel | Approved selection plan |
| 2. Requirements | Business scenarios, prioritised requirements, integration and security needs | Requirements pack |
| 3. Market scan | Research, optional RFI, long list | Invitation list |
| 4. Issue RFP | Clear response format, timeline, Q&A process | Vendor responses |
| 5. Evaluate | Independent scoring, moderation, shortlist | Shortlist of two or three |
| 6. Deep-dive | Scripted demos, workshops, references, due diligence | Preferred vendor |
| 7. Negotiate | Commercials, contract terms, statement of work | Signed agreement |
Stage 1: Prepare before you talk to vendors
The biggest RFP mistake is engaging vendors before the business knows what it wants. Vendors will happily fill the gap, and the requirements end up shaped around one product.
Agree internally:
- The business outcomes the system must deliver
- What is in and out of scope
- An indicative budget range and timeline
- Who sits on the evaluation panel and who makes the final decision
- How conflicts of interest will be declared and managed
Stage 2: Write requirements around scenarios
Long spreadsheets of yes/no feature questions produce responses where every vendor answers 'yes' to almost everything. Instead, describe how your business works and what must happen. For example: 'A customer order with mixed stock and back-ordered items is received, partially shipped, invoiced and the remaining items are automatically allocated when stock arrives.'
Support scenarios with a concise list of prioritised requirements (must-have, important, nice to have), plus non-functional needs: security, data residency, availability, integration, reporting, and support arrangements.
Stage 3 and 4: Scan the market and issue the RFP
Research the market to identify credible options for your size and industry. If the landscape is unclear, a short request for information can help. Then issue the RFP to a manageable number of vendors with:
- A fixed response template so answers can be compared
- A clear timeline with a question-and-answer window, sharing answers with all respondents
- Pricing schedules that force consistent cost breakdowns over several years
- A request for a draft statement of work and standard contract terms
Stage 5: Score responses consistently
Agree weighted criteria before responses arrive. A typical weighting might look like this:
- Functional fit to business scenarios
- Technical fit, integration and security
- Implementation approach, team and methodology
- Vendor viability and product roadmap
- Total cost of ownership
- Contract terms and risk
Evaluators should score independently first, then meet to moderate. Large score differences usually reveal a misunderstanding worth resolving. Record the reasons for each score.
Set a minimum threshold for must-have requirements as well. A vendor that scores well overall but fails a critical security, integration or compliance need should not progress, however attractive its price. Keeping this rule explicit prevents a strong commercial offer from masking a fundamental gap.
Stage 6: Test the shortlist properly
Invite two or three vendors to scripted demonstrations based on your scenarios, ideally using a sample of your own data. Do not let the vendor choose what to show. Follow up with:
- Reference calls with organisations of similar size and complexity, asking what went wrong and how the vendor responded
- Meetings with the proposed delivery team, not just the sales team
- Commercial and technical due diligence, covering financial stability, security practices, data ownership and exit provisions
- A total cost of ownership comparison over at least three to five years
Our technology due diligence service can provide independent assessment where the stakes are high.
Stage 7: Negotiate before you commit
Your leverage is greatest while more than one vendor remains in contention. Negotiate key terms before announcing a winner, including:
- Licence pricing, renewal caps and price protection
- Implementation scope, deliverables, acceptance criteria and payment milestones
- Service levels, support response times and remedies
- Data ownership, export rights and exit assistance
- Change request rates and governance
Our article on executive vendor management explains how to keep that leverage throughout the relationship, not just at signing.
Common RFP pitfalls
- Copying a requirements template from another organisation
- Allowing an incumbent vendor to help write the requirements
- Being swayed by the most polished presentation
- Comparing licence prices instead of total cost of ownership
- Signing the vendor's standard contract without negotiation
Why independent leadership of selection matters
The Technology Office runs software selection as independent, owner-side advisers through our technology and systems transformation service and our vendor management work. We sell no software, hold no reseller arrangements and take no implementation margin, so the only interest we represent is yours. Outcomes, decision gates and scoring criteria are fixed before any vendor is engaged, which keeps the process fair and the decision defensible to your board.
We support businesses of any size and industry across Australia, from a first major system purchase to complex multi-vendor selections, and stay involved through contracting so the commercial terms match what was promised.
Frequently asked questions
What should be included in a software RFP?
A software RFP should include business background, objectives, scope, key business scenarios, prioritised requirements, integration and security needs, the response format, evaluation approach, timeline and commercial terms you expect. It should be clear enough that vendors can respond consistently.
How many vendors should be invited to an RFP?
Many organisations do initial market research across a broader field, then invite a handful of credible vendors to respond and shortlist two or three for detailed demonstrations. Too many respondents wastes effort on both sides without improving the decision.
Should we tell vendors our budget?
Giving an indicative budget range can help vendors propose realistic solutions and avoid wasted effort. Keep firm negotiating positions private and compare responses on total cost of ownership.
What is the difference between an RFI, RFQ and RFP?
An RFI gathers market information early, an RFQ asks for prices on a clearly specified product or service, and an RFP asks vendors to propose a solution to defined business needs. Software selection usually uses an RFP, sometimes preceded by an RFI.
How do you score vendor responses fairly?
Agree weighted criteria and a scoring scale before responses arrive, have several evaluators score independently, then moderate differences together. Document the reasons for each score so the decision is defensible.
Mentioned services
These service and regional NSW pages expand on the topics covered in this article.
Need help applying this?
Bring in senior technology leadership without the full-time overhead.
The Technology Office works with Sydney and regional NSW businesses on embedded CIO support, Head of IT leadership, governance, vendor management, cost optimisation, crisis stabilisation, and no-cost technology reviews as a lighter first step.