Write an ERP RFP vendors can actually answer

Describe the operating context

Explain what the business makes or sells, where it operates and why it is changing systems. Share realistic transaction volumes, entity structure and integration boundaries. Keep sensitive customer and employee data out of the initial request. Provide enough context for vendors to identify scope rather than guess at a price.

Make requirements demonstrable

Write each requirement as a scenario with inputs and an expected outcome. Add a priority and an acceptance owner. Ask the vendor to identify whether the response is standard, configurable, an add-on, a customization or unavailable. Require a product version and a reference to supporting documentation.

Request a complete delivery proposal

Ask who performs migration, configuration, training and integrations. Request assumptions, customer responsibilities and the support handoff. Use a common cost template for one-time and recurring charges. A proposal should state what is excluded as clearly as what is included.

Evaluate the same way every time

Use the downloadable checklist as a starting point, then tailor it to your process. Freeze the important scenarios before demonstrations so every candidate faces the same questions. Keep commercial sponsorship separate from evaluation criteria. Record unresolved items and require a pilot for any launch-critical capability that remains uncertain.

Send a compact operating brief

Begin with a short description of demand patterns, production or distribution methods, legal entities, sites and the reasons for change. Supply volume ranges with an explanation of peak conditions. Ten thousand order lines spread across a month create a different problem from the same volume before a daily carrier cutoff. Include the systems that will remain and the team available to support the project. State the planned decision process and the evidence expected at each stage. Avoid sharing detailed personal or commercially sensitive data until needed and authorized. A useful brief lets an unsuitable supplier decline early and lets a plausible supplier identify the assumptions behind its proposal.

Write requirements in the language of an event

Replace 'supports traceability' with a scenario: receive two component lots, consume parts of both in one work order, split the output between shipments, then identify the affected customers from either input lot. State the expected records, permitted roles and time available for the exercise. Add a correction, such as reversing a mistaken issue. This makes the response assessable without demanding identical screen designs. Require the vendor to explain the proposed configuration and any external component. The acceptance owner should be the person responsible for that process after launch. A long list of yes answers tells the team less than a few connected scenarios with visible evidence.

Demand a bounded response taxonomy

Use standard, configuration, extension, partner product, custom development and unavailable as response categories, with definitions in the request. Ask the supplier to describe the actual work and dependencies behind its answer. 'Configurable' should identify who configures it and whether it survives upgrades. 'Roadmap' should remain separate from currently available capability. Record release, deployment model and relevant documentation alongside each answer. If a supplier cannot disclose detail yet, preserve it as unresolved rather than awarding a feature score. Let candidates propose a simpler alternative when it reaches the same business outcome; the requirement should describe the result you need, not merely reproduce a legacy screen.

Control the question and demonstration process

Create one question log and share clarifications consistently with all invited vendors, removing identifying commercial information. Freeze critical scenario inputs before demonstrations. Give reasonable preparation time, then introduce a small agreed exception live so the team can distinguish a configured workflow from a prerecorded sequence. Have evaluators record their observations independently before discussing scores. Preserve screenshots or exported evidence when permitted, together with the role and environment used. A supplier may need another session for a specialist module; set a resolution date and keep the gap visible. Do not let enthusiasm from a polished sales presentation substitute for confirmation of a launch-critical process.

Evaluate delivery capacity separately from software scope

Request the named delivery roles, estimated effort, availability, subcontractors and responsibility for migration, interfaces and training. Ask how changes are estimated and approved and what the customer must supply. Microsoft publishes an implementation go-live checklist that includes acceptance and support readiness; its existence illustrates the need to ask about delivery controls as well as features. It does not certify a proposal or prove a partner's performance. Test the proposed team's understanding of your hardest scenario in a working session. A reference conversation, if available and authorized, should address comparable complexity and delivery responsibility rather than seek a universal product endorsement.

Finish with a decision record that survives review

Illustrative example: candidate A demonstrates the core process but leaves a critical bank interface unresolved; candidate B requires an extension for a less important report. Those fictional findings should not be collapsed into one undifferentiated score. Set conditions for the unresolved interface, estimate the reporting extension and compare the resulting delivery risk. Record disqualifiers, evidence gaps, commercial assumptions and who accepts residual risk. Attach the selected scenarios and acceptance criteria to the implementation scope through the appropriate procurement process. The final pack should contain the operating brief, requirement register, question log, demonstration evidence, cost template and decision rationale. That is a more useful output than a large questionnaire nobody can reconcile to the contract.

Common questions

Continue your research

The following profiles provide a starting point for checking vendor-described scope. Inclusion is not a ranking or a statement that every requirement is supported.