Как настроить обратные вызовы SMS в Zapier

Обратный вызов о доставке полезен, только если он обновляет нужную запись. В рабочем процессе Zapier это может означать обновление контакта в CRM после того, как провайдер сообщил о доставке сообщения, — или отсутствие изменений, если событие относится к другой кампании. Главное — связать событие от провайдера с нужной записью, не считая все входящие обновления взаимозаменяемыми.

В этом руководстве показано, как настроить вебхук SMS в Zapier и обработать обратный вызов статуса доставки SMS: от выбора записи до проверки готового Zap.

1. Выберите запись, которую должен обновлять Zap

Для начала выберите, куда именно нужно вносить изменения. Это может быть контакт в CRM, заказ или запись о кампании — в зависимости от того, где ваша команда отслеживает результаты SMS-рассылок. Решите, как должно выглядеть полезное обновление: поле со статусом доставки, временная отметка или примечание с идентификатором сообщения. Чтобы понять, как обновлять CRM по статусу доставки SMS, заранее определите, какие из этих данных нужны команде.

Затем определите постоянный идентификатор, по которому обратный вызов можно связать с этой записью. Часто для этого подходит идентификатор сообщения от провайдера, если ваша система сохраняет его при отправке SMS. Номер телефона получателя может подойти, только если приложение назначения однозначно находит по нему нужную запись. Если в импортированном списке есть повторяющиеся номера телефонов, поиск только по номеру может привести к обновлению не того контакта.

Прежде чем создавать Zap, запишите, по какому полю приложение назначения ищет записи. Например, если CRM ищет по пользовательскому полю с идентификатором сообщения, убедитесь, что процесс отправки записывает в это поле тот же идентификатор. Обратный вызов сам по себе не сможет связать события с записью, если в исходной записи SMS нет подходящего значения.

2. Создайте триггер вебхука в Zapier

Создайте Zap и выберите триггер вебхука, например Catch Hook. Zapier должен показать сгенерированный URL для этого триггера. Скопируйте его в защищённую заметку, пока настраиваете провайдера.

По этому адресу SMS-провайдер будет отправлять события о доставке. Считайте URL конфиденциальной настройкой: не размещайте его в общедоступном документе и не отправляйте обычным сообщением.

Начните с простой версии. Подключите триггер вебхука к тестовому приложению или записи с явной пометкой «Тест», а не к реальной записи клиента. Так вы сможете проверить данные, которые получает триггер, прежде чем изменение статуса затронет действующий рабочий процесс.

3. Отправьте триггеру тестовое событие о доставке

Используйте тестовый обратный вызов SMS-провайдера, если такая функция доступна, или отправьте тестовое SMS и дождитесь обратного вызова статуса доставки SMS.

Когда событие поступит, проверьте захваченные в Zapier поля. Найдите идентификатор сообщения, данные получателя, статус от провайдера и временную отметку события. Названия полей могут быть сокращёнными или зависеть от провайдера, поэтому, прежде чем связывать поле с полем CRM, сверьте полученное значение с документацией провайдера.

Одно тестовое событие — это только начало, а не полноценная проверка. Если провайдер может отправлять события об успешной и неудачной доставке, получите каждый тип отдельно и отметьте, какие поля меняются. Если не проверить пример с ошибкой, Zap может правильно обрабатывать успешную доставку, но не реагировать на недоставленное сообщение.

В рабочих процессах с событиями электронной почты аналогичное различие между входящим событием и записью, которую оно должно затронуть, рассматривается в статье «События вебхуков транзакционных писем». Продукты различаются, но привычка проверять фактические данные события перед сопоставлением полей остаётся полезной.

4. Сопоставьте статусы провайдера с нужными метками

Статус, который отправляет провайдер, может не совпадать с метками в приложении назначения. Определите, какие значения нужны вашей команде, а затем используйте доступные в Zapier инструменты форматирования или ветвления, чтобы преобразовать статусы провайдера в нужные метки.

Например, в CRM могут использоваться статусы «Доставлено» и «Не доставлено», а провайдер — другие формулировки. Сопоставляйте только те значения, которые вы проверили по полученным событиям или документации.

Явно задайте правила сопоставления. Перед настройкой Zap составьте небольшой список:

