Техника 5.1: Структура статей KCS

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

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

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

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

Создание хорошего шаблона

Правильная структура гарантирует, что статьи KCS в базе знаний могут быть найдены и использованы целевой аудиторией. Определение целевой аудитории важно, поскольку аудитория определяет контекст статьи KCS. В идеале эта аудитория так же должна участвовать в создании статей и предоставлять отзывы на существующие статьи. К сожалению, не далеко не все организации действительно допускают клиентов до "работы" со статьями.

Одной из основных целей KCS является определение контекста проблемы: описание симптомов и точки зрения клиента в их собственных терминах.

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

• простые вопросы и ответы

• технические вопросы (как простые, так и сложные)

• техническая инструкция
• диагностические процедуры (как простые, так и сложные).

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

• Симптомы (иногда называю Проблема) — ситуация описанная словами клиента. Что они пытаются сделать или что не работает? То, что нам надо решить.
• Окружение — с какой функцией, процессом, продуктами, платформами, географическим положением, категориями или темами у заявителя возникла проблема? Как это настраивается? Изменилось ли что-нибудь в окружении за последнее время? Это позволяет нам найти правильное решение, когда проблемы могут быть очень похожими, но решение отличается в зависимости от окружения. Симптомы часто могут быть расплывчатыми, потому что они представляют собой восприятие клиентом того, что происходит. Данные окружения должны быть точными.
• Причина — основной источник проблемы.
• Решение — ответ на вопрос или шаги, необходимые для решения проблемы.
• Метаданные — атрибуты или информация о статье. Например, аудитория статьи, дата создания, количество повторных использований, история изменений и дата последнего изменения.

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

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

Поле Решения

Решение содержит ответ на вопрос, временное или постоянное решение проблемы.

Если решение содержит несколько шагов, то лучше всего представить их пронумерованным списком.

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

Сотрудники поддержки могут иметь доступ к скрытому полю в статье (которое пользователь не может видеть), в котором описаны действия по устранению проблемы. Это имеет смысл так же в случае, если нужно собрать дополнительную статистику по конкретной проблеме с известными симптомами, но нужно дополнительное исследование на стороне клиента. Добавление "внутреннего" поля в статью базы знаний предоставляет место для записи решения, которе мы не можем опубликовать для внешней аудитории, но используем для обучение или применения решения сотрудниками поддержки, которые имеют соответственный уровень доступа и навыки. Если же инструментарий не позволяет сделать такое разграничение, то можно использовать отдельную "внутреннюю" статью связанную с публичной.

Поле Причина

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

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

Еще одна полезная стратегия это добавление дополнительного поля, связанного с полем «Причина», которое называется «Проверка причины». В поле «Проверка причины» будет указана процедура или описание того, как проверить причину. Затем клиент или сотрудник поддержки может использовать этот тест, чтобы подтвердить причину. Например, причина "нет бумаги" может включать проверку причины, описывающую, как проверить уровень бумаги в принтере.

Мультимедийный контент

До этого мы в основном говорили о статьях KCS, представленных в виде текста. Однако для определенных аудиторий и определенных типов знаний мультимедийный контент (видео, аудио, снимки экрана, диаграммы и т.д.) оказывается гораздо более эффективным, чем текст. Визуальные образы могут заполнить языковые пробелы или решить проблемы перевода. Если же мы говорим о программном обеспечении, то использование снимков экрана практически обязательно, т.к. помогает клиентам гораздо быстрее и доступнее объяснить решение. Попытайтесь всегда понять кто ваша аудитория и поставить себя на место клиента. В каком виде информация для них будет более доступна?