Техническая поддержка

Если инфошум о замедлении Твиттера вчера не позволил вам увидеть важное, то сообщаю. Вчера, 10 марта, произошел пожар в дата-центре провайдера OVH в Страсбурге, который входит в топ-5 крупнейших провайдеров. Полностью уничтожен центр обмена данными SBG2 (выгорел полностью) и на 30% ЦОД SBG1 (выгорело несколько боксов). Остальные 2 здания, находившиеся рядом, залиты водой.

Восстановление затопленных ЦОДов займет не менее 2 недель. В дата-центре размещались крупные европейские компании, часть из них уже заявили, что данные потеряны безвозвратно.

Не устаю напоминать о необходимости регулярного создания бэкапов, а тут как раз подоспел очередной повод.

Я руковожу небольшимDigital-агентством, обслуживаем малый и средний бизнес, часто общаемся с начинающими предпринимателями. И постоянно сталкиваемся с анти-кейсами резервного копирования, возражениями вроде дорого, сложно, позже настроим, пока не надо и само рассосется.

Хочу развеять сомнения руководителей, показать, что все просто, дешево и само не рассосется. Поэтому сегодня дампростой план резервного копирования, в большинстве случаев даже программировать не придется. Инструкция подойдет небольшим и средним компаниям, не имеющим собственной IT-инфраструктуры. Итак, начнем.

1. Купите отдельные IP-адреса для боевых проектов

Если у вас облако, сервер или VPS, то один IP-адрес уже в комплекте. Если у вас виртуальный хостинг, то докупите к нему выделенный IP-адрес. В нештатных ситуациях это поможет быстро сменить хостинг или перенести проект на другой сервер. Обойдется примерно в99 руб. в месяц.

2. Используйте NS-сервера регистратора домена

Хостинг провайдеры предлагают перенести обслуживание DNS на свой хостинг. Не соглашайтесь, оставьте домен на NS-серверах регистратора домена, а в А-записи домена пропишите IP-адрес хостинга. Так вы сможете быстрее сменить хостинг в случае аварии. При изменении А-записи обновления распространятся в течение 1 часа, и ваш проект через час уже будет доступен на новом хостинге. Но если же вы будете менять NS-сервера, то обновления могу занять до 72 часов. Обычно регистраторы предоставляют услугубесплатно, но RU-center хочет денег.

3. Включите локальное резервное копирование на хостинге

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

4. Храните 1-3 локальных бэкапа

Как правило, дисковое пространство на хостинге стоит не дешево, даже если вы покупаете отдельный диск для бэкапов. Поэтому нецелесообразно хранить там большие объёмы информации. Храните только самые последнии копии за предыдущие дни.

5. Настройте резервное копирование на отдельный сервер

Я рекомендую использовать облака как основное хранилище резервных копий, но вы можете использовать и простой сервер или дешевый хостинг от другого провайдера. Главное, чтобы сервера этого другого провайдера располагались не в том же дата-центре, что и основной сайт. Но облака гораздо дешевле, хранение одного терабайта там стоит обычнооколо 500 руб. в месяц. Можно использовать Google Cloud, AWS или Yandex Cloud для них есть готовые инструменты резервного копирования, поэтому их легко настроить. Обычно рекомендуют хранить 7 копий за неделю, 4 копии за месяц, 12 копий за год так и сделайте.

6. Поверяйте бэкапы раз в неделю

Минимум раз в неделю проверяйте факт создания бэкапов и их размер. Любой сбой может нарушить вашу схему резервного копирования: смена пароля, обновление ПО, переполнение диска, нехватка денег на счету. Потратьте всего 2-3 минуты в неделю этого хватит, чтобы предотвратить неприятности.

7. Восстанавливайте бэкапы раз в месяц

Хотя бы изредка восстанавливайте свои резервные копии на тестовом сервере. Идеально делать это раз в месяц, минимум хотя бы раз в 3 месяца. Одно дело иметь резервные копии, и совсем другое иметь реально работающие резервные копии. Вы должны быть уверены, что в нужный момент бэкапы вам реально помогут и у вас есть возможность их быстро развернуть. Удобно и дешево можно разворачивать облачные сервера на reg.ru или hetzner.cloud, потратитемаксимум 100-200 руб за раз. Процедура займет всего 1-2 часа, но убережет от проблем в будущем.

Вот и все, просто соблюдайте хотя бы эти простые правила.

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

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

Пишите в комментариях свои идеи как еще больше упростить схему, ускорить восстановление резервных копий и какие сервисы помогут сэкономить на бэкапах.

Привет, Хабр! Несмотря на то, что информационная безопасность и все, что связано с этой сферой, сейчас на хайпе, найти инженера технической поддержки по ИБ задача непростая. Еще больше ее усложняет расхожее мнение, что техподдержка только для джунов, а более опытные специалисты должны переходить в проектную деятельность. Чтобы развенчать этот миф, подробнее расскажем о профессии и возможностях, которые она открывает.

В сервисном департаменте STEP LOGIC на двух линиях технической поддержки работает более 50 специалистов. Сейчас они обслуживают порядка 150 сервисных контрактов это более 10 тыс. инцидентов в год. Первая линия поддержки проводит классификацию обращений заказчиков и если проблему можно решить по скрипту, то закрывает заявку своими силами. Если сделать это в течение первого часа не удается или требуются дополнительные компетенции, то инцидент передается на вторую линию поддержки, инженеры которой обладают более глубокими техническими знаниями и навыками.

