WMS RFP Template

Section 1About Our Operation

The following describes our operation as it runs today and as we expect it to run within three years. Please reflect these figures in your proposal.

Fill this in before you contact anybody. The most expensive WMS mistakes are made here, not during implementation, and they are made by letting the vendor define the conversation first.

• Operation type: [3PL / e-commerce fulfillment / B2B distribution / retail replenishment / mixed]
• Facility footprint: [square feet], across [number] buildings in [locations]
• Current order volume: [orders per day, average], [orders per day, peak]
• Peak-to-average ratio and how often peak actually hits: [detail]
• Lines per order: [average], [maximum]
• SKU count: [active], [total including dormant]
• Inbound volume: [pallets per day], [containers per week]
• Current throughput rates: receiving [units/hr], putaway [units/hr], pick [units/hr], pack [units/hr], ship [units/hr]
• Required throughput at 12 months: [detail]
• Required throughput at 36 months: [detail, or state that it is unknown]
• User count: [warehouse floor], [supervisors], [office staff], [client-facing]
• Multi-client requirements: [yes / no — if yes, how many clients today and projected]
• Existing systems this must live alongside: [list]

Section 2Functional Requirements

For each capability below, indicate exactly one of: standard feature / available with configuration / available via add-on (state the cost) / custom development required (state the cost, the timeline, and who owns the resulting intellectual property) / not available.

Where a capability is available via add-on or custom development, state whether it survives a version upgrade without further cost.

That last sentence is the one that saves money. Customisations that break on every upgrade are how a fixed implementation price becomes an annual one.

• Receiving, including exception and discrepancy workflows
• Directed and zone-based putaway
• Pick methods we use: [single / batch / wave / zone / cluster]
• Pack station workflows with shipping-system integration
• Cartonisation and packing optimisation
• Cycle counting, full and ABC, with variance investigation
• Inventory adjustments with a full audit trail
• Lot, serial, and expiration date tracking
• FEFO / FIFO enforcement
• Multi-warehouse and inventory transfer support
• Returns and reverse logistics
• Kitting, light assembly, and value-added services
• Cross-docking
• Slotting analysis and re-slotting recommendations
• Labour tracking and productivity reporting by user
• Mobile / RF device support: [state your device models]
• Reporting and dashboards, including who can build a new report and whether that requires vendor services

Section 3Multi-Client Capabilities (3PLs Only)

Delete this whole section if you operate a single-client warehouse. It is the section that separates platforms built for third-party logistics from those that added multi-client support afterwards, so it is worth keeping if there is any chance you take on a second client.

Please answer each point specifically. We expect to see these capabilities demonstrated in a working system.

• Client-level inventory segregation, and whether it is enforced by the system or by convention
• Client-specific workflows, SLAs, and business rules
• Client-facing portal: what a client can see, what they can do, and whether it is included in the base licence
• Client-level reporting, and whether clients can self-serve it
• Per-client billing rules — storage tiers, pick fees, receiving fees, accessorials, minimums
• Whether billing output reconciles to an accounting system, and which ones
• Per-client EDI configurations and trading partner profiles
• Time to onboard a new client, from contract to first order shipped
• Whether onboarding a new client requires vendor services or can be done by our own staff

Section 4Integration Requirements

For each system below, describe your standard approach, the typical implementation effort in hours, and any per-connection licensing or ongoing maintenance cost. State whether the connection is a supported product feature or a project deliverable.

"Do you integrate with X?" gets a yes from everyone. The three questions that separate the answers are: is it a product or a project, what does it cost per connection per year, and who fixes it when the other side changes their API.

• ERP: [system and version]
• Shipping platforms and carriers: [list]
• Marketplaces and e-commerce platforms: [list]
• EDI trading partners: [list, with the standards and document types used]
• Accounting / billing: [system]
• TMS: [system, or none]
• BI and reporting tools: [system, or none]
• Automation and material handling equipment: [list, or none]
• For each of the above: real-time, scheduled batch, or file exchange?
• Who is responsible for maintaining the connection when the other party changes their API, and at whose cost?
• Is there a published, documented API we can build against ourselves, and is access included?
• What rate limits or transaction volume caps apply?

Section 5Total Cost of Ownership

Please provide a five-year total cost of ownership, itemised line by line rather than as a single blended figure.

