Архитектура: четыре звена одной цепи
Смысл всей схемы в том, что сообщение проходит через цепочку из четырёх узлов, и на каждом шаге к нему добавляется немного структуры, которой не было в сыром тексте. WhatsApp Cloud API — точка входа, она превращает входящее сообщение в HTTP-запрос на твой сервер. Claude — мозг посередине, он читает текст на человеческом языке и возвращает данные на языке программы: намерение, бюджет, срочность, рекомендованное действие. Слой скоринга — это просто набор условий вида «если намерение высокое и срочность выше четырёх, это горячий лид», который превращает JSON от Claude в конкретное действие. И CRM — хранилище, куда попадает уже размеченный контакт со всей историей.
Ключевая разница с типичной схемой на Zapier или Make в том, что здесь нет платного посредника между каждой парой шагов. Webhook и вызов Claude API можно написать в одном небольшом обработчике, который живёт на любом сервере с Node.js или Python: получил сообщение, отправил его в Claude, получил JSON, применил правило, записал в базу. Это не сложнее скрипта на полсотни строк, просто он должен быть постоянно включён и отвечать быстро, потому что WhatsApp ждёт подтверждения доставки за секунды, а не за минуты.
Звено первое: WhatsApp Cloud API, а не серый номер
Здесь стоит сразу закрыть вопрос, который всплывает первым: официальный ли это способ. Да, Cloud API — это продукт самой Meta, тот же WhatsApp Business Platform, через который работают крупные компании, а не обходной путь через эмуляцию личного аккаунта. Разница принципиальная: серый номер, подключённый через автоматизацию личного WhatsApp, рано или поздно банится, потому что нарушает условия использования обычного приложения. Cloud API — это отдельная инфраструктура с верифицированным бизнес-номером, официальной документацией и предсказуемым поведением.
Механика подключения простая на уровне идеи и муторная на уровне деталей: ты регистрируешь приложение в Meta for Developers, привязываешь к нему WhatsApp Business Account и номер телефона, получаешь токен доступа и настраиваешь webhook — HTTP-эндпоинт на своём сервере, на который Meta будет присылать уведомления о новых сообщениях. По официальной документации, каждое такое уведомление — это POST-запрос с JSON-телом, и твой сервер обязан ответить кодом 200 в течение нескольких секунд, иначе Meta будет повторять попытку с нарастающим интервалом до семи дней. Сам JSON выглядит примерно так:
{
"object": "whatsapp_business_account",
"entry": [
{
"id": "WHATSAPP_BUSINESS_ACCOUNT_ID",
"changes": [
{
"field": "messages",
"value": {
"messaging_product": "whatsapp",
"metadata": { "phone_number_id": "PHONE_NUMBER_ID" },
"contacts": [
{ "profile": { "name": "Имя клиента" }, "wa_id": "79161234567" }
],
"messages": [
{
"from": "79161234567",
"id": "wamid.XXXXXXXXXXXX",
"timestamp": "1751600000",
"type": "text",
"text": { "body": "Здравствуйте, сколько стоит консультация?" }
}
]
}
}
]
}
]
}Твой обработчик достаёт из этой структуры номер отправителя и текст сообщения, а дальше передаёт их следующему звену. Отдельно стоит помнить про верификацию webhook при первом подключении: Meta присылает GET-запрос с challenge-токеном, и сервер должен вернуть его обратно, только после этого начинают идти реальные события.
Звено второе: Claude как квалификатор лида
Дальше начинается та часть, где раньше сидел человек. Текст сообщения из webhook отправляется в Claude вместе с системной инструкцией, которая фиксирует, что именно нужно вернуть, и в каком виде. Формулировка системного промпта здесь важнее всего остального кода, потому что от неё зависит, получишь ты предсказуемый JSON или обрывок рассуждений вперемешку с данными:
Ты - квалификатор входящих лидов для [ниша бизнеса].
Тебе приходит сообщение клиента из WhatsApp и, если есть,
краткая история переписки.
Проанализируй сообщение и верни ТОЛЬКО валидный JSON,
без markdown-разметки, без пояснений до или после, строго
в следующем формате:
{
"намерение": "высокое" | "среднее" | "низкое",
"бюджет": "<упомянутая сумма или диапазон>" или null,
"срочность": число от 1 до 5,
"действие": "назначить" | "прогреть" | "отсеять"
}
Если в сообщении нет данных для поля - ставь null,
а не выдумывай значение.На конкретное сообщение «Здравствуйте, сколько стоит консультация, хочу решить вопрос на этой неделе» Claude должен вернуть что-то вроде {"намерение": "высокое", "бюджет": null, "срочность": 4, "действие": "назначить"}. Модель здесь не заменяет продавца и не ведёт переговоры, она делает ровно одну вещь: превращает разговорный текст в структуру, по которой дальше можно принимать решения программно. Именно поэтому системная инструкция такая жёсткая по формату — любой лишний текст в ответе ломает автоматический парсинг JSON на следующем шаге.
Звено третье: скоринг и маршрутизация
Получив JSON, обработчик применяет простое правило и решает, что делать с контактом дальше. Три исхода покрывают почти все случаи. Лид с высоким намерением и срочностью четыре-пять уходит в категорию горячих: система шлёт уведомление ответственному менеджеру и предлагает клиенту слоты для встречи, потому что здесь цена промедления выше цены ошибки. Лид со средним намерением или найденным, но небольшим бюджетом попадает в тёплую категорию — его не тревожат немедленно, а ставят в цепочку прогрева: серию сообщений с объяснением ценности продукта и ответами на типичные возражения, растянутую на несколько дней. Лид с низким намерением или явным отсутствием интереса получает вежливый автоответ и уходит в базу без участия человека, потому что тратить на него внимание сейчас нерационально, а вот вернуться к нему через рассылку через месяц вполне может иметь смысл.
Смысл этого распределения в том, что человек в этой схеме видит только то, что действительно требует его времени: горячие лиды и, изредка, спорные случаи, которые модель разметила неуверенно. Всё остальное происходит без него, и именно это освобождает те самые три часа, которые раньше уходили на ручную сортировку.
Лиды размечены. А что дальше — как довести их до оплаты?
Квалификация — только вход в воронку. Дальше нужны прогрев, лид-магнит и платёжка, которые превращают тёплый тег в оплату. Собираем весь путь на практикуме.
Что за практикум →С чего начать
Проще всего собрать систему по шагам, проверяя каждый на своём номере, прежде чем пускать реальный трафик. Сначала зарегистрируй приложение в Meta for Developers и подключи тестовый номер: на старте Meta сама выдаёт тестовый бизнес-аккаунт с возможностью слать сообщения на несколько проверочных номеров, этого достаточно, чтобы отладить весь путь. Дальше подними webhook-обработчик на любом сервере, который у тебя уже есть, и проверь, что он отвечает 200 и видит входящие сообщения в логах. После этого подключи вызов Claude API с системным промптом из раздела выше и убедись, что на десяток разных тестовых сообщений модель стабильно возвращает валидный JSON. И только когда вся цепочка от сообщения до записи в CRM проверена на себе, переводи бизнес-номер из тестового режима в боевой и подключай постоянный токен доступа вместо временного.
Отдельно стоит заложить время на то, что в реальном потоке сообщений будут смешанные и неполные фразы, голосовые и стикеры, поэтому первую неделю стоит смотреть логи вручную и донастраивать промпт под то, как реально пишут твои клиенты, а не под идеальные тестовые фразы.
Источники
Факты в этом гайде — из официальной документации Meta for Developers: