Jonathan Shroyer’s piece “Player Support Is the New Live Ops” is one of the more useful things written about gaming operations in a while. The core argument is right: player support is a signal system not just a clean-up system. Live ops teams that rely on telemetry alone are missing the layer where churn decisions actually happen. The emotional reality of the player experience shows up in support, not in dashboards.
But there is one signal Shroyer’s framework does not fully account for, and it is the one that behaves differently from everything else on the list.
Toxic behavior is not random noise
Most support signals are distributed across your player base. Billing confusion, onboarding friction, event reward issues: these problems affect many players, and fixing the underlying cause helps everyone. Toxic behavior does not work that way.
What we see across communities points to a distribution that changes the intervention logic entirely: roughly 0.5% of users cause around 75% of the harm. These exact numbers will vary by platform and genre, and you should test this against your own community data. But the shape holds, harm is not spread evenly. It is largely concentrated in a small group of repeat actors who move through communities, cause damage, and move on. That means the moderation challenge of volume can to a large extension be solved by identification.
A moderation system built for incidents will always be one step behind
Most moderation systems are built to resolve what is in front of them. A report comes in, someone reviews the incident, a decision gets made, and the case closes. That works well for isolated behavior but repeat actors do not behave that way. They move through communities, cause damage, and surface again somewhere else. Each incident looks manageable on its own and reviewed in isolation it might not even cross the threshold for action. The pattern is only visible if someone is looking across incidents, over time.
The gap is not staffing and it is not response time. It is that incident resolution and pattern recognition are different architectural problems. A system designed to close cases efficiently is not designed to connect them, and those are different design decisions with different infrastructure behind them. That is not something a BPO support partner typically provides, and it is not something a general ticketing system is built to do.
Toxicity is a live ops metric
Shroyer’s framework is largely about reactive intelligence, and his argument for connecting support data to live ops decisions is well made. Behavioral detection works earlier in that loop. The question is not only what happened, but who keeps making it happen, over time, across different communities.
The live ops case for this is straightforward. A player who does not feel safe is less likely to invest in identity, and identity drives monetization. Skins, cosmetics, guild membership, seasonal passes: players buy these things because they want to express who they are and where they belong. A community where toxicity goes unchecked is a community where that investment feels risky. Toxicity exposure affects session frequency, whether a player brings a friend, and whether a new player stays past the first week.
We think return to play after a safety incident should be a standard metric, and almost no studio is measuring it yet. Did the player who filed a harassment report come back? Did the moderation action actually work? That loop, from safety incident to player behavior to business outcome, only closes if your system is built to find the source, not just process the report.
A question worth asking
Shroyer asks live ops teams to treat support as one of their fastest, richest signal systems, and he is right. The follow-on question is this: inside that signal system, are you treating behavioral harm as a pattern problem or a ticket problem? If it is the latter, you are building the right intelligence loop with a hole in it.
