How to Write a Software RFP (7 Steps + Template)

Short answer: Write a software RFP in seven steps: name the decision, fix the scorecard and weights before any bid arrives, describe the outcomes your team needs rather than features you saw, ask the cost and security questions that make responses comparable, keep the document short, send it to a shortlist, and score the responses side by side against the published criteria. If the process costs more hours than the contract justifies, run a structured trial instead.

A software RFP is a document that turns a buying decision into a question every vendor answers in the same order. That is its entire value, and it is a real one: without it, three vendors describe three different products in three different formats using three different price structures, and the comparison you were hoping to make quietly becomes a preference for whoever presented best. With it, you get columns that line up. What an RFP is not is a guarantee of a good decision, and a badly written one is worse than none at all, because it produces a thick stack of documents that all look serious and answer nothing you can act on.

This walkthrough builds one in seven steps, from naming the decision through to scoring the responses, and ends with a fill-in outline you can copy into a blank document. It is written for a small business buying off-the-shelf software rather than for a public agency running a formal procurement, so the emphasis is on the shortest document that still makes responses comparable. The single hardest habit it asks for is deciding how you will score before you read a word any vendor writes.

It sits beside the shortlist-and-criteria walkthroughs elsewhere on VetLoft, for a CRM, for HR software, for project management software and for accounting software. Those pick a product. This one produces the document you send out when more than one person has to agree on the pick. Put your own headcount, budget and hours into the process helper on this page as you read, and let it tell you whether an RFP is proportionate to the deal you are about to do.

What a software RFP is, and what it is not

A request for proposal is a written solicitation: you describe what you need, you ask a set of vendors to propose how they would meet it and what it would cost, and you evaluate the answers against criteria you set in advance. In enterprise and public sector buying it is a formal instrument with legal weight. In a small business it is a lighter thing, closer to a structured question set that forces every vendor onto the same page so you can compare like with like.

What it is not is a substitute for knowing what you want. An RFP is an amplifier: it takes whatever clarity you bring and multiplies it across several vendors, and it does exactly the same to confusion. Send out vague requirements and you get back vague proposals, each vague in its own direction, and the reading burden lands entirely on you. The document cannot do your thinking, and the temptation to start writing it before the thinking is done is where most bad ones begin.

It is also not a negotiation. The proposal you get back is an opening position, and the discount conversation happens later, once you have a preferred vendor and a reason to move. Treating the RFP price as final leaves money on the table, and treating the RFP as the place to squeeze on price tends to produce proposals that are cheap on paper and expensive in scope changes. Our SaaS pricing walkthrough covers where the movement actually is.

The useful mental model is that an RFP buys you comparability and a record. Comparability, because everyone answers in your order rather than theirs. A record, because six months later, when someone asks why you chose this vendor, the scored criteria answer the question better than anyone’s memory of a demo.

When a small business should skip the RFP entirely

The most valuable thing this walkthrough can tell you is when not to write one. An RFP costs your team hours, and it costs each vendor hours, and both of those costs are paid whether or not the process improves the decision. There are four conditions that make it worth paying.

The first is that several people must agree. When a decision spans finance, operations and whoever will administer the system, a shared document and a shared scorecard are cheaper than a series of meetings where each person argues from a different demo. The second is contract size. When the three-year value is large enough that a few percent matters, a structured comparison pays for itself in negotiating position alone. The third is an external expectation, from a board, an investor, a grant condition or a regulator, that a selection be documented. The fourth is switching cost: when migrating in is hard and migrating out again would be worse, deliberation is cheap insurance.

Absent all four, a shortlist and a real trial beat a solicitation. Two or three products, your own data loaded in, and a week of your team actually using them tells you more about fit than any written proposal, and our software trial walkthrough lays out how to run one that produces a decision rather than an impression.

The honest test is arithmetic. Multiply the hours the process will take by a blended internal hourly cost, and compare that against the contract value it is meant to improve. If the process costs a meaningful fraction of the deal, it is not proportionate. Run that comparison in the process helper before you commit to the format.

RFP, RFI and RFQ: three documents, three questions

