WhatsApp Catalog API: процесс после выбора товара

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

Это руководство отвечает именно на операционный вопрос. Техническими границами служат актуальные объекты сообщений и webhook от Meta, а результатом становится процесс, который может проверить коммерческая команда. Главное правило: каталог — поверхность для выбора товара, а webhook — свидетельство намерения клиента. Ни то ни другое не доказывает, что товар зарезервирован, платёж получен или исполнение началось.

Что на самом деле предоставляет WhatsApp Catalog API

В официальной коллекции Meta описаны два полезных формата интерактивных сообщений. Сообщение с одним товаром использует type: interactive, подтип product, catalog_id и product_retailer_id. Сообщение с несколькими товарами использует подтип product_list, один catalog_id и разделы с позициями, идентифицированными через product_retailer_id (запрос одного товара, запрос списка товаров).

Meta также документирует шаблон каталога с кнопкой CATALOG. Такой шаблон открывает каталог компании в WhatsApp, но не заменяет товарную базу, учёт остатков, управление заказами или оплату (запрос шаблона каталога). Формат следует выбирать по задаче клиента, а не по эффектности представления.

Входящая сторона не менее важна. Запрос о товаре возникает, когда человек отвечает на товарное сообщение или выбирает «Message Business» на странице товара. Контекст webhook может содержать referred_product.catalog_id и referred_product.product_retailer_id (webhook запроса о товаре). Объект заказа может включать catalog_id, product_items, количество, цену, валюту и product_retailer_id каждой позиции (справочник объекта сообщения). Эти поля показывают выбор клиента; обещание и следующий шаг по-прежнему определяют ваши системы.

Создайте единый операционный контракт от каталога до заказа

Надёжный процесс начинается с одного письменного соглашения между маркетингом, поддержкой, коммерческими операциями и разработкой. В нём должны быть определены смысл и владелец пяти записей:

• Клиент — wa_id, телефон или внутренний contact_uuid: Связать личность с историей диалога
• Каталог — catalog_id: Определить источник товара в сообщении
• Товар — product_retailer_id: Сопоставить позицию WhatsApp со стабильным SKU
• Взаимодействие — ID исходящего сообщения и входящего webhook: Восстановить последовательность и убрать дубли
• Рабочая задача — ID запроса или заказа, состояние и владелец: Провести намерение через проверку, восстановление и завершение

Один статус не должен означать сразу несколько вещей. «Заказ получен» — не то же самое, что «оплачен», «зарезервирован» или «отправлен». Полезная минимальная модель: received → validating → reserved → confirmed → fulfilled, а явные выходы — needs_customer, out_of_stock, cancelled и failed. Если оплатой или исполнением владеет другая система, храните её ссылку рядом с записью сообщения, а не назначайте WhatsApp системой учёта.

Используйте семь этапов после выбора товара

1. Проверьте допустимость до отправки. Контакт должен иметь право получить нужное сообщение, товар должен быть активным, retail ID — однозначно соответствовать актуальному SKU, а формат — подходить задаче. Один товар обычно яснее, когда предмет уже известен. Небольшой список полезен для сравнения. Шаблон каталога подходит для возобновления знакомства только при допустимости шаблона и получателя.

2. Запишите отправленное. Сохраните клиента, catalog_id, все product_retailer_id, ID сообщения, язык, снимок цены при необходимости и источник кампании или сценария. Такой журнал отвечает на вопросы «какую цену видел клиент?» и «почему был предложен этот товар?».

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

4. Проверяйте до обещания. Найдите retail ID в текущей товарной системе. Проверьте возможность продажи, цену, валюту, остаток или доступную мощность, правила доставки или самовывоза и вариант, который не был зафиксирован сообщением. Так устаревший каталог становится управляемым исключением, а не нарушенным обещанием.

