Multi-client warehousing: 3PL software separation without duplication

Multi-client warehousing is the core capability, and it is more subtle than adding a client field to a table. You need strict logical separation of stock, orders and data, while keeping physical operations efficient across clients. Separate everything too hard and your operators walk twice as far; separate too little and you cannot prove whose stock you shipped. The same design choices also affect contract profitability, because the system has to capture work in real time for billing, reporting and service-level control.

Start with ownership. Stock is held against an owner, and every transaction moves stock within an owner rather than between owners unless an explicit transfer is booked. That makes stock accuracy answerable per client, which matters because your contract almost certainly commits to an accuracy level per client, not an average across the site.

Then decide storage policy per contract. Some clients require dedicated locations — regulated goods, tight batch traceability, or a customer audit that expects to see their own aisle. Others are far cheaper to serve in shared, chaotic storage where the system decides placement and density is maximised. A capable platform supports both in the same building, with zones flagged as dedicated or shared and putaway logic that respects the flag automatically.

Next, process variation. Client A wants goods received against an ASN with mandatory batch and expiry capture. Client B accepts blind receipts with a photo. Client C requires quality inspection on the first three inbound loads of every new SKU. In workflow-configured software, those are three receiving workflows sharing the same scanning app, not three code branches.

Pick strategy is the same story. Single-order picking suits low-volume, high-value contracts. Batch and cluster picking suit parcel-heavy ecommerce clients. Zone picking with consolidation suits large mixed orders. A 3PL platform should let you assign the strategy per client, per order profile, or per wave — and then still allow a mixed wave across clients where the walk saving is worth it and the consolidation step keeps the shipments separate.

Finally, data separation. Users, portals, reports and API keys are scoped to an owner. A client integration can only read and write that client's records. This is not only a commercial nicety; for many tenders it is a hard requirement, and it is one of the first things a professional shipper's IT team will test.

The pay-off of doing this properly is that new contracts stop being disruptive. Adding a client becomes a configuration exercise on an operation that already runs, instead of a renegotiation of how the whole warehouse works. Alongside multi-client control, this guide also looks at the features that separate 3PL software from a standard WMS, including billing, client portals, onboarding, KPIs, platform selection and common 3PL questions. For sector-specific requirements see the third-party logistics industry page.

A third-party logistics provider sells warehouse capacity, handling and fulfilment as a service. The stock on the racking belongs to somebody else, the service levels are contractual, and the margin on a contract is decided by how accurately the work performed is captured and invoiced. That single difference — you are running someone else's inventory for a fee — changes almost every design decision in the software underneath.

A standard warehouse management system assumes one owner of stock, one set of processes, one rate structure and one reporting audience. It directs the physical flow well: it tells the operator what to pick, validates the scan, and books the movement. A 3PL platform has to do all of that while carrying an extra dimension through every single record. Each pallet position, each carton, each pick line, each carrier label and each return belongs to a specific client, and the system must never let those clients see or touch each other's data.

Practically, that dimension shows up in five places. Stock ownership must be separable, so the same SKU can exist for two clients with different batch rules and different valuation. Processes must be configurable per client, because one contract wants two-man delivery scheduling and another wants same-day parcel cut-offs. Activity must be measured, not estimated, because that measurement becomes the invoice. Reporting must be partitioned, because your client wants their numbers and nobody else's. And integration must be repeatable, because every new contract arrives with its own webshop, ERP or marketplace.

The result is that 3PL providers who run a single-tenant WMS end up building the missing dimension in spreadsheets. Billing is reconstructed at month end from exports. Client reporting is emailed as a PDF. Onboarding takes months because every connection is a bespoke project. The operation works, but the commercial layer is manual, late and disputable — and disputes are where 3PL margin quietly disappears.

BizBloqs approaches this as a workflow problem rather than a feature list. The platform is configured as Business Process as a Service — a term worth pinning down, since it is not managed hosting and not outsourcing: your receiving flow, your pick strategy, your billing events and your client reporting are modelled as workflows, so a new contract is a configuration rather than a development project. See the WMS and the OMS for the underlying building blocks, and the complete WMS guide for the general warehouse decision.

The rest of this guide assumes the 3PL case specifically: multiple clients, contractual service levels, activity-based revenue and continuous onboarding.

For a logistics service provider, billing is not an accounting afterthought — it is the product. Every handling movement, every pallet-day of storage, every value-added service and every exception is potentially billable, and the difference between capturing it and reconstructing it later is the difference between a healthy contract and a thin one.

