Write a WMS RFP and run an evidence-based demo

A useful WMS RFP asks suppliers to prove your warehouse transactions, price a common scope, and disclose exceptions. Keep the document short enough to answer seriously, with attachments for sample data and scenarios. The goal is not the longest feature checklist. It is a record that connects a business requirement to a demonstrated result, an implementation commitment, and a commercial assumption.

Start with a warehouse profile

Describe sites, shifts, inventory ownership, order patterns, products, units, handling conditions, and peak periods. Include the systems that remain in place and the interfaces expected. Separate current workload from forecast workload and label estimates. Provide anonymized sample transactions without unnecessary customer or employee data. A supplier needs enough detail to identify complexity without receiving a production database.

List the operational problems you are trying to solve and their evidence. For example, document where stock adjustments originate or where staff rekey shipment data. Explain the intended outcome in measurable terms, but do not invent a target because it sounds ambitious. Distinguish nonnegotiable controls from preferences and future ideas. This prevents a visually impressive demonstration from distracting the team from a missing core capability.

Make each requirement observable

Ask suppliers to classify responses as standard, configured, integrated, custom, or unsupported. Require an explanation rather than a yes in a cell. Ask whether the demonstrated behavior is available in the proposed edition and whether additional licenses are needed. Store unresolved answers as open requirements with owners instead of translating them into optimistic scores.

Design a controlled demonstration

Provide a common sequence: receive a partial shipment, place stock, replenish a pick face, allocate an order, short pick, pack, cancel another order, ship, and process a return. Add the scenarios that matter to your operation, such as multiple clients, lots, serials, or automation faults. Use the same starting data and expected outcomes for each candidate.

Let floor staff observe the handheld workflow, not only the management dashboard. Ask how mistakes are corrected and what an operator sees when scanning an invalid item. Record manual steps, permissions, and evidence available afterward. A supplier-led demonstration is useful context, but it is not the same as your staff completing a hands-on acceptance test. Keep that distinction in the decision record.

Score evidence without hiding a failed gate

Use a small scale with clear definitions: demonstrated in the proposed scope, explained but not demonstrated, dependent on additional work, or unsupported. Do not average a failed inventory-control requirement into a passing overall percentage. Must-pass requirements should remain gates. For optional features, agree weights before seeing the demonstrations so the scoring does not follow whichever presentation the team liked best.

Keep price, fit, implementation risk, and support as separate dimensions. Record the evidence behind each assessment, including version, environment, and any custom setup used. Ask the supplier to confirm the written record. This is a procurement aid, not a public product review or an assertion that you tested every edition of a supplier's software.

Connect the RFP to delivery

Carry accepted scenarios into the statement of work and test plan. Clarify who supplies data, cleans mappings, configures rules, builds interfaces, trains users, and approves results. Request an implementation sequence and dependencies rather than an unsupported promise of a fixed launch date. A timeline without data and staff responsibilities is difficult to evaluate.

Ask for a matched commercial response: base and peak volumes, environments, integrations, support hours, migration rehearsals, training, and exit assistance. Use the total-cost model to compare proposals after scope alignment. Before signing, have qualified procurement, security, and legal reviewers examine their areas. A well-run demo does not replace contract review or a recovery exercise.

FAQ

How many requirements should be in the RFP?

Enough to establish the actual operation and decisive exceptions. Prioritize observable requirements over a long undifferentiated list of features. Attach detailed scenarios where needed.

Can a supplier use its own demo data?

It can for orientation, but require your common scenarios for the comparison. Otherwise candidates may demonstrate entirely different levels of complexity and leave important gaps hidden.

Is a high score enough to award the project?

No. Check must-pass gates, commercial scope, implementation ownership, security review, and contract terms separately. Scores help organize evidence; they do not remove judgment.

Continue your decision

• Warehouse management software cost: build a defensible budget — Map subscription, implementation, devices, integrations, and internal work into a comparable WMS budget without invented market prices.
• WMS pricing models: users, orders, sites, and overages — Decode the billing unit in a WMS proposal and test the effect of seasonal peaks, additional sites, and changing user counts.
• Cloud or self-managed WMS: assign the operating responsibilities — Compare hosting responsibilities, upgrades, recovery, and integrations before selecting a cloud or self-managed warehouse system.
• Use the launch readiness checklist to connect this guide to a practical planning task.
• Compare WMS approaches before treating a product category as a complete specification.

Sources and scope

Official pages checked on October 30, 2026. The planning procedures, test scenarios, and worked examples are original editorial guidance, not prescribed standards or evidence of product testing.

• SAP — What is a WMS? — General warehouse execution terminology; supplier education, not independent product evaluation.