WMS Requirements Template and Worksheet

WMS requirements are what you need the system to do, written so that anyone can check whether it does. They sit before a request for proposal. A good set makes the later steps easy; a vague set means every vendor answers a different question.

This page is a worksheet. Work through it with the people who do the work, and you will have a document that survives a demo.

Step 1: map each flow on one page

Start with how work moves today. Pick each main flow and describe it on a single page, in plain sentences or boxes.

Typical flows:

Receiving a delivery
Putting stock away
Taking an order
Picking and packing
Shipping
Returns
Counting and adjusting stock
Reporting to customers or management

For each flow write: who starts it, what information they have, what steps happen, what leaves the flow, and where it goes wrong today. Include the exceptions. "Pallet arrives with the wrong label" is a requirement waiting to be written.

Walk the floor while you do this. Process maps drawn from an office chair describe how things should work.

Step 2: split must-have from nice-to-have

Go through the pain points and label each one.

Must-have: without it, the system is not worth buying, or the business cannot run.
Should-have: important, with a workaround if needed.
Nice-to-have: pleasant, but you would not change your decision for it.

Be strict. If everything is a must, nothing is. A useful limit is to keep the must-have list short enough to read aloud in a few minutes. Anything beyond that needs a reason.

Test each must-have with this question: if a vendor says no, do we walk away? If not, it is a should-have.

Step 3: write requirements you can test

A requirement is testable when two people could watch the same demo and agree whether it passed.

Weak: "The system should be easy to use." Better: "A new picker can complete a pick on a handheld after a short walkthrough, without help."

Weak: "Good inventory accuracy." Better: "Each stock movement records who, when, from where and to where, and shows in a history list for the item."

A simple pattern:

When [situation], the system must [action], so that [result].

Add a column for how you will check it: demo, trial, document, or reference call.

Step 4: example rows (hypothetical)

These rows are invented for a small distributor. Adapt them to your own floor.

ID	Flow	Requirement	Priority	How we check
R1	Receiving	When a delivery has fewer cartons than ordered, staff can receive the shortfall and flag it, and the open balance stays visible	Must	Demo with a short delivery
R2	Putaway	The system suggests a location and staff can choose another, with the choice recorded	Should	Demo
R3	Picking	A pick list shows locations in walking order and confirms each item by scan	Must	Trial on handheld
R4	Packing	Packing screen lists the items and flags a missing one before the box closes	Must	Demo
R5	Returns	A returned item can go to a holding location and be graded before restocking	Should	Demo
R6	Counting	A counter can see a list of locations to count without seeing expected quantities	Should	Demo
R7	Reporting	Owner can see stock below reorder level at a glance	Nice	Demo
R8	Data	All stock and order history can be exported in a common file format	Must	Test export

Notice how each row names one behavior and one check.

Step 5: state your volumes in plain numbers

Vendors can only size a solution if they know your scale. Write down figures from your own records for:

Number of active items
Number of locations
Orders and lines per day, on a normal day and on a peak day
Receipts per week and lines per receipt
Number of users on the floor and in the office
Number of customers, if you serve several
Number of sites

Use ranges if you are unsure, and say where each number came from. Do not guess upward to look bigger; it will only affect the price and the fit.

Step 6: list the systems you must connect to

Anything the warehouse system has to talk to is a requirement too.

Accounting
Order sources, such as a store, marketplace or customer system
Carrier or label tools
Customer portals or reporting tools
Hardware, such as printers and scanners you already own

For each, note what moves in which direction, how often, and who owns the other side. Ask what you have today as well as what you want.

Step 7: set a budget range from your own numbers

Without quoting any market figures, you can work out what a fair range looks like for you.

Estimate what your current problems cost you each year: lost stock, rework, labor spent searching, delayed invoices.
Add what you spend on tools that this system would replace.
Decide what payback period feels acceptable to your business.
Decide whether you prefer a recurring cost or a single larger outlay, and why.

Do not publish the budget to vendors unless you want to. But write it down for yourself, so you can tell a reasonable quote from an unreasonable one.

Step 8: list what is out of scope

Say what you are not asking for. For example, accounting, transport planning or manufacturing. A short "not now" list stops scope growing during demos, when a clever feature can pull the whole project sideways.

Step 9: review it with the floor

Before you use the document, give it to two people who work on the floor. Ask them to find what is missing and what is wrong. They will, and the corrections are worth more than any template.

Then hand the final version to whoever will write the request for proposals, along with the volumes, the connection list and the priorities.

One hypothetical story

A small kitchenware distributor had a list of forty wishes. When asked which would end a vendor conversation, the owner found only six. Two of those turned out to be the same requirement said differently. The final list had five musts, eight shoulds and a handful of nice-to-haves. At the first demo, three vendors stalled on the same must-have, which saved the owner the rest of the afternoon.

If you consider a custom build

Cargohold, which we make, is a one-time custom build with no per-seat, per-truck or per-client fees. If you consider a custom route, requirements like these are what a builder needs most. They are equally useful for any subscription product.

Next step

Pick one flow, map it on one page this week, and write three testable requirements from it.

Questions people ask

What are WMS requirements?

Statements of what you need the system to do, written so anyone can check whether it does. They come before the request for proposal.

How do I write WMS requirements?

Map each flow on one page, split must-haves from nice-to-haves, write testable lines, state your volumes and the systems to connect, and have two floor staff review the result.

How do I write a testable WMS requirement?

Use the pattern when a situation arises, the system must do an action, so that a result follows. Then add how you will check it, such as a demo, trial, document or reference call.

How do I decide what is a must-have?

Ask whether you would walk away if a vendor said no. If not, it is a should-have. Keep the must-have list short enough to read aloud in a few minutes.

What volumes should I give vendors?

Give figures from your own records for active items, locations, orders and lines on a normal and a peak day, receipts per week, users, customers and sites. Use ranges if you are unsure.

Who should review WMS requirements before use?

Two people who work on the floor. They will find what is missing and what is wrong.