Подкаст «Как Делают Игры»: организация техподдержки

Структура, задачи и методы отдела.

16 марта 2017 года вышел 176 выпуск подкаста «Как Делают Игры». В этот раз ведущие Сергей Галёнкин и Михаил Кузьмин поговорили с гостями о структуре и работе команды технической поддержки.

Гости выпуска:

● Сергей Мелкомуков, руководитель службы поддержки Appodeal;

● Александр Банник, руководитель службы поддержки 101XP.

DTF публикует избранные фрагменты.

Сергей Мелкомуков: Я начинал с попыток создания собственных игр на Unity. Сейчас мне было бы стыдно их показывать, но тогда я считал, что можно сделать любой продукт и кто-то в мире захочет его купить.

После я несколько лет работал в Alawar, портировал игры на разные платформы. Два года назад пришёл в Appodeal и занялся поддержкой.

Александр Банник: Я начал карьеру в 101XP на должности обычного саппорта. Позже стал замруководителя, а в последние полтора года — главой отдела поддержки. До этого приложил руку к созданию портала по первой DotA ICCUP и немного поработал курьером в Nival.

Александр Банник: Поддержку игроков можно разделить на несколько аспектов. Пользователи обращаются по вопросам, связанным как с играми, так и с деятельностью компании. В первом случае сообщения выявляют неисправности и ошибки, а во втором — некачественный трафик.

Сергей Галёнкин: Один из немаловажных аспектов — «goodwill», добрая воля, отношение игроков к сервису. Один недовольный человек сообщит о своих впечатлениях гораздо большему числу людей, чем довольный. «Токсичность» таких пользователей в том, что они заражают других негативом. Техподдержка недооценена многими компаниями, как инструмент формирования отношения игрока к проекту.

Сергей Галёнкин: Комьюнити-менеджеры занимаются активностями вокруг проекта, а не в самой игре. Их основная задача — формировать сообщество и направлять его в конструктивное русло.

Например, человек хочет провести турнир по вашей игре и у него есть вопросы. Вы помогаете ему и знакомите с отделом разработки. Или, когда человек заметил проблему в балансе проекта — он пишет об этом на форуме или во «Вконтакте», а комьюнити-менеджер по итогам недели фильтрует подобные сообщения, убирает очевидный мусор и составляет дайджест для разработчиков.

Наиболее очевидная ситуация взаимодействия — когда есть серьёзная проблема, о которой техподдержка знает, но не может исправить. Допустим, игра вылетает, когда пользователь выбирает героя «X» на втором экране. Если продукт вышел на PlayStation, баг можно исправить только в следующем апдейте дня через два (ведь нужно пройти сертификацию). В техподдержку поступает неожиданно большое количество запросов и она сообщает комьюнити-менеджерам: у нас ошибка, предупредите сообщество.

Сергей Мелкомуков: Клиенты Appodeal это издатели и инди-разработчики. В нашем отделе работают только программисты, операторов нет. Если сотрудник может решить входящий запрос — он это делает. У него есть доступ к исходникам SDK и серверу. Конечно, он не может разбираться во всём, но выявит какие-то закономерности и найдёт ошибку.

Очень важна обратная связь: любой функционал порождает лестные и отрицательные отзывы. Это может быть связано с его новизной или с тем, что он плохо рассчитан или описан. Техподдержка столкнётся с этим одной из первых, и должна правильно обработать обращение: возможно, нужно что-то резко поменять, дополнить документацию, обучить пользователей.

У нас есть круглосуточный чат поддержки по любым вопросам (в основном техническим). Чаще всего обращаются из-за проблем с интеграцией или её пониманием. Среди клиентов есть крупные проекты, работающие с рекламой не первый день. Закономерно, что возникают конфликты из-за стереотипов о том, как она должна быть устроена, приводящие и к техническим проблемам.

Наш SDK на 80% состоит из чужих. Клиенты зачастую боятся сразу встраивать напрямую полный пакет — они хотят оставить старую, надёжную часть, приносящую свою копейку. Но частичная интеграция также порождает баги.

Александр Банник: Наша поддержка разделена на три линии. Первая работает 24/7, это удалённые агенты. Они фильтруют базовые проблемы и решают те, что могут. Для остальных запрашиваются дополнительные данные (если это баги, который ранее уже удалось классифицировать и внести в базу). Оставшиеся передают на вторую линию.

На ней сидят специалисты более узкого направления, работающие над одним или несколькими проектами. У них есть расширенный инструментарий вплоть до общения с разработчиками и доступа в панель администратора. Все проекты мы локализуем, поэтому часто не можем быстро связаться с создателями игры — приходится общаться через полмира.

