Running an RFI Process - A Step-by-Step Guide

You have been asked to run an IT RFI. Perhaps your team has a business problem and a rough sense that technology might solve it, but no real idea yet which vendors could help. Perhaps you tried to skip straight to an RFP and it collapsed under the weight of vendors who were never a genuine fit. Either way, you are at the point where the market needs to be asked a question before you write a single requirement.

This guide exists to make that process fast, structured, and genuinely useful. It walks through every stage of running an IT RFI, from deciding whether it is the right tool at all, through to building a confident shortlist ready for a formal RFP. We also flag where IT RFIs typically go wrong in UK organisations, and where specialist help is available if you want to move faster. We are Viewpoint Analysis, a Technology Matchmaker and we run RFI and RFP processes - so we hope this helps.

The blog is a companion piece to our guide on Running an IT RFP: A Step-by-Step Guide. If you already have a firm shortlist and are ready to evaluate detailed proposals and pricing, that is the guide you need instead. This one is for the stage before that, when you are still working out who belongs on your shortlist in the first place.

What This Guide Covers

•     What an IT RFI is, and how it differs from an RFP

•     How to decide whether an RFI is the right move right now

•     How to prepare a problem statement, not a requirements list

•     Building your vendor distribution list

•     Writing the RFI: structure, questions, and length

•     Issuing and managing the process without losing vendor goodwill

•     Evaluating responses and building your shortlist

•     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 RFI Actually Is

An IT RFI, or Request for Information, is a short document issued to a wide group of technology vendors, asking them to explain how they would approach a business problem you are facing. It is not a request to commit to a solution. It is not a request for a priced, detailed proposal. It is a market-listening exercise, issued at the point where you know you have a problem worth solving but you do not yet know who in the market can solve it.

The RFI exists to answer one question: who should be on our shortlist? Everything about the document, its length, its tone, and its questions, should be designed around answering that single question as efficiently as possible.

IT RFI vs IT RFP: The Key Differences

Confusion between an RFI and an RFP is one of the most common causes of a slow, frustrating technology selection. The short version is sequencing and depth.

Question	IT RFI	IT RFP
What is it for?	Explore the market and understand what vendors exist	Evaluate a shortlist in detail against firm requirements
How many vendors?	Wide net, often six to twelve	Narrow, typically three to five
How long is the document?	Short, five to ten pages	Longer, fifteen to twenty-five pages
What are you asking for?	Ideas, approach, and broad indicative cost	A firm proposal, implementation plan, and priced commercial offer
What is the tone?	Open and problem-led. You are listening	Structured and requirements-led. You are deciding

Many IT teams skip the RFI stage entirely and go straight to an RFP. The result is almost always the same: a bloated vendor list built on guesswork, inconsistent proposals that are hard to compare, and an evaluation that drags on because half the vendors invited were never a genuine fit. Worse still - your team will lose interest and will likely never read all the responses....

Our Viewpoint: The RFI Is About Listening, Not Deciding

The single most common mistake we see at RFI stage is treating it like a mini-RFP. Teams write detailed functional requirements, ask for indicative implementation plans, and then wonder why vendor sales teams treat the RFI as a burden rather than an opportunity.

An RFI should feel easy to respond to. You are not asking vendors to commit resource to a detailed proposal. You are asking them to tell you, in their own words, how they would approach your problem. Keep it open. Keep it light. The detail comes later, at RFP stage.

If you don't yet have any vendors in mind, use the Viewpoint Analysis Longlist Builder to generate a starting list of relevant vendors, free of charge, before you write anything.

Step 2: Decide Whether an RFI Is the Right Move Right Now

Before drafting anything, it is worth answering three honest questions.

Question 1: Do You Already Know Who Belongs on Your Shortlist?

If you already have a confident, evidence-based view of the three to five vendors worth evaluating, an RFI may simply add weeks to your timeline for little benefit. In that situation, move straight to an RFP. Our guide to running an IT RFP picks up exactly where this guide leaves off. If you don't know who to look at, the Longlist Builder is a brilliant starting point.

Question 2: Do You Need to Move Faster Than a Full RFI Allows?

