Your leaderboards stay inside. The reporting comes with you.
max.dash reads your Extensiv 3PL Warehouse Manager read-only and turns it into an SLA rate per client, a portal where each brand sees only its own numbers, and the billable volumes you invoice on.
Extensiv 3PL Warehouse Manager is a product of Extensiv, formerly 3PL Central. 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 is not built to prove.
Extensiv runs your warehouse, and it runs it for more clients than almost any other platform. What it is not built for is proving to those clients, month after month, that you delivered what the contract says.
- The SLA rate is calculable, not defined. The order data is all there. What is missing is the rule: when the clock starts, when your cutoff falls, which days count, which orders are excluded - and all of it per client, because every contract is different.
- Labor analytics stops at the edge of the interface. Extensiv does report picking and packing performance per worker. It reports it inside its own screens, to you. It does not hand it to anything you want to build on top.
- Your client has no window of their own. So they email. Every day, per brand, asking where an order is - and every unanswered email costs trust rather than time.
- Billable volumes are assembled by hand. Orders, returns, special handling. At month end, out of exports, again.
What we read out of Extensiv.
The connection runs through the documented interface, read-only. Whether your account uses self-serve keys or the older request route is something we clear during onboarding - it changes the paperwork, not the result.
Scroll table sideways
| What we read | From | What it becomes |
|---|---|---|
| Orders and shipments | order records | throughput, backlog, the SLA clock |
| Customers | account structure | the client separation, everywhere |
| Items and lines | order detail | weighting, points per order content |
| Inventory and movements | stock records | cover, receiving, returns |
| Timestamps | order and shipment events | cycle time, cutoff check |
We do not read pricing, margins, or end-customer data beyond name and delivery address. Running a warehouse does not require them, so they stay out of the connection.
Multi-client operation is not an add-on in Extensiv, it is the premise the platform is built on - which is exactly what you would expect from software written for pure 3PLs rather than for merchants with a warehouse attached. Your customers there become your clients in max.dash without inventing a separation field anywhere.
Where labor performance actually comes from.
This is the one place where being precise matters more than sounding capable, so here is the honest version.
Extensiv does measure picking and packing performance per worker. It shows it in its own labor analytics, with leaderboards, inside the Extensiv interface. What the connection we read through carries is order, item, inventory and customer data - and none of that ties a pick or a pack to a person.
So max.dash does not claim that number from the warehouse system. It builds it from a second source that is independent of what any WMS chooses to expose: your time tracking system, plus a mapping of scanner logins to the people behind them.
The advantage of this route is that it does not depend on a vendor roadmap. It works the same way whether Extensiv ever exposes worker assignment or not, and it works identically across every system in your estate.
What max.dash makes of it.
Not a second warehouse system. The reporting layer your warehouse system was never meant to carry.
Scroll table sideways
| Capability | With Extensiv | Built from |
|---|---|---|
| SLA rate per client | yes | timestamps, customers, your cutoff and working-day rules |
| Throughput and daily forecast | yes | orders per hour, history |
| Labor performance | via time tracking | time tracking plus scanner mapping |
| Points per order content | via time tracking | order lines, weighted over the tracked window |
| Client portal | yes | customers as the dividing line |
| Billable volumes | yes | orders, returns, special handling |
| Cover and stock value | yes | inventory per customer |
| Returns and receiving | yes | stock movements |
How the connection runs.
Four steps, a few days. You install nothing and your Extensiv account is never written to.
Clear the access
You create read access in your Extensiv account. We tell you which permissions the connection needs - and which it explicitly does not.
Map your customers
Your Extensiv customers become clients in max.dash. That is the line every report, every invoice figure and every portal login separates on later.
Rules and people
Cutoff time, working days, public holidays and exclusions, per client. If you want labor performance, this is where time tracking is connected.
Sign-off
One real week is checked against what you already know. SLA rate, volumes, 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 Extensiv?
No. Extensiv 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 Extensiv.
Does max.dash write anything back into Extensiv?
No. Access is read-only. What we read is mirrored into a separate database and evaluated there. Nothing is created, changed or deleted inside Extensiv.
Can Extensiv track SLA per client on its own?
Extensiv gives you the order data an SLA rate can be calculated from. What is missing is the definition work: when the clock starts, what your cutoff is, which days count as working days, which orders are excluded, and all of it separated by client. That calculation is what max.dash takes over, per client, every day.
Does labor performance come out of the Extensiv API?
Not directly. Extensiv reports picking and packing performance per worker in its own labor analytics, but that lives inside its own interface. The connection we read through does not carry a person-to-order assignment. The reliable route is your time tracking system plus a mapping of scanner logins to people - max.dash calculates minutes and volumes per person from that, independently of what the warehouse system exposes.
How long does the connection take?
A few days. Clear the access, map your customers to clients, set your SLA rules, then sign off against one real week of data. You install nothing.
See your own SLA rate before you decide.
30 minutes, no commitment. We show you on real numbers what comes out of your Extensiv data.