Третья линия — гейм-мастера. Они плотно вовлечены в работу над одним конкретным проектом и разрешают самые сложные вопросы. В частности, могут самостоятельно принимать решение о компенсации за неполадки, если они повлекли за собой исчезновение предметов в игре или затронули финансовый аспект.

Они же иногда проводят расследования, связанные с логами, по запросам других отделов. Работа с «админкой» и начислениями идёт бок о бок с копанием в многострочных таблицах. Это как интересные расследования, так и монотонное изучение статистики.

Сергей Мелкомуков: У нас есть основные цели — моментальная поддержка и компетентность ответа. Три канала обращений: чат, работающий 24/7, поддержка через Skype и по электронной почте.

Специалист поддержки может решить технические вопросы на стороне клиента. Вопросами на стороне сервера и SDK занимаются программисты-разработчики. Большая часть вопросов решается на первой стадии и до них не доходит.

Также мы ищем проблемы ещё до того, как о них напишет клиент: следим за статистикой и по побочным параметрам пытаемся выделить ошибки. Это делают аналитики, а не саппорт, но в итоге появляется запрос на проверку проблемы. Думаю, такая система была бы актуальна и для больших игр.

Александр Банник: Специалисты первой линии обычно работают удалённо — им самим так удобнее. Иначе приходилось бы приезжать на пересменку к шести утра.

Вторая и третья линия находятся в офисе, где есть возможность связаться с другими членами команды (например, с вышеупомянутыми комьюнити-менеджерами, если вопрос касается блокировки на форуме). В решение проблем, доходящих до третьей линии, вовлечены продуктовые менеджеры, продюсеры и другие участники проекта.

Сергей Галёнкин: У нас тоже три линии поддержки. На первой — компания-подрядчик, с выделенным составом, занимающимся нашим продуктом, работающим круглосуточно. К сожалению, она «покрывает» не все языки. Но, например, поддержка на русском у нас гораздо лучше в американском офисе — так сложилось исторически.

Первая линия поддержки отсеивает огромное количество вопросов. 9 из 10 обращений по Paragon — это жалобы на игроков, автоматическую блокировку и так далее. Обработать их можно, просто посмотрев логи чатов, не получая полный доступ к системе. На второй уровень отправляются технические вопросы, связанные с аккаунтом, биллингом или тем, что игра не запускается. Но, на удивление, их крайне мало.

Третья линия — единичные случаи, которые случаются раз-два в месяц — решения о крупных компенсациях и так далее.

У нас за всю историю только один вопрос дошёл до CEO. Выяснилось, что один из недавно заблокированных пользователей собирался провести турнир по игре. Мы посмотрели его логи — оказалось, что он много ругается, угрожает игрокам и так далее. Блокировку не сняли.

Александр Банник: Зачастую вопросы от пользователей наводят нас на огрехи в работе маркетинговых компаний-партнёров. Это доводится до отдела маркетинга, тщательно проверяется и при необходимости мы прекращаем сотрудничество.

Поскольку мы издатель, у нас есть как свой отдел разработки, так и связь с разработчиками игры. Саппорт может связываться с создателями проекта в критические моменты. Взаимодействие с внутренним отделом разработки обычно необходимо для улучшения портала, введения дополнительной интеграции для нашей рабочей среды, чтобы удобнее было работать.

Например, мы недавно сделали интеграцию со Slack, присылающую предупреждения, если количество пришедших за час тикетов превышает среднее для проекта за неделю. Если резко растёт число тикетов по платёжным проблемам, значит, что-то не так с системой оплаты и мы должны экстренно закрывать все «дыры».

Сергей Мелкомуков: Поддержка, хоть и отдельный департамент, но часть большой, единой команды. Важно выделять потоки информации и ставить точки — кто и за какие задачи ответственен. Клиент этого, конечно, не увидит — вопрос проходит круг внутри компании и возвращается к нему. Если продукт ориентирован на клиента, отзыв должен поступать туда, куда нужно и максимально быстро.

Помимо нашей разработки мы тесно сотрудничаем с разработчиками игр и приложений, и у нас есть команда, которая занимается тем, что анализирует отзывы в Google Play — нет ли жалоб на рекламу. Ведь если с ней что-то не так, вероятно, это наша проблема. Ретеншен и оценка игры не должны падать от того, что реклама работает неправильно.

