ERP Requirements Gathering: How to Build an RFP That Vendors Actually Read

Why you need a requirements document first

Before you talk to a single vendor, you need a requirements document. Without one, every demo feels impressive and you have no objective basis to compare vendors — exactly the trap the sales motion is designed to create. A written requirements baseline does three things: it forces internal alignment on what matters, it lets vendors respond on your terms instead of theirs, and it becomes the test script for every demo and reference call that follows. The hour you spend structuring it saves weeks of confused evaluation later, and it prevents the most expensive outcome — buying the wrong system because nobody agreed on what right looked like.

Step 1: map your core processes

Document the eight to twelve processes that define your business: order-to-cash, procure-to-pay, inventory replenishment, month-end close, production scheduling, and customer returns. For each process, note the current pain and the must-have capability in the new system. Be specific. "Better reporting" is not a requirement; "a daily aged receivables report by salesperson, available without IT help" is. Specificity is what lets a vendor give you a real answer instead of a reassuring general one, and it is what makes the later scorecard possible.

Involve the people who live in the process

A requirements document written only by the IT lead or the CFO will miss the floor-level reality. Run one-hour workshops with the operators, clerks, and supervisors who touch the work daily. They will surface constraints — a regulatory field that must appear on every pick ticket, a customer-specific pricing rule — that leadership has forgotten. Capturing these early prevents the late-stage discovery that a "complete" system cannot actually handle your business, which is the moment projects either balloon in cost or quietly abandon a promised capability.

Step 2: score must-have vs nice-to-have

Turn the raw list into a tiered register. A simple three-column table — capability, tier, and current pain — keeps the team honest. The discipline here is uncomfortable because every department believes its requests are critical; the scoring forces trade-offs explicitly rather than by accident during the sales call, when a confident presenter can talk any feature into feeling essential to everyone in the room.

• Must-have: blocks go-live if missing, such as multi-currency for exporters.
• Should-have: high value, with a manual workaround acceptable short-term.
• Nice-to-have: future-proofing, not decision-critical today.

Step 3: build the RFP around your process list

Send the same RFP to four to six vendors and require them to respond against YOUR process list, not their feature catalog. Ask for a ballpark three-year total cost of ownership, three reference customers in your industry and size, and a statement of which must-haves they meet natively versus via add-on or custom code. Comparable inputs are the only way to reach a comparable decision; a vendor that cannot map its product to your processes is revealing a fit problem you want to know about now, not at go-live when switching costs are brutal.

A minimal RFP skeleton

You do not need a 200-page document. A focused RFP with the right questions outperforms a bloated one vendors skim. Keep the structure tight so the responses are actually readable side by side, and so your team can score them in an afternoon rather than losing momentum while the proposals sit unread for three weeks.

• Section A: your company profile, size, entities, and industry specifics.
• Section B: the 8–12 core processes with current pain and must-haves.
• Section C: technical and commercial questions, including TCO and exit.
• Section D: required references and a scripted demo request.

Step 4: turn responses into a scorecard

As replies arrive, drop them into a weighted scorecard rather than reading them in isolation. Score functional fit against your must-haves using evidence, not claims, and capture the three-year cost number prominently. This is also where contradictions appear: a vendor may say multi-currency is included, then reveal in the reference call that it requires a paid module. The RFP is your first line of defense against that gap, and the scorecard is where the defense becomes a recorded, defensible decision rather than a feeling.

Step 5: use the document as your demo script

The same requirements register should drive the vendor demos. Hand each finalist the three or four hardest processes from your list and ask them to run those live. A vendor who answered the RFP confidently but cannot execute your process on screen has just saved you a costly mistake, and you reached that insight using the document you already built rather than a separate exercise.

Why this discipline pays off

Organizations that run a structured requirements and RFP process report materially lower overspend and faster time-to-value, because the document prevents both over-buying features and under-scoping the work. The same requirements register becomes the script for vendor demos and the checklist for reference calls, so the effort compounds across the whole selection instead of being discarded after the first step the way a casual wish-list usually is.