Skip to main content

Case Study — Gamification · Enterprise training

Atmos Advisor — Training 30,000 employees for Alaska's biggest loyalty launch

Built a production gamification system to prepare 30,000+ Alaska Airlines employees on the Atmos Rewards loyalty program before its public launch. The game ran under real enterprise load, survived a production failure on launch day, and performed well enough for the client to request it be turned into a reusable platform.

  • TypeScript
  • React
  • Staffbase Plugin API
  • JWT
  • OAuth
  • Supabase
  • Redis
  • GCP
  • Kubernetes
30K+Employees on platform
1,565Users on day one
13Days before public launch

Why this project existed

In 2025, Alaska Airlines launched Atmos Rewards — a complete overhaul of its Mileage Plan loyalty program, unified with Hawaiian Airlines' HawaiianMiles following their $1.9B merger. It became the #1 airline rewards program according to U.S. News & World Report and closed the year with 890,000 status holders. It was the biggest product launch in Alaska's recent history.

Before that launch reached passengers, it had to reach 30,000+ employees: the pilots, flight attendants, gate agents, and ground crews who would be answering questions about it from the moment it went live. An email announcement was not going to be enough. Alaska Airlines needed something employees would actually engage with — something that would make the program memorable, not just readable.

Favish, in collaboration with LocalWisdom, was contracted to build that training experience: a gamified quiz embedded directly into Team AAG, Alaska's enterprise employee platform used by the entire organization daily. I was the engineer who built it.

The game concept

The design was scenario-driven and narrative. Employees took on the role of a "Loyalty Coach" — guiding fictional travelers through real travel situations and choosing the optimal Atmos Rewards strategy for each one. Each decision had downstream consequences on point accumulation, shown in real time through a visual "dot-game" mechanic inspired by games like GeoGuessr: dots shift to reflect the quality of your choice as you make it.

The game wasn't designed to be completed once and forgotten. It was built for replayability: 20+ scenarios, speed-based scoring, a live leaderboard segmented by division and location, and a challenge mode where employees could compete asynchronously with teammates across the organization.

What I built

  • Full game frontend — quiz flow, scenario rendering, answer feedback with visual explanation, dot-game mechanic, animations, and responsive layout for both desktop and Staffbase mobile app.
  • ELO/XP scoring system — dynamic score that increases or decreases based on expected difficulty per question and response speed. Made the leaderboard competitive and difficult to game, unlike a simple points counter.
  • Real-time leaderboard — segmented by company, division, and location across Alaska Airlines, Horizon Air, and McGee Air Services. Showed live rankings during gameplay and as a standalone Staffbase widget on the Team AAG homepage.
  • Multi-tenant architecture — Staffbase plugins share the same domain across all instances (dev, test, LocalWisdom partner env, production). Designed and implemented a complete multi-tenant system using branch_id as instance identifier so that users, scores, and configurations stayed strictly isolated between environments. This was not in the original spec — I identified the need during development and built it before it became a production incident.
  • JWT authentication for Staffbase mobile — Staffbase has no official OAuth support for plugins running inside the mobile WebView. Implemented a custom JWT extraction and storage flow with HTTP-only cookie handling to keep tokens out of the URL bar (where sharing a link would accidentally expose a session token) and validate context per plugin instance. Worked directly with Staffbase engineering to resolve platform-level constraints.
  • Supabase backend — multi-tenant schema for games, individual answers with timestamps (used for cheat detection), per-user score history, leaderboard state, and admin management data.
  • Redis caching layer — added after launch when the system started degrading under real load. Cached critical query paths, invalidated per-game, and reduced Supabase pressure. Admin panel went from timing out to instant.
  • Cheat detection — post-launch data showed answer submissions with near-zero response times, indicating automated inputs. Built analysis and filtering logic to identify and remove invalid entries and preserve leaderboard integrity.
  • Admin panel — internal dashboard for question bank management, user data export, contest winner selection by date range, and score administration.
  • Deployment on GCP/Kubernetes — separate environments for dev, test, and production, with the game served from the Favish cluster and embedded into Team AAG via the Staffbase plugin iframe system.

The launch

The game went live on Team AAG on September 18, 2025 — thirteen days before the October 1 date when HawaiianMiles officially converted to Atmos Rewards and employees would start receiving passenger questions about the program.

The system fell over under load on launch day. With 1,565 users already on the platform in the first hours, Redis wasn't yet in place, the leaderboard was serving stale data, the admin panel was timing out, and the team had to temporarily pull the game from production while fixes were being applied.

I spent fourteen uninterrupted hours diagnosing, deploying, and verifying fixes — implementing Redis caching across the critical paths, correcting the leaderboard query logic, stabilizing the admin panel, and restoring the game to production. At the end of that session, with the system running cleanly under load:

"All the bug tickets should now be resolved. Everything is cached with Redis, so it should be running much faster now. I'm signing off for today since I've been at it for 14 hours and can barely think straight."

— Cristian, #alaska-atmos Slack, September 22, 2025

After launch

Following the initial stabilization, two further improvements were added based on data from live usage. First, the ELO/XP system was introduced mid-contest to make the leaderboard more dynamic and resistant to early-mover advantage. Second, a monthly leaderboard reset mechanism was added so the contest could remain active and competitive beyond the initial launch window.

The data showed the game engaging a meaningful cross-section of the workforce — enough that the team was also handling edge cases like employees competing unusually hard at the top of the board.

Outcome

The game fulfilled its primary purpose: Alaska Airlines employees had hands-on, scenario-based familiarity with Atmos Rewards before the program reached passengers. Atmos went on to win the #1 airline rewards program award from U.S. News & World Report and NerdWallet, closing 2025 with 890,000 status holders.

The more specific outcome for this project: David Henrich, Senior Manager of Communication Operations at Alaska Airlines, liked the result well enough to request a development estimate for turning it into a reusable internal platform — a generalized gamification system that could be deployed for future company programs. That request came directly from the client and reflects the most explicit validation that appears anywhere in this engagement.

What made this technically hard

The Atmos game was harder to build than it looked for reasons that weren't in the original spec. Staffbase doesn't support multi-tenancy in its plugin model — you get one domain, all environments share it, and it's your problem to keep data isolated. Staffbase doesn't support OAuth for mobile WebView plugins — you have to design your own JWT extraction and storage flow and convince it to work inside a sandboxed iframe on a mobile app. And production load at this scale doesn't behave like staging — the leaderboard logic that worked fine in testing fell over immediately when real users hit it simultaneously.

Each of those problems was identified, designed around, and resolved — some before launch, some under live pressure on the day. That's the kind of engineering this environment required.

Start with the right context

I am open to Staff / Senior Staff product roles and long-term contracting engagements. The useful first message is different for each.

Hiring team

Send the role, level, location constraints, interview process, and compensation range if available.

Client engagement

Send the product context, current system, timeline, team shape, and where ownership is missing.