A well-run RFI still takes several weeks: time to build the vendor list, time for vendors to respond, and time to evaluate what comes back. If your business genuinely cannot wait, the Technology Matchmaker approach, a problem statement followed by live vendor presentations, achieves a similar outcome in a fraction of the time. It trades a written comparison for a faster, more direct conversation.

Question 3: Have You Agreed the Problem You Are Solving, Internally?

This is the question teams most often skip, and it is the one that causes the most damage later. An RFI is only as good as the problem statement behind it. If your stakeholders have not agreed what the underlying business problem actually is, the RFI will surface that disagreement in front of the vendor community, which is not where you want it to happen. Spend real time on this before you write a word.

Step 3: Prepare Your Problem Statement Before You Write a Word

The single biggest difference between an RFI and an RFP is what you lead with. An RFP leads with requirements. An RFI leads with a problem statement, and that distinction should shape everything you prepare.

Write the Problem, Not the Solution

Describe the business challenge you are facing in plain language. What is not working today? Why does it matter, and to whom? What would a good outcome look like in twelve months? Resist the urge to describe the system you think you need. If you already know exactly what solution you want, you probably do not need an RFI at all, you need an RFP.

Agree Your Decision Criteria Early

Before you issue anything, agree internally how you will judge the responses that come back. You do not need a detailed scoring matrix at this stage, that comes later, but you do need a shared view of what will move a vendor from "interesting" to "shortlisted". Publishing a simplified version of this in the RFI itself also helps vendors calibrate their response.

Build Your Longlist

Pull together the vendors you believe could plausibly help. This does not need to be exhaustive or perfect, the RFI process itself will help you refine it, but it does need to be a genuine, researched list rather than a handful of names someone remembered from a conference.

Call Ahead

This is the step most IT teams skip, and it is the one that most affects response quality. Most vendor sales teams do not welcome an RFI landing cold in their inbox. Where possible, let key vendors know an RFI is coming, explain why they have been included, and give them a reasonable window to plan their response effort. A relationship built before the document lands will always outperform a document sent in isolation.

Tip: The Problem Statement Approach

Rather than opening your RFI with a list of questions, open with two or three paragraphs of genuine context: what the business does, what is not working, and why it matters now. Vendors respond far more thoughtfully to a real problem than to a form. The questions that follow should exist to help them answer that problem clearly, not to replace it.

Step 4: Build Your RFI Distribution List

Unlike an RFP, which should go to a tight shortlist of three to five vendors, an RFI can and should cast a wider net. Because the ask is lighter and the commitment smaller, six to twelve vendors is a reasonable range for most mid-market technology categories. This is precisely where the RFI earns its place in the process: it lets you test a broader field before narrowing down to the shortlist that will go through the heavier RFP evaluation.

When building your RFI distribution list, consider:

•     Direct competitors in the specific category you are buying, not just the household names

•     At least one or two vendors you have not worked with before, to genuinely test the market rather than confirm existing assumptions

•     Whether each vendor has a credible presence in your sector or geography

•     Whether the vendor is likely to be a realistic commercial fit for your scale, both too small and too large can be a poor match

•     Any vendor your business has a prior relationship with, positive or negative, and whether that history should influence inclusion

Our Viewpoint: Resist the Urge to Trim the List Too Early

Teams under time pressure often want to skip straight to a shortlist of three or four vendors and call it an RFI. That is not an RFI, it is a short RFP with a different name, and it defeats the purpose of running a market scan at all.

The value of an RFI comes specifically from hearing a genuinely broad range of approaches, including from vendors you were not previously aware of. If your RFI list looks identical to the shortlist you would have written from memory, the exercise has not done its job!

Step 5: Write the RFI Document

An effective IT RFI is short, readable, and genuinely interesting to a vendor sales team deciding whether to invest time in a response. Here is the structure we recommend.

Section 1: Company Information

A brief summary of your organisation: what you do, roughly how big you are, and where this requirement sits within the business. Keep it short, but make it real. Vendors want reassurance they are responding to a credible, live project.

Section 2: The Problem Statement

This is the heart of the document. Describe the challenge in plain language, why it matters, and what success would look like. This section should do more work than any other in the document, it is what determines whether a vendor engages seriously or files your RFI in the no-bid pile.

Section 3: The Process

