Warehouse Management Software: Do You Need a WMS or a Right-Sized System?
Most growing warehouses don't need a full WMS — they need the 20% of it they actually use, built around their real flow. Here's how to tell which side of that line you're on, and what a right-sized system covers that an enterprise WMS makes you pay for whether you use it or not.
Choosing warehouse management software is less about finding the product with the longest feature list and more about running a selection process that proves a system fits the warehouse you actually operate. A good process starts from your own order, stock and exception data, narrows the market to a realistic shortlist, tests each option on the same scripted scenario and compares total cost, implementation risk and exit terms side by side.
The practical problem is that most buyers do this in the wrong order. They watch polished demonstrations first, fall for one, and only then discover that peak volumes, carrier services, integration ownership or a three-year minimum term were never checked. This guide sets out the selection process step by step, so the decision rests on evidence you gathered rather than on the best presentation.
Selection should start from how work and records really move on your floor. Illustrative photograph, not an OpsMavix project.
Image credit: Rodrigo Rodrigues, Unsplash License. No edits.
Key Takeaways
- Build requirements from your own order profile, stock data and exception log, not from a vendor feature list.
- Decide the solution tier first, then shortlist three to five options that pass your knockout criteria.
- Give every supplier the same scripted demonstration built from your records, and score it with the same panel.
- Score suppliers on fit, integration, cost, implementation approach, support and contract terms, not features alone.
- Compare five-year total cost including internal time, contingency and the price increase clause.
- Agree data export, termination assistance and price terms before signing, because exit is hardest to negotiate later.
In this guide:
- 1. Start From Your Own Warehouse Data
- 2. Turn the Data Into Written Requirements
- 3. Build a Shortlist From the Right Tier
- 4. Run Scripted Demos on Your Own Records
- 5. Score Suppliers on More Than Features
- 6. Compare Total Cost Over Five Years
- 7. Reduce Implementation Risk Before Signing
- 8. Negotiate Contract and Exit Terms
- Frequently Asked Questions
- How OpsMavix Can Help
1. Start From Your Own Warehouse Data
Why requirements begin with records
Every warehouse management software supplier says their product handles receiving, picking and despatch. What separates a good fit from a poor one is how a system copes with your volumes, order shapes and exceptions, and those facts already sit in your order history, stock records and the notes your team keeps about things that went wrong.
Before speaking to any supplier, pull a representative period of data. Four to eight weeks that include at least one busy period is usually enough to see the pattern. If you have strong seasonality, add your peak weeks separately.
What to extract
| Data to pull | Where it usually lives | What it tells you |
|---|---|---|
| Orders and order lines per day | Order system, ecommerce platform or ERP | Daily workload and peak ratio |
| Lines per order and single-line share | Order line export | Which picking methods will suit you |
| Active SKUs and locations | Inventory system or stock sheet | How much location control you need |
| Batch, serial or expiry items | Product master data | Whether traceability fields are essential |
| Carrier services used | Shipping software or carrier invoices | Which label and manifest integrations to test |
| Exceptions in the period | Team notes, customer complaints, adjustments | The failures the new system must prevent |
Hypothetical worked example: an order profile
The figures below are hypothetical. A wholesaler exports four weeks of data covering 20 working days.
- Orders in the period: 9,600, so 9,600 ÷ 20 = 480 orders a day
- Order lines in the period: 26,880, so 26,880 ÷ 9,600 = 2.8 lines per order
- Busiest day: 760 orders, so 760 ÷ 480 = about 1.58 times the average day
- Single-line orders: 4,320, so 4,320 ÷ 9,600 = 45% of orders
These four numbers already shape the selection. Nearly half the orders are single-line, so batch picking of single-line orders is worth testing. The peak ratio means any per-user licence quote must allow for extra temporary staff, and any performance claim must hold at 760 orders, not 480.
2. Turn the Data Into Written Requirements
Separate essentials from preferences
Write each requirement as a short statement that can be tested, then mark it essential or desirable. “The system must hold returned stock out of available stock until inspected” can be tested. “The system should be user friendly” cannot, so rewrite it as “a new picker completes a scanned pick after 30 minutes of training”.
A failed essential should remove an option however well it scores elsewhere. Keep the essential list short and honest. If everything is essential, nothing is.
Cover the requirements buyers forget
Functional requirements describe what the software does on the floor. Our guide to warehouse management system functions walks through each step from dock to despatch, and warehouse management features turns them into a feature checklist. Use those as the functional base, then add the non-functional requirements that often decide whether a project succeeds:
- Integration: which systems send and receive orders, items, stock and despatch confirmations, and who owns each record. Our guide to ERP and WMS integration covers record ownership.
- Devices: handheld scanners, label printers, wireless coverage and whether the software runs on the devices you already own.
- Users and hours: permanent users, peak users, shift pattern and the support hours you need.
- Security: for a cloud service, the NCSC publishes 14 cloud security principles that it says are “designed to help you choose a cloud provider that meets your security needs”. They make a useful structure for written security questions.
- Data: retention, export format and who can access history after you leave.
Requirements template
The entries below are hypothetical, continuing the order profile example.
| Ref | Requirement | Essential or desirable | Evidence it is needed | Test in demo |
|---|---|---|---|---|
| R1 | Batch pick single-line orders | Essential | 45% of orders are single-line | Release 20 single-line orders as one batch |
| R2 | Hold returns until inspected | Essential | 3 resold faulty returns last quarter | Receive a return and check availability |
| R3 | Add 6 peak users for 8 weeks | Essential | Peak day is 1.58 times average | Written price for temporary users |
| R4 | Supervisor dashboard on a phone | Desirable | Requested by shift leads | Show on a phone browser |
The evidence column matters. When a supplier challenges a requirement, or a director asks why it costs extra, you can point to the record that created it.
3. Build a Shortlist From the Right Tier
Choose the tier before the product
Warehouse software comes in distinct tiers: the warehouse module of an ERP, an inventory app with bin locations, a standalone mid-market WMS, an enterprise WMS, a multi-client 3PL WMS and custom software. Comparing products across tiers wastes demonstrations. Our guide to warehouse management software solutions explains what each tier covers and where it stops.
Match the approach to your gaps
| Approach | When it fits | What to check |
|---|---|---|
| Configure current tools | Your ERP or inventory software already has bins and scanning that are not switched on | Edition, licence level, devices and training |
| Integrate existing systems | Each tool works but records fail between them | Record ownership, error queues and reconciliation |
| Packaged WMS | Your flow broadly matches established warehouse practice | Modules, configuration effort, integrations and licence model |
| Focused custom application | One or two workflows are the real gap and packages handle them poorly | Scope, source access, hosting, support and handover |
| Full ERP, packaged or custom | Warehouse, orders, purchasing and finance all need one shared record | Migration, finance fit, delivery capacity and long-term ownership |
Packaged warehouse software brings years of tested workflows, carrier connections and edge cases that a custom build would have to recreate, and it is often the fastest route for a standard operation. A focused custom application can suit a narrow, valuable gap, but it still needs maintenance and support. Neither is automatically cheaper. Smaller sites can use our warehouse management system for small business guide to right-size the scope.
Apply knockout criteria first
Before booking any demo, send each candidate a short written questionnaire covering your essentials. Remove any option that cannot confirm them in writing. Typical knockout questions:
- Does the edition you would sell us support every essential requirement without custom development?
- Which of our carrier services are supported, and is the connection direct or through a third party?
- Can you integrate with our order system and accounts package, and who builds and supports that link?
- Which legal entity signs the contract, and where is our data hosted?
- What are the minimum term, notice period and price increase terms?
Aim for three to five options. Fewer gives you no comparison; more turns the demo stage into a marathon that tires the evaluation panel. If you are comparing named UK products, our best warehouse management software comparison applies one scenario across several of them, and UK buyers can add the checks in warehouse management software UK.
4. Run Scripted Demos on Your Own Records
Send the script and data in advance
A scripted demonstration replaces the supplier’s standard tour with your scenario. Send the script and a small data set at least a week ahead: a few real SKUs, locations, a purchase order, ten orders and a return. Ask the supplier to load that data rather than using their own sample company.
The script itself should follow a day in miniature, from a short delivery through to a count variance. The feature-level detail of what each step must prove is already set out in warehouse management features, so use that as the content and concentrate here on how you run the session.
Rules for a fair demo
| Rule | Why it matters |
|---|---|
| Same script, same order, every supplier | Scores are only comparable if the test is identical |
| Same scoring panel at every session | Different people score differently |
| Include a warehouse operative on the panel | They spot awkward handheld steps that managers miss |
| Run steps on the handheld device, not only a desktop | Floor staff will use the device all day |
| Ask for the exception, then the fix | Normal flows rarely separate good systems from weak ones |
| Record whether each step was live, configured or described | A slide is not a demonstration |
| Note the edition and add-ons used | A step shown on a higher tier may cost extra |
Capture evidence during the session
Give each panel member a printed sheet with the script steps down the side and four columns: demonstrated, configurable, needs development, unsupported. Ask them to write a short reason for any mark below demonstrated. Collect the sheets before anyone discusses the session, so the loudest voice in the room does not set the scores.
After each demo, ask the supplier to confirm in writing how any step they described but did not show works and what it costs. Those replies can later form part of the contract.
A fair score weighs how the system copes with your real layout and volumes, not only its feature list. Illustrative photograph, not an OpsMavix project.
Image credit: Sebastian Schuster, Unsplash License. No edits.
5. Score Suppliers on More Than Features
Set the weights before the demos
Feature scores from the demonstration are one input. A full supplier score should also reflect integration, cost, implementation approach, support and contract terms. Agree the weights with the panel before any demo, so nobody adjusts them later to favour a preferred option.
Hypothetical worked example: weighted supplier scoring
The weights and scores below are hypothetical, for three unnamed suppliers that all passed the knockout stage. Each criterion is scored from 1 (poor) to 5 (strong), then multiplied by its weight. The weights add up to 100, so the maximum possible total is 100 × 5 = 500.
| Criterion | Weight | Supplier X | X weighted | Supplier Y | Y weighted | Supplier Z | Z weighted |
|---|---|---|---|---|---|---|---|
| Functional fit from demo | 35 | 4 | 140 | 4 | 140 | 5 | 175 |
| Integration approach | 20 | 3 | 60 | 4 | 80 | 2 | 40 |
| Five-year total cost | 15 | 4 | 60 | 3 | 45 | 2 | 30 |
| Implementation plan | 15 | 3 | 45 | 4 | 60 | 3 | 45 |
| Support and supplier | 10 | 4 | 40 | 3 | 30 | 4 | 40 |
| Contract and exit terms | 5 | 2 | 10 | 4 | 20 | 3 | 15 |
| Total | 100 | 355 | 375 | 345 |
As percentages of the 500 maximum: Supplier X scores 355 ÷ 500 = 71%, Supplier Y 375 ÷ 500 = 75% and Supplier Z 345 ÷ 500 = 69%.
Supplier Z had the best demonstration, scoring 5 on functional fit, yet finishes third because its integration approach and cost were weak. Supplier Y wins without topping any single feature test. That is the point of weighting the whole decision: a strong demo does not make up for an integration nobody will own or a cost the business cannot sustain.
Sense check the result
A weighted total must never override a failed essential. If a small change in weights flips the ranking, discuss the trade-off openly rather than relying on the number.
6. Compare Total Cost Over Five Years
Price the whole operating arrangement
Headline subscription prices are a floor, not a budget. Ask every shortlisted supplier to quote the same scope: users including peak, devices, integrations, implementation, training and support level. Then add the costs no supplier will quote for you, such as your own staff time on the project and a contingency for the unexpected.
Our solutions guide compares tiers on a three-year basis. For the final decision between two or three shortlisted options, five years is often more revealing, because price increases and renewals have time to show.
Hypothetical worked example: the price increase clause
The figures below are hypothetical planning allowances, not quotes or market prices. All figures exclude VAT. One packaged WMS is priced two ways: with a contract cap on annual increases of 4%, and without a cap where increases of 8% a year are assumed.
One-off costs, same in both cases
| Cost line | Calculation | Amount |
|---|---|---|
| Implementation and configuration | Supplier allowance | £20,000 |
| Scanners and label printers | Allowance | £6,000 |
| Internal project time | 60 days × £200 a day | £12,000 |
| Contingency | 15% × (£20,000 + £6,000) | £3,900 |
| One-off total | £41,900 |
Annual subscription, starting at £18,000
| Year | Capped at 4% | Uncapped at 8% |
|---|---|---|
| 1 | £18,000.00 | £18,000.00 |
| 2 | £18,720.00 | £19,440.00 |
| 3 | £19,468.80 | £20,995.20 |
| 4 | £20,247.55 | £22,674.82 |
| 5 | £21,057.45 | £24,488.80 |
| Five-year subscription | £97,493.80 | £105,598.82 |
- Five-year total with the cap: £41,900 + £97,493.80 = £139,393.80
- Five-year total without the cap: £41,900 + £105,598.82 = £147,498.82
- Difference: £147,498.82 - £139,393.80 = £8,105.02
The same software costs over £8,000 more across five years purely because of one contract clause. That is why total cost and contract terms belong in the same comparison.
7. Reduce Implementation Risk Before Signing
Ask for the plan, not just the price
Implementation carries much of the risk in a warehouse software project, and much of that risk can be seen before contract. Ask each finalist for a written implementation plan with phases, named roles on both sides, data migration steps, testing stages and the cutover approach. Compare who does what. A plan that assumes your team will clean all the item data in two weeks alongside normal work is a risk, not a plan.
Use a simple risk register
Score each risk for likelihood and impact from 1 to 5, then multiply. The figures below are hypothetical for one project.
| Risk | Likelihood | Impact | Score | Mitigation |
|---|---|---|---|---|
| Item data incomplete (weights, barcodes, units) | 4 | 4 | 16 | Data clean-up owner and deadline before configuration |
| Carrier integration fails at go-live | 3 | 5 | 15 | Test every daily service in the pilot |
| Go-live clashes with peak season | 2 | 5 | 10 | Contractual go-live window outside peak |
| Key user unavailable during testing | 3 | 3 | 9 | Named deputy and protected testing days |
Work from the highest score down. The register is also a useful finalist question: ask each supplier which of these risks they have seen most often and what they do about it.
Plan the cutover and the pilot
Agree how stock will be counted into the new system, how open orders and purchase orders will move across and what happens if go-live must be paused. A short pilot on a representative set of products and orders, with acceptance criteria agreed in advance, shows whether the system works with your data before every order depends on it. Our guide to the goods receiving process is a useful reference for the inbound checks to include.
8. Negotiate Contract and Exit Terms
Agree the terms that protect you later
Your negotiating position is strongest before you sign. Once the system runs your warehouse, changing supplier becomes expensive, so the contract should cover what happens when things change as well as how the service runs today.
| Term | What to ask for |
|---|---|
| Initial term and renewal | Length of the minimum term, automatic renewal and notice period |
| Price changes | A cap on annual increases and notice before any change |
| Users and volumes | Price for extra users, peak users and higher order volumes |
| Service levels | Availability, support hours and response times written into the contract |
| Scope of what was demonstrated | Written confirmation of capabilities described but not shown in the demo |
| Data export | Your data, including movement history, in a usable format at any time |
| Termination assistance | Help and pricing for exporting data and running in parallel when leaving |
| Custom code | For custom software, source code access or escrow and documentation |
Data protection and record keeping
A cloud WMS supplier that holds personal data for you, such as customer names and delivery addresses, will typically act as your processor. The ICO’s guidance on what must be included in a controller and processor contract says the processor must, “at the controller’s choice, delete or return to the controller all the personal data it has been processing for it” at the end of the service, and must not use a sub-processor without the controller’s prior written authorisation. Check the supplier’s data processing terms reflect this.
Record retention matters at exit too. HMRC says you must keep VAT records for at least 6 years, or 10 years if you use the VAT One Stop Shop scheme. A WMS is rarely the VAT record itself, but its despatch and return records may support what finance reports. Ask your accountant which records you need to keep, and make sure the contract lets you export them before the service ends.
Frequently Asked Questions
How long does it take to select warehouse management software?
It depends on the scope and how quickly you can gather data, shortlist and run demos. Plan each stage with a date and an owner: data extract, requirements, shortlist, demos, scoring, references and contract. Rushing the requirements stage usually costs more time later.
How many suppliers should be on the shortlist?
Three to five is a practical range. Fewer gives you no real comparison, while more stretches the evaluation panel and makes demos harder to compare fairly.
What is a scripted demo?
A demonstration where the supplier follows your written scenario using your own sample data, rather than their standard presentation. Every supplier gets the same script, so the results can be compared step by step.
Should we choose the supplier with the highest feature score?
Not on its own. Weigh functional fit alongside integration, total cost, implementation approach, support and contract terms, and never let a weighted total override a failed essential requirement.
Why compare costs over five years rather than one?
Price increases, renewals, extra users and integration upkeep take time to show. A five-year view makes the effect of contract terms visible, as the hypothetical price cap example shows.
What contract terms matter most for a WMS?
The minimum term and notice period, a cap on price increases, service levels, the cost of extra users, and the right to export your data with its history. For custom software, add source code access and documentation.
Is packaged software or a custom system the safer choice?
Neither is safer in every case. Packaged software brings tested workflows and an established support model. A focused custom application can close a narrow gap the packages handle poorly. Compare both on the same scenario, cost basis and contract terms.
Can OpsMavix build warehouse management software?
Yes. OpsMavix can build focused applications or a full custom ERP, and can configure or integrate suitable existing tools where those approaches fit the requirements.
How OpsMavix Can Help
OpsMavix can help you turn your own order, stock and exception data into written requirements, then test whether configuration, integration, a packaged WMS or a focused build closes the gaps you can demonstrate.
That may mean switching on what your current tools already offer, connecting them reliably, building an inventory automation system, adding a wholesale order management system or ecommerce inventory automation, or developing a full custom ERP.
Contact OpsMavix with one recent week of warehouse orders and exceptions, the records behind them and the handoff that creates the most rework. We can use that evidence to define requirements and a practical pilot.
Keep reading
Getting value from OpsMavix? Add us as a preferred source on Google — you'll see more of our operations content in your AI Overviews, AI Mode and Search.