Привет, Хабр. Меня зовут Мария Рылик, я — старший контент-менеджер группы управления пользовательским опытом веб-поддержки «Лаборатории Касперского». И полтора года назад я столкнулась с распространенной в техписовских кругах проблемой: децентрализованной базой знаний. Чтобы ��айти инфу по работе с конкретным продуктом, приходилось по крупицам искать ее в разных статьях, в большинстве своем имеющих мало общего с конкретной задачей, которую я пыталась решить.

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

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

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

Предыстория: так исторически сложилось, но больше так нельзя

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

Во многом причина таких показателей была в том, что наши статьи не всегда раскрывали те проблемы, которые были действительно важны для пользователей. Осознав это, я загорелась идеей создать единую систему управления знаниями для B2B-сегмента технической поддержки «Лаборатории Касперского». А конкретнее — упорядочить и актуализировать знания в базах данных и упростить поиск информации для конечных пользователей.

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

Как все работало раньше?

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

• Какие потребности у человека, который зайдет на этот текст?

• Почему ему понадобится эта статья?

• Как расписать ее максимально полезно?

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

И из-за всего этого «рассинхрона» пользователям (как внутренним, так и внешним) было тяжело разобраться в таком калейдоскопе информации. Поэтому юзеры не читали наши статьи и регулярно задавали одни и те же вопросы. А инженерам техподдержки было удобнее отвечать на запросы юзеров не цитатами из наших статей, а информацией из личных заметок в Note, Word или Notion (пока он был еще жив…), в которых они хранили точно актуальную информацию. Если же в собственных заметках инженер не находил ответа на вопрос, то он предпочитал задать его коллеге и воспользоваться его знаниями. В итоге нередко оказывалось, что специалист не мог ответить на вопрос, потому что коллега ушел в отпуск или вообще сменил компанию и знания ушли вместе с ним.

Решение: качаем культуру шеринга

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

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

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

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

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

Решению нашей задачи также помог активный пиар проекта. Чем больше коллег узнавало о том, что все делятся знаниями, тем больше из них думали: «Я тоже хочу!». Соответственно, тем больше информации мы получали, публиковали и могли донести до пользователей.

Делаем шеринг удобнее

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

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

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

Причем этот портал стал единой точкой входа для двух команд. Дело в том, что у нас две базы знаний: внутренняя и внешняя. Команда внутренней базы работает в Confluence, команда внешней — обрабатывает задачи в Jira и публикует через CMS статьи на сайте поддержки.

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

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

Генеральная уборка

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

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

То, что можно отредачить — редачим и обновляем. То, что поправить слишком сложно или вообще не нужно, потому что информация устарела — удаляем. Создаем новые материалы, которых нам не хватает: пишем статьи, подсказки, FAQ.

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

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

Теперь про каждый этап подробнее:

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

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

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

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

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

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

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

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

• Главное в контенте — польза. Если вы пишете красивый, но бесполезный контент, читать его никто не будет.

• Общайтесь с вашей поддержкой. Смотрите инциденты.

• Пишите подсказки и FAQ кратко. Для пользователя максимально полезен короткий, четкий ответ со ссылкой на статью с подробностями.

• Тегируйте статьи, информация из которых вынесена в FAQ, чтобы при обновлении статьи не забыть обновить и FAQ.

• Не игнорируйте «неважные» вопросы. Если ответ на простой вопрос не тянет на целую статью, добавляйте его в FAQ.

• Если возможности создать цельный FAQ нет, создайте сводную статью по самым частым в��просам с врезками в формате вопрос-ответ.

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

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

Все эти советы основаны на моментах, которые мы прошли и «прострадали» на собственном опыте.

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

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

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

У нас работает страница с популярными запросами пользователей.

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

На пятом этапе мы накапливаем статистику и начинаем отслеживать изменения (а они неизбежны). Через каждые 3–6 месяцев возвращаемся к первому этапу. Ознакомившись с изменениями, оцениваем все те же показатели статей: CSAT, посещаемость, используемость и фидбэки.

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

К чему мы пришли?

Организация такой уборки заняла полгода. Наша команда разработала три базы знаний по трем топовым продуктам, еще две базы в работе сейчас. За прошлый год написали 100 новых статей, серьезно переработали больше 200. Обработали почти 1000 крупных тасков.

Количество итераций общения между клиентом и инженером от создания запроса до его решения снизилось. Раньше у кейсов, связанных с продуктами, для которых мы сделали базы знаний, в среднем было почти 5 итераций, теперь 3,8. Эскалаций на вторую линию стало меньше: число снизилось с 19 до 14. То есть теперь инженеры реже идут за помощью к экспертам.

Вырос показатель «дефлекшен», так называемый Self-Service Usage Rate, который отражает, что пользователь зашел в форму создания запроса, но запрос не создал, то есть решил вопрос самостоятельно. Средний дефлекшен у нас 15%, но по ряду категорий достигает 60%, а в некоторые месяцы даже 80%. Это, конечно, зависит от сложности продукта и категории.

Автоответы, которые мы создали, отправляются в 50% случаев. Доля FCR, то есть тех запросов, которые решаются одним касанием инженера, у нас в первом квартале составляет 37%.

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

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

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

Уборка — процесс постоянный

Увы, на одной глобальной зачистке все не заканчивается. Нужно возвращаться, отсматривать актуальные метрики, ведь база знаний — это живой организм.

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

Да и в целом далеко не все знания можно публиковать в текстах. Что-то не разрешит R&D, что-то заблокируют и сами эксперты. Для таких случаев мы пишем статьи, где объясняем, как собрать диагностическую информацию, проверить ее и уже потом идти в поддержку. Это тоже сокращает количество итераций обращения, потому что инженеру не придется несколько раз запрашивать данные. Пользователь уже подготовлен и проверил все, что мог проверить сам.

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

Итоги и мысли о будущем

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

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

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

Главное — четко определить цели и критерии: что нужно написать, что обновить, что удалить, что создать. А также определиться, в каком виде и где вы будете это публиковать.

Все это улучшит пользовательский опыт и упростит работу саппорта.