Explain what happens after the RFI. When will you shortlist? What does the RFP stage look like, roughly? When do you aim to have a vendor selected and live? Vendors are more willing to invest effort when they can see a credible, well-paced process ahead of them.

Section 4: Questions

Ask open, outcome-focused questions rather than a checklist of features. Good RFI questions typically cover: how would you approach this problem, what does a typical implementation of this kind look like for you, who are two or three comparable customers, and what would you need from us to scope this properly. Avoid asking for detailed pricing at this stage, an indicative range or model is enough.

Section 5: Dates and Response Format

State clearly when you want responses back, and in what format. Keep the format simple, a written document or a short structured template is usually sufficient. Avoid demanding elaborate submissions for what is, at this stage, an exploratory exercise.

Section 6: Decision Criteria

Give vendors a simplified view of how you will assess responses. You do not need to publish full weightings, but a short outline builds trust and helps vendors focus their effort where it matters most to you.

Section 7: Contact Information and Invitation to Engage

Provide a single named point of contact for questions, and ideally offer a short call before the response deadline for any vendor who wants one. Very few vendors will commit real time to a document from an organisation they have never spoken to.

IT RFI Length: How Long Should It Be?

A focused IT RFI for a mid-market technology requirement should run to somewhere between five and ten pages, roughly a third the length of the RFP that may follow it. If your RFI is longer than your RFP, something has gone wrong. The RFI's job is to open a conversation, not close one.

Step 6: Issue the RFI and Manage the Process

Once your RFI is drafted and internally approved, how you manage the process matters as much as the document itself.

Issuing the RFI

Send the RFI to all vendors on your list at the same time, with a short covering note explaining the context and the timeline. Simultaneous issue keeps the process fair and avoids any perception that one vendor was given a head start.

Note - most people find this the hardest part - actually making the first contact and finding the right people to speak to. We have a free service here that could be really helpful - Free Vendor Connector Service - it comes with a few helpful services, and importantly, it sees Viewpoint Analysis help to connect you straight to the right sales team.

Give Realistic Timescales

Two to four weeks is a reasonable window for most technology RFIs, assuming vendors have had some advance notice. Rushed timescales signal disorganisation and will reduce both the number and the quality of responses you receive. Remember that responding to an RFI is entirely optional for a vendor, so there is little to be gained from being aggressive about deadlines.

Handle Questions Fairly

Set a cut-off date for clarification questions, collate everything received, and issue a single set of answers to all vendors at once. This keeps the process transparent and avoids any single vendor gaining an information advantage.

Stay Visible

One of the most damaging things a buyer can do during an RFI is go quiet after issuing the document. Acknowledge submissions on receipt, and if your internal timeline slips, tell vendors proactively rather than letting them find out by asking.

Our Viewpoint: Vendors Are Choosing You Too

It is easy to forget, especially on a first RFI, that the vendor sales team is also deciding whether you are worth their time. A well-run, respectful process with realistic timescales and clear communication will attract stronger responses from stronger vendors. A chaotic one will attract whoever had the least else to do that quarter.

Step 7: Evaluate Responses and Build Your Shortlist

With RFI responses in hand, the goal shifts to narrowing a wide field down to a genuine shortlist, typically three to five vendors, ready for a formal RFP.

Score Against What You Published

Use the decision criteria you set out in the RFI as your evaluation framework, applied consistently across every response. A simple weighted approach at this stage might look like the following.

Evaluation Criterion	Suggested Weighting	Notes
Problem/requirement fit	35%	Does the vendor's proposed approach genuinely address the problem you described?
Credibility and relevant experience	25%	UK presence, sector experience, comparable customer examples
Quality and clarity of response	15%	Did they engage with your specific problem or send a generic pitch?
Indicative cost and commercial model	15%	Ballpark only at this stage, but enough to rule out obvious mismatches
Engagement and responsiveness	10%	Did they ask good questions and meet the deadline?

This is deliberately lighter than the scoring framework you would use at RFP stage. You are not trying to pick a winner yet, you are trying to identify who deserves a place in the more detailed evaluation to come.

Look Beyond the Document

Written responses vary enormously in quality of presentation, which is not the same as quality of fit. Where a response is borderline, a short qualifying call can reveal far more than another read of the document. Some of the strongest vendors are simply not the strongest writers.

