Sonic Tools USA

The problem

Sonic Tools USA runs a busy multi-rack warehouse moving a deep SKU catalog of professional tools out to dealers and end customers across the continent. Their existing inventory management system was doing the parts it was built for — stock control, purchase orders, receiving, financial reporting — well. The trouble was on the floor.

Bin locations were fixed. A SKU lived where it had always lived, regardless of how often it was actually picked. Picklists were assembled upstream, printed, and handed to the floor with the order of stops baked in by whoever printed them — not by where things actually were in the warehouse. Pickers walked the same long routes every day. Fast-moving items sometimes sat deep in the racks; slow movers sometimes sat in prime real estate. None of this was the inventory system's fault — that work just wasn't in scope when it was specified.

The approach

We started with a feasibility study, not a build proposal. Two weeks on the floor: watching picks happen, timing routes, mapping which bins held what, pulling the order history out of the existing system to see what actually moved versus what occupied prime locations. The deliverable was a written audit — what the existing system did well, what it left on the table for the floor team, and a concrete option set for closing the gap.

The decision out of the audit was deliberate: don't replace the existing system. Build an interface layer. The inventory system stays the source of truth for stock, purchase orders, GL reporting, and the operational reporting their accounting team already trusts. A new application sits beside it and handles the parts the floor needs that the inventory system was never designed to do.

The build

The interface layer connects to the existing inventory system through its API. SKUs, stock levels, and incoming orders flow in; location moves, pick assignments, and confirmations flow back out. On top of that integration the application does four things the original system didn't:

• Handheld scanner integration.Any standard smartphone or rugged Android scanner becomes a pick-and-place terminal — no proprietary hardware to source or maintain. Workers scan a bin barcode, the app confirms or corrects, and the existing inventory ledger updates in real time.
• Picklist assignment via app.Orders surface in a queue, get assigned to a picker on shift, and arrive on the handheld in the order the warehouse should actually be walked — not the order the customer placed them in.
• Dynamic routing.For every picklist the application solves a shortest-path traversal of the warehouse — S-shape for full-aisle batches, largest-gap when picks are sparse, TSP-optimal for short lists. Industry benchmarks for dynamic versus static routing land around a 45% reduction in walking time. Actual gains depend on layout and pick density; the direction is the same: less walking, more picking.
• Dynamic placement.The biggest single change. Fixed bin locations are gone. The application assigns each SKU to a location based on what's available, what velocity class it falls into (top 20% by pick frequency goes to the “golden zone” — knee-to-shoulder height, closest to the outbound dock), and what it tends to ship with (co-location of items frequently ordered together). When velocity shifts — seasonality, a new SKU surge, a discontinuation — the app proposes re-slotting moves before the floor feels the impact.

What it does in production

The interface model is the point. The client kept the system they trusted for the parts of the business it handles well, and added the layer they needed for the floor without going through a multi-year WMS replacement project. New SKUs onboard through the existing system; the new application picks them up automatically and slots them appropriately. Reports the inventory system already generates don't break. The procurement workflow doesn't change. The floor experience does.

This is the Sophonix house pattern in one project: figure out what the existing system actually does well, figure out what the new system needs to do, and build the seam between them. Conventional automation where the math is well-understood — route optimization, ABC velocity classification, golden-zone slotting — and AI where it earns its place: demand forecasting that triggers re-slotting moves, co-occurrence detection that quietly groups related SKUs.

Tech stack

• Web application — browser-first, no install, runs on smartphone, tablet, and warehouse workstation
• Three.js 3D warehouse viewer — every rack, bin, and floor location inspectable in-browser
• Existing-WMS REST API integration — two-way sync for inventory, orders, and location moves
• Slotting + routing: ABC velocity classification, dynamic re-slotting triggers, S-shape / largest-gap / TSP route solvers, k-means / DBSCAN clustering for batch picking
• Demand forecasting: Auto-ARIMA / ETS / Prophet across the fast-moving mix, Croston / TSB for intermittent-demand slow movers
• Mobile scanning via standard smartphone — no proprietary hardware

If this pattern sounds familiar

A trusted core system the business depends on, doing most of the job — and a floor team working around the parts it can't reach. The shape shows up across logistics: warehouses, fulfillment lines, fleet ops, supply chains, returns processing. If you've got a version of it in your operation, we'd be glad to take a look with you. The feasibility study is the first paid deliverable; if it turns out the existing system can be tuned without a new build, we'll tell you that.