First: do you actually need a WMS?
Before reading any further, answer this question honestly: do you have a process problem or a visibility problem?
A WMS solves a visibility and control problem. It tells you where stock is, enforces the sequence in which work happens, and creates an audit trail of who did what and when. If your operation is running well but you can't see what's happening in real time — a WMS will help.
If your operation isn't running well — high error rates, inconsistent pick paths, unclear accountability — a WMS will make those problems more expensive and harder to ignore. It won't fix them. The same picking error that costs you a reprint on a paper system will cost you a failed audit trail, a support ticket, and a root cause investigation in a WMS. That's not necessarily bad, but it's not what most people budget for.
The operations where WMS implementations go best are the ones where the process is already reasonably disciplined and the manager understands it well enough to configure the system correctly. The ones where implementations go worst are operations that bought the software hoping it would create discipline that didn't exist yet.
If you can't currently tell — from memory or a quick check — where a specific SKU is located, how many picks were completed yesterday, and what your error rate was last week, you probably need measurement and process work before you need a WMS. A spreadsheet and a weekly rhythm will deliver more value in the short term and set you up to get more from a WMS later.
What a WMS actually does on the floor
Vendor demos show a WMS as a smooth, frictionless overlay on your existing operation. In practice, a WMS changes how every person on the floor works — every shift, every day.
Pickers no longer decide where to go next. The system tells them. They scan a location, scan an item, confirm a quantity. If any of those scans don't match what the system expects, they get an error — and depending on how your system is configured, they either override it, escalate it, or can't proceed until a supervisor resolves it.
This is the point that most buying decisions miss. The question isn't "does the WMS support barcode scanning?" — they all do. The question is: what happens on your floor when a scanner fails, a label is damaged, a location hasn't been replenished, or a picker is new and doesn't understand what the error screen means? Those are the scenarios that determine whether a WMS makes your operation run better or worse.
A WMS also changes the job of a warehouse supervisor. More time resolving system exceptions, less time on the floor directing work. Whether that's better depends on your current situation — but it's a real change that your supervisors need to be prepared for.
The implementation reality nobody talks about
Industry research consistently puts average WMS implementation timelines at six to eight months for mid-size operations. Vendors will quote you four to six weeks. The gap between those two numbers is where most of the pain lives.
Here's what actually fills that gap:
Your data is probably not ready
The single most common reason WMS implementations run over time and over budget is data quality. Before a WMS can go live, every product needs a clean SKU, a weight and dimension (if the system uses them), a barcode that matches what's on the physical item, and a defined home location in the warehouse. If any of those are missing or wrong, the system can't operate correctly — and in most warehouses, a significant proportion are wrong.
This is not the vendor's problem. They will help you map the fields, but you have to supply clean data. Underestimate this phase and you will push your go-live date.
Budget for a proper data audit and clean-up as part of the project — not as an afterthought. If you have 2,000 active SKUs, assume the data clean-up alone will take four to six weeks of someone's time alongside their normal job.
Your location structure needs to be designed, not assumed
A WMS needs a formal location hierarchy: zones, aisles, bays, levels, positions. Most warehouses have an informal version of this in their heads and on their labels. Making it explicit — and making sure it's logical enough that a new starter can navigate it on day one — is a bigger project than it sounds.
Get this wrong and you'll be reworking it after go-live, which is disruptive and sometimes requires a stock count to reconcile. Get it right and the system's pick path logic will actually work. The standard recommendation is to design your location structure from scratch as part of the WMS project, even if you think your existing system is fine.
The go-live trough is real
Almost every WMS go-live is followed by a productivity dip. The duration varies — typically two to eight weeks — but it's consistent enough that you should plan for it explicitly. LPH will drop. Error rates may rise temporarily as pickers learn new confirmation steps. Exceptions will queue up faster than supervisors can resolve them.
This is normal. It's not a sign the WMS is wrong for your operation. But if you've gone live during a peak period, or if your MD is expecting productivity improvement from week one, the go-live trough will be a difficult conversation.
Plan your go-live date for a quiet period. Build a six-week buffer into your expected ROI timeline. Brief your senior stakeholders before go-live that performance will dip before it improves.
The implementation team and the support team are different people
The consultant who implements your WMS is usually not the same person you'll call when something breaks six months later. This distinction matters more than most buyers realise. A smooth implementation can mask poor ongoing support — and in a warehouse environment, a WMS issue at 6am on a Monday with orders to ship is a different kind of problem to a software bug at 2pm on a Tuesday.
Before you sign, ask to be connected with the support team — not the sales team, not the implementation team. Ask them what their average response time is for critical issues. Ask what "critical" means in their SLA. Ask whether they have a UK-based support line and what hours it operates. Then ask for references from customers who've been live for 18+ months, not just recent go-lives.
Questions to ask that vendors won't volunteer answers to
The questions below are the ones that separate useful vendor conversations from rehearsed demos. Ask them early — in the first meeting, not after you've narrowed your shortlist.
"What's the most common reason your implementations run over the original timeline?"
The honest answer is almost always "client data readiness" or "scope changes." Any answer that doesn't acknowledge client-side factors should make you cautious — it means they're not setting realistic expectations, which will be a problem when your data isn't ready and they're surprised.
"Can I speak to a customer who's had a difficult implementation — not just a success story?"
Every vendor will offer you references. Those references are pre-selected. Asking specifically for a difficult case, or asking to speak to their support team rather than their sales team's preferred contacts, reveals a lot about how they handle problems.
"What happens to my data if I leave you?"
You need to be able to export all of your stock data, transaction history, and location data in a usable format. Some vendors make this easy. Others charge for it, delay it, or provide it in formats that are difficult to work with. Check this before you're locked in. GDPR also requires that you can demonstrate you can retrieve or delete personal data on request.
"What does your system do when it goes offline — and what's our fallback?"
Cloud-based WMS systems require internet connectivity. If your warehouse loses internet access — or if the vendor has a service outage — your pickers can't scan. What's the procedure? Is there an offline mode? Do you fall back to paper? How do you reconcile stock when the system comes back up? If the vendor doesn't have a clear answer, you should have a plan.
"How long does it take to train a new picker to work independently in the system?"
This is a real ongoing operational cost that nobody factors into the ROI calculation. If your operation has high staff turnover or relies heavily on agency workers, training time per head is a genuine expense. A system that takes four hours to train versus one that takes forty-five minutes is a meaningful difference across 20 agency placements a year.
"Show me what the exception screen looks like — and walk me through how a picker resolves a common error."
Demos almost always show the happy path — clean scans, correct items, smooth flow. The exception flow is what your floor will actually look like once the system is live. If the resolution process is complicated, or requires a supervisor for every exception, that's a material impact on throughput that won't show up in the vendor's ROI projections.
"What's included in the implementation fee — and what will cost extra?"
Standard contract exclusions to look for: data migration work, additional integration builds, hardware (scanners, printers, labels), extended go-live support beyond a set number of days, and customisations. Get the list of exclusions in writing. The headline implementation fee is rarely the full number.
What to actually look for — in operational priority order
Most WMS feature checklists put "real-time inventory tracking" at the top. That's table stakes — every system does it. Here's the priority order that matters from an operational standpoint:
1. Pick path logic you can configure
The system's default pick path algorithm will not be optimised for your specific warehouse layout. You need to be able to adjust it — either yourself or with vendor support — to reflect your zone structure, your fast-mover locations, and your despatch requirements. Ask specifically: can you set pick path sequence by zone? Can you override it for specific order types? Can you prioritise by despatch time?
2. Exception handling that doesn't stop the line
How the system handles discrepancies — wrong scan, location empty, quantity mismatch — is more operationally important than how it handles correct picks. You want exceptions to be logged, not ignored; but you also need pickers to be able to continue working without every exception requiring a supervisor intervention. Find the balance the system supports and test it explicitly in your demo.
3. Reporting you'll actually use
Most WMS systems come with a reporting suite. Most of that suite goes unused because the reports aren't set up to answer the specific questions the warehouse manager needs to answer each morning. Before going live, identify your four or five key operational questions — LPH by shift, accuracy by picker, despatch compliance, replenishment status — and confirm the system can answer them without significant configuration effort.
4. Integration with what you're actually using
"Integrates with Shopify / Sage / Royal Mail" is on every vendor's feature list. The quality of that integration varies significantly. A genuine integration means real-time two-way data exchange — orders flow in automatically, despatch confirmations flow out automatically, inventory updates in both systems simultaneously. A surface-level integration means a scheduled export/import that runs every few hours, or a Zapier connection someone built to fill a gap. Ask to see the integration in a test environment with your actual systems before you commit.
5. UK carrier support
If your operation ships through Royal Mail, DPD, Evri, DHL, or similar, your WMS should generate the correct labels and manifests natively. This sounds obvious but the depth of carrier integration varies. "Supports Royal Mail" can mean full Click & Drop integration with automated manifest generation, or it can mean you export a CSV and upload it manually. Confirm which.
UK-specific considerations
Data residency and ICO compliance
Under UK GDPR, you need to know where your data is stored and processed. Cloud WMS platforms based on US infrastructure should either have UK/EU data centres or provide a valid data transfer mechanism. Ask the vendor for their ICO registration number and data processing agreement before signing. For operations handling pharmaceutical or sensitive product data, this is particularly important.
Accounting integration
Sage is the dominant accounting platform in UK SME operations. If you're on Sage 50, Sage 200, or Xero, verify that the WMS integration is direct and current — not a legacy connector built for an older version. QuickBooks UK is also common. The integration should handle stock valuation adjustments automatically, not require manual journal entries.
UK support hours
If your operation runs early starts — 6am despatch is common in pharmaceutical logistics and distribution — you need vendor support available from that time. Many US-headquartered WMS vendors offer UK support hours in theory but route calls through a US team on a delay. Test this before you sign: call the support line at 7am on a weekday and see what happens.
Working Time Directive considerations
If your WMS tracks time and attendance — and some do — make sure it's configured to flag Working Time Directive compliance issues. Automated alerts for staff approaching the 48-hour weekly limit and appropriate rest period gaps aren't just good practice; they're a compliance requirement.
The shortlist for UK mid-size warehouses (5–50 staff)
| System | Best for | Watch out for | UK pricing (approx.) |
|---|---|---|---|
| Descartes Peoplevox | E-commerce warehouses; multi-channel; good pick path and RF scanning support | Less suited to B2B / pallet-based operations; implementation requires a dedicated internal project lead | From ~£700/month; implementation separate |
| Mintsoft | 3PL operations; multi-client billing; strong Royal Mail and carrier integrations | Built for 3PL — if you're a single-client operation, some features add complexity rather than value | Custom pricing; typically £500–£1,500/month depending on order volume |
| Linnworks | Multi-channel retailers managing inventory across platforms (Amazon, eBay, Shopify); strong order routing | More of an order management system than a true WMS — pick path and RF scanning support is limited compared to dedicated WMS platforms | From ~£449/month; scales with order volume |
| inFlow Inventory | Smaller operations (under 10 staff); straightforward stock control; low implementation complexity | Limited pick path optimisation; not designed for RF scanning workflows; ceiling on operational complexity it can support | From ~£99/month (2 users); scales by user count |
| Cin7 / DEAR | Operations that need inventory + purchasing + accounting in one platform; good if you're outgrowing spreadsheets | WMS functionality is part of a broader platform — dedicated WMS features are less deep than standalone systems; configuration can be complex | From ~£349/month; implementation costs vary significantly |
| NetSuite WMS | Larger operations already on NetSuite ERP; strong reporting and integration with the wider NetSuite suite | Significant implementation cost and complexity; typically requires a NetSuite implementation partner; not appropriate for operations under ~50 staff | Enterprise pricing; typically £2,000+/month total platform cost |
This isn't a ranked list — the right system depends entirely on your operation type, order profile, and existing tech stack. It's a starting point for a shortlist, not a verdict.
For a detailed comparison of specific WMS platforms suited to UK warehouses, see our WMS roundup review.
How to run the selection process without getting sold to
Write a brief before you talk to vendors
A one-page document covering: your operation type, current order volume, SKU count, peak season profile, current systems, and the three or four specific problems you're trying to solve. Send this to vendors before the first call. It filters out systems that aren't a fit and forces the conversation onto your terms, not theirs.
Bring your operations manager or lead supervisor to the demo
The person who bought the system and the person who uses it every day are often different people in warehouse environments. That gap is a root cause of many implementation failures. The people who will actually work in the system — supervisors, lead pickers — should be in the demo asking questions about exception flows and daily workflows, not just the MD or finance director evaluating cost.
Run a parallel pilot before you commit
Where a vendor offers a trial or proof of concept, run it with real data and real scenarios — not the vendor's demo data. Ask them to set up your top 50 SKUs, your actual location structure, and a real order from the previous week. See what breaks. See how long it takes a picker who hasn't used the system before to work through three picks with guidance. That tells you more than a two-hour demo with a vendor expert doing the scanning.
Use the procurement checklist
Before signing any software contract, work through the questions in our SaaS procurement checklist — it covers exit clauses, data ownership, GDPR obligations, and pricing trap questions that are easy to miss in the excitement of a good demo.
Set a go-live date last, not first
Vendors will ask for your target go-live date early in the conversation. That date will then anchor the rest of the project plan. Don't give a hard date until you've completed the data audit and have a realistic picture of how long the data clean-up will take. A go-live date that's too aggressive is the single most reliable predictor of a difficult implementation.