Should you set an onboarding SLA?

Last updated 19 August 2026

Yes, but commit only to what you control. An SLA on total onboarding duration will be broken by customer-side delays and quietly abandoned. An SLA on your own response and turnaround times is keepable, meaningful, and does more for the customer's confidence than a date nobody can hold.

Why do onboarding SLAs usually fail?

Because they are written against the wrong thing. A commitment to have a customer live within thirty days assumes you control the thirty days, and you do not — access, security review, data and the customer’s own competing priorities sit outside your team and routinely account for most of the elapsed time.

What follows is predictable. The date is missed for reasons that are genuinely not your fault, the SLA is quietly stopped being mentioned, and the organisation learns that its published commitments are aspirational. That last effect is the expensive one, and it outlasts the SLA itself.

What can you actually commit to?

Commitment	Controllable?	Worth publishing
Contact within N business days of signature	Yes	Yes
Kickoff scheduled within N days	Yes	Yes
Turnaround on a configuration request	Yes	Yes
Blocker escalated within N days	Yes	Yes
Go-live within N days of signature	No	—
Go-live within N days of dependencies met	Partly	Yes, if the dependencies are named

The last row is the useful compromise. It gives the customer a real number and makes the conditions explicit, which has the side effect of telling them exactly what to prioritise.

How do you handle a paused clock fairly?

Decide the rule in advance and make the state visible while it is happening. A clock that pauses when a dependency is marked blocked, in a plan both sides can see, is a mechanic the customer can watch operating — and can dispute at the time, which is when disputes are cheap.

A clock that is reconciled at the end, when you explain that eleven of the days were theirs, is a different conversation entirely. The facts may be identical; the credibility is not.

Does an SLA change customer behaviour?

Usually yes, and in a direction that helps you. A published commitment on your side raises the implicit expectation on theirs — a customer who knows you will turn a request around in two days is more likely to get their part done, because the delay becomes visibly theirs.

This is the strongest argument for an SLA that has nothing to do with the SLA. It converts a vague joint project into one with a rhythm, and rhythm is most of what keeps an onboarding moving.

What should a small team do?

Start with one commitment, the first-contact one, and meet it every time. It is the cheapest to keep, it lands at the moment the customer is most anxious — just after signing, before anything has happened — and it is the one whose absence is most noticed.

Add the others when the first has been kept for a quarter. An SLA you meet consistently is worth more than three you meet occasionally.

Common questions

What should an onboarding SLA cover?

Your responsiveness, not the end date: time to first contact after signature, turnaround on a configuration request, how quickly a blocker gets escalated. Each is inside your control, each is measurable, and together they cover most of what a customer is actually anxious about.

Can you commit to a go-live date at all?

You can commit to one conditional on named dependencies — "live within four weeks of receiving access and sign-off" is a real commitment. What fails is an unconditional date, because it makes you accountable for a process substantially run by someone else.

What happens when the customer causes the delay?

The clock should pause, and both sides should have been able to see it pause. That only works if the dependency was named and visible beforehand — retroactively attributing a delay to the customer is an argument, whereas a shared plan showing a two-week wait is a fact.

Should the SLA be in the contract?

Rarely necessary and often unhelpful. A published standard you consistently meet builds more trust than a contractual clause with a remedy attached, and it can be improved without a negotiation. Enterprise procurement may insist, in which case keep it to the responsiveness measures.

What if you miss it?

Say so before the customer notices, with the reason and the new date. An SLA missed and flagged is a process working as intended; an SLA missed and discovered is worse than having had none, because you have now taught them not to trust the next commitment either.