Как размечать диалоги с клиентами без вреда для отчетов

В 10:12 сотрудник помечает диалог словами «оплата», «возврат», «срочно» и «сердитый клиент». В 10:18 другой сотрудник решает такую же проблему, но выбирает только метку «проблема с платежом». Обе ситуации решены правильно. В конце месяца отчет показывает, что запросов на возврат стало меньше, а проблем с платежами больше.

Работа не изменилась. Изменился словарь внутри данных.

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

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

Метка должна отвечать на повторяемый вопрос

До создания метки запишите вопрос, на который она ответит. Вопрос «Какие диалоги были связаны с ошибкой в адресе доставки?» полезен, потому что команда сможет найти причины и изменить форму или процесс. Вопрос «Какие диалоги были сложными?» пока бесполезен: сотрудники поймут сложность по-разному, а решение не определено.

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

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

Разделяйте факты состояния итоги и метки

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

Долговременные факты о клиенте описывают человека или аккаунт за пределами одного диалога. Язык, рынок, тариф, состояние согласия, сегмент и источник привлечения обычно принадлежат полям клиента. Факт может меняться, но у него должно быть одно текущее авторитетное значение, а не несколько противоречащих тегов.

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

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

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

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

Опишите малый словарь до создания правил

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

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

Формат имеет значение. Документация Zendesk говорит, что теги добавляют контекст и применяются в представлениях, поиске и бизнес-правилах. Она также предупреждает, что подчеркивание, дефис и косая черта создают разные теги. Выберите один разделитель, единое правило числа и один язык системных идентификаторов.

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

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

Управляйте созданием и изменением меток

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

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

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

Проверяйте метки на реальных диалогах

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

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

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

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

Очищайте классификацию без переписывания истории

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

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

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

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

Используйте метки как доказательство

Полезный отчет показывает определение и знаменатель рядом с числом. Вместо фразы «тегов возврата стало больше» уточните, означает ли тег просьбу, одобрение или завершенный возврат, а знаменатель — диалоги, клиентов, заказы или решенные случаи. Сравнивайте только периоды с совместимыми определениями.

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

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

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

Частые вопросы о разметке диалогов

Нужен ли тег каждому диалогу

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

Может ли автоматизация ставить теги

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

Как часто пересматривать теги

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