Running an IT RFP: A Step-by-Step Guide
- Phil Turton
- 6 hours ago
- 14 min read
By Phil Turton, Viewpoint Analysis | Independent Technology Matchmakers
You have been asked to run an IT RFP. Perhaps it is the first time. Perhaps you have done it before and it went on far too long. Either way, you probably already know that a poorly run Request for Proposal process can drain months of resource, frustrate potential suppliers, and still leave you uncertain about which vendor to choose.
This guide exists to fix that. Whether you are in procurement, IT leadership, or a business team taking ownership of a technology decision, this step-by-step walkthrough covers everything you need to run an IT RFP that is fast, structured, and defensible.
We also share where IT RFPs typically go wrong in UK organisations, how to avoid the most common mistakes, and where specialist help is available if you want to move faster.
What This Guide Covers • What an IT RFP is and when to use one • The difference between an RFI and an RFP • How to prepare before you issue anything • Writing the RFP: structure, questions, and length • Managing the vendor process: Q&A, scoring, and shortlisting • Making the decision and communicating the outcome • Common mistakes UK IT teams make, and how to avoid them • How Viewpoint Analysis can help you move faster |
Step 1: Understand What an IT RFP Actually Is
An IT RFP, or Request for Proposal, is a formal document issued by an organisation to a shortlist of technology vendors. It asks each vendor to propose how their solution would meet your specific requirements, and at what cost.
An IT RFP is not a market scan. It is not a conversation opener. It is a structured buying document issued when you already have a clear idea of what you need and you are genuinely ready to make a decision. If you aren't at this point, there are two places you should look:
If you have a business problem and know that you need a new solution but don't know what vendors can help you, we need to first of all find the right technology players that can meet your needs. The best first step for that you can use the Viewpoint Analysis 'Longlist Builder' to build a list of vendor options that will previsly fit your needs. It's free and will save you a lot of time researching the market.
If you have a list of vendors, you need to run a quick beauty parade or market scan to get to your shortlist. A great way to do this is to issue a 'problem statement' and ask the vendor community to pitch how they help you. Take a look at the Viewpoint Analysis 'Technology Matchmaker Service' or run a 'Rapid RFI' - both will quickly boil down the options.
IT RFP vs IT RFI: What is the Difference?
This is one of the most common points of confusion in technology procurement. The short answer is sequencing:
Document | Purpose | When to Use It |
IT RFI (Request for Information) | Explore the market. Understand what vendors exist and how they would approach your problem. | Early stage. You are not yet ready to buy but want to build a qualified longlist. |
IT RFP (Request for Proposal) | Evaluate a shortlist in detail. Gather structured proposals, pricing, and implementation plans. | Later stage. You have a clear shortlist and a genuine intent to purchase. |
Many UK IT teams issue an RFP too early, before they have done the market scanning work. The result is a bloated vendor list, inconsistent responses, and an evaluation that takes months rather than weeks. If you are not sure which you need first, read our guide to running an IT RFI.
Our Viewpoint: RFI vs RFP Timing Issuing an RFP without first running a proper market assessment is one of the most common and most avoidable mistakes we see. You end up with eight or nine vendor responses when you should have had three, and the evaluation process takes twice as long. Start with a structured longlist. Then shortlist. Then RFP. What you might not see is the work needed to run a broad RFP process. It doesn't just fall on the person running the process, it falls on the most important people - the selection team. Remember that for every vendor in the RFP process, you have:
|
Step 2: Decide Whether an IT RFP is the Right Move Right Now
Before you invest time in writing an RFP, there are two questions every IT team should answer honestly.
Question 1: Is this definitely a new purchase decision?
If you are already running a system that is underperforming, it is worth asking whether the problem is the technology or the way it is being used. Replacing software is expensive and disruptive. If the root issue is poor configuration, undertrained users, or a difficult vendor relationship, switching may solve nothing.
Viewpoint Analysis offers a Stick or Switch Application Review for organisations who are unsure whether to stay with their current system or move on. It is a structured diagnostic that saves significant time and money when the honest answer turns out to be: fix what you have.
Question 2: Do you have enough internal clarity to run an RFP?
An IT RFP is only as good as the requirements behind it. If your stakeholders have not agreed what the new system needs to do, issuing an RFP will surface those disagreements in public, in front of your vendors. That is not a good position to be in. The prerequisite for a successful IT RFP is a clear, agreed problem statement: what challenge are we solving, why does it matter, and what does success look like? This is worth spending real time on before anything else.
Question 3: Do you have the support of your leadership team - and the team you are buying the system for?
We have seen too many RFPs issued without real executive support (and budget), and without the buy-in of the teams who have to invest time in the process. It leads to a process that collapses - and egg on the face of the RFP lead and the buying company.
Step 3: Prepare Your Requirements Before You Write a Word
The single biggest driver of a slow, painful IT RFP process is vague or incomplete requirements. Vendors cannot respond well to requirements they do not understand. And evaluation teams cannot score responses objectively without a shared framework.
Preparation before writing your RFP should cover four areas:
1. Business Requirements
What does the business need this technology to achieve? These are outcome-based requirements, not feature lists. Examples include: reduce month-end close from 10 days to 5, enable self-service HR for 2,500 employees, or automate invoice processing across three business units.
2. Functional Requirements
What must the system actually do? This is where feature requirements belong. Group them into must-have (deal-breakers if absent) and nice-to-have (desirable but not essential). Avoid listing hundreds of requirements. A focused list of 30 to 50 well-written requirements is more useful than a sprawling spreadsheet of 200. It's good to be able to issue this to the vendors - but it's also good to make sure the internal team knows what they are buying, before they are blinded by all the potential bells and whistles they will invariably see.
3. Technical Requirements
How must the system integrate, operate, and comply? UK-specific technical requirements increasingly include data residency (is data stored in the UK or the EU?), compliance with UK GDPR, compatibility with Making Tax Digital etc. Have you spoken to your IT team - and do they have a representative that will be actively involved in the process?
4. Commercial Requirements
What is your budget envelope? What is your preferred commercial model (SaaS subscription, perpetual licence, managed service)? What implementation timeline are you working to?
Tip: The Problem Statement Approach to Requirements Rather than issuing a long requirements spreadsheet, the most effective modern IT RFPs open with a clear problem statement and then ask vendors to propose their solution. This approach invites genuine engagement from vendors and often surfaces better proposals than a checkbox exercise. You still need your must-have requirements as evaluation criteria, but you lead with context, not a form. |
Step 4: Build Your IT RFP Shortlist
An IT RFP should be sent to no more than three to five vendors. Any more than this and you have too many responses to evaluate objectively, and you signal to the market that you have not done your preparation work. IF you do go with more than say 4 or 5 vendors - expect some of those vendors to qualify out. If you signal to the market that you are issuing to a shortlist - they will expect it to be short, and they will expect to have a fair chance of winning.
When selecting vendors for your IT RFP shortlist from your market scan, consider the following criteria:
What is the User Interface (UI) like, and can your team live with it?
How do the vendors charge? What is the ballpark budget, and can your CFO accommodate spending that level of spend?
Are you buying a system that can be configured or are you going to have to build it?
Are they profitable?
Have you credit-checked them?
Who implements the solution?
How much does the implementation cost?
How long does it take to install?
The list goes on; this is where an experienced RFP process partner will come in handy, as they will have a checklist to review.
Step 5: Write Your IT RFP Document
A well-structured IT RFP does not need to be a lengthy document. The purpose is clarity, not volume. Here is the structure we recommend:
Section 1: Introduction and Background
Introduce your organisation, the context for this procurement, and what you are trying to achieve. Include the scale of the requirement (number of users, sites, transaction volumes where relevant) and any relevant background on your current technology landscape.
Section 2: The Problem Statement
Describe the problem you are solving in plain language. What is not working today? What does the future state look like? Why does this matter to the business? A well-written problem statement gives vendors the context they need to craft a genuinely relevant response.
Section 3: Functional and Technical Requirements
List your requirements clearly, separating mandatory requirements (which you will score as pass/fail) from desirable requirements (which you will score on a scale). Keep the list focused.
Section 4: Vendor Qualification Questions
Ask vendors to confirm key qualifying information: UK presence, relevant certifications (ISO 27001, Cyber Essentials Plus), customer references, implementation approach, support model, and data residency. These responses tell you whether a vendor is a credible partner, not just a credible product.
Section 5: Pricing
Ask for a structured pricing response that covers: licence or subscription fees, implementation costs, training costs, ongoing support costs, and any additional costs that apply at your scale. Specify the format you want, otherwise you will receive ten different pricing structures that are impossible to compare.
Section 6: Commercial Terms
Include your preferred contract length, payment terms, and any standard commercial terms you expect vendors to accept or comment on. This avoids surprises at the contract stage.
Section 7: Process and Timeline
Set out clearly: the RFP issue date, the deadline for clarification questions, the RFP response deadline, the dates for presentations or demonstrations, and your target decision date. Vendors need this to resource their response effort properly.
IT RFP Length: How Long Should It Be? A focused IT RFP for a mid-market technology purchase should run to fifteen to twenty-five pages. The longer your document, the fewer quality responses you will receive. Just like it's a burden on your team to read an RFP response - it's also a burden on the IT vendor's team to read the RFP - and the more hurdles they have to jump (e.g. if you ask 500 questions) the more likely they will bow out. |
Step 6: Issue the IT RFP and Manage the Process
Once your IT RFP is written and approved internally, the vendor management phase begins. This is where many IT RFP processes quietly fall apart, not because of the document, but because of poor process management.
Calling Ahead
NEVER just issue an RFP - always make sure that the sales teams have lots of notice and understand why you have chosen them to be a part of the process. If you have run at Technology Matchmaker or run a Rapid RFI or similar, you don't need to worry. If you haven't, don't make the mistake of just dropping it on them.
Issuing the RFP
Send the RFP simultaneously to all shortlisted vendors. Include a covering note that explains the context, confirms the timeline, and provides a single named point of contact for questions. Do not brief vendors individually before issuing, as this creates an uneven playing field.
Managing Clarification Questions
Create a cut-off date for clarification questions, typically one to two weeks after issue. Collate all questions received and issue a single Q&A document to all vendors simultaneously. This keeps the process fair and avoids any vendor gaining an advantage from early access to clarifications.
Running a Supplier Panel
Rather than running multiple one-to-one calls during the RFP period, consider running a single virtual Supplier Panel, a group Q&A session where all vendors can hear the same questions and answers. This saves significant time for the buying team and ensures consistency. Viewpoint Analysis uses this approach in its Rapid RFP service.
Receiving Responses
Acknowledge all responses on receipt. If a vendor misses the deadline, decide in advance whether you will accept late submissions and stick to that decision. Inconsistency here creates procurement risk.
Our Viewpoint: Vendor Communication Vendors put real resource into responding to IT RFPs. The best ones will resource the response based on their assessment of the buyer's seriousness and the quality of the process. A professional, well-run process attracts professional, well-considered responses. Treat vendors as potential partners, not just respondents. |
Step 7: Score and Evaluate Responses
Scoring IT RFP responses objectively is harder than it sounds. Without a pre-agreed framework, evaluation becomes subjective, and subjective decisions are difficult to defend if challenged.
Build Your Scoring Matrix Before You Read the Responses
Define your evaluation criteria and their relative weighting before the responses arrive. A typical weighting framework for an IT RFP might look like this:
Evaluation Criterion | Suggested Weighting | Notes |
Functional fit (requirements met) | 30% | Score mandatory requirements as pass/fail, then desirables on a scale |
Technical fit and integration capability | 20% | Include data residency, security certifications, API capability |
Implementation approach and timeline | 15% | Realism, methodology, resource commitment from vendor |
Vendor credibility and references | 15% | UK presence, relevant industry experience, customer examples |
Pricing and commercial terms | 15% | Total cost of ownership over three years, not headline licence only |
Support model and SLAs | 5% | UK-based support hours, response times, escalation process |
Involve Multiple Evaluators
Scoring should involve a team of evaluators, ideally including a business stakeholder, an IT representative, and a procurement or finance lead. Use independent scoring first, then a moderation session to agree a consensus. This reduces the risk of any single evaluator's preference dominating. Scoring using a simple three point scale is our preferred approach - it means your team have to make a tough decision.
Demonstrations and Presentations
Invite your vendors to present and demonstrate their solution. Provide a structured agenda in advance, including a defined scenario for the demonstration. Do not let vendors run a generic product demo; insist that the demonstration addresses your specific requirements and problem statement.
Reference Checks
Before making a final decision, speak with at least two customer references provided by each shortlisted vendor. Ask references specifically about implementation experience, the quality of ongoing support, and whether the vendor delivered what they promised. Positive references are almost universal; what you are looking for is genuine depth of satisfaction rather than rehearsed endorsement.
Step 8: Make the Decision and Communicate the Outcome
Once scoring, demonstrations, and reference checks are complete, you should have enough information to make a well-founded decision. Consolidate your evaluation scores, record the rationale for your recommendation, and present this to your internal stakeholders for approval.
Communicating to Successful and Unsuccessful Vendors
Notify the winning vendor promptly and move quickly to contract. Delays at this stage increase the risk of the vendor's sales team moving on to other opportunities. Notify unsuccessful vendors as soon as the decision is confirmed. Offer deep feedback where you can. Vendors invest significant resources in responding to RFPs, and professional feedback builds goodwill, even in rejection. The market is smaller than you think.
Don't Forget: Contract Negotiation is Part of the Process Many IT RFP guides end at vendor selection. But the contract negotiation phase deserves its own attention. Key areas to address include: SLA commitments and service credits, data ownership and exit rights, price protection over the contract term, implementation milestones and payment gates, and UK GDPR data processing agreements. Do not accept a vendor's standard terms without review. |
The Most Common IT RFP Mistakes (and How to Avoid Them)
In our years of running technology selections and taking part in them, these are the mistakes we see most often:
Issuing the RFP too early. Running an RFP before you have done market scanning means you are evaluating vendors you should never have invited. Do the RFI work first.
Assuming the vendors will all want to respond. You will lose some of your vendors along the way. It could be that they had a bad experience with your company previously, or it might be they are busy, or it could be that the sales lead is not interested and focused on another key deal.
Sending to too many vendors. More than five vendors on an IT RFP shortlist is almost always a sign that the preparation phase was skipped. Quality over quantity.
Requirements that are too vague. Vendors cannot respond to requirements like 'the system should be user-friendly'. Be specific. Use measurable criteria wherever possible.
Requirements that are too prescriptive. Over-specifying your requirements locks you into a solution design before you have heard from vendors. Leave room for vendors to propose their approach.
Not selling the project. If you want the key vendors to want to work with you, you had better make sure they know why. Let them know you are keen to work with them.
No pre-agreed scoring framework. If you score responses after reading them, you are introducing unconscious bias. Build the scoring matrix first.
Ignoring total cost of ownership. Headline licence costs are rarely the full picture. Always ask for a three-year total cost of ownership breakdown, including implementation, training, and support.
Allowing the process to drift. IT RFPs that lack a firm timeline almost always overrun. Set deadlines and stick to them. Missing deadlines is a sure-fire way of losing some of your key vendors from the process. If you expect the vendors to be professional and meet your deadlines, know that they will expect you to do the same.
Forgetting to involve legal and security early. UK GDPR requirements, data processing agreements, and cyber security assessments take time. Brief these teams at the start, not at the contract stage.
How Viewpoint Analysis Can Help You Run Your IT RFP
Viewpoint Analysis is an independent Technology Matchmaker. We help enterprise IT buyers run faster, sharper technology selection processes, from initial market scanning through to vendor selection and contract. We don't mind what you are looking to buy - the process remains pretty much the same - whether it be ERP or Route Planning Software, or CRM or Unified Communications - an IT RFP is an IT RFP - it has a problem to solve and a process to follow.
We are not tied to any technology vendor. We do not receive fees from vendors for recommending them. Our only objective is to help you find and select the right technology as quickly as possible.
Our IT RFP and Selection Services
Rapid RFP Service | Our flagship managed IT RFP service. We build the RFP document, manage vendor communications, run the Supplier Panel Q&A session, and support your evaluation and scoring. Typical engagements run from six to ten weeks from kick-off to preferred vendor decision. Learn more.
30 Day Selection Process | Our fastest process that combines our Rapid RFI and Rapid RFP into one slick 30-day process. Go from a standing-start to vendor selection in a month - ideal for projects that have to move fast. Learn more.
IT RFP Template | A free, structured IT RFP template that you can download and adapt for your own procurement. Includes prompts for every section of a well-structured RFP. Download free.
Longlist Builder | Not sure which vendors should be on your shortlist? Enter your requirements and receive a personalised vendor longlist within 48 hours. Free to use. Build your longlist.
Technology Matchmaker Service | Our free buyer-facing service that manages the full process from requirements definition through to shortlist. Funded by vendor introduction fees, not buyer fees. Learn more.
Enterprise Software Selection Playbook 2026 | For a complete guide to every phase of the enterprise software selection journey, including RFI, RFP, scoring, and decision-making, read our comprehensive playbook. Read the playbook.
Ready to Start? Talk to Viewpoint Analysis If you are about to run an IT RFP and want an expert view on your approach before you issue anything, we offer a free initial consultation. We will review your requirements, advise on shortlist size and structure, and tell you honestly whether an RFP is the right step right now. |
Final Word
A well-run IT RFP does not have to be a months-long ordeal. With clear requirements, a focused shortlist, a structured document, and a disciplined evaluation process, most technology selections can move from RFP issue to preferred vendor in six to eight weeks.
The organisations that struggle are those that skip the preparation work, invite too many vendors, or allow the process to drift without a firm timeline. The organisations that succeed treat the RFP as a professional procurement exercise, not a paperwork formality.
If you are about to run an IT RFP and want to do it well, we are here to help
Viewpoint Analysis can run your process, act as an advisor, and everything or anything you need.