Insurance Automation That Knows Where to Stop: Inside ALKEME's AI Playbook

Why is data access no longer the differentiator?

Deeds came to ALKEME after roughly 25 years in insurance, most of it inside agencies: fifteen years at two large retail brokerages, then a conglomerate spanning dozens of US and European agencies, then a data startup. That vantage point shaped a conviction he returns to repeatedly, which is that the industry solved data capture and never solved data usefulness.

The failure mode he describes is familiar to anyone who has built an insurance data analytics function: the report gets built, it gets presented, and it gets rejected on instinct.

His answer is not a better dashboard. It is prescription. The tools his team builds try to name the next action rather than describe the current state, because in his experience the specificity of the instruction is what predicts whether anyone does anything.

What actually makes agency data trustworthy?

This is the unglamorous half of the episode and arguably the load bearing one. Deeds works at the level of individual data elements rather than datasets, and he validates each one against multiple independent sources.

In practice that means picking a field, finding two or three places it can be corroborated, and grading the result. If he is checking which states clients sit in, he will bounce agency records against third party business data providers until he has agreement or a documented disparity. He is candid that three trustworthy sources is often more than the industry can produce.

He points to estimated revenue on a policy as the field that separates agencies that can forecast from agencies that cannot. Many smaller shops never populate it and run on billings instead, which he describes as a lagging indicator with no forward look.

The second mechanism is verification the user can perform themselves. When ALKEME's dashboards show a producer their lost business, the producer can dispute a record, which routes to a human who researches it and reports back with the reason and the notes. Elsewhere, a verify button queries the source system directly.

Deeds says that pattern runs across ten to twelve different data elements, and it is the thing that ended arguments about whether the numbers were right. Grace Schmidt drew the parallel to Advocate's own work on policy data, where the harder problem is confirming that what was keyed into the system matches what the source document and the broker correspondence actually said.

What has ALKEME genuinely automated?

The clearest example Deeds gave is a renewal preparation workflow. The system collects the activity history for an account, pulls the relevant contacts, retrieves a year of email correspondence with the service team, analyzes it for recurring issues and red flags, and assembles a renewal package with the key talking points already surfaced inside the 90 day window. He described building it in about a day once he had access to the email graph, and sees the next step as agent to agent: one model produces the package, a second grades it and escalates anything that needs a human.

Realistically, he noted, an agency would run that against the top fifteen to twenty percent of a book of business. The rest of the book gets handled differently.

He is also releasing an outbound campaign tool that mirrors a producer's own voice, letting them specify a segmented drip for a particular class of business and edit before enrolling clients and prospects. And an earlier piece of internal work illustrates the pace: two team members brought him an Excel macro they were feeding PDFs into and asked whether it could be automated. He scoped it through his own tooling and had them testing a working version the same week, complete with a suggestion button that routes fixes back to his agents.

Where does insurance automation deliberately stop?

This is the part worth reading twice, because Deeds draws the line by line of coverage and he is explicit about why.

Cyber runs all the way through to issuance. Workers compensation gets quoted and then a human picks up the phone. The difference is not technical capability. It is product variability and buyer comprehension.

And underneath that, a boundary he states flatly:

Asked whether his reticence about automated bind is permanent or a function of where the technology and the law currently sit, Deeds located it in comfort level rather than capability, and tied it back to the fundamental thing insurance sells.

That framing also reshapes the human role. Deeds does not describe a person supervising each step. He describes a person directing work and confirming output.

What happens to the smallest accounts?

Every agency ALKEME acquires arrives with the same shape: a large majority of accounts producing a small minority of revenue. By Deeds's internal numbers, the bottom deciles account for roughly 12 percent of overall revenue while representing well over half the client count.

The honest status quo for those accounts is neglect.

So they move to an automated servicing track, internally called the hive, where proactive communication and coverage gap outreach run through the engine rather than through an account manager. The first campaign targets clients with no cyber coverage, which Deeds frames partly as failure to offer litigation exposure and partly as growth. His stated goal is lifting retention in that band from 83 percent to 88 percent.

Whether the client is told depends on the acquired agency. ALKEME leaves that call to them, though Deeds prefers transparency, positioning the move as an upgrade in proactive service rather than a downgrade in attention.

Has the build versus buy calculus changed?

For years the reason an agency did not build its own software was maintenance: somebody had to own it forever. Deeds thinks that constraint has largely collapsed, and he is blunt about what replaces it.

The scarce resource is no longer engineering. It is deciding what to build and in what order, and then getting anyone to use it. Which is why his procurement instincts have shifted toward API access over interfaces. He is unenthusiastic about vendors who require his team to work inside someone else's UI, and describes signing up on the spot for a data provider that offered clean API access on a month to month contract.

On the vendor side of that conversation, Advocate's hosts made the case that workflow automation itself has stopped being a differentiator and that proprietary data is what remains. Deeds agreed, and articulated the position more directly than most vendors do.

Why is adoption a culture problem rather than a UI problem?

Deeds spent as much of the conversation on people as on architecture, and he opened there rather than being led there. His position is that psychological safety is the precondition for any technology rollout.

The mechanism he describes is specific to how agencies are structured. Service staff have a defined path that keeps them out of trouble and keeps producers from escalating at them. Ask them to deviate from that path with no protection if it goes wrong, and they will not move. So he redesigned what the technology says to people. Audits, in his framing, exist to tell people what they did wrong; his teams report the percentage of things done right alongside the exceptions.

He is equally unsentimental about complexity objections.

And about the ceiling on adoption. A one year old producer tool sitting at roughly 40 percent adoption is, in his read, a win, and he is not spending energy converting the last quarter of holdouts. [VERIFY: 40 percent adoption, approximately 110 daily logins and 350 to 400 weekly unique logins. Ryan's ALKEME figures.] What he wants long term is technology nobody has to opt into, which is part of the appeal of agent driven work: it runs whether or not anyone logs in.

That said, he credits leadership pressure for most of what stuck. Without regional presidents pushing adoption downward, he says, the tooling would have remained a set of impressive demos.