Three acronyms circle this decision and they are not interchangeable, which matters because issuing the wrong one wastes a round of everybody’s time.

A request for information asks who exists and what they broadly do. It suits a category you do not know yet, where you cannot write requirements because you do not yet know what the range of solutions looks like. It should be short, it should be easy to answer, and its output is a map of the market plus a rough shortlist, not a decision.

A request for proposal asks how each vendor would meet a defined set of requirements and what it would cost. It assumes you know the problem well enough to describe it and are open about the shape of the answer. This is the instrument this walkthrough builds, and it is the right one for most small business software decisions that warrant a formal process at all.

A request for quote asks for a price against a specification you have already fixed. It suits a purchase where the product is decided and the only remaining variable is commercial terms, such as adding seats to a platform you already run or buying a specific hardware and software bundle.

The common small-business error is issuing an RFP when a fifteen-minute RFI conversation with three vendors would have produced the same shortlist in a fraction of the time. The second most common is issuing an RFP when the decision is already made and only the price is open, which is an RFQ wearing a costume, and vendors can usually tell.

Before you start

An RFP rewards preparation more than drafting, because almost every weakness in a finished document traces back to something that was not settled before writing began. Five things belong on paper first.

The decision itself, written as a sentence: what will be true when this is done, and by when. The budget range, expressed as an annual or three-year figure you would genuinely sign, not a ceiling. The named decision maker, meaning the one person who signs, plus the people whose objection would stop it. The timeline, working backwards from the date the software must be live, including implementation and migration time rather than just the selection. And the current-state description: what your team does today, in what volumes, with what tools, because that is the raw material every requirement is built from.

Gather the operational detail too, since vendors will ask for it and guessing produces bad pricing. Headcount and how many of those people will actually use the system. Transaction, ticket, record or job volumes per month. The systems this must connect to. Any data you must bring with you, and roughly how much of it. Any compliance obligation that constrains where data can live.

Set aside a working session with the people whose work the software will change, not just the people who will pay for it. The gap between what a manager thinks the workflow is and what the person doing it every day knows it to be is the single most common source of a requirement list that scores the wrong product highly. Put your headcount, budget and expected hours into the process helper now, so the cost of the process is visible before you commit to it.

Step 1: Decide the decision before you write a word

Open a blank page and write, in one sentence, what you are actually deciding. Not the category, the decision. “We will replace the spreadsheet and the shared inbox that currently run our job scheduling with a single system, live before our busy season, for a team of thirty” is a decision. “We need field service software” is a category, and it is not enough to write requirements from.

Then add the three constraints that bound it. The budget range you would genuinely sign, stated as a range. The date the system must be running, and what forces that date. And the boundary of scope: what is explicitly not in this purchase, which is the line that stops an RFP growing a payroll module halfway through.

Name the people next. One decision maker who signs. A small evaluation group, usually three to five people, who will score. And a single point of contact for vendors, because vendors talking to different people and getting different answers is how a fair process quietly stops being one. Write those names into the document itself.

Finally, write down what would make you abandon the purchase entirely. It sounds pessimistic and it is the most clarifying question in the set, because a purchase with no failure condition is a purchase that will happen regardless of what the responses say, which is the definition of the procurement theatre this walkthrough is trying to help you avoid. If nothing a vendor could write would change your mind, do not run an RFP. Go and negotiate with the vendor you have already chosen.

Step 2: Write requirements a vendor can actually price

Requirements are the load-bearing part of the document, and the failure mode is writing them as a feature list copied from the product you have already seen. A feature list guarantees you buy something like the thing you already imagined, and it lets a vendor answer “yes” to every line while delivering something that does not fit.

Write outcomes instead, one per line, in the language of your own work. Not “must have a Kanban board” but “a supervisor must be able to see, in one view, every job scheduled for tomorrow and who is assigned to it”. The first sentence names a mechanism; the second names a result, and it lets a vendor propose a better mechanism you had not thought of. It also makes a hollow “yes” much harder to write.

Mark each line must-have or nice-to-have, and be strict about it. A must-have is a requirement whose absence disqualifies the vendor, full stop. If you would still consider a product that failed the line, it is a nice-to-have. Teams routinely mark two thirds of a list as must-have, which disqualifies everyone and forces a quiet retreat to preference. Keep the must-have list short enough that you would genuinely walk away.

