WhatsApp Coexistence: как сохранить приложение при подключении Cloud API

WhatsApp Coexistence позволяет подходящей компании сохранить действующий номер в приложении WhatsApp Business и одновременно подключить его к Cloud API. Это снимает жёсткий выбор между приложением и API, но не делает два интерфейса одинаковыми.

В актуальной документации Meta по подключению пользователей WhatsApp Business app описана гибридная схема: недавние личные чаты можно синхронизировать, новые сообщения — зеркалировать, а приложение продолжает работать. Там же указаны требования, фиксированный предел пропускной способности и существенные различия функций.

Поэтому покупателю недостаточно спросить: «Можно ли оставить номер?» Нужен другой вопрос: «Сможет ли команда вести одни отношения с клиентом через два интерфейса без двойных ответов, невидимой работы и неясного выхода?» Этот чек-лист помогает ответить до подключения рабочего номера.

Что меняет coexistence — и чего не меняет

В стандартном Cloud API платформа становится рабочим интерфейсом для сообщений, проходящих через API. При coexistence приложение WhatsApp Business остаётся вторым рабочим интерфейсом того же номера. Владелец может отвечать с телефона, пока отдел продаж или поддержки работает в общей платформе.

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

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

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

Общий WhatsApp inbox может объединить владельца и историю поддерживаемых разговоров, но события со стороны приложения всё равно нужно проверить для выбранного способа подключения.

Пройдите проверку условий до обещания запуска

Поток Meta для пользователей бизнес-приложения — не универсальный переключатель в любом аккаунте Cloud API. Официальные требования сейчас указывают WhatsApp Business app версии 2.24.17 или новее. Подключающая сторона должна уже быть Solution Partner или Tech Provider, уметь работать с Cloud API, принимать нужные webhooks и использовать Embedded Signup с session logging.

Для покупателя это пять предварительных вопросов:

1. Номер действительно работает в WhatsApp Business app? Не путайте бизнес-приложение с обычным WhatsApp или номером в несовместимой конфигурации.
2. Провайдер поддерживает именно этот поток сегодня? Поддержка Cloud API не равна возможности подключить существующего пользователя приложения через coexistence.
3. Кому принадлежат активы Meta? Уточните business portfolio, WhatsApp Business Account, номер, display name, платёжную связь или credit line.
4. Провайдер докажет готовность webhooks? История, контакты и сообщения из приложения зависят от событий `history`, `smbappstatesync` и `smbmessage_echoes`.
5. Нагрузка совместима с режимом? Meta указывает фиксированные 20 сообщений в секунду для номера, работающего одновременно в приложении и Cloud API. Не считайте его профиль масштабирования равным стандартному номеру Cloud API.

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

Зафиксируйте границы функций до подключения

Главная ошибка — считать, что всё доступное в приложении автоматически доступно через Cloud API. Таблица Meta конкретнее.

• Личные чаты: можно синхронизировать сообщения за последние шесть месяцев. Новые входящие и исходящие сообщения зеркалируются между Cloud API и приложением.
• Контакты: синхронизируются контакты с номером WhatsApp.
• Группы: продолжают работать в приложении, но не поддерживаются и не синхронизируются через Cloud API в этом режиме.
• Исчезающие сообщения, view once и live location: после подключения отключаются или не поддерживаются в личных чатах.
• Списки рассылки: новые списки в приложении создать нельзя, существующие становятся read-only. Кампания API — отдельный процесс, а не продолжение списка приложения.
• Голосовые и видеозвонки: работа приложения не меняется, но звонки не становятся функцией Cloud API в таблице coexistence.
• Инструменты приложения: каталог, заказы, статус, приветствие, away message, быстрые ответы и labels остаются инструментами приложения и не превращаются автоматически в возможности API.

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

Рабочее пространство WhatsApp в DripTell поддерживает официальные разговоры WhatsApp Business Platform, шаблоны, кампании, автоматизацию и командное владение. Это не означает автоматическую пригодность любого существующего номера приложения; номер и маршрут подключения проверяются отдельно.

Назначьте владельца каждого действия

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

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

Для каждого зеркального сообщения рабочий процесс должен:

1. привязать событие к правильному клиенту и разговору;
2. обновить владельца или статус без создания дубликата;
3. остановить или пересчитать автоматизацию, которая иначе вмешается в живой диалог.

