WMS for e-commerce — a complete guide

Three core differences that translate into WMS configuration:

• Small order size. Average 1-3 SKUs. In drugstore and cosmetics 1-2. That changes the meaning of picking - with a three-line order it makes sense to pick 15 orders simultaneously into a cart split into slots.
• High volume volatility. Black Friday means a 5-10x multiplier compared to the average. Valentine's Day, Mother's Day, Christmas. The WMS has to handle that without hiring an IT team for the night.
• Short packing window. The customer clicked at 2:50 PM, the parcel has to leave with the courier at 3:30 PM. There's no time to explain to the worker where to find the product - they need a specific instruction on the terminal.

The list of platforms a WMS realistically has to talk to in Polish e-commerce in 2026:

• PrestaShop, WooCommerce, Magento, Shopify - own-shop engines. Order pulling, stock updates, statuses, waybill numbers, tracking.
• BaseLinker - aggregator. Collects orders from dozens of sources and presents them uniformly. With 5+ sales channels it's the standard.
• Allegro - the Polish market doesn't exist without it. Allegro Smart!, Allegro One, locker integration, automated fulfillment.
• Amazon, eBay - for cross-border clients. FBA, SFP, MCF - each programme has its own shipping time requirements.
• Erli, Empik, Allegro Lokalnie, OLX, Etsy - for niche industries.

What we pull from the platform: order data (customer, address, products, quantities, prices, shipping method, payment method). What we send back: stock levels (near-real-time), order status (accepted for fulfillment, packed, shipped), waybill number, PDF invoice if the shop expects it.

The most common trap with new clients: the shop pulls stock once an hour or once a day. In high-rotation e-commerce that's a guaranteed oversell. Two customers buy the last unit half an hour apart - the second one gets an email "sorry, out of stock" and never comes back.

The realistic standard is a webhook from the WMS to the shop, called on every warehouse operation, plus a full reconciliation every 15 minutes. The webhook fires immediately, the reconciliation catches situations where the webhook was lost due to a timeout or network blip. Configured this way, the system keeps stock at 99.5%+ accuracy - oversells only happen on very rare race conditions.

For some industries (cosmetics, seasonal) it makes sense to distinguish physical stock from sellable stock. The WMS shows 47 units, but we expose 42 to the shop - 5 units are a buffer for returns and reserve. That parameter is set per product, not globally.

Three main strategies and when each makes sense:

• Single order picking - one worker picks one order start to finish. Makes sense for big orders (B2B, high values) or very low volumes (a dozen orders a day).
• Batch picking (multipicking) - a worker picks 10-20 orders in parallel, walking through the floor once. The most common pattern in typical e-commerce. Requires a cart with physical slots or paper labels in bags.
• Wave picking - orders are grouped into "waves" by courier pickup time or warehouse zone. Makes sense for big operations - 1000+ orders a day with multiple couriers and pickups at different hours.

In Weaver WMS the strategy is selected at the warehouse zone level - you can have single order for high-value B2B orders and batch picking for typical e-commerce in the same warehouse.

A pet supplies client, average 350 orders a day, 1-3 SKUs per order. Before the implementation - single order picking, average pick time 7 minutes per order. After multipicking with a 10-slot cart - 3.5 minutes per order of effective time.

How it works on the terminal: the worker logs in, the system groups the 10 most urgent orders, displays the optimal path through the warehouse (zone A first, then B, then C), the worker walks through once, on each location the terminal shows "take X units and put them in slot 4". After all locations, the cart goes to the packing zone, where the packer transfers the contents of each slot to a separate box, scans the first SKU for verification, and gets a ready courier label.

In practice the gain from multipicking is 40-55% over single order. With the caveat that you need a warehouse layout that allows sensible paths - without that the savings shrink.

Packing is the second critical moment in e-commerce, alongside picking. At the packing station the WMS has to handle three things: content verification (each SKU scanned and compared with the order), courier label generation (weight, dimensions, address), shipping document generation and optionally an invoice.

The list of carriers that you realistically work with in Polish e-commerce:

