С чего начать базу знаний: первые десять статей

Оператор в конце дня закрывает ноутбук и вспоминает, что три раза объяснял одно и то же: где скачать счёт, почему не приходит письмо и как поменять e-mail в профиле.

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

В этот момент обычно хочется «сделать базу знаний». Открыть пустой документ, придумать разделы, нарисовать оглавление: «Оплата», «Доставка», «Личный кабинет», «Возвраты». Выглядит солидно, но часто заканчивается папкой из двух статей и чувством вины.

Начинать лучше не с оглавления. Начните с десяти вопросов, на которые вы уже отвечали на этой неделе.

Оглавление кажется порядком, но прячет настоящую работу

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

В поддержке всё наоборот. Клиент не спрашивает: «Покажите мне раздел про финансовые документы». Он пишет: «Где акт?», «Мне нужен счёт на юрлицо», «Оплата прошла, а тариф не включился».

Если начать с большого оглавления, команда быстро уходит в абстракции. Появляются статьи «Общие сведения об оплате» и «Работа с личным кабинетом». Они вроде полезные, но оператору всё равно приходится дописывать клиенту конкретный ответ.

Первые статьи должны закрывать не темы, а повторяющиеся ситуации. Не «Оплата», а «Как получить счёт на оплату для юрлица». Не «Аккаунт», а «Что делать, если не приходит письмо для входа».

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

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

Десять вопросов проще найти, чем придумать

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

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

Смотрите не только на одинаковые формулировки. Клиенты редко пишут одинаково. Один спрашивает: «Где чек?», второй: «Мне нужен документ для бухгалтерии», третий: «Оплатили картой, как получить подтверждение?». Для базы знаний это может быть одна статья, если ответ по сути один.

Хороший список первых десяти вопросов выглядит примерно так:

• как войти, если письмо со ссылкой не пришло;
• где скачать счёт, чек или акт;
• как изменить e-mail или телефон в аккаунте;
• что делать, если оплата прошла, а доступ не появился;
• как отменить подписку;
• можно ли вернуть деньги и на каких условиях;
• как добавить коллегу в аккаунт;
• почему не видно заказ, проект или заявку;
• как поменять тариф;
• куда написать, если вопрос срочный.

Это не универсальный шаблон. У интернет-магазина вместо тарифа будут доставка, самовывоз и размерная сетка. У сервиса для бизнеса — документы, доступы и роли. У школы — расписание, перенос занятия и сертификаты.

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

Если спорите, что важнее, берите не самый громкий вопрос, а самый повторяемый. Один сложный конфликт с крупным клиентом может съесть полдня, но статья по нему пригодится редко. А короткий вопрос про счёт может появляться каждый день и каждый раз отрывать оператора от очереди.

Статья должна отвечать так, как ответил бы хороший оператор

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

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

Для первых статей хватает короткой структуры:

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

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

Дальше — шаги: посмотреть e-mail в профиле, проверить письмо с подтверждением, обновить страницу, написать в поддержку и приложить номер платежа. Если есть ограничения, их нужно назвать. Например: «Мы не видим полный номер карты и не просим его присылать».

Чем конкретнее статья, тем меньше у клиента поводов вернуться с уточнением. «Перейдите в настройки» хуже, чем «Откройте профиль в правом верхнем углу и выберите “Документы”». Но конкретика требует платы: статью придётся обновить, если интерфейс поменяется.

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

Черновик можно собрать из уже отправленного ответа

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

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

Возьмите один хороший ответ и уберите из него всё личное:

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

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

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

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

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

Без владельца база быстро превращается в склад старых ответов

База знаний устаревает не потому, что кто-то плохо работает. Просто продукт меняется. Появляется новый тариф, переезжает кнопка, меняется срок возврата, бухгалтерия просит другую формулировку в документах.

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

Для первых десяти статей не нужна сложная редакция. Нужны два правила.

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

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

Цена такого порядка — немного дисциплины. Кто-то должен раз в неделю открыть список замечаний и поправить тексты. Если этого не делать, база знаний станет ещё одним местом, куда страшно отправлять клиента.

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

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

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