• Значение провайдера, подтверждающее доставку: установить в целевой записи статус «Доставлено».
• Значение провайдера, подтверждающее неудачную доставку: установить статус «Не доставлено» или выбранную вашей командой метку.
• Неизвестное или отсутствующее значение: не менять статус или отправить событие на проверку.

Последний случай важен. Если после изменения настроек появится новый статус провайдера, общее правило, которое присваивает всем неизвестным значениям статус «Доставлено», может создать в CRM ложные данные. Проверьте определения статусов провайдера и обновите правила сопоставления, если в реальном событии появится неожиданное значение.

5. Связывайте каждый обратный вызов с нужной записью

Добавьте действие в приложении назначения, которое находит или обновляет запись, а затем сопоставьте идентификатор сообщения или получателя из обратного вызова с полем поиска приложения. Убедитесь, что провайдер передаёт значение, по которому приложение назначения действительно может выполнить поиск. Если в обратном вызове есть идентификатор сообщения, а CRM хранит только номера телефонов, Zap должен надёжно связать эти значения, прежде чем обновлять нужную запись.

Проверьте поиск на записи, которую вы сможете узнать. Тестовый контакт с чёткой пометкой в имени поможет понять, нашёл ли Zap нужную запись или не обнаружил совпадений. Если поиск может вернуть несколько записей, остановитесь и исправьте ключ сопоставления, а не позволяйте рабочему процессу выбирать запись без чёткого правила.

Не создавайте новые записи клиентов автоматически, если это не предусмотрено вашим процессом: иначе из-за опечатки или незнакомого значения в обратном вызове в системе могут появиться лишние записи.

События SMS могут содержать данные получателя, поэтому сопоставляйте только те поля, которые нужны команде для работы. О том, как обрабатывать данные в другом канале обмена сообщениями, читайте в статье «Отслеживание электронной почты и соблюдение требований к конфиденциальности». В этом Zap, например, можно не добавлять номер телефона в текстовое примечание, если достаточно указать статус и идентификатор сообщения.

6. Не применяйте устаревшие или повторные обновления

До подключения Zap к реальной записи решите, как он должен обрабатывать повторные обратные вызовы и события со статусом, поступившие с задержкой. Иначе более старое событие может заменить новый статус, а одно и то же событие — создать несколько одинаковых примечаний.

Если в приложении назначения есть поле для временной отметки, сохраняйте в нём время события вместе со статусом и учитывайте его, чтобы определить, какое обновление новее. Поле со временем получения события может помочь при устранении неполадок, но оно не всегда показывает, какое событие провайдера произошло раньше.

Если рабочий процесс не может надёжно сравнивать идентификаторы событий или временные отметки, выберите осторожный подход: обновляйте одно поле статуса вместо добавления нового примечания при каждом обратном вызове и проверяйте историю задач, если появляются повторные изменения.

7. Проверьте весь Zap на реальных данных обратного вызова

Запустите тест от триггера до действия в приложении назначения. Убедитесь, что обратный вызов поступает в нужную запись, статус провайдера преобразуется в ожидаемую метку, а остальные поля остаются без изменений. Успешная проверка триггера сама по себе ещё не доказывает, что шаг поиска выбрал нужный контакт.

Проверьте как минимум одно событие, которое должно обновить запись, и один случай, когда обновления быть не должно, например обратный вызов без подходящего идентификатора, если провайдер может его отправить. После каждого запуска проверьте саму запись. Zapier может сообщить, что действие выполнено, но для команды важнее всего увидеть фактические значения в записи.

Если Zap работает не так, как ожидалось, проверьте историю задач Zapier и сравните значения, полученные триггером, с полями, используемыми в действиях поиска и обновления. Убедитесь, что идентификатор сообщения не пустой, правило сопоставления статусов учитывает значение провайдера, а приложение назначения не нашло другую запись. Исправляйте по одному пункту за раз, а затем повторно протестируйте весь процесс.

Прежде чем переключаться с тестовой записи на реальную, вместе проверьте выбранный Zap, URL триггера, поле поиска и правила сопоставления статусов. Запишите значения статусов провайдера, которые вы проверили. Если при следующем тесте появится новое значение, приостановите правило обновления, пока не выясните, что оно означает.