What a Fulfilment SLA Should Include

One number stretched over every event is not an SLA

The line you most often see on a fulfilment page is "24-hour support". Read as a service level it means almost nothing, because it puts one clock over four different events. A client asking for a quote, a paid order waiting to move, and a customer whose parcel is lost are not the same promise, and a single figure that covers all three is either too slow on the urgent one or impossible to keep on the routine one. When you sell fulfilment to a client, that vagueness lands on you: your client judges your agency on how quickly the store you manage answers, and the account you could lose is the one where a lost-parcel message sat unanswered while your "24-hour" promise technically held.

An SLA that survives a real week separates the events first, then attaches a promise to each. Below are the four clocks worth measuring, and for every one the seven things that turn a nice sentence into something you can hold a supplier to and repeat to a client.

The four clocks

A fulfilment relationship has four moments where speed is the whole point. Name them separately and you can promise each honestly:

• Quote acknowledgement — a request lands and someone confirms it exists and says what happens next.
• Quote completion — a complete brief becomes a landed price you can put in front of a client.
• Order release to dispatch — a paid order becomes a parcel with a tracking scan.
• Issue acknowledgement and next update — a problem is raised, confirmed, and then carried on a named update rhythm until it closes.

For each clock, write down seven things: the start event, the stop event, the business hours and timezone it runs in, what pauses it when information is missing, the peak-season exception, the severity, and whether a credit applies. Miss any of these and the clock becomes an argument. The start event is the one most often left implicit, and the one every dispute turns on.

Clock 1 — Quote acknowledgement

Start event: a request arrives — a brief, a product link, a "can you quote this". Stop event: a human confirms it is received and states either what is missing or when the quote will follow. This clock is not the quote; it is the receipt, and it exists so a client is never left wondering whether a message vanished.

Business hours: your provider's working hours, in their timezone, stated plainly. RyanFulfil's desk runs from Guangzhou (UTC+8) and answers Monday to Saturday; a message arriving at 10pm China time is a next-morning reply, not a same-evening one. Missing-info pause: an acknowledgement should never pause — you can always confirm receipt — but it is the moment to name the gap, so the next stage does not start against a brief that cannot be quoted. Peak-season exception: none needed; an acknowledgement is cheap even in the Chinese New Year window. Severity: low. Credit: no — nobody has paid for anything yet.

Clock 2 — Quote completion

Start event: a complete brief — product reference, destination markets, the variants that matter, and a realistic volume. Stop event: a landed quote issued with its legend, meaning the price says which item, on what unit basis, covering which costs, to which destination on which route, and how long before transit begins.

Business hours: quoting depends on suppliers, and suppliers are the constraint. Factories and most suppliers are closed at the weekend, so a brief that lands on Sunday is worked on Monday, and this clock should run in working days, not calendar hours. Missing-info pause: this is where the pause earns its place — each unanswered question (which variant, which country, what quantity shape) stops the clock until it is answered, which is why the acknowledgement named the gap. Peak-season exception: factory closures move the whole timeline; write the Chinese New Year and peak exception into the SLA rather than discovering it in February. Severity: medium. Credit: normally none, because a quote is not a paid order. Before you promise a client a quote turnaround, understand how the commercial model works on the Agency Desk, so the promise sits on a cost you control.

Clock 3 — Order release to dispatch

Start event: a paid order is released to the warehouse — on Shopify and WooCommerce automatically through the two-way connection; on TikTok Shop, eBay and Etsy it is the order you pass through. Stop event: the parcel is handed to the carrier and a tracking number is uploaded back to the store. This is the clock your client cares about most: the gap between "payment taken" and "it's on the way".

Business hours: working days again, and split the case in two — stock already held in the warehouse dispatches on a different clock from an item procured to order, and your SLA should say which promise applies to which. Missing-info pause: an incomplete address pauses this clock, and so does a missing customs identifier on the countries that require one — Turkey (TC Kimlik No), Chile (RUT), Brazil (CPF/CNPJ), South Korea (PCCC) and Argentina (CUIL).

