Как HRlink сэкономил 6,5 млн в год на внедрении базы знаний
Расскажем, за счет чего поддержка не пробила дно, а стабильно вывозит 25 тысяч обращений в месяц, экономя при этом 6,5 млн рублей в год.
Привет! Меня зовут Ксения Нейман, я руководитель службы заботы о клиентах в HRlink — сервисе кадрового электронного документооборота.
За два года мы выросли в два раза. Расскажу, за счет чего поддержка не пробила дно, а стабильно вывозит 25 000 обращений в месяц, экономя при этом 6,5 млн рублей в год. Расскажу, как мы этого добились.
Квест для поддержки
Кадровый электронный документооборот HRlink — это как ЭДО, но не для бухгалтерии с контрагентами, а для кадровика с сотрудниками.
HR может:
- принять сотрудника на работу, заключив трудовое соглашение;
- подписать допник к нему;
- составить приказ и отправить его для подписания сотрудниками;
- отработать заявления сотрудника, оформленные по КЭДО — на отпуск, на отгул, на матпомощь — в сервисе масса шаблонов;
- вести электронный архив кадровой документации.
Для распределённых команд (будем честными, и для коллективов в офисе тоже) придумать что-то более удобное сложно.
В ходе работы у пользователей сервиса возникают различные вопросы, на которые в HRlink отвечает служба заботы о клиентах — так у нас называется поддержка.
Были проблемы: сотруднику техподдержки нужно было пройти целый квест, чтобы получить ответ на элементарный вопрос.
Например, пользователь хочет знать: когда будет готова его электронная подпись.
Для этого сотруднику нужно зайти в удостоверяющий центр → посмотреть статус → уточнить его в поддержке центра, которая отправит ответ нашим инженерам — и тогда надо узнавать статус у них.
А это автоматически приводит к эскалации тикета на следующий уровень поддержки, что плохо: в ответ втягиваются лишние люди, в процессе отработки появляются дополнительные шаги, которые приводят к задержкам.
Усложняет работу новизна предметной области. КЭДО существует всего пару-тройку лет, и, как любое новшество, вызывает массу вопросов клиентов — а это снова время на уточнение того, чего хочет пользователь и что знают по этому поводу коллеги.
Как нам жилось без базы знаний
В самом начале у нас было пять сотрудников, как минимум двое из которых работали со дня основания компании и были настоящей энциклопедией для остальных.
Вопросы решали коллегиально — это просто, когда все находятся в одном помещении, а самих обращений не так уж и много: в среднем 10 сообщений в чате и два звонка в день на специалиста.
В сложных случаях мы могли обратиться к разработчикам, архитекторам, менеджерам — к любому человеку вплоть до директора — все няшки, все друг другу помогают. Такое положение дел устраивало сотрудников и руководство, саппорт соблюдал прописанное SLA (Service Layer Agreement или Соглашение об уровне услуг).
Информацию о способах решения вопросов каждый сотрудник фиксировал самостоятельно — в блокноте, на стикерах, в гуглдоке. Естественно, информация по одному и тому же вопросу в этих «хранилищах» отличалась.
В кросс-функциональных командах есть похожая проблема: каждый делает свою часть работы, но из-за того, что не выстроен обмен информацией, люди делают одну и ту же работу или вовсе не то. Как с этим справиться?
Поговорим на бесплатном вебинаре 20 февраля!
Решение руководства о масштабировании бизнеса нарушило домашний уют саппорта. С приходом новых клиентов обращения посыпались, создавая настоящую лавину — 25 000 обращений в месяц! Старой командой со старыми процессами такое было просто не вывезти.
Остро встали вопросы об обучении и адаптации сотрудников службы заботы, оценке их знаний, поддержании этих знаний на должном уровне, информировании об изменениях в сервисе и способах решения типовых задач пользователей. И всё это для обеспечения того самого SLA.
Почему потом стало плохо?
Начнём с того, что на фоне масштабирования онбординг большой массы сотрудников у нас проходил хаотично. Эйчары вели свои таблицы, мы — служба заботы о клиентах — свои.
Качество поддержки упало: у сотрудников не хватало информации, вся она была разрознена, за актуальностью и корректностью следить было невозможно. Немалая часть полезных знаний была только в головах «старичков», а они не успевали передавать её «из уст в уста».
Выход один — база знаний. Сложный выбор
Решить основную часть вопросов, поставленных руководством, нам помогла база знаний. В ней мы проводим онбординг и тестирование. Она же — единый источник информации для саппорта.
Мы долго выбирали средство для реализации нашей базы знаний. Сначала решили, что это будет сервис, а не локальное решение — нам не хотелось развёртывать серверы, организовывать доступ для удалённых сотрудников.
Отказались от всех продуктов на вики-движке. Здесь можно спорить, но для наших специалистов вики-разметка неудобна. Она ни с чем не совместима, ни на что не похожа — её знание бесполезно в перспективе.
Определились с отечественным происхождением. После известных событий февраля 2022 года многие зарубежные сервисы просто закрыли доступ к базам знаний для российских пользователей.
Нашим коллегам пришлось буквально выцарапывать свои базы, срочно переносить их на локальные сервера или в российские сервисы. Мы сами пробовали Confluence и не стали мириться с риском потерять к нему доступ, когда в августе 2023 Atlassian просто заблокировал российские аккаунты.
Далее мы выписали требования заинтересованных лиц, а по ним сформировали шорт-лист из отечественных сервисов баз знаний.
Сравнили тарифные планы, и в топ вышел сервис Teamly.
Заказали бесплатную демонстрацию, потестировали в пробный период. Поняли, что не ошиблись в выборе и успешно пользуемся вот уже скоро год.
Чем хороша для нас эта платформа:
- очень удобный интуитивный поиск, учитывающий особенности русского языка.
- можно структурировать информацию так, как нужно нам.
- визуальный редактор позволяет не задумываться о разметке, делать структуры заголовков и оглавления, выделять важное в тексте.
- в статьи можно вставлять диаграммы из сервиса diagram.net, документы и таблицы гугл — это нам очень помогло на этапе внедрения.
Сотрудник службы заботы на стартовой странице видит основные разделы. Информация в них классифицирована по какому-то объединяющему свойству. У нас таких четыре:
- описание сервиса;
- информация службы;
- инструкции для сотрудников;
- регламенты.
Внутри разделов есть головные статьи со ссылками на всё более и более конкретную информацию.
Например, описание сервиса содержит статью «Функциональные блоки». Статьи названы интуитивно понятно, так что при навигации обычно вопросов не возникает.
Для чего нужны перекрёстные ссылки в базе знаний? Ответ прост: база знаний, в которой одна и та же информация дублируется — это плохая затея. Во-первых, дубли статьи могут иметь отличия друг от друга. Во-вторых, обновить все статьи при изменении информации — работа только для очень внимательных людей. Принцип «один вопрос/сущность — одна статья» снимает все эти сложности.
Как внедрить базу знаний и не нажить себе врагов
В базе знаний HRlink много сложных терминов. Это обусловлено спецификой предметной области. Электронному кадровому документообороту в принципе ещё нет даже трёх лет . И саппорт должен отличать друг от друга, например, четыре вида электронной подписи.
Поэтому в базе знаний мы расшифровываем все термины. Если к нам пришёл новичок из саппорта компании или другой сферы (доставка еды, торговые площадки) – ему не нужно спрашивать или гуглить, он просто откроет базу знаний.
Разумеется, мы обучаем и приучаем всех сотрудников к работе с базой знаний с первого дня. Центр обучения после лекций даёт задание самостоятельно найти ответы на некоторые вопросы в TEAMLY
К использованию TEAMLY подталкивает сама организация обучения и адаптации. Саппорт разбирает кейсы, находя ответы на вопросы клиентов в базе знаний. Это единственный источник информации.
Спрашивать олдов можно, но у них своя работа и свои KPI, им некогда отвечать ещё и на вопросы коллег. Можно смотреть старые шиты — диалоги в инцидентах в БД поддержки. Но способы решения могут не сработать, потому что изменился сам сервис HRLink.
Владение TEAMLY — часть аттестации после испытательного срока. Сотруднику дают 40-60 вопросов, ответы на которые он должен найти в базе знаний.
Контроль качества. У нас есть специальный отдел, который случайным образом выбирает тикеты и проверяет, насколько корректно они решены, как клиент оценил работу саппорта.
И здесь ребята быстро понимают, что самую актуальную информацию нужно искать именно в базе знаний – это помогает получить высокую оценку. А ещё самые крутые кейсы из практики специалисты сами скидывают нам, чтобы мы включили их в базу знаний.
Мотивация рублём. В KPI сотрудников есть два показателя, напрямую зависящие от использования базы знаний. Первый — та самая средняя оценка качества. Чем она выше, тем выше зарплата специалиста.
Второй — каждый квартал сотрудники службы заботы проходят тестирование по специфике работы сервиса, процессам, поддержке. Все ответы есть в базе знаний, достаточно правильно поискать. Прошёл тест — весь следующий квартал имеешь немалый бонус к зарплате.
Решение типового вопроса — до и после
Вернёмся к вопросу из начала статьи — клиент интересуется, как дела с его электронной подписью.
В процессе участвуют три стороны: HR, который формирует заявление для пользователя, сам сотрудник, который подтверждает это заявление и удостоверяющий центр, где создаётся электронная подпись. Задержка в процессе влечёт за собой обращение кадровика или сотрудника в службу заботы.
При работе над обращением сотруднику саппорта нужно посмотреть по статусу, что происходит с электронной подписью, выявить проблему, которая произошла на пути заявления.
Как ребята делали раньше: заходили в удостоверяющий центр (УЦ), смотрели статус, и, если не могли разобраться сами, писали в поддержку УЦ. Сотрудники службы заботы не всегда понимали ответ, изобиловавший терминами и кодами ошибок, поэтому большую часть обращений приходилось эскалировать на уровень инженеров — иначе ответ было не сформулировать.
Инженер отвечал, сотрудник саппорта отписывался клиенту. Следующая задержка — и всё по тому же кругу.
Мы собрали значения статусов в статью базы знаний. Теперь для ответа на обращение пользователя специалист службы заботы видит статус в УЦ и сразу отписывается клиенту о том, на каком этапе сейчас выпуск и что клиент в связи с этим должен сделать (или сколько ждать).
В результате достигаются сразу три преимущества:
- снижается количество эскалаций (об этом я расскажу чуть позже на цифрах);
- снижается время ответа на обращение;
- повышается лояльность клиента — он предупреждён, а значит, вооружён.
До внедрения базы знаний количество эскалаций с первой линии поддержки говорило о её неэффективности. Сейчас же метрики показывают, что она работает хорошо.
Спойлер: первая линия закрывает самостоятельно 83% обращений!
Результаты внедрения базы знаний
Напомню. Мы начинали с 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 нам удается планировать задачи так, чтобы команда не выгорала, и успевала в обновлять продукт в срок.