An ERP RFP exists to make three or four vendors answer the same hard questions in writing, so you can compare them on fit, price, and terms rather than on who demos best. The single biggest mistake is sending a giant undifferentiated feature list, 500 to 900 rows long, that every modern suite answers "yes, standard" to. That list produces a stack of returns where every vendor scores above 90%, which tells you nothing. A useful RFP does the opposite. It poses 40 to 80 questions where vendors actually differ, built around your own business scenarios and your own commercial terms, and it ties every answer to a score you set before the responses arrive.
Send an RFI first only when you cannot name three finalists
An RFI (request for information) and an RFP (request for proposal) do different jobs, and sending the wrong one wastes a month. An RFI is a short, open set of questions sent to five or more vendors to learn what exists in the market and who is worth a closer look. An RFP is a detailed, scored request sent to the two or three finalists you already believe can win, asking them to commit to scenarios, prices, and terms.
Skip the RFI when the shape work has already named your shortlist. A $600M single-country process manufacturer that has settled on tier 2 and three finalists does not need an RFI; it needs the RFP. Send the RFI only when the field is genuinely open, for example a first-time buyer replacing a 20-year-old custom system who cannot yet name three credible products. Even then, keep it to 15 to 25 questions and a two-week turnaround, because its only purpose is to build the shortlist the RFP will test.
Put four things in, leave the feature encyclopedia out
The RFP should carry the facts a vendor needs to price and commit, and nothing that invites marketing prose. Four content blocks do almost all the work: your company shape and scope, the discriminating requirements as scenarios, the commercial questions, and the response format you will score. Everything else is padding that lengthens the read and lowers the signal.
| Include | Purpose | What good looks like |
|---|---|---|
| Company shape and scope | Lets the vendor price the real program | Revenue, user count, legal entities, countries with statutory reporting, the systems you are keeping |
| 40 to 80 scenario requirements | Exposes where products differ | Each tied to a process you run, with numbers, demanding a four-way answer |
| Commercial and pricing terms | Makes the five-year cost comparable | License model, implementation assumptions, exclusions, change-request rates, named SI |
| Response format and scoring weights | Makes returns comparable side by side | Fixed templates, word limits, the weights you will score against |
| Timeline and decision dates | Sets the competitive clock | Response due date, demo window, decision date, target go-live |
Leave out the 900-row feature checklist, the paragraphs of company history, and any requirement you cannot imagine a credible vendor failing. The test for keeping a requirement is simple: if you cannot name at least one finalist that would answer it with anything other than "standard," it is scoring noise, so cut it. "The system shall post a journal entry" scores every vendor the same and belongs nowhere in the document.
Write requirements as scenarios with numbers, not as feature rows
A feature row asks "do you support intercompany billing?" and every vendor answers yes. A scenario asks the vendor to walk a specific transaction through the product, with your numbers, and the differences surface immediately. Write each discriminating requirement as a short scenario the vendor must respond to in writing and then show live in the demo. Three illustrations show the shape.
Consider a $500M distributor processing a drop-ship order across two legal entities. A customer in entity A orders 400 units; the goods ship direct from a supplier to the customer; entity B holds the supplier contract and must record the intercompany margin; the sale has to eliminate on consolidation at month-end. Ask the vendor to describe, step by step, which documents the system creates, where the intercompany entry posts, and whether any step needs custom code. Take a five-plant discrete manufacturer running an engineer-to-order job where the customer changes the spec mid-build, after 60% of material is issued. Ask how the system reprices the order, handles the already-issued material, and keeps the margin visible. Suppose a 12-entity group closes the books in two currencies across four countries, each with its own statutory report, in a five-day close. Ask the vendor to show the consolidation and the local filings, not just the group ledger.
Each scenario should demand a four-way answer rather than a yes or no: standard (works out of the box), configured (met through setup with no custom code), custom code (development you will own and maintain), or partner or roadmap (a third-party product or a future release). A vendor that marks "standard" against a scenario that is really custom code is the vendor whose program lands at the top of the cost range, and the scenario is what lets you test that claim live. You do not have to invent these from a blank sheet. Start from the companion ERP business requirements catalog, a downloadable workbook of common process requirements, and keep only the 40 to 80 that discriminate for your business.
Ask the commercial questions in writing, because the answers change
Vendors answer money questions differently on paper than in a meeting, so the RFP is where you pin them down. A verbal "it's all included" becomes a precise scope once it has to be written and signed. Put each of these in the commercial section and require a direct answer, not a brochure.
- License or subscription model, priced per named user, per module, or by consumption, with the unit defined and the five-year total shown on the vendor's own growth assumptions.
- The SI (systems integrator) implementation estimate, with the SI named and its consultants' certifications listed, because the SI is commonly 40 to 60% of the total bill and a strong product installed by a weak team is a weak program.
- The implementation assumptions behind that estimate: how many entities, how many integrations, how much data migration, how many custom reports, and the number of your people assumed on the program.
- What is NOT included. Ask directly for the exclusions: data cleanup, integrations to systems you are keeping, training, testing, the first weeks of support after go-live, and any third-party product needed to meet a requirement.
- Change-request rates and the process. Get the hourly or daily rate for work beyond the statement of work, in writing, and the approval path, because 10 to 30% of program hours typically land as changes once the real detail appears.
- Annual increases. Ask for the cap on subscription increases at renewal, since an uncapped 7 to 10% a year compounds into a large number over a five-year horizon.
The exclusions list is the most useful answer in the whole RFP. A low implementation quote with a long list of exclusions is more expensive than a higher quote that includes them, and only the written RFP forces the exclusions into daylight before you sign.
Tie every question to a weighted score before the responses arrive
An RFP is only comparable if you decide what each answer is worth before you read a single response. Build a weighted scoring model, publish the category weights inside the RFP, and score each finalist on the same rubric. Weights should follow the decision, so fit and the SI carry more than a vendor's company size.
| Scoring category | Suggested weight | Scored on |
|---|---|---|
| Scenario fit (the 40 to 80 requirements) | 35% | Four-way answers, tested live in the demo |
| Commercial terms and five-year cost | 25% | The written price, exclusions, and change rates |
| SI quality and implementation plan | 20% | Named team, certifications, realistic hours |
| Deployment, roadmap, and references | 10% | Model offered, dated roadmap, a reference of your shape |
| Viability and support model | 10% | Financials, install base in your industry |
Score each scenario 1 to 5, multiply by the category weight, and total the three finalists on one page the steering committee can defend. A 5 means "shown live on our data, standard." A 1 means "custom code or a partner product the vendor first called standard." Because the weights were set before the responses arrived, no vendor's strong demo can move them after the fact. The same rubric then carries into the demos, where a requirement marked "standard" on paper must be shown live, on your data, with no "we can configure that later."
Avoid the four mistakes that waste the RFP
Most weak RFPs repeat the same errors, and all four are avoidable. The first is copying a vendor's own RFP template, which is written to flatter that vendor's product and will quietly steer the questions toward its strengths. The second is the 900-row feature list nobody scores, which produces returns where every vendor clears 90% and the decision defaults to price or to the best demo. The third is sending no scenarios, so the vendor answers in generalities and commits to nothing you can test. The fourth is leaving the commercial terms vague, which lets a low headline price hide a long exclusions list that reappears as change requests after signing. Write your own document, keep it to the questions that discriminate, build it around scenarios with numbers, and make the money terms specific.