Клиент пишет снова: ищем причины с ИИ

Поддержка отправила решение и закрыла диалог. На следующий день клиент пишет: «Всё ещё не работает». Возможно, в ответе ему указали кнопку, которой нет в его интерфейсе. Или временное решение помогло ненадолго. Бывает и другая причина: после обрыва связи система получила копию прежнего сообщения. Разберитесь, что произошло между первым ответом и следующим обращением, прежде чем считать его повтором.

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

Решение не сработало у клиента

В примере А клиент пытается выгрузить отчёт из рабочего кабинета. После ответа оператора заявку Т-101 пометили решённой. На следующий день пришла новая заявка Т-118.

День 1, клиент: «Отчёт не выгружается, кнопка недоступна». Поддержка: «Откройте настройки и включите экспорт». День 2, клиент: «Пишу по вчерашнему отчёту. У меня нет такого переключателя, кнопка по-прежнему недоступна».

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

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

Клиент не знает, когда ждать ответ

В примере Б клиент ждёт возврата денег по заказу О-7. Поддержка передаёт вопрос коллегам, но не говорит, когда вернётся с ответом.

День 1, клиент: «Возврат по заказу О-7 ещё не пришёл». Поддержка: «Передали запрос коллегам». День 3, клиент: «По О-7 ничего не изменилось. Кто занимается возвратом и когда ждать ответ?»

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

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

Например, после регистрации запроса и согласования времени ответа можно написать так:

«Запрос по О-7 зарегистрирован и передан ответственному за возвраты. Завтра до 15:00 по Москве сообщим, что выяснили или какого ответа ещё ждём. Когда поступят деньги, пока неизвестно. Описывать заказ заново не нужно: продолжим здесь».

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

Что легко принять за повтор

Ответ на просьбу прислать сведения

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

Поддержка: «Для проверки пришлите версию приложения и время ошибки». Клиент: «Версия 2.1, ошибка сегодня в 18:20».

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

Обрыв связи и повторная доставка

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

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

Передача специалисту

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

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

Новая проблема в старом диалоге

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

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

Одна проблема может занять несколько заявок

Считайте каждую отдельную проблему клиента: например, К-12 не может получить отчёт Р-4. Он может написать об этом в чат и по почте, открыть новую заявку или дождаться передачи специалисту. Соберите эти сообщения в одну историю и сохраните их номера и время. Для разбора не обязательно объединять сами заявки в системе.

В Zendesk ответ на заявку со статусом Solved («Решено») может открыть её снова. Ответ на Closed («Закрыто») создаёт новую связанную заявку, follow-up. В Intercom переписка и заявка могут иметь разные статусы. Поэтому выясните, что означает поле статуса в вашей выгрузке, и прочитайте сообщения, прежде чем делать вывод.

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

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

Подготовьте переписку без личных данных

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

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

В Claude Opus в MashaGPT можно сравнить разрешённые к отправке переписки без личных данных. Попросите модель объяснить каждое решение цитатой из сообщения. Начните с нескольких историй, которые сможете прочитать целиком: общая тема ещё не означает одну проблему, а пропущенный ответ может изменить вывод.

Почему клиент написал ещё раз

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

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

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

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

Как посчитать долю повторных обращений

Выберите, за какое время после ответа будете искать повторы. В примере ниже это семь суток; для вашей команды срок может быть другим. Начинайте отсчёт с первого ответа, в котором поддержка предложила шаг, решение или объяснила, чего ждать. Автоматическое «мы получили запрос» таким ответом не считается.

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

Допустим, первые ответы отправили с 1 по 3 октября, а переписки проверяют в конце 10 октября. Для каждой проблемы прошло семь суток. Если ответ отправили вечером 3 октября, повтор ровно через семь суток, вечером 10 октября, тоже учитывают. Проблемы с первым ответом 8 октября пока не добавляйте: по ним ещё нельзя посмотреть весь выбранный срок. Считайте время в одном часовом поясе.

Допустим, разобрали 80 проблем. По 14 из них клиент вернулся в течение семи суток: 14 / 80 × 100% = 17,5%. Даже если в этих историях было 18 повторных сообщений, в расчёте остаются 14 проблем. Ещё шесть историй требуют проверки. Так и сообщите команде: «14 из 80; ещё 6 пока не разобраны». Остальные проблемы нельзя автоматически назвать решёнными.

Если все шесть спорных историй окажутся повторами, получится 25%: (14 + 6) / 80 × 100%. Это расчёт на условии «если», а не прогноз. Он ничего не говорит о сообщениях, которых нет в ваших данных. Проверьте, не пропущен ли канал и правильно ли связаны обращения одного клиента.

Готовый Recontact rate в Intercom устроен иначе: среди новых диалогов за выбранный период он считает те, которые тот же клиент начал в течение заданного срока после решения предыдущего вопроса. Показатель по общей AI-подтеме зависит ещё и от того, каким диалогам ИИ назначил тему. Например, «платежи» могут объединять вопросы о разных заказах. Эти цифры нельзя напрямую сравнивать с долей повторов по одной проверенной проблеме.

Исправьте одну найденную проблему

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

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

Начните с одной истории: что человеку предложили, что случилось после ответа и зачем он написал снова. Запишите причину и то, что ещё нужно проверить. Когда сотрудники одинаково понимают такие истории, можно подсчитать повторы и выбрать, что изменить. ИИ поможет сравнить сообщения; выводы подтвердите по переписке и действиям поддержки.