Сергей Галёнкин: Каждую неделю, когда выходит апдейт, команда разработки отсылает в саппорт список открытых задач. В нём перечислены баги, которые пока не решены, отсортированные по приоритетности. Для некоторых есть «костыли», для некоторых — нет. В свою очередь, команда техподдержки сгруппировывает пользовательские сообщения об ошибках по темам и отсылает ответный список разработчикам.

Для возникших впервые багов есть рассылка «issues», а для требующих немедленного решения проблема — «shit happens». Последняя уходит команде оперирования (live ops). Это вторая часть команды программистов, постоянно контактирующая с технической поддержкой.

Конечно, есть и автоматические боты, которые, если что-то «упало», пытаются «поднять» сами, а при неудаче присылают отчёты дежурному. Но главное — это регулярный, стандартизированный обмен информацией между отделами. Такого не бывает, чтобы ничего не ломалось.

Александр Банник: Мы используем ZenDesk. Она генерирует тикеты по обращениям из разных источников. Кроме того, наша рабочая среда позволяет писать письма, личные сообщения от лица страницы игры в Facebook и с помощью интеграции обрабатывать комментарии пользователей на Google Play. Всё делается через рабочую среду.

Ещё есть очень удобная интеграция с сервисом форм, позволяющая в ряде проектов использовать web-форму, не требующую регистрации, но с обязательным указанием электронной почты. Для внутренней связи мы пользуемся JIRA.

Сергей Мелкомуков: У нас другие инструменты — Intercom, Asana. У разработчиков свои инструменты для отслеживания. Intercom сродни ZenDesk, просто лучше подходит для наших нужд и позволяет получать больше данных от клиента — например, знать, какая страница документации у него открыта.

Александр Банник: У нас всё контролируется рабочей средой. Мы вручную проставляем допустимое время ответа (например, первая реакция на сообщение пользователя в подавляющем большинстве случаев требует меньше часа).

Это не значит, что за это время её решат: зачастую нужно привлекать разработчиков, которые не сразу примут и исправят неполадки. Но первый ответ даём за час и каждые сутки стараемся выходить с пользователем на связь, даже если ситуация не разрешилась.

Наша рабочая среда позволят систематизировать поток тикетов так, чтобы первыми отображались те, срок SLA которых подходит к концу. Если есть свежая задача и нерешённый тикет, на который уже ответили, но не связывались с автором 23 часа 55 минут — в ленте у агента появится последний.

Сергей Мелкомуков: Мы ставим жёсткие рамки: первый ответ должен быть дан быстрее, чем за пять минут. Очень важный момент — категории вопроса. Ввиду специфики нашей работы, на некоторые запросы можно дать исчерпывающий ответ за это время. Но для решения некоторых требуются один-два дня. Бывает, что ситуацию нельзя разрешить и в течение двух недель — если это требует, например, апдейта SDK или изменений на сервере, а значит нового цикла разработки с тестированием, отладкой и так далее.

SLA в разных категориях будет отличаться. В идеальной ситуации тикет закрывается, только когда клиент пишет «у меня всё работает». Но некоторые из пользователей больше не вернутся на сайт поддержки и вопрос закроется через два дня после ответа. Кроме того, мы должны написать клиенту в течение этих двух дней.

Сергей Галёнкин: У нас два основных канала поддержки — сайт и почта. Это, наверное, удобно для разработчиков, но не для пользователей. Многие неигровые компании оказывают поддержку в Twitter и Facebook. Нам предлагали инструменты, позволяющие разграничивать опыт и контролировать тикеты из этих социальных сетей. Мы на это пока не решились, но есть ощущение, что всей индустрии придётся оказывать поддержку там, где удобно игрокам.

Александр Банник: Как я уже говорил, у нас есть интеграция с Facebook, которая переводит личные сообщения для страниц игры в тикеты. Такая же штука работает в Google Play. Но у подобных систем есть недостатки. Например если человек присылает скриншот в facebook-беседу, может возникнуть проблема — его аккаунт не всегда авторизован для чтения личных сообщений страницы. Когда разработчики ПО закроют эти дыры, можно будет говорить о полноценной поддержке. Сейчас она есть, но со своими подводными камнями.

Если аудитория сидит в Twitter, можно организовать поддержку на базе того же ПО, что и по другим направлениям. ZenDesk позволяет собирать все сообщения с определённым упоминанием. При появлении в сообщении названия компании или проекта генерируется тикет.

Сергей Мелкомуков: Важно с самого начала определиться, какие каналы мы будем поддерживать. Если решили выйти, например, в Telegram, нужно брать на себя ответственность за то, что ответ будет дан в сроки SLA, даже если поступит один вопрос в течение года. Кто-то должен всегда мониторить канал поддержки, ПО, которое будет это всё объединять, наверняка будет ломаться при апдейтах каналов и кто-то из клиентов точно не получит ответ вовремя.

