The Context

Ben is a global flexible benefits platform headquartered in London. Its product features a modern SaaS platform with per-employee Mastercards and the financial infrastructure to instantly add employee choice to their customers’ existing benefits, unlocking access to hundreds of additional options catered to the individual employee.

By definition, being a global provider and selling across multiple sizes and geographies, means the portfolio of HR systems used by Ben’s customers is large and inconsistent in how they collect, index, and distribute the critical HR data that is core to Ben’s product offering.

Subsequently, their enterprise customers from the U.S. might use the likes of Workday or iCIMS as their source of truth, their European SME customers – Personio or BambooHR – and the list goes on with the systems count adding up to 50+ needed integrations with the individual HRIS.

Robert, Ben’s CTO, told us more about why building all of these integrations in-house was never a choice for them.

We built a handful of integrations in-house at the beginning (BambooHR, Workday; we still maintain a generic SFTP integration ourselves), but we quickly realized that building and maintaining these was not core to our product and the number of diverse integrations needed by our customers was growing too quickly.
— Robert E., CTO

The Challenge

Integrations are a must-have, both internally and externally.

For a benefits platform like Ben, integrating with their customers’ HR systems is not just a nice add-on. It is a crucial component of their product offering.

Internally – they need all the employee-specific data points from HR to be able to run their product.

For any customer of Ben to be able to set up an accurate system for their employees, Ben has a rule system in place that relies on up-to-date HR data and determines whether a particular employee is eligible for a particular benefit, based on criteria such as:

• Tenure
• Employment Type (part-time, full-time, during probation, etc.)
• Team & Department (and details such as: are they a manager?)
• Salary: where a benefit might be based on a % of the salary
• Location: to determine under which instance an employee should go if being employed in country X but living in country Y
• Age: especially interesting for insurance companies
• Etc.

All of these different factors can be codified into the algorithm that a customer of Ben sets up, and it is all up to the individual customer to decide these rules. So, for Ben, the more data points they are able to gather, the richer the flexibility of their customers to build their ideal employee benefit system.

Externally – Ben works with vendors where accurate employee data is critical not only for the smooth running of the product and collaboration with their partners, but can have wider implications as well.

For example, it would be critical for a health insurance provider to know at all times what tax bracket an employee falls into, their marital status, location, or any other demographics that factor into their contribution margin.

All of that considered, for Ben, the question was less: “Should we build in-house or outsource? But: “Who should we partner with for our integrations?”

The Decision

Ben has previously used merge.dev – another unified API provider – but switched to Kombo after a year of using Merge. The reasons for the change primarily lie in Kombo’s:

• High velocity of shipping new integrations
• Pricing model that incentivizes scale

We can never predict in advance which integration we will need next, because the inbound requests usually come from new customers and we want to onboard them quickly. That said, it was very important for us to have an integration partner we can trust to be responsive when one of our new or existing customers requests a new integration.
— Robert E, CTO

Focusing only on the HR vertical (as opposed to Merge, which covers 7+) allows us to be fully immersed in the space and highly attune to our customers’ integration requests, edge case coverage, and world-class support. We can also spot new developments in the market early and often, and pass them on to our customers.

Because of that, we have designed our product and engineering team to be the most responsive solution on the market regarding feature and integration velocity.

Our pricing model is also designed to fit our customers’ needs and growth plans. It takes into account everything from the number of integrations needed to the size of our customers’ customers.

The Outcome

Ben's transition from merge.dev to Kombo was seamless and took around 6 weeks. Since working together, we’ve shipped 5 new integrations for their use case.

When asked what were the main highlights so far working with Kombo, Robert mentioned:

Support
The Kombo team is always available if we run into any issues or questions, so on that front, support is very well done and of great help.

Integrations Velocity
We can get new integrations up and running (with quick solutions such as beta integrations plus active monitoring before everything is ironed out), and that has been truly amazing – knowing that if an important customer comes along, Kombo will make it work.

High-impact features
Things such as setting up different permission scopes is very important for our customers so they don’t have to share any information they don’t have to. The product team at Kombo is constantly conducting market research and improving their product.
‍
— Robert E., CTO

Best-in-class support, high integrations and feature velocity, and deep understanding of our customers’ space and problems are all enabled and enhanced by our unique approach to focus on the future of work space and the integration challenges of our customers there.

It’s been great working with Ben, Robert, and the team so far, and we look forward to helping their business to grow in the future.

If you want to explore how Kombo’s product can power your benefits infrastructure, too, reach out!