The classic support model is built around tiers. There’s a first line where all incoming tickets land — in about 80% of cases the issue is standard and can be resolved by the agent (or even automatically), although it still takes time and effort. The remaining ~20% are more complex cases, usually related to payments or technical issues, and are escalated to a second line where a technical specialist gets involved.
Our model is fundamentally different. We don’t have tiered support, no assembly-line approach — every team member is ready to handle any type of request, from simple to complex. But the key difference is that around 60% of tickets are resolved without any human involvement at all. This allows us to keep the team lean and respond to players faster. The secret is partial automation combined with strong employee onboarding.
First steps: Bringing order to chaos
A few years ago, our support team consisted of around five people — several managers and one lead. We were handling multiple successful titles, and while Helpshift was already in place, there was no well-structured system behind it. For example, some tickets came directly via email from the website and the app, and the team processed them in a live queue.
At that time, each person handled around 100–150 tickets, which wasn’t a major issue, but it was clear that this model wouldn’t scale. So we decided to completely rethink the support architecture.
As always, it started with manual work. First, we built detailed documentation and FAQs, analyzing a large volume of tickets accumulated over the years. Then came automation setup. It was crucial to consolidate all incoming requests across all projects into a single centralized hub. We built this as a Help Center portal on top of Helpshift, and prepared comprehensive materials for every game — detailed FAQs, explanatory articles, and more.
The core goal was to ensure that most tickets could be resolved without a human agent. Previously, 100% of tickets required agent responses. After launching the Help Center, about one third were resolved automatically.
Today, roughly 60% of tickets are handled through automation, while the remaining 40% are escalated to agents. Most escalations involve payments, lost progress, or progression-related issues.
When a player enters support from the game, we immediately receive all relevant data — player ID, game version, currency balances, and so on. In a traditional model, initial triage is handled by first-line agents, but in our case this happens automatically.
As a result, automation freed managers from routine work and gave them room to grow.
Support is also, by nature, about cost efficiency. Every ticket has a cost — there’s a fixed cost for the support platform and a variable cost based on ticket volume. Naturally, the goal is to reduce that total. Today, each project is handled by just a couple of people, not linear agents, but all-round specialists who work on setup, routing, automation, and more.
Another less obvious benefit of this approach is faster onboarding of new projects. When Idle Outpost joined our portfolio, we were able to apply our existing setup and launch support within a couple of weeks. Previously, this process could take up to six weeks due to integrations, coordination with development teams, and other setup tasks.
What player tier segmentation brings
The next step was player segmentation. Different types of players come to support: some play casually, others make small in-app purchases, and some are highly engaged and spend significant amounts. It was only natural to start identifying and differentiating between these groups.
After analyzing in-game data, we defined five player tiers based on their in-app spending behavior. We studied the types of issues each tier encounters, how many steps it takes to create a ticket, and the average time to first human response. Based on this, we built our Service Level Agreement (SLA).
The maximum response time is 24 hours for all players, including non-payers. For highly engaged players, it’s reduced to 16 hours (and in practice, the average is often closer to 10 hours).
This is not instant support, but considering the volume and complexity of requests, it’s a strong result. The industry benchmark is around 24 hours, but we respond faster for paying users — and do so with a compact, highly skilled team.
Handling negative experience
We understand that if a player reaches out to support, they’ve already had a negative experience. Our main goal is to resolve the issue as quickly as possible and bring them back into the game.
There are three key factors that influence this.
The first is speed. This is where the 16-hour SLA comes into play — and that’s specifically for cases where a human agent is required and there is no ready-made solution in guides or FAQs. These cases are relatively rare, since 60% of tickets are resolved automatically, and bot responses are effectively instant.
For example, when a player contacts support, they are directed to the Help Center, select the issue type (such as technical or payment), and immediately receive an automated response requesting necessary information — email, player ID, etc. Based on the input, the system provides a solution. If that doesn’t help, the player can request escalation, which then falls under the 16-hour SLA.
The second factor is communication quality. We have a clearly defined tone of voice with structured call-to-actions — how we respond, how we explain, how we guide players.
For instance, if a player missed a reward or lost an item, we may compensate them — and often slightly overcompensate. If they lost 200 gems, we might give 250. This can turn a negative experience into a positive one.
Another benefit of this approach is financial. For example, if a player spent $10 but didn’t receive the purchase, they might request a refund. Instead, we can offer to manually grant the item immediately. In most cases, players prefer that over a refund.
Our analytics showed that refund requests used to be quite frequent on some projects. Now, refunds happen in about 30% of cases (down from 50%+), and interestingly, this improvement didn’t require additional costs.
The third factor is player journey — how many steps it takes from opening a ticket to resolving it. Last year, we redesigned this flow and reduced the number of steps almost by half. As a result, players now get answers much faster, often directly through FAQs.
What we did:
- Rewrote more than 500 texts (bot responses, automation flows, quick replies) across multiple projects
- Completely redesigned bot logic and flow — over 700 interaction scenarios across three major projects
- Eliminated dead ends in bot interactions — now every path leads either to a resolved issue or a proper escalation to an agent
- Increased full automation rate from 25% to 50%
- And more
Team level
This kind of support architecture requires a different level of team expertise.
First, everyone on the team actually plays games and understands them. You need to experience the product yourself, understand its mechanics, and anticipate player issues. For a support manager, knowing the product is essential — it allows you to stay aligned with the player’s perspective.
Second, we look for empathetic people who genuinely enjoy helping players and improving their experience. In 90% of cases, players come to support with a negative experience. Simply having someone mechanically process tickets is not the level of quality we aim for.
Third, we invested significant time in building detailed project documentation, which is openly accessible. However, much of it is written in product language, which requires a certain level of expertise from support specialists.
This also makes onboarding more demanding, but the result is that our team consists of all-round specialists — support generalists who develop across multiple areas: product, analytics, and marketing.
In many companies, support is seen as an entry-level role — the easiest way into the industry. In our case, it’s more complex. There have been cases where support specialists grew into product owners. You could say it’s more of a launchpad with multiple trajectories, where people gain real, hands-on experience.
An indirect benefit of this setup is the removal of routine work that doesn’t build expertise, allowing people to focus on more complex and valuable tasks. For example, the idea to reduce refund rates didn’t come from management, it came from the support team itself.
Ultimately, the result is simple: players receive not just high-quality, but fast support. In a way, this also contributes to branding. There’s a common stereotype that if support replies at all, even after a week, you’re lucky. We want every interaction with support to leave a positive impression, because it’s part of the product we build — and part of why we love game development.


