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

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

Всем привет! Эту статью мы готовили с исполнительным директором мультибрендового интернет-магазина туристического снаряжения и сопутствующих товаров «Турторг» (название изменено по просьбе владельцев). Прошло больше года с тех пор, как в компании организовали базу знаний для техподдержки на платформе TEAMLY. Об этом рассказывали в статье Как самому создать базу знаний поддержки. Даём инструкцию. Пришла пора порассуждать на тему вывода базы знаний (БЗ) вовне и снижения нагрузки на службу поддержки.

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

Почему даже хорошая база знаний не всегда работает

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

Вот живой пример. Недавно у нас в интернет-магазине случился всплеск обращений по оплате заказов через новый способ — «Оплата по частям». Как водится, мы сразу добавили статью в базу знаний: подробно расписали шаги, сделали скриншоты — и решили, что всё описали.

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

Почему клиенты не находят ответы: 5 главных причин

Проблема, как оказалось, не только в том, что не всё написали. А в том, как описали и поставил ли автор себя на место клиента. Вот причины:

• Нужная информация отсутствует в БЗ. Типовые вопросы про «оплату частями» объяснили не всё: конкретных нюансов (например, как отменить платёж, куда приходят уведомления) в базе не было вовсе. Такие «дыры» быстро выявляются анализом «нулевых результатов поиска» или Zero Result Searches — то есть когда поиск не выдал релевантных запросу результатов.
• Плохая навигация и тегирование. Вбивая в поиск «отмена платежа» или «проблема с рассрочкой», пользователь не видит подходящих статей, потому что они озаглавлены сухо («Пошаговая инструкция по оплатам»), без упоминания в тегах ключевых слов и категорий, которыми мыслит клиент. Например «отменить заказ» и «вернуть платёж» для клиента — это, часто, синонимы. А для поддержки, разумеется, два совершенно разных процесса. Но статьи должны иметь нужные теги!
• Статьи слишком сложные или абстрактные. Иногда инструкция понятна только специалисту — а клиент путается. Сюда же отнесу инструкции, написанные «юридическим» языком или канцеляритом,  длинные «портянки».
• Недостаточная проработка инструкций в связи с изменениями, провоцирующая всплески запросов после релизов новых UX-решений. 
• Операторы сами не находят статьи. Если сотрудник открытия заказов не использует базу знаний, а пишет ответ «от себя» — скорее всего, информация в БЗ либо неудобна в поиске, либо не актуализирована, либо оператор не знает о её существовании.

Как выглядит этот путь глазами клиента

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

Саша открывает вкладку «Помощь», вводит в поиске «недостаточно средств» — результатов нет. Пытается «ошибка оплаты по частям» — ничего полезного. Какое-то время Саша пробует ещё, потом пишет в чат поддержки и ждёт ответа, нервничая за свой подарок.

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

Какие данные реально нужны для анализа

Чтобы не повторять эти сценарии, собирайте метрики:

• Поисковые запросы клиентов: что ищут, как формулируют, какие при этом используют «нехарактерные» слова.
• Популярные и редкие запросы.
• Запросы без результатов (Zero Result Searches) — индикатор того, что темы не раскрыты или ключевые слова в статьях не совпадают с «языком клиентов».
• Рейтинг и фидбек по статьям: чаще всего низкий рейтинг или комментарии «ничего не понятно» идут по действительно слабым материалам.
• Частота использования БЗ операторами — как часто они находят статью и пересылают ссылку вместо «копипасты» из какого-нибудь своего гугл документа.
• Новые тикеты по темам, которые должны быть закрыты статьями, но клиент открывает их снова и снова.
• Время между поиском информации клиентом и созданием тикета. Все эти показатели легко собираются в СУБЗ, имеющих собственные аналитические модули. Как, например, в TEAMLY.

Пример совместной работы над корректировкой статьи в БЗ TEAMLY

Как аналитику превращают в реальное улучшение поддержки

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

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

Сбор данных и их сегментирование

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

Определение паттернов

Например, по отчётам Teamly стали очевидны три темы:

• Внезапный рост поисков «как отменить заказ» в день после крупных распродаж.
• Всплеск интереса к статье «Условия доставки в регионы» после запуска новой акции.
• Регулярные обращения по «оплате частями» через мобильное приложение, которых не было в web-версии. Это позволяет быстро мобилизовать команду: выпустить специнструкцию, сделать инфографику, добавить видеоролик в статью базы знаний.

