“We’ll jump on deliverability issues fast” is not an SLA. It’s a hope, and clients who’ve been burned by a previous agency or in-house team tend to ask for something more specific during procurement — a defined detection time, a defined response time, and a defined communication cadence when something breaks. Agencies that can’t produce that specificity lose the deal to ones that can, even if the actual quality of the work is comparable.

Run a free audit → — paste your email headers and see every failing check, with the fix for each. No account.

The Three Things an SLA Should Actually Commit To

1. Detection time — how long between an incident starting and someone (or something) noticing. This is largely a function of monitoring cadence, not effort: a tool polling hourly detects faster than one checked manually once a week, independent of how good your team is.

2. Response time — how long between detection and a human acknowledging the issue and starting to investigate. This is the number clients usually care about most, and the one most within an agency’s direct control — it’s a staffing and process commitment, not a technical one.

3. Communication cadence — how often the client hears something while the incident is open, even if there’s no resolution yet. A client who hears nothing for three days assumes nothing is happening, even if someone’s actively working the cause. A committed update cadence (every 24 hours, every business day, whatever’s realistic) prevents that assumption regardless of actual progress.

The One Thing an SLA Should Not Promise

Inbox placement percentage. This is the overcommitment that shows up most often in agency sales conversations, and it’s the one that causes the most damage when a client holds the agency to it later. Placement rate depends on mailbox-provider policy (outside anyone’s control), the client’s own list quality and sending behavior (the client’s responsibility, not the agency’s), and content/engagement signals that compound over time rather than responding instantly to a fix. An agency that promises “95% inbox placement” in an SLA is promising an outcome it doesn’t unilaterally control — a placement dip caused entirely by the client’s own list decay still reads as an SLA breach the client will point to.

The honest version: commit to the process (detection, response, communication) and be explicit in the SLA language that placement outcomes depend on factors the agency monitors and advises on but does not solely control.

A Practical SLA Structure by Tier

Most agencies that formalize this end up with two or three tiers rather than one blanket commitment:

  • Standard: detection within the monitoring tool’s normal interval, human acknowledgment within 4 business hours, update cadence of one check-in per business day while an incident is open.
  • Priority (paid add-on or higher retainer): detection within the hour via real-time monitoring, acknowledgment within 1-2 hours including some after-hours coverage, update cadence of every few hours during an active incident.
  • Enterprise / custom: negotiated individually, usually tied to a named on-call contact and sometimes a phone escalation path rather than email/Slack only.

Tying the tier to actual monitoring capability matters — promising 1-hour detection on a tool that only polls daily isn’t a tier difference, it’s a commitment the underlying process can’t meet.

Tracking Whether You’re Actually Meeting It

An SLA nobody tracks is a marketing line, not a commitment. At minimum, log three timestamps per incident: when it was detected, when it was acknowledged, and when the client was first notified. Without a tool that does this natively, a shared spreadsheet works for a handful of clients — past that, manually maintaining accurate timestamps across every open incident becomes its own source of error, which is the point most agencies move to a platform with built-in incident tracking and multi-client visibility (InboxStack’s Command tier supports custom SLAs alongside multi-tenant workspaces, purpose-built for tracking this per client rather than per spreadsheet row).

Frequently Asked Questions

What should a deliverability SLA actually cover?

Three things, specifically: detection time (how fast an incident is identified after it starts), response time (how fast a human acknowledges and begins investigating once detected), and communication cadence (how often the client gets an update while the incident is open). It should not promise a fixed resolution time, since root cause and fix time vary too much by incident type to responsibly commit to a number.

Should agencies promise inbox placement percentages in an SLA?

No — this is the most common overcommitment in the space. Inbox placement depends on factors outside any agency’s or tool’s control (mailbox provider policy changes, a client’s own list quality, a client’s content choices). An SLA can commit to monitoring, detection speed, and response process. It cannot ethically commit to a placement rate outcome, because no one controls that outcome unilaterally.

What’s a reasonable response-time commitment for a deliverability incident?

It depends on monitoring cadence and team size, but a common structure is: automated detection within the monitoring tool’s normal polling interval (often within the hour for real-time tools, daily for others), human acknowledgment within 4 business hours for standard-tier clients, and 1-2 hours for a premium or enterprise tier willing to pay for it. Anything faster than automated detection allows is a commitment the process can’t actually back up.

What happens if the agency’s tool doesn’t support custom SLA tracking?

The SLA still exists as a commitment to the client, but tracking whether it was actually met becomes a manual log — timestamping when an alert fired, when someone acknowledged it, and when the client was updated. That’s sustainable for a handful of clients and becomes its own operational burden past that, which is usually the point an agency looks at tools with built-in SLA tracking instead of a spreadsheet.