Если клиент не ответил на звонок с кодом или его линия занята, система должна предложить следующий способ подтверждения, а не запускать бесконечные повторы. Для этого задайте ограниченное число попыток, короткую паузу между ними и резервный канал, например Voice OTP или SMS. Ниже — схема, которую можно использовать при регистрации или входе: она поможет сохранить понятный путь для клиента и не допустить лишних звонков.
Что считать неудачной попыткой авторизации?
Сначала определите, какие результаты звонка требуют повторения. Например, клиент не ответил, линия занята или сервис не получил подтверждение ввода кода. Эти ситуации отличаются от неверного кода: повторный звонок не исправит ошибку ввода.
Зафиксируйте результаты попытки в системе: «не дозвонились», «занято», «код введён неверно», «подтверждение прошло». Для каждого результата задайте отдельное действие. Так разработчик сможет настроить логику без догадок, а служба поддержки — понять, на каком шаге остановился вход.
Как выстроить резервный сценарий?
Начните с одного основного канала и одного резервного. Например, система звонит и передаёт код, а если клиент не ответил, предлагает Voice OTP или отправляет код по SMS. Flash Call использует входящий короткий звонок: пользователь подтверждает номер по цифрам номера звонящего. При Voice OTP код звучит в голосовом сообщении. Эти каналы работают по-разному, поэтому резервный вариант нужно проверить на устройствах и в сетевых условиях, которыми пользуются ваши клиенты.
Практическая последовательность может выглядеть так:
- Клиент вводит номер и запрашивает код.
- Система запускает основной звонок и показывает, сколько ждать.
- Если звонок не состоялся или клиент не ответил, система предлагает повторить попытку либо перейти к резервному каналу.
- После подтверждения система завершает вход и блокирует повторное использование кода.
Переход между способами лучше сделать явным: покажите кнопку «Получить код голосом» или «Отправить SMS». Если переключение происходит автоматически, сообщите клиенту, какой канал используется и куда придёт код. Подробно сравнить поведение каналов поможет материал о переходе с Flash Call на Voice OTP.
Как ограничить повторы и не запутать клиента?
Задайте лимит попыток для одной сессии и паузу перед повторным звонком. Конкретные значения подбирают по тестам: слишком короткий интервал создаёт лишние звонки, слишком длинный заставляет клиента ждать. После исчерпания попыток предложите другой канал или понятный способ начать вход заново.
Свяжите лимиты с номером и текущей сессией, чтобы частые запросы не запускали новые звонки без ограничений. Для неверного кода используйте отдельный лимит: ошибка ввода и отсутствие ответа на звонок требуют разных действий. Правила повторов можно сверить с рекомендациями по настройке лимитов авторизации по звонку.
На экране достаточно коротких подсказок: «Звоним», «Не удалось дозвониться», «Повторить через некоторое время», «Выбрать другой способ». Не показывайте клиенту технические коды ошибок. Сохраняйте их в журнале событий, чтобы команда могла найти причину сбоя.
Как проверить резервный сценарий до запуска?
Проверьте не только успешный вход, но и случаи, когда клиент не отвечает, линия занята или вводит неправильный код. Отдельно пройдите путь повторного запроса и переключения на резервный канал. Для каждого теста запишите ожидаемый результат: сколько раз система звонит, что видит пользователь и когда доступна следующая попытка.
После запуска отслеживайте долю попыток, завершившихся входом, и причины незавершённых проверок. Если клиенты часто переходят на резервный канал, проверьте основной способ доставки и настройки интеграции. Не увеличивайте число повторов автоматически: сначала выясните, где именно прерывается сценарий.
Какие ошибки чаще всего мешают входу?
- Система повторяет звонок сразу после неудачи, хотя клиенту нужно время ответить.
- Неверный код и пропущенный звонок обрабатываются одинаково.
- Резервный канал запускается без уведомления, поэтому клиент ждёт код не там, где нужно.
- Повторы не ограничены для одной сессии, и клиент получает лишние звонки.
- После переключения старый код остаётся действительным без понятного правила для пользователя.
Сначала опишите в таблице три ситуации: нет ответа, занято, неверный код. Для каждой назначьте одно действие, затем проверьте сценарий на тестовом номере и убедитесь, что клиент видит следующий шаг после сбоя.