Приоритизация: не пытайтесь сделать всё и сразу

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13470 тендеров
проведено за восемь лет работы нашего сайта.

Логика простая: если 10% клиентов за сутки не могут найти ответ про отмену заказа — устраняйте это сразу, потому что поток тикетов и потери времени операторов больше всего ударят именно по этой теме. Малозначимые вопросы (например, «Тарифы для оптовиков» с частотностью 0,85%) можно корректировать позже.

Исправления и обновления базы знаний службы поддержки

Действенные методы:

• Добавлять новые статьи с фокусом на реальные формулировки клиентов: «отмена оплаты по частям», «ошибка оплаты рассрочка», «как быстро отменить заказ».
• Редактировать заголовки и теги — использовать не только термины из внутренней документации, но и «живой» язык клиентов, проверяя метрики поисковых фраз.
• Включать примеры и скриншоты по принципу «можешь показать — покажи», настраивать структуру по принципам «Шаг 1 — Шаг 2 — и т.д.», «Возможные ошибки — Пути решения» — то, что в английской традиции называется Troubleshooting.
• Добавлять краткое видео или FAQ прямо в начало статьи: это реально снижает время поиска решений.

Обучение операторов и контроль качества

Результаты внедрения аналитики нужны не только для развития базы знаний — показывайте их команде. Проводите мини-сессии по разбору популярных тикетов. Давайте обратную связь по скриптам и ответам, мотивируйте использование БЗ в работе: так исчезает формат «каждый всё решает по-своему», знания становятся коллективным активом, который обновляется и растёт.

Сравнение метрик до и после изменений

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

Как должна измениться эффективная база знаний — реальный пример

Вернёмся к истории с «оплатой по частям». После анализа тикетов и истории поиска в Тимли мы сделали следующее:

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

• Какую карту можно использовать для оплаты?
• Как отменить платеж по частям, если уже оформил заказ?
• Почему возникает ошибка «недостаточно средств»?

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

Сценарий: как покупатель находит ответ без обращения в поддержку

Маша оформляет заказ, выбирает «Оплата по частям». При ошибке «Недостаточно средств» она открывает вкладку «Помощь», вводит: «ошибка оплаты по частям». Система находит статью с актуальными тегами. Уже из краткого FAQ в начале материала Маша видит причину ошибки (на карте должна быть сумма не менее первого платежа), понимает, что делать дальше, и не пишет в поддержку. Итог — клиент доволен, тикет не создан, оператор работает над следующей задачей или, наконец-то, получает возможность пообедать.

Признаки хорошей базы знаний

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

• Главная страница. Здесь могут быть, например, раздельные пункты для «Новичков» и «Продвинутых пользователей».
• Быстрый поиск по ключевым словам, который «прощает» опечатки и предлагает наиболее популярные запросы.
• Понятные категории, например, «Платежи», «Доставка», «Личный кабинет», «Акции», «Бонусы и промокоды».
• Внутри категорий — набор статей с кликабельными заголовками. Хорошо, если в заголовке есть сразу и вопрос, и ответ.
• В каждой статье — цепочка: краткий ответ → конкретный алгоритм решения → блок «Возможные ошибки и что делать» → пошаговые инструкции/скриншоты → FAQ → видео по теме. Не обязательно в такой последовательности, статья спокойно может начинаться с видео.
• Внизу — ссылки на смежные статьи и возможность оценить полезность статьи, оставить обратную связь авторам базы знаний.

Аналитика как источник счастья

Когда покупатель легко находит ответы на свои вопросы, он счастлив. Значит, меньше обращается в службу поддержки. И её начальник тоже счастлив. У него нет KPI по количеству тикетов, только время реакции и NPS.

Грамотная аналитика позволяет построить действительно хорошую базу знаний. И тогда происходит следующее:

• Снижается поток однотипных запросов, освобождается время операторов для сложных случаев.
• Поддержка работает быстрее, больше клиентов остаётся лояльными.
• Статьи действительно помогают людям, а не живут «для отчётности».
• А главное — команда превращает опыт обращений клиентов в ценное знание, доступное каждому: и новичку, и постоянному покупателю.

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

С чего начать изменения в базе знаний?

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

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

Кстати, на собственную внешнюю БЗ нас вдохновил опыт Teamly. Ребята как раз рассказали о ней в статье Как внешняя база знаний снижает затраты компании на техподдержку клиентов. Мы же пользовались Академией Тимли при работе над собственной базой.