Webhooki statusu dostarczenia SMS-ów w Zapier
Dowiedz się, jak skonfigurować webhooki dostarczenia SMS-ów w Zapier, powiązać zdarzenia z właściwym rekordem i mapować statusy dostawcy.

Webhook potwierdzający dostarczenie jest przydatny tylko wtedy, gdy aktualizuje właściwy rekord. W przepływie pracy w Zapier może to oznaczać aktualizację kontaktu w CRM po otrzymaniu od dostawcy informacji o dostarczeniu wiadomości — albo pozostawienie kontaktu bez zmian, jeśli zdarzenie dotyczy innej kampanii. Najważniejsze jest powiązanie zdarzenia od dostawcy z właściwym rekordem docelowym, a nie traktowanie każdej przychodzącej aktualizacji tak samo.
W tym przewodniku wyjaśniamy, jak skonfigurować webhooki statusu dostarczenia SMS-ów w Zapier — od wyboru rekordu po sprawdzenie gotowego Zapa. Jeśli szukasz praktycznych wskazówek, jak skonfigurować webhook SMS w Zapier, zacznij od określenia, który rekord ma aktualizować przychodzące zdarzenie.
1. Wybierz rekord, który ma aktualizować Zap
Na początek wybierz jeden rekord docelowy. W zależności od tego, gdzie zespół sprawdza wyniki wysyłki SMS-ów, może to być kontakt w CRM, zamówienie lub rekord kampanii. Zastanów się, jak powinna wyglądać przydatna aktualizacja: może to być pole ze statusem dostarczenia, znacznik czasu albo notatka zawierająca identyfikator wiadomości. W przypadku przepływu, w którym potrzebna jest aktualizacja kontaktu w CRM przez webhook, szczególnie ważne jest wybranie stabilnego pola do wyszukiwania rekordu.
Następnie znajdź stabilną wartość, która powiąże webhook z tym rekordem. Dobrym kandydatem jest często identyfikator wiadomości nadany przez dostawcę — pod warunkiem, że system zapisał go w chwili wysyłania SMS-a. Numer telefonu odbiorcy może się sprawdzić tylko wtedy, gdy aplikacja docelowa potrafi jednoznacznie znaleźć pasujący rekord. Jeśli zaimportowana lista zawiera powtarzające się numery, wyszukiwanie wyłącznie po numerze może doprowadzić do aktualizacji niewłaściwego kontaktu.
Zanim utworzysz Zapa, zanotuj pole, którego aplikacja docelowa używa do wyszukiwania. Jeśli na przykład CRM wyszukuje rekordy na podstawie niestandardowego pola z identyfikatorem wiadomości, upewnij się, że proces wysyłki zapisuje tam ten sam identyfikator. Jeśli pierwotny rekord SMS-a nie zawiera pasującej wartości, sam webhook nie będzie w stanie powiązać go z właściwym rekordem.
2. Utwórz wyzwalacz webhook w Zapier
Utwórz Zapa i wybierz wyzwalacz webhook, na przykład Catch Hook. Zapier powinien wyświetlić wygenerowany adres URL wyzwalacza. Skopiuj go do bezpiecznej notatki roboczej na czas konfiguracji dostawcy.
Wygenerowany adres URL to miejsce, pod które dostawca SMS-ów będzie wysyłać zdarzenia dotyczące dostarczenia. Traktuj go jak poufną konfigurację: nie publikuj go we współdzielonym dokumencie ani nie przesyłaj w zwykłej wiadomości.
Na początek ogranicz zakres konfiguracji. Połącz wyzwalacz webhook z testowym miejscem docelowym albo wyraźnie oznaczonym rekordem testowym, a nie z rekordem aktywnego klienta. Dzięki temu sprawdzisz, jakie dane otrzymuje wyzwalacz, zanim zmiana statusu wpłynie na działający proces.
3. Wyślij przykładowe zdarzenie o dostarczeniu do wyzwalacza
Skorzystaj z testowego webhooka dostawcy SMS-ów, jeśli jest dostępny, albo wyślij testowego SMS-a i poczekaj na webhook potwierdzający jego status.
Gdy zdarzenie dotrze, sprawdź przechwycone pola w Zapier. Poszukaj identyfikatora wiadomości, danych odbiorcy, statusu od dostawcy i znacznika czasu zdarzenia. Nazwy pól mogą być skrócone lub specyficzne dla danego dostawcy, dlatego przed przypisaniem wartości do pola w CRM porównaj je z dokumentacją dostawcy.
Jeden przykład to dopiero początek, a nie pełny test. Jeśli dostawca może wysłać zdarzenie informujące o dostarczeniu i zdarzenie o niepowodzeniu, przechwyć każde z nich osobno i sprawdź, które pole się zmienia. Brak przykładu nieudanego dostarczenia może sprawić, że Zap poprawnie obsłuży dostarczone wiadomości, ale zignoruje wiadomość, której nie udało się doręczyć.
Podobne rozróżnienie między przychodzącym zdarzeniem a rekordem, którego powinno ono dotyczyć, omawiamy w kontekście przepływów pracy opartych na zdarzeniach e-mail w artykule Webhooki zdarzeń e-mail dla wiadomości transakcyjnych. Produkty są różne, ale sprawdzanie rzeczywistego ładunku danych przed przypisaniem pól to wciąż dobra praktyka.
4. Przypisz statusom dostawcy zrozumiałe etykiety
Dostawca może wysyłać wartości statusu, które nie odpowiadają etykietom używanym w aplikacji docelowej. Zastanów się, jakie informacje są potrzebne zespołowi, a następnie skorzystaj z dostępnych w Zapier narzędzi do formatowania lub rozgałęziania przepływu, aby zamienić wartości specyficzne dla dostawcy na odpowiednie etykiety. Dzięki temu status dostarczenia SMS w Zapier będzie łatwiejszy do zrozumienia i wykorzystania przez zespół.
Na przykład CRM może używać etykiet „Dostarczono” i „Nie dostarczono”, podczas gdy dostawca przesyła inne określenia. Przypisuj tylko te wartości, które potwierdzono w przechwyconych zdarzeniach lub dokumentacji.
Określ jawnie sposób mapowania. Przed skonfigurowaniem Zapa warto przygotować krótką listę reguł:
- Potwierdzona przez dostawcę wartość oznaczająca dostarczenie: ustaw w rekordzie docelowym etykietę „Dostarczono”.
- Potwierdzona przez dostawcę wartość oznaczająca niepowodzenie: ustaw etykietę „Nie dostarczono” albo inną wybraną przez zespół.
- Nieznana lub brakująca wartość: nie zmieniaj statusu albo skieruj zdarzenie do weryfikacji.
Ostatni przypadek ma znaczenie. Jeśli po zmianie konfiguracji pojawi się nowy status od dostawcy, reguła obejmująca wszystkie nierozpoznane wartości i oznaczająca je jako „Dostarczono” może spowodować błędny wpis w CRM. Sprawdź definicje statusów dostawcy i zmień mapowanie, gdy rzeczywiste zdarzenie ujawni nieoczekiwaną wartość.
5. Dopasuj każdy webhook do właściwego rekordu docelowego
Dodaj działanie aplikacji docelowej, które wyszuka lub zaktualizuje rekord, a następnie przypisz identyfikator wiadomości lub odbiorcy z webhooka do pola wyszukiwania w tej aplikacji. Upewnij się, że dostawca przekazuje wartość, której aplikacja docelowa rzeczywiście może użyć do wyszukania rekordu. Jeśli webhook zawiera identyfikator wiadomości, ale CRM przechowuje wyłącznie numery telefonów, Zap potrzebuje niezawodnego sposobu powiązania tych wartości, zanim zaktualizuje właściwy rekord.
Przetestuj wyszukiwanie na rekordzie, który łatwo rozpoznasz. Kontakt testowy z wyraźnie oznaczoną nazwą pomoże sprawdzić, czy Zap znalazł właściwy rekord, czy też nie zwrócił żadnego wyniku. Jeśli wyszukiwanie może zwrócić kilka pasujących rekordów, przerwij konfigurację i popraw klucz dopasowania. Nie pozwól, by przepływ wybrał rekord bez jasno określonej reguły.
Nie twórz automatycznie nowych rekordów klientów, chyba że jest to zamierzony element procesu. W przeciwnym razie literówka lub nieznana wartość z webhooka może niepotrzebnie zaśmiecić bazę.
Zdarzenia SMS mogą zawierać dane odbiorcy, dlatego przypisuj tylko te pola, których zespół potrzebuje do działania. Więcej o przetwarzaniu danych w innym kanale komunikacji przeczytasz w artykule Śledzenie wiadomości e-mail a ochrona prywatności. W tym Zapie może to oznaczać rezygnację z umieszczania numeru telefonu w notatce tekstowej, jeśli wystarczą etykieta statusu i identyfikator wiadomości.
6. Nie stosuj nieaktualnych ani powielonych aktualizacji
Zanim połączysz Zapa z aktywnym rekordem, zdecyduj, jak ma on obsługiwać powtórzony webhook i zdarzenie o statusie, które dotrze z opóźnieniem. W przeciwnym razie starsze zdarzenie może zastąpić nowszy status albo to samo zdarzenie może wygenerować kilka identycznych notatek.
Jeśli aplikacja docelowa oferuje pole na znacznik czasu, zapisuj czas zdarzenia razem ze statusem i wykorzystuj go do ustalenia, czy aktualizacja jest nowsza. Pole z czasem odebrania zdarzenia może pomóc w diagnozowaniu problemów, ale nie musi wskazywać, które zdarzenie od dostawcy wystąpiło jako pierwsze.
Jeśli przepływ nie potrafi niezawodnie porównywać identyfikatorów zdarzeń ani znaczników czasu, ogranicz jego działanie: aktualizuj jedno pole statusu zamiast dodawać nową notatkę przy każdym webhooku. Gdy pojawią się powielone zmiany, sprawdź historię zadań.
7. Przetestuj cały Zap na rzeczywistych danych z webhooka
Przeprowadź test od wyzwalacza aż po działanie aplikacji docelowej. Potwierdź, że webhook trafia do właściwego rekordu, status od dostawcy zostaje zamieniony na oczekiwaną etykietę, a niezwiązane z nim pola pozostają bez zmian. Pomyślny test samego wyzwalacza nie dowodzi jeszcze, że etap wyszukiwania wybrał właściwy kontakt.
Przetestuj co najmniej jedno zdarzenie, które powinno zaktualizować rekord, oraz jeden przypadek, który nie powinien tego robić — na przykład webhook bez pasującego identyfikatora, jeśli dostawca może go wygenerować. Po każdym uruchomieniu sprawdź sam rekord docelowy. Zapier może zgłosić, że działanie zostało wykonane, ale dla zespołu najważniejszym sprawdzianem są wartości widoczne w rekordzie.
Jeśli przepływ działa niezgodnie z oczekiwaniami, przejrzyj historię zadań w Zapier i porównaj przechwycone wartości wyzwalacza z polami użytymi w działaniach wyszukiwania i aktualizacji. Sprawdź, czy identyfikator wiadomości nie jest pusty, czy mapowanie statusu uwzględnia wartość od dostawcy oraz czy aplikacja docelowa nie dopasowała innego rekordu. Wprowadzaj po jednej zmianie, a następnie ponownie przetestuj cały przepływ.
Zanim przełączysz się z rekordu testowego na aktywne dane, zweryfikuj jednocześnie wybranego Zapa, adres URL wyzwalacza, pole wyszukiwania i mapowanie statusów. Zanotuj potwierdzone wartości statusu od dostawcy. Jeśli późniejszy test zwróci nową wartość, wstrzymaj regułę aktualizacji, dopóki nie ustalisz, co ona oznacza.
Na tej stronie
← Wszystkie artykułyJedno kliknięcie. Mówi nam, co napisać dalej.
Brak ocen — twoja będzie pierwsza.
Komentarze
Komentarze są czytane przed ich publikacją.