SetScale

Lead response time SLA: 7 rules a team can hold

August 5, 2026·14 min read
Woman in her early thirties running the response time board of a small sales team, dark curly hair, ochre knit sweater, standing at a wooden counter in a warm loft office with a brick wall and a round wall clock, morning light through a large window

A lead response time SLA is a written promise about one thing: how fast a new inbound lead gets a real first reply, measured per source, per account and per shift, with a named owner when the promise is missed. Most teams write it as a single number, put it on a slide, and break it the first Saturday night.

This one is written for the person who runs several client accounts or several closers and has to defend that promise in a client review: an agency owner, a head of sales, an ops manager. Below you get the two clocks that Meta documents publicly and that your SLA does not get to negotiate, seven rules that survive a real week, and a starting table you can copy. You will not find the famous five minute statistic here, because you cannot verify it and you do not need it. Rule 6 shows how to measure your own number instead.

TL;DR

  • An SLA is a threshold plus a scope plus a measurement method plus a consequence. A number alone is not an SLA, it is a wish.
  • Two platform clocks bound the promise. Meta states that businesses "have up to 24 hours to respond to a user" on the Messenger Platform, and that the Human Agent tag allows manual replies "within a 7-day period".
  • WhatsApp runs its own timer: a 24 hour customer service window opens when the user messages you, and once it closes you can only send pre approved templates.
  • Coverage beats typing speed. Nights, weekends and setter handoffs cause more breaches than slow replies do.
  • Report attainment per client account, not as an agency average, or one account's failure will keep hiding inside another's success.

Table of contents

What a lead response time SLA actually promises

SLA stands for service level agreement: a commitment about the level of service, written down, with what happens when it is not met. A usable lead response time SLA has four parts, and most internal ones only have the first.

The threshold is the target time. The scope says which leads it applies to, on which accounts, during which hours. The measurement method says when the clock starts, when it stops, and which statistic you publish. The consequence says who is notified, who fixes it, and what the client is told. Drop any of the last three and you have a number that nobody can be held to, because every breach can be argued away.

First response time is the metric underneath it: the delay between the first inbound message of a new conversation and the first reply that a human would call an answer. Keep that definition close, because rule 2 is entirely about defending it from your own dashboard.

Teams that already run several closers off one shared pipeline usually discover that the SLA is not a speed problem at all. It is a coverage and ownership problem wearing a stopwatch.

The clocks you do not control

Before you promise anything to a client, note the limits that the platforms publish. On the Messenger Platform, Meta's policy overview states that businesses "have up to 24 hours to respond to a user", and that message tags "include a Human Agent tag that allows businesses to manually respond to user messages within a 7-day period" (page checked on 5 August 2026).

WhatsApp runs a separate timer. The Cloud API documentation is explicit: "When a WhatsApp user messages you or calls you, a 24-hour timer called a customer service window starts", and "When the window closes, you can only send pre-approved template messages."

Read that as an operations constraint, not a legal footnote. A reply at hour 25 is not a late reply, it is a different object: a pre approved template, with its own approval flow, its own tone, and its own cost line. An SLA that sits at 20 hours is not "inside the window", it is one bank holiday away from turning your whole pipeline into template traffic.

Two practical consequences. Set your internal target far enough inside the window that a weekend cannot push a conversation past it, and re read the official pages before you copy any of this into a client contract: Messenger Platform policy overview, WhatsApp Cloud API messages guide and the Instagram messaging documentation hub. These windows are Meta's to change, not yours.

The test: if your SLA and the platform window are the same number, you do not have an SLA, you have a deadline you will miss.

Rule 1, one SLA per source and not one number for everything

A lead who just clicked a paid ad and a lead who answered a three week old thread are not in the same state of mind, and they should not share a target. One number for everything means you either overspend on cold sources or quietly fail the hot ones.

Start from a grid like this one, then overwrite every cell with your own numbers once rule 6 gives them to you.

