Почему База Знаний бесполезна в технической поддержке?

Я 19 лет проработал в службе технической поддержки компании-разработчика ПО, начиная с должности младшего инженера и закончив в должности топ-менеджера. Вместе с компанией я прошел через серию слияний, поглощений и ребрендингов, будучи свидетелем, а иногда и инициатором значительных изменений в организации поддержки.
В течение всех этих лет мы много работали с инструментами поддержки, оптимизировали и автоматизировали процессы, повышали эффективность и т.д. Основываясь на этом опыте я могу рассказать, почему во многих службах поддержки, создание Базы Знаний это бесполезное занятие.

В далеком 2003 году наша молодая компания только начинала находить своих первых зарубежных клиентов, и с поддержкой традиционно никто не заморачивался, оказывая ее по email. Однако клиентская база росла и было принято решение перейти на хелпдеск. Тогда еще не было такой богатой россыпи хелпдеск решений (а про облачные и тем более отечественные решения вообще никто ничего не слышал), поэтому свой выбор мы остановили на дешевом (бесплатном) и сердитом opensource решении.

Сразу же после этого мы начали задумываться о написании FAQ'ов, чтобы адресовать самые популярные запросы. Однако первые проблемы начались уже на выборе этих "самых популярных запросов".

Казалось бы, что могло пойти не так?

Итак, наш «самый опытный инженер» начал писать статьи в базу знаний, которые он думал будут полезны. К сожалению, выбор темы для написания статьи не всегда (а чаще никогда) не отражал реальной потребности клиентов, и они продолжали заводить заявки вместо использования базы знаний.

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

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

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

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

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

Но почему же база знаний оказалась бесполезной?

Однако прежде чем пойти дальше, нужно понять, а что это же такое эффективность базы знаний? И в каких «попугаях» она измеряется?

Один из таких KPI это Volume Deflection или просто Deflection, или «упреждение заявок». Deflection показывает скольких заявок удалось избежать и соответственно сэкономить ресурсов в клиентской поддержке.

Его формула следующая:

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

Deflection= 14/ (14+ 86) = 14%

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

Но что если те же 100 клиентов имеют те же проблемы, но часть из них даже и не будет пытаться обратиться в техническую поддержку. Они пойдут в поисковую систему, введут запрос, найдут и применят статью. И все. Это будет косвенный или непрямой Deflection.

Но как же измерять то, чего не произошло? Вы правы. Измерить это нельзя, но существуют определенные алгоритмы, которые позволяют рассчитывать и экстраполировать такой Deflection.

Итак, какой же Deflection был у нас? И насколько наша база знаний была эффективной?

Я был бы рад ответить на этот вопрос, но тогда я знал о Deflection абсолютно ничего.

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

Мы решили копать дальше, и расследование выявило еще больше проблем:

• Нерелевантный и избыточный контент. Причина этому была, что наши выделенные «контент-писатели» создавали контент, который они думали был бы полезен клиентам. Однако они не всегда (а точнее почти никогда) не могли угадать точно в каком месте «выстрелит». Они пытались создать всеобъемлющие статьи, которые покроют все сценарии, однако на практике такие статьи становились избыточными, громоздкими и сложными к восприятию.
• Неактуальный и устаревающий контент. В дополнение к предыдущему пункту такие статьи требовали больших временных затрат на написание и их сложно было поддерживать в актуальном состоянии. Выходили новые версии продукта, менялись компоненты, а скорость обновления статей была очень низкой (а в основной массе статьи вообще не обновлялись).
• Потеря компетентности. Еще один аспект возник примерно через полгода работы с базой знаний. Наши «самые опытные инженеры» были оторваны от работы и поддержки продукта, и начали терять свои технические навыки, что также сказывалось на качестве контента.

Примерно в 2012 году мы натолкнулись на методологию Knowledge-Centered Service — KCS®, которая уже несколько лет широко использовалась в службах поддержки многих IT компаний.

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

Мы прочитали тонны документации, посетили конференции, вебинары и рвались в бой. Однако это все красиво выглядело в теории, при этом не давая практического ответа на вопрос "А как с этой всей фигней взлететь?" (с)

Из доступных решений на рынке были только плагины к Большой Голубой CRM системе, которые стоили как самолет (ну и конечно же требовали использование самой ЦРМ в качестве тикетницы).

И мы решили:

«Яжепрограммисты» — решили мы, и приступили к написанию своего инструмента.

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

Но наконец все было готово, интегрировано и мы запустили процесс создания контента согласно методологии.

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

1. Скорость создания нового контента повысилась в разы за счет того, что каждый инженер участвовал в его создании, и создавал черновик на каждую проблему.
2. При этом актуальность контента стремилась к 100% за счет публикации только востребованных кейсов, которые в свою очередь отслеживались через связку с тикетами, а значит то, что действительно важно и непонятно для клиентов.
3. Высокая релевантность поиска достигалась за счет использования клиентского языка в описании симптомов проблемы. Другие клиенты могли быстро находить и применять решения не обращаясь в службу поддержки.
4. Создание и обновление контента всеми инженерами, т. е. теми, кто постоянно при этом продолжал заниматься поддержкой продукта, поддерживало экспертизу, а значит и качество контента на нужном уровне.
5. И наконец мы начали измерять Deflection, что позволило точно оценивать эффективность работы Базы Знаний.

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