Who owns a lead nobody touched: defining first response, a single-owner record, an escalation ladder on a clock, and a clean handback to a named person.
Key takeaways
- "First response" has to be defined as an observable action rather than a feeling. A call that connected, a message that was delivered, a meeting that was booked - not "I saw it".
- One owner at a time. Two people responsible for a lead is functionally the same as nobody, because each assumes the other handled it.
- An SLA differs from an internal target by having a consequence. Google's SRE book gives the test: if there is no explicit consequence for missing it, you are looking at an objective, not an agreement.
- Escalation transfers ownership rather than adding recipients. The familiar on-call pattern applies: each level has a timeout after which the item moves to the next level.
- A lead returned to the queue arrives with history: who held it, what was tried, and why it came back. Without that the next person starts from zero and opens with the same script.
An unanswered lead is not an alerting problem, it is an ownership problem. Every lead has exactly one owner at any moment, a clock that starts the instant it is written, and an escalation ladder that moves ownership to a different person when the clock expires. Without all three, another alert only adds noise.
What counts as a first response, and what definitely does not
A vague definition is what turns every SLA discussion into an argument. A good one answers three questions: which action counts, when the clock starts, and when it stops.
- What counts: an outbound call that connected, a WhatsApp or SMS message that was delivered, a personally sent email, or a meeting placed in the calendar. An action the system can observe.
- What does not count: opening the record, reading the message, changing a status, adding a tag, or setting yourself a reminder for tomorrow.
- When the clock starts: the moment the lead is written to the system, not the moment somebody noticed it.
- When it stops: at the first action that counts. A call that rang out does not stop it, but it is recorded as an attempt.
- What happens outside working hours: the clock is either paused or running, but the decision is made in advance and written down. A lead that arrives on Saturday evening should not appear as a breach on Sunday morning if the rule says the clock is paused.
The pause-or-run distinction generates most of the disagreement between management and the floor. Settle it once rather than re-litigating it in every report.
The ownership record: what is stored on the lead
| Field | Example value | Why it exists |
|---|---|---|
owner | Dana L. | The single person responsible right now. Never a team, never a list |
owner_since | 2026-09-21T09:14:00+03:00 | When ownership began. The base for the next breach calculation |
first_response_due | 2026-09-21T09:29:00+03:00 | The target, computed once rather than recomputed on every query |
first_response_at | Empty until an action that counts | What stops the clock |
escalation_level | 0 | Where on the ladder this lead currently sits |
attempts | 2 | How many attempts were made, including ones that went unanswered |
returned_from | Uri K. | Who held the lead before the escalation |
return_reason | Not reachable, two calls unanswered | What the next person needs before picking up the phone |
Those last two fields are the difference between escalation that works and a shifted blame. A lead handed to a new person with no return_reason produces the experience every customer recognises instantly: the second call opens exactly like the first.
Who owns a lead nobody claimed?
The system does, and only briefly. A lead with no owner is an illegal state that should exist for seconds between the write and the assignment. Three assignment methods, each with a cost:
- Rule-based assignment. Source, region, service type or language determines the owner. The most predictable, and the one that needs the rules maintained.
- Round-robin by availability. Spreads load, ignores specialisation, and produces calls where the rep cannot answer the question.
- Self-claim from a pool. Fast when the team is alert, and produces orphaned leads exactly during the hours the team is busiest - which are the hours that matter.
The method matters less than the rule above it: if nobody has claimed the lead within a short fixed interval, the system assigns it by force and marks the assignment as forced. Force-assigned leads are the metric that tells you whether a self-claim model is genuinely working for you.
The escalation ladder: what happens at each breach
The pattern comes from on-call systems: each level has a timeout after which the item moves to the next level. In PagerDuty, for example, the default escalation timeout is 30 minutes, with a documented minimum of one minute for a single target. The values below are an example for sales, not a standard.
| Level | When | What happens | Who holds ownership |
|---|---|---|---|
| 0 | On arrival | Automatic assignment, clock starts | The assigned owner |
| 1 | +15 min | Personal reminder to the owner only | Unchanged |
| 2 | +30 min | Lead returns to the open pool, marked as a breach | Pool, then force-assigned |
| 3 | +2 hours | Raised to the team lead with the return_reason | Team lead |
| 4 | +24 hours | Enters the daily unhandled-leads report | Held, flagged for review |
Look at level 2. It reads as harsh, and that is the point: a reminder resent to the same person is not escalation, it is noise. Real escalation changes who is responsible, which is why it is measured in leads that changed owner rather than in alerts that were sent.
Related: automating lead routing, automating lead follow-up, traffic without leads.
What happens when the owner is genuinely unavailable?
This is where most processes come apart, because planned and sudden absence need different behaviour.
- Planned absence. Ownership passes to a named stand-in in advance, and the system stops assigning new leads to anyone flagged unavailable. A lead assigned to somebody on holiday is a breach you created on purpose.
- Sudden absence. The escalation ladder handles it with no special case. That is precisely why the ladder is driven by time rather than by a human acknowledgement.
- Return from absence. Leads do not flow back automatically. Whoever took ownership keeps it until they hand it back explicitly, otherwise two people call the same customer on the same day.
- A load spike. A campaign that triples inbound volume produces breaches at every level. The fix is not to relax the SLA that day, it is to increase the number of available owners - otherwise the metric stops describing reality.
The four numbers you report, and no more
Google's SRE book argues for a small number of indicators, on the basis that choosing too many makes it hard to pay attention to the ones that matter. The same logic applies here:
- First-response attainment. The share of leads that received a counting action inside the target.
- Median response time, not the mean. One lead that sat for three days distorts an average and hides twenty leads answered in seven minutes.
- Leads escalated to level 2 or beyond. This is the number that points at the person, the hour or the source where the system breaks.
- Escalated leads that closed the loop. How many escalated leads eventually received a response. Escalation that never ends in a response is just an orderly way to lose a lead.
The rule behind that list: an SLA with no consequence is an objective. The SRE book offers a simple test - ask what happens if the objective is not met; if there is no explicit consequence, it is an objective rather than an agreement. In internal sales the consequence is not a penalty, it is a change of ownership, and that is exactly what the escalation ladder implements.
Sources
Frequently asked questions
Should the SLA be identical across every lead source?
Usually not. A lead from a "call me now" form and a lead from a guide download do not carry the same urgency, and one shared SLA makes the first look permanently in breach and the second permanently fine. Set a target per source and measure each source separately.
What do we do with a lead escalated twice and still unanswered?
Take it off the ladder and put it on a separate track that ends in a human decision: a reasoned close, an attempt on a different channel, or a dated future callback. A lead that circulates on the ladder forever produces alerts everyone learns to ignore, and that is what kills the whole process.
Should the customer be told nobody has answered yet?
An automatic acknowledgement on arrival is not a first response and does not stop the clock, but it does change the waiting experience. What you must not do is count it as a response, because attainment then reads 100% while nobody is speaking to anyone.
How do we stop the metric from producing tick-box behaviour?
By making the counting action one the system observes rather than a manual status change. A call logged by the phone system, a delivered message, or a meeting on a calendar are hard to fake. The moment the metric depends on a manual flag, it measures the flag rather than the response.
Keep reading
Related service
Custom CRM
A CRM built around your pipeline, connected to the tools you already use.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.