The May 7 post was about pre-closing bottlenecks — where files stall between clear-to-close and the closing table. The most common response I got was some version of “I believe you, but I don’t know where my files stall.” Fair. This is the sequel: how to instrument your own pipeline with data you already have, starting with the window most shops never look at at all — order-to-open.

The premise matters, so let me state it plainly: you don’t need new software, a data warehouse, or a consultant. Your production system already timestamps everything. Every order has a received time, an opened time, a search-assigned time, a commitment-out time, a cleared-to-close time, a closed time. The instrumentation project is not collecting data. It’s deciding to read data you’ve been collecting for years — and reading it the right way.

Why Order-to-Open First

Order-to-open — the gap between when an order arrives and when a file is actually opened and moving — is the best first target for three reasons. It’s early, so delay here propagates through everything downstream; a day lost at intake is a day lost at closing, with interest. It’s cheap to fix, in the sense that nothing in this window requires licensed judgment — no examination, no underwriting, just intake — so delay here is pure process friction rather than a hard tradeoff. And it’s invisible: turn-time conversations almost always start the clock at open, which means this window appears in nobody’s metrics. Shops measuring it for the first time routinely discover they’re losing a real fraction of their perceived “search turn time” before the search was ever assigned.

Read the Distribution, Not the Average

Here’s where most first attempts die. Someone pulls the data, computes an average — orders open in 6.5 hours — declares it fine, and stops. The average is close to useless here, because delay in an order pipeline isn’t normally distributed. It’s long-tailed: most orders open fast, and a minority sit for days. The average blends those two populations into a number that describes neither. I fly airplanes for a living, and this is the difference between average fuel burn and the burn on the one leg with the headwind — you don’t plan around the average; you plan around the tail, because the tail is what runs you dry.

So look at percentiles. If your median order-to-open is 3 hours but your 90th percentile is 2.5 days, you don’t have a speed problem. You have a stall problem affecting one order in ten — and your customers experience you through that tail, because the fast files are unremarkable and the stalled ones generate the phone calls. The whole diagnostic collapses to one question: what’s different about the tail?

That’s a segmentation question, and it’s the actual work. Cut the tail population by dimensions you already store: order source (which lender, which portal, email versus integration), transaction type, county, day and hour received, who touched it first. The tail is never uniform. It concentrates. One lender portal sends orders with incomplete legals that sit in a clarification loop. Everything received after 3 p.m. Friday waits until Monday afternoon — not Monday morning. One county’s orders stall because intake waits on a tax cert that could have been ordered in parallel. Each of these is a specific, fixable mechanism, and not one of them is visible in an average.

Two rules keep the analysis honest. Use business hours, not clock hours, or your weekend orders dominate the tail and tell you nothing. And break the window into stages as soon as you can — received-to-acknowledged, acknowledged-to-assigned, assigned-to-opened — because “orders stall at intake” is a complaint, while “orders stall between acknowledgment and assignment, on Mondays, in the refi queue” is a fix.

A Habit, Not a Project

The one-time analysis finds the current bottleneck. The recurring version keeps finding the next one, because pipelines re-bottleneck — fix intake and the constraint moves to search assignment. That’s not failure; that’s how constraints work. The sustainable form is small: a weekly report, percentiles by stage and segment, trended, read by somebody with the authority to change process. Twenty minutes a week. The shops that do it develop an almost unfair advantage in lender conversations, because they answer “what’s your turn time” with a distribution and a trend line while the competition answers with a hopeful average.

And when a fix ships, measure the same window afterward — not to celebrate, to confirm. About half of intuitive process fixes don’t move the percentile they were aimed at. Learning that in two weeks instead of two quarters is the entire return on having instrumented in the first place.

Where ElectraOne Fits

ElectraOne timestamps every stage of every file as a side effect of running your operation, and its reporting reads those timestamps the way this post describes — distributions, stages, segments — instead of burying them under an average. But I want to be honest about the order of operations: the thinking in this post works on whatever system you run today, including a competitor’s, including a spreadsheet export. The software makes the habit cheap. It doesn’t substitute for deciding to look.

Your pipeline is already telling you where it hurts. The data’s been sitting there for years, waiting for someone to read it.

See how ElectraOne reads your pipeline →