Что такое Knowledge-Centered Service?

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

- А почему вы так считаете? — спрашивал я.

- Ну как же! У нас специальная команда технических писателей, инженеров поддержки, контент менедджеров (нужное подчеркнуть), которые только и делают, что пишут прекрасные статьи.

- Ну а как-то вы оцениваете, что эти статьи действительно прекрасные?

- Нет. А зачем?

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

По своему опыту я могу выделить следующие признаки, которые (все вместе или как минимум несколько из них) характерны для таких компаний:

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

И вот только когда какой-то из этих факторов начинает “сбоить”, то тогда руководитель начинает задумываться насчет эффективности (Но это не точно : )) . Если, например, усложнился продукт и стало требоваться больше людей для его поддержки, то он просто идет к вышестоящему руководству и просит дополнительный штат/бюджет. А когда бывает этот бюджет не дают, то просто разводит руками — “ну мол, не моя вина в том, что теперь у нас поддержка плохая”.

Однако те, кто задумываются над вопросом эффективности управления знаниями в службах поддержки, возможно сталкивались с методологией Knowledge-Centered Service — KCS. И здесь у них возникает следующий вопрос:

Knowledge-Centered Service (KCS®, по-другому еще Knowledge-Centered Support и Knowledge-Centric Support) это методология управления знаниями в службах клиентской поддержки, которая создает знания как «побочный» продукт решения клиентских проблем. KCS предлагает новый алгоритм работы для сотрудников службы поддержки, который собирает и объединяет их разрозненные знания в единое пространство, доступное как для всей компании, так и для ваших клиентов. В отличие от традиционного подхода к управлению знаниями, где выделенные технические писатели создают контент базы знаний, практики KCS включают всех сотрудников службы поддержки, которые решают клиентские заявки, в процесс создания и обновления контента.

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

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

И это правда!

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

В процесс публикации же вовлечены только сотрудники с правами на публикацию.

Без использования KCS технические писатели или контент-менеджеры создают контент «на всякий случай», который они думают должен приносить пользу клиентам.

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

С использованием KCS знания документируются сразу же, как только в этом видна потребность — клиент завел заявку с проблемой, на которую еще нет существующей статьи.

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

Следующий каверзный вопрос:

- Но мы же тогда можем создать кучу ненужного контента! Зачем тратить на это время?

Действительно на практике в публикацию уходит только 20% всего создаваемого контента. Однако не забывайте, что затраты на его создание — минимальны: по умолчанию создаются черновики, состоящие из описания проблемы словами клиента и ответа поддержки в заявке.

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

Т. е. ресурсы затрачиваются только на 20% контента, НО контента, который реально востребован клиентами!

Учитывая, что наша цель в том, чтобы все сотрудники службы поддержки делились своими знаниями друг с другом, мы должны соотнести их личные показатели эффективности (KPI) и систему мотивации с этой целью.

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

Очень часто эффективность работы контент-менеджеров измеряется количеством и набором их действий. Например: количество созданных или отредактированных статей, время за которое создается контент и т.д.

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

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

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

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

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

В конце концов наличие классификатора не избавляет от необходимости вычитывать относящиеся к нему тикеты.

При использовании методологии вы получаете:

Улучшение операционных показателей

Оптимизация ресурсов

Сокращение расходов