Give each requirement the context that makes it priceable: how many users, how often, at what volume, on which devices, connected to which other systems. A vendor cannot quote accurately against “reporting” but can against “twelve people need to pull a monthly job-profitability report themselves, without asking an administrator”. Number the requirements, because the numbers become the columns of your scorecard and the references in every later conversation.

Step 3: Set scored evaluation criteria and weight them

Write the scorecard before any response arrives. This is the step teams skip and the one that determines whether the process is real, because criteria invented after reading the bids will always, without anyone intending it, describe the bid that was most enjoyable to read.

Start with five or six criteria, no more. A workable default set: functional fit against your must-have requirements, total cost of ownership across three years, security and data handling, implementation and support, and vendor stability including references. Assign each a weight, and make the weights sum to one hundred, because the act of dividing a fixed hundred forces the trade-off conversation that vague criteria let you postpone.

Then define the scale. A one-to-five score per criterion is enough, but write a sentence describing what a one, a three and a five look like, so two people scoring the same paragraph land in the same neighbourhood. Undefined scales produce scores that measure the scorer’s optimism rather than the response.

Publish the criteria and the weights inside the RFP. Vendors write better, more relevant proposals when they know what is being measured, and hiding the weights buys you nothing except responses aimed at the wrong target. The scorecard is not a secret; it is the specification for a good answer.

Step 4: Ask the pricing and total-cost questions

Free-text pricing is how comparability dies. One vendor quotes per user per month, another quotes an annual platform fee with a user band, a third bundles implementation and a fourth itemises it, and by the time you have normalised four structures by hand the numbers have stopped meaning anything. Give every vendor the same table and require them to fill it in.

The table needs a line for each of: recurring licence or subscription cost, stated per user and in total at your actual user count; the minimum contract term and the notice period; one-time implementation, configuration and data migration charges; training, both included and chargeable; support tiers and what the included tier actually covers; integration or interface charges for each system you named; storage, transaction or usage charges that scale with activity; and the price of every module you would need at your stated volumes rather than the base package alone.

Then ask three questions that reveal the shape of the deal beyond year one. What is the renewal uplift, expressed as a maximum percentage, and is it in the contract? What happens to the price when we add or remove users mid-term? And what is the total cost in year three at our expected growth? Those are the questions that separate a cheap first year from a cheap contract, and our true cost breakdown covers why the sticker is only the floor.

Finally, ask for the price of leaving: any data extraction fee, any charge to run in parallel during a migration, any early termination cost. A vendor confident in its product answers those plainly. A vendor that will not answer has told you something worth knowing before you sign rather than after.

Step 5: Ask the security, data ownership and migration questions

This section carries more weight than its length suggests, because these are the answers that are expensive to discover late. Keep the questions plain and answerable; a small business asking for a full enterprise security questionnaire mostly gets a boilerplate document back and learns nothing.

Ask where the data is stored, geographically, and who else can access it. Ask what authentication options exist, including whether two-factor is available on the plan you would actually buy rather than only on the top tier. Ask about role-based permissions, because “everyone sees everything” is a real answer from real products. Ask what the backup and recovery arrangement is in practice, and what happens during an outage. Ask what security documentation the vendor can share, and read what comes back rather than filing it.

On ownership, ask three questions in exactly these words: who owns the data we put in, in what formats can we export all of it, and can we do that ourselves without asking you. Ownership language in a contract can be generous while the export capability is a support ticket and a fee, and the gap between those two is where lock-in lives.

On migration, ask what the vendor does, what you do, and what the realistic elapsed time is for a data set your size. Ask what they need from you and in what format, and ask what typically goes wrong. A vendor who has done this often will describe the failure modes readily. Our migration walkthrough covers the work that lands on your side regardless of what the proposal promises.

Step 6: Set the timeline and run a fair question window

A timeline is what turns a document into a process, and vendors treat an RFP with dates in it more seriously than one without. Publish five: the issue date, the deadline for vendor questions, the date you will circulate answers, the response deadline, and the date you expect to notify. Add the intended contract start and go-live dates so a vendor can tell you honestly whether the implementation fits.

