Software Is a Service

/0 Comments/in /by

No. That’s not a typo in the title. Yes. It’s a play on Software As a Service (SaaS). Yes. Our software is available in the cloud. But it’s also something we think about frequently when we’re asked, “What do you do?”

The Obvious

We provide an administration suite for property/casualty insurance. That means our suite does everything a comprehensive administration suite should do:

  • It accepts applications.
  • It has workflows.
  • It applies business rules.
  • It rates and quotes applications.
  • It binds coverages and issues policies.
  • It processes renewals and declinations.
  • It integrates with other systems and data sources.
  • It contains a forms library.
  • It enables analytics and reporting.
  • It feeds billing and claim modules (or systems).
  • It processes the necessary transactions.
  • It makes information and transactions accessible to policyholders and agents.

Along the way, the Finys Suite also lets insurers make all necessary policy changes, audit premiums, cancel and reinstate policies and endorsements, track coverage histories, and other cool stuff.

[Yawn …] Well, yes. Those things and more are what the Finys Suite does. But it’s not what we do.

The Not So Obvious

Our Software As a Service offering is actually a Software Is a Service offering. Here’s why we believe that: We develop software that provides processing and transactional services to our customers. The Finys Suite’s digitalization, centralization, automation, and configuration make it easier for our customers to do the business they need to do, the way they want to do it. It also makes it easier for people (policyholders, agents, and other parties) to do business with them.

By making it easier for people to do business with them, the services our software provides also enables our customers to provide better service to all of their constituents. Policy service, claims service, self-service, billing, a variety of payment methods — all of those things and more help our customers cultivate and retain the relationships through which their products are sold and by which their businesses are sustained.

Could Software Is a Service be considered a stretch? Sure it could. But we don’t think of it that way. We think of it as a service that makes providing service easier for our customers.

If you don’t think software is a service, try processing or transacting something without it.

The End of What?

/0 Comments/in /by

We happened to see a piece on the Gartner website the other day that said this, in part:

Policy administration systems [provide] full end-to-end life cycle management … vendors are increasingly offering a comprehensive range of products with vendors looking to alternative capabilities to differentiate their offerings; for instance, front-end portals with embedded engagement tools.

We have to admit that every time we see something described as end-to-end, we think of two things: The first is a short story by Ernest Hemingway called, “The End of Something”. It was written during what some scholars refer to as Hemingway’s suggestive period, in which he was trying to say something without saying anything. The other is The End of It, a beautiful novel in which a young American artillery officer is driven nearly insane by the barbarity of World War II but is saved by the beauty, the people, and the culture of Italy.

But as you might guess, this isn’t supposed to be a post about literature. So, we’ll get back to our Gartner reading.

Vanishing Point

We have to admit to being perpetually perplexed by the phrase, end to end, for two reasons. First, regardless of the business you’re in, why would you want to suggest the end of anything? We completely understand that nothing lasts forever. But no matter what you’re creating or selling, why invoke even philosophical curiosity about when it might cease to be created or sold?

Policy Lifecycle

Bill: Well, ya know, everything has to end sometime.
Will: I know. But we just started.

Second, maybe we’re being too literal. But if we’re talking about a lifecycle — in this case, a policy lifecycle — where could we say it ends? Isn’t a lifecycle self-perpetuating? Shouldn’t it sustain itself by the fulfillment of commitments, responsive service, and operational transparency? And where or why would it end? When the policyholder stops paying premium? When the insurer refuses to pay a claim and the policyholder takes his business elsewhere? Are we too conservative? We don’t know. But setting aside the argument that the insurance industry is and should be conservative, why even flirt with any of that?

We get the idea that end-to-end is supposed to connote comprehensiveness, a set of processes from policy application to claims adjudication, with billing and a few other things in the bargain. But why not say comprehensive instead of suggesting some point of termination?

Why take it to the vanishing point?

DIY Means Design It Yourself

/0 Comments/in /by

When most people think about designing something — a car, a software program, a rocket, the perfect in-laws, an insurance product — they usually think about something difficult and pretty messy. It doesn’t have to be that way, at least not always.

Our customers were asking us for a toolset to give them maximal flexibility and maximal independence with minimal complexity. As we listened to their requests and took them to heart, we decided we had two options:

  1. We could make them completely dependent on us to do all of the things they wanted to do by themselves.
  2. We could give them access to exactly the same toolset our designers and developers use, which would enable them to do all the things they wanted to do by themselves.

After careful deliberation, a few sleepless nights, and a seance or two, we chose Option 2.

How Do We Define Success?

“What do our customers want us to do?” We could answer that question in a multitude of ways: They want us to process their insurance transactions. They want us to manage their claims. They want us to bill their policyholders. They want us to give them the best software we can develop to do those things. The list of answers goes on. All of them are only partly correct. What our customers really want us to do is to enable them to do more business more easily, more efficiently, more accurately, and less laboriously. That’s just what our Design Studio does.

We gave our Design Studio an intuitive user interface. We created pre-built line of business templates. We provided drag-and-drop, WYSIWYG fields and process aspects. We enabled real-time collaboration. We included report wizards. We developed automated regression testing. And we made sure users could administer security administration down to the level of individual fields.

It gives our customers exactly as much self-sufficiency as they want. We meet them online in our Design Lab. In joint design sessions, we work with them to establish functional objectives. We teach them how to configure the Suite, their products, their states, and their lines of business. We show them how to do those things simply and efficiently. We tell them they can have all the autonomy they want, but we’ll always be there to help them out and to back them up. That’s why we define our success by the success of our customers.

But help with your in-laws? Not so much.