SERVICE DESIGN / A PERSONAL TAKE
The ticket counter is not the scoreboard.
A service desk can borrow the best parts of game design without turning its employees into contestants on a productivity game show.
Long before I was building actual games, I was asking a dangerous question at work: what would happen if the service desk borrowed a few ideas from games?
Not badges for answering the phone. Not a leader board where somebody wins because they closed the most tickets on a slow afternoon. I mean clear goals, visible progress, meaningful teamwork, and a reason to get better at the job.
The trap: measure a number, get more of the number
Tickets closed is easy to count. It is not the same thing as problems solved. A technician who closes twelve password resets can look more productive than the person who spends a morning unraveling a recurring network failure. That is not a game you want to reward.
In an earlier service-desk planning document, I proposed gamification alongside knowledge management, automation, training, problem management, and better metrics. The point was to improve a growing support organization as a system. The proposal is evidence of the design direction, not proof that an experiment delivered some miraculous percentage increase.
Reward behavior you would like to see more of
Progression ought to reflect useful contribution: a properly resolved customer issue, a reusable knowledge article, a good handoff, a root-cause fix, a teammate brought up to speed. Some jobs deserve more credit because they require more judgement or produce lasting value.
That is a proposed scoring philosophy, not a live production metric. A score should never become an excuse to ignore work that the scoring system does not understand.
Make the game cooperative
The most valuable improvements tend to be collective. Good knowledge is shared. Escalations involve multiple teams. One technician fixes the immediate incident; another discovers why it keeps happening; a third makes sure the fix survives next quarter. If only one person gets the points, the system is teaching the wrong lesson.
Think team quests, optional skill paths, peer recognition and visible milestones. Keep participation voluntary where practical, review the scoring for unintended incentives, and give technicians a way to challenge errors. A competition can be fun. A compulsory performance-surveillance carnival is something else.
The actual win condition
Customers should spend less time waiting. Agents should have more agency and fewer pointless repeats. Support should become easier to operate as it grows. If the scoreboards go up while all three get worse, the game design has failed.
I still believe there is something powerful here. The trick is remembering who the game is for: the people doing the work and the people depending on it.
The best leaderboard might be the one showing how much unnecessary work the team eliminated.
Personal commentary and work-in-progress thinking. Historical workplace material is used only as private research context; this page does not disclose private operational records. Descriptions of planned features are not claims of released software.