Speed-to-Lead Audit

Link

2

Link Name

Speed-to-Lead

Loop Step

Diagnose

Role

audit

Purpose

Determine how quickly and consistently new inquiries receive a meaningful first response across every relevant source, channel, time period, and operating condition — so a response leak is confirmed with evidence before any SLA, script, or automation is installed.

What To Measure

The elapsed time and completeness of first response for each new inquiry, segmented by source, channel, responder, and operating condition (business-hours vs after-hours, weekday vs weekend).

Governing Principle

An automatic 'we received your form' email is NOT meaningful first contact. Measure the ladder of contact, not the auto-reply. Speed only matters if it leads to a real two-way conversation.

Contact Ladder

Note

Every inquiry is scored against how far up this ladder it got, and how long each rung took. Counting an auto-acknowledgement as 'contact' is the most common way a response leak hides.

Data To Collect

Note

One row per inquiry. Timestamps must be real system/CRM/telephony records, never estimates. Where a field is unavailable, mark it Unknown — do not guess.

Calculated Metrics

Note

Compute where the data permits. If a segment has too few inquiries to be meaningful, report the count and flag it rather than reporting a rate that looks precise. Do not report a percentile on a tiny sample as if it were stable.

Benchmark Policy

Rule

Do not fabricate benchmark thresholds. If a ShiFt-approved benchmark exists in the governing content/data layer, use it and label it explicitly as a benchmark with its source. If no approved benchmark exists, report actual performance and let the operator define the target SLA in RLR-11.

Approved Benchmarks Available

false

Fallback

Report the raw distribution (median/p75/p90 and the loss metrics). The operator sets the SLA target in RLR-11; %-within-SLA becomes computable only after that.

Leak Patterns

How To Interpret

Read speed and coverage together. Fast median response with a high %-never-attempted means you serve the leads you touch but drop many entirely. Good business-hours numbers with poor after-hours numbers is a coverage-model problem (RLR-14), not a scripting problem. Wide variance by responder is an ownership/accountability problem (RLR-15).

Action That Follows

Route each confirmed leak pattern to its repair resource(s) above, then set or tighten the standard in RLR-11 before deploying scripts (RLR-12) or workflows (RLR-13/RLR-14).

Owner

Operations or revenue leader accountable for inbound response; audit executed by whoever can pull CRM/telephony timestamps.

How To Implement

1) Export inquiries for a representative recent window with the fields above. 2) Reconstruct the contact ladder per inquiry from real timestamps. 3) Compute the metrics you have data for. 4) Segment by hours/day/source/channel/responder. 5) Tag leak patterns.

How To Test

Spot-check a random sample of rows against raw CRM/telephony logs to confirm timestamps and dispositions are accurate before trusting the aggregates.

When To Remeasure

Re-run 14 and 30 days after each Link 2 repair (RLR-42), using the same window length and segments.

How To Know It Improved

Median and p90 first-response time fall, %-within-SLA rises, and %-never-attempted / unworked counts drop — on comparable sample sizes — not merely that a workflow was switched on.

Sample Size Guidance

Report the inquiry count for every segment. Treat rates on very small segments as directional only, and prefer collecting more data over acting on an unstable percentage.

Missing Data Rules

Any unavailable timestamp is Unknown, never zero and never 'fast'. A missing first_attempt_at counts as never attempted, not as instant response. Segments dominated by Unknowns are reported as a data-quality finding that routes to tracking repair, not as good performance.