Transformed fragmented scheme creation and execution workflows into a structured, stage-driven system with clear ownership and visibility across actors
Context
ILMP (Name changed for NDA reasons) is a loyalty management system built for industries where purchase decisions are driven by field influencers like mechanics, repair personnel, and micro influencers, not end customers.
The goal is to incentivize these users so they repeatedly choose and recommend the brand.
Scope of the case study
The case study focuses on the upstream system that enables scheme creation across multiple products, SKUs, and geographies, and generates coupons for each scheme.
It covers how these coupons are allocated across a chain of vendors involved in printing and packaging.
These vendors print physical coupons and embed them into different packaging components, which are then integrated into the production process at the factory level and become part of individual product units.
The problem
A scheme is defined across multiple stages and stakeholders, but executes as independent coupon units across vendor chains.
These units move asynchronously with dependencies, making execution fragmented and hard to track.
The challenge was to structure this system and enable clear, end to end visibility from definition to execution.
Challenge breakdown
In managing scheme the challenge was to make stage-wise progress and ownership clear at a glance, so users know what needs action and where things are stuck without opening each scheme.
Scheme landing page
Design decisions taken
Stages are shown as a dedicated list within the scheme. This makes the full lifecycle visible at once and shows what is pending, in progress, or not started.
Grouped scheme inputs into five steps around distinct decisions to keep each step focused
Turned complex incentive logic into simple, readable rules by separating eligibility and outcome
The most critical step was the last step where the bonus rules are defined on top of base coupon values.
Bonus rules mix different conditions like tier, region, and user actions, which makes it easy to miss or misconfigure something.
Defined a simple condition → reward model where each rule clearly shows who qualifies and what they get
Added a final checkpoint where the entire scheme is visible and can be reviewed and edited if required, before committing
Three models were explored for distributing execution among vendors
Finally the consignment model was chosen
Execution distributed among vendors through consignments
Supporting thought process
Vendors access assigned consignments through their portal, carry out production, and dispatch them to the next vendor in the chain.
Tracking becomes complex when consignments are created as a single unit, but vendors dispatch them in batches based on operational constraints.
The tracking model was designed in such a way that business users track overall progress through a consignment, while underlying batch movement drives real progress.
This separation allows the system to remain simple at the tracking level while supporting complex execution underneath
Edge cases handled
One major outcome that was achieved
Reduced execution delays and follow-ups
Clear ownership, stage visibility, and batch tracking removed ambiguity in who needs to act and what’s pending.
Schemes moved faster with fewer manual follow-ups across teams.