The order cannot move without them, so the clock stops until the field is supplied rather than counting against the warehouse. Peak-season exception: the Chinese New Year and peak window applies here too. Severity: high — this is revenue in motion. Credit: this is the one clock where a credit for the controllable part is defensible, but only against the release-to-dispatch window your provider owns, never against transit time.

Delivery windows are route-specific estimates, not guarantees, and a credit written against the carrier's route is a promise no fulfilment provider can keep.

Clock 4 — Issue acknowledgement and next update

Start event: an issue is raised — a lost parcel, a damaged or wrong item, an address or delivery failure. This clock has two stops, not one. The first stop is the acknowledgement: the problem is confirmed and owned. The second is the rhythm that follows, because a first reply is not a resolved problem, and the failure mode here is the acknowledgement that is treated as the answer.

The rule worth writing into the SLA is that every update names four things: the current stage, who owns it, when the next update comes, and what evidence closes the case. That is the same standard RyanFulfil publishes on its own order issue centre, and it is what stops "we're looking into it" from becoming a silence. The seller-side version of this discipline is set out in the note on what a status reply actually carries; the agency version is to make it a contractual cadence, not a courtesy.

Business hours: as above, with anything that depends on a factory getting a named working day rather than a vague "soon", because the supplier is closed at the weekend. Missing-info pause: a claim that needs arrival photos or a fault video pauses on the evidence, but the update cadence does not pause — you still owe the client a "still waiting on X" on schedule. Peak-season exception: applies. Severity: tier it by whether an end customer is actively waiting; a live delivery failure outranks a general query. Credit: no automatic provider credit — the response commitment is the deliverable, and any goodwill credit to the end customer is your own choice with your client, funded on your side.

The measured figure, and why the target values are blank on purpose

You will want numbers to put against these clocks. Be careful whose numbers they are. The one service-level figure RyanFulfil has actually measured is a median first reply of 23 minutes to messages arriving inside working hours — with the honest other half of it, that about one in five in-hours messages still take more than half a day. The full basis is on the response-time answer in the FAQ. That is a first-reply figure only; it is not a dispatch target and not a resolution target.

Everything else is deliberately unpublished. RyanFulfil publishes SLA target values only after the founding pilot has measured them, rather than printing a quote-time or dispatch-time number that reads as a promise and has never been tested against a real month of volume. As an agency, copy that discipline: the framework above is publishable today because it is structural and honest; the target values are not, until you have watched your own account produce them. Promising a client a dispatch window you inherited from a provider's marketing is how you end up apologising for a number you never controlled.

Where the credit clause actually belongs

Credits are the part most likely to be copied thoughtlessly, so separate what your provider controls from what the route does. The controllable clocks are acknowledgement, the release-to-dispatch window, and the update cadence on an issue. The uncontrollable one is transit: customs holds, carrier congestion and last-mile delays are estimated per route and are not guarantees. Write any credit against the first group only.

Who carries the credit depends on your path. On a referral, RyanFulfil contracts, invoices and prices the seller, so the commitments sit in that relationship. On co-manage and white label you contract, invoice, price and take first line, so the SLA your client signs is yours to write — and the protection behind it, including how a stranded order is handled if a relationship lapses, is set out under client protection on the Agency Desk. Either way, do not offer a delivery credit you cannot recover from a carrier.

Put the four clocks in front of the client

Build these four clocks into your onboarding document, with the start and stop event spelled out for each, the working-hours note attached, and the target-value column left as "measured, publishing soon" until you can fill it from your own account. Agree the missing-info pauses before the first order so a paused clock is a rule and not a surprise, and agree the peak exception before the season, not during it. When you are ready to attach real operations behind those promises, apply to the Agency Desk and build the SLA on a backend you can actually hold to it.