Помочь применить это руководство?Спросить команду DripTell
Статус шаблона изменился на одобренный. Хочется сразу добавить реальную аудиторию и нажать отправку. Но это слишком рано.
Одобрение означает, что шаблон прошел проверку Meta и его можно использовать. Оно не доказывает, что рабочие данные правильно подставятся в переменные, выберется нужный язык, события доставки попадут в вашу систему, ответ получит владелец, а автоматическая цепочка остановится после реакции клиента. Считайте одобрение разрешением начать сквозную проверку.
Одобрение начинает проверку запуска
Актуальная документация Meta о проверке шаблонов говорит, что одобренный шаблон получает статус Active с ожидающей оценкой качества, отображается как APPROVED в API и может отправляться. Изменение статуса также можно получить через webhook. Важная часть здесь заключается в том, что оценка качества еще ожидается. Meta приняла артефакт, но не проверила весь путь клиента.

Руководство Meta по качеству шаблонов объясняет, что новый шаблон начинает с неизвестной оценки. Затем она меняется по мере появления данных об использовании, обратной связи и вовлеченности. Позже шаблон может оказаться под угрозой паузы или отключения. Поэтому успешный тест подтверждает готовность сейчас, а не гарантирует ее навсегда.
| Доказательство | Что оно подтверждает | Чего оно не подтверждает |
|---|---|---|
| Одобренный статус | Указанные шаблон и язык можно отправлять | Корректность рабочих переменных |
| Контрольный получатель | Одно сообщение пришло в ожидаемом виде | Доступность для всей аудитории |
| Тестовый ответ | Входящий путь и владелец сработали один раз | Обработку каждого типа ответа |
| Малый контролируемый запуск | Реальный трафик прошел по задуманному пути | Неизменное качество в будущем |
Зафиксируйте точную версию запуска
Запишите имя шаблона, язык, категорию, версию, отправителя, триггер и правило аудитории. На время теста зафиксируйте их. Если один человек меняет автоматизацию, пока другой ее проверяет, положительный результат не показывает, какая версия действительно прошла тест.
- Точный одобренный артефактЗафиксируйте имя, язык, категорию, отправителя, триггер и правило аудитории.
- Реалистичные данныеПроверьте безопасные короткие, длинные, отсутствующие, медиа, ссылочные и кнопочные случаи.
- Контролируемая доставкаЗапускайте реальным событием и сохраняйте доказательства провайдера до получения.
- Ответ с владельцемДокажите, что обычные ответы попадают в нужную очередь и отменяют лишнее продолжение.
- Наблюдаемый выпускОткройте малую группу с ответственным, условием остановки и действием отката.
Для каждой переменной используйте реалистичные, но нечувствительные значения. Проверьте самое короткое ожидаемое значение, самое длинное безопасное, отсутствие необязательных данных, даты, валюты, ссылки, медиа и кнопки реального процесса. Здесь поможет руководство по переменным шаблона, потому что хороший пример при проверке не гарантирует удачную подстановку рабочих данных.
Прочитайте окончательное сообщение на телефоне получателя глазами клиента. Понятно ли, кто пишет и зачем? Каждое ли значение стоит на своем месте? Ведет ли действие к полезному следующему шагу? Если смысл сообщения приходится объяснять устройством теста, оно не готово.
Проведите один контролируемый сквозной тест
Выберите разрешенного внутреннего получателя, которому можно безопасно пройти точный рабочий путь. Запускайте его реальным бизнес-событием, а не удобной ручной копией. Напоминание должно начинаться событием записи, а уведомление о заказе подтвержденным состоянием заказа. Так вы проверяете выбор шаблона, языка, получателя и данных вместе.
Сохраните идентификатор запроса и события принятия, отправки, доставки, прочтения или ошибки, которые реально получает ваша система. Принятие запроса API не равно доставке клиенту. Руководство по отчетам о доставке помогает отделить события провайдера от бизнес-результата.
Повторите тест для значимых отказов. Попробуйте отсутствующие данные, недоступного получателя, истекшую ссылку, недоступное медиа и повторный триггер. Безопасным исходом может быть остановка и создание исключения с конкретным владельцем. Молчаливая отправка поврежденного сообщения не является запасным вариантом.
Проверьте ответ и правило остановки
Попросите тестового получателя отправить ответы, которые вероятны в реальной работе. Подтверждение, вопрос, просьба изменить запись и отказ от сообщений требуют разных действий. Каждый ответ должен оставаться рядом с исходным сообщением и контекстом клиента, попадать в правильную очередь и иметь ответственного владельца.
После этого проверьте дальнейшую автоматизацию. Ответ клиента должен отменять шаг, который больше не соответствует ситуации. После переноса записи нельзя отправлять старое напоминание. Отказ должен обновить исключение до постановки следующей кампании в очередь. Руководство по ответам на кампании и рабочее пространство кампаний полезны потому, что результатом должна быть управляемая беседа, а не только исходящее сообщение.
Если разговор принимает человек, убедитесь, что общий ящик показывает шаблон, ответ, источник и следующий шаг вместе. Проверка только исходящей стороны скрывает самый дорогой сбой.
Выпустите сообщение для малой группы
После контрольного теста выберите минимальную реальную когорту, которая выявит операционные проблемы без риска для всей аудитории. До запуска задайте состав группы, время, ожидаемый объем, владельца наблюдения, условия остановки и действие для отката.
Следите за ошибками доставки, неожиданным отображением, непониманием клиентов, ответами без владельца, дублями, отказами, текущим статусом и качеством шаблона. Не придумывайте универсальную норму. Сравнивайте данные с целью сообщения и обычным поведением этой аудитории.
Первый выпуск должен быть достаточно мал, чтобы человек мог прочитать реальные примеры. При корректной работе расширяйте аудиторию осознанно. При сбое остановите автоматизацию, сохраните доказательства, исправьте одну причину и повторите контрольный тест. Раздел шаблонов DripTell помогает держать одобренный шаблон рядом с кампанией и автоматизацией, но решение о выпуске все равно требует владельца.
Сохраните квитанцию запуска
Сохраните идентичность шаблона, класс тестового получателя, случаи для переменных, доказательство триггера, события провайдера, результаты ответа и остановки, когорту, владельца и решение. Это станет исходной точкой при изменении шаблона, качества или доставки.
Одобрение отвечает на вопрос, принимает ли Meta шаблон. Проверка выпуска отвечает на вопрос, безопасно ли весь процесс работает для реального клиента. Это разные решения.
Часто задаваемые вопросы
Можно ли сразу отправлять одобренный шаблон WhatsApp?
Его можно отправлять, но массовый запуск должен дождаться проверки триггера, переменных, отображения, доставки, маршрута ответа и правил остановки.
Нужны ли реальные данные клиента для первого теста?
Сначала используйте реалистичные нечувствительные значения и разрешенного внутреннего получателя. Малую реальную группу подключайте после успешного контроля и готовности наблюдения.
Что должно произойти после ответа тестового получателя?
Ответ должен остаться в исходной беседе, попасть ответственному владельцу и остановить дальнейшие шаги, которые больше не соответствуют состоянию клиента.
Когда шаблон готов к расширению?
Когда контрольный путь пройден, сбои имеют владельцев, малая группа ведет себя ожидаемо, а за статусом и качеством после расширения назначен ответственный.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники




