Ongoing WMS knows who packed it. It just doesn't tell anyone.
max.dash reads your Ongoing WMS warehouses read-only and turns it into Ongoing WMS reporting that covers an SLA rate per goods owner, a labor report per worker, and a client portal where every brand sees only its own numbers.
Ongoing WMS is a product of Ongoing Warehouse AB. All product and company names are trademarks of their respective owners. They are named solely to state compatibility. No partnership, endorsement or certification is implied.
What a warehouse system doesn't prove on its own.
Ongoing WMS runs your warehouse. It isn't built to prove to your goods owners, day after day, that you delivered what the contract says - and that is exactly what they keep asking you.
- The SLA rate is calculable, not defined. The order and shipment data is all there. What's missing is the rule: when the clock starts, what your cutoff is, which days count as working days, which orders are excluded - and all of it split by goods owner, because every contract reads differently.
- Labor sits in the raw data, not in a report. Who picked and who packed is data Ongoing WMS already carries. Turning it into a labor report across shifts, days and order content is possible, but it doesn't come pre-built.
- Your goods owner has no window of their own. So they email. Every day, per brand, asking for numbers that already exist somewhere in the system.
- Billable volumes get assembled by hand. Packages, returns, special handling - at month end, out of lists, stitched together manually.
What we read out of Ongoing WMS.
The connection runs through the documented REST interface, plus webhooks for events. The documentation is open, and none of it needs a sign-off from Ongoing or an extra module inside the account.
Scroll table sideways
| What we read | From | What it becomes |
|---|---|---|
| Orders and shipments | order records, webhook on status change | throughput, backlog, the SLA clock |
| Goods owners | order header | the client separation, everywhere |
| Worker per order line | picking and packing operations | labor performance |
| Timestamps | order and shipment events | cycle time, cutoff check |
| Line items per shipment | order lines | weighting, points per order content |
| Inventory and movements | stock records, receiving lines | cover, receiving, returns |
We do not read pricing, margins, or end-customer data beyond name and delivery address. Running a warehouse doesn't require either, so both stay out of the connection.
Three ways in, two different jobs.
Ongoing WMS offers REST, SOAP and webhooks side by side, openly documented and set up without a sign-off process from the vendor. That's more than a technical choice - a connection has two different jobs, and the three routes serve them differently.
The first job is the initial load: warehouses, goods owners and articles as master data, plus months of history in orders, shipments and stock movements. REST and SOAP are built for exactly that - pulling large volumes in one pass, sorted cleanly the first time. The second job is keeping up to date: every new order, every status change, every pallet move, as it happens. Repeatedly asking again at short intervals would be the wrong tool for that - slow and unnecessary. So ongoing operation runs on the webhook instead: Ongoing WMS reports the event itself, the moment it happens. The initial load and day-to-day operation each run over the route built for them, rather than forcing one route to compromise on both jobs at once.
Ongoing WMS is used in more than 700 warehouses by the vendor's own count. For a connection, that shows up mainly in how mature the interface itself is: objects and structures have been documented and stable for years, not published last quarter.
The one field that makes the Ongoing WMS labor report different.
Most warehouse systems don't hand over which person handled a given order. Ongoing WMS does - directly, inside the same record, no detour required. That's why labor performance needs no second source here.
The assignment doesn't stop at shipping. Ongoing WMS carries the same worker reference for receiving and for pallet moves. That means the same connection can calculate not just who picked and who packed, but also who logged a receiving line and who moved a pallet - two jobs that eat just as much warehouse time as picking, but rarely get their own report.
No join against a second table, no reconstructing anything from a time window. The webhook carries the worker along with it, so labor performance is readable close to real time instead of only at day's end. On the floor, that's the difference between a shift lead seeing at 2pm that a line has been under target since the morning shift, and one who only finds out at the evening close - once the shift is over and there's nothing left to fix. The same holds for receiving and pallet moves: backlog at the dock becomes visible while it's forming, not the next morning during reconciliation. This is Ongoing WMS's strongest sentence for a labor report: it hands over who picked and who packed directly, so labor performance needs no second source at all.
What max.dash makes of it.
Not a second warehouse system. The reporting layer, KPI dashboard and client portal your warehouse system doesn't carry on its own.
Scroll table sideways
| Capability | With Ongoing WMS | Built from |
|---|---|---|
| SLA rate per client | yes | timestamps, goods owner, your cutoff and working-day rules |
| Throughput and daily forecast | yes | shipments per hour, history |
| Labor performance | yes | worker per operation, straight from the source |
| Points per order content | yes | line items per shipment |
| Ongoing WMS client portal | yes | goods owner as the dividing line |
| Ongoing WMS billing report | yes | shipments, returns, special lines |
| Cover and stock value | yes | inventory per goods owner |
| Returns and receiving | yes | movements and receiving lines |
How the connection runs.
Four steps, a few days. You install nothing and your Ongoing WMS account is never written to.
Clear the access
You create read access in your Ongoing account. We tell you which permissions the connection needs - and which it explicitly does not.
Map your clients
Warehouses and goods owners get mapped to your clients. That's the line every report, every invoice figure and every portal login separates on afterward.
Rules and people
Cutoff time, working days, holidays and exclusions, per client. Alongside that, the Ongoing users get mapped to your own workers for the labor report.
Sign-off
One real week gets checked against what you already know. SLA rate, volumes, labor performance. Only then does the connection go into regular operation.
When a second system sits next to it.
Plenty of 3PLs do not run one system but two or three - per site, per client, per acquisition. That is the normal case, not the exception.
max.dash reads several sources into the same cockpit. Where an interface exists, it works as described here. Where it does not, there is a defined import: eight datasets by file or REST, same feature set, hours of latency instead of minutes. For your clients in the portal, the difference is invisible.
Common questions.
Do I have to move off Ongoing WMS?
No. Ongoing WMS stays your warehouse system and nothing about it changes. max.dash reads along through the existing interface and puts a reporting layer on top. No migration, no extra module inside Ongoing.
Does max.dash write anything back into Ongoing WMS?
No. Access is read-only. What we read is mirrored into a separate database and evaluated there. Nothing is created, changed or deleted inside Ongoing WMS.
Can Ongoing WMS calculate the SLA rate per client on its own?
Ongoing WMS gives you the order and shipment data an SLA rate can be calculated from. What's missing is the definition work: cutoff time, working days, holidays, exclusions, and the split by goods owner. That calculation is what max.dash takes over, per client, every day.
Where does labor performance come from in Ongoing WMS?
Ongoing WMS hands over who picked and who packed each order line directly, inside the same record, with no second lookup needed. max.dash turns that into volume and minutes per package, per person, without reconstructing anything from a separate source.
Does that cover receiving and pallet moves, or just shipping?
Both. Alongside picking and packing, Ongoing WMS carries the same worker assignment for receiving lines and pallet moves. max.dash builds labor performance out of all three, not shipping alone.
See your own SLA rate before you decide.
30 minutes, no commitment. We show you on real numbers what comes out of your Ongoing WMS data.