How to measure certificate-of-insurance turnaround from your own inbox

Most agencies can tell you roughly how fast they turn around a certificate of insurance. Few can show it. The evidence is already in your service mailbox: every request arrives with a timestamp, and every certificate leaves with one. This article walks through the method we used to rebuild turnaround in the founder’s agency, the traps that cost us real runs, and what to do with the requests the inbox cannot explain.

Why measure COI turnaround from the inbox?

Because the inbox is usually the only place where both ends of the job carry a timestamp. In the founder’s agency, certificates were not tracked as tasks in the agency management system at all, so the shared service mailbox was the one complete clock.

A certificate request is small work with large consequences. A truck can’t be loaded, a contractor can’t start a job, and a lease can’t be signed until the certificate arrives. Clients remember the wait. If you don’t measure it, you are managing an impression.

What exactly are you timing?

You are timing three moments, not two. Request received, request complete, and certificate sent.

• A: request received. The email lands.
• B: request complete. You have everything you need. If you had to ask for a VIN or the contract wording, B is when the answer arrived.
• C: certificate sent. The certificate leaves the agency.

C minus B, counted in business minutes, is your processing time. That is the number your team controls. C minus A, in clock minutes, is what the client experienced. Report both, and never mix them in one figure.

How do you find the requests?

Find them by where they end up and what the body says, not by the subject line. Real requests arrive titled “URGENT!”, “Need COI ASAP”, or with no subject at all, and a subject filter misses a meaningful share of them.

Better signals, in order:

1. Folder membership. If a tool or a person files handled requests into a folder, that folder is your ground truth.
2. The body. Look for holder names, “additional insured”, contract numbers and job references.
3. Exclusions. Certificate-tracking platforms send automatic acknowledgments (“Request received”) seconds after you send them a certificate. Those are not requests. If you count them, the matching reaches forward to an unrelated certificate and invents long delays that never happened.

How do you pair each request with its certificate?

Use a ladder of matching rules, strongest first, and record which rule made each match. The certificate is often a new message, not a reply, and it often goes to the certificate holder rather than the person who asked.

A workable ladder:

1. Same email thread.
2. Certificate sent to the requester’s address.
3. The insured’s name from the request found in the body of the certificate email. In our mailbox the insured’s name was almost never in the subject.
4. A short time window for the weakest matches: days, not weeks.

Two rules matter more than the rest. One certificate answers one request. If several requests can claim the same certificate, the earlier ones look days late for work that was done. And give every pair a confidence label, so you can filter to high-confidence pairs when you need a clean number.

Why use a business-hours clock and the median?

Because a request sent at 10 p.m. on a Friday did not wait on anyone until Monday morning, and because a handful of stuck requests should not define your service. Count processing time only inside your posted office hours, with holidays removed. A request answered at night by an automated tool shows zero business minutes, which is correct.

Then report the median, not the average. A few requests that sit for days waiting on a client will drag the average far from what a normal client experiences. Lead with three numbers:

• the median;
• the 90th percentile, which shows the slow tail;
• the share finished within four business hours.

The last one is your accountability number. Write down your service standard first, then measure against it.

What do you do with requests you cannot pair?

Count them, label them, and say so in the headline. Some requests will never pair from email, and an honest report shows how many and why.

Sort them into buckets:

• Platform portal. The holder’s tracking platform wanted an upload, so no certificate went by email.
• Replied, certificate not identified. Someone answered, but you can’t tell which message carried the certificate.
• No email trace. These are often delivered from the management system, which leaves nothing in the mailbox. Check a sample there before you call any of them unfulfilled.

Also hold back requests from the last few days that have no certificate yet. They are in flight, not failures.

Why split automated and manual certificates?

Because the two paths behave so differently that a blended number hides the problem. Report each path on its own, every time.

In the founder’s agency, we reconstructed 621 requests from 12,108 messages between July 1 and September 12, 2026. Of those, 407 had a measurable request-to-certificate time. That is a measured subset, not every request.

On that subset:

Path	Requests	Median	Within 4 business hours
A certificate tool we selected, then measured	261	6 minutes	99.2%
Manual handling	146	42 minutes	76.0%

The automated path’s 90th percentile was 10 minutes. The manual path is where the slow tail lives, so that is where to look first. To be clear about credit: the certificate tool is a vendor’s product, not ours. What we built is the measurement.

What else belongs in the report?

Rework and duplicate sends. Turnaround alone will not show either one, so count them as their own categories.

• Rework. A certificate that is rejected or revised costs more than a slow one, because the client has to ask twice. In our measured subset, 1.1% of automated issuances came back rejected or revised, against 5.8% of manually handled ones.
• Duplicate sends. Look for the same certificate sent to the same recipient more than once within a few minutes, with identical content. Count the bursts and the extra copies. A client who receives the same certificate several times in a row does not think “fast”. They think “broken”. Mail data alone may not tell you which system caused a burst, so report it as a finding to investigate, not a verdict.

How do you know your numbers are right?

Test the measurement before you quote it. Three checks catch most errors:

1. Read the slowest rows against the original emails. Outliers are where false pairings hide. In our first pass, three of the six slowest requests turned out to be bad matches, not slow work.
2. Run an impossible window. A date range with no mail must return zero requests. If it doesn’t, the search is broken.
3. Check against a second source. If your certificate tool reports how many certificates it issued, your request count should come in at or below it, because one request can produce several certificates.

Then run the same method every month. One measurement is a snapshot. The same measurement, repeated, is a management tool.

Where should a licensed person stay in the loop?

On anything that touches coverage wording. Additional insured status, waiver of subrogation, and primary and noncontributory language are coverage questions. A tool can prepare the certificate; a licensed person should confirm the wording matches the policy before it goes out.

Measure those requests as their own group. They will always be slower than a standard certificate, and that is fine. What you want to know is whether they are stuck, not whether they are fast.

Want this measured on your own inbox?

Rebuilding a baseline like this from your own data is how we start with an agency: the first fix is chosen and measured against numbers like these. Book a free discovery call.