EVEREE —
Eliminating friction: building a smarter rehire workflow for recurring workers.
Product Design Project
Service: Desktop Application (Admin/Worker), Mobile Application (Admin/Worker)
Team: Myself, Team Flerken Dev Team, Product Manager
Timeline: February - March 2026
Toolkit: Figma / Figjam, Pendo, Mobbin, Maze, Pastel
Everee is a leading payroll platform built for the complexity of gig and staffing agencies.
Everee has positioned itself as one of the leading payroll platforms for gig and staffing agencies. With a strong foundation in workforce management, the platform serves clients who rely on flexible, recurring labor — making seamless worker lifecycle management a core product priority.
THE COMPANY
CONTEXT
Rehiring a returning worker meant duplicate profiles, a support call, and a mess of data.
One of the most significant product gaps within Everee was the lack of a native rehire process for recurring workers. When a previously separated worker needed to be brought back, admins had no way to rehire them directly. Instead, they were forced to create an entirely new worker profile and contact Everee's customer support team to manually merge the two accounts on the backend. This workaround created a confusing tangle of duplicate data, placed unnecessary burden on both admins and the CS team, and introduced friction at a moment that should have been routine.
The solution? Design a self-serve rehire flow — no support ticket required.
The goal was to build an intuitive, self-serve rehire flow directly into the Everee platform — one that allowed admins to bring back a separated worker in just a few steps, without ever needing to contact support. Rather than creating a new profile, admins could locate an existing separated worker, initiate a rehire, and configure any updated details like role, pay rate, or start date — all within a single, guided experience. This not only eliminated duplicate profiles and preserved the integrity of historical worker data, but also significantly reduced the volume of rehire-related support requests. The result was a faster, cleaner workflow for admins and a more scalable process for Everee's internal teams.
PROBLEMS
Rehiring exposed deep cracks across data, compliance, and support — all at once.
Data Integrity: Duplicate profiles led to fragmented payment histories, inconsistent worker records, and unreliable compliance reporting.
Tenure & Leave Complexity: No clear ruleset existed for calculating tenure across employment gaps, and known failure states made leave balance carry-over unpredictable.
Tax & Compliance Risk: SUTA wage bases were incorrectly reset with each new profile, creating inaccurate state tax filings and putting clients at regulatory risk.
Worker Type Conflicts: Rehiring under a different classification — such as W-2 to contractor — introduced unresolved edge cases around authentication and legal record-keeping.
Fuzzy Matching Fragility: Rehire detection relied on email and phone matching, a fragile system prone to false positives and missed matches.
Support Dependency: Every rehire required a manual CS intervention, making the process completely unscalable as Everee grew.
THE PROCESS
CONDENSING CONTENT AND WORKING AROUND DEVELOPER CONSTRAINTS
Data Integrity: Duplicate profiles led to fragmented payment histories, inconsistent worker records, and unreliable compliance reporting.
Tenure & Leave Complexity: No clear ruleset existed for calculating tenure across employment gaps, and known failure states made leave balance carry-over unpredictable.
Tax & Compliance Risk: SUTA wage bases were incorrectly reset with each new profile, creating inaccurate state tax filings and putting clients at regulatory risk.
Worker Type Conflicts: Rehiring under a different classification — such as W-2 to contractor — introduced unresolved edge cases around authentication and legal record-keeping.
Fuzzy Matching Fragility: Rehire detection relied on email and phone matching, a fragile system prone to false positives and missed matches.
Support Dependency: Every rehire required a manual CS intervention, making the process completely unscalable as Everee grew.
The old experience which was a clunky, double-paned experience with percentage-based limitations that only applied to bulk enrolling workers.
The smaller, flexible policy balance transfer that allows admins to enter starting PTO balances for the rehired worker in a more condensed slideout.
-
![ljk]()
Step 1:
Admin navigates to the separated worker’s profile and selects the “rehire” button.
-
![]()
Step 2:
Review the job details page (the form will be autofilled where possible from the worker’s previous employment.)
-
![]()
Step 3:
Navigate through the worker role and benefits page. For security and compliance reasons, we cannot automatically restore previous benefits and deductions. Select “add” to navigate to the next step.
-
![]()
Step 4:
Fill out and add any applicable benefits and deductions to the worker.
-
![]()
Step 5:
The admin selects whether they want to enroll their worker in a PTO policy. If the worker was NOT paid out their leave balances upon their last separation, there may be leave balances that the admin can restore. Note that in some areas, there are laws and regulations that stipulate that certain leave types MUST be restored if hired again within a certain time frame.
-
![]()
Step 6:
If the admin decides that they want to enroll the worker in a leave policy again, they select which policy to enroll the worker in.
-
![]()
Step 7:
The admin then chooses what balances (if any) to award to the worker upon their rehire date. If the worker has historical leave balances from their previous employment, those will populate as a read-only column.
-
![]()
Step 8:
The worker confirms their PTO policy balance selections. Any historical data from their previous employment will be overriden at this point, but if the admin wishes to make changes to their rehire starting balances, they may do so later.
-
![]()
Step 9:
The worker fills out the rest of the second page of the form and confirms that to the best of their knowledge the information they have entered is accurate. This will unlock the “rehire worker button.”
-
![]()
Step 10:
As a final confirmation, the admin is informed of the consequences and timeline of rehiring a worker and makes the final decision. Yay!!
DESIGN DECISIONS
MAKING HARD CALLS ON DESIGN AND USER EXPERIENCE
Several decisions on this project required balancing competing priorities: user clarity, technical feasibility, compliance requirements, and team capacity. Here are the ones that shaped the design the most:
Challenge
TENURE HAS NO CLEAN ANSWER
Design response
Rather than picking a tenure calculation method for admins, I designed a prompt that surfaces the worker's total prior tenure and asks whether to carry it over. The system supports a manual override so admins can honor company-specific policies. Two calculation models were documented as options for future engineering implementation.
Challenge
Design response
FUZZY MATCHING IS FRAGILE
The detection logic relies on email and phone — a system prone to both false positives and missed matches. I designed the match confirmation step to show enough worker detail (name, last role, prior hire date) for admins to make an informed judgment, rather than auto-resolving. The "no match" path is always one click away and drops cleanly into the standard Add Worker flow.
Challenge
Design response
REHIRE DATE DETERMINES AVAILABLE OPTIONS
If the rehire date is in the future, admins get a "Cancel Rehire" option that cleanly undoes the action. If the date is in the past or today, they go through the separation experience to correct course. This branching logic was designed as a clear, upfront date selection — preventing admins from getting deep into configuration before realizing they've entered the wrong date.
Challenge
Design response
LEAVE BALANCE UI WAS BUILT FOR BULK, NOT INDIVIDUAL USE CASES
The existing enrollment UI was a heavy, double-paned percentage-based flow designed for bulk operations. For a single rehire, it was completely disproportionate. I built a compact, flexible balance input within the rehire slideout — allowing admins to enter specific starting balances without switching contexts or loading a separate enrollment tool.
Challenge
Design response
BENEFITS/DEDUCTIONS CAN’T BE RESTORED ARBITRARILY
Unlike leave balances, prior benefit and deduction records can't be automatically re-applied — plan terms, eligibility windows, and rates may have changed. I designed the benefits step as an "option to add, not restore" — presenting prior enrollments as reference, not preselected, and prompting the admin to configure new enrollments intentionally. Ended ECDs from previous employments are explicitly hidden to avoid confusion.
DESIGNING FOR THE UNHAPPY PATH :((
REHIRES V2: MERGING EXISTING ACCOUNTS
I knew that we couldn’t just design the “happy path” and pray. Admins would likely continue with their existing workflows, where they would try to add a new account for a worker even if it was a rehire. Even though rehires was released without this feature due to time constraints, we knew that solving this issue would have to be done quickly after release.
Our solution was to perform a fuzzy-logic check after the admin input the basic identifiers for a worker: legal first name, middle name, last name, phone number, and personal email address. We would search our database for a possible match and then surface it to the admin as the previous worker record and leave the final decision up to them: they can then choose to merge the two accounts into one record, or, in the case that the profile does not belong to the rehired worker, they can continue on to add it as a new record.
THE END RESULT
WHAT THIS PROJECT ACCOMPLISHED
01—
Fewer customer service tickets and feature requests from admins requesting this feature.
This project was one of the most complicated projects I’ve done, because it touched almost every experience in Everee: payroll, benefits and deductions, onboarding, et cetera. It was so gratifying to be part of a project to solve one of the most requested features. Not only will this impact a large portion of our customers, but this empowers Everee to grow and scale into the future with ease.
Previously, there was no way for admins to rehire a worker. They would have to create a duplicate, and then one of our devs (usually our CTO!!!) would have to go into the back-end to merge the two worker profiles in the backend.
01—
Improved scalability: bigger companies can use Everee with ease, with less intervention, with improved flexibility to support seasonal and gig staffing.
01—
1 unified worker profile with a preserved history and no duplicates.
THE FUTURE
What I would do differently, or next:
A more unified and seamless on-boarding experience for workers.
The "welcome back" notification to rehired workers is currently the same as a standard onboarding email. A "Welcome Back" message variant — one that acknowledges the returning worker and confirms what's been restored — would meaningfully improve the worker-facing experience and is a low-effort, high-signal touch.
Longer term: now that we have three entry points producing structured rehire data, there's an opportunity to surface rehire analytics in the admin dashboard — tracking patterns like average time-to-rehire, most common rehire roles, and seasonal spikes. That data could directly support workforce planning conversations for admins.
Thanks for getting this far! Want to see more of my work?
-
![]()
ORACULI:
increasing conversion and legitimacy for a non-profit through a site redesign.
-
![]()
THRIVE:
empowering struggling college students through a task breakdown focus app.
-
![]()
TOGATHER:
increasing attendance rates for social events through genuine connections.
