Fulfillment SLA metrics: how to build a rate you can defend

The four parts of an SLA metric

Every fulfillment SLA is a promise to ship an order within a defined window - the common phrasing is something like "orders received by 2pm ship the same working day." That sounds simple. The complexity lives entirely in how it gets measured, not in the promise itself. Three identically worded SLAs can produce a rate of 91 percent or 99 percent from the exact same underlying operations, depending purely on definition.

An SLA metric always has four moving parts: a clock start (when the timer begins), a clock stop (what counts as done), a calendar (which days and hours count toward the deadline), and a set of exclusions (which orders don't count at all). Skip any one of these and you're not measuring an SLA, you're reporting a feeling. This is also where a 3PL and its client talk past each other most often - the client means "from the moment I clicked buy," the operator means "from the moment payment cleared." The gap between those two readings is measured in hours, sometimes days.

Where should the clock start?

The most common disagreement is the start point. Three definitions are in common use, and they produce different rates:

• Order placement - the clock starts the instant the order lands in the system. Easy to explain to a client, unfair to the warehouse when payment settles days later.
• Payment received - the clock starts once the order is paid and cleared. With delayed payment methods this can run from seconds to several days.
• Release to fulfillment - the clock starts once the order is pickable in the warehouse, meaning after payment, stock and hold checks have cleared.

In practice, the defensible choice is almost always release to fulfillment, combined with the agreed cutoff. An order released at 9am ships the same day. One released at 4:30pm, after a 2pm cutoff, has next working day as its target. What matters most is applying the chosen start point identically to every order - otherwise the comparison stops meaning anything.

What should stop the clock?

The end point is just as ambiguous. What actually satisfies the SLA?

• Label created - the shipping label was generated. Early, but no proof the parcel left the building. A label sitting on a bench for three days has technically met the SLA and practically missed it.
• Handed to carrier - the carrier's pickup scan. The most honest value, but often poorly reflected inside a warehouse system because the carrier scan comes back asynchronously.
• Ship status set - the order management system marks the order shipped. The practical compromise, as long as the status is set consistently and same-day.

The most defensible definition is the real ship timestamp - the moment the parcel is booked as shipped, not the moment a packing slip happened to be generated somewhere upstream. Those two values often sit a full shift apart. Measuring against the slip flatters the rate, because the document exists before the real shipment does.

Rule of thumb: measure against the date that reflects the real point of departure, not the date that appears earliest in the system.

Working days, holidays and cutoff

An SLA almost never runs in calendar days. An order released Friday at 5pm, after cutoff, has Monday as its target - not Saturday. Three settings need to be explicit:

1. Cutoff time - the daily line after which an order rolls to the next shipping day. Often around midday or early afternoon, and it can vary by carrier and by client.
2. Working-day calendar - which days count as shipping days. Weekends are usually excluded; some operations ship Saturdays.
3. Public holidays - the calendar for wherever the warehouse actually sits. The point is that this is configured per warehouse location and per client, not hard-coded once and forgotten - a facility in one region and a facility in another rarely share the same holiday calendar, and a client with sites in more than one country needs its own calendar per site.

The target ship date is therefore a calculated value: release timestamp plus cutoff logic plus the working-day and holiday calendar. Only against that target date does the real ship date get compared. On time means: shipped on or before the target date.

What should be excluded?

A fair SLA measurement excludes events the warehouse doesn't control. Otherwise the rate punishes the operation for things outside its reach. Typical exclusions:

• Held orders - holds set by the client or a fraud/credit check. While the hold is active, the clock does not run.
• Backorders and stockouts - if the item isn't in the building, fulfillment cannot ship it. These belong in their own category, not in the shipping SLA.
• Cancelled orders - something that was never meant to ship cannot fail to ship.
• Payment pending - as long as payment is outstanding and the start point is defined as release, the order simply hasn't started its clock yet.

These exclusions aren't a trick to inflate the number - they're an honest separation of responsibility. What matters is transparency: the client needs to see how many orders were excluded and why. An SLA rate of 99 percent with 30 percent of volume quietly excluded is worthless. The credible version always reports both figures side by side - the rate, and the excluded volume with a reason attached.

Different SLA rules per client

A 3PL rarely serves a single client under a single rule. One client has a 2pm cutoff and ships Saturdays, a second has noon and weekdays only, a third has a two-day window for oversized items. An SLA measurement that pools every order into one bucket averages away exactly the differences that matter and ends up correct for nobody.

The correct approach measures per client: every order is checked against its own client's SLA rules, and the rate is reported per client. Only the roll-up across those per-client numbers gives an operator-wide view. Reporting has to follow the same split - one client should never see another client's numbers inside the same view. That isn't just good practice, it's often a contractual requirement.

What counts as a good rate?

In our experience, not as a fixed norm: a well-run same-day or next-day shipping SLA sits in the 95 to 99 percent range. A rate sitting at 100 percent for long stretches is itself suspicious - either the deadline is so generous it says nothing, or too many events are being excluded from the count. A rate under 95 percent usually points to a structural issue - capacity that's too tight, weak cutoff discipline, or stock gaps.

Stability matters more than the headline number. A rate that swings between 91 and 99 percent is harder to manage than a steady 96. That's why an SLA is better tracked as a daily trend than a single monthly figure - outliers show up on the day they happen, not a month later. A useful SLA report shows the rate against target, the trend over time, and the individual misses with an order reference attached, so every outlier stays traceable. Where SLA performance sits inside the wider set of contract metrics a 3PL tracks is covered in the metrics that decide client profitability.

Why spreadsheets struggle with this

Most operators build their SLA view in a spreadsheet on top of a CSV export from the warehouse system. That works right up until it doesn't - and it breaks at exactly the points described above:

• The cutoff and working-day logic has to be rebuilt as a nested formula, holiday table included, for every location. Every holiday change and every new client rule makes the formula longer, until nobody fully understands it anymore.
• The exclusions - holds, backorders, cancellations - usually live in different tables than the ship date and have to be joined by hand. Every export is a snapshot; historical holds that have since cleared quietly distort the number.
• Per-client rules mean a separate tab or a column of special-case logic for every client in a spreadsheet. That stops scaling past a handful of accounts.
• An export is a point-in-time snapshot. An SLA rate belongs on a screen that refreshes itself, not in a file someone pulls by hand every Monday and that's already stale by Tuesday.

Most warehouse systems already hold the raw data - order timestamp, payment status, ship timestamp, hold reasons - but not a finished SLA calculation with cutoff, working-day and per-client logic layered on top. The derived fields, like the target ship date or the on-time flag, don't physically exist in the database. They have to be computed from the raw values and applied consistently across every client. That's a data-modeling problem, not a spreadsheet task, and it is exactly the layer max.dash builds on top of the systems already connected read-only.

Common questions