Snabba PucksSNABBA·PUCKS
ARBETE/CASE STUDIES/GAMIFICATION-SYSTEM
PROJEKT 03 / GAMIFICATION ENGINE

Gamification-system.

Engagement-motor för konsumentplattform. Systemtänk över feature-tänk.

Vad handlar projektet om?

Engagement-motor för konsumentplattform. Systemtänk över feature-tänk. Byggt av Snabba Pucks med Python, FastAPI och Next.js. Mätbar ökning i användarengagemang och retention

01/BAKGRUND

En konsumentplattform hade ett klassiskt engagement-problem: användarna kom in, gjorde det de skulle, och försvann. Klassiska gamification-lösningar — badges på allt, leaderboard överallt — skulle förmodligen ha gjort det värre snarare än bättre. Användarbeteende ändras inte av att man slänger poäng på det.

Uppdraget var att designa och bygga en engagement-motor som faktiskt påverkade hur människor använde plattformen — inte bara visuellt dekorerade den.

02/VAD VI BYGGDE
01 / BETEENDEKARTLÄGGNING

Innan en enda komponent byggdes: kartläggning av vilka faktiska användarbeteenden som var värdefulla för plattformen, vilka som var fyllnadshandlingar, och var den verkliga friktionen låg. Gamification utan beteendemodell är dekoration.

02 / REWARD-SYSTEM

Belöningsstruktur designad runt de specifika handlingar som faktiskt skapade värde för användaren och plattformen. Variabel reinforcement där det funkade, fast belöning där det behövdes. Inga badges för sakens skull.

03 / STREAK & RETENTION

Återkommande mönster och streak-mekanik byggd för att skapa daglig vana utan att kännas tvingande. Reset-logik som inte straffar användaren för att leva ett liv. Återkomst-incitament utan dark patterns.

04 / PROGRESSION-VISUALISERING

Tydlig visuell feedback på framsteg utan att överrösta huvudprodukten. Subtila signaler snarare än konfetti-explosioner. Progressionen ska kännas, inte annonseras.

05 / REAL-TIME LOGIK

Snabb implementation av komplex backend-logik för poängberäkning, streak-tracking och belöningsutdelning. System som svarar omedelbart utan att tappa konsistens vid hög belastning.

INSPEKTION
Kvalitetsmätning
Show-Up Rate per säljare
MAJ 2024 · ANONYMISERAT
Sara L.56%
Magnus R.52%
Erik P.32%
Johan K.16%
SUR mäts enbart på möten vars datum passerat — framtida bokningar räknas inte in. Ger rättvisare bild än volym.
Escrow-principen
Poäng frigörs vid show-up
Bokning skapad+10 pts
mötet genomförs →
Escrow frigörs + bonus+50 pts
avbokning / no-show →
Escrow förverkas0 pts
Eliminerar luftbokningar. Säljaren tjänar bara poäng när kunden faktiskt dyker upp — inga direkta minuspoäng.
Anti-gaming detektion
Synlig enbart för manager
Sena ombokningar
Ombokning <3 dagar före möte → escrow halveras automatiskt
Lead-återanvändning
Samma lead bokas 3+ gånger → lead låses, inga fler poäng
Volymanomalier
Hög bokningsvolym + låg SUR → manager-alert, tyst för säljaren
24% av bokningarna var sena ombokningar (<3 dagar) — identifierat och mätt direkt från CRM-data.
Personlig provisionskalkyl
Baserad på faktisk SUR
EXEMPEL · SARA L. (SUR 56%)
Genomförda möten
14
Provision intjänad
0 kr
För att nå 5 000 kr:
Boka ~11 möten till (56% SUR → 20 genomförda)
Generell 50%-regel hade sagt 20 bokningar — Sara behöver bara 18.
Systemet räknar med din faktiska show-up rate, inte en schablonregel. Mer rättvist och motiverande.
Kundcase — B2B mötesbokning · 16 säljare · CRM-integration mot Puzzel Sales Intelligence · Alla namn är anonymiserade
03/SPECS
TIMELINE
Intensiv build-sprint
TYP
Engagement-system / R&D
DOMÄN
Konsumentplattform
DELIVERABLES
Systemdesign · backend · integration · spec
FOKUS
Beteendemodell · retention · daglig vana
STATUS
Implementerat
04/ARKITEKTUR
BACKEND

Real-time scoring engine · streak-logik · belöningsutdelning

PIPELINE

Event-driven arkitektur · idempotent action-processing · konsistent state vid samtidiga handlingar

05/RESULTAT
  • Mätbar ökning i användarengagemang och retention
  • Daglig återkomst utan tvingande mekanik eller dark patterns
  • System byggt för att skala med plattformens tillväxt utan refactoring
  • Demonstration av att gamification med beteendemodell slår gamification utan
06/LÄRDOMAR
  • ·Beteendemodell måste komma före feature-lista — annars bygger man fel reward-system och förstärker fel handlingar
  • ·Streak-mekanik utan grace-period skapar churn snarare än engagement — människor lever liv som inte alltid är linjära
  • ·Tysta signaler i UI presterar ofta bättre än explicita belöningar för långsiktig vana
  • ·Real-time konsistens vid samtidiga handlingar är svårare än det låter och måste designas in från början

Tänkte du på något liknande?

Vi tar uppdrag där komplexiteten är reell och deadlinen nära. Vad behöver du byggt?

Boka samtal →