Allow more time than feels necessary for the response window. A serious proposal, with a filled pricing table and considered answers, takes real work, and a short window selects for vendors with a template rather than for vendors with a good fit. Two to three weeks is a common working range for a small purchase; less than one produces recycled boilerplate.

Run the question window fairly, which mostly means one rule: every question goes to the single named contact, and every answer, with the question anonymised, goes to every vendor at the same time. It costs you an hour and it removes the most common source of a compromised process, which is one vendor holding information the others do not have. It also improves the responses, because good questions from one vendor sharpen everybody’s understanding of what you meant.

Step 7: Score the responses and decide without re-litigating

Score the written responses before you sit through any demo. A demo is a performance, and a good one lifts the memory of a weak written answer in a way that is almost impossible to correct for afterwards. Read, score, record the reasons, and only then schedule the demonstrations, using them to test the answers you scored rather than to form fresh impressions.

Have each evaluator score independently first. Collective scoring in a room converges on whoever spoke first, which is not the same as agreement. When the independent scores are in, meet and compare, and treat any criterion where two people scored far apart as a sign that the criterion was ambiguous rather than that one of them read badly. Fix the definition, rescore that criterion, and move on.

Check references before you finish scoring, not after you have chosen. Ask each reference the two questions that produce real answers: what took longer than expected, and what would you check before signing if you were doing it again. Vendor-supplied references are of course friendly, and those two questions still get useful material out of them.

Then decide, and write down why in a paragraph. The paragraph matters more than the total, because it is the thing you will reread when the implementation gets hard and someone asks whether you picked wrong. Notify the winner, notify the others properly, and move straight into the negotiation, since the strongest moment to ask for terms is when a vendor knows it has won but nothing is signed.

A fill-in software RFP outline you can copy

Copy this into a blank document and fill the brackets. Nine sections, in this order, are enough for almost any small business software purchase.

1. Background. Two paragraphs. Who you are, what you do, how many people, and why you are buying now. Name the problem the current arrangement causes.

2. Scope. What the software must cover, and one explicit line naming what is out of scope for this purchase.

3. Functional requirements. A numbered list. Each line: an outcome in your own words, marked must-have or nice-to-have, with volumes and user counts attached.

4. Technical, security and data requirements. Hosting and data location, authentication, permissions, the systems it must integrate with, export and ownership, backup and recovery.

5. Implementation, migration and support. What you expect the vendor to do, what you will do, the data you will bring, the training you need, and the support level you expect.

6. Pricing. The fixed table from Step 4, with a line for every cost category, to be completed by every vendor in the same format.

7. Evaluation criteria. Your criteria, their weights summing to one hundred, and one sentence per criterion describing what a strong answer looks like.

8. Timeline and process. Issue date, question deadline, answers circulated, response deadline, notification date, intended go-live. One named contact with an email address.

9. Submission instructions. Format, length limit, where to send it, and what a complete submission contains.

Two rules govern the whole outline. Every section must change how you score, or it should not exist. And a length limit on the response is a kindness to you as much as to the vendors, because you are the one who has to read all of them.

How long a software RFP should be

Length is the most common way a small business RFP goes wrong, and it goes wrong upward. The instinct is that thoroughness signals seriousness, so sections get added, and each addition is individually defensible while the total quietly becomes a document that takes a vendor days to answer.

That has two costs, and both land on you. The first is response quality: a long document gets a templated answer, because assembling a bespoke response to eighty questions is not economic for a vendor pitching a modest contract. The second is self-selection. The vendors best placed to decline a long RFP are the ones with enough demand not to need it, which are frequently the ones you most wanted to hear from.

The filter that keeps it short is a single question asked of every line: if a vendor answered this differently, would my score change? If the answer is no, the line is decoration and it goes. Applied honestly, that question removes a surprising proportion of a first draft, usually the company-history and methodology narrative sections that nobody scores.

Put the depth where it earns its place: the numbered requirements, the pricing table, and the security and data questions. Those three sections do the actual comparing. Everything else is context, and context can be brief. For an off-the-shelf small business purchase, a handful of pages plus the requirement list and pricing table is a normal, complete document.

