Как HRlink сэкономил 6,5 млн в год на внедрении базы знаний

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

Привет! Меня зовут Ксения Нейман, я руководитель службы заботы о клиентах в HRlink — сервисе кадрового электронного документооборота.

За два года мы выросли в два раза. Расскажу, за счет чего поддержка не пробила дно, а стабильно вывозит 25 000 обращений в месяц, экономя при этом 6,5 млн рублей в год. Расскажу, как мы этого добились.

Кадровый электронный документооборот HRlink — это как ЭДО, но не для бухгалтерии с контрагентами, а для кадровика с сотрудниками.

HR может:

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

Для распределённых команд (будем честными, и для коллективов в офисе тоже) придумать что-то более удобное сложно.

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

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

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

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

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

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

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

В сложных случаях мы могли обратиться к разработчикам, архитекторам, менеджерам — к любому человеку вплоть до директора — все няшки, все друг другу помогают. Такое положение дел устраивало сотрудников и руководство, саппорт соблюдал прописанное SLA (Service Layer Agreement или Соглашение об уровне услуг).

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

Решение руководства о масштабировании бизнеса нарушило домашний уют саппорта. С приходом новых клиентов обращения посыпались, создавая настоящую лавину — 25 000 обращений в месяц! Старой командой со старыми процессами такое было просто не вывезти.

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

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

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

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

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

Отказались от всех продуктов на вики-движке. Здесь можно спорить, но для наших специалистов вики-разметка неудобна. Она ни с чем не совместима, ни на что не похожа — её знание бесполезно в перспективе.

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

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

Далее мы выписали требования заинтересованных лиц, а по ним сформировали шорт-лист из отечественных сервисов баз знаний.
Сравнили тарифные планы, и в топ вышел сервис Teamly.

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

Чем хороша для нас эта платформа:

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

Сотрудник службы заботы на стартовой странице видит основные разделы. Информация в них классифицирована по какому-то объединяющему свойству. У нас таких четыре:

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

Внутри разделов есть головные статьи со ссылками на всё более и более конкретную информацию.

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

Для чего нужны перекрёстные ссылки в базе знаний? Ответ прост: база знаний, в которой одна и та же информация дублируется — это плохая затея. Во-первых, дубли статьи могут иметь отличия друг от друга. Во-вторых, обновить все статьи при изменении информации — работа только для очень внимательных людей. Принцип «один вопрос/сущность — одна статья» снимает все эти сложности.

В базе знаний HRlink много сложных терминов. Это обусловлено спецификой предметной области. Электронному кадровому документообороту в принципе ещё нет даже трёх лет . И саппорт должен отличать друг от друга, например, четыре вида электронной подписи.

Поэтому в базе знаний мы расшифровываем все термины. Если к нам пришёл новичок из саппорта компании или другой сферы (доставка еды, торговые площадки) – ему не нужно спрашивать или гуглить, он просто откроет базу знаний.

Разумеется, мы обучаем и приучаем всех сотрудников к работе с базой знаний с первого дня. Центр обучения после лекций даёт задание самостоятельно найти ответы на некоторые вопросы в TEAMLY

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

Спрашивать олдов можно, но у них своя работа и свои KPI, им некогда отвечать ещё и на вопросы коллег. Можно смотреть старые шиты — диалоги в инцидентах в БД поддержки. Но способы решения могут не сработать, потому что изменился сам сервис HRLink.

Владение TEAMLY — часть аттестации после испытательного срока. Сотруднику дают 40-60 вопросов, ответы на которые он должен найти в базе знаний.

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

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

Мотивация рублём. В KPI сотрудников есть два показателя, напрямую зависящие от использования базы знаний. Первый — та самая средняя оценка качества. Чем она выше, тем выше зарплата специалиста.

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

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

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

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

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

Инженер отвечал, сотрудник саппорта отписывался клиенту. Следующая задержка — и всё по тому же кругу.

Мы собрали значения статусов в статью базы знаний. Теперь для ответа на обращение пользователя специалист службы заботы видит статус в УЦ и сразу отписывается клиенту о том, на каком этапе сейчас выпуск и что клиент в связи с этим должен сделать (или сколько ждать).

В результате достигаются сразу три преимущества:

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

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

Напомню. Мы начинали с 5 специалистов, каждый из них обрабатывал 10 текстовых обращений и 2 звонка в день.

После масштабирования поток обращений увеличился до 25 000 (!) в месяц. Даже не буду приводить расчётное количество специалистов, если бы они работали также, на расслабоне. Мы подсчитали, что без базы знаний нам нужен был бы 31 специалист при норме 800 тикетов в месяц или примерно 40 в рабочий день.

Внедрение TEAMLY позволило одному сотруднику отрабатывать 1150 тикетов в месяц — эту норму мы вывели эмпирическим путём. Вот что получилось в цифрах.

Только экономия фонда оплаты труда составила 29% или 6,48 млн рублей в год при средней зарплате одного сотрудника в 60 000 рублей.

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

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

Ещё у нас снизилось количество сообщений в одном тикете. Оно уменьшилось на треть — значит, на треть выросла скорость решения, повысилась лояльность клиентов.

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

Сколько удалось сэкономить на техподдержке с помощью базы знаний подсчитала Ксения Нейман – руководитель службы заботы о клиентах в HRlink.

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

Например, для лидеров команды разработки мы выработали план, чтобы разные команды на одном проекте не делали одно и то же. И мы готовы им поделиться!

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