Every broker carries a mental league table of lender speed — built from memorable disasters, three-month-old anecdotes, and the last BDM lunch. It's folklore, and folklore fails exactly when it matters: on the tight closing where you promised “usually two or three days” from memory, in the season when everyone's queue doubled and yours was the last to know.
The fix costs thirty seconds per file: four timestamps in a simple log. Within a quarter you own something almost no competitor has — current, personal, per-lender turnaround data — and every expectation you set starts sounding like this: “based on my last six files with this lender, expect four business days.” Here's the whole system.
Step 1. Track four timestamps per file — no more
Worksheets die of ambition, so this one tracks the minimum that produces the insight: (1) Submitted — the moment the complete package leaves for the lender; (2) First response — approval, decline, or first document request; (3) Conditions cleared — the last condition confirmed accepted by the lender; (4) Final instruction — documents to the lawyer / broker copy issued. Alongside them, four context columns: lender, product type (purchase / refinance / switch), month, and a notes cell for anything unusual.
Keep it honest: log timestamp 1 only when the package was genuinely complete — a bounced file for missing pages is your turnaround problem, not the lender's, and the fix for that lives in the pre-submission checklist.
Step 2. Build the log in ten minutes
A spreadsheet with eight columns is the entire build: the four timestamps, the four context columns. Add two computed columns — days to first response (timestamp 2 minus 1, business days) and days to clear-to-close (timestamp 3 minus 1) — and you're done. Put it wherever your file tracker already lives so it gets filled at the moments the events happen, not reconstructed at month-end from memory, which is the folklore machine you're replacing.
If a fulfillment associate runs your process lane, the log is naturally theirs to maintain — the timestamps are all events they touch anyway, which makes the tracker a free by-product of a well-run pipeline.
Step 3. Read it quarterly: medians, seasons, drift
Each quarter, take twenty minutes: median days to first response per lender (medians, not averages — one disaster file shouldn't define a lender), medians by product type (switches often run on different rails than purchases), and the trend against last quarter — drift is the real intelligence, because a lender whose median slid from three days to seven is telling you about their current queue long before your BDM does.
Small samples are fine — six files with a lender beats zero data and beats folklore. Just weight your confidence accordingly and note it: “runs about four days, though I've only got a handful of recent files there” is exactly the calibrated honesty clients trust.
Step 4. Put it to work in three places
- →Client expectations: replace “usually pretty quick” with “my last six files here: about four business days to a response.” Data-backed expectations are the backbone of the update cadence in the underwriting communication article — and they make your “this is normal” messages genuinely credible.
- →Lender choice on tight files: when a closing is compressed, current speed is a legitimate selection factor alongside rate and fit — and you're the broker who actually knows it, which is a real edge in a renewal year full of date-sensitive switches.
- →Condition and closing timing: your buffer math — how much runway a file needs between approval and completion — stops being a guess and starts being a percentile.
One boundary: the tracker is decision support, not a public scoreboard. Lender relationships matter, queues fluctuate, and your sample is yours — use the data to serve clients and manage files, not to editorialize.