Building a player support function from scratch at a 10-person studio

Most player support functions at small studios start the same way: the founder handles tickets in a shared email inbox until it breaks. The question is when it breaks and what you have ready to replace it.

This is a practical sequence. Not a theoretical framework.

Day one: routing and triage, nothing else

The first thing you need is not a knowledge base, analytics, or automation. You need to know that every ticket is seen and that someone is responsible for it. Set up a single inbox with clear ownership. Tag tickets by issue type manually. That's it.

Do not build automation at day one. Automation that is wrong wastes player time and creates a second support problem. You need 60 days of volume to understand your actual ticket distribution before you automate anything.

Month one: identify your top-5 ticket types

After 30 days you have data. Pull your closed tickets and categorise them. You will find that 5 issue types account for 60–70% of your volume in almost every studio at early stage: purchase issues, account access, content delivery (missing items), bug reports, and "how do I" questions.

The first three have resolution templates. Write them. The fourth goes to engineering. The fifth is a knowledge base problem. Start with the first three.

Month two: your first knowledge base

A knowledge base at this stage is not a comprehensive library. It is five articles for your five most common "how do I" questions. Write them from the most recent 10 tickets in each category — not from memory. The tickets tell you what the player actually asked, which is different from what you think they asked.

Player-facing article quality at this stage matters more than quantity. One accurate, readable article deflects more tickets than five technically correct but unreadable ones.

Month three: your first SLA policy

You need a written SLA before you hire your first dedicated support agent. Without it, there is no standard to train to and no way to measure performance.

For an early-stage studio, a two-tier SLA is sufficient. Tier 1 (payment issues, account access): 2-hour first response, 4-hour resolution. Tier 2 (everything else): 24-hour first response, 48-hour resolution. Communicate both tiers publicly so players have correct expectations.

What to get wrong on purpose

You will set up automation too early and have to rip it out. You will write KB articles in the wrong tone and rewrite them. You will choose the wrong SLA tiers and adjust them. These are not failures — they are the data collection phase.

What you cannot get wrong: ownership and accountability. If no one is responsible for every ticket being resolved, nothing else you build will compensate for it.

When to invest in tooling

A dedicated support platform becomes worth the investment when any of these are true: you have a dedicated support hire, your ticket volume exceeds 50 per day consistently, or you are approaching a major launch that will 5× your normal volume.

Before that threshold, the overhead of a sophisticated platform exceeds its value. After it, the overhead of not having one exceeds its cost.