Selection

How to set up an ERP RFP that vendors can answer properly

Build an ERP RFP that creates comparable responses, exposes risk, and helps your team shortlist with more confidence.

An ERP RFP can be useful, but only when the business already understands what it needs, what it can realistically deliver, and how it will evaluate responses. Without that groundwork, the RFP becomes a polished document that creates false confidence and a lot of low-value reading.

The goal of a good ERP RFP is not to produce the longest response pack. It is to make vendor and partner assumptions visible, force scope clarity, and let the buying team compare like with like.

For most small and medium businesses, the best RFP is focused, scenario-led, and commercial enough to expose delivery risk rather than just software marketing.

What to prepare before you write the RFP

• A clear statement of business outcomes, phase-one scope, and what success should look like 12 months after go-live.
• A list of in-scope processes, sites, legal entities, reporting needs, integrations, and known pain points.
• A shortlist scorecard so the RFP asks for the evidence you actually need to compare vendors.
• Internal agreement on timeline, budget range, decision owners, and the expected role of implementation partners.

What a practical ERP RFP should contain

• Business overview: industry, size, operating model, growth plans, and current systems landscape.
• Scope and priorities: what is in phase one, what is out, and which processes are most critical.
• Scenarios and use cases: the real process journeys vendors must address in their response and demo.
• Delivery expectations: required governance, migration approach, testing expectations, training expectations, and post-go-live support.
• Commercial response format: software, implementation, support, assumptions, exclusions, and change-control model.

Questions every RFP should force vendors to answer

• What part of the proposed solution is standard, configured, custom-built, or dependent on third-party tools?
• Which assumptions have the biggest effect on timeline, cost, and project risk?
• What data, reporting, or integration issues typically cause delays in similar projects?
• Which roles from the client team are required, and how much time will they realistically need to contribute?

Common RFP mistakes

• Asking for hundreds of feature-box responses without weighting what actually matters.
• Issuing the RFP before the business agrees its phase-one scope and decision criteria.
• Using generic requirements language that allows every vendor to answer “yes”.
• Failing to standardise the commercial response structure, which makes proposals impossible to compare cleanly.

FAQ

• Should an RFP come before demos? Usually after a lighter discovery and shortlist step, not before.
• How long should it be? Shorter than most businesses think. Clarity matters more than volume.
• Who should own it? A programme lead supported by finance, operations, and the eventual business sponsors.