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