5. Резервируйте и подтверждайте осознанно. Если бизнес резервирует товар, создайте бронь в системе остатков и назначьте срок. Только затем сообщайте, что именно удерживается, до какого времени и какое действие завершает покупку. Если резерв невозможен, скажите об этом прямо.

6. Считайте webhook заказа запросом на обработку. Проверьте позиции, количество, валюту и актуальную сумму, устраните дубль, затем создайте или обновите заказ в коммерческой системе. Несовпадения должны идти в очередь исключений с ответственным сотрудником. Сам payload заказа не доказывает оплату или физическое исполнение.

7. Замкните цикл. Запишите итог в хронологию разговора: подтверждено, заменено, отменено, получено, отправлено или не выполнено. Уведомите клиента допустимым способом, сохраните ответственного и причину замены или отмены.

Реальный пример: самовывоз из садового центра

Клиент спрашивает о двухлитровом горшке розмарина. Команда отправляет сообщение с одним товаром, где product_retailer_id соответствует herb-rosemary-2l. Ответ клиента приходит с тем же товаром в webhook. Сценарий привязывает диалог к правильному контакту и направляет его в очередь самовывоза.

До обещания служба остатков проверяет точный SKU в выбранной точке. При наличии система создаёт резерв на 90 минут, а оператор подтверждает магазин, количество, цену и срок. Если клиент отправляет корзину каталога, обработчик снова проверяет товар, устраняет повтор webhook и создаёт рабочую задачу. Самовывоз завершён лишь тогда, когда операционная система магазина фиксирует передачу.

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

Выбирайте формат по стоимости решения

Сообщение с одним товаром подходит, если клиент уже назвал позицию, оператор продолжает точный запрос или одной рекомендации нужен понятный следующий шаг. Сравнивать проще, а referred-product context легче интерпретировать.

Список товаров применяйте, когда нужно сравнить небольшую группу с общим ограничением: совместимые запчасти, три доступных размера или короткую подборку под известный бюджет. Не выгружайте весь магазин в каждый раздел. Чем больше вариантов, тем выше вероятность изменения цены, остатка или владельца до ответа.

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

Спроектируйте контроль отказов до запуска

Самый опасный сбой — нестабильный product_retailer_id. Считайте его постоянным интеграционным ключом, а не подписью. При смене внутренних SKU используйте явное сопоставление или миграцию; нельзя отдавать старый ID другому товару.

Обработка webhook должна быть идемпотентной. Храните ID события или сообщения, чтобы повторная доставка была безопасной. Неизвестный товар, неверное количество, несовпадение валюты, отсутствующий контакт и тайм-аут следующей системы должны иметь именованные состояния. Каждому нужны очередь, владелец, срок реакции и разрешённый ответ клиенту.

Учтите границу сервисного окна. На текущей странице разработчиков DripTell указано, что отправка товара может вернуть 422, когда 24-часовое окно обслуживания закрыто (API DripTell). Значит, рабочему процессу нужен допустимый шаблон или решение человека, а не бесконечные повторные попытки.

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

Измеряйте путь, а не только объём сообщений

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

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

Сопоставьте процесс с DripTell

Опубликованные возможности DripTell для WhatsApp включают торговые каталоги, товарные сообщения, общий inbox, маршрутизацию, контекст клиента, заметки и последующие сценарии (канал WhatsApp). В документации API указан /api/v1/send/product для одного и нескольких товаров с catalog_id, product_retailer_id или products и phone либо contact_uuid; заказы из корзины каталога отражаются в истории WhatsApp commerce (API для разработчиков).

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

Запускайтесь с доказательным набором из десяти случаев

До масштабирования проверьте: один допустимый товар; допустимый список; запрос о товаре; корзину с количеством два; повтор webhook; неизвестный retailer ID; старую цену или валюту; отсутствие товара после выбора; закрытое сервисное окно; тайм-аут системы заказов. В каждом случае проверьте сообщение клиенту, сохранённые ID, владельца, переход состояния, поведение повторов и финальное доказательство исполнения.

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