Число тикетов в поддержку растёт вместе с числом пользователей, и центр помощи нужен, чтобы тикеты росли медленнее. Хороший центр помощи снимает повторяющуюся половину обращений и заодно приводит поисковый трафик по низкочастотным запросам. Плохой превращается в кладбище устаревших статей, которые никто не может найти. Здесь — о структуре, о поиске и о слое ИИ, который становится всё важнее.
Начинайте с тикетов, а не с функций
Соблазнительно пройтись по списку функций и описать каждый экран. Полезнее открыть почту поддержки и посчитать. Первые двадцать статей — это двадцать вопросов, на которые ваша команда отвечает чаще всего: именно такие тикеты центр помощи и способен снять.
Отсюда же и стиль: статья — это ответ, а не глава руководства. Одна задача на статью, ответ в первом абзаце, шаги ниже. Пользователь приходит из строки поиска с проблемой и не читает от начала до конца.
Структура: категории, статьи и заголовки, которые совпадают с запросами
Держите иерархию в два уровня: категории и статьи в них. Глубокие деревья выглядят упорядоченно, а работают ужасно, потому что каждый лишний уровень — это выбор, в котором пользователь не должен ошибиться.
Названия категорий отражают то, что нужно пользователю («Оплата», «Начало работы», «Интеграции»), а не вашу оргструктуру или внутренние названия модулей. Заголовок статьи — это вопрос в том виде, в каком его набрал бы пользователь: «Как сбросить пароль?» лучше, чем «Управление паролями».
Дайте каждой статье постоянный слаг, а каждой категории — свою страницу. Не жалейте перекрёстных ссылок: статья о счетах должна ссылаться на статью о способах оплаты.
Поиск — это и есть продукт
Большинство визитов в центр помощи начинается со строки поиска, и здесь классический поиск по ключевым словам подводит пользователей. Типичный случай: пользователь вводит «с карты сняли деньги два раза», а статья называется «Повторное списание». Общих слов нет, результата нет, ещё один тикет.
Семантический поиск решает это: он сравнивает смысл, а не слова. Статьи превращаются в векторы, запрос тоже, и результаты ранжируются по близости. Когда выбираете платформу для центра помощи, проверьте именно эту функцию на своих самых неудачных формулировках. Модуль помощи в Kookee ищет по смыслу среди опубликованных статей и к каждому результату возвращает совпавший фрагмент, так что интерфейс может показать, почему статья подошла, а не только её заголовок.
Если вы делаете свой фронтенд, подключите поиск прямо к полю ввода с debounce: результаты по мере набора измеримо выигрывают у кнопки отправки.
Слой ИИ: от результатов поиска к ответам
Следующий шаг после поиска — сразу отвечать на вопрос. Это генерация с дополненной выборкой (RAG): система находит нужные статьи и составляет по ним ответ со ссылками на источники. Полезную реализацию от источника проблем отличают два свойства:
Ответ ссылается на источники. Пользователь видит, из каких статей взят ответ, и может перейти к ним. ИИ-ответы без источников в поддержке подрывают доверие в первый же раз, когда ответ окажется неверным.
Корпус — ваша документация, а не весь интернет. Модель отвечает по вашим опубликованным статьям, а в остальных случаях говорит «не знаю».
На практике это чат-виджет в центре помощи или в приложении. В Kookee всю работу делает тот же контент-бэкенд: в SDK есть help.chat и потоковый help.chatStream (с событием sources), которые отвечают по уже опубликованным статьям, так что синхронизировать документацию с отдельным ИИ-продуктом не нужно. Есть и связанный приём: статьи с видимостью «Только чатбот», которые ИИ берёт как контекст, но которых нет в публичном центре помощи. Они скрыты из списков, но не засекречены: ассистент может процитировать их кому угодно.
Свой домен и своя отрисовка
Центр помощи на поддомене поставщика отдаёт SEO поставщику. По низкочастотным запросам о помощи («вашпродукт экспорт csv») поиск должен приводить на ваш домен, по адресу yourapp.com/help.
Архитектура та же, что у блога на API: статьи пишут в панели управления, получают в виде JSON, а ваш фронтенд отрисовывает их на сервере. Маршрутов немного: главная страница справки со списком категорий, страница категории со списком статей, страница статьи и страница поиска. С React-хуками (useHelpCategories, useHelpArticles, useHelpSearch) каждый из них — это компонент и один запрос, а готовые серверные компоненты закрывают все четыре страницы, включая поиск по мере набора. Подробнее — в статье Центр помощи на React-компонентах.
Если запуститься нужно раньше, чем появится фронтенд, готовый портал покажет тот же контент по публичному адресу с первого дня. Когда дойдут руки, вы замените его своими страницами.
Как не дать справке устареть: владельцы и обратная связь
Справка устаревает незаметно: после редизайна экрана настроек десяток скриншотов уже неверны, и никто этого не замечает, пока не пожалуются пользователи. Помогают три привычки:
Назначьте владельца каждой категории. «Документация общая» значит, что она ничья.
Обновляйте справку в каждом релизе. Функция готова, когда готова её статья, так же как её запись в журнале изменений.
Следите за сигналами. Поиски без результатов — это бэклог контента, который за вас написали пользователи. Реакции и комментарии к статьям показывают, какие из них не помогают читателям. Ответы поддержки, которые раз за разом объясняют одно и то же, — это статья, которой не хватает.
Честно считайте снятые обращения
Центр помощи оправдывает себя снятыми тикетами, и честная косвенная цепочка такая: поиск → просмотр статьи → этот пользователь не пишет в поддержку в течение дня-двух. Точно связать одно с другим невозможно, важно направление. Если просмотров статей больше, а тикетов на пользователя меньше, всё работает. Если у вас есть чат-виджет, следите ещё за соотношением ответов ИИ и передач человеку: когда передач становится больше, обычно не хватает контента, а с моделью всё в порядке.
В каком порядке строить
Напишите 20 статей по самым частым тикетам и разложите их по категориям в два уровня.
Запустите маршруты
/helpна своём домене с серверной отрисовкой или начните с готового портала.Подключите семантический поиск к строке поиска.
Добавьте ИИ-чат, когда статей станет достаточно, чтобы он мог на них опираться.
Раз в месяц просматривайте поиски без результатов и дописывайте недостающее.
Центр помощи никогда не бывает готов, но окупается рано: каждая статья, которая ответила на вопрос сто раз, — это сотрудник поддержки, которого вам не пришлось нанимать.