By the end of this you will have a concrete design for automating COI issuance, including the specific requests that must stay in human hands.
Certificate requests are the clearest example of work that is high-volume, time-sensitive, and almost entirely mechanical. A contractor cannot get on site tomorrow without one. The request is four sentences. Producing it takes a few minutes. And yet in most agencies the median COI sits for the better part of a day.
If you want to see the parsing half working, try Cert Desk on a real request and see the holder, the limits, and the wording come back on a finished certificate.
Where COI time actually goes
Almost none of it is spent generating the document.
It goes to the request arriving as free text in an inbox that also holds renewals, claims, and endorsement requests, so it waits for triage. Then to figuring out which of the insured's four entities the holder is asking about. Then to reading a pasted contract clause to work out whether they need additional insured status, a waiver of subrogation, primary and non-contributory wording, or all three. Then to checking whether the policy actually carries the endorsement that grants it.
That last step is the one that matters and the one most often skipped under time pressure.
The request-to-issued path
Four stages, and automation helps in different amounts at each.
Intercept. Route certificate requests to a dedicated address or a form so they stop competing with the rest of the inbox. This alone removes most of the queue time and costs nothing.
Parse. Pull the holder's legal name and address, the required limits, the project or job reference, and any special wording out of the request. Free-text requests and pasted contract clauses are exactly what a language model is good at, and this is the stage with the largest gap between what software used to do and what it can do now.
Match and check. Find the policy for the right named entity, confirm it is in force through the date the holder needs, and verify that any requested additional insured or waiver language is backed by an actual endorsement on the policy. Automation should surface a clear yes or no here, never a guess.
Generate and review. Populate the ACORD 25 from policy data, present it next to the original request for a one-click approval, then send and log it against the account.
Keep the review. It costs seconds and it is the difference between a fast agency and an E&O claim.
What the holder actually needs
Most requests ask for more than the contract requires, because whoever sent it copied the strictest template they had.
Read the underlying clause when it is included. It will usually specify a limit, a status (additional insured on a primary and non-contributory basis, say), a waiver of subrogation, and a notice-of-cancellation period. Those are four separate things, granted by different endorsements, and the certificate is only evidence that they exist.
Where the request asks for something the policy does not grant, the correct output is not a certificate. It is a note back to the insured that they need an endorsement, before the job starts.
Three requests you should never automate
Anything asking for coverage the policy does not currently grant. This is a coverage conversation with the insured, not a document request.
Certificates with manuscript wording pasted from a contract. If the holder wants specific language on the form, a human reads it against the policy. Reproducing wording that the endorsements do not support is how agencies end up on the wrong side of a claim.
Requests against a policy that is within thirty days of expiration. These are renewal conversations wearing a certificate costume. Issue it if the coverage is bound, but flag the account.
Renewal season is the real test
The volume problem is not the daily trickle. It is the reissue wave when a master policy renews and every holder on the account needs a fresh certificate at once.
That wave is fully automatable, because the requests are already known: you are reissuing the same certificates against a new policy term. An agency that has the holder list, the wording, and the endorsement status stored per certificate can regenerate the whole book on renewal and route one batch for review, instead of fielding two hundred separate emails over the following three weeks.
If you are still storing that context in the certificate PDFs themselves, this is the argument for moving it into structured data. The same argument applies to submission rekeying between your AMS and carrier portals.
How does this work for an AMS360 agency?
The same four stages apply, and the question is who runs them. Your team can build certificates in AMS360 by hand, agencies on AgencyOne with InsurLink can use Vertafore's certificates tool, or you can hand the whole path to a service.
With Cert Desk, an AMS360 agency forwards the request and approves the finished ACORD 25. Your team keeps working in AMS360 the way it does today. The options are laid out on certificate automation for AMS360 agencies, and the form itself on how to fill out an ACORD 25.
What should a small agency do first?
Start with the intercept stage, because it costs nothing. Send every certificate request to one address this week, and count how many arrive and how long each one takes.
That count tells you the rest. If requests are rare, one address may be all you need. If they keep pulling a producer off sales, look at help built for small agencies, or compare software against outsourcing. Commercial shops with heavier volume should start from high-volume certificates.
Try it on a real request
What comes back: a filled ACORD 25 for a fictional fabrication shop, with the Port of Oakland as holder.
Take the last COI request that sat in your inbox too long and forward it to Cert Desk. You get a certificate back to approve, with the holder, limits, wording, and endorsement question worked out. Then decide how much of that path you want back.
FAQ
Would you rather approve this than type it?
Forward the request or the prior application. Salience prepares the form, flags what's missing, and nothing goes out until you approve it.
Frequently asked questions
How do you automate certificate of insurance issuance?
Intercept the request at the inbox, parse the holder name, address, required limits, and any additional insured or waiver language, match it to the policy in the AMS, generate the ACORD 25 from the policy data, and route it for a one-click review before it sends. The automation is in the parsing and the matching, not in the PDF generation, which every AMS already does.
Can AI read a COI request email and issue the certificate?
It can read the request and prepare the certificate. Most requests arrive as free text or a forwarded contract clause, and a model handles that far better than a form does. Sending without review is where agencies get into trouble, because the failure mode is an incorrect additional insured endorsement, not a typo.
What is the ACORD 25 and how does it relate to COI automation?
The ACORD 25 is the Certificate of Liability Insurance, the standard form a holder receives. Automating COIs means populating the ACORD 25 from policy data, plus attaching or referencing the endorsements that actually grant additional insured or waiver of subrogation status. The certificate itself confers no coverage.
How long should a COI take to issue?
For a routine request against an in-force policy with no special wording, minutes. Agencies that measure it usually find the median request sits in a queue far longer than it takes to produce, which is why the fix is request interception and triage rather than faster typing.
What is the difference between a certificate and an additional insured endorsement?
The certificate is evidence. The endorsement is the coverage. A COI listing someone as additional insured on a policy with no corresponding endorsement is worthless to the holder and creates real E&O exposure for the agency. Any automation must check that the endorsement exists rather than trusting the request wording.