Insurance Innovation That Actually Solves Problems: How to Avoid Building Tech No One Uses

Innovation” has become nearly synonymous with technology. Mention innovation in the insurance industry, and the conversation quickly turns to AI, automation, agent orchestration, data platforms, or the latest insurtech darling. But tech alone is mere invention. Innovation carries the requirement that the new thing being brought to the table is successfully implemented to create actual value.

It happens often: insurance organizations spend significant time, money, and energy implementing stuff that technically works but doesn’t solve the problem employees, producers, or clients are living in. A system performs exactly as designed and somehow makes the workflow more complicated. A tool ships with a dozen capabilities and half of them go untouched. An automated process saves measurable labor in one department while quietly creating more work somewhere else.

Start with the objective. The technology comes second.

Don’t Solve a Problem You Can’t Define

When someone says, “We need a new tool,” the first question shouldn’t be which vendors to evaluate. It should be: What is the intended outcome? It literally needs to be on paper. That sounds simple, but it forces a useful shift in thinking. Instead of beginning with a proposed solution, the organization has to clearly illustrate what it’s actually trying to accomplish and demonstrate how that goal is aligned with its overarching strategy.

From there, two more questions follow:

What does the current process look like?

What’s preventing it from producing the desired outcome?

If those questions can be answered in a format that promotes communication across diverse audiences, ideally through diagrams and the written word, the organization is likely halfway to solving the problem.

The obstruction could be outdated technology. It could also be a disconnected workflow, unclear ownership, thin training, messy data, or a communication gap between departments that never talk. Not every obstacle is a technology problem, and it would be nonsense to throw a technology solution at a training problem or a fundamental strategy weakness.

This is where it helps to stop thinking in departments and start thinking in flows. A problem can show up in accounting, sales, claims, or service, but its cause may sit several steps earlier or sideways in the process. Understanding it requires following the flow of information from where it starts to where it lands.

Where does the data originate? Where does it go next? Who touches it? Where does the process slow down? Is a system simplifying the work, or has it quietly become one more thing people work around?

The organization knows it’s making progress when the process begins to resemble an old-timey detective’s board, full of evidence and red string tracing every connection until the whole picture is visible.

Diagnose Before You Redesign

A personal story from outside insurance illustrates the risk of solving the wrong problem.

At a highly automated food production facility, a controls engineer was approached about a malfunctioning robot. A product was supposed to move consistently from one point to another, but the robot was occasionally dropping it. The proposed solution was to rewrite the robot’s programming.

That would have been possible. It also would have taken time to change, test, validate, and recalibrate code that had previously worked well.

Before pulling all the stops to rush a coding fix, the engineer paused. He observed how employees were operating the equipment. They were using it correctly. He then inspected the robot itself and found that a basic suction cup responsible for gripping the product had worn out.

It was replaced in about 10 minutes.

The problem could have been addressed with a complicated technology change. Instead, asking “why” enough times uncovered a much simpler solution.

Insurance organizations face their own versions of the worn-out suction cup. A slow process may not require an entirely new platform. A reporting issue may not require a more sophisticated dashboard. A producer might resist new software simply because no one explained how it fits into their day.

A new tool might help a broken process move faster. It won’t necessarily heal the break.

‘The organization knows it’s making progress when the process begins to resemble an old-timey detective’s board, full of evidence and red string tracing every connection until the whole picture is visible.’

Don’t Overcomplicate the Solution

In one insurance organization, a business intelligence review identified revenue opportunities between the commissions the company was receiving and the amounts it could be receiving. Individually, the gap appeared to be drops in a bucket. Collectively, it added up to millions of dollars.

The answer? It wasn’t a whole new system. It was the choice of a phone call or a canned email added between two steps in the existing process.

Organizations sometimes assume that a large problem requires a large solution. In practice, the size of the outcome and the complexity of the solution aren’t always related. In fact, sometimes solutions are not additive at all but actually cutbacks. The goal should be to find the simplest reasonable step that can test the organization’s strategy.

Evaluate the Experience, Not Just the Features

Before adopting a tool or redesigning a workflow, think through how the change lands on everyone who touches the process, not just the person who requested it.

For employees, does it cut duplicate work or create another system to babysit?

For producers, does it support the way they serve clients and manage relationships, or does it pull attention away from those critical responsibilities?

For clients, does it make insurance easier to understand, access, or use?

For technical teams, can the solution be supported, secured, and integrated with the organization’s existing environment?

If a tool helps one group by dumping work on another, the process hasn’t been fixed. The bottleneck has simply moved somewhere less visible, for now. Once the organization finds balance in the larger equation of experience, it’s ready to tackle features.

Building a tech stack or designing bespoke applications can’t be approached like ordering a hamburger. That’s why cultivating real understanding between business users and technical builders is essential. Business users should avoid the temptation to throw a list of demands into the IT abyss. They need to take the time to illustrate the why behind the request. Builders and engineers should also recognize that building exactly to spec with no context is folly. Genuine curiosity about the problem at hand matters.

Business teams understand the daily frustrations and desired outcomes. Technical teams understand what can be built, integrated, automated, and maintained. Neither perspective is enough on its own.

Technology Can’t Replace Clarity

The larger and more complex an insurance organization becomes, the easier it is for “good” ways of working to become twisty and tangled. That’s just entropy, and it happens faster the more people and products you add to the pot. Technology may help manage that complexity, but it can’t be the only card an organization plays. Vision, leadership, and training cannot be replaced by processes and software.

Insurance organizations don’t need to stop building, buying, or testing new technology. They need to be disciplined about what they want. The strongest innovation starts with a clear outcome, an honest look at the current process, and enough persistence to keep asking “why” until the real issue emerges–not just the first plausible one.

Harmon is the director of innovation at ALKEME Insurance, a full-service insurance agency providing commercial and personal insurance, employee and executive benefits, retirement, and wealth management services.

Topics InsurTech Tech