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