A shipping SLA you can defend, not just repeat.
Every 3PL promises a delivery SLA to its clients - ship in 24 hours, same-day with a cutoff, whatever the contract says. Almost no warehouse system can tell you, cleanly, whether you actually held it. max.dash turns your order data into an SLA rate per client, built from the rule your contract actually contains.
What "shipped within 24 hours" does not prove.
A shipping SLA sounds like a simple fraction: orders shipped on time, divided by all orders. The argument starts underneath that fraction, at three questions almost nobody writes down.
- When does the clock start? At the order in the storefront, at payment, at import into your system? Pick the wrong one and an order lands on the wrong side of the line - most spreadsheets pick whichever timestamp was easiest to export, not the one the contract names.
- When does it stop? When a packing slip is generated, or when the parcel actually leaves the building? Those are not the same event, and they routinely fall on different days. Measuring against the wrong one flatters the number, or undersells a rate you actually held.
- Which days even count? A same-day or 24-hour promise is almost always a working-day promise - weekends and public holidays sit outside the clock. What counts as a working day, and which holidays apply, differs by client and by country.
None of this is a data problem. Your warehouse system already has the timestamps. It is definition work, and until someone does it per client, "we shipped almost everything on time" is a claim, not a number.
What actually makes an SLA rule.
An SLA rule is not one number, it is a small set of decisions, and every one of them is answered by the contract you signed, not by whichever field is easiest to read out of your system.
Cutoff time, the calendar of working days, which public holidays apply, and which orders are allowed to count at all - each of those is set once per client, matched to that client's contract and to the country they ship from. A US client on a next-day promise and a UK client on same-day do not share a calendar just because they share a warehouse.
Once that rule exists, it runs against your real order data every day, without anyone touching a spreadsheet. Which warehouse system you run does not change the logic - see the systems max.dash already reads.
Why the rule changes with every contract.
You do not run one SLA. You run as many as you have contracts, and they rarely match.
One client sold their shoppers a 24-hour promise with a mid-afternoon cutoff. Another sold same-day, cutoff at noon, and never wants backorders counted against them. A third ships from a different country entirely, on a different holiday calendar. A single, shared rate averaged across all three tells none of them the truth about their own contract - it just hides the disagreement inside one number.
That is why the rule lives at the client level, not at the warehouse level. Cutoff, deadline, working-day calendar and exclusions are configured separately for each client you serve, so the rate each of them sees is the rate their contract actually describes.
What the report actually shows.
Not a single percentage floating on its own. A rate you can stand behind in a call.
You see the SLA rate against the target the contract sets - not against an arbitrary round number nobody agreed to. You see how it moved across the month, so a bad week is visible before it becomes a bad quarter, not discovered afterwards in a complaint. And you see what is still open today: which orders have not shipped yet and are running toward the cutoff, before they turn into a miss on tomorrow's report.
Every excluded order stays traceable. If a rate is questioned, you can open it down to the single order and show why it counted, or why it did not.
The same number on both sides of the call.
A defended SLA rate is worth more in a renewal than any promise, and it changes what the conversation with your client is even about.
In the client portal, each client sees their own SLA rate live - only their own, never another brand's. No end-of-month PDF, no argument about your spreadsheet formula. Your client is looking at the same figure, from the same source, that you are looking at. When a complaint starts with "you're too slow," there is a number to open instead of an opinion to argue with.
Modeled once, then it runs by itself.
Four steps, and none of them involve you keeping a spreadsheet current.
Read the contract
We go through each client's SLA clause with you and pull out the actual terms: the promise, the cutoff, and what the contract excludes.
Build the rule
Cutoff, working-day calendar, public holidays and exclusions are set as one rule per client, matched to the country they ship from.
Run it daily
The rule runs against your real order data every day. No list to maintain, no export to rebuild at month end.
Sign off
One real week is checked against what you already know before the rate goes live in the report and the client portal.
Common questions.
What exactly starts and stops the SLA clock?
The clock should start on a moment defined in your contract - order receipt, payment, or import into your system - and stop on the actual shipment, not on when a packing slip or label was created. Those two events often fall on different days, and using the wrong one flatters or distorts your rate. Which moments apply is fixed once per client, from your contract.
How do cutoff times and working days get set for my SLA rule?
They are not assumed, they are entered. Your cutoff time, which days count as working days, and which public holidays apply are set per client and per country during onboarding, based on what your contract actually says. An order placed after the cutoff, or before a holiday, is measured against the next working day, not against the calendar.
Do you handle public holidays for markets outside Germany?
Yes, holiday calendars are configured per client and per country, not hardcoded to one market. If a client ships out of the US, UK or anywhere else, their working-day and holiday rules are set to match, the same way cutoff and exclusions are - the logic is the same everywhere, only the calendar changes.
Which orders are excluded from the SLA rate, and why?
Orders that would not fairly reflect your timeliness: holds, backorders, unpaid orders, address problems, cancellations and any other case your contract names. They are removed before the rate is calculated, not counted against you and not hidden - which orders are excluded is defined per client, because every contract excludes different things.
Can every client have a different SLA rule?
Yes. If client A has a 24-hour shipping SLA and client B has same-day with a 2pm cutoff, each gets its own rule: cutoff time, deadline, working-day calendar and exclusions are all set separately, per client.
Does my customer see the same number I see?
Yes. In the client portal, each customer sees their own SLA rate, calculated the same way you see it internally - not a monthly export, not a different formula. If the number is questioned, you and the customer are looking at the same source, not two competing spreadsheets.
See your own SLA rate - on your own data.
30 minutes, no commitment. We work through one client's SLA rule with you, live.