Як налаштувати статус доставки SMS у Zapier

Зворотний виклик про доставку корисний лише тоді, коли він змінює потрібний запис. У робочому процесі Zapier це може означати оновлення контакту в CRM після того, як провайдер повідомив про доставку повідомлення, або залишення контакту без змін, якщо подія стосується іншої кампанії. Головне — пов’язати подію від провайдера із записом у цільовій системі й не вважати всі вхідні оновлення взаємозамінними.

У цьому посібнику розглянемо, як налаштувати вебхук SMS у Zapier для зворотних викликів статусу доставки: від вибору запису до перевірки готового Zap.

1. Виберіть запис, який має оновлювати Zap

Спершу виберіть цільовий запис. Це може бути контакт у CRM, замовлення або запис кампанії — залежно від того, де ваша команда відстежує результати SMS-розсилок. Визначте, яке оновлення буде корисним: поле зі статусом доставки, мітка часу або примітка з ідентифікатором повідомлення.

Потім визначте стабільне значення, яке пов’язує зворотний виклик із цим записом. Ідентифікатор повідомлення від провайдера часто підходить, якщо система зберегла його під час надсилання SMS. Номер телефону одержувача можна використовувати лише тоді, коли цільовий застосунок однозначно знаходить за ним потрібний запис. Якщо в імпортованому списку є дублікати номерів, пошук лише за номером може призвести до оновлення не того контакту.

Саме так можна визначити, як зіставити зворотний виклик SMS із записом, не покладаючись на неоднозначні дані. Перш ніж створювати Zap, запишіть, за яким полем цільовий застосунок шукає записи. Наприклад, якщо CRM шукає за спеціальним полем ідентифікатора повідомлення, переконайтеся, що процес надсилання записує той самий ідентифікатор саме в це поле. Зворотний виклик не зможе самостійно пов’язати дані, якщо в початковому записі SMS немає відповідного значення.

2. Створіть тригер вебхука в Zapier

Створіть Zap і виберіть тригер вебхука, наприклад Catch Hook. Zapier згенерує URL-адресу для цього тригера. Скопіюйте її в захищену робочу нотатку, поки налаштовуєте провайдера.

За цією URL-адресою провайдер SMS надсилатиме події про доставку. Ставтеся до неї як до конфіденційних налаштувань: не публікуйте її в спільних документах і не надсилайте звичайним повідомленням.

Для початку налаштуйте лише найнеобхідніше. Під’єднайте тригер вебхука до тестового цільового застосунку або чітко позначеного тестового запису, а не до запису реального клієнта. Так ви зможете перевірити, які дані отримує тригер, перш ніж зміна статусу вплине на активний процес.

3. Надішліть тригеру тестову подію про доставку

Скористайтеся тестовим зворотним викликом від провайдера SMS, якщо така можливість є. Або надішліть тестове SMS і дочекайтеся зворотного виклику.

Коли подія надійде, перевірте отримані поля в Zapier. Знайдіть ідентифікатор повідомлення, дані одержувача, статус від провайдера та час події. Назви полів можуть бути скороченими або специфічними для певного провайдера, тож перш ніж зіставляти їх із полями CRM, звірте отримані значення з документацією провайдера.

Одна тестова подія — це лише початок, а не повноцінна перевірка. Якщо провайдер може надсилати події про успішну доставку й помилку, окремо отримайте кожну з них і занотуйте, які поля відрізняються. Без прикладу помилки Zap може правильно обробляти успішну доставку, але не реагувати на повідомлення, яке доставити не вдалося.

У робочих процесах електронної пошти, що запускаються подіями, такий самий принцип — відрізняти вхідну подію від запису, на який вона має вплинути, — розглянуто в матеріалі про події вебхуків транзакційної електронної пошти. Продукти різні, але перевіряти фактичні дані події перед зіставленням полів корисно завжди.

4. Перетворіть статуси провайдера на зрозумілі позначення

Статус, який надсилає провайдер, може не збігатися з позначеннями в цільовому застосунку. Визначте, що саме має бачити команда, а потім скористайтеся доступними в Zapier інструментами форматування або розгалуження, щоб перетворити специфічні для провайдера значення на потрібні позначення. Це допоможе зрозуміти, як оновлювати статус доставки SMS у CRM відповідно до подій від провайдера.

Наприклад, у CRM можуть використовуватися позначення «Доставлено» й «Не доставлено», тоді як провайдер надсилає інші значення. Налаштовуйте відповідність лише для тих значень, які ви підтвердили за отриманими подіями або документацією.