• Licence or subscription cost — priced per what? Per user, per concurrent session, per device, per warehouse, per transaction, or per order?
• What happens when we exceed the pricing unit — the cost of the next user, device, or order band
• Implementation services — included hours, hourly rate beyond, and who bears the cost of an overrun
• Data migration — included or billed, and what format you require our existing data in
• Training — included or billed, per user or per session, on site or remote, and whether train-the-trainer is supported
• Annual support and maintenance — first-year structure, and year-two-and-beyond structure
• Annual price escalation — the cap, as a percentage, in writing
• Customisation — hourly rate, IP ownership, and what happens to it at version upgrade
• Hardware and third-party licences we would need to buy separately
• Sandbox or test environment — included, and how often it can be refreshed from production
• Termination — exit cost, the format our data is returned in, and what transition support is included
• Data export — format, frequency, and whether we can run it without vendor involvement
• Disaster recovery — recovery time objective, recovery point objective, and geographic redundancy

Section 6Contract Terms to Clarify

Please confirm your position on each of the following in your response, rather than deferring them to contract negotiation.

Asking now costs nothing. Asking after you have chosen a vendor costs whatever they decide it costs, because by then you have no alternative left to walk to.

• Pricing escalation cap, as a percentage per year
• Service level agreement: uptime commitment, and what the remedy is when it is missed
• Support response times by severity tier, and how severity is defined and by whom
• Data ownership and portability terms
• Source code escrow (on-premise) or business continuity provisions (SaaS)
• Liability cap, and what it is a multiple of
• Termination for convenience — whether it exists, notice period, and cost
• Acquisition and change-of-control protections
• Whether the contract auto-renews, for how long, and what notice is required to prevent it
• Which entity actually signs the contract, and whether implementation is delivered by that entity or a partner

Section 7Reference Customers

Please provide three reference customers matching the following criteria.

• Same operation type as ours
• Within 50% of our order volume
• Comparable complexity — multi-client, multi-warehouse, or automation as applicable
• In production for at least 18 months
• Implemented within the past four years, on the version you are proposing to us

We will ask those references about: planned versus actual implementation timeline; planned versus actual cost; challenges encountered and how they were resolved; customisations made and whether they survived version upgrades; support responsiveness after go-live; and what they would do differently.

A reference on a four-year-old version tells you about software you are not buying. The version match is the criterion vendors most often quietly ignore.

Section 8Implementation Timeline and Process

Describe your typical approach to each phase below. For each, state the effort estimate in hours, who is responsible — your staff or ours — and what we need to have ready before the phase can begin.

• Discovery and requirements
• Configuration
• Data migration, including what we must supply and in what format
• Integration build and testing
• User acceptance testing, and what constitutes acceptance
• Training delivery
• Go-live approach — big bang, phased by process, or phased by site
• Go-live support: how many of your people are on site, and for how long
• Stabilisation period: how long, what is covered, and when billing for it starts
• Named implementation lead, and whether that person changes at go-live
• Total hours of our staff time required, by role

That last line is the one operators forget to ask for. The vendor's hours are on the invoice; yours are not, and they are usually the larger number.

Section 9Deployment Model

State which model you are proposing, and answer the corresponding questions.

• If SaaS: data residency, backup and disaster recovery approach, whether we can obtain our own copy of a backup, upgrade cadence, whether we can defer an upgrade, and the exit migration path
• If on-premise: hardware requirements, operating system and database support, the upgrade path and its typical cost, source code escrow, and what happens if we skip a version
• Either way: what happens to the system, and to our access to our data, if our internet connection is down for a shift
• Either way: what offline capability exists on the warehouse floor, and how it reconciles when connectivity returns

The cloud-versus-on-premise argument is mostly settled, and mostly a distraction. The questions that still matter are the last two: what your floor can do when the connection drops.

Section 10Submission Requirements

• Response due: [date]
• Format: [PDF / this document completed / both]
• Pricing format: five-year total cost of ownership, itemised line by line
• Reference list with contact names, titles, and direct contact information
• Demo expectations: we will provide scripted scenarios in advance and ask that they be run in a working system.
• Questions about this RFP may be submitted to [name and email] until [date]. Answers will be shared with all respondents.
• Primary contact: [name], [title], [email], [phone]
• Decision timeline: shortlist by [date], selection by [date], target go-live [date]

We are evaluating fit rather than feature count. Where part of our operation is a poor match for your product, please say so — it will not count against your response.