TL;DR
- An ERP RFP (Request for Proposal) is a formal document sent to shortlisted vendors asking them to respond to your requirements, provide pricing, and explain their implementation approach.
- A well-written RFP forces vendors to respond to the same criteria, makes evaluation objective, and protects you from discovering gaps after contract signature.
- The seven sections every ERP RFP needs: company overview, project scope, functional requirements, technical requirements, commercial requirements, vendor information, and evaluation criteria.
- The biggest RFP mistake is writing requirements that are too vague. “Good reporting” is not a requirement. “The system must generate a month-end P&L, balance sheet, and cash flow statement by cost centre, exportable to Excel” is.
- Send your RFP only to vendors who have already passed an initial shortlisting screen. A well-written RFP takes time to respond to properly, and you should only ask vendors to invest that time if they are genuinely in contention.
- The free ERP RFP template linked at the end of this guide is pre-structured for UK businesses, with MTD compliance, PAYE, and GDPR requirements built in.
Most ERP procurement processes start with a demo and end with a spreadsheet of notes that nobody agrees on.
The problem is not the demo. Demos are useful for getting a feel for a system. The problem is that demos are vendor-controlled. You see what they want you to see, in the sequence they want you to see it, using data they have prepared. When you sit down afterwards and try to compare three vendors based on your notes, you are comparing three different presentations, not three different products evaluated against the same criteria.
That is what an RFP is for. Not bureaucracy. Not a procurement hoop to jump through. A properly written Request for Proposal creates a level playing field where every vendor responds to the same questions, in the same format, against the same requirements. It makes comparison objective, surfaces capability gaps before contract signature, and gives you a documented basis for your final decision.
This guide walks you through how to write one, what to include, and the mistakes that make RFPs less useful than they should be.
What Is an ERP RFP and When Do You Need One?
An ERP RFP (Request for Proposal) is a formal document that sets out your business requirements and invites shortlisted ERP vendors to submit a structured proposal explaining how their system meets those requirements, what it will cost, and how they will deliver the implementation.
It is different from an RFI (Request for Information), which is an earlier-stage document used to gather general information about vendors and products before you have a shortlist. An RFP comes after you have done your initial research, identified a shortlist of three to five plausible vendors, and are ready for a detailed evaluation.
You need an ERP RFP when:
- Your project is significant enough in scope or cost that a structured comparison process is warranted. For most UK businesses spending more than £30,000 on an ERP project, that threshold is met.
- You have multiple stakeholders (IT, finance, procurement, operations) who need to agree on the selection, and you need a documented process to align those perspectives.
- Your organisation has procurement governance requirements that demand a formal process.
- You want to reduce the risk of discovering critical gaps after you have signed a contract.
Smaller businesses evaluating one or two vendors on a straightforward implementation may not need a full formal RFP. The structured evaluation questions in our vendor evaluation guide may be sufficient. But for anything with material complexity, an RFP pays for the time it costs to write it many times over.
The Seven Sections Every ERP RFP Needs
There is no universal RFP format. But well-structured ERP RFPs consistently cover the same seven areas. Here is what goes in each one.
Section 1: Company Overview and Project Background
Before vendors can respond intelligently to your requirements, they need to understand your business. This section is not about writing a marketing pitch for your company. It is about giving vendors the context they need to tailor their proposal to your situation.
Include: your company’s size (headcount, revenue range), your primary industry and any sub-sectors, your locations and any multi-site requirements, your current technology landscape (what systems you are replacing or integrating with), and the high-level driver for this project (growth, system end-of-life, merger, compliance, or operational inefficiency).
Also state your project timeline expectations. If you have a hard go-live target, say so. If the timeline is flexible, say that too. Vendors price and resource projects differently depending on timeline pressure.
Section 2: Project Scope
This section defines exactly what you are asking vendors to respond to. Be explicit about what is in scope for this RFP and what is not.
List the modules you need: finance and accounting, procurement, inventory management, warehouse management, manufacturing, HR and payroll, sales force automation, project management, or whichever combination applies to your business. If some modules are phase-one requirements and others will follow later, say so clearly.
State the number of users who will need access, broken down by module if relevant. A business with 80 users who all need finance read access but only 20 who actively process transactions needs to communicate that distinction, because it affects how vendors price the system.
State any known integrations: bank feeds, e-commerce platforms, CRM, payroll bureaus, sector-specific tools. These will need to be addressed in vendor proposals.
Section 3: Functional Requirements
This is the core of your RFP and the section that takes the most time to write well.
Functional requirements describe what the system needs to do. They should be specific, testable, and written from the perspective of what your business needs, not what the system does.
A requirement like “the system must have good reporting” is not a requirement. It is a preference, and it tells the vendor almost nothing. A requirement like “the system must generate a month-end P&L, balance sheet, and cash flow statement by cost centre and consolidated across all entities, with drill-down to transaction level, exportable to Excel” is a requirement. A vendor can either demonstrate it or confirm they cannot.
Structure your functional requirements by module. For each requirement, indicate whether it is essential (the system must do this before go-live), important (needed within 12 months), or desirable (useful but not business-critical). This priority weighting helps vendors understand where to focus their responses and helps you score proposals consistently.
UK-specific functional requirements to include for any UK business:
For finance and accounting: Making Tax Digital compatible VAT return submission; integration with HMRC’s digital tax portal; open banking or bank feed connectivity for UK high street banks; multi-currency support if applicable; UK GAAP or FRS 102 compliant financial reporting.
For HR and payroll: PAYE and NIC calculation with HMRC RTI submission; workplace pension auto-enrolment assessment and contribution calculation; statutory pay calculations covering SSP, SMP, SPP, and ShPP; P60 and P11D generation; CIS (Construction Industry Scheme) deduction management if applicable.
For data and compliance: UK GDPR compliant data handling with a written data processing agreement available; data hosted within the UK or EEA; the ability to respond to data subject access requests within the system.
Section 4: Technical Requirements
Technical requirements cover the architecture and infrastructure of the system, rather than what it does functionally.
Include: deployment model preference (cloud SaaS or on-premise), required uptime SLA and disaster recovery commitments, browser and device compatibility (particularly important if you have field teams using mobile devices), API availability for future integrations, single sign-on compatibility with your existing directory (Microsoft Entra ID, Google Workspace, or equivalent), role-based access control capabilities, and audit trail functionality.
Also ask vendors to confirm where data is hosted. For UK businesses, this matters for UK GDPR compliance. A vendor whose data centres are outside the UK and EEA needs to explain the legal basis for that data transfer.
Section 5: Commercial Requirements
This section sets out the information you need on pricing and contract terms.
Ask vendors to provide: software subscription or licence costs for years one, two, and three (so you can see the escalation); implementation fees broken down by phase or workstream; data migration costs; training costs; integration development costs for any integrations not covered by pre-built connectors; and ongoing annual support and maintenance costs.
State that you want total cost of ownership over three years, not just the year-one headline. Make clear that proposals that do not include all cost components will be treated as incomplete.
Also ask vendors to confirm: minimum contract term, notice period required for termination, price escalation terms (capped or uncapped), and data export terms at contract end.
Section 6: Vendor Information
This section asks vendors to tell you about themselves, their track record, and their implementation approach.
Ask for: company background and financial stability indicators (relevant for a long-term software commitment), the number of UK customers on the same platform, three reference customers from the last 12 months in a similar sector and at a similar scale, the proposed implementation methodology and project timeline, details of the specific people who would work on your project, and their post-go-live support model including response times and escalation procedures.
Also ask: what percentage of implementations are delivered by their own team versus implementation partners? If partners are involved, what is the vendor’s quality assurance process for partner-delivered projects?
Section 7: Evaluation Criteria
Tell vendors upfront how you will evaluate their proposals. This is not a weakness in your negotiating position. It is transparency that helps vendors give you the information that actually matters to your decision.
State the weighting you will apply to: functional fit (how well the system meets your documented requirements), implementation quality and experience, total cost of ownership, UK compliance capabilities, support model, and vendor stability and roadmap.
A typical weighting for a UK mid-market ERP evaluation might look like: functional fit 30%, implementation quality 25%, total cost 20%, UK compliance 10%, support 10%, vendor stability and roadmap 5%.
Your weighting will differ depending on your priorities. A business with a tight budget will weight cost more heavily. A business in a heavily regulated sector will weight compliance higher. State your actual criteria and let vendors respond to them.
How to Run the RFP Process
Writing the document is only half of it. Here is how to run the process once the RFP is ready.
Shortlist before you send. An RFP takes a vendor 20 to 40 hours to respond to properly. Only send it to vendors who have already passed an initial screen: your desk research confirms they serve businesses of your size and sector, and a brief introductory call has given you confidence they are worth the detailed evaluation. Sending an RFP to six vendors to see who responds is not best practice. It wastes everyone’s time and produces six proposals that are harder to compare than three focused ones.
Set a clear deadline. Give vendors three to four weeks to respond. Less than that and you will get rushed proposals that miss detail. More than that and the process drags. Confirm the deadline in writing and hold to it.
Hold a briefing session. Once the RFP is sent, offer a 60-minute Q&A session where all shortlisted vendors can ask clarifying questions at the same time. This ensures every vendor is working from the same understanding of your requirements and it creates efficiency by handling questions in a group rather than individually.
Send all questions and answers to all vendors. If one vendor asks a clarifying question, the answer is relevant to all of them. Send every Q&A response to all vendors so proposals are based on consistent information.
Score proposals against your criteria before the presentation. When proposals arrive, score them against your evaluation criteria before you hold any further vendor presentations. This protects against presentation style influencing your assessment of the proposal itself.
Use follow-up presentations to probe weak areas. Once you have scored proposals, use follow-up presentations or demonstrations to dig into areas where a vendor’s proposal was unclear or where you need to see the capability demonstrated rather than described. Do not use these presentations to let vendors re-present their strengths. Use them to address your specific concerns.
The Most Common RFP Mistakes
Requirements that are too vague. The more specific your requirements, the more useful vendor responses will be. Vague requirements produce vague promises.
Sending it to too many vendors. More proposals does not mean a better decision. It means more noise to sort through. Three to four is the right number.
No mandatory format. If you do not specify how you want vendors to respond, you will receive proposals in different formats that are almost impossible to compare. Include a response template or at least a required section structure.
Treating the RFP as the entire evaluation. A written proposal is not the same as a demonstrated capability. Follow up every proposal with a scenario-based demonstration of the requirements that matter most. Reference conversations should still happen regardless of how good the written proposal looks.
Ignoring the commercial section. Procurement teams sometimes focus heavily on functional requirements and gloss over contract terms. The commercial section is where you find out about price escalation clauses, data portability restrictions, and exit terms. Read it carefully.
Not involving finance in the review. The IT head evaluates the system. The CFO evaluates the total cost and contract terms. Both need to be involved before a final recommendation goes to the board.
Download the Free ERP RFP Template
The RFP structure above gives you the framework. To save you the hours it would take to build it from scratch, we have put together a ready-to-use ERP RFP template specifically for UK businesses.
The template includes:
- Pre-written company overview and scope sections you customise with your details
- A functional requirements register with 120 pre-built requirements across finance, procurement, inventory, sales, HR and payroll, and manufacturing, each with a priority field (essential, important, desirable) and a vendor response column
- UK-specific compliance requirements for MTD, PAYE, RTI, auto-enrolment, CIS, and UK GDPR built in as standard
- A vendor information section with questions pre-written
- A commercial requirements section with pricing table structure
- An evaluation scoring matrix ready to populate
If you would prefer to have a conversation before committing to a full RFP process, the Blue Lotus 360 team can walk you through a requirements scoping session that covers the same ground in a structured consultation. It is free, it takes about 90 minutes, and it gives you a clearer picture of what you actually need before you put it in writing.
Book your free consultation at bluelotus360.com/uk/
Frequently Asked Questions
What is the difference between an ERP RFP and an ERP RFI?
An RFI (Request for Information) is an early-stage document used to gather general information about vendors and their products when you are still exploring the market and have not yet identified a shortlist. An RFP (Request for Proposal) comes later, once you have a shortlist of credible vendors and are asking for a detailed proposal against your specific documented requirements. Most ERP procurement processes use an RFI to reduce a long list to a shortlist, then an RFP to evaluate the shortlist in detail.
How long should an ERP RFP be?
There is no fixed answer, but a well-structured ERP RFP for a UK SMB or mid-market business typically runs to 15 to 30 pages. The functional requirements section is usually the longest, especially for businesses with multiple modules in scope. Shorter is better if the shorter version still covers all seven sections with sufficient specificity. A five-page RFP that has vague requirements will produce vague proposals. A 50-page RFP that over-specifies low-priority requirements will exhaust vendors and obscure what actually matters.
Should we write our own RFP or use a consultant?
For most UK SMBs and mid-market businesses, writing the RFP internally with guidance like this guide is sufficient, particularly if you have an IT head and a procurement or finance lead who can collaborate on it. An independent ERP consultant adds value when the project is particularly complex, when your internal team lacks ERP procurement experience, or when you need a neutral party to validate requirements before they go to vendors. If you do use a consultant, confirm they do not receive vendor referral fees.
How many vendors should receive our ERP RFP?
Three to four is the right number for most ERP RFP processes. Fewer than three and you risk not having a genuine competitive comparison. More than four and you are producing evaluation overhead for both your team and the vendors that is unlikely to improve the quality of your final decision. Do initial shortlisting before sending the RFP to ensure every vendor who receives it is genuinely in contention.
What happens if vendors do not respond to all sections of the RFP?
An incomplete proposal should be treated as a signal. Either the vendor did not have the capacity to respond properly (a resource concern for a long-term partner), or they could not answer certain sections because their system does not meet those requirements (a capability concern). In either case, follow up directly and ask why specific sections were not addressed. If the reason is a genuine capability gap, confirm whether it is on the product roadmap and when, or whether it would require customisation at additional cost.