Задайте відповідність явно. Перш ніж налаштовувати Zap, складіть короткий список правил:

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

Останній випадок важливий. Якщо після зміни налаштувань з’явиться новий статус провайдера, універсальне правило, яке позначає будь-яке невідоме значення як «Доставлено», може призвести до хибного результату в CRM. Перевірте визначення статусів у документації провайдера й оновіть відповідність, якщо реальна подія містить неочікуване значення.

5. Зіставте кожен зворотний виклик із потрібним записом

Додайте дію цільового застосунку для пошуку або оновлення запису, а потім зіставте ідентифікатор повідомлення чи одержувача зі зворотного виклику з полем пошуку в застосунку. Переконайтеся, що провайдер надсилає значення, за яким цільовий застосунок справді може виконати пошук. Якщо у зворотному виклику є ідентифікатор повідомлення, а CRM зберігає лише номери телефонів, Zap має надійно пов’язати ці значення, перш ніж оновлювати потрібний запис.

Перевірте пошук на записі, який легко впізнати. Контакт із чітко позначеним тестовим ім’ям допоможе з’ясувати, чи Zap знайшов потрібний запис, чи не знайшов жодного. Якщо пошук може повертати кілька записів, зупиніться й виправте ключ зіставлення, а не дозволяйте процесу вибирати запис без чіткого правила.

Не створюйте новий запис клієнта автоматично, якщо це не передбачено вашим процесом. Інакше через помилково введене або незнайоме значення зі зворотного виклику в системі можуть з’явитися зайві записи.

Події SMS можуть містити дані одержувача, тому зіставляйте лише ті поля, які потрібні команді для роботи. Про обробку даних в іншому каналі обміну повідомленнями читайте в матеріалі про відстеження електронної пошти та дотримання вимог конфіденційності. У цьому Zap, наприклад, можна не додавати номер телефону у текстову примітку, якщо для роботи достатньо статусу й ідентифікатора повідомлення.

6. Не застосовуйте застарілі або повторні оновлення

Перш ніж під’єднувати Zap до реального запису, визначте, як він має обробляти повторні зворотні виклики та статуси, що надійшли із запізненням. Інакше стара подія може замінити новіший статус, а повторна — створити дублікати приміток.

Якщо в цільовому застосунку є поле для мітки часу, зберігайте в ньому час події разом зі статусом і використовуйте його, щоб визначати, яке оновлення новіше. Поле з часом отримання може стати в пригоді для пошуку несправностей, але воно не завжди показує, яка подія від провайдера відбулася першою.

Якщо робочий процес не може надійно порівнювати ідентифікатори подій або часові мітки, обмежтеся обережними діями: оновлюйте одне поле статусу, а не додавайте нову примітку для кожного зворотного виклику. Якщо з’являться дублікати змін, перевірте історію завдань.

7. Перевірте весь Zap на реальних даних зворотного виклику

Запустіть тест від тригера до дії в цільовому застосунку. Переконайтеся, що зворотний виклик надходить до потрібного запису, статус провайдера перетворюється на очікуване позначення, а сторонні поля залишаються без змін. Успішна перевірка тригера сама по собі не доводить, що крок пошуку вибрав правильний контакт.

Перевірте щонайменше одну подію, яка має оновити запис, і один випадок, коли оновлення не має відбутися, наприклад зворотний виклик без відповідного ідентифікатора, якщо провайдер може надіслати такий. Після кожного запуску перевіряйте сам цільовий запис. Zapier може повідомити, що дію виконано, але команді важливо бачити, які значення фактично з’явилися в записі.

Якщо щось працює не так, перегляньте історію завдань у Zapier і порівняйте отримані тригером значення з полями, використаними в діях пошуку й оновлення. Перевірте, чи не порожній ідентифікатор повідомлення, чи не пропущене значення статусу провайдера під час зіставлення та чи не знайшов цільовий застосунок інший запис. Вносьте по одній зміні за раз, а потім повторно перевіряйте весь процес.

Перш ніж замінити тестовий запис на реальний, перевірте разом вибраний Zap, URL-адресу тригера, поле пошуку й зіставлення статусів. Збережіть перелік підтверджених значень статусів провайдера. Якщо під час подальшої перевірки з’явиться нове значення, призупиніть правило оновлення, доки не з’ясуєте, що воно означає.