Александр Банник: Зависит от ситуации. Обычно мы стараемся поддерживать лояльность клиентов и всячески им угождать. Но в этом разница между игровыми и корпоративными клиентами: последние всегда готовы поддержать конструктивную беседу, как коллеги.

Когда мы облегчили способ обращения в техподдержку для проекта на Facebook, чтобы игроки могли без дополнительной регистрации отправить нам сообщение из игры, не указывая никаких обязательных данных, почти в 10 раз увеличилось количество просьб в стиле «дайте мне золота». Мы не могли пойти таким людям навстречу — это было бы несправедливо по отношению к остальным игрокам.

Михаил Кузьмин: Вы считаете, что клиент всегда прав, а что отвечаете попрошайкам?

Александр Банник: Мы конечно, не говорим «нет, мы жадные». Объясняем, что не практикуем такую благотворительность. Зачастую в играх есть пути бесплатного получения премиальной валюты — квесты, ежедневные задания — рассказываем о них.

Сергей Галёнкин: У нас похожий подход. На удивление малое количество людей просят халяву. Но по умолчанию мы пользователю доверяем — если не доказано, что он не прав. Просто всегда всё максимально проверяется. Если он утверждает, что вёл себя, как паинька, а в логах видно, что он рассказывал про маму, папу и бабушку с дедушкой оппонентов — скорее всего врут не логи.

Сергей Мелкомуков: Очень важно отношение к клиенту. При больших объёмах работы текст не должен быть сухим. У нас есть для каждого сотрудника своеобразная «мантра», каким он должен видеть клиента — и он читает её каждый день перед тем, как заступает на смену.

Александр Банник: Основное отличие в том, что для разрешения технических вопросов у издателя может уйти чуть больше времени, чем у разработчика. Если продукт разрабатывался в студии — всегда можно разбудить программиста в три утра и сказать, что нужно срочно исправлять.

Когда же речь идёт об издании игры — большинство багов и ошибок правится на стороне разработчика. И в таком случае нужно правильно донести информацию — фразы «там ошибка» может быть недостаточно. Тогда уходит чуть больше времени.

Когда ты работаешь с проектом своей студии — ты всегда прав, можешь принимать решения. А издавая чью-то игру, встречаешься с подходом «это не баг, а фича», и последнее слово остаётся за разработчиком.

Александр Банник: В нашем случае это совокупность разных факторов: количества закрытых тикетов, данных ответов, времени первого ответа и разрешения проблемы. Понятно, что человек может закрыть 100 тикетов, с которыми он работал не очень корректно — просто передал информацию, неделю бил баклуши, через неделю ему пришло исправление, и он отписался клиенту.

Если же сотрудник активно напоминает разработчику или менеджеру проекта, и проблема разрешается быстрее — конечно, он старается больше. Также смотрим на удовлетворённость пользователя. После закрытия тикета игроку предлагают оценить, помог ли ему специалист поддержки. Рейтинг влияет на оценку эффективности.

Сергей Галёнкин: Обычно хватает шкалы из пяти вариантов от «не помогли совсем» до «идеального результата». Но вот, например, у Amazon по итогам общения с техподдержкой опросник из пяти вопросов по пять вариантов ответа в каждом. И в конце даже открытый вопрос.

Сергей Мелкомуков: Нельзя забывать и о нагрузке на весь отдел в целом. Это неразрывно связано с эффективностью каждого человека. Если у нас сегодня будет 1000 вопросов, а мы можем ответить на 1200 — это не значит, что кто-то работал хуже.

В какой-то день случится сбой на серверах, обращений станет больше — а ресурсов на то, чтобы ответить всем, не хватит. Из-за этого увеличится период ответа и решения. Внутри отдела мы постоянно проводим конкурсы вроде «собери за день больше благодарностей от клиентов».

Александр Банник: Если проект действительно небольшой, то и с поддержкой, и с комьюнити может справиться один человек. Но по мере роста, естественно, потребуется привлекать дополнительных специалистов и разграничивать позиции.

Михаил Кузьмин: Вы не можете не оказывать вообще никакой поддержки. У вас должна быть либо форма обратной связи на сайте, либо вы должны общаться с людьми в социальной сети.

Александр Банник: Боты, к сожалению, не годятся для принятия решений, да и общаться клиенту приятнее с живым человеком. Пока что ботов в индустрии стараются не использовать, только для каких-то узких кейсов.