Шаблон статьи базы знаний поддержки: образец структуры

Кратко

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

Готовый образец

ОБРАЗЕЦ 1. СТАТЬЯ ДЛЯ ПОЛЬЗОВАТЕЛЯ

Заголовок: <как человек опишет проблему своими словами, а не как она называется у нас>

Примеры: «Не приходит письмо с кодом подтверждения», а не «Сбой доставки OTP».

Кому подойдёт эта статья

Эта статья для случая, когда <точный признак: вы нажимаете «Отправить код» и письмо не приходит дольше пяти минут>.

Если у вас <другой близкий признак> — смотрите статью <ссылка>.

Что происходит (две–три строки, без внутренних терминов)

<Простое объяснение причины. Если причин несколько, перечислите их в порядке убывания частоты.>

Решение

• <Действие. Одно действие на шаг, начинается с глагола.>

Что должно получиться: <наблюдаемый признак>.

• <Действие.>

Что должно получиться: <наблюдаемый признак>.

• <Действие.>

Что должно получиться: <наблюдаемый признак>.

Если не помогло

Проверьте: <второе по частоте объяснение>.

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

Сколько занимает: <2 минуты>

Обновлено: <ДД.ММ.ГГГГ> · Проверил: <ФИО>

ОБРАЗЕЦ 2. ВНУТРЕННЯЯ КАРТОЧКА РЕШЕНИЯ — для операторов, пользователю не показывается

ПРАВИЛА ВЕДЕНИЯ

Как заполнять

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

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

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

Блок «Если не помогло» — с перечнем того, что приложить. Это переводит обращение сразу в решаемое состояние: вместо трёх писем уточнений сразу приходит нужное. Сам перечень — те же поля, что в форме приёма: см. Форма приёма заявки в техподдержку.

Две статьи на одну тему — намеренно. Пользовательская отвечает на вопрос «что мне сделать», внутренняя — на вопрос «как отличить и когда передавать». Попытка совместить даёт статью, в которой пользователю показывают внутренние проверки, а оператору не хватает границ полномочий.

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

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

Частые ошибки

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

Шаги без глаголов. «Настройки безопасности» — не шаг. «Откройте Настройки, выберите Безопасность» — шаг. Инструкция, состоящая из названий разделов, требует догадываться, что с ними делать.

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

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

Удаление устаревших статей. Ссылки на них остались в закрытых обращениях; при разборе повторного случая след обрывается. Убирайте из выдачи, сохраняя по ссылке.

База знаний без правила, кто заводит. Если заведение статей — общая обязанность, это ничья обязанность. Правило «решил в третий раз — напиши» привязывает его к конкретному человеку в конкретный день; в должностной инструкции это отдельный пункт с проверяемым результатом, см. Должностная инструкция специалиста технической поддержки.

Статьи, которых нет в поиске пользователя. Внутренняя база, куда пользователь не имеет доступа, снимает нагрузку только частично: половина обращений из тех, что люди решили бы сами. Разделение на два образца выше позволяет открыть пользовательскую половину, не раскрывая внутренних проверок; как устроен клиентский портал — см. Клиентский портал: обзор.

Связанные статьи

• Форма приёма заявки в техподдержку: образец полей
• Скрипт первого ответа техподдержки: готовые формулировки
• Памятка новичку первой линии: образец на первую неделю
• Клиентский портал: обзор