The mechanism that works is event capture at source. When an operator scans a receipt, the system records a receiving event with quantity, unit of handling, client and timestamp. When storage is measured at the daily cut-off, an occupancy snapshot is recorded per client per location type. When a pick is confirmed, a pick-line event is recorded. When someone spends twenty minutes relabelling, a value-added service event is recorded against a service code. Nothing has to be remembered, reconstructed or negotiated at month end, because the invoice is assembled from events that already exist.

On top of the events sits the rate card. A workable rate model needs per-client rates, tiered rates that step with volume, minimums and periodic fees, surcharges for out-of-window or non-conforming work, and effective dates so that an annual indexation does not require re-rating history. Rates should be versioned: when a client queries an invoice line from two months ago, you need the rate that applied then, not the one that applies now.

Storage deserves particular care because it is where most disputes start. Decide explicitly whether you charge by pallet position occupied, by volume, by weight, or by a hybrid, and whether the measurement is a snapshot, a peak within the period, or an average of daily snapshots. Whatever you choose, the platform should show the client the same underlying series you invoiced from. Transparency ends most disputes before they are raised.

Then there is the handover to finance. The billing run should produce a priced, per-client statement that maps to your accounting system's structure, with line-level drill-down back to the originating events. Push it into your finance package rather than rekeying — see the integrations overview for the connection patterns, and what a WMS costs for the platform-side numbers to put in your own business case.

The commercial effect of automated activity billing is usually visible within the first full period: fewer missed value-added services, faster invoicing, shorter dispute cycles, and — often the biggest one — the ability to see contract profitability per client while there is still time to renegotiate.

Every hour your team spends answering "where is my order" is an hour that is not billable and not improving the operation. A client portal is the cheapest structural fix available to a logistics service provider, and it is also a retention tool: a shipper who can self-serve their stock position and order status will tolerate a great deal more than one who has to email for it.

At a minimum, a portal should expose live stock by SKU, including allocated versus available, batch and expiry where relevant, and location type. It should expose order status across the whole lifecycle — received, allocated, picked, packed, shipped, delivered — with the carrier tracking reference attached. It should expose inbound expectations, so the shipper can see what you are waiting for. And it should expose exceptions honestly: short shipments, damages, quarantine and returns.

Two capabilities separate a good portal from a token one. The first is order entry: letting the client place, amend and cancel orders within agreed cut-offs, so the phone stops being the ordering channel. The second is documents and reporting: proof of delivery, packing lists, periodic activity statements and the billing detail described above, downloadable without asking anyone.

Scope everything to the owning client and give the client control over their own users. A shipper's customer service team, their finance team and their supply chain planner need different views, and asking your account manager to create accounts is friction you do not need.

Portals also change your service model in a subtle way. Once the routine questions are self-served, the remaining contact is exception handling — which is the conversation where you actually add value and where upsell to value-added services happens naturally. Route those conversations properly: link the portal's help path to support so requests land as tickets rather than in an inbox.

Finally, treat the portal as part of the sales pitch, not just the delivery. In competitive tenders, showing a live portal with the prospect's own scenario in it is frequently the moment the conversation turns. If you want to see that in your own numbers, start with the ROI calculator, then book a demo and we will run the portal against one of your own client scenarios.

Growth for a logistics service provider is throttled by one thing more than any other: the elapsed time between signing a contract and shipping the first order profitably. If onboarding takes four months, your pipeline stalls behind implementation. If it takes weeks, your commercial team can sell with confidence.

A repeatable onboarding runs in five stages. First, data: item master, packaging hierarchy, barcodes, weights and dimensions, batch and serial rules. Poor item data is the single most common cause of a slow go-live, so validate it before anything else and reject records that will break picking or shipping later. Second, process design: which receiving, storage, picking, packing and returns workflows this client gets, and where they deviate from your standard.

Third, integration: the client's webshop, ERP or marketplace, plus the carriers they use. Fourth, the commercial layer: rate card, billing events, invoicing cadence and reporting pack. Fifth, a rehearsal — run real orders through the flow before the volume arrives, with the client watching, so the surprises happen in a controlled window.

What makes this fast is standardisation with deliberate exceptions. Maintain a house standard for each stage and treat deviations as explicit, priced decisions rather than silent accommodations. Every unpriced exception you absorb during onboarding becomes a permanent cost on the contract.

Software choice affects this directly. Platforms configured through workflows let an operations lead assemble a client on a screen; platforms that require development turn every contract into a project queue behind a vendor's roadmap. That is the practical meaning of the low-code, workflow-first approach: your growth rate is not capped by someone else's release schedule.

Prepare with the same discipline you would apply to your own systems: the selection checklist and the implementation guide both translate directly to a client onboarding runbook.

Logistics service providers usually measure the site well and the contract badly. Site-level throughput tells you whether today went smoothly; contract-level metrics tell you whether the business is worth having. A 3PL platform should produce both from the same event stream, without anyone assembling a spreadsheet.

