Automation consulting for insurance companies: what actually automates, and in what order.

An automation project in an agency is not really a modelling problem. The models are good enough to read an emailed endorsement request or a loss run. The constraint is the system of record: what your agency management system will let an outside system read, what it will let that system write, and what your specific license tier and vendor agreement permit.

So the first question in scoping is never "can this be automated". It is "what can we reach, under what agreement, and what happens when the vendor changes it". A consultant who has not asked that in the first meeting is selling you a demo. Ask any prospective automation partner to answer it in writing for each of your systems before you sign anything.

The second question is what happens to the audit trail. If an automation updates a policy record or issues a document, the activity log needs to show what was done, by which system, on what input, and which human was accountable. Agencies that skip this discover the gap during an E&O review rather than during the build.

EZLynx is the common answer for personal lines heavy agencies, and it ships its own rules-based automation tooling for campaigns and recurring workflows. That tooling is genuinely useful and underused; a fair number of agencies pay for automation consulting to do things their existing configuration already covers. Any honest engagement starts by exhausting what you already own.

Where it runs out is unstructured intake and cross-system work. A rules engine inside the AMS can trigger on a field change or a date. It cannot read an inbound email, decide it is an endorsement request for a specific vehicle on a specific policy, and pre-fill the change. That is the layer a build adds on top, and it should write its results back into the same activity stream so nothing lives in a shadow system.

Confirm your current API access tier with the vendor before scoping, because the practical answer differs by agreement rather than by product. The detail is in the EZLynx AI automation playbook, and if you are weighing the platform itself, Applied Epic versus EZLynx covers the comparison and EZLynx alternatives covers the field.

Epic is the deepest of the four and the most configurable, which cuts both ways. Larger agencies on Epic usually have real workflow structure already in place: activity types, suspense conventions, a defined service model. Automation lands well on that foundation because there is something consistent to write into.

The complication is that depth invites custom field conventions, and every agency's are different. An automation that has to decide whether a policy is in force, who the servicing producer is, and which activity type to log is reading your conventions, not a standard schema. This is exactly the boundary where productized tools stop and a commissioned build starts, because the product cannot ship your taxonomy.

Integration goes through Applied's partner and developer program, so the access question above is not rhetorical. Get the answer in writing. The Applied Epic AI integration playbook covers the workflow patterns we see most often on Epic books.

HawkSoft agencies are usually smaller, which changes the economics more than it changes the technology. A twelve-person agency has the same seven workflows as a hundred-person agency; it just has less volume in each, and less budget to throw at any of them. That argues for buying narrow products first and building only where the work is genuinely specific to the agency.

Where a build does make sense at that size, it is normally the phone layer or certificates, because those are the two workflows where volume stays high even when headcount is low. A commissioned build in the $45,000 to $65,000 band has to displace real recurring cost to make sense, and in a small agency that arithmetic is honest or it is not. We will tell you which on the call rather than after the invoice.

The HawkSoft AI automation playbook has the workflow-level detail, and what AI consulting costs for a regional agency has the arithmetic before you talk to anyone.

AMS360 agencies tend to be commercial-lines weighted, which pushes the priority list toward certificates, submissions, and commission reconciliation rather than renewal review. That is a meaningfully different build than the personal lines picture, and a consultant who proposes the same first project regardless of your book mix has not read it.

Vertafore exposes developer access through its own program, and the same rule applies: confirm what your agreement covers before anyone scopes a write-back. Where write access is not available, a read-plus-file-exchange design still works for reporting, reconciliation, and preparation, and it keeps the human as the one who commits the change. That is a slower workflow but an easier one to defend.

See the AMS360 AI automation playbook for the commercial-lines version of the sequence.

Whatever the AMS, a large share of the data arriving in it comes from carrier downloads rather than from anyone typing. That plumbing decides how much of a workflow is really automatable. If policy and claim data lands structured, renewal comparison and reconciliation get much easier. If a given carrier only publishes to a portal, the choice is screen-level automation with a maintenance plan, or leaving that carrier's slice manual.

The mistake to avoid is designing a build that assumes uniform carrier behaviour. Inventory your top carriers by volume, classify each one as structured, semi-structured, or portal-only, and scope against that reality. It is unglamorous work and it is the difference between a system that holds up in month six and one that quietly stops being used.

For a regional carrier rather than an agency, the same logic applies one layer down: submission intake into policy administration, rating exception handling, claims document classification, and reporting extracts are the equivalents, and the access question is about your own core system vendor instead of your AMS.

Quandri is the clearest example in the agency market. Its software robots work personal lines renewals inside the agency management system, pulling the renewal, comparing it against the expiring policy, and flagging premium jumps, coverage changes, and missing data so the account manager receives a reviewed file. Inside that scope it is very good, and an agency whose top friction is exactly renewal review should buy it rather than commission anything.

The limits are the same as any focused product: submissions, certificates, commission reconciliation, and producer reporting stay manual unless you solve them separately. That is not a criticism of the product, it is the definition of a product. The Quandri comparison works the five dimensions in detail, and Quandri alternatives covers the adjacent field.

The general rule: where a well-funded vendor has built a deep product against exactly your workflow, buy it. You will not out-build a company that has spent years on one slice, and you should not try.

Before anyone quotes a build, exhaust the workflow tooling inside the AMS you already license. Rules-based task routing, templated client communication, recurring activity creation, renewal date triggers, and standard reporting are usually included and usually underused. An automation consultant whose first proposal ignores this is optimizing for their invoice.

The honest limit of configuration is that rules trigger on structured events. A date arrives, a field changes, a status flips. That covers a real share of agency work. It does not cover reading an unstructured inbound message, deciding what it is, and preparing the action, which is the layer where models earn their place.

Generic robotic process automation sits in between. It can drive a carrier portal that has no API, and it will break when that portal changes. RPA is a legitimate tool with a maintenance bill attached, and it should be scoped with that bill visible rather than presented as a permanent fix.

Does it cross systems? Work that starts in email, resolves in the AMS, and finishes in a carrier portal has no single vendor responsible for it. That is build territory by default.

Does it need your taxonomy? Carrier appetite, producer splits, custom AMS fields, and your own document conventions are not shippable in a product. If the automation has to know your conventions to be correct, no product can hold them.

Is the volume real? A build has to displace enough recurring cost to justify a fixed fee in the $45,000 to $180,000 range. Count the actual transactions per month before anyone writes a scope. If the number is small, buy something or leave it alone.

Does ownership matter? A commissioned build hands over source code and architecture documentation and runs inside your own tenant, which matters when carrier data agreements restrict where insured data may be processed. A subscription keeps that data on the vendor's stack indefinitely. The build, buy, or commission framework is the longer version of this test.

Anything that issues coverage advice to an insured without a licensed human in the path. Anything that adjudicates a claim. Anything that decides, without review, that a policy should be rewritten or non-renewed. These are not technical limits, they are limits of what a regulated distribution business should let software decide on its own, and an automation partner who agrees to them too easily is a liability rather than an asset.

We would also decline a build whose only justification is that a competitor has one. The point of the diagnosis call is to establish whether a build is the right lever at all. Sometimes the honest answer is that a process needs fixing on paper before it is worth automating, because automating a broken process only produces the same errors faster. What we do not build is the full list.