Настройка версий статей для разных клиентов
Когда в вашей базе знаний накопилось больше сотни статей, а клиенты — от малого бизнеса до enterprise с разными продуктами, возникает знакомая проблема: как сделать так, чтобы каждый видел только релевантную информацию? Показывать всем всё — значит заставлять пользователя пробиваться через шум. Прятать статьи вручную — гарантированно ошибаться. Решение — версионирование контента.
Зачем разделять статьи по клиентам
Представьте: вы поддерживаете три тарифа. У всех разный функционал, разные типичные ошибки, разные скрипты решения. Если оператору базового тарифа показывать инструкцию для премиум-функций, он либо запутается, либо начнет обещать то, чего нет. Если enterprise-клиенту не показывать статью «Как настроить индивидуальный SLA» — время решения заявки растет, клиент нервничает.
Версионирование решает три задачи:
- Релевантность — оператор видит только те статьи, которые применимы к продукту клиента
- Скорость — не нужно листать 50 статей, чтобы найти нужную среди 5
- Безопасность — внутренние инструкции или конфиденциальные данные не уходят не тем клиентам
Как устроено версионирование в связке Telegram-CRM и базы знаний
Технически это выглядит как привязка метаданных к статье. У каждой статьи появляется поле «версия» или «тег клиента». Когда оператор открывает базу знаний внутри тикет-системы, CRM подтягивает данные о клиенте и фильтрует статьи.
Вот базовая схема:
| Компонент | Что делает | Как связано с версиями |
|---|---|---|
| Профиль клиента в CRM | Хранит тег тарифа, продукта, сегмента | Определяет, какую версию показывать |
| Статья в базе знаний | Содержит тело текста + метаданные | Помечена тегом версии |
| Фильтр интеграции | Сопоставляет тег клиента с тегом статьи | Отсеивает неподходящие версии |
| Интерфейс оператора | Отображает только отфильтрованные статьи | Оператор видит только релевантное |
Пошаговая настройка
Шаг 1. Определите критерии разделения
Не плодите версии без необходимости. Обычно хватает 2–5 вариантов. Типичные критерии:
- Тарифный план (базовый / расширенный / премиум)
- Тип продукта (если у вас несколько линеек)
- География (разные регуляторные требования)
- Уровень доступа оператора (junior / senior / супервизор)
| Версия | Для каких клиентов | Какие статьи включает |
|---|---|---|
| basic | Тариф «Старт» | Только базовые функции, без интеграций |
| pro | Тариф «Бизнес» | Всё из basic + интеграции, API |
| enterprise | Индивидуальные контракты | Всё из pro + кастомные настройки, SLA |
Шаг 2. Разметьте существующие статьи
Теперь нужно пройтись по всем статьям и присвоить каждой версию. Если статья универсальна — ставьте тег «all». Если специфична — конкретную версию.
Удобно делать это через массовое редактирование в админ-панели базы знаний. Если такой возможности нет — через CSV-импорт с полем version.
Важно: одна и та же статья может относиться к нескольким версиям. Например, «Как сменить пароль» — для всех. А «Настройка webhook-интеграции» — только для pro и enterprise.
Шаг 3. Настройте сопоставление в CRM
В вашем Telegram-CRM должна быть возможность привязать к тикету или клиенту метку версии. Обычно это делается через:
- Кастомное поле в карточке контрагента (например, `knowledge_base_version`)
- Тег, который автоматически проставляется при создании тикета (если клиент определяется по номеру договора или домену)
- Правило-триггер: «Если тариф = X, то присвоить версию Y»
Шаг 4. Интегрируйте фильтр в поиск статей
Когда оператор открывает базу знаний внутри тикет-системы, запрос должен содержать не только текст поиска, но и идентификатор версии. CRM передает его в базу знаний, а та возвращает только отфильтрованные статьи.
Проверьте, поддерживает ли ваша база знаний параметр `?version=` в API. Если нет — придется делать фильтрацию на стороне CRM, загружая все статьи и отсекая лишние. Это менее производительно, но работает.
Подробнее о том, как устроен поиск статей по SLA в тикет-системе, читайте в статье «Поиск статей базы знаний по SLA в тикетной системе».
Шаг 5. Проверьте на реальных кейсах
Создайте тестовые тикеты от клиентов разных версий. Откройте базу знаний. Проверьте:
- Клиент basic видит только свои статьи?
- Клиент enterprise видит и свои, и общие?
- Оператор видит только те статьи, которые разрешены его уровню доступа?
Типичные ошибки и как их избежать
Ошибка 1: слишком много версий. Если у вас 20 тарифов, не нужно 20 версий. Клиенты с похожим функционалом объединяйте в одну группу. Иначе вы создадите ад для авторов контента — каждую правку придется вносить в 20 мест.
Ошибка 2: забыли про общие статьи. Статьи типа «Как восстановить пароль» или «Контакты поддержки» должны быть видны всем. Сделайте для них тег «all» и убедитесь, что фильтр его не отсекает.
Ошибка 3: не обновляете версии при изменении тарифа. Клиент перешел с basic на pro — его версия должна измениться автоматически. Если этого не происходит, оператор будет видеть старые статьи, а клиент — злиться.
Когда версионирование не нужно
Иногда проще сделать одну базу знаний с хорошим поиском и тегами, чем плодить версии. Версионирование оправдано, когда:
- У вас больше 50 статей
- Разные клиенты используют принципиально разный функционал
- Есть конфиденциальные инструкции, которые нельзя показывать всем
Чек-лист: готовность к запуску версий
- Определены критерии разделения (тариф, продукт, география)
- Создана карта версий (таблица «версия — клиенты — статьи»)
- Все статьи размечены тегами версий
- В CRM настроено поле «версия базы знаний» для клиента
- Настроена интеграция: CRM передает версию в базу знаний
- Проверено, что общие статьи (тег «all») не отфильтровываются
- Проведено тестирование на 3+ реальных кейсах
- Операторы обучены: знают, что видят только релевантные статьи
- Настроено автообновление версии при смене тарифа клиента