Как сервисные партнеры нескольких крупных вендоров, мы имеем право оказывать услуги по технической поддержке оборудования от их имени. Например, при обслуживании оборудования Cisco наши специалисты решают до 80-90% проблем самостоятельно, за помощью к вендору мы обращаемся только при гарантийной замене или обнаружении программных ошибок. Для того, чтобы вендор авторизовал партнера на предоставление совместных услуг, в штате обязательно должны быть сертифицированные инженеры, имеющие CCIE или, как минимум, CCNP. Еще два обязательных условия прохождение ежегодных аудитов на соответствие уровня услуг, требования к которым схожи с лучшими практиками ITIL, и принцип оказания технической поддержки, основанный на практиках Cisco CX Specialization.

Конечно, оптимальное решение для компаний, у которых есть локальная задача поддержки оборудования конкретного вендора, это покупка его стандартных пакетов обслуживания. У того же Cisco, например, есть варианты на разный вкус и кошелек: контракты Cisco SMARTnet или расширенная версия Solution Support, Next Calendar Day, если нужна замена оборудования в выходной или праздничный день, профессиональные услуги вендора Advanced Services (AS) и Business Critical Services (BCS), если заказчику необходим дизайн сети. Но бизнесу, в котором требования постоянно меняются, зачастую удобнее работать с компанией, которая будет жить в конкретной инфраструктуре, понимать, как она построена, в чем ее плюсы и минусы, узкие места и иметь опыт работы с технологиями разных производителей. Востребованы наши услуги и в системах высокой критичности, где нужен высокий SLA с фиксированным временем решения и круглосуточный сервис. Совместное оказание услуг часто удобно и самому производителю, так как он может не держать большой штат поддержки и сосредоточиться на основном бизнесе, не переживая при этом об уровне сервиса.

В локдаун значительно увеличилось число запросов на организацию и сопровождение VPN-каналов, Next Generation Firewall, SIEM-систем, расследование инцидентов безопасности, поэтому остро встал вопрос расширения команды инженеров по информационной безопасности на вторую линию поддержки.

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

График работы предлагаем стандартный 8 часов 5 дней в неделю. Иногда по отделу назначаются дежурства. Если ночью появилась критичная проблема, то дежурному придется подключиться и разобраться с ней. Но есть и небольшой плюс ехать никуда не нужно, специалисту выдается доступ в систему, с помощью которого он может работать удалено. Собственно, поэтому мы и не зацикливались на Москве или области, а сразу расширили зону поиска на всю Россию.

Почему возникли проблемы

• Небольшое число подходящих специалистов. Забив перечисленные выше параметры на hh.ru, мы видим чуть более 70 человек, находящихся сейчас в поиске работы. Если бы мы искали сотрудника в московский офис, то ситуация была бы еще хуже. Для сравнения, при поиске бухгалтера сайт выдает более 1000 подходящих резюме.

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

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

5 причин обратить внимание на вакансию инженера технической поддержки

1. Быстрый горизонтальный рост компетенций

   Минимальные начальные требования для кандидатов знание сетевых технологий, основ информационной безопасности, шифрования, принципов работы межсетевого экрана и системы предотвращения вторжений. Кроме стандартных файрволов и VPN, инженеры техподдержки работают с такими классами решений как Next Generation Firewall, SIEM, Web Application Firewall, DLP, IPS/IDS, Identity/AccessManagement, IRP/SOAR, Threat Intelligence. Это помогает развиваться не по одному направлению предметной деятельности, а более широко. Наши специалисты детально изучают оборудование ведущих ИБ-вендоров, тестируют в лаборатории его новые версии.

   Идеальный кандидат должен уметь работать в режиме многозадачности, быстро адаптироваться к изменениям и все схватывать буквально на лету. Такой темп работы позволяет быстро продвигаться по карьерной лестнице: в среднем, путь от младшего инженера техподдержки до ведущего эксперта в STEP LOGIC составляет 5 лет.

2. Возможность стать экспертом, так как нужно "копать" глубоко

   Работа инженера внедрения заканчивается после ввода проекта в эксплуатацию. Как сотрудники техподдержки, мы можем с уверенностью заявить, что все самое интересное на этом только начинается. Техническая поддержка это не только консультации клиентов по вопросам функционирования оборудования, удаленная диагностика и настройка, решение проблем, локализация и мониторинг аварий, но и совместная работа с вендором по устранению багов, разработка планов по развитию и миграции инфраструктуры. Недавно мы приняли участие в проекте по миграции, который стал для нас своеобразным челленджем. Немного предыстории: крупный российский банк для защиты периметра продолжительное время использовал межсетевые экраны Cisco ASA. За последний год объем трафика увеличился в несколько раз, и оборудование перестало с ним справляться. Заказчик закупил межсетевые экраны нового поколения Cisco Firepower и перед ним встала задача провести максимально бесшовную замену, так как инфраструктура критическая и должна работать 24х7. Необходимо было перенести с одной ОС на другую большое количество настроек: сотни интерфейсов, тысячи правил межсетевого экранирования, сотню VPN и сделать это в короткое окно работ. Была проведена комплексная работа, включающая в себя изменение настроек маршрутизации, трансляции NAT, редистрибуции и фильтрации тысяч маршрутов, учитывающая переходные процессы с целью минимизации возможных потерь трафика.

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

3. Развить командные навыки работы и soft skills

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

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

4. Научиться работать с технической документацией

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

5. Усовершенствовать технический английский

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

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

• эксперта по классу решений или технологии

• менеджера/сервис-менеджера/product owner по продукту или услуге

• руководителя нового направления/услуги

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

