Deeply localising Keka's leave setup experience to align with US workforce norms, regulations, and expectations — from geography-aware configurations and compliant templates to native terminology and formats.
US HR and payroll teams must manually build location-specific leave plans that satisfy a complex web of federal and state-level labour laws. Most HR managers don't have in-depth legal knowledge of these statutes — so the effort invested in figuring out compliant leave plans typically stalls HRMS rollouts for weeks.
This results in repeated implementation calls, delayed go-lives, and a growing perception that Keka isn't truly "US-ready." Beyond the friction, misconfigurations carry real financial risk — exposing employers to fines and payroll corrections.
Pre-built, editable, jurisdiction-aware templates simplify one of the most time-consuming tasks in US onboarding. By cutting go-live timelines, the feature directly contributes to earlier revenue recognition and a stronger competitive position in a market Keka is actively expanding into.
Competitors like Rippling, ADP, and UKG already lead with "compliant templates" as a sales lever. The feature has been explicitly requested by multiple existing clients and prospects — making it both a retention and an acquisition play.
In Keka today, creating a leave plan is a multi-tab affair. HRs first create leave types in one tab, then create leave plans in a separate tab. While creating a plan they pick types, configure each one, and assign the plan to teams or employees.
We spoke with several US prospects. Three themes came through clearly:
We studied how Rippling, BambooHR, and Deel approach the same problem to understand what "table stakes" looks like in the US market.



We began solutioning by mapping the ideal end-to-end journey for setting up leave policies — from country selection through template adoption to assignment and review.
We reused a prior time-off setup revamp that had already solved the overwhelming configuration problem — narrowing the experience to 4 essential inputs and surfacing advanced config on demand.
Initially we proposed two templates: one US-compliant and one default for other markets. After internal reviews and prospect conversations, several flaws surfaced:
This made it clear: the architecture itself needed to change.
We flipped the model. Time off types become the top-level entity, and policies sit underneath them — each with its own configuration and assignment rules. This mirrors how US HR teams already think about leave, and removes the rigid bundling that forced plan duplication.
Companies with employees across countries usually have regional HRs. An HR managing the US workforce doesn't need to see policies for India or the Gulf. We list policies by country, reducing cognitive load and the surface area to manage.

Step 1 starts with templates compliant with local labour laws. Companies can opt out of any time off type they don't operate under. For markets like the US where different jurisdictions mandate different policies, we offer a choice: one policy compliant across all jurisdictions, or multiple policies grouped by similar jurisdiction rules.

Step 2 lets companies review added policies and add policies for specific teams. A Compliant badge marks time off types mandated by local law. If a change makes a policy non-compliant, the badge flips to Non-compliant. Custom types carry no badge, since compliance doesn't apply.

HRs can add custom sick time off policies with basic configuration. Since employees may not yet be in the system at setup time, rule-based assignment (team, department, location) is the default mechanism. A note acknowledges complex policies and reassures users that advanced config is available post-setup.

Once the first custom policy is added, the "Add custom time off policy" CTA moves from a banner to the header. If a configuration falls outside what's compliant for the assigned jurisdiction, a Non-compliant badge appears. We notify but don't block — companies sometimes need flexibility, and this respects their judgment.

Companies often offer more time off than the government mandates. Research found that metadata like paid/unpaid, accrual vs. incident-based, and calendar year is largely consistent across policies of the same type within a company — so we promoted these to the time off type level to eliminate redundant configuration.

Once setup is complete, policies go live for employees. This step lets users review everything and step back in to reconfigure before committing.

Once setup is complete for a country, HRs return here to add departments or teams to existing policies, create new policies for specific teams, or reconfigure an in-use policy. The country-scoped view keeps the surface focused.

Because policies are assigned through include-exclude rules, overlaps are inevitable — an employee can end up with multiple policies for the same time off type. Priority order resolves this, mirroring the pattern that worked well in Rippling.

This is the full configuration surface for any time off type. Deliberately surfaced only after initial setup so first-time users aren't overwhelmed by the system's full power upfront.

Make the system feel native to each market without making any market feel secondary.
Notify when users drift out of compliance; don't block them. HR teams know their context better than the system does.
Start with what's mandatory and minimal. Reveal advanced config only on demand.
Mandated, compliant templates eliminate the legal-research burden HRs were never trained for.
Time off types as the top-level entity — not "plans" — because that's how US HR teams already think.
CTAs earn their visual weight only when the user needs them. Once a behaviour is learned, the UI quiets down.
The project is in active development. These numbers come from moderated user testing sessions with US prospects and existing clients, on a clickable prototype with limited configuration scope.
Zero testers missed the assignment step in the new flow, compared to 60% who missed it in the early "leave plan" iterations. Qualitative feedback from US prospects consistently described the new experience as "finally feels built for us."
Compliance is not static — statutes change, jurisdictions update mandated minimums, and companies revise policies year over year. The next phase will introduce:
What started as a request to add "US compliance templates" turned into a much deeper rethink of how leave is modelled in Keka. The biggest shift wasn't visual — it was architectural: moving from leave-plan bundles to time-off-type-led policies, mirroring how US HR teams already think.
The work also reinforced a tension worth designing for explicitly: localising for a new market without making existing markets feel like an afterthought. Country-scoped listings, jurisdiction-aware templates, and a single coherent architecture across geographies were how we resolved it.