Gamification

Context

Groner’s customers run sales and field teams, and they want to reward them. The CRM already paid commissions on proposals and sales — but only on those.

The problem

Customers couldn’t commission or reward any other operation of the company; they were limited to the business rules of proposals and sales inside the CRM. Visits, installations, tasks and service orders — the work that keeps a solar company running — went unrewarded.

My role

I conceived the module and built its first version on my own: a separate service in Bun, Hono and Prisma on ECS, fed by the CRM through SQS. After a teammate ported it into the .NET API, I built the rules and reconciliation engine that runs it today and new goal types, and I maintain the module. Almost all of the front end is mine, too.

Architecture

• Facts from everywhere. About 60 places in the CRM — sales, proposals, leads, tasks, visits, installations, service orders and WhatsApp — report a fact after saving their own data, with everyone involved and their role.
• The engine. It matches each fact against the active goals and applies each goal’s rules — which roles get credit and how much, minimum values, caps, waiting periods, filters by lead source or sale type — before updating progress, the points ledger and rewards.
• Time-based steps. Cycle starts, midpoints, reminders and closings come from a scheduler backed by DynamoDB, deduplicated with idempotency keys.
• For the teams. Rankings, progress projections, levels, streaks and achievements in the front end; redeeming a cash reward creates a payable in the CRM’s finance module.

Key decisions

• Send the total, apply the difference. A fact doesn’t add +1: it states the total it should contribute to each goal. The engine keeps one history row per goal and origin and applies only the difference with an atomic update — so a fact sent twice changes nothing, an edit re-sends the new total, and a delete sends zero and reverses the credit.
• One rule, two paths. Each of the 13 rules has an event version, for live facts, and a query version, used to rebuild a goal from the source tables. A parity test keeps both paths in agreement.
• Money-safe rewards. Points live in a ledger, debits go through only when the balance covers them, and partial cash-outs run in a serializable transaction.

The hardest part

Performance and integrity. Gamification runs inside about 60 operations of the CRM, so it must never slow them down or break them — its errors are logged, never thrown — and it still has to count every fact exactly once.

So rules do no database work per goal, each event loads extra details in a single query and only when a goal needs them, user lookups are batched, and summaries are aggregated in SQL. That last part matters when the database connection pool is shared by hundreds of tenant databases.

Results

• Companies reward the work they care about: 19 metrics, from sales and proposals to technical visits, installations and closed WhatsApp conversations.
• Goals for the whole company, a branch, a team or a person, fixed or recurring, paid in points, cash, on-target earnings or badges — with a points store on top.
• Notifications keep teams on track: at the midpoint, in the last days and when a goal stalls.