Lead source First reply target to start from Hours you cover Named owner
Click to message ad, campaign live minutes ad schedule plus one hour setter on shift
Comment turned into a private message minutes posting schedule setter on shift
Organic DM on a client account under one hour that client's business hours account setter
Inbound form or email same business day business hours setter, then closer
Reactivation of a dormant thread next business morning business hours closer

The paid rows are tight for a reason: you are paying twice for that attention, once for the click and once again if the lead has to be re warmed. The bottom rows are loose for the same reason in reverse. If you run this across several client accounts at once, the grid gets one column per account rather than one line for the agency.

Anyone comparing this internally against buying the coverage outside will want the arithmetic in the three routes for appointment setting: agency, in house team, or software. The SLA is the part of that decision people forget to price.

Rule 2, agree where the clock starts and stops

Half the SLA arguments in an agency are definition arguments. Settle them in writing, once.

The clock starts on the first inbound message of a new conversation, not on every message in a thread. Otherwise a chatty prospect can generate a dozen technical breaches while being perfectly well served. Define what makes a conversation new: a common rule is that a thread dormant for 30 days restarts the clock.

The clock stops on the first reply that moves the conversation forward. An automatic acknowledgement does not stop it. This is the single most common way teams get a green dashboard and a dead pipeline: the bot says "thanks, we will get back to you", the metric is satisfied, and the human shows up nine hours later.

Business hours belong in the definition too, per account and per timezone. A client in another country either buys coverage in their hours or accepts the delay, in writing, before the first breach conversation happens rather than during it.

The test: hand your definition to two setters, have them time the same five conversations, and compare. If the numbers differ, the definition is not finished.

Building that promise on top of an AI setting layer that spans every account you run only helps once the definition is stable. Automate an ambiguous metric and you industrialise the ambiguity.

Rule 3, staff the calendar and not the average

Breaches are not spread evenly, they cluster. Friday evening to Monday morning, lunch, the handoff between two setters, the week someone is away. An average over a month erases exactly the hours where you lose the deal.

So publish a rota, not an intention. Who covers which hours, on which accounts, and who is the fallback. Then write the handoff protocol: what the outgoing setter leaves in the thread, in which field, so the incoming one does not restart the qualification from zero. Teams that run closers with genuinely full calendars treat that note as part of the shift, not as an afterthought.

One honest question to answer before you promise weekend coverage: is the extra revenue worth the shift, or would you rather state clearly that inbound after Friday 18h is answered Monday morning? Both are defensible. Only the unwritten version is not.

Ready to run this on every client account at once? Join the waitlist and we will tell you when SetScale opens.

Rule 4, give every breach an owner and a deadline

An SLA without a consequence decays in about three weeks. The consequence does not have to be punitive, it has to be procedural.

Fifteen minutes a week is enough: pull every conversation that breached, sort by cause, and assign one action per cause. Four causes cover almost everything. Coverage, meaning nobody was on shift. Tooling, meaning the notification never arrived. Ambiguity, meaning two people thought the other one had it. Volume, meaning a campaign spiked and the rota did not.

Note the cause, not the person. Naming an owner is about who fixes the cause by when, not about who was slow on a Tuesday. The moment the review becomes a blame meeting, your setters will start closing conversations to protect the metric, and you will have optimised for a number instead of a pipeline.

Rule 5, report attainment per client account

This is the rule that agencies pay for and skip anyway. An agency wide attainment of 94 percent can hide one account sitting at 71 percent, and that account is the one whose contract is up for renewal.

Publish, per account and per month: volume of new conversations, attainment against the target, the worst hour of the week, and the count of breaches with their causes. That is a page, not a dashboard project. It is also the difference between a service that gets renewed and a service that gets audited.

If you resell this under your own brand, the reporting is the product as much as the replies are. The mechanics of packaging it sit in the white label DM automation playbook, and the tooling side of that bill is worth checking against what an all in one platform really costs an agency before you commit to a price per account.

