Back to work
PM Case Study · Product Research & Strategy

Dynamic Incentive Management CRM

Banks ran sales incentives by hand, with structures that differed by branch, region, and product and changed constantly as new schemes and regulations came in. The manual math meant errors, late payouts, and constant disputes. I researched the problem and mapped the logic for a rule-driven CRM that calculates every incentive automatically and shows its work, the system behind a roughly 60% drop in disputes.

Incentive Management screen
Incentive Management · base payout, quality adjustments, clawbacks and points per rep
ContextKobl · Banking & Financial Services
My roleProduct Research & Strategy Intern
Team4–5 people
TimelineJun – Sep 2025
Methods
Product ResearchSystems MappingRule-Engine LogicFigma Prototyping
01
Research

Understood why a manual, branch-by-branch incentive process produced errors, delays, and disputes.

02
Systems thinking

Mapped every path a payout takes, from rules and roles through compliance checks, clawbacks, and final payout.

03
My contribution

Researched and shaped two features the system leans on: clawback and recovery, and the audit trail.

01 · The Problem

Every branch had different incentive rules, and the math was done by hand.

Incentive structures at a bank vary by branch, region, and product, and they change constantly as new schemes launch, regulations shift, and seasonal offers come and go. Most CRMs lock their commission logic into fixed rules, so every one of those changes has to go through central IT to update. That backlog is why branches ended up calculating incentives by hand.

Manual math at that scale produces errors, late payouts, and, above all, disputes. A rep who can't see how a number was reached has no reason to trust it, and that mistrust chips away at the exact motivation the incentives are supposed to create.

The Real Goal

One system where each branch can define its own rules, every payout is calculated automatically, and the math is clear enough that reps and managers stop arguing about it.

02 · The System I Mapped

I mapped every path a payout could take.

The answer was a rule-driven engine that calculates incentives in real time and keeps a full audit trail. Before any interface existed, I mapped the whole logic end to end: how a payout moves from the rules and the person's role, through the calculation and a compliance check, to clawbacks and the final amount. Every rule change gets logged along the way, so the whole thing stays auditable.

The mapped payout flow across iterations
The payout flow, mapped across three passes. Each pass tightened how a payout moves from the rules through compliance to the final amount.

Iterating on the flow was the real work. Later passes added version logs so every rule change is traceable for compliance, added ESOP eligibility, and made failure explicit: if a payout fails a compliance check, it now routes back to be fixed instead of quietly breaking.

03 · Inside the Rule Engine

Built so the business never has to wait on IT.

The core of the system is a rule engine that branch admins set up themselves, without writing any code. Because the rules are read fresh each time a payout is calculated, a branch can adjust its own incentives the moment a scheme or regulation changes, instead of waiting on IT.

Product-wise slabs & caps

Different incentive bands per product, with thresholds and a maximum cap.

Designation multipliers

The same sale rewards a Senior RM and a Branch Head differently.

Conditional AND/OR logic

Stack conditions, a time-bound campaign plus a product category, into one rule.

Multi-level hierarchy

Branch → Region → Zone → National, with overrides allowed at each level.

Create New Rule screen
Create new rule - a manager sets the incentive logic directly, instead of filing an IT ticket.
04 · How a Payout Gets Computed

From a closed deal to a logged, auditable payout.

01
A deal closes

A rep closes a high-value loan.

02
The engine evaluates

It checks every rule that applies to that product, region, and designation.

03
Incentive is calculated

Computed instantly, and recalculated on status updates or retroactive rule changes.

04
Logged for audit & payout

The full trail is recorded per employee, ready for payout and compliance review.

05 · Transparency & Audit

Every payout, traceable.

Disputes fall when reps and managers see the same numbers and the trail behind them. The system keeps a complete incentive history for every employee and logs each rule change for compliance. The audit trail was one of my two areas, so I prototyped the interface in Figma to show how all that mapped logic turns into something a manager can actually sit down and use.

Dashboard screen, a shared filterable view of every rep's numbers and final payout, exportable to Excel and an audit-format PDF
Dashboard — one shared, filterable view of every rep's numbers and final payout, the clear record the manual process never had. Exports to Excel and an audit-format PDF.

The Incentive Management view (shown at the top) breaks down base payout, quality adjustments, zone bonus, clawbacks, and points per rep, and it surfaces compliance issues at the top instead of burying them.

06 · Impact

60% fewer disputes, 70% faster computation.

~60%
Fewer incentive disputes once calculation became automatic and transparent
70%
Faster incentive computation versus the manual process
0
IT tickets needed for branches to change their own rules
1000+
Branches the rule-driven architecture is built to scale across

It all comes back to one idea: when the math is automatic and every step is visible, disputes have far less to start from.

07 · My Role

Two features came out of my research.

My research mapped how banks actually structure sales incentives, benchmarked that against fintech models, and surfaced where the existing approach fell short. Two features came out of it, and both started as a gap in the research, not a line in the brief.

Clawback & recovery

Closing a sale isn't the same as making a good one. A loan that defaults or a policy that lapses shouldn't keep paying out. I defined the conditions for reversing or recovering a payout based on the quality of the sale, like whether a loan actually gets repaid, instead of just whether it closed. That became the Clawback & Recovery step in the flow.

The audit trail

A disputed number can only be settled if you can trace it. I made the case that every payout should map back to the exact rule, version, and inputs that produced it, so a rule change is logged rather than quietly overwritten. That traceability is why a disagreement becomes a lookup instead of a standoff.

08 · What I Learned

Disputes were really about transparency.

01
Visibility is what built the trust

People don't trust numbers they can't trace. Most of the value here came from making the calculation visible, not from changing the math.

02
The real design work was mapping the system

Building the flow diagram surfaced every edge case early, failed compliance checks, clawbacks, retroactive rule changes, before a single screen existed.

The takeaway

A spreadsheet can hold the numbers. Getting people to trust them is the hard part, and that started with mapping the logic long before I designed a screen.

"I owned the research and the logic underneath. Everything people saw on screen sat on top of that, and the trust came from being able to trace every payout."
Back to all work