Звонок в техподдержку:
— Было плохо, стало еще хуже. Верните, чтобы было опять просто плохо.
Если вы разрабатываете какой-либо продукт для рынка, каким бы идеальным и откалиброванным он ни был, все равно нужна техническая поддержка. Пользователи рано или поздно столкнутся с проблемами и вопросами, и ответить на этот запрос — прямая обязанность каждого благородного дона или доньи, в чьем ведении находится продукт.
Общение с пользователями по вопросам обеспечения работы сервиса — это не просто рутинное бремя и обязанность, но и вполне ощутимые и полезные точки роста.
Через грамотно выстроенную поддержку мы повышаем лояльность клиентов и их доверие, намечаем точки для саморазвития. Ведь каждое обращение, по сути, фидбэк по продукту — тот самый лимон, из которого можно приготовить лимонад.
Всем привет! Меня зовут Женя, я работаю в одной из продуктовых команд Т-Банка и хочу рассказать, как мы выстроили процесс работы с обращениями по проблемам пользователей и примерно в три раза снизили время реагирования на такие запросы.
Песнь первая. Как все начиналось
— Блин, как я ненавижу классическую музыку!
— Ты опять пытался дозвониться в техподдержку?
Когда я пришел работать в текущую команду разработки, волею судеб попал на слом эпох. Команда существовала уже пару лет, но в момент моего прихода по разным причинам (я не виноват, чесслово!) абсолютно все старожилы разбежались. Наша вновь сформированная вокруг продукта команда оказалась в ситуации, что продукт уже есть, уже работает, но процесс технической поддержки не выстроен никак.
В компании работала первая линия поддержки, которая решала львиную долю запросов пользователей. Но некоторые заковыристые проблемы первая линия решить не могла, и такие обращения направлялись в техническую команду, разрабатывающую продукт, то есть к нам.
Эти обращения мы называем SD (от service desk), и в те времена каждое такое SD назначалось на всю нашу техническую команду, без указания конкретного ответственного. Так как никто конкретно указан не был, то и разбирать эти обращения никто не торопился: у каждого всегда была куча своей прямой работы, дедлайны, инэмури и прочее.
В итоге обращения могли висеть несколько дней. Скорее поздно, чем рано до них добирался самый пассионарный член команды и разбирался в проблеме. У такого подхода было несколько болевых точек:
Долгий срок реагирования на обращения (SD). В самых критических случаях обращения могли висеть и месяц.
Невыстроенность процесса. Итоговый результат зависел от субъективной воли члена команды. Никакого регламента, никаких правил. Кропоткину бы понравилась такая анархия, но в вопросе поддержки продукта паттерн не самый успешный.
Перегруз одного члена команды. Как правило, в итоге до разбора SD добирался один и тот же человек, команда к этому привыкла и уже ждала от него этой работы. В результате бедняга оказался перегружен, потому что взвалил на себя эту ношу изначально. Он был молодец, но выгорал стремительнее, чем бикфордов шнур. И с этим нужно было срочно что-то делать.
Добавляло сложности еще и то, что исчерпывающего понимания работы продукта не было ни у кого, потому что мы все только-только пришли в команду. Каждый разбор проблемы пользователя превращался в интересный и подчас мучительный ресерч, заставляющий одновременно ощущать себя мистером Шерлоком Холмсом, Алисой, падающей в кроличью нору, и медведем, лезущим в горящую машину.
Процесс был мучителен и болюч, страдали все: пользователи, первая линия поддержки, техкоманда. Нарастала мировая энтропия, мириться с этим дальше было нельзя. И мы начали ворочать жернова изменений в команде.
Песнь вторая. Пошаговый план-капкан
- Я в ноябре подключен был прошлого года! 26 апреля этого года я получил первый разрыв!!! Почему не было ни единого разрыва?!! Отвечай на мой конкретный вопрос!!!
Мы выполнили ряд шагов, чтобы наладить процесс работы с поддержкой.
Прикрутили метрики для понимания времени реагирования на SD. Нам нужна была точка отсчета, чтобы понять, насколько быстро после назначения на нас SD мы обрабатывали его и переводили обратно на первую линию поддержки. Это было нужно, чтобы улучшаться относительно начальной точки отсчета, замерять, становимся ли мы эффективнее.
Для этого у нас в компании нашлась специальная метрика, но, если у вас чего-то подобного нет, можно раз в неделю рассчитывать на ЭВМ соотношение по формуле: Общее время обработки обращений / Количество обращений.
Шаги для расчета:
Собрать время обработки каждого обращения за неделю.
Суммировать все времена обработки.
Разделить полученную сумму на количество обращений.
Допустим, за неделю было 5 обращений с временем обработки 10 минут, 15 минут, 20 минут, 5 минут и 30 минут.
Скорбь коснулась нас, когда мы увидели среднее время реагирования на SD за последний квартал: оно оказалось целых 36 часов!!! Мы решили дерзнуть и поставить перед собой цель — реагировать на обращения максимум за 12 часов. Путь наш был извилист, но перспективы намечались светлые: поставить цель — полдела осилить.
Создали чат с первой линией поддержки. Ранее оповещения об обращениях поступали к нам через почту, на общую рассылку команды разработки. Эти письма не содержали в себе информативности, в них, по сути, была только ссылка на заведенный тикет. Коммуникации с сотрудником первой линии, создавшим тикет, никакой не было, письмо отправлялось специально обученным ботом, ответить на него было невозможно.
Мы сделали очень простой шаг — завели в рабочем мессенджере Time закрытый чат, куда пригласили всех сотрудников первой линии поддержки и всех членов команды разработки. В этот чат прикрутили форму, заполнив которую сотрудник первой линии отправлял к нам в команду запрос на разбор обращения.
В форме создания обращения нужно заполнить несколько нехитрых полей:
Влияние
S5 — уточняющий вопрос по работе продукта.
S4 — проблема у клиента, не блокирует использование продукта.
S3 — заблокирована часть функциональности, клиент не может пользоваться продуктом.
S2 — массовый сбой, часть функциональностей заблокирована или не работает.
S1 — массовый сбой, полностью не работает продукт.
Ссылка на обращение
Ссылка на заведенный тикет.
Описание
Описание сути проблемы простым, человеческим языком.
В SD приложен скриншот или видео проблемы
Так как продукт у нас интерфейсный, это может быть довольно важно. Но мы все равно оставили два варианта: «Да» и «Для данной проблемы невозможно приложить скриншот/видео».
Создание чатика и формы сил заняло немного, а пользы от них оказался целый вагон. У нас появился прямой канал связи и коммуникации с первой линией поддержки, в котором мы в режиме реального времени могли общаться и решать возникающие вопросы.
Ввели институт дежурств в команде. Когда не было конкретного ответственного за обращение, тикет навешивался на всю команду. Теперь же мы решили равномерно разделить ответственность и нагрузку между всеми членами команды. Каждый по расписанию оказывался дежурным в конкретный день. Сотрудники первой линии, приносящие обращения, тегали именно этого человека.
Для удобства мы прикрутили специального бота, который по календарю автоматически расставлял дежурства и в 9 утра присылал в наш чатик с первой линией поддержки жизнеутверждающее послание: «Дежурный супергерой сегодня — Кецалкоталь Женя». И всем было очевидно, кто сегодня ответственный за обращения.
Описали Кодекс дежурного. Хотя получился и не Бусидо, но это ОЧЕНЬ важная часть нашего процесса по внедрению культуры работы с обращениями. Мы составили кодекс, в котором зафиксировали основные принципы дежурящего.
Кодекс дежурного
В нашей команде есть график ежедневных дежурств:
Каждый день назначается новый дежурный исходя из данных, зафиксированных в календаре дежурств.
Ежедневно в 09:00 мск специально обученный бот шлет нотификацию в чат ~support. В этой нотификации есть имя дежурного и ссылка на неразобранные обращения.
Дежурства нужны, чтобы все члены команды равномерно участвовали в разборе обращений от поддержки по нашим продуктам и никто не выгорал из-за чрезмерной нагрузки. Также дежурства позволяют значительно повышать уровень экспертизы в продукте.
Что делает дежурный:
Устраняет инциденты и сбои в продуктах команды, консультирует первую линию поддержки в канале ~support.
Решает вопросы в чате ~ask.
Описывает разобранные проблемы в типовых вопросах, встречающиеся в SD.
Чего не делает дежурный: не обсуждает вопросы в личке и не поощряет такие способы коммуникации.
Многие сторонние команды привыкли решать свои вопросы в личке, что может иметь негативные последствия:
Отсутствует прозрачность в работе дежурного. Команда может видеть обращение, но не видеть действий дежурного.
Не сохраняется история обсуждения, которая может быть полезна в дальнейшем.
Поощрение таких способов коммуникации означает, что подобная практика будет прогрессировать и другие дежурные могут с ней столкнуться.
Основные принципы дежурного:
При заступлении на дежурство инженер должен заложить в свой рабочий день время на работу с обращениями. Это время, когда он откладывает основные задачи и занимается исключительно обращениями. Исключения в этом принципе возможны только при необходимости чинить упавший прод. Время разбора обращений в среднем может занимать 30% рабочего времени (при необходимости больше).
Если дежурный не успел разобрать обращения, при передаче дежурства следующему инженеру он должен отписаться, что делал по ним, что удалось выяснить, какая проблема осталась нерешенной. Такой отчет необходимо сделать в треде о новом дежурном, который прислал бот.
Если при заступлении на дежурство инженер видит, что остались неразобранные обращения, в первую очередь он фокусируется на них и только потом — на иных рабочих моментах.
Причина «Поздно пришло обращение, поэтому не успел взяться» уважительная только при поступлении обращения за полчаса до конца рабочего дня.
Инструкции для дежурного:
Получить доступы на прод для полноценного дежурства.
Прочитать мануал «Как разбирать SD», чтобы изучить инструменты для разбора SD, полезности и хитрости.
Прочитать типичные вопросы, встречающиеся в SD, и способы их решения.
Если не удается самостоятельно разобраться в SD и не помогают инструкции из пункта три, следует обратиться в чатик ~duty_knowledge. В обращении приложить ссылку на SD и описать краткую суть проблемы.
Такой кодекс дежурного у нас получился в итоге. В нем мы рассмотрели все моменты, которые важны и нужны для вкатывания сотрудника в процесс дежурств. Все описано, на все есть четкая инструкция и регламент.
Дали первой линии инструменты для самостоятельного решения вопросов. Многие вопросы, которые доходили до нас от первой линии, были однотипны, монотонны и зачастую не требовали глубокой технической экспертизы. Мы прикинули, что их решение можно вверить в бравые руки ребят из поддержки. Оказалось, что это довольно неплохой массив обращений: примерно 7 из 10 обращений решается именно этим способом.
Довольно скоро и малыми ресурсами мы предоставили ребятам из первой линии весь пул инструментов, которые нужны для разбора обращений:
Описали пошагово алгоритм действий при разборе таких SD в формате «Делай раз, делай два!».
Предоставили поддержке доступы в нужные БД, чтобы ребята могли сами анализировать проблему, собирать данные для ее решения.
Запилили специально для поддержки API методы, которые позволяли осуществлять целевые действия для решения обращений. Например, пересчитать количество и сумму платежных операций после ручного инсерта в БД затерявшейся транзакции (такие агрегации хранятся в отдельной БД).
В результате те самые 70% типичных обращений стали решаться без привлечения техкоманды, до нас стали добираться действительно сложные случаи, разобраться в которых с кондачка не получалось.
Создали чат поддержки новых дежурных. Об этом чатике есть упоминание в Кодексе дежурного (чат ~duty_knowledge). В нем находится уютный круг всех дежурных, а также причастных к дежурствам и тайно им сочувствующих. Создан он для того, чтобы счастливчик, на чью долю выпало быть дежурным в текущий день, мог бы обратиться с вопросами ко всем остальным ребятам. Так дежурный не ощущает себя одиноким спартанцем, отбивающим атаки орд персов: рядом всегда комрады, которые при необходимости помогут советом, поддержат и разделят бремя разбора обращений.
Особенно полезно и актуально это для дежурных-новичков, у которых не так много опыта по разбору обращений. Чувство товарищеского плеча рядом позволяет без больших проблем влиться в славные ряды дежурящих.
Презентовали дежурства команде. После проведения всех работ дело оставалось за малым — презентовать команде концепцию дежурств. Мы собрали общую встречу и рассказали, что дежурить теперь будем по очереди. Показали Кодекс дежурного и ответили на вопросы.
Не могу сказать, что эта идея была встречена с большим энтузиазмом: комрады привыкли, что обращения разбирает один человек, что нет дополнительной ответственности, что этот контекст отсутствует в жизни. Но и огромного сопротивления тоже не было: в итоге все согласились, что поддержка приложения — обязанность всей команды. И что нести эту почетную ношу всем по очереди будет справедливо.
И… Шестеренки закрутились, процесс понесся галопом.
Let's get ready to rumble!
Создали встречу-синк с первой линией поддержки. В процессе взаимодействия с поддержкой при внедрении дежурств мы поняли, насколько остро нам не хватало качественной, постоянной коммуникации с ребятами. У них был ряд проблем и болей, которые мы зачастую могли довольно быстро решить, дать полезные инструменты. А нам не хватало прямого фидбэка с первой линии обороны: в чем у нас есть проблемы, чего от нас ждут в первую очередь.
Мы создали регулярную ежемесячную встречу, на которой обсуждаем проблемы, ожидания друг от друга и прочие нужности и полезности. Эти встречи сделали нас действительно одной командой, работающей над продуктом, а не лебедем, раком и щукой, тянущими воз каждый в свою сторону.
Песнь третья. В чем профит, Лебовски?
— У меня интернет не работает!
— Как давно начались проблемы?
— Уже неделю ничего не работает, а вы даже не звоните и не интересуетесь!
Вот чего мы добились после внедрения дежурств.
Распределили нагрузку по разбору обращений на всю команду. Берсерк, который раньше в одиночку разбирал обращения, доволен, на работе горит, а не выгорает. Высвобожденный ресурс пассионарности может направить на что-то не менее благое.
Главное, мы синхронизировались всей командой в понимании, что приложение — это общая ответственность и что за все, что мы делаем, мы отвечаем тоже вместе.
Сейчас в дежурствах участвует 10 человек, процесс вливания новичков в этот процесс прост и безболезнен.
Регламентировали и описали процесс работы с обращениями. У нас появилась четкая и понятная инструкция, как стать дежурным. И что делать на дежурстве. И куда пойти, если обращение поставило в тупик и небо кажется с овчинку. Кто-то скажет: «Бюрократия», мы скажем: «База» :)
Прокачали экспертизу в продукте. Крайне неожиданный и приятный бонус. При разборе обращений часто приходится заглядывать в такие уголки приложения, куда никогда не заведет рутина. Когда там оказываешься, понимаешь, как вообще-то у нас устроено приложение, уровень экспертизы растет с каждым дежурством.
Так, например, мобильный разработчик может пощупать веб-версию нашего приложения. А бэкендер увидит собственными глазами, как отображаются для пользователя данные из БД, которые он бережно передает своими API-методами.
Еще дежурства — классная возможность оказаться в роли реального пользователя, понять, как он видит продукт, как его использует. Примерив эту роль на себя, инженер волей-неволей и в повседневной работе начинает учитывать этот аспект. В мировосприятии приложение перестает быть реализацией строчек из спеки, становится реальным продуктом для реальных людей.
А еще мы сами, из первых рук получаем отличный фидбэк о самых проблемных местах у нас в приложении, и это позволяет быстро реагировать на такие сигналы, усилять и фиксить места, где у нас слабая броня.
Уменьшили время реагирования на обращения. Один из самых важных пунктов, ради которого мы и затевали всю историю с дежурствами.
Приведу статистику по ближайшему после внедрения дежурств временному отрезку.
Q4 21 — это четвертый квартал 2021 года, когда у нас не было дежурств. Среднее время обработки обращения — 36 часов.
В Q1 22 (первый квартал 2022) мы внедрили дежурства и сразу же наметилась тенденция, что обращения стали обрабатываться примерно за 10 часов. То есть понижение получилось весьма существенное и ощутимое. В последующие кварталы мы сохранили и закрепили эту тенденцию.
Тренд сохраняется: абсолютное большинство обращений разбирается в день поступления. Редкие исключения переносятся на следующий день и уже там успешно обрабатываются. Так, в 2025 году среднее время обработки обращений составляет 4 часа 28 минут. Кажется, очень недурной результат :)
Песнь четвертая. Сложности
— Алло, это служба поддержки?
— Да!
— Я не хочу делать отчет!
— Поддерживаю!
При внедрении дежурств не все прошло гладко и мы столкнулись с рядом сложностей. О некоторых я уже вскользь рассказал выше, здесь же резюмирую.
Недостаток доступов и прав. На начальном этапе не все в команде имели необходимые для дежурств доступы. А самое главное, не было исчерпывающего списка, какие же именно доступы нужны. Это создавало барьеры для полноценного выполнения обязанностей дежурного.
Решение: мы составили подробный список необходимых доступов и описали пошаговый процесс их получения. В итоге вышло около 10 пунктов, и получение доступов стало занимать всего один-два дня, так как было подробно описано.
Недостаточная коммуникация с первой линией поддержки. Первоначально у нас была слабая коммуникация с первой линией поддержки, из-за чего мы не получали важный фидбэк от ребят, были слабо синхронизированы в процессах и ожиданиях.
Решение: организовали регулярные встречи-синки, на которых обмениваемся видением ситуации, намечаем совместный план действий и экшен-пойнты. А еще создали единый чат для общения с ребятами из поддержки — это жемчужинка нашей коммуникации.
Сопротивление изменениям. Некоторые члены команды сопротивлялись новому процессу дежурств, предпочитая старые методы работы. Не скажу, что сопротивление было титаническим, но определенный уровень накала страстей имел место.
Решение: провели серию встреч, где терпеливо объясняли, зачем мы вводим дежурства, какую это принесет пользу и почему решение проблем пользователей — ответственность всей команды. При этом вовлекли сопротивляющихся сотрудников в процесс принятия решений, чтобы они чувствовали свою значимость и вовлеченность.
Недостаточная документация. В процессе внедрения дежурств мы столкнулись с тем, что у нас не было достаточно подробной документации, как разбирать обращения, описания типовых проблем и инструментов. Наметки были, но исчерпывающими их можно было назвать едва ли. И это затрудняло процесс дежурств для ребят.
Решение: дописали мануалы по инструментам разбора обращений и типичным проблемам. Внедрили систему обновления документации: каждый дежурный должен добавлять новые решения, если он сталкивается на дежурстве с какой-то ранее не описанной проблемой или новым инструментом. А еще провели обучение по эффективному использованию документации для всех членов команды.
В целом после проработки всех пунктов можно сказать, что организация процесса дежурств — это в большей степени не техническая задача, а управление человеческими ресурсами и культурой в команде.
И совместное решение всех сложных моментов сплачивает, создает «братство дежурных». Кольцо Всевластия, конечно, за тридевять земель никто не несет. Но что может быть более сплачивающим, чем совместно решенная проблема, когда рядом оказалось плечо коллеги?
Песнь пятая. Выводы
— Алло, это техподдержка?! Какой у меня пароль?
— Такой же, как логин.
— Гм... А какой у меня логин?
— Такой же, как пароль.
— Спасибо большое!
Кратенько резюмируем: чего мы хотели, что сделали и что получили в итоге.
Чего хотели:
Уменьшить срок реагирования на обращения.
Выстроить процесс обработки обращений.
Распределить нагрузку по обработке обращений среди всех членов команды.
Что сделали:
Научились считать время реагирования на обращения.
Создали чат с первой линией поддержки.
Ввели институт дежурств в команде.
Описали Кодекс дежурного.
Дали первой линии инструменты для самостоятельного решения вопросов.
Создали чат поддержки новых дежурных.
Презентовали команде дежурства.
Создали встречу-синк с первой линией поддержки.
Что получили в итоге:
Распределили нагрузку по разбору обращений на всю команду.
Уменьшили время реагирования на обращения.
Регламентировали и описали процесс работы с обращениями.
Бонус: очень круто прокачали экспертизу в продукте.
Внедрение дежурств было славным приключением, которое сплотило команду, помогло нам осознать свой продукт с точки зрения пользователей и сделать его качественнее и стабильнее. Надеюсь, описанный путь кому-то поможет и будет полезен.
Ну а я полетел на дежурство! :)