Таким образом, если работа с оборудованием и устранение неполадок приносит радость, среди soft skills присутствует пресловутая коммуникабельность и клиентоориентированность, имеется стойкое желание развить свои технические знания и стать экспертом в конкретной области ИТ, то у вас есть веский повод обратить внимание на вакансию инженера технической поддержки.

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

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

Просто представьте, что у Вас сотня админов, которых Вы ежедневно обеспечиваете работой (это не выдумка, а реальность).

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

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

Можно ли с этим что-то сделать? Конечно! Работающие и очень эффективные меры давно известны это Бережливое производство (Lean Manufacturing) и Теория ограничений (Theory of Constraints, TOC).

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

Небольшой экскурс в Lean и TOC

Давайте начнем с краткого введения в Теорию Ограничений и Бережливое производство в том небольшом объеме, который необходим для понимания концепции этой статьи.

Если говорить кратко, то Бережливое производство это философия (набор методик) для сокращения потерь, ускорения производства и его непрерывного совершенствования с целью увеличения прибыли предприятия.

Теория ограничений это как бы надстройка над Бережливым производством, которая гласит, что в любом производстве есть всего лишь одно единственное узкое место, которое тормозит всё. И скорость всего предприятия в целом равно скорости этого узкого места (бутылочного горлышка).

Бесполезно расширять что-либо еще, кроме бутылочного горлышка это всё равно ни к чему не приведёт. Именно поэтому локальные оптимизации не работают. И именно поэтому нет смысла утилизировать мощности отделов на 100% - это только вызовет перепроизводство.

А вот увеличение производительности горлышка на X% приведет к увеличению прибыли всего предприятия на X%. А это миллионы, а может и миллиарды!

Это если кратко.

Единственная, но очень важная метрика теории ограничений

В Теории ограничений есть, по сути, единственная метрика, на основе которой принимаются все решения это Проход (или Проток, Throughput).

T_u=P TVC,

где T_u величина прохода на единицу продукции;
P цена единицы продукции;
TVC полностью переменные затраты

