Connectivity
If you're buying a policy software platform, you want to ensure that platform plays well with other systems, whether those are major chunks of your stack—like a billing system—or smaller add-ons for convenience and efficiency.
Integrating with other systems is a common bottleneck in insurance. It's worth doing some due diligence before you take that shiny new platform home. There are a few themes to look at.
Openness
In the modern software world, we're used to platforms that are open to third-party development. Chrome and Firefox, in the browser world, allow anyone to write extensions, and have a marketplace for you to download and install them. Obsidian, the note-taking program I'm using to write this article, similarly has a whole community of developers writing extensions. This open pattern allows for unparalleled breadth and speed of innovation.
Watch for this kind of openness in your policy software as well. Platforms like InsureMO and Dais are built around it, in something like a two-sided marketplace of insurers and solution providers. To be clear, most policy software systems want other providers to integrate with them. Many (certainly most you'll see reviewed here) lower the barrier; others make it almost nonexistent.
To lower the barriers to connectivity, keep an eye out for webhooks, which allow one-way notifications from the platform out to other systems; APIs, which allow other systems to interact with the platform; particularly flexible forms of configurability, like Socotra's JavaScript plugins, to allow you to call out to other systems; and generally the existence of really good documentation.
In the most open platforms, integration efforts can be led by the third party solution provider, either alone or with the platform's collaboration and guidance. Otherwise, it is the platform that leads the effort and maybe even does the development work. If the platform leads the effort, it could be for the very best of reasons: They want to ensure those integrations are up to their standards, for example, for both your experience and their brand. It could be the nature of the deal: The platform is more motivated than the third-party provider in this particular case. Or it could be something less desirable: The platform is just not built to make the process easy.
Customization
If it's the platform leading the effort, the second question to ask is whether they're setting it up for just you, or they're setting it up for all their customers. It's often in the platform's best interest to set up integrations for all customers, rather than just you. Other times, what you're integrating with is proprietary, your secret sauce, and you don't want it to be available for just anyone.
The answer to this question will help determine the shape of the engagement. If the integration will be available to everyone, it might be cheaper for you. But it may also take longer. You'll want to ask the platform you're working with.
The shape of the engagement
If an integration is customized just for you, you'll need to contract with the platform regarding costs, hours, and timeline. A lot of platforms will scope the integration and charge it as a separate body of work. Some will include a standard number of integrations with your base contract. Others will offer a base number of developer hours per year, and you can fit the integration within those. Whatever integrations you have in mind when you first look into a platform, assume you'll have more in the future. Ask before you start work with them how these engagements are structured on an ongoing basis.