Watch for Incumbent Bias

If an existing supplier is part of the RFI, be conscious of the tendency to read their response more favourably simply through familiarity. The RFI exists to open up the market, not to quietly confirm a decision you had already made.

Document Your Reasoning

Keep a clear, written record of why each vendor did or did not make the shortlist. This matters for internal governance, and it matters when unsuccessful vendors, reasonably, ask for feedback.

Step 8: Communicate the Outcome and Move to RFP

Once your shortlist is agreed internally, notify every vendor who responded, not just the ones going through to the next stage. Vendors who were not shortlisted deserve a timely, courteous message and, where possible, brief feedback on why. This costs little and preserves goodwill in a market that is smaller than it looks.

For the vendors moving forward, be clear about what happens next. The output of a well-run RFI is a confident, evidence-based shortlist, exactly what a strong RFP needs to build on. If you have not already, this is the point to move to our companion guide, Running an IT RFP: A Step-by-Step Guide, which picks up from exactly this stage.

The Most Common IT RFI Mistakes (and How to Avoid Them)

Having run RFI processes across a wide range of technology categories, these are the mistakes we see most often:

•     Treating it like a mini-RFP. Detailed functional requirements and demands for firm pricing at RFI stage reduce response quality and put vendors off. Keep it problem-led and open.

•     Sending it to the wrong vendors. An RFI is only as useful as the list it goes to. Research your longlist properly rather than relying on names you already know.

•     Sending it to too few vendors. Trimming the list to three or four before you have even heard from the market defeats the purpose of running an RFI at all.

•     Making it too long. A lengthy, complex RFI reduces your response rate. Vendors will no-bid a document that feels like more effort than the opportunity justifies.

•     Skipping the internal problem statement. If your own stakeholders have not agreed the problem, the RFI will surface that disagreement in front of your vendor community.

•     Setting unrealistic timescales. Aggressive deadlines signal disorganisation and produce weaker responses. Give vendors a fair, realistic window.

•     Going quiet after issue. Vendors who invest time in a response deserve acknowledgement and, eventually, an outcome. Silence damages your reputation in the market.

•     Confusing RFI evaluation with RFP evaluation. Scoring an RFI as though it were a final decision slows the process down. You are building a shortlist, not choosing a winner.

•     Not calling ahead. An RFI that lands cold, with no prior relationship or context, will always generate weaker engagement than one vendors were expecting.

How Viewpoint Analysis Can Help You Run Your IT RFI

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 are not tied to any technology vendor, and 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 RFI and Market Scanning Services

• Rapid RFI Service | Our managed RFI service. We interview your team to understand the problem, write the RFI in vendor-friendly language, identify and approach the right vendors, manage all vendor communication, and guide you to a confident shortlist. Learn more.

• Technology Matchmaker Service | Our free, buyer-facing alternative to a written RFI. We issue a short problem statement to the vendor community and host live vendor presentations instead of managing written responses. Funded by vendor introduction fees, not buyer fees. Learn more.

  
  

• 30-Day Selection Process | Combines our Rapid RFI and Rapid RFP into a single streamlined process. Go from a standing start to vendor selection in a month. Learn more.

  
  

• Longlist Builder | Not sure which vendors should receive your RFI? Enter your requirements and receive a personalised vendor longlist within 48 hours, free to use. Build your longlist.

Ready to Start? Talk to Viewpoint Analysis

If you are about to run an IT RFI and want an expert view on your approach before you issue anything, we offer a free initial consultation. We will review your problem statement, advise on distribution list size, and tell you honestly whether an RFI is the right step right now.

Request a free consultation

Final Word

A well-run IT RFI does not need to be a drawn-out research exercise. With a clear problem statement, a genuinely broad distribution list, a short and readable document, and a disciplined evaluation approach, most organisations can move from a standing start to a confident shortlist in three to four weeks.

The organisations that struggle are those that skip the internal groundwork, write the RFI like a requirements document, or narrow the field before they have genuinely tested the market. The organisations that succeed treat the RFI for what it is: a listening exercise that sets the ceiling for everything that follows.

If you are about to run an IT RFI and want to do it well, we are here to help. Viewpoint Analysis can run your process, advise from the sidelines, or do everything in between.