Rule 6, measure your own baseline instead of quoting a famous number

There is a very well known figure in this industry about replying within five minutes. It is not quoted here, on purpose. The studies behind it are old, several were funded by vendors selling speed, and they describe web form leads in a market that is not yours. Repeating it in a client deck means being asked for the source, and the source will not survive the question.

Your own baseline takes an afternoon and beats it for every practical purpose.

Export the last two weeks of conversations per source. Compute first response time for each new conversation using your rule 2 definition. Then publish two statistics, never the mean: the median, which tells you what a normal lead experiences, and the 90th percentile, which tells you what your worst leads experience. The gap between them is your real operations problem.

Set the first SLA at your current 90th percentile. Yes, that feels unambitious. It also means you hit it, which is what makes the whole thing credible internally. Tighten it one step per quarter, and only when the previous step has held for a full month.

The test: if you cannot produce last month's median and 90th percentile in under an hour, your measurement method is the thing to fix, not your response time.

Rule 7, automate the first touch and keep humans on the judgement calls

Automation is what makes the first minutes possible at all, across accounts, at night, during a campaign spike. It acknowledges, asks the two or three qualifying questions that never vary, and books the obvious cases. That is where the clock is won.

Judgement stays human: the objection with a real story behind it, the budget conversation, the borderline fit you would rather turn down than take. A setter who spends the day copying the same three opening lines is expensive; a setter who spends the day on the ambiguous half of the inbox is not.

Two cautions worth writing into the same document. Tone: an instant reply that reads like a machine costs you more than a slower human one. Compliance: opt in, traceability and the messaging windows are yours to respect, and the official documentation linked above is the only reference you should be quoting on that.

Where SetScale fits

SetScale is an AI setter built for teams and agencies rather than for one inbox: several client accounts, several closers, reporting per seat, with a white label option planned. The rules above are the reason it exists in that shape, because the hard part of response time at scale is not writing faster, it is covering every account and proving that you did.

To be straight about the state of things: the product is not open yet. The only action available today is joining the waitlist. A 7 day free trial (card required) is planned at opening. There are no customer numbers on this page for the same reason.

If your response time promise currently lives in a slide instead of a rota, start with rule 6 this week and rule 1 next week. Those two cost you nothing and change what you are able to promise. Join the waitlist to hear when the rest is available, or read how the whole setting layer is meant to fit together on the SetScale approach.

FAQ

What is a good lead response time SLA? The one you hit at least nine times out of ten, derived from your own 90th percentile, and set comfortably inside the platform windows. A target you miss weekly is worse than a slower one you always hit, because it teaches everyone that the SLA is decorative.

Should the SLA be the same for every client account? No. Volume, hours and lead sources differ per account, so targets and owners do too. Keep the measurement method identical across accounts, which is what makes the reporting comparable.

What happens if we answer after 24 hours on Instagram or WhatsApp? You leave the standard window. On the Messenger Platform, Meta documents a Human Agent tag for manual replies within a 7 day period; on WhatsApp, once the 24 hour customer service window closes, only pre approved templates can be sent. Check the official pages before relying on either.

Do nights and weekends belong in the SLA? They belong in it explicitly, either as covered hours with a rota or as excluded hours stated in writing. The failure mode is leaving them unmentioned and discovering the client assumed coverage.

Who owns the SLA inside an agency? One named person per account for the daily promise, and one ops owner for the method, the weekly breach review and the monthly report. Two roles, both named, or the SLA belongs to nobody.

Conclusion

Pick the two rules you can apply before the end of the week: measure your real median and 90th percentile, then split your single target into one target per source. Everything else in this article is easier once those two numbers exist, and most of it is impossible before.

Then decide the uncomfortable one on purpose: which hours you genuinely cover, and what you tell clients about the hours you do not. That sentence, written down and honoured, is worth more to a renewal than any figure on a slide. Join the waitlist if you want the AI setting layer that is being built to hold it across every account you run.