Wysyłanie rozmów z WhatsApp do Salesforce z numeru Coexistence

Jak wygląda przepływ w n8n?

Cztery węzły w jednej linii, plus gałąź weryfikacji, której wymaga każdy webhook Meta.

Węzeł Webhook odbiera żądanie POST, które Meta wysyła dla każdej wiadomości. Węzeł Salesforce uruchamia zapytanie SOQL o Lead lub Contact, którego telefon pasuje do nadawcy. Węzeł IF rozdziela przepływ w zależności od tego, czy cokolwiek wróciło: jeśli tak, przepływ przekazuje dalej identyfikator rekordu; jeśli nie, kolejny węzeł Salesforce tworzy Lead z nazwą profilu z payloadu. Ostatni węzeł Salesforce tworzy Task przy tym rekordzie, z treścią wiadomości w opisie i tematem informującym, że była to wiadomość z WhatsApp.

Gałąź weryfikacji odpowiada na GET od Meta, zwracając wartość hub.challenge jako zwykłą treść odpowiedzi. Bez niej Meta nie zacznie dostarczać wiadomości, a reszta przepływu będzie bezczynna.

Zadanie czy notatka: gdzie zapisywać wiadomość?

W większości zespołów lepszy jest Task, ponieważ trafia na oś czasu aktywności, którą handlowcy i tak czytają, i można go uwzględnić w raportach. Ustaw jego status na ukończony, żeby nie wyglądał jak otwarte zadanie do wykonania, i nadaj mu temat wskazujący kanał, dzięki czemu filtr aktywności z WhatsApp to jeden warunek.

Operacja Add note w węźle n8n pasuje do innego przypadku: podsumowania zamiast każdej wiadomości. Niektóre zespoły każą przepływowi zebrać wiadomości z całego dnia dla danego kontaktu i wieczorem zapisać jedną notatkę. Dzięki temu oś czasu pozostaje czytelna, gdy klient wysyła dwadzieścia krótkich linijek.

Niezależnie od wyboru zapisz w rekordzie identyfikator wiadomości z WhatsApp. Meta ponawia dostarczanie, a przepływ, który przed zapisem sprawdza, czy taki identyfikator już istnieje, nigdy nie zapisze tej samej wiadomości dwa razy.

Czy zespół nadal może odpowiadać z telefonu i czy Salesforce to zobaczy?

Tak, w obu przypadkach. Coexistence sprawia, że aplikacja WhatsApp Business nadal działa na tym samym numerze, więc osoby, które wczoraj odpowiadały klientom, robią to dalej. Gdy odpowiadają z aplikacji, Meta wysyła echo wychodzącej wiadomości na ten sam adres docelowy webhooka, w polu smb_message_echoes.

Dodaj w przepływie drugą ścieżkę dla tych ech i zapisuj je jako wychodzące Taski. Handlowiec, który otworzy leada, zobaczy wtedy po kolei zarówno pytanie, jak i odpowiedź udzieloną przez sklep, bez ręcznego kopiowania czatu.

Odpowiedzi wysyłane przez sam przepływ, przez węzeł HTTP Request skierowany do Cloud API, należy zapisywać w momencie wysłania. Przepływ ma już wtedy pod ręką treść i identyfikator rekordu.

Jak uniknąć zduplikowanych leadów?

Dopasowuj po znormalizowanym numerze telefonu, a nie po polu w takiej postaci, w jakiej wpisali je ludzie. Meta przekazuje nadawcę jako cyfry z kodem kraju i bez znaku plus. Pola telefonu w Salesforce zawierają to, co wpisała osoba tworząca rekord, ze spacjami, nawiasami i myślnikami.

Solidne rozwiązanie to własne pole tekstowe z numerem składającym się wyłącznie z cyfr, wypełniane przez przepływ przy tworzeniu leada oraz przez jednorazowe uzupełnienie dla istniejących rekordów. Zapytanie SOQL porównuje wtedy to pole na równość, co jest szybkie i dokładne.

Sprawdzaj także kontakty, nie tylko leady. Klient, który już został przekonwertowany, jest Contact, a przepływ szukający wyłącznie wśród leadów utworzy nowego leada dla każdego istniejącego klienta, który się odezwie.

Typowe błędy

• Przeszukiwanie wyłącznie obiektu Lead. Istniejący klienci to Contact i każdy, kto napisze, staje się zduplikowanym leadem.
• Zapisywanie wiadomości jako otwartych Tasków. Handlowcy dostają zadanie do wykonania przy każdej linijce klienta; przy tworzeniu ustaw status na ukończony.
• Pominięcie w przepływie gałęzi weryfikacji GET. Meta nigdy nie potwierdzi adresu docelowego i żadna wiadomość nie zostanie dostarczona.

Najczęściej zadawane pytania

Czytaj dalej