Логика оценки
Какие ветки есть в шаблоне
Seed начинает с вопроса о вероятности рекомендации, но после sendMessage нет waitInput или иной ноды ожидания. Поэтому setVariable не получает ответ человека: в nps_score записывается буквальная строка {{input}}, и граф сразу идёт к условиям. Сообщение создаёт видимость опроса, однако оценка пользователя в этом пути не сохранена.
В seed заданы условия gte 9 и gte 7. Компилятор сопоставляет gte со строгим gt, поэтому после исправления ввода такие пороги будут означать >9 и >7. При последовательной проверке это оставляет 10 в верхней ветке, 8 и 9 во второй, а 0–7 в оставшейся. Это не совпадает с текстом seed о группах 9–10, 7–8 и 1–6.
До публикации добавьте supported-ноду waitInput после вопроса, запишите её результат в nps_score либо используйте переменную ожидания напрямую и проверьте числовой диапазон 0–10. Затем задайте условия и тексты для выбранных групп в одном месте. Только после этого теги nps_promoter, nps_passive и nps_detractor могут означать фактический ответ, а не прохождение неполного графа.
- После вопроса добавлена supported-нода waitInput, которая сохраняет ответ пользователя.
- Проверка допускает только целое число от 0 до 10 и повторно спрашивает при ошибке.
- Условия учитывают строгую компиляцию gte в gt и соответствуют выбранным диапазонам.
- Теги nps_promoter, nps_passive и nps_detractor получают фактический ответ, а не literal {{input}}.
Пример диалога
До первой проверки
Подумайте о некорректном вводе
Пока в графе нет waitInput, некорректный ввод не является отдельным случаем: никакое сообщение пользователя не удерживает выполнение после вопроса. Первое обязательное исправление — добавить supported-ожидание, связанное с переменной оценки. Уже после этого можно решать, как реагировать на слово, дробное значение, эмодзи или несколько чисел.
Валидация должна принимать только число от 0 до 10 по выбранному правилу, например целое значение. При ошибке сценарий должен объяснять формат и возвращать человека к тому же ожиданию, а не отправлять в одну из NPS-веток. Если используете кнопки, их значения обязаны записываться в ту же проверяемую переменную.
После доработки проверьте 0, 6, 7, 8, 9 и 10. С учётом текущего преобразования gte в gt границы нужно выставить так, чтобы они давали именно утверждённые вами группы. Не считайте текст в узле условием: сопоставьте отображаемую шкалу, записанную переменную, оператор компилятора и все ветви на тестовых ответах.
Выберите момент опроса
Спрашивайте после понятного взаимодействия: завершённой услуги, полученного ответа поддержки или другого события, которое вы можете назвать пользователю.
Настройте обработку ввода
Добавьте waitInput, числовую проверку и повторный вопрос для значений вне диапазона. Исходный setVariable с {{input}} не заменяет ожидание сообщения.
Пройдите пограничные оценки
Проверьте шесть граничных значений после компиляции условий и убедитесь, что сообщение и тег соответствуют утверждённой группе.
После ответа
Свяжите сегменты с реальными действиями
До добавления ожидания и валидации теги в seed не подтверждают реальную оценку, поэтому нельзя запускать по ним разные коммуникации. После исправления верхняя группа может получать просьбу о рекомендации, средняя — вопрос о недостающей функции, а низкая — приглашение описать проблему. Размер бонуса, ссылки и условия реферальной программы из демонстрационного сообщения замените на свои проверенные значения.
Сообщение для средней группы просит написать, что можно улучшить. Заранее назначьте канал обработки: операторский диалог, форму или очередь отзывов. Ветка с низкой оценкой упоминает личный контакт менеджера; оставляйте это обещание только при установленном времени реакции и ответственном сотруднике. Иначе дайте конкретный рабочий путь в поддержку.
Не делайте из тега окончательный портрет человека. Даже после исправления одна оценка относится к одному эпизоду, а не ко всем отношениям с продуктом. Сохраняйте дату, контекст и добровольный комментарий в пределах разрешённой обработки данных. Отдельно проверяйте, что новый ввод не перезаписывает оценку другого опроса.
Коммуникация и данные
Собирайте только нужную обратную связь
После добавления работающего ввода NPS-вопрос всё равно не требует номера карты, документа или других лишних сведений. Если человек присылает персональные данные в свободном тексте, оператор действует по правилам доступа и хранения. Не просите чувствительные данные в ответ на просьбу объяснить оценку. Для технической диагностики достаточно номера заказа или обращения, если он уже есть в системе и понятна цель запроса.
Тон сообщения для низкой оценки важен: не спорьте, не требуйте доказательств и не обещайте исправление к конкретной дате без согласования с командой. Когда ветка действительно получает валидную оценку, спокойное приглашение описать проблему можно адаптировать под голос бренда и передать в установленный канал обработки.
Не превращайте исправленные сегменты в причину для навязчивых рассылок. Одна оценка не означает согласие на неограниченные сообщения. При дальнейшем контакте соблюдайте настройки уведомлений и контекст диалога. Если человек просит прекратить сообщения, обработайте это независимо от его NPS-тега.
- Запрашиваются только сведения, нужные для ответа на обратную связь.
- У команды есть канал для обработки комментариев из passive и detractor.
- Обещание связи с менеджером подтверждено процессом, а не только текстом.
- Последующие сообщения учитывают настройки и контекст пользователя.
Контроль перед публикацией
Проверьте путь глазами пользователя
Сначала внесите обязательные изменения: waitInput после вопроса, проверку числа 0–10 и условия, учитывающие строгий gt. Затем запустите опрос тестовыми ответами на границах шкалы и убедитесь, что переменная, тег и итоговое сообщение принадлежат одной группе. Ссылка для верхней ветки и способ оставить комментарий должны вести к существующим действиям.
Проверьте, что результат не смешивается с другими опросами. Если в боте уже есть оценки поддержки, доставки или продукта, названия переменных и тегов должны различать их. Не используйте nps_score как общую переменную без контекста, если один профиль проходит несколько опросов. Добавьте более точную структуру в пределах возможностей конструктора.
После начала сбора просматривайте не только число тегов, но и необработанные обращения. Рабочая ценность появляется в следующем шаге команды: прочитать проблему, ответить в доступный срок и исправить процесс там, где это возможно. Сам seed без обязательной доработки этой работы не запускает.