Лучшая техническая поддержка
Предисловие
Дорогие читатели,
Перед вами – книга, которая стала квинтэссенцией более чем двадцатилетнего пути в мире клиентского сервиса и технической поддержки. Меня зовут Алексей Ворм, и за эти годы я прошёл путь от рядового специалиста, вживавшегося в каждую проблему пользователя, до руководителя, выстраивающего системы, где помощь становится не функцией, а культурой. Этот путь – от «джедая» техпода, виртуозно владеющего решениями, до «самурая» сервиса, для которого честь – это безупречное служение клиенту. Каждый диалог, каждый решённый и нерешённый вопрос, каждая благодарность и каждая жалоба стали бесценными уроками, кристаллизовавшимися в принципах, которыми я делюсь с вами.
Эта книга – не просто сборник инструкций или сборник кейсов. Это живое повествование о том, как превратить техническую поддержку из затратного центра в стратегический актив компании, в точку роста лояльности и источник конкурентного преимущества. Вы найдёте здесь не только проверенные методики и готовые регламенты, но и философию, в центре которой – человек: клиент, который доверяет вам свою проблему, и сотрудник, который с гордостью её решает.
Я глубоко убеждён, что техническая поддержка – это не периферийный отдел, а нервная система бизнеса, определяющая его жизнеспособность и репутацию. Самый инновационный продукт терпит фиаско, если пользователь остаётся наедине со сложностью. И наоборот, искренняя забота и эффективная помощь способны компенсировать временные несовершенства и создать прочную, эмоциональную связь с брендом.
– как воспитывать и мотивировать команду, создавая среду, где профессионализм и эмпатия идут рука об руку.На этих страницах я собрал и систематизировал лучшие практики, которые позволили мне и моим командам создавать службы поддержки, становившиеся эталонами в своих отраслях. Вы узнаете: – как интегрировать разрозненные каналы связи в целостную, умную экосистему; – как работать с негативом, трансформируя жалобы в истории успеха и лояльности; – как выстроить процессы так, чтобы клиент чувствовал не безликий конвейер, а персональное внимание;
Все примеры и ситуации, описанные в книге, основаны на реальном опыте, но обезличены и адаптированы. Это сознательное решение, позволяющее сосредоточиться на универсальных принципах и механизмах, которые вы сможете применить в своей уникальной реальности.
Отдельная благодарность – моим бесчисленным коллегам, соратникам и, конечно, клиентам. Ваши вопросы, ваша критика, ваше терпение и ваша благодарность были тем топливом, что двигало меня вперёд и формировало понимание того, каким должен быть по-настоящему выдающийся сервис.
Пусть эта книга станет для вас не только практическим руководством, но и источником вдохновения. Вместе мы можем поднять планку клиентского сервиса, сделав его более человечным, профессиональным и уважительным.
С уважением и верой в то, что даже самый сложный вопрос имеет решение,
Алексей Ворм
P.S. Помните: лучшая техническая поддержка начинается не со скрипта, а с искреннего желания помочь. Это и есть её главный секрет.
Почему эта книга важна именно для вас?
Для руководителей и основателей: Вы получите готовую систему построения и масштабирования службы поддержки, которая экономит ресурсы, повышает NPS и превращает клиентов в адвокатов бренда.
Для тимлидов и менеджеров поддержки: Вы найдёте инструменты для мотивации команды, разрешения сложных конфликтов и построения процессов, которые работают даже в ваш выходной.
Для специалистов поддержки: Вы откроете для себя алгоритмы решения самых нестандартных задач, приёмы профессиональной коммуникации и карьерные траектории внутри профессии.
Для всех, кто верит в силу сервиса: Эта книга – о том, как делать обычную работу необыкновенно хорошо и как в этом найти и личный смысл, и профессиональную гордость.
Добро пожаловать в мир, где техническая поддержка – это искусство, а клиентский сервис – это философия.
Введение. Истоки пути: от первого тикета до философии сервиса
Здравствуйте, друзья.
Меня зовут Алексей Ворм. Сорок семь лет жизни, двадцать пять из которых – в мире, где каждый день начинается с вопроса «Как вам помочь?». Мой путь в технической поддержке стартовал 13 января 2000 года, задолго до того, как эта профессия обрела сегодняшние контуры и значимость. Это был сознательный выбор, определивший не только карьеру, но и мировоззрение. Я оказался в компании, которая на долгие годы задала эталон: здесь ценностью были не только технологии, но и люди – как клиенты, так и коллеги. Должен заметить, что в этом мне невероятно повезло – каждая организация, в которой мне довелось работать, по-своему являлась лучшей. Возможно, дело не в везении, а в том, что я всегда искал не просто место работы, а поле для свершений, где важны были качество, результат и та особая удовлетворённость, которая возникает, когда сложная проблема решена безупречно. В каждый проект, в каждую команду я вкладывал частицу честности и искреннего желания сделать сервис лучше, и каждый из этих опытов оставил во мне неизгладимый, ценный след.
Сегодня я руковожу технической поддержкой в крупной российской IT-компании, чьи решения активно используются по всей стране. Эта роль – не просто должность, а логичное продолжение двадцатилетнего диалога между технологией и человеком, где моя задача – обеспечить, чтобы этот диалог был чётким, конструктивным и по-настоящему полезным.
Сознательно избегая упоминания конкретных брендов и продуктов, я хочу сосредоточить ваше внимание на главном – на принципах, процессах и философии, которые универсальны. В книге вы встретите нейтральные обозначения: CRM, Helpdesk, Телефонный провайдер. Это не уход от реальности, а фокусировка на сути, позволяющая адаптировать описанные подходы к вашим уникальным условиям.
Сама эта книга родилась из вызова – задачи построить с нуля техническую поддержку, которая стала бы не просто функцией, а эталоном. Мы начали не со скриптов и не с закупки софта, а с плана. Сначала – общее видение, затем – детальное описание, и наконец – погружение в тончайшие нюансы. В результате родился перечень из 24 ключевых пунктов: функций, интеграций и доработок, которые и составили каркас будущей системы. Этот список стал нашим пазлом, и когда последний элемент встал на место, оставалось лишь одно – последовательно выполнить всё, что было задумано.
Именно об этом пути – от концепции до воплощения, от первого тикета до отлаженной экосистемы сервиса – и пойдёт речь на страницах этой книги. Мой опыт, ошибки, находки и озарения – к вашим услугам. Пусть это чтение станет для вас не только источником полезных рецептов, но и вдохновением. И пусть у вас всё получится – ровно так, как однажды получилось у нас.
Глава 1. Телефонная интеграция: выбор и интеграция инфраструктурного партнёра
Первым и фундаментальным шагом в построении технической поддержки является выбор инфраструктурного партнёра – поставщика телефонии. Это не просто сервис связи, а кровеносная система будущего сервиса, от надёжности и гибкости которой зависит качество каждого диалога с клиентом. Наш выбор пал на провайдера, которого мы условно называем «Лучший телефонный провайдер». Критерий отбора был прост и логичен: чтобы построить эталонную поддержку, необходимо, чтобы ваши собственные партнёры демонстрировали тот же уровень сервиса. Невозможно требовать безупречности от своей команды, если ваша инфраструктура работает со сбоями. Мы оценивали кандидатов, включая «Провайдера 0», «Провайдера 1» и «Провайдера 2», по ключевым параметрам: качество клиентского сервиса самого оператора (время реакции его техподдержки не превышало 10 минут), техническая надёжность, гибкость настройки и глубина аналитики.
Выбранный провайдер стал неотъемлемой частью нашей экосистемы благодаря глубокой интеграции с нашей CRM-системой (Helpdesk). Каждый входящий звонок автоматически создаёт тикет с уникальным номером, куда загружается запись разговора для неограниченного хранения. Это создаёт единую историю коммуникаций, где телефонный диалог, последующая переписка и внутренние заметки существуют в одном контексте. Система позволяет назначать тематику и сложность прямо на основе звонка, а также оперативно перенаправлять вызовы между специалистами, что закреплено в соответствующем внутреннем регламенте.
Регламент 1.1: Перевод входящего звонка между агентами
Если агент технической поддержки, принявший звонок, понимает, что не обладает достаточной компетенцией для его оперативного решения, он обязан:
1. Вежливо извиниться перед клиентом и кратко объяснить причину перевода: «Чтобы решить ваш вопрос максимально быстро и точно, я передам вас моему коллеге, который специализируется на этой теме».
2. Используя функционал телефонии, выполнить «тёплый» перевод (предварительно связавшись с коллегой) на выбранного специалиста или на свободного агента второй линии поддержки.
3. После успешного перевода добавить в автоматически созданный тикет заметку с указанием причины перевода и имени коллеги, которому был передан звонок.
Особое внимание мы уделили аналитике и проактивному управлению. Провайдер предоставляет прозрачную статистику, включая длительность разговоров. Мы ввели метрику «проблемного звонка» – диалога длительностью более 5 минут. Все такие звонки автоматически фиксируются и отправляются на специальный почтовый ящик для последующего разбора – силами лидера или с помощью аналитических инструментов. Это позволяет выявлять системные проблемы или сложные темы, требующие доработки инструкций.
Регламент 1.2: Обработка пропущенных вызовов
Любой неотвеченный входящий звонок является тикетом, который должен быть закрыт. Цель – не допустить потери клиента из-за технической недоступности.
1. Обязательность обратного звонка: Каждый пропущенный вызов требует совершения обратного звонка.
2. Проверка истории: Перед звонком агент проверяет, не связывался ли уже кто-то с клиентом по данному номеру в других тикетах.
3. Если контакт был: Тикет о пропущенном звонке закрывается с комментарием, содержащим ссылку на тикет, где общение уже ведётся. Единая тематика проставляется обоим тикетам.
4. Если контакта не было: Незамедлительно совершается обратный звонок.
5. Временное окно: Звонок совершается, если с момента пропуска прошло не более двух рабочих дней или если инцидент произошёл перед/после выходных.
6. Ответственность: Обработку изначально выполняет агент, на которого тикет был назначен системой. При его недоступности руководитель переназначает задачу другому специалисту.
7. Фиксация результата: После звонка в тикет вносится исчерпывающий комментарий с сутью проблемы и проделанной работой, а также проставляется тематика.
Таким образом, телефонная интеграция – это не просто подключение номеров. Это создание управляемого, анализируемого и бесшовного канала коммуникации, который становится основой для прозрачности, контроля качества и постоянного улучшения клиентского сервиса.
Глава 2. Интеграция в Хелпдеск направлений компании.
Мы проводим интеграционные процедуры для направлений по вопросам, связанным с Направлением 2.
Мы интегрировали в Хелпдеск направления компаний, обслуживание которых ранее осуществлялось отдельными направлениями, блоками-инструментами.
Таким образом мы замкнули на одном инструменте – это Хелпдеск, интеграционное обслуживание по всем направлениям корпорации.
Это является важным шагом для того, чтобы оперативно взаимодействовать по всем направлениям в рамках единого центра технической поддержки.
Инновации позволили нам реализовать возможность поддержки новых направлений через подключение нового/хорошо скрытого функционала хелпдеска.
Важность данной процедуры заключается в том, что теперь, когда мы видим низкую загрузку сотрудников технической поддержки в отдельных направлениях компании – мы можем увеличивать и распределять эту нагрузку по другим направлениям.
Например, когда мы видим, что техническая поддержка по Направлению 3 не до-загружена – у нас появляется возможность оперативно переключать коллег на поддержку других направлений. Это же касается и Направления 0 – когда мы видим, что специалисты недозагружены – переключаем специалистов на другие направления и задачи.
Подобные взаимодействия стали осуществимы после того, как мы интегрировали все направления нашей Корпорации в CRM систему Хелпдеск.
Ранее мы не могли определять и анализировать информацию по всем направлениям компании.
Используя современные методы, нам удалось открыть шкатулку Пандоры.
На диаграмме ниже мы видим, что общая недозагруженность технической поддержки составляет 68 % – это в разрезе данных за шесть месяцев с 1 июля по 10 января 2022 года.
Глава 3. Интеграция в работу мессенджера Телеграм
Техническая поддержка и ранее использовала мессенджер Telegram в своей работе. Однако применив практику интеграции – нам удалось каждый запрос от клиента, поступающий в Telegram канале, фиксировать как новое, отдельное сообщение/обращение – это важно для того, чтобы каждое обращение было зафиксировано и обработано, и у каждого обращения был свой идентификационный номер.
Ранее обслуживание канала Telegram осуществлялась в несбалансированном, архаичном и сложно управляемом потоке данных. Клиенты писали в одну группу, задавали много вопросов, и не было чёткого понимания того, закрыт вопрос клиента или нет. Клиенты жаловались, что их вопросы не решаются. Техническая поддержка жаловалась, что их заваливают большим количеством вопросов, на которые сложно и трудно отвечать. Руководству сообщалось о том, что взаимодействовать в большой группе общения с клиентами очень сложно.
Интеграция канала Telegram в CRM-систему Хелпдеск, а также гибкое распределение запросов от клиентов позволило снизить нагрузку по обращениям на техническую поддержку, а также улучшить общение с технической поддержкой на уровне клиентского сервиса. Каждое обращение от клиента, направленное в техническую поддержку – это новая задача, новый вопрос, новое решение или возможность. Как только мы реализовали и запустили этот функционал – мы в разы улучшили качество обслуживания клиентов на уровне технической поддержки.
Интеграция мессенджера Telegram в CRM-систему Хелпдеск на уровне технической поддержки – это очень важный стратегический шаг, сделанный нами для создания лучшей технической поддержки.
Сейчас ежемесячно через канал Telegram мы получаем около более 200 запросов от клиентов. Каждый новый запрос – это закрытая и решённая задача. При этом мы добились такой интеграции и взаимодействия с клиентами, когда даже если мы не можем решить вопрос клиента – мы его заводим либо на доску разработчика, либо на доску аналитика и при этом оставляем тикет клиента на удержание.
Таким образом у клиента складывается ощущение того, что он просто общается через мессенджер с технической поддержкой, но на стороне технической поддержки – это выглядит более логично, и каждый вопрос клиента – это решение.
Данная интеграция позволила нам добиться того, что даже если через год разработчик ответит на вопрос технической поддержки и закроет задачу на своей стороне – в этом случае мы всё равно сможем и ответим клиенту, что его вопрос решён. То есть, даже если решение вопроса от клиента произойдёт через год, мы в любом случае ответим клиенту через канал Telegram, что решили его вопрос.
Понятно, что лучше не доводить до таких ситуаций, когда клиенту отвечаем через год, но нужно заметить, что ситуации бывают разные, и что не всегда все ответы от клиентов решаются на стороне технической поддержки. Обычно к таким сложным вопросам относятся такие задачи, как доработка системы, аналитика и аналитическая проработка данных на стороне группы аналитиков, сложно программируемые задачи и дополнения к основному функционалу программы.
В рамках данной интеграции были разработаны и внедрены регламенты про сложные задачи клиентов, с ними можно ознакомиться далее в главе 12 – «Регламенты и работа по правилам».
Глава 4. Интеграция мессенджера WhatsApp: техническая реализация, процесс работы и стратегическое значение
Внедрение WhatsApp в экосистему технической поддержки представляет собой комплексный проект, выходящий за рамки простого добавления канала связи. Это инженерная задача по интеграции платформы с закрытой архитектурой, глубокое перепроектирование процесса первичного взаимодействия и стратегическое решение по размещению сервиса в точке максимального клиентского комфорта. Основная техническая сложность заключается в отсутствии у Meta официального, прозрачного и полнофункционального API для бизнес-взаимодействия, сравнимого с Telegram Bot API. Это вынуждает использовать обходные методы интеграции, часто через специализированных провайдеров (как Business API партнёров) или гибридные решения, имитирующие работу пользовательского клиента. Мы реализовали подключение через функционал нашего Helpdesk, который выступает в роли агрегатора и управляющего ядра.
Техническая архитектура и процесс взаимодействия.
1. Выделенный номер и аккаунт – для канала поддержки был зарегистрирован и верифицирован отдельный номер телефона (+7(000) 000-00-00) и создан официальный бизнес-аккаунт WhatsApp Business. Это необходимо для легитимности массовых рассылок, получения «зелёной галочки» верификации и доступа к расширенной статистике.
2. Цепочка первичного контакта (Onboarding Flow).
Шаг 1: Автоприветствие. Сразу после первого сообщения клиента срабатывает автоматический триггер. Клиент получает чёткое, структурированное сообщение: «Здравствуйте! Вы написали в техническую поддержку [Название компании/Направление 0]. Этот канал обслуживают живые специалисты. Для оперативного решения вашего вопроса, пожалуйста, опишите проблему как можно подробнее: что произошло, когда, на какой странице или в каком модуле. Прикрепите скриншот или видео, если это возможно. Ориентировочное время первого ответа – 10 минут».
Шаг 2: Создание тикета. Как только клиент отправляет содержательное описание проблемы (превышающее пару слов), система анализирует сообщение. Она не просто создаёт новый тикет в Helpdesk, а обогащает его метаданными: источником (source: whatsapp), номером телефона клиента (который выступает уникальным идентификатором), временем первого обращения и полным текстом запроса. Тикету автоматически присваивается тематика по ключевым словам (например, «оплата», «ошибка входа», «отчёт») или статус «Уточняется», если алгоритм не может классифицировать запрос.
Шаг 3: Назначение и уведомление. Созданный тикет автоматически назначается на свободного агента первой линии или на специализированную группу, отвечающую за направление. Агент получает уведомление в общем интерфейсе Helpdesk, где видит всю историю переписки по данному номеру телефона (если она была), включая предыдущие звонки и письма. Это обеспечивает контекстное обслуживание.
3. Рабочий процесс внутри Helpdesk – Агент общается с клиентом напрямую из интерфейса Helpdesk, не открывая приложение WhatsApp. Его ответы форматируются и отправляются через интегрированный шлюз. Все сообщения логируются в истории тикета с временными метками. Поддерживается отправка и приём файлов (скриншоты, документы, видео) – они загружаются во вложения тикета.
4. Завершение обращения и сбор обратной связи – после решения проблемы и отправки финального сообщения клиенту (например, «Проблема решена, проверьте, пожалуйста») агент переводит тикет в статус «Ожидание обратной связи». Через 1-2 часа система автоматически отправляет в тот же WhatsApp-чат короткое сообщение с просьбой оценить работу: «Помог ли вам специалист?» и кнопками-быстрыми ответами «Да, спасибо» / «Нет, проблема осталась». Выбор «Нет» автоматически переоткрывает тикет и эскалирует его старшему специалисту или руководителю сцены.
Стратегическое обоснование и результаты
Следование за клиентом – опросы и аналитика показали, что более 75% нашей B2B и B2C-аудитории используют WhatsApp как основной мессенджер для делового и личного общения, в то время как Telegram распространён значительно меньше. Отказ от интеграции с WhatsApp означал бы создание искусственного барьера между нами и клиентом.
Увеличение доступности и снижение нагрузки на телефонию – WhatsApp стал предпочтительным каналом для не-срочных, но требующих документального подтверждения вопросов (пересылка чеков, скриншотов ошибок). Это снизило нагрузку на телефонные линии на ~15%, освободив операторов для действительно сложных и срочных звонков.
Критически важный канал аварийных коммуникаций – в случае глобальных сбоев, когда веб-интерфейс и мобильное приложение продукта недоступны, WhatsApp остаётся независимым каналом связи. Мы заранее формируем списки рассылки для ключевых клиентов и через Business API оперативно информируем их о инциденте и ходе работ, что резко снижает количество гневных обращений на другие каналы и повышает доверие.
Консолидация коммуникаций – все диалоги, независимо от канала, хранятся в единой карточке клиента в Helpdesk. Это исключает ситуацию, когда клиент начинает разговор в WhatsApp, продолжает по email, а затем звонит, и каждый раз рассказывает историю заново. Специалист видит всю картину.
Важные технические и юридические нюансы
Согласие на коммуникацию – первое автоматическое сообщение содержит не только инструкцию, но и ссылку на политику конфиденциальности. Факт продолжения диалога клиентом считается согласием на обработку данных в рамках оказания поддержки.
Риски блокировки – несанкционированные массовые рассылки через неофициальные API приводят к перманентной блокировке номера. Мы используем только легитимные методы через Business API с соблюдением лимитов и правил платформы.
Резервный сценарий – на случай технических проблем со шлюзом WhatsApp у агентов есть инструкция по ручному переходу в мобильное приложение Business для завершения критически важного диалога с немедленным последующим внесением лога в тикет вручную.
Таким образом, интеграция WhatsApp – это не «фича», а фундаментальный компонент клиентоцентричной сервисной стратегии. Она требует значительных инженерных затрат и внимания к деталям, но возвращается многократно в виде повышенной лояльности клиентов, операционной эффективности и создания надежной системы коммуникации на все случаи.
Глава 5. Эволюция корпоративного мессенджера: от игрового хаба к суверенной экосистеме коммуникаций
Внедрение единого корпоративного мессенджера стало для технической поддержки ключевой инфраструктурной реформой. Это решение преследовало стратегические цели: ликвидировать коммуникационный хаос, создать структурированное пространство для обмена знаниями, обеспечить мгновенную кросс-функциональную связность для решения инцидентов и формализовать процессы обсуждения задач. Изначально, ища платформу с максимальной гибкостью и низким порогом входа, мы выбрали Discord, условно обозначенный здесь как «Хороший корпоративный мессенджер».
Фаза 1: Структурирование рабочего пространства в Discord
Архитектура, повторяющая организацию компании.
Мы создали отдельный Discord-сервер для каждого бизнес-направления (Направление №0 – №6). Это обеспечило необходимое тематическое и информационное разделение. Например, обсуждение интеграции API для Направления №2 не смешивалось с кейсами клиентского обучения для Направления №4.
Иерархия каналов и потоков (threads).
Внутри каждого сервера мы выстроили чёткую иерархию голосовых и текстовых каналов.
#◉-оперативный-штаб – голосовой канал для ежедневных летучек и срочных созвонов по инцидентам.
#🚨-эскалация – текстовый канал для экстренных уведомлений о критических сбоях. Право писать было только у ботов интеграций и тимлидов.
#📚-база-знаний – канал для публикации и обсуждения новых инструкций и разбора сложных случаев.
#🔧-задачи-в-разработке – канал для обсуждения тикетов, переданных в отдел разработки.
#💬-флудилка – неформальное пространство для команды.
Ключевым открытием стала эффективность использования потоков (threads). Любое сообщение, запускающее обсуждение конкретной проблемы (например, скриншот ошибки от клиента), становилось основой для нового потока. Все дальнейшие обсуждения, логи, решения и статусы велись внутри этого потока, не засоряя основной канал. По истечении периода неактивности потоки автоматически архивировались, сохраняя историю, но поддерживая порядок.
Интеграции и автоматизация через ботов.
Мощь Discord раскрылась через кастомизацию. Мы настроили приватных ботов (на базе Python), которые:
– автоматически публиковали в #🚨-эскалация новые тикеты с меткой «Проблема» из Helpdesk;
– отправляли уведомления о статусах сборки из CI/CD (Jenkins) в #🔧-задачи-в-разработке;
– позволяли через slash-команды (например, /find_kb) быстро искать статьи во внутренней базе знаний прямо из чата.
Таким образом, Discord-серверы превратились в интерактивные командные центры в реальном времени.
Фаза 2: Осознание операционных и стратегических рисков
Несмотря на операционную эффективность, со временем проявились фундаментальные риски:
Происхождение и фокус платформы – Discord изначально создавался как платформа для геймеров, а не для корпоративных коммуникаций. Его политики, интерфейс и приоритеты разработки не всегда соответствовали бизнес-потребностям (например, управление членством в крупных организациях).
Инцидент с массовой блокировкой – в один день техническая поддержка Discord без внятного предупреждения заблокировала несколько наших корпоративных серверов и личных аккаунтов сотрудников, посчитав активность «неестественной» или нарушающей Условия предоставления услуг. Процесс разблокировки через форму обращений был долгим, непрозрачным и вёл на английском языке, что парализовало работу целых направлений на несколько дней.
Геополитическая уязвимость – растущая нестабильность и зависимость от иностранной SaaS-платформы создавали неприемлемый риск внезапной потери ключевого канала внутренней коммуникации.
Вопросы безопасности данных – хотя трафик шифровался, сам факт хранения всей корпоративной коммуникационной истории, включая обсуждения инцидентов и данных клиентов, на серверах компании, чьи юрисдикция и политики нам неподконтрольны, перестал соответствовать нашей внутренней политике информационной безопасности.
Эти риски перевесили операционные удобства. Назрела необходимость в суверенизации коммуникационной инфраструктуры.
Фаза 3: Стратегическая миграция на «Лучший корпоративный мессенджер» (Telegram)
После анализа отечественных решений выбор пал на Telegram. Ключевыми факторами стали: массовое распространение, мощный API, функция тредов в комментариях (аналогия потокам в Discord) и, что критически важно, – предсказуемость и контроль в рамках российской юрисдикции.
Процесс миграции был выполнен как полноценный IT-проект.
Аудит и проектирование – мы зафиксировали все серверы, каналы, роли (Discord Roles) и интеграции. На основе этого спроектировали новую структуру в Telegram: Публичные каналы для анонсов и Супергруппы с включёнными «Темами» для оперативной работы.
Ролевая модель и управление – в каждой супергруппе были назначены администраторы с правами на управление темами. Это позволило сохранить контроль над структурой обсуждений, аналогичный модерации каналов в Discord.
Поэтапный перенос – миграция шла направление за направлением. Мы не переносили историю сообщений слепо, а создавали «точку останова» в Discord и «точку старта» в Telegram, перенося итоговые решения и ключевые материалы.
Воссоздание интеграций через ботов – используя Bot API Telegram и наш внутренний middleware, мы воссоздали и даже улучшили систему оповещений. Единый бот-шлюз теперь агрегировал уведомления из Helpdesk, мониторинга и CI/CD, отправляя их в нужные треды с контекстом.
Регламентация и обучение – был выпущен внутренний регламент, детально описывающий, как создавать темы (например, [Инцидент][Напр.0] – Падение API с 14:25), как их вести и когда архивировать. Проведены воркшопы для команды.
Итог и приобретённые преимущества
Миграция доказала, что эффективность определяется не фичами платформы, а зрелостью процессов. Telegram, как «Лучший корпоративный мессенджер», не только выдержал нагрузку, но и принёс новые преимущества:
Суверенитет и предсказуемость – полный контроль над доступом и данными, отсутствие риска внезапной блокировки по непонятным правилам.
Универсальность и доступность – сотрудники уже были в экосистеме Telegram, что сократило время адаптации. Доступ с любого устройства был мгновенным.
Экономическая эффективность – отсутствие платы за использование ключевых функций.
Гибкость интеграций – открытый API позволил создать более глубокую и специфичную для наших нужд автоматизацию.
Этот переход закрепил важнейший принцип: инфраструктура поддержки должна быть устойчивой, контролируемой и независимой. Кризис с Discord стал катализатором для создания более зрелой, суверенной и отказоустойчивой коммуникационной экосистемы, которая стала надёжным фундаментом для работы лучшей технической поддержки.
Глава 6. Реализация прозрачного стиля общения
Реализация прозрачного стиля общения – это новый стандарт лучшего мирового сервиса по работе с клиентами.
Для того, чтобы лучше обслуживать клиентов многие компании, с недавнего времени заговорили о том, что должна быть прозрачность общения. Очень важно решать вопросы клиентов, используя не личные переписки между сотрудниками, а большие группы и информационные каналы – это важно для того, чтобы как можно большее количество вовлеченных и заинтересованных людей было в курсе той или иной проблемы. В рамках взаимодействия с использованием прозрачного стиля общения техническая поддержка использует инструмент Telegram. У этого инструмента есть и плюсы, и минусы, но всё же мы (техническая поддержка) считаем, что «телега» в данном случае является лучшим инструментом для того, чтобы поддерживать прозрачный стиль общения.
Прозрачный стиль общения и взаимодействия является очень важным для того, чтобы мягко взаимодействовать, решать и передавать клиента по отделам, а также решать все его вопросы. Техническая поддержка в рамках основного такого инструмента использует Telegram.
И прозрачный стиль общения является основополагающим фактором для того, чтобы создать лучшую техническую поддержку не только в России, но и в мире.
Очень часто в «телеге», можно заметить, как сотрудники технической поддержки, привлекая внимание аналитиков, разработчиков, общаются по вопросам клиента и все вместе решают проблему клиента – это очень важно, чтобы сделать лучшую техническую поддержку.
Все должны работать на клиента и прозрачный стиль общения – это именно то, что мы делаем для того, чтобы любые вопросы клиента были решены.
Глава 7. Создание Баз знаний по направлениям компании
В рамках работы технической поддержки реализуется направление по созданию и поддержке баз знаний для всех направлений группы компаний.
К таким направлениям относится Направление 0, Направление 1, Направление 2, Направление 3. Базы знаний ведутся и поддерживаются в одном месте и имеют условно одну общую структуру и архитектуру по взаимодействию между собой и другими объектами, а также клиентами технической поддержки.
База знаний содержится и находится в облаке. Управление базами знаний осуществляется на стороне технической поддержки клиентского сервиса. В Базу знаний гибко интегрированы интернет-ресурсы, а также программы, что позволяет клиентам быстро получать доступ к требуемой информации.
Для нас было важно создание единого облачного решения, которое при обновлении в одном месте ретранслирует обновлённую информацию во все разделы, структуры и иерархии других подразделений, с которыми работают наши клиенты.
Сейчас базы знаний находятся в одном месте и оперативно обновляются технической поддержкой. Очень важно, чтобы информация была актуальной. Даже тогда, когда происходят небольшие изменения – мы стараемся оперативно быстро обновить информацию в Базе знаний.
В Базах знаний содержатся и находятся ответы на все вопросы клиентов, которые нам когда-либо задавали. Если клиент задаёт нам вопрос, ответа на который нет в Базе знаний – специалисты технической поддержки (клиентского сервиса) добавляют эту информацию в необходимый раздел данного информационного ресурса.
Все базы знаний во всех направлениях интегрированы в CRM Хелпдеск – это особенно важно для того, чтобы давать оперативный вопрос клиентам и отвечать на любой вопрос клиентов.
Глава 8. Реализация информационных рассылок.
Реализация информационных рассылок предусмотрена для того, чтобы оповещать клиентов в случае аварийных ситуаций, когда программа или программное обеспечение для взаимодействия с клиентом не работает.
Информационные рассылки реализованы на основе платформы Хелпдеск, а также интеграционного взаимодействия с функционалом от ботмамы.
Используя опции CRM, мы информируем клиентов о том, что в нашей системе произошёл сбой/авария, и когда данный сбой будет устранён, ну и, конечно, после устранения сбоя.
Данная процедура необходима для организации лучшей технической поддержки. Это важно для того, чтобы оповещать клиентов о сбое раньше, чем они с ним (сбоем) столкнутся.
Данная реализация имеет как плюсы, так и минусы. К плюсам относится то, что мы имеем функционал, позволяющий в двухстороннем направлении общаться с клиентами. Минус – это то, что клиенты могли бы и не узнать об аварии, но из-за нашего информирования они (клиенты) об аварии узнают и могут использовать данную информацию в провокационных и других целях, носящих характер саботажа или коммерческого шантажа.
После того, как мы реализовали информационные рассылки через Ватсап, мы реализовали информирование в самой программе, но, как я и писал раньше – индивидуальное обращение в Ватсап или «тележку» работает лучше, чем информирование о сбое или аварии в самой программе. Также к минусам информирования о сбое/аварии из самого ПО – можно отнести тот факт, что если ПО не работает, то и саму «объяву» наши клиенты также не видят. Мы почесали затылки, пообщались, обсудили, ещё раз пообщались и договорились, что:
– если мы не хотим усложнять реализацию задачи, её проработку и эксплуатацию – нам нужно, прежде всего, сделать акцент на том, чтобы избегать аварийных и сбойных ситуаций, когда у нас не работает программа;
– мы заводим аварийный канал в «телеге» и заводим туда всех заинтересованных пользователей, клиентов, партнёров, при этом число ответственных, которые имеют возможность информирования в канале, регламентировано определённым количеством от каждой стороны участников процесса;
– мы создаем всплывающую информационную плашку в программе, в которой информируем клиентов о сбоях и нововведениях, при этом важно отметить, что в зависимости от важности новости у плашки разная цветовая гамма и палитра: красный, жёлтый, зелёный;
– в качестве резервного канала информирования клиентов мы используем Ватсап и Telegram и используем их, когда остальные средства и методы недоступны.
То есть, говоря простыми словами – мы не пишем в Ватсап о том, что у нас ошибка или неполадка в модуле. В Ватсап мы пишем только в случае серьёзной аварии, только тогда, когда проинформировать клиентов в программе не получается.
Ну и конечно информируем через, а точнее, ИЗ нашего Хелпдеска.
Ну, не буду напоминать, что КЛИЕНТЫ – это наше всё, и наша задача, задача Лучшей технической поддержки – информировать клиентов и держать их в курсе. Это важно не только для того, чтобы закрывать вопросы типа: «а почему вы нас не предупредили?» Это важно, чтобы клиенты понимали, что происходит, и если это происходит, могли оперативно принимать стратегически важные для них (КЛИЕНТОВ) решения.
Так обстоит в нашей технической поддержке дело с информационными рассылками.
Глава 9. Внедрение методологии работы с жалобами.
Методология работы с жалобами – это современная часть клиентского сервиса. Многие компании недооценивают эффективность работы с жалобами и вместо того, чтобы обращать на жалобы особенное и пристальное внимание, стараются эти проблемы замаскировать и не учитывать ни в работе технической поддержки, ни в работе компании. Многие используют жалобы как некий формат метрики, по которому оценивают работу и качество технической поддержки и клиентского сервиса (чем меньше жалоб, тем лучше сервис) – это неправильно. Неправильно не то, что коллеги используют жалобу как метрику, неправильно то, как эту метрику используют. Непонятно? Запутанно? Тогда читайте дальше, сейчас всё разжуём и погрузимся в детали.
Современные методы работы технической поддержки с жалобами таковы, что крайне важно относиться к жалобам, как к подарку, как к подарку судьбы. Жалоба от клиента – это именно подарок судьбы. Ведь представьте, что клиент мог отнести этот подарок не вам, а куда-нибудь в другое место, например, на Первый телевизионный канал и затем эту новость подали бы вам в вечерних новостях.
Задача технической поддержки (при получении проблемы), не хвататься за голову и не прятать её (голову) в песок, а искренне поблагодарить клиента за то, что он сообщил нам о проблеме.
Мы благодарим клиентов за то, что они нам жалуются и сообщают о проблемах.
Сегодня у нас есть определённый регламент, в котором описываются конкретные действия для технической поддержки, если они получают жалобу:
– благодарим клиента и говорим спасибо за жалобу/проблему;
– объясняем клиенту, почему для нас важна жалоба;
– извиняемся перед клиентом (очень важно извиняться, но не делать это сразу, а только после 1 и 2 пункта);
– сообщаем о том, что мы все уже бросились на исправление/решение ситуации;
– исправляемся и отвечаем.
Пример:
Благодарим вас за проблему.
Спасибо, что сообщили нам об этой ситуации.
Для нас очень важен подобный фидбек.
Извините за доставленные неудобства.
Мы уже связываемся с коллегами из диспетчерского центра, чтобы выяснить ситуацию о сбое.
Главные задачи технической поддержки – это поблагодарить за жалобу, рассказать клиенту о том, что для нас это очень важно, и объяснить почему. Извиниться за то, что мы доставляем клиенту подобные неудобства. Рассказать о том, что мы уже взяли в работу данную жалобу и через определённое время вернёмся к клиенту с решением и ответом на вопрос по его жалобе.
Данный формат очень важен для того, чтобы не потерять клиентов, а приумножить. Также в формате работ с жалобами в технической поддержке организован специальный канал – «Наши клиенты».
В этом канале собраны все клиенты, которые любят сообщать нам о проблемах. Наши клиенты нам часто пишут и жалуются, и сообщают о проблемах. Наши клиенты – это очень важные для нас люди. Всех клиентов, которые находятся в этом канале, в этом разделе, мы обслуживаем как наших лучших клиентов. Обычно, вопросы от Наших клиентов мы решаем в первую очередь. Мы всем клиентам стараемся отвечать максимально быстро, но Нашим клиентам мы стараемся отвечать реактивно – мы быстро передаём проблему в любых направлениях для достижения лучшего результата. Это не значит, что со всеми другими клиентами мы не делаем так же, как с Нашими клиентами – делаем, но приоритет всё же у Наших клиентов.
Мы абсолютно уверены в том, что будущее прибыльных компаний там, у кого техническая поддержка и клиентский сервис умеют правильно работать с жалобами клиентов.
Для нас очень важно установить постоянный канал связи, идущий от потребителя к разработчику/производителю – мы это реализуем через формат регламента работы с жалобами клиентов. Когда техподдержка в курсе того, чего хотят клиенты, и реализует это – значит техподдержка смотрит глазами клиента, в таком случае компания двигается на шаг впереди конкурентов.
Мы учитываем жалобы от клиентов с таким же пиететом, с каким мы считаем и положительные отзывы. Также мы привязываемся к общей статистике и аналитике и смотрим на проблемы в процентном соотношении как к друг другу, так и к общему и среднему количеству обращений. Мы уверены в том, что жалобы могут сообщить организации о качестве её работы и о положении на рынке больше, чем это могут дать специально разработанные опросы типа NPS. Многие компании прячутся от плохих новостей и претензий потребителей, и ваш покорный слуга искренне считает, что те, кто прячется от плохих новостей – проигрывает в этом марафоне по созданию лучшей технической поддержки в мире.