---
title: "Splitting systems delay from human delay: a working-hours speed-to-lead SLA"
type: case-study
evidence_type: proof
category: "Lead Routing & Speed-to-Lead"
publisher: "LeanScale"
date_modified: 2026-08-08
word_count: 1060
topics: ["revenue-operations", "demand-generation"]
canonical_url: https://knowledge.leanscale.team/customers/working-hours-speed-to-lead-sla-systems-vs-human-delay/
source: "LeanScale Knowledge Hub — https://knowledge.leanscale.team"
license: "Free to quote and cite with attribution to LeanScale."
---

# Splitting systems delay from human delay: a working-hours speed-to-lead SLA

**Evidence type:** proof (what happened)

A cybersecurity software company needed to prove its inbound leads were actually being worked. LeanScale measured the full lead-to-first-touch chain, redefined what counts as a first touch, and put a one-hour working-hours SLA into production with alerting and a dashboard that separates system latency from rep latency.

## The challenge

Leadership wanted to know whether inbound leads were being worked at all. There was no defined SLA — reps had blanket "try to get to your outreach within an hour" guidance with no enforcement and no measurement. Worse, nobody could say whether the delay belonged to the sales team or to the stack, because the only definition of a first touch was "an outreach sequence started." First touches that happened by phone, dialer, LinkedIn or a manually logged activity simply did not exist in the data.

## The approach

Measure before legislating
Pulled 90 days of leads out of the marketing platform across four cohorts — demo requests, contact-us form fills, free-trial signups, and purchased list pulls — and unified roughly ten thousand records into a single evaluation dataset with 26 calculated columns. Origination was derived by comparing the marketing-platform create date against the CRM lead create date, so every record could be attributed to the system it actually started in. Eight duration metrics were computed across the whole chain: create → first MQL, MQL → CRM sync, CRM create → SDR assigned, SDR assigned → first pursuing activity, and the end-to-end variants for each origination path.

Normalize to business hours, then bound the outliers
Elapsed time was recalculated against a defined working window so a lead arriving in the evening didn't get charged for overnight. Records were flagged as after-hours and as delayed-engagement (first touch on a different calendar day than creation). Outliers were bounded with an interquartile-range fence rather than an arbitrary cutoff: the middle half of responses ran from roughly fifteen minutes to a bit over two hours, which set the upper fence at about six hours. Anything past that was flagged, not deleted.

Separate 'no response' from 'no data'
A missing-pursuing flag distinguished leads old enough to have been worked but with no first-touch activity recorded (a real coverage problem) from leads that were simply too recent to judge. That one distinction is what turned the analysis from an argument into a diagnosis — a large share of the apparent slowness was activity that was happening but not being logged.

Redefine 'pursuing' as a four-channel cascade
Response time was moved off the sequence-start trigger and onto an SDR-last-activity-date stamp fed by four channels: an active outreach sequence, calls placed through the dialer, LinkedIn Sales Navigator activity, and manually logged activity. The marketing automation user was explicitly excluded so nurture email could not fake a first touch. Account-executive activity flips the record to Pursuing but is deliberately excluded from the response-time calculation, so the metric stays a coaching signal for the SDR team rather than being flattered by an AE jumping on a hot lead.

One-hour working-hours SLA in production
The routing platform's first-response timer became the SLA primitive, with per-user business-hours availability configured so the clock only runs when the rep is working. Target: one hour on MQLs during business hours, with a 24-hour fallback for off-hours and weekend arrivals. Demo requests and free-trial fills were designated highest priority. Breach alerts fire to the assigned rep and their manager — throttled to MQLs only, and triggered off the business-hours response-time field rather than a naive timestamp, because the first version ran on raw timestamps and flooded a manager's inbox over a weekend.

Scope the SLA deliberately narrow
No SLA was placed on list-pull and scaled prospecting work — different reps batch their prospecting on different days and a timer would have penalized legitimate workflow variance. A marketing-side workflow delay of roughly thirteen minutes on one trial path was measured, judged acceptable inside a one-hour SLA, and explicitly left alone rather than becoming a project.

A dashboard built around the two numbers that have different owners
Six-row CRM dashboard: executive KPIs (average speed to lead, average systems delay, average human delay, SLA hit rate); weekly trend lines for speed to lead and SLA hit rate; per-rep SLA hit/miss and average human delay; breakdowns by lead type; a systems-delay diagnostics row including marketing-platform-to-CRM sync time by week; and two drillable hygiene tables — leads missing first-touch activity older than two days, and a past-SLA no-follow-up escalation queue. Supported by a small set of formula fields on the lead object and the underlying reports behind each card. The design principle: if systems delay is high, it is an ops problem; if human delay is high, it is a coaching problem; a single blended number lets both sides blame the other.

The hold-list exception the SLA could not see
The SLA and a 30-day activity-decay rule together kept auto-deprecating records that reps were intentionally holding for a future follow-up. Built a five-field schema, identical on lead and contact: a restricted reason picklist (qualified future follow-up / high-intent inbound / reschedule) with field-history tracking, an added date that auto-stamps on any reason change, a follow-up date made visible and required only for the future-follow-up reason via dynamic forms plus a validation rule, a notes field, and an added-by user lookup. The high-intent reason stamps automatically on demo-request conversions, sequenced to fire after routing completes so the owner recorded is a real rep and not a routing placeholder. Clearing the reason auto-clears the dates and owner but preserves notes as history, and lead-to-contact conversion carries all five fields. A one-line exclusion in the decay flow stops flagged records from being deprecated.

## Outcomes

A one-hour SLA that actually runs
Live in production, calculated inside business hours, with breach alerts routed to both the assigned rep and their manager.

A defensible baseline instead of an argument
The 90-day study produced median response time by lead source, a bounded outlier definition at roughly six hours, and a coverage number for how many leads had no logged first touch at all.

Delay attributed to the right owner
Separating systems delay from human delay showed the longest lags sat on the CRM side after the marketing sync, largely driven by how narrowly a first touch had been defined — not by reps sitting on leads.

The manual workaround got a home in the CRM
A manually maintained hold list moved off a spreadsheet into a structured, reportable field set that the decay automation respects.

Known gaps carried honestly
At last review the response-time dashboards still had missing data points, and the response-time fields were still owed on the rep-facing record page layouts. Both remained open items rather than being quietly closed.

## Quotes

> In theory, the lead routing was right, but like, that original person had that great conversation that they were supposed to follow up in six months, but they just so happened to come back a little sooner.
>
> — Customer, SDR Manager


## Canonical

https://knowledge.leanscale.team/customers/working-hours-speed-to-lead-sla-systems-vs-human-delay/