How Many Approved Carriers Answered Before the Cutoff?
Key Takeaways
- Quote coverage by cutoff is the share of approved carriers asked on a load that returned a valid quote before the booking decision had to be made.
- Calculate it per load first, then roll it up by lane; an average across all loads hides the thin ones.
- Count only valid quotes: from an approved carrier, matching the shipment, complete enough to compare, and received before the cutoff.
- Read coverage next to response rate and follow-up count to tell a thin carrier list from a follow-up gap or a bad quote request.
- Wilson, by Cartage, records every quote request, follow-up and reply on the shipment, and can produce carrier-performance or lane reports from that data on request.
What is quote coverage by cutoff, and why measure it?
Quote coverage by cutoff is the number of valid quotes a load received from approved carriers before the booking decision, divided by the number of approved carriers asked. It answers a plain question: when the team had to book, how much real choice did it have?
Average response time does not answer that. If one carrier replies in ten minutes and three never reply, the average looks excellent, yet the load was booked with a single option. Response time describes carriers; coverage describes the decision. Both are useful, and measuring carrier response time remains the right tool for judging how much chasing each carrier needs. Coverage is the tool for judging whether booking decisions were made with enough options on the table.
The cutoff matters because a quote that arrives after the load is booked did not inform the booking. Counting it would make the decision look better informed than it was.
How to calculate it, step by step
The calculation is simple once three definitions are fixed.
1. Fix the cutoff for each load
Pick one rule and apply it to every load. Two common choices: a set time before pickup that the company configures by lane or mode, or the timestamp when the booking decision was actually made. The first measures the process against the policy; the second measures what the team really had in hand. Many teams track the policy cutoff and note when bookings happened earlier or later.
2. Set the denominator: approved carriers asked
Count each approved carrier that received a quote request for the load once, however many follow-ups it got. Do not count the full approved list for the lane if only some carriers were asked; that mixes a coverage problem with a request problem. Track "asked versus approved on the lane" as its own figure.
3. Set the numerator: valid quotes before the cutoff
Count quotes that meet the validity rules in the next section and carry a timestamp before the cutoff.
4. Calculate and roll up
Coverage per load = valid quotes before cutoff ÷ approved carriers asked. Then summarize by lane over a set period: the median coverage, the share of loads with fewer valid options than the company's minimum, and the share of loads booked with exactly one option. Report the count of valid options alongside the percentage, because 2 of 2 and 4 of 4 are both 100% but are not the same choice.
Two supporting figures help explain the result: time to the first valid quote, and follow-up attempts per valid quote.
What counts as a valid quote, and what the data must capture
A reply is not automatically a quote, and a quote is not automatically valid. A quote counts toward coverage only when it:
- comes from a carrier on the company's approved list;
- matches the shipment as requested: equipment, pickup window, pallet count, weight, and freight class for LTL;
- includes the accessorials the shipment will actually incur, or states them, so it can be compared with the others;
- is still within its validity period at the cutoff;
- arrives before the cutoff.
A decline counts as a response, not as coverage. So does "we can do it, rate to follow." Tracking response rate and valid coverage separately is what makes the metric diagnostic.
The data behind it needs a timestamp for each request per carrier, each follow-up and its channel, each reply, and the cutoff itself, plus the quote content needed to judge validity. The common gaps are quotes given by phone and never logged, replies that land in a different email thread from the request, and quotes that assumed a different freight class. When those live in personal inboxes, coverage is underreported and nobody can say why.
How to read the numbers
Coverage on its own says that choice was thin. The figures next to it say why, and each pattern points to a different fix:
- High response rate, low valid coverage. Carriers are answering, but the quotes cannot be compared. Look at the request itself: missing dimensions, wrong class or unstated accessorials. The order data checklist before a quote is the place to start.
- Low response rate, few follow-ups. The carriers may have capacity, but nobody chased them in time. This is a follow-up problem, not a carrier problem.
- Low response rate despite follow-ups. The approved list is thin on that lane. The fix is another approved carrier for the lane or earlier requests.
- Valid quotes clustered just after the cutoff. Requests go out too late, or the cutoff is set too early for how that lane responds.
- Good coverage, but bookings still above target. Choice is not the issue; the lane's rate target may be behind the market.
Set a floor, not a goal of 100%. A company might decide, as an illustration, that two valid options is enough on routine lanes and three on high-spend lanes. Chasing every carrier on every load costs time that coverage beyond the floor rarely repays. Read lanes with few loads cautiously, and look at trends over several weeks rather than single loads.
A worked week: coverage by load and what it says
The figures below are illustrative. Cutoff is the policy time before pickup for each load.
| Load and lane | Asked | Responded | Valid before cutoff | Coverage | Reading |
|---|---|---|---|---|---|
| 1, Ohio to Georgia FTL | 5 | 5 | 4 | 80% | Healthy choice |
| 2, Ohio to Georgia FTL | 5 | 4 | 1 | 20% | Three quotes missed the liftgate; fix the request |
| 3, Texas to Arizona LTL | 4 | 1 | 1 | 25% | Only one follow-up sent; chase earlier |
| 4, Texas to Arizona LTL | 4 | 2 | 2 | 50% | At the floor |
| 5, Illinois to Utah FTL | 3 | 1 | 0 | 0% | Thin list; escalated; lane needs another approved carrier |
| 6, Illinois to Utah FTL | 3 | 3 | 2 | 67% | Two valid, one arrived after cutoff |
Rolled up, the Ohio lane looks fine on average, but load 2 shows a request-quality problem worth fixing. The Texas lane needs faster follow-up. The Utah lane needs another approved carrier. One weekly table like this replaces a debate about whether carriers are "slow" with a specific fix per lane.
How Wilson, by Cartage, produces the data behind coverage
Coverage can only be measured if every request and reply is recorded against the right load. Wilson does that as part of executing the work. Wilson replaces the TMS for freight execution and connects to the company's ERP or existing order data flow, so each quote request starts from the order's actual details.
Wilson sends quote requests to the company's approved carriers by email, API, or EDI where supported, and follows up by email and phone where calls are configured. Requests, follow-ups, replies and changes are recorded in the shipment history with their timestamps. Wilson compares the valid quotes, negotiates against the company's rate targets within approval limits, and escalates to the team when no approved option fits the rules.
Wilson does not keep a standing carrier ranking or recurring rate benchmarking by default. It can use the data from the shipments it runs to produce carrier-performance or lane-rate reports on request, including the request and reply history coverage depends on. For how quotes are then weighed against each other, see how a team compares quotes across a carrier panel.
To see where your own loads stand, bring a week of quote requests and bookings to Cartage and work out coverage load by load.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai