Техника 1.3: Поиск — это создание

Создание релевантного контента

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

Ниже приведены некоторые рекомендации по наполнению контента статей для максимизации их релевантности:

Слова и фразы, которые клиент использует для описания проблемы (даже если они технически неточны).
Описание окружения (операционная система, версия установленного ПО и т.д), относящееся к проблеме или уникальное для нее
Информация, которая отличает эту статью от других статей с похожими симптомами, но другим решением (отличительные характеристики чаще всего бывают в описании окружения)
Диагностический процесс, используемый для решения проблемы (подробности или способы выполнения сложных многоразовых диагностических процессов часто сами являются статьями, и на них можно и нужно ссылаться)
Решение, которое полностью решает проблему, описанную клиентом

Сбор и уточнение информации в статье по мере того, как мы работаем над проблемой, имеет решающее значение. Мы начинаем с того, что пытаемся понять проблему. По мере того, как мы решаем проблему, начальная информация может оказаться неточной или неполной. Обычно это относится к окружению (Платформе, операционной системе, версии ПО и т.д.) . Перед изменением состояния статьи с Work in Progress (WIP) на Draft мы должны быстро проверить актуальность контента.

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

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

См. Приложение E в качестве краткого руководства по содержанию и структуре статей базы знаний.

Поисковые слова являются инструментом для создания новых знаний

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

Эта статья создается в статусе Work In Progress (WIP) и сохраняется в базе знаний, даже если у нас еще нет решения. Мы можем продолжить работу над проблемой или передать ее другим специалистам для решения (этот процесс зависит от роли и опыта сотрудника поддержки). Наличие статьи WIP в базе знаний позволяет другим узнать, что такая проблема уже возникало. Когда решение найдено, мы добавляем его в WIP статью и переводим ее в статус черновика Draft. . В случае, если есть другие открытые заявки, связанные с этой статьей (пока она была в статусе WIP), их можно быстро решить и закрыть.

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