Writing requirements as outcomes, not features

It is worth spending longer on this, because it is the difference between an RFP that finds the right product and one that confirms the product you had already half chosen.

A feature requirement describes a mechanism: a Gantt view, a Kanban board, a custom field, a mobile app. An outcome requirement describes what someone needs to be able to do: see whether the job that has to ship on Friday is at risk, reassign a technician from a phone while standing in a car park, or record a job-specific detail that the standard fields do not hold. The second phrasing does two useful things. It lets a vendor answer with a different mechanism that solves it better, and it makes an evasive answer visible, because “yes, we have custom fields” does not obviously satisfy “a dispatcher must be able to record the gate code for a site and see it before arriving”.

The reliable way to generate outcome requirements is to sit with the people who do the work and walk a real case end to end. Take one job, one order, one ticket, and follow it from arrival to invoice, writing down every point where information is retyped, chased, lost, or held in someone’s head. Each of those points is a requirement, phrased as the outcome that would fix it, and it comes with its own volume figure attached because you know how often that case occurs.

Watch for the requirement that is really a preference for the current tool. “Must work the way our spreadsheet does” is common, and it usually encodes a workaround rather than a need. Ask what the spreadsheet’s arrangement is achieving, and requirement-ise that instead.

The pricing table every software RFP should include

Give every vendor an identical table with the rows fixed, and state that a response with the table modified or omitted is incomplete. That single instruction does more for comparability than any other line in the document.

The rows, at minimum: subscription cost per user per month and per year; the number of users the quote assumes; minimum contract term; notice period for cancellation; renewal uplift cap; one-time implementation and configuration; data migration; training, included and additional; support tier included and cost of upgrading it; integration charges by named system; usage, storage or transaction charges; each optional module you would need, priced separately; and a three-year total on your stated user count.

Then add two computed rows and ask the vendor to complete them: the total cost in year one, and the total across three years. Vendors compute those differently when left to themselves, and requiring both on your definitions removes an entire category of argument later. A three-year view is the right horizon for most software, because it captures the renewal and the growth that a first-year quote hides.

Read the completed tables for shape rather than for the smallest number. A proposal that is cheap in year one and steep at renewal, or cheap on licences and expensive on implementation, is not necessarily worse, but it is a different deal and it should score differently. When you have the tables side by side, our software spend audit approach applies directly: compare the annual total at your real volumes, not the headline per-user rate.

Worked example: a 30-person firm runs an RFP for field service software

A thirty-person maintenance contractor decides to replace a spreadsheet and a shared inbox with a scheduling and job management system. Every figure here is illustrative and used to show the arithmetic.

The decision sentence: one system for scheduling, job records and invoicing hand-off, live before the busy season, used by thirty people of whom eighteen are technicians on phones. Budget range: an illustrative $18,000 a year, which on thirty users is $600 per user per year, or roughly $50 per user per month. Timeline: seven weeks from issue to notification, matching the illustrative schedule in the chart above, with go-live six weeks after that.

They invite five vendors, chosen from a shortlist built on three must-have requirements. They estimate forty hours of internal time across the evaluation group, at a blended internal cost of $60 an hour, which is $2,400. Against a three-year contract value of $54,000, that process cost is about 4.4 percent of the deal. Read the other way, a discount of roughly 5 percent on the contract pays for the entire process, which is the arithmetic that makes an RFP proportionate here. Forty hours across five vendors is eight hours per vendor, which is enough to read a proposal properly and sit through a demo.

They weight the scorecard 40 functional fit, 25 cost, 20 security and data, 15 support, then score the written responses before any demo. Two vendors score within three points of each other, so the reference calls decide it. The pricing tables show one of them cheaper in year one and higher across three, which changes the cost score but not the winner. Run your own version in the process helper, and if the process cost comes out large against your contract, that is the signal to run a trial instead. Our field service software cost breakdown covers what this category typically prices at.

Who should be in the room, and who signs off

