Dsquares Loyalty: Transparent Wallet & Earning Engine

The loyalty app had strong reach — most logged-in users browsed for extended sessions — yet only 70% of them converted into an actual transaction. The application behaved like a passive catalog, leaving users in a state of decision paralysis when faced with high-value but abstract offers.

In parallel, support was spending an outsized share of its week answering the same two questions: why is my voucher expired, and why is this code already used. Both complaints traced back to the same root cause — users could not see the rules that governed their benefits, and the cart validation API failed loudly on edge cases rather than recovering gracefully.

• 30% drop-off between login and first transaction — the activation chasm
• No structural urgency or transparent earning logic to nudge browsing toward action
• Users unaware of voucher expiration windows and minimum-spend criteria until failure at checkout
• Cart validation API hitting race conditions during peak traffic and disconnected retail POS states
• Repeated support tickets that the application itself could have prevented

The redesign shifted the app from a passive catalog into an active, utility-focused transaction companion. Instead of rebuilding the catalog, three initiatives were evaluated against the RICE framework and sequenced by impact, not by elegance.

• Initiative 1 — Transparent Earning Ledger: a clean, tabular UI on the home screen detailing exactly how points are computed across different retail brands, removing calculation confusion during browsing.
• Initiative 2 — Real-Time Wallet & State Engine (the chosen focus): a full wallet overhaul replacing static lists with explicit utility-driven states ('Active,' 'Expiring in X Hours,' 'Criteria Not Met'), paired with time-sensitive push alerts before vouchers lapse.
• Initiative 3 — Proactive Cart Error Guard: enhanced cart validation API that gracefully degrades on edge-case failures — caching token states locally and surfacing clear, actionable error messages instead of generic crashes.
• API synchronization via webhooks between retail brand POS networks and the loyalty core, so an offline redemption propagates to the app database instantly and prevents 'already used code' replay attacks.
• ISO 8601 UTC timestamp normalization across multi-brand databases, so a user's app and a brand's backend agree on whether a voucher is still active.
• Intelligent local caching of voucher criteria rules for sub-200ms cart validation feedback, even during partner-server micro-downtimes.

Initiative 2 was selected first because it directly addressed the activation drop-off while systematically clearing the support ticket backlog — high reach combined with straightforward backend logic. The work was scoped from a single user story, expressed in Gherkin syntax that engineering could split into Linear/Jira epics.

• User story: 'As a loyalty app user, I want to view the exact expiration countdown and required purchasing criteria of my vouchers directly inside my wallet, so that I can confidently complete my transaction before my benefits expire without encountering cart errors.'
• Scenario — Active voucher near expiry: given the user is in 'My Wallet,' when a voucher is within 48 hours of expiration, then a high-visibility countdown renders (e.g., 'Expires in 23h 14m') alongside brand criteria (e.g., 'Valid on online orders over 500 EGP').
• Scenario — Unfulfilled criteria at cart: given the cart totals 300 EGP, when the user applies a voucher requiring a minimum spend of 500 EGP, then the API returns 'Add 200 EGP more to unlock this voucher' and blocks an invalid payload from reaching the partner POS.
• Three Amigos alignment sessions (PO, QA Lead, Tech Lead) before sprint planning ensured edge cases in the data layer were accounted for before any code was written.
• Phased rollout isolated the new wallet engine to a single retail brand ecosystem first to monitor technical stability before wide-scale release.

The wallet stopped being a list and became a decision surface. Browsing users could see exactly what to do next, and the cart stopped being a place where benefits died.

• Primary KPI — Login → first transaction conversion moving from the 70% baseline toward an 85% target.
• Operational KPI — 40% reduction in support tickets tagged 'Expired Benefits' or 'Invalid Codes' within the first 30 days of full release.
• System KPI — Cart code validation latency held under 200ms at p95, even during peak traffic.
• Trust KPI — 'Already used code' complaints replaced by proactive push alerts before vouchers lapse.