Лучшая техническая поддержка

#🚨-эскалация – текстовый канал для экстренных уведомлений о критических сбоях. Право писать было только у ботов интеграций и тимлидов.

#📚-база-знаний – канал для публикации и обсуждения новых инструкций и разбора сложных случаев.

#🔧-задачи-в-разработке – канал для обсуждения тикетов, переданных в отдел разработки.

#💬-флудилка – неформальное пространство для команды.

Ключевым открытием стала эффективность использования потоков (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. Многие компании прячутся от плохих новостей и претензий потребителей, и ваш покорный слуга искренне считает, что те, кто прячется от плохих новостей – проигрывает в этом марафоне по созданию лучшей технической поддержки в мире.