About the Company
Deel is the fastest-growing B2B SaaS company in history, offering comprehensive global HR solutions for hiring, payroll, and compliance in over 150 countries.
Stages of the project
- Opportunity & Hypothesis
- Goals
- Designing the Marketplace
- Designing the Quote Flow
- Designing the Admin Tools
- Results & Impact
The Opportunity
As Deel’s payroll management business grew, the demand for providing a comprehensive benefits offering within our platform arose with it. Current clients from different countries (especially the US) increasingly requested having a cohesive experience for browsing, understanding, shopping, and managing their workers’ benefits within the same space their payroll was handled.
At the same time, as our benefits product matured with a new administrative suite of tools and a powerful benefits configurator, the natural next step was to build a scalable structure for an in-house shopping experience that could grow for years to come.
Hypothesis & Goals
Introducing a self-serve Benefits Marketplace within our platform will drive higher benefits adoption and incremental revenue by reducing manual broker dependencies. By building an embedded experience for clients to browse, analyze, and select benefits for their team directly in Deel, we’ll streamline the purchase flow and unlock new upsell opportunities.
Goals for the business
- Automate manual quoting processes, and empower operations to increase sales efforts substantially.
- Provide a more unified solution for benefits within the HRIS and Payroll ecosystem, to increase new client onboarding.
- Generate new revenue sources from brokerage, benefits compliance, upselling, and eventually, selling to external prospective customers.
Goals for the user
- Understand what constitutes a compliant benefits package for specific countries/worker types combinations.
- Be able to browse through different levels of benefits, select and discard depending on business needs
- Get a quick quote on interesting benefits and be able to offer them to employees in the same platform
Explorations and Jobs To Be Done
Based on internal stakeholder and client interviews, the main goals were largely understood. But the design process began with some uncertainty in regard to the necessary jobs to be done to fulfill.
After exploration and further research, we came to the realization that there were two main use cases to consider. The first would be companies purchasing benefits in large packages varying by level of market competition. The second, buying benefits individually, for upselling. The insight? While a traditional digital retail marketplace would focus on a “pick and choose” experience, this product had to do both: Let users quote individual benefit products and also suggest the ideal benefits package for them.
Designing the Marketplace
There were a lot of moving pieces to take into account when designing the storefront. for example, time restraints and adherence to our design system were key considerations during the process. Here are some of the other questions we had to ask ourselves:
- How might we structure navigation so items cluster into tiered groups but still appear as standalone products?
- How might we build an information architecture scalable across 150+ countries and various worker types with different legal and practical requirements?
- How might we showcase products when we have minimal data for each?
- How might we engage users in shopping when they can’t immediately purchase what they want in-platform?
Navigation
Navigation and information architecture required a deep analysis of the most likely future categories of benefits to be offered and their relevance. It also needed a clear hierarchy. Eventually, it was clear that worker type and country had to be the first filters that would define the store experience.
Iteration on the detail view
Early mocks showed full comparative plan tables when data availability was unknown, then we added icon-driven insights and charts that required heavy ops support. In the final design we used a simple modal from our design system to display only essential copy, key metrics, and a clear “Request quote” button, dramatically reducing operational overhead.
Designing the Quote Flow
Ideally, users would compare plans and see pricing directly in-platform. Due to technical constraints, clients would request quotes instead, and Deel Operations would coordinate with brokers to deliver them promptly. For this reason, all CTAs should guide the user to the quote flow.
Quoting would require basic info from clients: Country, worker type, intended benefits start date, and most importantly, a selection of benefits to be quoted. The benefits selection step require multiple iterations and conversations to pin down.
Requirements to be considered
- Clients must understand benefits as belonging to different tiered packages.
- Statutory benefits must be selected by default to promote compliance.
- All benefits should have the individual capacity to be deselected to support different use cases.
- Each following package contains the previous one in theory, as per its tiered structure. But the client is not forced to quote by package. They can pick and choose benefits to quote.
To demonstrate the behavior of this page, I vibe-coded several versions of the flow and coordinated with stakeholders from product and development to check usability and consider any technical restraints.
Designing the Admin Tools
Once we defined what the storefront would look like and how it would work for clients, we had to work out how it would all be powered by our ops team. These admin tools could merit a case study of their own, but for brevity’s sake, here’s a summary of what we built:
Benefits by country
Eventually, integrations would be built to have a direct data transfer and display of all the up-to-date information for each benefit product. Before that, we would need to provide a space for ops teams to add, modify, and remove the items manually.
Quote tracker
Admins needed a space for them to track every unfulfilled quote request and communicate at what stage of the service process each one is. A simple status update system serves as the communication system between ops team members.
Referral revenue tracker
This tool is a continuation of the quote tracker. Every fulfilled order is automatically moved to a revenue tracker for admins to understand the impact coming from specific clients, benefit types, carriers, etc.
Broker Directory
Simple enough, a way for admins to know exactly which brokerage company provides services for every different benefit type or package. They can tag preferred brokers for specific sectors and find contact information for the right representative.
Final prototypes
Browsing benefits and requesting a quote
Dark mode and mobile
