Agent Gamification Platform
A gamification platform for sales agents — regional teams compete over a season with a live leaderboard, tiers, achievements, and redeemable offers.
- Liveleaderboard over SignalR
- 3roles: agent, admin, master
Tech stack
- C#
- .NET
- ASP.NET Core
- Entity Framework Core
- SignalR
- Angular
- PostgreSQL
How it works
- 1Sale verified
- 2Score attributed to region/team
- 3Standings recomputed
- 4Live push to dashboard
- 5Tier/achievement check
Problem
A gamified platform to drive sales-agent engagement — agents are grouped into regional teams that compete over a season, with a live leaderboard, tiers, achievements, and redeemable offers.
Why it was difficult
Every verified sale needs to update a live leaderboard in real time and roll up into team standings without the leaderboard read path becoming a bottleneck as agents and sales grow. Access also needed three distinct roles — agent, admin, and master — with a two-level manager hierarchy layered on top.
Architecture
A .NET Web API backend (controllers, services, DTOs, an EF Core data layer) sits behind a SignalR hub that pushes typed real-time events — a sale, a tier upgrade, an updated leaderboard — to an Angular single-page app. One background service periodically recomputes live match scores from verified sales; another periodically snapshots the leaderboard for fast reads.
Technical approach
Leaderboard reads stay fast by maintaining running totals per agent and per team that update the moment a sale is verified, rather than aggregating from raw sales data on every page load. Role-based policies gate what each of the three user types can see and do.
Implementation
JWT-based auth with short-lived access tokens and longer-lived refresh tokens, plus password hashing and Swagger-documented endpoints throughout the API.
Challenges
SignalR client connections cannot always attach custom authorization headers, which conflicts with the header-based JWT scheme used everywhere else in the API.
Solution
The real-time hub accepts the JWT as a query-string parameter on its connection path specifically, while every other endpoint keeps standard header-based auth — a narrow, contained exception rather than weakening auth everywhere.
Evaluation
Not documented — no automated tests exist yet for this project.
Results
Not documented — ask Suraj for real engagement numbers if he wants them included.
Future improvements
The project currently runs against an in-memory database for local development, with a documented manual step to switch to a real production database as the clear next step.
Want something like this built?
Let’s talk