Классификация жалоб по звонкам: от эмоции к предмету проблемы

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

Жалобу классифицируют по предмету проблемы и запрошенному исправлению, отдельно от эмоциональной формы. Сообщённое клиентом не равно проверенному факту. Категория полезна, когда приводит к понятному действию и ответственному.

В двух недовольных звонках могут требоваться совершенно разные действия

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

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

Разберём условный сервис поставок. В нём могут возникнуть вопросы о составе, сроке, документах и общении. Мы будем отличать слова клиента от подтверждённых обстоятельств. Если человек сообщил, что товар пришёл повреждённым, запись должна сохранить это сообщение и необходимые уточнения. Она не должна незаметно превратить рассказ в уже завершённое расследование.

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

Сначала выделяем предмет, затем добавляем контекст

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

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

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

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

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

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

Строим небольшой словарь причин с ясными границами

Для учебного сервиса начнём с четырёх групп: состав поставки, движение заказа, документы и взаимодействие. Внутри первой можно различать вариант, количество и комплектность. Внутри второй — отсутствие понятного статуса и несоответствие сообщённого времени. Это рабочие категории примера, а не универсальная отраслевая норма. Их пригодность проверяется на материалах компании.

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

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

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

Словарь полезно версионировать. Когда категория разделяется на две, старые отчёты не становятся автоматически сопоставимыми с новыми. Для повторного анализа требуется понятное правило. Иначе руководитель увидит рост одного вида жалоб, который объясняется только изменением классификатора. Изменение количества не всегда означает изменение работы с клиентами.

Желаемое исправление важнее догадки о скрытой причине

Клиент может сообщить проблему, но не назвать, что хочет получить. Или назвать несколько вариантов: замену, уточнение, документ, связь со специалистом. Аналитика должна сохранить этот запрос отдельно от предлагаемого компанией решения. Фраза «надо заменить» может принадлежать менеджеру, а не клиенту; при передаче это различие имеет значение.

В учебной сцене человек говорит: «Мне важно закончить работу к выходным, размер не подходит». Менеджер предполагает возврат, но клиент спрашивает о доступном варианте замены. Если карточка содержит только «хочет возврат», следующий сотрудник начнёт разговор с неверной рамки. Хороший разбор показывает сообщённое ограничение и реально высказанное пожелание.

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

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

W3C Data Quality Vocabulary связывает качество с предполагаемым использованием данных. В нашем случае карточка пригодна, если помогает продолжить конкретное обращение. Полнота текста без сохранения статуса просьбы и обещания не решает эту задачу. Авторская схема выделяет эти поля именно из-за различия последующих действий.

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

Учебная карточка: от жалобы о размере к проверке поставки

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

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

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

{
  "subject": "Сообщённое несоответствие размера",
  "source": "Учебный разговор и отметка эпизода",
  "customer_statement": "Клиент сообщает о другом размере в упаковке",
  "category": {
    "main": "Состав поставки",
    "detail": "Вариант изделия",
    "dictionary_version": "Версия рабочего справочника"
  },
  "customer_request": "Уточнить возможность подходящей замены",
  "company_action": "Проверить состав заказа и отгрузки",
  "confirmed": ["Назван предмет обращения"],
  "unknown": ["Причина расхождения", "Возможность исправления"],
  "handoff": "Роль, уполномоченная проверить поставку",
  "completion": "Не считать разговор завершённым исправлением"
}

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

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

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

Разбираем три пограничных случая до запуска классификатора

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

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

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

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

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

Отчёт по категориям должен приводить к изменению работы

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

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

W3C Data on the Web Best Practices рассматривает понятность и описание данных. Для нашего отчёта это означает сохранять определения категорий, период и способ подсчёта. Документ не подтверждает причинную связь между графиком и качеством сервиса. Такая связь требует собственного разбора процесса и сопоставимых наблюдений.

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

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

Приёмка заканчивается понятной ответственностью за следующий шаг

Перед передачей карточки проверьте объект обращения, источник, предмет, статус сообщённых обстоятельств, просьбу клиента и обещанное действие компании. Отдельно — кто может выполнить следующий шаг. Если ответственный не определён, классификация может быть содержательно верной и при этом не помогать работе. Аналитика не должна оставлять человеку только красивое описание нерешённой проблемы.

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

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

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