Клиент ушёл из-за проблемы: когда win-back рано отправлять
Когда откладывать win-back после сервисной проблемы: матрица причины ухода, доказательства исправления, стоп-условия и маршрут клиента в поддержку.
Письмо «Мы скучаем, вернитесь со скидкой» выглядит странно, если человек ушёл из-за повторяющейся ошибки, а она всё ещё воспроизводится. Давность последней покупки помогает найти спящего клиента. Для выбора следующего контакта нужна ещё причина ухода.
Я бы добавил перед обычным win-back проверку сервисных исключений. Она отвечает на узкий вопрос: можно ли сейчас предлагать возвращение человеку, который столкнулся с конкретной проблемой? Общая сегментация реактивации этой проверки не заменяет.
Найдите причину и её источник
Разделите сообщение клиента, вывод сотрудника и предположение модели. «Не вернулся после ошибки оплаты» — наблюдение последовательности. «Ушёл из-за ошибки оплаты» — уже вывод о причине. Если человек сообщил её сам, сохраните ссылку на обращение и дату. Если причина неизвестна, не подставляйте наиболее удобную.
Для работы достаточно карточки: клиент, проблема, затронутый продукт или версия, источник причины, ответственный, состояние исправления, последнее подтверждение и допустимый следующий контакт. Она может находиться в CRM, но должна быть связана с системой, где действительно ведут проблему.
Высокая ценность клиента по RFM может повысить приоритет разбора. Она не подтверждает, что ошибка исправлена, и не отменяет стоп-условие.
Что именно считается исправлением
У Atlassian инцидент считается resolved, когда сервис снова работает обычным образом. Поиск первопричины и последующие меры продолжаются в postmortem. Поэтому закрытый инцидент не гарантирует завершения всех действий против повторения.
Для контакта важен пользовательский сценарий. Если клиент не мог загрузить файл нужного размера, проверьте этот размер, тип аккаунта и текущую версию. Успешная загрузка маленького тестового файла на другой учётной записи подтверждает меньше, чем хочется написать в письме.
Не нужно обещать абсолютную невозможность повторения. Нужно точно знать, что восстановлено, что проверено и какие ограничения остаются. Если доступно только временное решение, его так и следует назвать.
| Ситуация | Доказательство | Следующее действие |
|---|---|---|
| Ошибка ещё воспроизводится | Есть актуальный повтор и открытая задача | Маршрут в поддержку; предложение вернуться приостановлено |
| Исправление выпущено, сценарий клиента не проверен | Есть запись о релизе | Проверить применимость, не объявлять проблему решённой для клиента |
| Сценарий восстановлен | Зафиксирована проверка нужной версии и условий | Сообщить, что изменилось; обсудить возвращение без гарантии результата |
| Доступен обходной путь | Проверен способ работы с ограничениями | Объяснить ограничения и дать человеку выбор |
| Причина ухода неизвестна | Подтверждена только неактивность | Уточнить контекст, не ссылаться на вымышленную проблему |
Как поставить эту проверку в автоматизацию
В Mailchimp Marketing Automation Flows есть условия входа, ветвления и ожидание события. Это механизмы выполнения правил. Сами по себе они не узнают, какой тикет связан с покупателем и прошла ли проверка исправления; доступность отдельных шагов также зависит от тарифа.
Я бы передавал в маршрут явные состояния: «сервисная причина не проверена», «проблема открыта», «можно сообщить об исправлении», «можно обсуждать возврат». У каждого изменения должны быть источник и время. Если интеграция перестала обновлять состояние, старое разрешение нельзя считать бесконечно действующим.
- Проверьте состояние перед входом в цепочку и ещё раз непосредственно перед отправкой. Между ними клиент мог открыть новое обращение.
- Не превращайте пустое поле в разрешение. Для неизвестного состояния предусмотрите отдельную ветку разбора.
- Исключите повторную отправку при повторном событии исправления. Свяжите контакт с ID проблемы и версией сообщения.
- Проверьте, что выбранный канал общения действительно допустим для этого клиента и соответствует договорённости с ним.
Что сказать после проверки
Сообщение должно объяснять изменение: какую проблему исправили, в каких условиях проверили и что человек может сделать дальше. Если необходимо его участие, предложите ограниченный шаг. Не подменяйте описание исправления скидкой.
В прошлый раз у вас не проходила загрузка файла выбранного формата. Мы обновили обработку и проверили этот сценарий на текущей версии. Если задача ещё актуальна, можем вместе проверить ваш файл. Ограничение по размеру сохраняется.
Это условный текст: в реальном письме каждое утверждение должно иметь подтверждение. Ответ «уже не нужно» завершает конкретную попытку. Ответ «ошибка осталась» возвращает клиента в поддержку, а не в следующую рекламную ветку.
После контакта отдельно учитывайте восстановление сценария, согласие попробовать снова и фактическую покупку. Три разных события помогут понять, где процесс остановился, без обещания, что техническое исправление обязательно вернёт клиента.