• InPost - lockers and courier. For many shops that's 50-70% of the volume. Integration via ShipX API.
• DPD, DHL, GLS, FedEx, UPS - classic couriers. Each has its own API, easiest to go through a broker (Apaczka, Sendit, Furgonetka).
• Polish Post - Pocztex lockers, Kurier48. Less convenient API but sometimes essential (a small village InPost doesn't reach).
• Orlen Paczka, Allegro One - growing alternatives in Poland.
• DHL Express, UPS Express, FedEx International - for cross-border, longer lead time due to customs.

In practice: Weaver WMS integrates with the main brokers (Apaczka, Sendit, ShipX) and directly with InPost. That covers about 95% of cases in Polish e-commerce. The shop picks the courier, the customer picks the pickup point, the WMS generates the label and prints it.

Returns in e-commerce are 5-15% of orders depending on the industry (fashion can hit 30-40%). It's a separate process, not a simplified "reverse" of shipping. You have to assess the goods, decide what's next (A-grade resale, B-grade, outlet, disposal), possibly issue a credit note and refund.

In a WMS the return flow looks roughly like this: the customer files a return through the shop, gets an RMA number, prints a return label, the parcel arrives, the worker scans the RMA number, the system shows what was supposed to come back and compares it with what actually came in. The goods go to the assessment zone - a packer/coordinator decides whether they go A-grade (back to sale) or to B-grade/outlet. That decision drives which location the goods are booked into.

In Weaver WMS, RMA is a separate document type with its own workflow. That gives you return history per customer, per product, per reason - and lets you spot products with chronic return rates (usually a sign of a bad shop description or a faulty delivery).

Two approaches to when the available stock should drop:

• Reserve at order placement. The customer clicks "buy", the shop stock drops immediately, before the WMS even starts picking. Safe for volume, but requires handling cancellations and payment timeouts.
• Reserve at payment confirmation. The stock drops only when the payment is confirmed. Fewer reservation reversals, but the risk that during the 5 minutes between cart and payment someone else also buys the last unit.

In practice, for normal traffic, the first option works better with a 30-60 minute payment timeout (after which the reservation expires and stock returns to available). For seasonal peaks (Black Friday) you can shorten the timeout to 15 minutes so abandoned carts don't block stock.

Cross-border sales from a Polish warehouse is the fastest-growing segment for many shops. What needs to be handled from the WMS perspective:

• VAT OSS. B2C sales to the EU settled through one window, but VAT rates are national. The WMS has to distinguish the destination country and pass it to accounting.
• Currencies. The customer pays in EUR, the document is in PLN, the rate is from the day of the transaction. That's on the ERP/shop side, but the WMS has to consume the data correctly.
• Warehouse outside Poland. German Amazon FBA, a Czech warehouse near the border - the WMS has to support multi-warehouse with limited network access (replication, asynchronous sync).
• Customs and clearance. For sales outside the EU (UK, Norway, USA) - CN23 documents, proforma invoices, HS codes. The WMS can generate them automatically from the product card.

At some point part of companies with their own warehouse move into fulfillment - handling e-commerce for external clients. That's a completely different business model (3PL) and the WMS has to handle service billing per operation, separate stock per client, separate warehouse zones, and reporting to each client separately. That topic has its own depth - we plan to give it a dedicated post. Soon.

Most warehouse operations in e-commerce happen on a mobile terminal, not on a computer. The standard worker flow in a warehouse worker app looks like this:

• Login and mode selection. Multipicking, single order, inbound, stocktake.
• Task acceptance. The system automatically assigns jobs in priority order and by location proximity.
• Operation execution. Scan location, scan product, enter quantity (or scan, if piece by piece), confirm to slot/cart.
• Task closure. Verification scan, return to packing zone or next task.

The Weaver WMS Mobile app works offline - if the WiFi drops in the middle of the warehouse, the worker finishes the task and synchronisation happens when the connection comes back. This matters because steel racks and metal boxes turn a warehouse into a Faraday cage - you don't get away without planning the WiFi range.

A standard implementation scope for an online shop with 500-2000 orders a day looks like this: integration with the shop engine (PrestaShop, Shopify, custom), integration with BaseLinker for multichannel, integration with a courier broker (Apaczka or directly with InPost), mobile terminals with the Warehouse Worker app, thermal printers for SKU and courier labels, packing stations with scan verification.

An implementation with us typically takes 6-10 weeks from contract signing to production go-live. The first two weeks are process analysis and configuration, two-three weeks are integrations with selling platforms, the last 1-2 weeks are tests with the client on real data and operator training. We usually combine the start with a weekend or a low-sales window so we can iron out the first mistakes without Black Friday pressure.

17 years on the market means we've seen pretty much every scenario e-commerce can come up with - from a one-person drugstore to fulfillment for a few dozen clients with tens of thousands of parcels a day. Every company is different, but the typical patterns are about a dozen. The point is to recognise them before the implementation, not after the first seasonal campaign.