Guides
A request for proposal that is missing an integration inventory or a set of disclosed evaluation criteria produces bids you cannot compare. Below is the full outline we recommend, with an explanation of each section and the mistake we see most often within it. Everything on this page is free to read and use.
It pairs well with our discovery and scoping sprint and our build vs buy framework, which can help settle the problem statement before you write the RFP at all.
The outline
Who you are, what the business does, and the systems and processes currently in place. Describe the current state honestly, including its known weaknesses — suppliers price more accurately, and propose better solutions, when they understand what they are replacing.
Common mistake: describing the current state in terms of what you wish it did rather than what it actually does, which hides the real migration and integration risk from every respondent.
The specific business problem the new software must solve, stated in outcomes rather than features — for example, 'reduce policy renewal processing time from four days to same-day', not 'we need a workflow engine'.
Common mistake: writing a feature list instead of a problem statement, which invites suppliers to bid on features rather than on solving your actual problem.
An explicit list of what the engagement covers and, just as importantly, what it does not — which systems, teams or processes are out of scope for this round.
Common mistake: leaving scope boundaries implicit, which leads to bids that are impossible to compare because each supplier has assumed a different scope.
Every system the new software must exchange data with: the system name, the interface mechanism available (API, file transfer, database access), approximate data volumes, and which system is the source of truth for each shared data field.
Common mistake: omitting systems that are 'probably fine' — undocumented integrations are the single biggest source of scope creep once a project starts.
Performance expectations, availability targets, expected concurrent users, data retention periods and any accessibility standard you require.
Common mistake: leaving non-functional requirements out entirely, which lets every supplier assume the easiest possible interpretation and then charge extra once the real requirement surfaces.
Data classification, any sector-specific regulatory regime that applies, required certifications from the supplier, data residency requirements and your expectations for security testing before go-live.
Common mistake: asking for a certification (for example, a particular security standard) without stating why, which makes it hard for suppliers to propose an equivalent control if they do not hold that specific certification.
What data needs to move from existing systems, its approximate volume and quality, and who is responsible for cleansing it before migration versus during the project.
Common mistake: assuming data migration is a minor line item — for most legacy replacements it is one of the largest cost and schedule risks, and treating it as an afterthought in the RFP produces bids that understate it.
Whether you want fixed price, time and materials, or a phased model with a fixed discovery phase; your budget band if you are willing to disclose one; and your expected payment schedule.
Common mistake: refusing to disclose any budget indication at all, which produces bids ranging so widely they cannot be meaningfully compared.
The criteria you will score bids against — technical approach, relevant experience, commercial terms, cultural fit — and the weight given to each, published to bidders before they respond.
Common mistake: scoring on criteria that were never disclosed to bidders, which is both unfair and produces a result that is hard to defend internally.
The date the RFP is issued, the deadline for questions, the submission deadline, the expected evaluation period and your target start date.
Common mistake: an unrealistically short response window that filters out exactly the suppliers most likely to do the work well, because thorough suppliers decline to bid on a rushed brief.
A structured set of questions you want every supplier to answer identically — team composition, relevant delivery experience, approach to the specific problem statement, references, and how they would run discovery.
Common mistake: allowing free-form responses with no structure, which makes bids impossible to compare side by side.
Editable document
The outline above is the whole document — reading it and copying it into your own format costs nothing. What is gated is a ready-to-fill version of the same structure as an editable document, sent after a short enquiry so we can tailor a note to your sector if it would help. There is no separate paywall or account: it is the same enquiry form used across the site, with your message tagged so we know it is a template request.
Questions
No. The full outline and the explanation of every section is on this page, free to read and copy by hand. The gate is only for the editable document — a ready-to-fill template file — which we send after a short enquiry.
Sending the editable file lets us see what kind of procurement you are running and reply with something more useful than a generic document, and it gives us a reason to have a short conversation before you send the RFP to suppliers, which usually improves the questions it asks.
No competent supplier minds a structured RFP — it is easier to answer than a scattered brief, and a well-run procurement process is itself a signal that the resulting project will be well-run.
You are welcome to. We will answer it like any other supplier would, and tell you plainly if we are not the right fit for what you have described.