The gamification of operations

Some of the most popular games of the last twenty years ask players to do operations management. In Factorio and Satisfactory you design production lines, balance throughput and hunt for the machine that is holding everything else back. In theme park and hospital games you watch queues, hire staff and decide where the next investment goes. People pay for these games and play them for hundreds of hours, voluntarily, after work.

Then they go back to work and use operations software that nobody enjoys. Production systems, warehouse tools, booking systems and point of sale terminals collect excellent data and present it as tables, alarms and settings menus. Supervisors read reports after the shift. Owners open dashboards when something has already gone wrong. The data is there, but the picture of the operation lives in a few experienced heads.

We think the interface that games developed for running a pretend operation is the better interface for running a real one, at every scale from a three-chair hair salon to a factory hall. This is a blueprint for that idea.

What the games understood

The gamification we mean is the tycoon game. You are not rewarded for using a tool. You run the whole operation, you see all of it at once, and every decision you make shows up in the world in front of you. That is the part worth bringing into real operations.

They show the operation as a place. In a factory game you do not read that work in progress has risen at station six. You see parts piling up in front of it while the stations after it sit idle. The number is still there if you want it, but the first signal is visual and anyone in the room understands it.

They connect a decision to its consequence. Add a machine, change a route or move a worker, and you see the flow change within seconds. Real operations have the same cause and effect, but the feedback arrives in next week's report, mixed with everything else that happened, so nobody learns which change did what.

They let you try before you commit. In a game, a bad layout costs nothing. You rebuild it. In a real factory, a bad decision costs a shift of output. That difference is the reason simulation matters so much.

They always show the next step. There is a constraint holding the system back and the game makes it obvious. This is not a new idea in management. Eliyahu Goldratt built the theory of constraints on it in the 1980s and wrote a novel, The Goal, to teach it to factory managers. Factorio teaches the same lesson to millions of people for fun. The mental model already exists in a whole generation of workers. Their tools just do not use it.

The same idea at three scales

In a hair salon with three chairs, the owner opens the app in the morning and sees the salon from above: the chairs, today's bookings arriving as customers through the day, and a gap at two in the afternoon shown as an empty chair. Next to it is one suggestion. Five regular customers who have booked that slot before are due for a cut. Send them an offer. In the evening the view replays the day, and over weeks the owner starts to see what the booking report always contained but never showed.

In a mid-sized production company, the shift lead sees the line as a flow of parts through stations. The station that is limiting output today is highlighted, with the reason next to it: a slower changeover, a missing operator, a machine running below its usual speed. Before moving two people from packing to assembly, the lead can play the change forward and see what it does to the end of the shift. The plant manager sees all lines at once, the way a player zooms out from one production chain to the whole map.

In a warehouse, orders arrive as a stream, pickers move through the aisles, and the zones where pickers wait for each other show up as congestion on the floor plan. Moving the twenty fastest-selling products closer to packing becomes a decision you can test in the view before anyone carries a box.

The engine underneath is the same in all three. It reads what happened from the systems the operation already runs, builds a live model of it, shows that model as a place, and uses it to suggest and simulate the next decision. What changes between a salon and a factory is the data source and the depth of the simulation, not the idea.

Why this is possible now

Industry already has a version of this. Large manufacturers build digital twins: detailed simulations of plants and lines, often made with the same game engines used for entertainment. But those twins are tools for engineers, built for planning projects and commissioning lines. They are expensive and rarely open on the screen of the person running the shift. The opportunity is not to invent the digital twin. It is to bring it to the people who make operational decisions every hour, in a form they want to use.

Three things make that affordable now. The data exists in almost every operation, from machine controllers and production systems in a factory to the booking tool and card terminal in a salon. Game engines and the skills to use them are cheap and widely available. And AI closes the last gap: turning messy, inconsistent data into a usable model, and turning that model into a short suggestion written for the person who has to act on it.

The line it must not cross

There is a darker version of this idea, and it already exists. Some delivery and warehouse operators have used game mechanics to push workers to go faster, with streaks, rankings and rewards designed to keep people working past the point where they would otherwise stop. It works for a while and then it destroys trust.

In Switzerland there is also a legal line. The ordinance on health protection under the labour law does not allow monitoring systems whose purpose is to watch the behaviour of employees. A control app that turns staff into ranked players moves straight into that territory.

So the rule has to be built into the product. The game is about the operation, not about the people in it. The view shows machines, flows, stock, queues and money. People can see their own progress privately if they want to, and teams share goals, such as finishing the order backlog by Friday. Public rankings of individuals are left out entirely. That is the ethical choice, and it is also the practical one. A tool the people on the floor resent will be worked around within a month.

How we would build it

The mistake would be to replace the systems operations already depend on. Nobody will rip out a production system or a booking tool for a better picture of their data. The product sits on top. It connects to what is there, reads, models and suggests, and leaves the systems of record alone.

There are two ways in, and they pull in different directions. Small businesses are fast to reach and quick to decide, but each one pays little and integrations multiply across many tools. Mid-sized manufacturers pay far more per site and feel the cost of a bottleneck in hours of lost output, but sales cycles are longer and every plant has its own mix of machines. We would start with manufacturers. Switzerland has a dense base of mid-sized production companies with one to five lines, owners who still walk the floor, and a constant shortage of skilled staff, which makes anything that helps a shift lead run the line better easy to justify. The engine and visual language built there can then be packaged down for salons, shops and restaurants as a simpler product with standard integrations.

Pricing would follow the value the operator can feel: per line for manufacturers, per location for small businesses. In both cases the price has to be covered by something visible, such as output recovered from a bottleneck or appointments that would have stayed empty.

What has to be true

Three things need to hold, and each can be tested cheaply before building much.

The people running the operation have to open it without being told to. If the view is not useful enough to become part of the shift or the morning routine, game design will not save it. We would test this with a single screen for one line or one shop, built from data they already have, and watch whether it is used every day for a month.

The suggestions have to be right often enough to be trusted. One good suggestion per shift beats five average ones. A shift lead who follows a suggestion and sees the line speed up will follow the next one. One who gets three bad ones will stop looking.

The model has to match reality. A view of the operation that is wrong is worse than no view at all. Connecting to old machines and inconsistent data is the unglamorous part of this work, and it is where most of the effort will go.

If those three hold, operations software stops being something people fill in and becomes something they look at to decide. That is the shift management games made a long time ago, and the real economy has not caught up with it yet.