Three roles, and confusing them is a common source of a stalled process. The decision maker signs and owns the outcome, and there is exactly one. The evaluation group scores, and it should be three to five people who represent genuinely different exposure to the system: someone who will use it daily, someone who will administer it, and someone who owns the budget. The point of contact handles all vendor communication, and can be one of the above.

The daily user is the role most often left out and the most valuable one present. A system that scores well on management reporting and badly on the twelve times a day a technician has to open it will be abandoned in practice, and no amount of executive enthusiasm survives that. Give that person a real weight in the scoring, not an advisory seat.

Agree in advance what happens in a tie or a genuine disagreement, because deciding that in the moment is how a process turns into a negotiation between colleagues. A workable default: the decision maker decides, having heard the scores, and records the reason in writing when the choice differs from the highest total. That is legitimate, as long as it is visible.

Keep the group small. Every additional evaluator adds scheduling drag and dilutes accountability, and a group of nine produces an average that represents nobody’s actual judgement. Three to five people who will each read every response properly beats a wide group who each skim.

What to send the vendors you reject

This is a short section about a step almost everyone skips, and it is worth thirty minutes. Send every unsuccessful vendor a note that says the decision is made, thanks them for the work, and gives one honest sentence about where their proposal fell short against your published criteria.

The reason is practical rather than sentimental. You will run another process, in this category or another, and the vendor community for small business software is smaller than it looks. Vendors talk, and a buyer with a reputation for running a fair, communicative process gets more effort from better vendors next time. A buyer whose RFPs disappear into silence gets boilerplate.

It also protects you from a specific failure. Sometimes the winner falls over during contracting, and the second-placed vendor is the one you go back to. That conversation is very different with a vendor who was told promptly and courteously than with one who was left guessing for a month and has drawn its own conclusions.

Keep it brief and do not open a negotiation. One paragraph, no detailed scores, no invitation to rebut. The honest sentence about where they fell short is a professional courtesy, not a debate, and framing it against your published criteria keeps it factual.

How the RFP feeds the trial and the negotiation

An RFP does not end the buying process; it hands off to two things, and planning that hand-off is what separates a decision from a document.

The first is the trial or proof of concept. The winning proposal contains claims, and a short structured trial tests the two or three that would hurt most if untrue. Load your own data, run the workflow the daily user described, and check the specific outcome requirements you marked must-have. This is deliberately narrow: a trial after an RFP is a verification exercise, not a re-evaluation, and letting it become the latter restarts a process you have already run.

The second is the negotiation, and the RFP has quietly built your position for it. You have comparable pricing tables from several vendors, a documented set of requirements, and a preferred vendor who knows it is preferred but has not signed. Ask for what the proposals showed to be movable: term length in exchange for rate, a renewal uplift cap in writing, implementation or training thrown in, or a longer notice period.

Then plan the implementation before you sign, because the RFP answers tell you what it will take. Data migration, training, and the parallel-running period all have dates and owners, and the vendor’s proposal already stated what it needs from you. Our migration walkthrough covers the sequence, and the responses you collected make it a schedule rather than a guess.

Common mistakes that turn an RFP into procurement theatre

Procurement theatre is a process that produces documentation without producing a decision, and every version of it has the same tell: the outcome was never actually in question.

Running an RFP with the winner already chosen. The clearest sign is that no vendor’s answer could have changed the result. It wastes several vendors’ unpaid work and it teaches your own team that the process is decorative, which is what makes the next one worse.

Writing requirements from one vendor’s feature list. A requirement set copied from the product you liked disqualifies everyone else on technicalities and produces a scored justification for a decision already made.

Inviting too many vendors. Twelve responses look thorough and get read badly. Filter first, invite three to five, and read every one of them properly.

Marking everything must-have. A list where two thirds of the lines are mandatory disqualifies the whole field, forces a retreat to preference, and destroys the scorecard you built.

Scoring after the demo. Presentation quality is not product quality, and a memorable demo reliably outscores a better written answer if the scoring happens afterwards.

Changing the weights once the bids are in. If a criterion turns out to matter more than you thought, that is a finding for the next process. Adjusting weights to fit the responses converts a scorecard into a rationalisation.

