Управление знаниями
Хелпдеск
Поддержка
Тарифы
Бизнесу
Управление знаниями
Конструктор отчетов
Управление персоналом
Корпоративный поиск
AI
Хелпдеск
Поддержка
Тарифы
Бизнесу
Управление знаниями
Конструктор отчетов
Управление персоналом
Корпоративный поиск
AI
Хелпдеск

Создание больших статей-хабов

Добро или Зло?

Некоторые компании, при внедрении методологии KCS, задаются следующим вопросом: У нас 100500 статей на одну тематику одной проблемы. Можно ли собрать всё в кучу и сделать одну большую статью-хаб?

Точка зрения методологии KCS

Это попытка создать классическую документацию.

С точки зрения KCS это неправильно. В частности это противоречит пунктам 5,6,7 основных принципов KCS.

В KCS каждая статья должна описывать один конкретный кейс, чтобы если пришел клиент с вопросом "У меня не работает XYZ", то статья описывала конкретно этот кейс, и еще и словами клиента.

Потому как, если сделать статью-хаб с кучей разных ссылок, и такие статьи в последствии давать клиентам на массу их различных кейсов, то клиент просто утонет в потоке информации - не решит свою проблему и, как правило, будет недоволен - заполнит DSAT 😞.

Customer Experience анализ

Второй важный аспект в кейсовости статьи - сбор статистики для понимания Customer eXperience (в Swarmica это раздел Улучшение продукта) - когда мы можем смотреть топ статей по количеству привязанных заявок, и определять «что болит» в продукте с целью починить первопричину и улучшить продуктовый опыт клиентов.

За счет этого избавиться от ненужной нагрузки в поддержке и, что самое главное - повысить лояльность клиентов. 😀

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

И здесь возникает вопрос: Но агенты создают кучу дубликатов или просто похожих статей. Что же делать с ними?

Ответ: Для этого должен быть правильно настроен процесс QA . В частности Контроль Точности Связанности как раз отвечает за это направление. Выборки событий связи тикетов и статей должны проверяться на регулярной основе, и там как раз оценивается критерий Дубликата и Релевантности, привязанной статьи.

Этот процесс обязательно должен работать в комбинации с добавлением KPI по Точности Связанности в мотивационную схему агентов, т.к. это ключевой параметр, который оценивает их работу со знаниями.

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