6 причин, почему база знаний должна быть гибкой

Мы разрабатываем платформу, с помощью которой реализуется омниканальное обслуживание клиентов. Один из модулей платформы – База знаний InKnowledge - ядро информации для внутреннего использования и для обслуживания клиентов.

База знаний оказалась востребованной на рынке как самостоятельное ПО, поэтому мы вывели ее в отдельное решение и сосредоточились на функционале. Главной задачей стало сделать ее гибкой. Почему?

Рассмотрим пример пользовательского опыта.

Для того, чтобы база знаний приносила пользу, нужно упорядочить всю накопленную информацию и разложить ее “по полочкам”.

Если компания достаточно крупная: много функциональных подразделений, пара офисов в разных регионах и партнерская сеть, то информации за короткое время накопится в переизбытке. Тогда базу знаний очень легко превратить в помойку - пользоваться ей будет невозможно, да и деньги на ветер.

Поэтому здесь стоит подумать над классификацией и разделении знаний.

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

Для этого мы создаем страницы - разделы базы знаний.

Во-вторых, контент для внешних участников может быть обособлен от нашей базы знаний. Это делается для того, чтобы пользователи получали доступ к определенному сегменту знаний и не блуждали по всему контенту. Например, для партнеров мы создаем отдельный сайт - набор страниц со своими разделами.

Наконец, структурируем сами разделы знаний и каждую единицу контента.Главное здесь - создать дерево категорий, с помощью которого весь контент на странице будет привязан к какой-либо тематике и будет легко найден. Дерево категорий может выглядеть так:

Каждая статья привязывается к одной или к нескольким категориям. Это помогает более четко обозначить цель статьи. Например, статья, привязанная к категориям: Продукт А, Сеть доставки, Рассмотрение жалоб будет иметь понятную цель - что делать, если клиент пожаловался на доставку при заказе продукта А.

С таким подходом весь контент раскладывается на свои места. А еще это помогает быстро его находить.

В колл-центр обращается клиент : “хочу пожаловаться на доставку. Заказывал у вас “Продукт А”, привезли битый товар. Что делать?”

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

Поэтому смотрим в категории и быстро выбираем все, что относится к его запросу: Сеть доставки, Рассмотрение жалоб, Продукт А . База знаний отфильтрует нам статью, которая будет соответствовать всем выбранным категориям. Находим ответ:

Кроме поиска по категориям мы можем написать запрос в обычную строку поиска, выбрать подходящий тег или задать более четкие условия через расширенный поиск:

Все эти варианты приведут нас к нужному результату .

Чем больше контента, тем больше условий требуется задать, чтобы найти самый подходящий результат. в противном случае можно столкнуться с десятком статей, которые в какой-то степени подходят под запрос. Тогда задействуем сразу все варианты поиска и тратим на это минимум времени. Сначала выбираем категорию контента, потом смотрим на теги, которые есть в данной категории, выбираем нужный. В выдаче уже сформировано несколько результатов. Добавляем в поисковую строку ключевое слово, которое должно быть в названии или содержании и получаем искомую статью.

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

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

Сформировать ролевую модель и разделить права доступа нужно для того, чтобы пользователи не получали информацию в переизбытке или наоборот, в недостатке. А также, чтобы четко разграничивать доступные функции.Например, когда я работала с системой, которая имела довольно скудное разграничение прав, мне приходилось назначать некоторым пользователям роль администратора, чтобы они могли выполнять свою работу. И еще отдельно писать инструкции, на какие кнопки ни в коем случае нельзя нажимать, чтобы сотрудники других подразделений видели открытые задачи, требующие их участия.

Здесь, чтобы пользователи получили доступ к информации своей организации, мы присваиваем им роль “участник сайта”. Так сотрудник будет видеть контент только для партнерской сети, если он является партнером или для колл-центра, если он, например, работает оператором.

Внутри каждой организации всем тоже нужно задать роли. Можно объединить сотрудников и задать роль на группу или назначить роль каждому сотруднику отдельно.

Например, у нас есть операторы трех линий поддержки. Операторы каждой линии объединены в группу с ролью “пользователь”, чтобы иметь возможность открывать и смотреть контент по вопросам своей линии.

Сами роли определяют, сколько у сотрудника будет прав: у редактора - писать и редактировать статьи, у пользователя - только просматривать. Изменяем эти правила мы путем проставления галочек:

Все просто и интуитивно понятно.

Когда мы пишем новую статью, то сразу можем определить,кому ее показывать и какие права на нее нужно раздать.

Допустим, у нас есть контент, который читают и сотрудники, и посетители сайта.

Чтобы предоставить доступ к информации и тем и другим, мы, логично, разместим ее в двух местах: в базе знаний и на сайте. Получается дублирование одного и того же контента - нецелесообразный подход.

Проблема решается назначением прав доступа. Статья в базе знаний всегда хранится в единственном экземпляре, а увидеть ее могут только те, для кого мы указали право на просмотр:

Гость = неавторизованный пользователь, то есть обычный посетитель сайта или мобильного приложения.

Если у гостя для статьи появится право просмотра, значит ее увидят все, кто зашел на сайт.

Когда это единственный канал взаимодействия с клиентом - поддерживать информацию в актуальном состоянии не сложно. А если у нас целый набор каналов: портал самообслуживания, мобильное приложение, портал специалиста контакт-центра, учебный центр для новых сотрудников, чат-бот, робот, IVR, техподдержка?

Чтобы контент оставался актуальным, нужно контролировать, где пора обновить статью или заменить ее часть. А еще это нужно делать быстро, чтобы не вводить клиента в заблуждение, давая ему устаревшую информацию и оправдываться, что мы просто не успели везде поправить.

Поэтому у нас оригинал статьи всегда хранится в одном месте - в ядре базы знаний. Во всех остальных местах он лишь отображается. Делается это с помощью публикаторов: это виджеты, которые показывают только тот контент, который настроен на отображение. Публикатор можно настроить индивидуально. Например, на сайте он показывает только статьи из категорий “часто задаваемые вопросы”, в базе знаний сервисной службы из категорий по ремонту и обслуживанию продуктов и часто задаваемые вопросы про сервис. поэтому, когда редактор решит изменить ответ на вопрос: “сколько дней требуется на ремонт?”, он автоматически обновится во всех каналах. Тогда у нас не возникнет неприятностей, если клиент прочитает про 3-5 дней ремонта, а потом выяснит, что по новым правилам ждать придется 7 дней.

Можно ли быть уверенным в том, что все статьи, которые размещены в базе знаний, приносят пользу?

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

самый простой способ следить за пользой контента, это не просто считать количество открытий, а еще взаимодействовать с теми, кто ее читал.

Чтобы сообщить редактору о том, что касается его статьи, сразу пишем в форму “написать редактору” свое примечание или вопрос. Так он сразу увидит, что и в какой статье нужно поправить. А для того, чтобы посмотреть, было ли что-то исправлено, нажимаем на “подписаться на изменения” и получаем уведомления по данной статье.

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

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

Вот мы выстроили структуру, раздали всем роли - наступает время очередных перемен: новый подход к формированию партнерской сети, реструктуризация компании. Что делать? вызывать аналитиков, программистов, чтобы переписали все под новые процессы?

Нет, большинство задач можно решить самостоятельно. даже перестроить рабочие места пользователей системы, потому что сами окна тоже созданы из портлетов, которые выносятся drag'n'drop:

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

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