Making it easier for customers to connect their existing system to an external EOR.
An EOR is a third-party company that becomes the legal employer of a worker on another company's behalf in a country where it has no legal entity. EOR connects to the HRIS or Payroll system the company already uses. However, there are cases where the system might not be built as an integration in the EOR. This case study looks at how to make it easier for the customer anyway.
Remote.comIntegrationsHRISEOR
In short
- The problem: Today, only a few systems connect instantly with integrations in another platform. Others wait for their system to be built as an integration on a platform to connect. Or routes to a person to help build their system as an integration.
- The fix: Give every customer a 'Login' button for their existing system. We automatically use whichever path already works, a partner platform or our own. If neither exists yet, the request gets captured and handled directly, instead of the customer being left waiting with no next step.
Proof
- About the role in the job description: "Customers need expert guidance and delivery support to integrate Remote with the tools and processes they already use." — Remote, Senior Product Manager, Remote Build
- Remote's Integration Page: "Integrate using Merge's unified API for fast, secure HRIS and ATS connections." Listed under Security & Compliance — not as a one-click customer option. — remote.com, Integrations for customers
- Finch's Coverage: "Many listed systems carry a 'Beta' status with 'Assisted' data access — some data must be requested rather than pulled automatically." — developer.tryfinch.com, Provider Network
- Being able to connect isn't the problem. It's that customers still need someone else to do it for them. How do we make it easier for them to connect?
Why it happens
- Building a one-off, custom connection for a single system is real, expensive engineering work — it can take hundreds of hours and cost tens or hundreds of thousands of dollars a year to build and maintain, which is why most systems never get a dedicated integration. — tryfinch.com, The Ultimate Guide to HRIS Integrations
- Even where a broader connector platform already reaches a system, that coverage isn't automatically reliable enough to hand straight to a customer — some connections are still partial, or need manual handling behind the scenes. — developer.tryfinch.com, Provider Network
- And today, there's no documented, reusable process for deciding how a new system should get connected — each request is still handled as its own one-off discovery project, which is the specific gap this role exists to close. — Job description, Remote Build
- So: the fix has to work regardless of whether a system is common or obscure, and regardless of who — or what — ends up doing the connecting behind the scenes.
The solution
- This happens now: Only a few systems connect instantly. Everything else routes to a person, with no consistent process and no promised timeline.
- Customer connects and login: The customer clicks 'Connect,' picks their system, and logs in the normal way.
- The flow decides the best path: Behind that login, we check what's already available: a partner platform, or a connection we own. Whichever one works gets used automatically.
- If neither available: The request is captured clearly instead of disappearing. A person steps in right away if it's blocking something real, while a proper connection gets built for next time.
Compounding the experience
- From the solution: The very first customer on a system nobody's connected before still has to wait. Someone has to confirm the connection works and maps correctly before it's trusted with real pay and compliance data.
- The compounding step: Save how that system's data was matched the first time. Every later customer on the same system gets the instant version. Just log in, and it's done. The hard part gets paid for once. Every customer after that gets it for free.
Letting usage decide what we own outright
- What is not in the solution yet: Leaning on a partner connection is fast to turn on. But it isn't free, and it isn't always the most reliable option long-term. That matters most for a system a lot of customers depend on.
- The compounding step: Track cost and reliability per system, not just popularity. Once a system crosses a clear threshold, move it from the partner connection to one we own directly. That way, the experience keeps getting more reliable and cheaper for the whole customer base as usage grows. The customer never sees a difference.
Risks, and how I'd handle them
- When neither path is ready yet — Risk: A deal can get stuck if a customer's system has no path yet. What I'd do: A person steps in immediately for anything time-sensitive, while the real connection gets built for next time.
- Customers won't hand over login details to a connect system — Risk: Trusting us with real login details is a big ask, especially for payroll and personal data. What I'd do: Never store the raw password. Exchange it right away for a limited, revocable token. Use a proper login-and-approve flow wherever a system allows it. Give the customer a page showing exactly what's connected, with a one-click way to disconnect it.
- Relying on a partner has a cost — Risk: Leaning on a partner connection isn't free, and it isn't always reliable long-term. What I'd do: Track cost and reliability per system. Once a system crosses a clear threshold, move it to a connection we own directly, instead of guessing when it's worth it.
What I'd test first
- Test that it actually compounds: Have a handful of customers on systems we haven't connected before try the one-login flow. If the second customer on that same system connects noticeably faster than the first, that proves the compounding is real, not just a nice idea.
- Test the ownership trigger: Pick the system costing the most through the partner connection, move it to a direct build, and check whether reliability and cost actually improve — with zero visible change for the customer.
- What to watch: None of this works if customers don't trust it with real login details, or if the fallback path becomes a graveyard of ignored requests. Every captured request needs a clear owner and a visible outcome.
- If both of these hold up, that's proof this is ready to grow beyond a small test.
Want to discuss this in person?
Send me a note about what you read here and I'll get back to you myself.