Reducing ESOP exercise friction.
Redesigning the ESOP exercise experience for a system used by finance teams and the employees who hold the grants — reducing exercise-related support friction by 70%.

What an ESOP is, and why exercising it is hard
An ESOP — Employee Stock Option Plan — is a promise of ownership. A company gives an employee the right to buy a fixed number of shares at a fixed price, over a fixed schedule. Unlike a product you can hold or a salary that arrives every month, ownership is abstract. It lives inside legal documents, vesting schedules, and valuation reports — and it usually only becomes real years later.
That abstraction is the problem. Employees are being asked to make a high-stakes financial decision — sometimes the largest one of their life — about an instrument they cannot see, in a system they don't fully understand. The product has to do the work that the share certificate, the broker, and the bank statement would normally do for a public stock.
Exercising an ESOP — converting that promise into actual shares — is the single most operationally fragile moment in the lifecycle. It involves taxation, vesting confirmations, liquidity constraints, exercise windows, payment timelines, and dependencies across finance, payroll, and legal.
At every step, the user is being asked to commit real money against an asset they cannot easily sell. Trust is not a feature here — it is the substrate the entire experience has to stand on.
The larger ESOP management system
The exercise flow does not sit on its own. It is the visible tip of a much larger system the finance team runs every day — grant management, vesting schedules, exits, forfeitures, pool accounting, and cap-table reconciliations.
On the admin side, the work is operational: issuing grants, maintaining policy, approving exceptions, reconciling against the cap table, and producing audit trails. A single backdated cliff or off-cycle grant can ripple into weeks of cleanup.
On the employee side, the work is decisional: understanding what's vested, what an exercise window means, what the tax bill will look like, whether to pay now or wait, and what the unit might be worth at a liquidity event nobody can date.
The product has to hold both audiences inside one coherent system — operational precision for the people running the program, and quiet clarity for the people living inside it.
The exercise flow as we found it
The old exercise experience was not one workflow — it was three half-workflows held together by support tickets. An employee would start in the product, drop into email for tax clarification, return to upload PAN, contact finance to confirm the payable amount, and then wait days for a confirmation they couldn't see the status of.
State was opaque. A grant could be exercisable, partially exercisable, locked by a blackout, or pending approval — and the UI gave back the same neutral grey for all of them. The system never told the user where they were, what was happening, or what would happen next. Most users solved this by calling someone.
- FragmentationWorkflow split across product, email, support
- Opaque stateUsers couldn't see where the exercise actually was
- Trust gapNo reassurance during the highest-stakes moment
- Support loadMost exercises ended in a finance ticket
- Operational dragFinance reconciled manually after the fact
Finance teams were not approving exercises so much as re-creating them — checking each one against a parallel spreadsheet, confirming tax math by hand, chasing approvals over chat, and posting to the cap table after the fact.
Holders were being asked to pay real money against an instrument they couldn't value, in a window they didn't fully understand, with no in-product reassurance that the system would do the right thing on the other side.
Redesigning the workflow as a guided system
We rebuilt the exercise around three commitments: a single linear path with no dead-ends, visible system state at every step, and a progressive disclosure of operational complexity so users could focus on the decision in front of them.
The flow was reorganised into four steps — confirm units, review tax, confirm payment, settle — with each step doing the underlying calculation, surfacing only the numbers the user had to act on, and locking in the result before moving forward.
Workflow restructure
The new flow is a single product path. Tax calculations, blackout checks, and post-exercise ownership previews happen inline, in the order they actually matter to the decision.
- 01Select grantESOP-22 · 7,500 vested
- 02Choose unitsUp to 7,500 · enter amount
- 03Tax previewPerquisite + capital gains
- 04ConfirmPost to ledger · notify
Visible system state
Every grant card now answers the three questions employees actually ask — what's vested, when does the next vest happen, and what can I do with it today. Hidden state was the source of most support load; making it visible eliminated most of the tickets.
Progressive disclosure
The default screen shows only what a holder needs to act. Tax derivations, cap-table impact, and audit trails live one level deeper — available, never imposed. Density is opt-in, not the default.
The flow, as shipped
Three moments from the employee-facing exercise flow — the decision, the payment, and the settlement. The same five-step progress bar carries through, so the user always knows where they are inside a transaction that used to disappear into email. Tax and total payment are surfaced before commit rather than after, explicit verification states replace the old wait-and-wonder gap, and the flow closes with a downloadable share allotment certificate — a receipt-style confirmation that reads like a document, not a notification. The result is a single linear path with no dead-ends and no detours into email: the screen tells the user where they are, what is being committed, and what happens next, without ever asking them to leave the product to find out.



Outcome
“Reduced exercise-related support issues and client queries by 70%.”
The qualitative change was larger than the number. Holders stopped asking finance teams to translate their grant for them, finance teams stopped reconstructing exercises after the fact, and the workflow that used to live across product, email, and chat moved entirely inside the system — on a shared object, with a visible audit trail.