We have written about how to write an RFP for software and walked through a sample response. This is the template. It is short on purpose. The RFPs that produce good proposals describe the problem well and leave the solution to the people responding; the ones that run forty pages mostly produce forty-page responses that nobody reads.
Download the template (Word, .docx), or read the outline below and write your own. Either way, aim for six to ten pages.
The eleven sections
1. About your company. Two paragraphs. What you do, how big you are, where you operate, and how the people who will use this software fit in. Firms are sizing the fit, not just the work.
2. The problem. The most important section and the one most RFPs skip. What is happening today that should not be, in operational terms. The spreadsheet that runs the schedule. The re-keying between systems. The report that takes a week. What it costs you, if you know.
3. What success looks like. How you will know it worked, in numbers if you have them. Hours saved, days off month-end close, errors eliminated, customers served. This is what a good firm will build toward and measure against.
4. Who will use it. Each kind of user, roughly how many, where they are, and what device they will use. A dispatcher at a desk and a crew lead in a truck need different things.
5. What it has to do. The must-haves, as short statements of what a user needs to accomplish. Not screens, not features from a competitor’s brochure. “A technician can complete a job form offline and it syncs when they have signal.” Ten to twenty of these is plenty. Mark anything that is a nice-to-have as one.
6. What it has to connect to. Every system the software will exchange data with, what it is, and who owns the relationship. Integrations are where the estimate lives.
7. Constraints. Security or compliance requirements, data that cannot leave your environment, hosting preferences, technology your team can support, and anything else a firm needs to know before proposing.
8. Timeline and budget. A target date and what drives it. And a budget range. Owners hesitate here, but a range is what lets a firm propose the right thing rather than guess whether you mean $60,000 or $600,000. Every serious firm will ask anyway.
9. What you already have. Existing systems, code from a previous attempt, documentation, data. A firm proposing to take over or modernize needs to know.
10. How to respond. What you want in the proposal and in what order: understanding of the problem, approach, team, timeline, price, references. Ask for a fixed structure so the responses compare. Ask for the names and roles of the people who would do the work. Ask for their questions.
11. How you will decide. The criteria and their weight, the timeline for the decision, and who is deciding. Firms respond better when they know what matters.
What to leave out
- A detailed specification. If you already know exactly what to build, you do not need proposals, you need a builder. If you do not, a spec written before discovery will be wrong and every firm will price it as if it were right.
- A required technology stack, unless your team genuinely has to support it. Let the firm propose and explain.
- Legal terms. Send the master agreement to the finalist.
- Twenty questions about the vendor’s history. Ask five that matter. The questions to ask a software partner are a good list.
What to expect back
A firm worth hiring will read the problem section carefully, ask questions before proposing, and very likely propose a paid planning step before committing to a full price. That is not evasion. It is how a serious estimate gets made. If every response quotes a firm fixed price for the whole thing off the RFP alone, be suspicious of all of them.
We will respond to a well-written RFP. We will also tell you, on a call, whether we think you need one, because for many projects a Discovery Call and a Deep Dive get you to a better decision faster than a formal process. Either way, the template will make the conversation sharper.