Start with service. On-time dispatch against the client's cut-off, order accuracy, inventory accuracy from cycle counting, and dock-to-stock time for inbound are the four that appear in almost every contract. Measure them per client, because that is how they are contracted, and expose them in the client portal so the conversation is about the same figures on both sides of the table.

Then measure cost to serve. Handling minutes per order line, travel per pick, touches per shipment and rework rate per client separate contracts that look similar on revenue but differ sharply on margin. A client with many small orders and frequent amendments can consume more capacity than a client with twice the revenue and steady pallet movements.

Combine the two into contract profitability: billed activity against measured effort, per client, per period, with the trend visible. This is the number that should trigger a renegotiation, a process change, or a decision to price differently at renewal — and it is only trustworthy when the underlying events are captured automatically rather than estimated.

Add capacity metrics on top: occupancy by zone and by client, seasonal peaks, and how much space a growing client will need next quarter. Space sold twice is the fastest way to lose a contract, and space left empty is margin evaporating quietly.

Finally, watch the exception queues themselves. Integration failures, quarantine, short receipts and carrier rejections are leading indicators; when a queue grows for two weeks, service metrics follow it downwards a month later. See the ROI calculator to turn these into a case in your own terms, or book a demo to walk your exception queues with us.

Most 3PL software evaluations go wrong the same way: the demo shows a clean single-client flow, everyone agrees it looks good, and the multi-client, billing and onboarding realities surface after signature. Test the things that actually decide your margin.

Ask the vendor to configure a second client live, in front of you, with a different receiving process and a different rate card. If that requires a change request, you have learned the most important thing about your next few years. Ask to see one order's journey end to end, then ask to see the billing events that order generated and the invoice line they produce.

Then probe the boring resilience questions. What happens when a client's webshop sends the same order twice? What happens when a carrier API is down for an hour at cut-off? Who sees the failure, and where? How is a mis-shipment corrected, and what does that correction do to the invoice? Answers to these tell you more than any feature matrix.

Weigh total cost across a realistic horizon, including implementation, per-client onboarding effort, integration work, support and the internal time to run the platform. Compare vendors on the same scenario rather than on their own scripts — the comparison guide sets out a scoring method, and the cost guide covers the pricing models you will encounter.

Two structural criteria deserve extra weight for a 3PL specifically. Configurability decides how fast you onboard, which decides how fast you grow. Data separation decides which tenders you can credibly enter. Everything else can usually be worked around; those two cannot.

If you would like to run this against your own contracts and client mix, book a working session and bring a live example. Nothing else surfaces the fit as quickly.

A 3PL platform is an integration hub with a warehouse attached. On one side sit your clients' systems, and there will be as many of those as you have contracts. On the other side sit carriers, customs and your own finance stack. The quality of these connections determines both service level and margin, because every message that fails silently becomes manual work and, eventually, a credit note.

On the client side, the recurring patterns are: an ERP sending purchase orders and sales orders and expecting stock and confirmations back; a webshop or marketplace sending orders and expecting shipment and tracking updates; and a supplier sending advance shipping notices. Support all three well and most contracts connect in days. See the partner overview for the systems already connected, including Exact Online, Business Central, Shopify and ChannelEngine.

Where carrier integration ends and a TMS begins

On the carrier side you need multi-carrier label generation, service selection rules per client, tracking write-back and returns labels. That is execution: the shipment exists, the carrier and service are known or derivable, and the label has to be right.

Route optimisation, freight rate management and multi-leg planning are a different job, and a different system. A transport management system decides which vehicle, which sequence and which cost; a warehouse platform decides what goes in the box and which label it carries. Both matter to a 3PL, and conflating them in a tender is how providers end up with a product that does neither well.

BizBloqs sits on the execution side and integrates with the transport side rather than replacing it. If your contracts involve own fleet planning or freight procurement, you need a TMS alongside, and the question to ask any vendor is how cleanly the two exchange shipments, statuses and costs.

Rate shopping is valuable when you control the carrier choice, but be careful: if the client's contract dictates the carrier and the service, your rules engine has to respect that, and the audit trail has to show it did.

Message design matters more than protocol. Whether it is REST, EDI or a flat file drop, the questions are the same: is the message idempotent, so a retry cannot duplicate an order; is there a dead-letter path with an owner; are failures visible to a human within minutes rather than at end of day; and can you replay a day of traffic after an outage without corrupting stock?

Finally, plan for the client who has no system at all. A portal with order entry and a spreadsheet import covers the small shipper perfectly well, and it prevents your integration backlog from being clogged by contracts too small to justify it. That completes the ladder: portal for the smallest, file exchange in the middle, full API or EDI for the largest.