Реальный случай: клиент ждёт банковскую карту
В Nubank одним из массовых поводов обращения был вопрос о доставке карты. Клиент мог ждать первую карту или замену потерянной, повреждённой либо просроченной. Прежний помощник находил информацию в базе знаний и передавал разговор сотруднику. Выполнять действия по этому вопросу он не умел.
Команда выстроила последовательность работы: получить сведения о доставке, сопоставить статус с ожидаемым сроком, уточнить обстоятельства получения. Например, доступ в подъезд или возможность передачи консьержу. Если проблему решить не удавалось, помощник мог инициировать перевыпуск карты.
Для этого ему подключили данные клиента и отслеживание доставки. Добавили передачу разговора человеку при недовольстве клиента, проверки действий и краткости ответов. Ошибки в тестовых диалогах становились основанием для доработки. Новые варианты сначала получали 1% потока, затем долю увеличивали.
Что получилось
В A/B-сравнении с прежними вариантами команда сообщила о двух изменениях:
Показатель | Результат |
|---|---|
tNPS, индекс оценки обслуживания после обращения | Рост на 37 процентных пунктов |
SSR, доля вопросов, решённых без передачи сотруднику | Рост на 29 процентных пунктов |
При этом tNPS оставался на 10 процентных пунктов ниже результата опытных сотрудников. Исследование выполнено командой компании. Оно оценивает совокупность изменений; приписывать весь эффект одной модели нельзя. Эти показатели не устанавливают окупаемость проекта. Gupta и соавторы, разделы 5–6, таблица 3.
Что из этого полезно руководителю
Для своей компании стоит разобрать момент, в котором обращение застревает. Клиент уже прочитал условия доставки, но всё ещё не знает, где находится его заказ. Сотруднику приходится сопоставлять переписку, статус в учётной системе и сообщение службы доставки. Именно этот участок можно выбрать для автоматизации.
Здесь важны три условия: у помощника есть актуальные сведения, ему понятен порядок разбора ситуации и у него есть разрешённый следующий шаг. Ответ «заказ передан перевозчику» может закрыть вопрос о статусе. При жалобе на потерю отправления того же ответа недостаточно: необходимо начать разбирательство и назначить ответственного.
Поэтому при подготовке проекта Makesense предлагает описать, что компания считает решённым вопросом. Закрытый чат сам по себе ничего не говорит о результате для покупателя. Если тот вынужден писать снова, эту ситуацию нужно видеть в оценке качества.
Как адаптировать подход для Беларуси
Начать можно с интернет-магазина, оптового поставщика или сервисной компании, доставляющей оборудование клиентам. Подход имеет смысл там, где повторяются вопросы о конкретных отправлениях и их состояние можно проверить в системе. Это предлагаемое применение; результаты местного внедрения ещё предстоит измерить.
Для первого проекта мы предлагаем одну очередь обращений: статус и задержка доставки. Нужно определить, где хранится достоверная информация, как быстро она обновляется и какие действия разрешены при отклонении от срока. Если используются 1С, CRM и кабинет перевозчика, сначала проверяется возможность обмена данными между ними.
Предлагаемый порядок работы выглядит так:
Узнать заказ клиента. Связать обращение с подтверждённой учётной записью или пройти принятую в компании проверку. Номера заказа недостаточно для раскрытия чужих данных.
Получить актуальный статус. Показать сведения из системы и ожидаемый срок, если он указан. При отсутствии данных передать вопрос сотруднику.
Разобрать отклонение. При задержке предложить создать обращение в службу доставки. Сообщать о его создании только после подтверждения системы.
Сохранить контекст. Если требуется сотрудник, передать ему найденные сведения и уже выполненные шаги, чтобы клиенту не пришлось объяснять всё заново.
Правила следует настроить под реальные маршруты, населённые пункты, график службы поддержки и условия конкретных перевозчиков. Основной язык ответов и необходимость белорусскоязычного обслуживания определяются по обращениям заказчика. Возврат денег, изменение адреса и повторную отправку товара на первом этапе оставляем ответственному сотруднику.
Что предлагает Makesense
Makesense предлагает помочь спроектировать и проверить такой процесс в системе заказчика. Первый этап начинается с разбора обезличенных обращений и существующего порядка доставки. Результатом станет карта одного сценария: нужные данные, причины передачи человеку, допустимые действия и способ оценки результата.
Затем мы предлагаем подготовить пилот с подключением к выбранному источнику статусов. Сначала сотрудник проверяет ответы и действия. Это позволяет обнаружить неверные сроки, неполные данные и лишние уточнения до самостоятельного общения системы с покупателями. Переход к автоматическим ответам происходит после проверки согласованных сценариев.
Заказчик получает настроенный процесс, набор испытаний, инструкцию для сотрудников и отчёт о пилоте. В нём отдельно показываются качество ответов, повторные обращения, время участия человека и затраты на работу решения. Настройки, данные и инфраструктура остаются под управлением заказчика; сопровождение согласуется отдельно.
Ожидаемая польза для покупателя состоит в понятном ответе и следующем действии. Для сотрудника это возможность тратить меньше времени на поиск статусов и заниматься сложными случаями. Для руководителя важно подтвердить эту пользу измерениями, включая стоимость проверки и поддержки системы.
Для первого разбора достаточно подготовить обезличенные примеры обращений, правила обработки задержек и перечень систем, где видны заказы. Makesense поможет определить, какой участок можно проверить пилотом и какие пробелы в данных нужно устранить до его запуска.
Исходный кейс касается доставки банковских карт; описанная адаптация для заказов белорусских компаний является предложением Makesense.