Что такое база знаний службы поддержки и как её собрать
Кратко
База знаний — собрание статей с готовыми ответами, которым пользуются и клиенты (чтобы решить вопрос без обращения), и операторы (чтобы отвечать одинаково и быстро). Собирают её не «по темам продукта», а по реальным вопросам из очереди: первые десять статей закрывают заметную часть потока, следующие сто — почти ничего.
Две базы знаний, а не одна
Под одним названием живут два разных собрания, и их смешение — источник половины неудач.
Внешняя, для клиентов. Пишется словами клиента, отвечает на его вопрос и не требует знания внутренних терминов. Успех измеряется тем, сколько обращений не случилось.
Внутренняя, для операторов. Пишется словами команды, содержит то, что клиенту не показывают: как проверить в админке, кому эскалировать, какие есть известные ограничения. Успех измеряется тем, насколько одинаково отвечают разные операторы.
Почему нельзя одну на двоих: внешняя статья, в которую дописали внутренние подробности, перестаёт быть понятной клиенту; внутренняя статья, из которой вычистили внутренние подробности, перестаёт быть полезной оператору. Начинать при этом стоит с внутренней — она окупается быстрее и на неё уходит меньше редактуры.
С чего начинать: не с плана, а с очереди
Обычный порядок — сесть и расписать структуру разделов. Он приводит к тридцати статьям, из которых читают три.
Рабочий порядок обратный.
- Взять последние 200 обращений и сгруппировать по сути вопроса, а не по заявленной теме.
- Отсортировать группы по частоте. Обычно первые 10 групп дают заметно больше половины потока — типовые вопросы всегда распределены неравномерно.
- Написать статью на каждую из первых десяти групп. Заголовок — дословно вопрос человека, а не название раздела продукта.
- Остановиться и месяц смотреть, что ищут и не находят. Следующие статьи пишутся по этому списку, а не по плану.
Этот порядок даёт побочный полезный эффект: вы увидите группы, где статья не нужна, потому что вопрос вообще не должен возникать. Двадцать обращений «где найти кнопку X» — это не заявка на статью, это заявка на исправление интерфейса.
Устройство статьи
Единый шаблон важнее качества отдельного текста: читатель учится ориентироваться и перестаёт читать всё подряд.
| Часть | Что в ней | Зачем |
|---|---|---|
| Заголовок | Вопрос словами клиента | По нему находят через поиск |
| Короткий ответ | 2–3 предложения | Половине читателей больше не нужно |
| Шаги | Пронумерованно, с тем, что человек увидит | Чтобы можно было делать по ходу |
| Если не помогло | Что проверить дальше, куда обратиться | Иначе статья заканчивается тупиком |
| Ссылки на смежное | 2–4 штуки | Соседний вопрос почти всегда следующий |
Раздел «если не помогло» — единственный, который обычно забывают, и единственный, из-за отсутствия которого человек, прочитавший статью, всё равно пишет в поддержку, но уже раздражённым.
Признаки мёртвой базы знаний
База знаний умирает тихо: она продолжает существовать, ею перестают пользоваться. Признаки, по которым это видно раньше жалоб:
- Операторы отвечают текстом, а не ссылкой. Значит, найти статью дольше, чем написать ответ заново.
- Даты обновления старше года при живом продукте. Одна устаревшая статья дороже десяти отсутствующих: отсутствие заставляет спросить, устаревшее заставляет сделать неправильно.
- Поиск по базе даёт ноль результатов по частым запросам. Статья, возможно, есть — просто названа внутренним термином.
- Нет ответственного. База без владельца не обновляется. Владелец не обязан писать всё сам, он обязан замечать, что статья устарела.
Кто и когда пишет статьи
Самая работающая схема — писать не по расписанию, а по поводу, и повод всего один: вторая линия решила случай, который может повториться. Тогда решение оформляется статьёй в тот же день, пока контекст свежий, и класс вопросов возвращается на первую линию.
Правило, делающее это устойчивым: статья считается частью решения обращения, а не отдельной задачей «когда будет время». Задача «когда будет время» не выполняется никогда.
Отдельно стоит договориться о том, кто пишет внешние статьи. Оператор, написавший внутреннюю заметку, редко умеет переписать её клиентским языком, и заставлять его не стоит — получится плохо и медленно. Разумнее, чтобы внешние тексты писал один человек на основе внутренних.
Частая ошибка: база знаний вместо ответа
База знаний нужна, чтобы человек мог решить вопрос сам. Она не нужна, чтобы отвечать ссылкой на тех, кто уже написал.
Ответ «вот статья, почитайте» на обращение живого человека воспринимается как отказ, даже когда статья действительно содержит решение. Рабочая форма другая: короткий ответ по существу его случая — и ссылка рядом, для подробностей. Разница в две строки текста, разница в реакции огромная.
Проверить себя просто: посмотрите ответы, состоящие из одной ссылки без единого предложения. По ним же обычно и приходят повторные обращения.
Как проверить за вечер
- Возьмите 50 последних обращений и отметьте те, ответ на которые есть в базе. Высокая доля — база хорошая, но её не находят: проблема в поиске и заголовках, а не в содержании.
- Посмотрите, что искали в базе и не нашли. Это готовый список следующих статей, точнее любого плана.
- Проверьте даты обновления пяти самых читаемых статей. Всё старше полугода при живом продукте — перечитать.
- Посчитайте, сколько статей не открывали ни разу за месяц. Их можно не удалять, но и считать их работой тоже нельзя.
Связанные статьи
- Что такое портал самообслуживания и зачем он поддержке
- Шаблоны ответов: как составить и когда они вредят
- Первая и вторая линия поддержки: чем они отличаются
- Быстрые ответы
Нужна поддержка, которая так и работает?
TehProf Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.