Техническое эхо не равно операционному владению. Событие `smbmessageechoes` доказывает, что сообщение приложения дошло до webhook. Оно не доказывает, что агент его увидел, цепочка остановилась или CRM-исход изменился.

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

Проведите пилот из десяти сценариев

Завершение Embedded Signup ещё не означает успешную эксплуатацию. До роста объёма выполните контролируемый пилот.

1. Откройте личный чат из шестимесячного окна и проверьте ожидаемую историю.
2. Начните новый входящий личный разговор и проверьте оба разрешённых интерфейса.
3. Ответьте из приложения и убедитесь, что платформа получила правильное эхо без второго контакта.
4. Ответьте из платформы и найдите сообщение в том же чате приложения.
5. Отправьте обычный поддерживаемый media message и проверьте содержание и статус.
6. Измените тестовый контакт в приложении и проверьте обработку события состояния.
7. Ответьте во время ожидания автоматического follow-up и докажите остановку до отправки.
8. Откройте группу и убедитесь, что платформа не выдаёт её за синхронизированную.
9. Смоделируйте сбой: задержите или отклоните webhook в тестовой среде и проверьте видимость исключения.
10. Пройдите документированный offboarding и перечислите, что экспортируется, переназначается или настраивается заново.

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

Поймите, когда coexistence — неправильная архитектура

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

Выбирайте стандартный Cloud API, если:

• каждое взаимодействие обязано попадать в одну управляемую очередь;
• работа из приложения создаёт недопустимые пробелы аудита или назначения;
• группы — ключевой процесс, которым должна управлять команда платформы;
• нагрузка превышает документированный предел coexistence;
• провайдер не показывает текущую пригодность и поведение функций;
• нет владельца телефона, активности приложения или переподключения;
• синхронизацию считают резервной копией вместо хранения записей в правильной системе.

Безопаснее архитектура, которую команда может объяснить во время инцидента. Приложение не даёт преимущества, если создаёт второй невидимый inbox.

Измеряйте целостность работы, а не только подключение

Проверяйте согласованность гибридного процесса:

• доля ответов из приложения, появившихся в платформе;
• доля ответов платформы, видимых в нужном чате приложения;
• дубликаты контактов и разговоров;
• автоматические шаги, корректно остановленные ответом;
• разговоры без владельца и время принятия ответственности;
• ошибки message echo и синхронизации истории;
• app-only разговоры, потребовавшие ручной передачи;
• переподключения, offboarding и необъяснимые отключения;
• исходы, записанные в правильной карточке клиента.

Разделяйте «сообщение пришло» и «работа получила владельца». Первое — транспортная метрика, второе — операционная. Проверяйте обе в пилоте и после существенного изменения Meta или провайдера.

Чек-лист покупателя для coexistence

Попросите провайдера показать точный маршрут планируемого номера. Демонстрация должна включать пригодность, владение активами, Embedded Signup, объём истории, ответ из приложения, ответ из платформы, остановку автоматизации, границы групп, ожидаемую пропускную способность, видимость сбоя и offboarding.

Попросите ограничения письменно. Формулировки «ничего не изменится», «вся история синхронизируется» и «app равен API» противоречат собственной таблице Meta.

Принесите один реальный клиентский путь на демонстрацию DripTell. Отметьте, где начинается разговор, кто отвечает в приложении, кто владеет общей очередью, какое событие останавливает автоматизацию и где хранится исход. Правильным решением может быть coexistence, стандартный Cloud API или узкий пилот. Цель — сохранить непрерывность для клиента и добавить операционный контроль.

Частые вопросы

Может ли один номер работать в WhatsApp Business app и Cloud API?

Да, если бизнес и провайдер выполняют текущие требования Meta, а номер подходит для этого потока. Не каждый Cloud API и не каждый номер автоматически совместимы.

Синхронизируется ли вся история WhatsApp?

Нет. Meta описывает личные сообщения за последние шесть месяцев. Групповые чаты через Cloud API в coexistence не синхронизируются.

Можно ли продолжать пользоваться списками рассылки приложения?

Существующие списки становятся read-only, а новые после подключения создать нельзя. Кампании Cloud API работают отдельным процессом платформы.

Кто должен владеть разговором?

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

Гарантирует ли DripTell coexistence для любого номера?

Универсальную гарантию пригодности давать нельзя. DripTell поддерживает официальные процессы WhatsApp Business Platform, а coexistence нужно подтвердить для конкретного номера, активов Meta и маршрута подключения до планирования запуска.