Передача диалогов WhatsApp в Salesforce с номера Coexistence

Как выглядит рабочий процесс n8n?

Четыре узла подряд плюс ветка верификации, которая нужна для любого вебхука Meta.

Узел Webhook принимает POST-запрос, который Meta отправляет на каждое сообщение. Узел Salesforce выполняет SOQL-запрос и ищет Lead или Contact, у которого телефон совпадает с телефоном отправителя. Узел IF разделяет потоки по тому, вернулось ли что-нибудь: если да, рабочий процесс передаёт дальше id записи; если нет, узел Salesforce создаёт Lead с именем профиля из тела запроса. Последний узел Salesforce создаёт Task для этой записи: текст сообщения попадает в описание, а тема указывает, что это сообщение WhatsApp.

Ветка верификации отвечает на GET-запрос Meta значением hub.challenge в виде обычного тела ответа. Без неё Meta не начнёт доставку, и остальная часть рабочего процесса будет простаивать.

Task или заметка: что лучше хранит сообщение?

Для большинства команд Task, потому что он попадает в ленту активности, которую менеджеры по продажам и так читают, и по нему можно строить отчёты. Установите статус «выполнено», чтобы он не выглядел как открытое дело, и добавьте тему с названием канала: тогда фильтр по активности WhatsApp сводится к одному условию.

Операция Add note в узле n8n подходит для другого случая: когда нужна сводка, а не каждое сообщение. Некоторые команды собирают сообщения за день по каждому контакту и вечером записывают одну заметку. Так лента остаётся читаемой, даже если клиент прислал двадцать коротких строк.

Что бы вы ни выбрали, записывайте id сообщения WhatsApp в запись. Meta повторяет доставку, а рабочий процесс, который перед записью проверяет наличие такого id, никогда не залогирует одно и то же сообщение дважды.

Может ли команда отвечать с телефона и увидит ли это Salesforce?

Да, и то и другое. Coexistence сохраняет работу приложения WhatsApp Business на том же номере, поэтому сотрудники, которые отвечали клиентам вчера, продолжают это делать. Когда они отвечают из приложения, Meta отправляет эхо исходящего сообщения на тот же адрес вебхука, в поле smb_message_echoes.

Добавьте в рабочий процесс второй путь для этих эхо-сообщений и записывайте их как исходящие Task. Тогда менеджер, открывший лид, увидит по порядку и вопрос, и ответ магазина, и никому не придётся копировать переписку вручную.

Ответы, которые рабочий процесс отправляет сам через узел HTTP Request к Cloud API, нужно записывать в момент отправки. Текст и id записи у процесса уже есть.

Как избежать дублей лидов?

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

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

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

Распространённые ошибки

• Поиск только по объекту Lead. Существующие клиенты хранятся как Contact, и каждый из них, написав вам, становится дублем лида.
• Запись сообщений как открытых Task. Менеджеры получают дело на каждую реплику клиента; при создании ставьте статус «выполнено».
• Пропуск ветки верификации GET в рабочем процессе. Meta не подтверждает адрес назначения, и ни одно сообщение не доставляется.

Часто задаваемые вопросы

Читайте дальше