Running an enterprise-scale process on a small contract. A forty-page document for a four-figure deal costs more than it can possibly save, and the vendors worth hearing from will decline it.

Troubleshooting: when the RFP stalls

Only one vendor responds. Usually the document was too long, the timeline too short, or the requirements too narrow to fit anything on the market. Ask two of the non-responders directly why they passed; they will generally tell you, and the answer is fixable.

The responses are not comparable. This is a pricing-table failure. Send the table back with a short note asking for it completed as specified, and give a firm short deadline. Most vendors comply, and a refusal is information.

Every vendor scores about the same. Your criteria are not discriminating. Return to the must-have requirements and check whether they describe outcomes specific to your work or generic category features that any product satisfies. Generic requirements produce identical scores.

The evaluation group cannot agree. Look at which criterion carries the disagreement. If it is one, the definition is ambiguous and needs rewriting and rescoring. If it is spread across all of them, the group is disagreeing about the decision rather than the responses, and that conversation belongs with the decision maker, not the scorecard.

The timeline has slipped past the go-live date. Decide explicitly whether to move the go-live or to shorten the process, and say which. An RFP that drifts without a decision loses the vendors’ attention, and their pricing assumptions expire with their proposals.

A vendor asks for an extension. Grant it, and grant the same extension to everyone. Refusing usually costs you a considered response; granting it privately costs you the fairness the process was for.

Your software RFP checklist

Work top to bottom. Everything above the pricing table is preparation; everything below it is process.

• Wrote the decision as one sentence, with the budget range, the go-live date, and the explicit out-of-scope line.
• Named one decision maker, an evaluation group of three to five including a daily user, and one point of contact for all vendor communication.
• Confirmed the process is proportionate: estimated hours times blended internal cost, compared against the three-year contract value.
• Walked one real case end to end with the people who do the work, and turned every friction point into an outcome requirement.
• Numbered every requirement, marked must-have or nice-to-have strictly, and attached user counts and volumes to each.
• Built the scorecard before issuing: five or six criteria, weights summing to one hundred, and a sentence defining a low, middle and high score.
• Published the criteria and weights inside the document, so vendors aim at the right target.
• Fixed the pricing table with a row for every cost category, plus year-one and three-year totals on your own definitions.
• Asked the data questions plainly: where it lives, who owns it, how you export all of it yourself, and what leaving costs.
• Published five dates plus the intended go-live, with a response window of at least two weeks.
• Ran the question window fairly: one contact, every anonymised answer to every vendor at the same time.
• Scored written responses independently, before any demo, recording the reason beside each score.
• Checked references with the two questions that produce real answers, before finalising the decision.
• Wrote a paragraph explaining the choice, notified everyone including the unsuccessful vendors, and moved straight into the negotiation.

The bottom line

A software RFP is worth writing when a decision needs to be shared, defended or compared, and it is worth skipping when it is not. That judgement is the first thing this walkthrough asks for, and it is the one most likely to save you real money, because the process has a cost that lands on your team whether or not it improves the outcome. Where it does earn its place, the value is narrow and genuine: several vendors answering the same questions in the same order, priced in the same table, scored against criteria you fixed before you read a word. Everything else the format is famous for, the length, the formality, the narrative sections, is overhead that neither improves your decision nor survives contact with a small business calendar. Write the decision sentence, write outcomes rather than features, build the scorecard first, keep the document short enough that good vendors will answer it, and run the question window in a way you would be happy to have described back to you. Then treat the award as the beginning of the commercial conversation, not the end of it. Put your own headcount, budget, vendor count and hours into the process helper before you start drafting, and let the arithmetic tell you whether an RFP is the right instrument for the deal in front of you.

Every figure on this page, including the budgets, hourly costs, weightings and elapsed days, is illustrative and exists to show how the arithmetic works rather than to report a market rate or a survey result. VetLoft is not a law firm and nothing here is legal, procurement or contract advice: an RFP and the agreement that follows it can create obligations that vary by jurisdiction and by contract, so have anything you intend to sign reviewed by a qualified professional who has read the actual document. Vendor pricing, contract terms and security practices are set by each supplier and change without notice, so confirm them directly rather than relying on any range described here.