Как построить базу знаний техподдержки

Зачем она нужна раньше, чем кажется

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

База знаний решает три задачи сразу:

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

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

Что складывать в базу знаний

Хорошее правило: в базу идёт то, что уже спрашивали дважды. Конкретно:

• типовые неисправности и проверенный порядок действий по ним;
• инструкции по настройке оборудования и ПО, которое вы обслуживаете;
• регламенты: что делать при аварии, как эскалировать, кого звать ночью;
• ответы на частые вопросы клиентов — их можно сделать публичными;
• особенности конкретных клиентов: нестандартная схема, доступы, контакты на объекте.

Что НЕ надо тащить: пароли и доступы (для этого менеджер секретов), устаревшие инструкции «на всякий случай» и пересказ официальной документации вендора — вместо него достаточно ссылки.

Структура: чтобы находили, а не искали

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

Что работает:

• плоская структура вместо глубокой вложенности — максимум два уровня;
• разделы по типу оборудования или услуги, а не по отделам компании;
• теги для сквозных тем («аварии», «первая линия», конкретный клиент);
• нормальный поиск по тексту — на объёме больше 50 статей это важнее рубрикатора.

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

Шаблон статьи-решения

Единый формат экономит время и пишущему, и читающему. Минимальный работающий шаблон:

• Симптом — как проблема выглядит глазами клиента, его словами;
• Причина — что на самом деле происходит;
• Решение — пронумерованные шаги, которые можно выполнить не думая;
• Если не помогло — куда эскалировать и что приложить;
• Дата и автор — чтобы было видно, не протухла ли статья.

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

Как не дать базе умереть

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

• Встройте в процесс: закрыл нетиповую заявку — либо статья есть, либо создаёшь;
• Назначьте владельца — конкретного человека, который раз в месяц чистит устаревшее;
• Правьте прямо из заявки: если инженер нашёл неточность, поправить должно быть делом одной минуты;
• Удаляйте смело — устаревшая инструкция хуже, чем её отсутствие, потому что ей верят.

Как понять, что база работает

Смотрите не на число статей — это тщеславная метрика. Смотрите на эффект:

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

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