(https://tocpeople.com/2012/08/upravlenie-predpriyatiem-po-finansovym-pokazatelyam-tos/)

Если грубо, то это операционная прибыль, заложенная в конкретную единицу продукта.

Как это можно использовать?

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

Продукт А стоит 300 руб, а продукт Б 400 руб.

При этом Проход (грубо - Прибыль) продукта А = 100 руб, а у продукта Б = 200 руб

Какие продукты и в каком количестве должен производить человек-бутылочное горлышко, чтобы максимизировать прибыль предприятия (а мы знаем, что именно он определяет всю прибыль предприятия)?

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

Казалось бы, продукт Б стоит дороже и прибыль в нём больше, однако всё не так просто. Для решения уравнения не хватает одной очень важной переменной времени, которое человек-горлышко затрачивает на производство каждого вида продукта.

Время производства продукта А 5 мин, продукта Б 30 мин.

Продукт А: 100 руб / 5 мин = 20 руб / мин

Продукт Б: 200 руб / 30 мин = 6,6 руб / мин

Получается, что при изготовлении продукта А компания получает прибыль в 20 руб/мин, а при изготовлении продукта Б всего 6,6 руб/мин.

Выбор очевиден, не правда ли? Нужно производить как можно больше продукта А, а в оставшееся время продукт Б.

Переложение метрики Прохода для технической поддержки

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

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

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

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

Из Jira, например, можно извлечь следующие данные:

Приоритетзадачи

Категория задачи

Общее время исполнения(от регистрации до перевода в статус Resolved) с учетом всех дней и выходных. Время исполнения с точки зрения клиента от самого начала до самого конца.

Дополнительно можно вычислить Touch time - время ручной работы админа по каждой задаче. Другими словами время, затраченное администратором на задачу за вычетом выходных, нерабочего времени и нахождения задачи в статусе Need Info (запрос доп информации от клиента).

Если на человеке висело несколько параллельных задач, то Touch time вычисляется по каждой завершенной задаче отдельно, а затем берется 85% персентиль от всего полученного множества.

Персентиль не так чувствителен к выбросам как среднее, поэтому его часто используют в качестве гарантированного значения для какого-либо параметра, в нашем случае Touch time.

В Jira значение Touch time можно вычислить как время между сменами статусов.

Время работы человека-горлышка (или время, затраченное на производства продукта) = Touch time

Проход = количество выполненных задач конкретной категории и приоритета

К прохода = Прибыль / Время работы горлышка

или

К прохода = количество выполненных горлышком задач / Touch time

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

Вот реальный пример из службы тех поддержки:

Колонка template Категория задач. Строки упорядочены по убыванию коэффициента прохода.

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

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

Почитайте интересную статью про технологию Swarming в которой есть много подобных нестандартных выводов.

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

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

Поиск бутылочного горлышка техподдержки

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

Если просуммировать время создания ценности и соотнести его с общим временем цикла, то можно посчитать эффективность потока:

Эффективность потока = Суммарное время создания ценности / Общее время цикла * 100%

Часто эффективность потока в компаниях не превышает 5-10%.

Каким образом посчитать эффективность потока для задач тех поддержки?

Если Вы используете Jira, то можно считать время между сменой статусов и в качестве времени создания ценности брать время непосредственной работы админа, но это сложно.

Можно использовать метод проще и считать по количеству выполненных задач за период:

Эффективность потока = Кол-во выполненных задач / (Всего задач в работе) * 100%

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

Вот примеры с реальными данными:

Можно отфильтровать данные по наименее эффективным группам и получить эффективность входящих в них админов.

Что обозначает эффективность потока в тех поддержке?

Эффективность потока это не только подсчет времени потерь. На самом деле это поиск мест, где скапливается незавершенка - большое количество задач в работе, которые никак не могут закончится, либо лежат и ждут своей очереди.

Вот пример реальной ситуации по настоящему, не выдуманному админу:

Как видите, ситуация жесткая он делает всего 4-5 задач в день, а вешают на него аж по 10 штук.

Естественно, о какой эффективности тут может идти речь.

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

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

А если посчитать Touch time и коэффициент прохода, то можно еще и расставить приоритеты исполнения обращений, приходящих в бутылочное горлышко.

Т.е. метрики бережливого производства действительно могут помочь с налаживанием дел в технической поддержки.

Что делать со всеми этими метриками?

Улучшать, конечно. С помощью Kaizen непрерывного совершенствования. В низкой эффективность виноваты не люди виновата система. И её надо перестраивать.

Т.е. нужно находить корневую причину проблемы (истинную причину, а не лежащую на поверхности) и устранять её. И так поступать с каждой проблемой.

Вот хороший пример как в Службе Service Desk использовали Lean (бережливый подход) и что из этого получилось.

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

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

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

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

А почему у админа много задач? Корневой причиной является распространенная ложная установка. Руководство считает, что ресурсы надо утилизировать на 100%, чтобы они не простаивали. Поэтому и загружает админа задачами. Но на самом деле это заблуждение, вызывающее огромные проблемы.

При однозадачности задачи выполняются в разы быстрее, чем при многозадачности:

Решить проблему можно. Теория ограничений для этого случая говорит:

Расширьте бутылочное горлышко

Подчините ему всё производство

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

Простая перестройка процесса позволит админу выполнять только одну задачу за раз. Это может увеличить его производительность в разы:

Вариантов решений множество.

Помните, что этот админ-бутылочное горлышко, по сути, является первопричиной того, с какой скоростью и качеством Ваша служба технической поддержки обрабатывает запросы. Думайте в числах прохода. Если найм или выделение помощника этому админу увеличит проход в 5 или 10 раз, разве это не стоит того?

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

А на этом всё.

NB. Все выводы в этой статье сделаны на основе наблюдений за реальным отделом технической поддержки большой компании.

Автор статьи надеется, что смог показать другую точку зрения на привычные процессы и зародил в читателе зерно сомнения и инакомыслия.

Ваши комментарии он с удовольствием прочитает и ответит на них.

Привет, меня зовут Сергей и я отвечаю за техническую поддержку компании itsoft, так что, в этой статье речь пойдет именно про поддержку.

Поддержка это лицо компании для текущих клиентов. Однако, так ли часто мы сталкиваемся с хорошей поддержкой? Ответ, к сожалению, очевиден.

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

Что всех бесит в поддержке

Начать я решил со списка того, что меня и моих коллег (да и вас, скорее всего) бесит в поддержке:

• долгое ожидание;

• роботы;

• некомпетентность;

• ограниченное количество каналов для связи;

• письма с адреса no-reply@domain.ru;

• нельзя пожаловаться (отсутствие обратной связи).

Долгое ожидание

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

• Сейчас мы не можем ответить на звонок;

• Оператор сейчас ответит, пожалуйста, оставайтесь на линии;

• Сейчас все операторы заняты, вам ответит первый освободившийся оператор;

• Продолжать можно до бесконечности!

Мало того, что нам приходится тратить на это много времени, так еще и далеко не всегда понятно сколько придется ждать, может 5 минут, может 20.

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

Есть уникальное в своем роде решение Ричарда Брэнсона, владельца авиакомпании Virgin Atlantic, который вместо раздражающих и клишированных фраз записал на автоответчик следующее обращение:

Здравствуйте, меня зовут Ричард Брэнсон, я владелец авиакомпании Virgin Atlantic. Сейчас все операторы заняты. Это непорядок. Давайте поступим следующим образом: если через 18 секунд никто не ответит на ваш звонок, вы получите скидку 450 фунтов. Я начинаю обратный отсчет 18, 17, 16, 15

Однако, мы с хоть каким-то подобием данного подхода пока не встречались, к сожалению.

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

Роботы

Переходим ко второму нашему пункту, который нас бесит общение с роботами.

В своих попытках бороться с длительным ожиданием многие компании приходят к решению укомплектовать свою поддержку новыми сотрудниками:

• всевозможными чат-ботами, которые сегодня "умеют" практически все, даже пытаются учиться;

• автоматической системой распределения тикетов с ИИ и без него;

• роботом на телефоне и другими искусственными заменителями.

В редких ситуациях это действительно удобно и скорее всего эффективно, однако, чаще всего это очередная возможность серьезно взбесить своего клиента!

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

У нас даже есть забавная статистика, по которой около 5% обращений в наш онлайн-чат приходят с единственным вопросом: Это робот?. Однако, мы роботами не пользуемся и не планируем, так что, на все обращения отвечают живые сотрудники.

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

Некомпетентность

Следующий пункт, который нас бесит в поддержке некомпетентность сотрудников.

Даже длительное ожидание можно выдержать, если быть уверенным в том, что это принесет результат, однако, именно из-за некомпетентности именно его мы и не получаем.

Попробую перезвонить, чтобы попасть на другого сотрудника, потому что этот не может решить мою проблему. Пользовались таким лайф-хаком?

Бесит, не правда ли? К сожалению, мы уже привыкли получать бесполезную, неточную, а порой и вовсе ложную информацию от поддержки, что, как нам кажется, недопустимо.

Такие причины как низкие зарплаты, а как следствие высокая текучка и низкая квалификация кадров, попавших туда по массовому отбору понятны, а вот что непонятно почему это устраивает большинство компаний?

Пример из жизни: когда-то давно, получив в банке свою первую пластиковую карточку я пытался привязать ее к счету в paypal, но была смешная по нынешним меркам проблема на карточке отсутствовал cvc-код. Забегая вперед скажу, что проблема заключалась в том, что карта не являлась дебетовой, это была visa electron, на которых наличие cvc-кода не предусмотрено. Решалась проблема просто нужно было завести другую карту, например, виртуальную. Однако, для выяснения этой информации мне пришлось раз 6 позвонить в поддержку банка и лишь на третий день на другом конце провода попался компетентный сотрудник, который за 2 минуты все объяснил. Само собой, новую карту я завел уже в другом банке.

Невнимательность

Отдельным пунктом, который мы решили выписать изолировать от некомпетентности будет невнимательность сотрудников поддержки, которая бесит не меньше!

Знакома ли вам ситуация, когда в процессе переписки с поддержкой вы задаете три вопроса, но получаете ответ только на один или два? Нам знакома! Стоит отметить, что даже педантично пронумерованные вопросы тоже могут потеряться. Комментарии тут излишни.

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

Ограниченное количество каналов для связи

Еще один пункт в нашем антирейтинге это ограниченное количество каналов для связи. Какой смысл даже в хорошей поддержке, с которой у вас нет возможности связаться?

Тут речь пойдет не о личных предпочтениях каждого, а о ситуациях, когда вам НУЖНО связаться с поддержкой, но из-за ограниченного количества каналов связи такой возможности не представляется.

Вот достаточный список:

• тикет-система, если клиенту так комфортнее и нужно отслеживать статус обращения;

• адрес электронной почты, если нет возможности авторизоваться в тикет-системе;

• номер телефона, на случай отсутствия доступа в интернет;

• возможность связаться через мессенджер или онлайн-чат, если нет возможности позвонить.

Нам сразу вспоминаются страховые компании, в контактах у которых только номер городского телефона, что очень удобно когда ты за границей. Знакомо?

Не менее крутая ситуация возникает с большинством гос. учреждений, которые принципиально отказываются принимать заявления никак иначе, как на бумаге, которую вы должны привезти лично. ЭЦП? Не, не слышали!

Письма с адреса no-reply@domain.ru

Пожалуй, самый безобидный, но наиболее распространенный пункт, который нас тоже бесит.

В данной ситуации раздражает факт того, что мы не можем ответить на такое письмо. Точнее можем, но его никто не прочитает.

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

Нельзя пожаловаться

Последний пункт, который нас бесит: отсутствие возможности оценить качество поддержки и получить обратную связь. Каждый из нас хоть раз в жизни просил соединить его с руководством, устав добиваться чего-либо от некомпетентного сотрудника поддержки. Но у каждого ли это получилось?

Часто ли вам предлагают возможность оценить качество полученного ответа? На самом деле, такая возможность появляется все чаще, но всегда ли эта оценка на что-то повлияет и поможет решить вашу проблему?

Типичный пример: в некоторых банках окна обслуживания оборудованы кнопками (чаще всего это красный и зеленый смайлик), которые позволяют оценить качество того самого обслуживания. Но что произойдет, если нажать на красный, поставить отрицательную оценку? Вероятнее всего ничего. Возможно, где-то в корпоративной системе будет зафиксирован минус в карму сотруднику, но это не точно (с). Что точно никто не побежит разбираться в причинах негативной оценки, так какой в этом смысл?!

Отсутствие желания у руководства разбираться в каждой негативной ситуации можно понять, но это бесит!

На что влияет качество поддержки

Разобравшись со списком того, что нас бесит в поддержке пришло время подумать, а на что же это влияет?

Тут можно выделить 3 основных момента:

• отток клиентов;

• отсутствие лояльности;

• и как следствие, отсутствие продаж по "сарафанке".

Отток клиентов

Начнем с оттока клиентов, в чем нам поможет исследование ресурса pwc.com. В исследовании проводился анализ причин оттока клиентов, а лидерами рейтинга стали:

• плохое отношение сотрудников компании к клиентам;

• недружелюбное обслуживание клиентов;

• плохая репутация компании;

• некомпетентные сотрудники;

• низкая эффективность;

• недоступность товара (услуги).

Ничего не напоминает?

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

Отсутствие лояльности

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

Лояльность клиента подразумевает:

• адресное и продуктивно общение с отделом продаж;

• объективная, честная и своевременная обратная связь;

• готовность к изменениям, которые вы запланировали;

• помощь, в ряде ситуаций, причем как словом, так и делом;

• и конечно же, рекомендации!

Грамотная, адекватная и доброжелательная поддержка всегда производит хорошее впечатление, клиент будет обращаться к вам с удовольствием и никогда не откажет в диалоге и выслушает ваши предложения. К сожалению, многие этого не ценят, а мы ценим!

Отсутствие продаж по сарафанке

Согласно индексу NPS, стать промоутером вашей компании могут только максимально лояльные клиенты, которые набирают 9-10 баллов, т.е. полностью довольны результатом вашего сотрудничества и качеством услуг. Будет ли доволен клиент, которого бесит ваша поддержка?! Конечно же нет.

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

Методы, которые сработали у нас

Далее, я расскажу про те методы, которые сработали у нас в компании и помогли сделать отличную поддержку. Вот список того, что мы сделали:

• запустили поддержку в Telegram;

• наладили систему премирования;

• внедрили систему оценок качества поддержки;

• перестали работать с некомпетентными и невнимательными сотрудниками.

Поддержка дата-центра в Telegram

Начнем с того, что мы первые, кто запустил возможность обращаться в поддержку дата-центра через Telegram. На данный момент около 20% обращений обрабатываются именно там. Процесс коммуникации простой и понятный всем, кто пользуется этим мессенджером.

Можно воспользоваться виджетом в правом нижнем углу на нашем сайте, либо найти чат в самом мессенджере (@itsoft_bot) и задать интересующий его вопрос.

Для интеграции с рабочей средой (у наc это Slack) использовали сервис telebot.im.

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

Система премирования

Еще один метод, который помогает нам удерживать планку это система премирования, которая завязана на ряд параметров KPI каждого сотрудника поддержки.

Многие параметры KPI связаны непосредственно со скоростью реакции сотрудника на поступившее обращение и качеством его работы, например:

• скорость реакции на поступившее обращение;

• время, которое потребовалось на его закрытие;

• количество пропущенных звонков;

• качество коммуникации с клиентом.

Следовательно, если сотрудник хочет получить премию он заинтересован в том, чтобы быстро и качественно обработать каждое обращение.

Для удобства сотрудников мы внедрили уведомления в Slack, которые срабатывают несколько раз до момента проваленных показателей + в списке тикетов была добавлена цветовая индикация, которая подкрашивает те обращения, которые нужно закрывать в первую очередь.

Если говорить о цифрах, то каждый сотрудник поддержки, который выдерживает уровень своих показателей KPI выше 95% на протяжении некоторого времени может поднять уровень своей зарплаты на 40% от базовой ставки, это не считая премии. Самые же эффективные сотрудники поддержки всегда могут рассчитывать на квартальную премию в размере 50% от уровня базовой зарплаты. Без кнута тут тоже не обходится, но об этом немного позже. Не жалейте денег на сотрудников, мотивация делает вещи!

Система оценок качества поддержки

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

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

Работает система довольно просто. Для начала руководитель внимательно изучает обращение и процесс коммуникации с клиентом, т.к. иногда проблема очевидна. Подключается к решению задачи и связывается с клиентом, предоставляя ему необходимую информацию. Если по контексту ситуации причину понять не получается, руководитель все равно связывается с клиентом и выясняет, что побудило его поставить негативную оценку.

Оценки можно ставить:

• в переписке по электронной почте;

• в тикет-системе;

• в чате Telegram.

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

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

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

Мы не работаем с некомпетентными и невнимательными сотрудниками

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

Звучит проще, чем кажется на самом деле. Но вот как это на самом деле:

• начинается все с длительного отбора и череды собеседований (благодаря премиальной системе и достойному уровню зарплаты мы можем позволить себе опытных специалистов);

• каждый сотрудник поддержки проходит испытательный срок длительностью три месяца;

• на испытательном сроке тратится много сил на закрытие пробелов как по части коммуникаций, так и по техническим моментам (для этого мы разработали подробную систему обучения и массу инструкций, регламентов и регулярно наполняем корпоративную wiki);

• по итогам испытательного срока обязательная аттестация;

• если испытательный срок не пройден - увольняем;

• для тех сотрудников, которые уже прошли испытательный срок действует вышеупомянутая система KPI и правила, которых мы придерживаемся (если показатели KPI продолжительное время ниже 90% - увольняем);

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

Стоит отметить, что даже несмотря на строгость, текучка у нас практически отсутствует, но на это есть свои причины.

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

Риски перемен и как работать с персоналом

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

Нововведения мы стараемся подавать с точки зрения удобства данной для сотрудников (более того, мы в это верим), с точки зрения выгоды, как личной, так и компании в целом.

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

Однако, даже такой подход не может застраховать от ряда проблем, вот 3 основных:

• итальянская забастовка;

• увольнения;

• демотивация и нежелание работать.

К ним и перейдем.

Итальянская забастовка

Итальянская забастовка, это своеобразная форма протеста, которая в первую очередь определяется предельно строгим выполнением правил и инструкций, установленных работодателем, причем не всех, а выборочно и самое главное ни шага в сторону.

Все прекрасно понимают, что такой формат взаимодействия невозможен.

Всегда находятся сотрудники, которые не хотят ничего менять в устоявшейся, родной, привычной схеме работы, им сложно самим принимать решения и ответственность в новых условиях. Они боятся навредить себе и/или компании, приговаривая дайте мне инструкции, и я буду их выполнять. Вот тут начинается самое интересное. Да, правила, инструкции и регламенты нужны и должны быть, но есть 3 момента:

• вы не закроете инструкциями 100% возможных ситуаций;

• ситуации, которые не закрыты инструкцией требуют, чтобы сотрудник думал самостоятельно;

• чем больше инструкций, тем меньше сотрудник думает самостоятельно.

Ситуация, на самом деле патовая, но мы стараемся ее избежать:

• всего должно быть в меру. Инструкции и правила есть, но только самые необходимые, для типовых ситуаций. Мы всегда оставляем свободу для творчества и даем возможность проявить инициативу;

• в узких местах наша система оценки и мотивации гибкая, но не нарушает базовых принципов, цели и правила компании (например, если принято неверное решение, но оно имеет адекватно обоснование, мы дорабатываем систему, а не скидываем вину на сотрудника);

• мы не стесняемся объяснить сотрудникам цели компании, ее принципы, мотивацию руководителя и суть наших бизнес-процессов;

• учим сотрудников вникать в суть проблемы, ведь так проще принять решение, когда ситуация не подразумевает наличие инструкции;

• регулярно доказываем на практике, что руководитель - помощник и друг, а не надзиратель с кнутом, которого нужно избегать всеми силами.

Увольнения

Да, у нас, как и у других случаются увольнения. Значит цели и ценности компании и сотрудника сейчас не совпадают.

Но мы стараемся выяснить чем вызвано такое решение и получить максимально подробную обратную связь:

• устраивает ли заработная плата? (иногда вопрос сводится к сумме, которую мы можем себе позволить, сохранив сотрудника);

• в каком направлении сотрудник решил двигаться? (может быть и нам нужен такой специалист, у нас несколько разных направлений);

• если это результат конфликта, то в чем он заключался? (может быть есть проблемы, о которых мы не знаем);

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

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

Демотивация, нежелание работать

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

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

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

Тут мы придерживаемся следующих принципов:

• система KPI прозрачна и понятна всем, причем, создавалась она не единолично, все участвовали в этом, имея возможность высказать опасения и предложить решение;

• параметры KPI реальны и достижимы, мы не пытались задрать планку на такую высоту, которую никто не возьмет, при этом, не стали опускать ее слишком низко;

• мы поддерживаем тягу сотрудников к развитию своих профессиональных навыков, готовы оплатить им курсы, повысить заработную плату или пригласить на другую должность;

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

Результаты

Как мы знаем, главное это результат, о котором далее и пойдет речь.

Чего мы добились благодаря нашим методам и работе с сотрудниками?

Вот краткий список:

• увеличилась скорость реакции поддержки;

• увеличилась скорость закрытия обращений;

• снизилось количество пропущенных звонков;

• увеличилось количество обращений на сотрудника;

• снизился отток клиентов.

Далее, разберем каждый пункт немного подробнее и приведем цифры.

Увеличилась скорость реакции поддержки

За последние три года мы смогли сократить время ожидания клиентов на 43%. Например, в рамках тикет-системы до середины 2017 года среднее время ответа поддержки составляло 8,6 минуты, на данный момент это 4,9 минуты.

Увеличилась скорость закрытия обращений

Если взять за шаблон такой тип обращения как Подключение IP-KVM, то за три года мы добились сокращения сроков на 76%! Стоит отметить, что и принцип закрытия обращений изменился. Мы не закрываем обращения без обратной связи от клиента (само собой, если это необходимо), а значит, мы добавили промежуточный этап, но все равно стали быстрее.

Снизилось количество пропущенных звонков

Пропущенным звонком мы считаем ситуацию, когда трубку не подняли за 5 гудков, так вот, таких ситуаций стало ниже. Му улучшили показатели с 9% три года назад до 3% на данный момент. 6% не такой уж и выдающийся показательно, но и звонков с тех пор стало больше примерно на 10%.

Увеличилось количество обращений на сотрудника

Многих вышеперечисленных показателей легко достигнуть, растеряв часть клиентской базы или увеличив штат поддержки, но в нашем случае клиентская база росла, а среднее количество обращений на сотрудника за три года увеличилось на 76%, а это значит, что мы стали не просто быстрее, мы стали эффективнее!

Снизился отток клиентов

Эффективность не имеет смысла, если клиенты все равно уходят, но и эту статистику мы смогли выправить.

Вот наши показатели оттока клиентов по годам:

• за 2017-й год средний отток составлял 2,8 %, для нас это много, и мы начали действовать;

• в 2018-м мы получили первые результаты, отток снизился и составил 1,6 %;

• в 2019-м показатель не сильно изменился и оставался на уровне 1,7 %;

• за текущий, 2020-й год средний отток составляет всего 1,1 %.

Мы бы хотели похвастаться показателем меньше 1%, но увы, год выдался трудным и к сожалению, многих клиентов мы потеряли по независящим от нас причинам.

Появился отдел поддержки

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

С полным списком наших клиентов вы можете ознакомиться на нашем сайте.

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

Заключение

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

Служба техподдержки в крупной компании обычно обслуживает целый зоопарк сервисов, например: пару виртуальных АТС, онлайн-магазин, умный дом и охранную систему в придачу. У ребят всегда есть работа тысячи звонков с сотнями проблем от подключения новых телефонных номеров, до отвалившихся IP-камер.

Чтобы упростить работу техподдержки, команда из нашего акселератора разработала автоматизированную систему на базе машинного обучения. Она запускается за 2 дня без подготовки и без помощи специалистов по data science.

Меня зовут Екатерина Мелькова, я тимлид группы продуктовых инноваций в КРОК. Сегодня мы с разработчиками расскажем, как AutoFAQ автоматизирует клиентскую и техническую поддержку.

Тысячи проблем и как их решить

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

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

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

Затем нужно интегрировать бота с helpdesk и корпоративными сервисами и надеяться, что все это будет хорошо работать.

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

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

С этой мыслью мы разработали единую систему обработки обращений для совместной работы людей и алгоритмов. Она получила название AutoFAQ, потому что для запуска не нужны обучающие выборки и долгая подготовка, достаточно FAQ с сайта компании.

UI и почему это не главное

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

С виду AutoFAQ напоминает стандартный helpdesk со списком тикетов, разделением по тематикам вопросов, очередями и окном чата. Из этого же интерфейса доступна история переписки, дашборды, отчетность.

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

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

Возможности чат-бота

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

Классификатор намерений определяет, в чем состоит вопрос, к какой базе знаний обратиться, и какая запись в базе содержит подходящий ответ.

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

У некоторых заказчиков до 30% тикетов покрываются такими простыми ответами. Однако, наш сервис может помочь, даже если для решения проблемы требуются активные действия службы поддержки.

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

Через подключенные интеграции он идентифицирует пользователя и проверяет подключение к камере.

Если камера не отвечает, для начала бот посоветует проверить ее питание. Если отвечает чат-бот предложит перезагрузить камеру, и после подтверждения сам отправит команду на перезагрузку. Если это не помогло, предложит следующее решение.

Когда бот не может решить задачу, в дело вступают сценарии регистрации заявок в ServiceDesk. Запрос пользователя классифицируется, для каждого класса бот собирает необходимые данные и регистрирует полностью заполненный и размеченный инцидент.

С помощью бота клиенты службы поддержки могут управлять заявками: просматривать, комментировать, вносить изменения.

Сценарии и интеграции

C помощью AutoFAQ можно автоматизировать многоступенчатые сценарии решения проблем.

Для этого мы предусмотрели упрощенный описательный DSL-язык. Он нужен для описания основных шагов взаимодействия бота с пользователем и различными сервисами.

Сценарии могут взаимодействовать с REST и SOAP сервисами. Через них можно формировать SQL запросы. Из коробки поддерживаются MS SQL Server, PostrgreSQL, MySQL и MariaDB. Чтобы реализовать сложную логику, в сценарии можно встроить произвольный JavaScript-код.

С описательной частью сценария без проблем справится бизнес-аналитик, а для работы с запросами и JS-блоками достаточно позвать джуниора.

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

Чат-бот и операторы

Конечно, наш бот не идеален и порой не понимает клиентов. Если он не уверен в ответе, и никакие уточняющие вопросы не помогают, система переводит запрос на оператора.

Пока оператор общается с пользователем, бот анализирует диалог и пытается догадаться, какой ответ или сценарий действий уместен в этом случае. Когда система поймет, что к чему, оператор может снова переключить тикет на бота и перейти к следующей задаче.

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

Под капотом

Мы хотели, чтобы AutoFAQ дообучалась на данных, собранных в процессе работы. Задачу осложняло то, что обучение должно было происходить без помощи лингвистов с их ключевыми словами и дата-сайентистов с гиперпараметрами.

Поэтому можно было сразу забыть о классических требованиях к обучающим выборкам. Мы готовились к тому, что перед запуском не будет данных, либо это будет сильно перекошенная выборка. Например, 80% вопросов будет относиться к паре проблем, а для остальных будет только по одному вопросу.

Чтобы система работала из коробки, мы использовали нейронную сеть, предобученную на наших исследовательских проектах. Она отвечает за общение с клиентами службы поддержки, пока AutoFAQ не соберет данные на практике.

Это позволяет запускать AutoFAQ в работу с минимальной подготовкой и сразу получать хорошее понимание вопросов. Благодаря предобученной сетке бот понимает вопросы, сформулированные совершенно иначе, чем в примерах. Поэтому он нетребователен к объему и качеству обучающей выборки.

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

Сразу после запуска AutoFAQ начинает накапливать обучающую выборку и повышать качество понимания вопросов. Чтобы система быстрее начала понимать специфические термины, мы предусмотрели словарь, который можно заполнить вручную.

Обучение на практике

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

Благодаря этому механизму накапливается массив из различных формулировок одного и того же вопроса. Это позволяет системе лучше понимать людей.

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

Всякий раз, когда робот не справляется с обработкой запроса, и на него отвечают операторы, генерируется рекомендация по пополнению баз.

Ответ оператора попадает в реестр рекомендаций. Затем администратор системы просматривает реестр, отбирает и группирует удачные рекомендации и нажатием одной кнопки вносит их в базу знаний.

Собранная таким образом выборка все равно получается несбалансированной, но есть и плюс она состоит из вопросов, которые актуальны здесь и сейчас.

Как только AutoFAQ накапливает достаточный объем данных, предобученный алгоритм отключается, пайплайн перестраивается, и в дело вступают модели, использующие обучение с учителем. Мы заранее не знаем, какой метод будет лучше справляться с данными клиента, поэтому встроили в AutoFAQ сразу несколько алгоритмов: от простых TF-IDF, до BERT и LASER.

Система проверяет объем и сбалансированность обучающей выборки. В зависимости от результатов формируется новый программный конвейер, подбираются алгоритмы и гиперпараметры.

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

На практике, в AutoFAQ часто строятся ансамбли из нескольких алгоритмов. Система постоянно сравнивает их результаты по внутренним метрикам и выдает на выход наиболее уверенные ответы.

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

Запуск AutoFAQ

Мы разбили AutoFAQ на микросервисы и упаковали в докер. Система не требует подключения к сторонним сервисам и работает в изолированной среде. Все ее компоненты дублируются. Они либо работают параллельно, либо запускаются по мере надобности.

Мы рассматривали Kubernetes, но оказалось, что для оркестрации нам хватает Docker Compose. Он упрощает процесс развертывания и не требует kubernetes-кластера.

В результате

AutoFAQ разворачивается за пару часов, подключается к практически любым текстовым каналам коммуникации от электронной почты до Slack и Skype for business. После этого система готова к работе понимает письменную речь, начинает обрабатывать запросы в службу поддержки и накапливать базы знаний.

Чем больше обращений поступает в службу поддержки, тем лучше система их понимает и тем больше задач берет на себя. За 12 месяца AutoFAQ наполняет базу знаний, и автоматизация запускается в полную силу. Как правило, AutoFAQ решает порядка 45% обращений без помощи людей.

Система не заменяет операторов, но избавляет их от большинства рутинных запросов. У сотрудников службы поддержки появляется время на тщательный разбор сложных обращений.

Информация, разбросанная по разным документам у разных операторов, постепенно собирается в единую базу знаний. Отвечать на вопросы и искать решения проблем становится заметно проще.

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

P.S. Если у вас остались вопросы по AutoFAQ, оставляйте их в комментариях или пишите на почту: EMelkova@croc.ru.