Use the same start event, attempt definition and clock across locations. Different definitions can make otherwise identical response times look different. This guide covers how to measure; for what target to set and what the first call should say, read the guide to calling a new lead.
What exactly are you measuring?
Write these four definitions down before pulling any data, and use the same ones at every location.
The start. The timestamp the lead record was created, in the system where leads land. Not the time somebody noticed it. Not the time it was assigned.
The end. The first outbound attempt to that person: a dial, a text, or an email, whichever came first. An attempt is an attempt whether or not anyone answered.
The clock. Use elapsed wall-clock time. A lead that arrives at 9pm and gets a call at 9am waited 12 hours. A business-hours clock measures a different interval and should be labeled separately. If you want to understand staffing, measure business hours as a second column, never as the headline.
The unit. Minutes, everywhere. Locations that report in hours and locations that report in minutes cannot be compared without someone doing conversions, and conversions invite errors.
Why the median and not the average?
A long delay can pull the mean well above the median. Both measures describe the data, but answer different questions. The median shows the middle attempted lead; the mean and slow-tail measures help reveal longer waits. Neither describes leads that received no attempt, so report those separately.
Report both of these instead, and the picture holds up:
- Median time to first attempt. The typical experience.
- Share attempted inside 5 minutes. The share that got the fastest first attempt.
Then keep one count beside them, because it shows leads the timing numbers leave out: leads with no attempt at all. Those leads are excluded from any timing calculation, which means a location can improve its median by ignoring more leads. Publishing the count closes that door.
What does the export look like?
Request six columns with one row per lead. Verify what your system exports and reconcile missing fields before calculating response time.
| Column | Where it comes from | Why it is there |
|---|---|---|
| Lead id | Lead record | Lets you go back to the specific lead |
| Location | Lead record | The unit of comparison |
| Created at | Lead record, with time zone | The start of the clock |
| Source | Lead record | Web form and phone leads may behave differently |
| First outbound attempt at | Call log or message log | The end of the clock |
| Attempt channel | Call log or message log | Tells you what the location actually does first |
Time zone is not a detail. A multi-location export that mixes local time and UTC produces response times that are hours out, and the error looks exactly like a genuinely slow location.
How do you calculate it?
Calculate elapsed minutes after checking timestamps and duplicates.
Add a column for minutes elapsed: first attempt time minus created time, converted to minutes. Filter out rows with no first attempt and count them separately. Then, per location, take the median of that column, and the share of rows at or under 5.
Hypothetical calculation: eleven attempted leads have elapsed times of 2, 3, 4, 6, 9, 14, 22, 41, 95, 310 and 1,190 minutes. The median is 14 minutes; the mean is 1,696 / 11, or about 154.2 minutes. Three of eleven attempts occurred within five minutes, or 27.3%. The median describes the middle observation; the mean reflects the long delays too. Keep the slowest cases and leads without any attempt visible alongside both.
Which target should you compare against?
Choose the target in one place and measure every location against it. The guide to calling a new lead discusses a five-minute example target during approved contact hours and why it is a working target rather than a benchmark.
What goes wrong with this measurement?
Six failures, all worth checking before you trust a number.
Bulk imports. A list of 400 names imported on Tuesday creates 400 lead records with the same timestamp and no real arrival time. Exclude imported leads or measure them separately.
Duplicates. The same person filling in two forms creates two records. The second may get no attempt, because the first is already being worked, and it drags the no-attempt count up.
Automatic replies counted as attempts. If an automated confirmation counts as the first attempt, every location scores under a minute and the measurement stops describing human follow-up. Decide explicitly whether automated messages count, and apply the answer everywhere.
Attempts logged in batches. A staff member who makes six calls and logs them at the end of the shift makes response time look worse than it was. This one is often visible as a cluster of identical timestamps.
Time zone drift. Check that timestamps refer to the same time standard before subtracting them.
Definition drift. Someone changes what counts as an attempt to make a target easier. Keep the definitions in one written place and date them.
How often should you look?
Monthly for the table, weekly for the no-attempt count. The monthly table is for deciding things. The weekly count is an operational alarm, and it works because it is a single number that anyone can read in five seconds. To put the timing next to bookings and attendance for each location, use the guide to finding follow-up gaps across locations.
Look at the same window every time. Comparing a four week month against a five week one is a small error that produces confident, wrong conclusions.
The definitions still belong to you. A number is only comparable because someone wrote down what it means and made everyone use it.
Where does a system like Fynso fit?
When follow-up runs through Fynso, the first attempt is made the same way at each location that uses it. Lead follow-up is live in supported configurations: a text or call when a lead arrives, within the contact hours and cadence each location approves, booking against real availability and handoff to a named person. Every attempt and outcome is recorded as it happens, in one format across locations, with bookings checked against the booking system rather than counted from replies, so the timing columns above come from the record. Confirm which exports and reports are available for your setup.