От входящей заявки до выкупа. От первого полученного заказа до следующей покупки.
01
AI-ОТДЕЛ ОБРАБОТКИ ВХОДЯЩИХ ЗАКАЗОВ
Подтверждение заказа без очереди к менеджеру
Суть концепции
Покупатель оставляет заявку на сайте, и она попадает в CRM. Обычно менеджер связывается с ним, уточняет заказ и предлагает дополнительные товары. Автор предлагает передать типовую часть этой работы AI-агенту в мессенджере, оставив людям случаи, которые автоматизация не закрыла.
Это система обработки уже входящего спроса: её задача — подтвердить намерение клиента, оформить заказ и увеличить его ценность через уместную допродажу.
Как проходит заказ
Заявка поступает в CRM. Система получает данные клиента и выбранного товара.
AI начинает диалог. В описанном пилоте используется Telegram: агент подтверждает заказ и ведёт продажу.
Заказ оформляется. После подтверждения создаётся ТТН — накладная для отправки, затем идут уведомления о доставке.
Сложный случай получает менеджер. Автор обсуждает передачу человеку, если подтверждение не произошло примерно за час.
В описании видео говорится о передаче AI около 30% потока за неделю и улучшении показателей маржинальности и подтверждения. Доступный материал не даёт полноценной сравнительной таблицы или методики измерения.
ДАЛЬНЕЙШИЙ ПЛАН
Несколько каналов и A/B-тесты
Расширить коммуникацию на Viber и WhatsApp, сравнить сценарии и порядок контактов. Обсуждаемый ориентир автоматизации 70–90% — цель развития, а не уже достигнутый результат.
Продукт принимает входящий спрос, выбирает доступный способ контакта, помогает принять решение и сопровождает исполнение. У каждого контакта есть причина, следующий шаг и условие остановки.
Вход в систему: пять маршрутов
Заявка с сайта. На checkout клиент выбирает удобный канал. Экран «Спасибо» содержит сумму, статус и кнопку быстрого подтверждения. Telegram-ссылка передаёт непрозрачный токен заказа; сайт тоже позволяет подтвердить покупку без обязательного перехода в мессенджер.
Разрешённый первый контакт по номеру. При отсутствии Telegram-chat_id система выбирает подключённый Viber Business Messages, SMS со ссылкой или телефонный звонок с учётом выбора клиента. Ссылка ведёт на короткую страницу продолжения с выбором «чат / подтвердить / перезвонить».
Входящий чат из рекламы. Объявление ведёт прямо в брендовый диалог. Агент выясняет товар и минимальные данные, создаёт черновик в CRM и продолжает сценарий. Источник и рекламная кампания сохраняются, чтобы сравнивать качество трафика.
Входящий звонок. Голосовой ассистент уточняет намерение, находит или создаёт заказ и предлагает отправить итог в согласованный мессенджер/SMS. Он не заставляет звонящего переходить в чат для завершения покупки.
Продолжение старого контакта. Клиент возвращается по ссылке, пишет в чат или звонит повторно. Система восстанавливает текущий заказ и незакрытый вопрос. Если это уже новая повторная покупка, её инициирование относится к LTV-продукту; исполнение заказа использует этот же контур.
Измеряем каждую ступень: лид → доступный канал → доставка → ответ → уточнение → подтверждение → оплата, если требуется → отправка → выкуп. Провал между ступенями должен иметь причину, а не общий статус «не купил».
Голос: сообщения и живой телефонный диалог
Голосовые в мессенджере
Входящее аудио распознаётся, сохраняется транскрипция, намерение попадает в тот же сценарий заказа. При низкой уверенности ассистент переспрашивает конкретное поле. Адрес, количество и итоговая сумма дополнительно подтверждаются текстом.
Исходящий ответ может быть коротким синтезированным голосовым сообщением, если клиент предпочитает аудио. Рядом — текстовая сводка и кнопки. Видео-кружки и демонстрации товара используем только там, где формат действительно объясняет товар; не маскируем AI под конкретного сотрудника.
Телефония/SIP → двусторонний аудиопоток → распознавание речи или речевая модель → сценарий и инструменты CRM → синтез ответа. Телефонный канал — отдельная интеграция; отправка voice в Telegram не даёт боту возможность звонить пользователю.
На старте ассистент называет магазин и обозначает, что он виртуальный помощник, спрашивает, удобно ли обсудить заявку. Умеет замолчать при перебивании, повторить непонятое, назначить звонок и перевести на сотрудника с краткой сводкой. Запись и хранение разговора настраиваются под действующие требования бизнеса.
Задачи голосового пилота: подтверждение простого заказа, ответ на один вопрос, согласование времени, передача человеку. Продажа сложного товара и конфликт сначала остаются менеджерам. Тестируем перебивания, шум, смешение русского/украинского, цифры, паузы, обрыв связи и автоответчик. При техническом сбое не притворяемся, что заказ оформлен.
Мощность голоса считается отдельно. Пример: 300 попыток/день × 3 минуты занятости линии = 900 минут; за 10 часов — 1,5 занятой линии в среднем. При пике ×4 ориентир — 6 одновременных линий плюс резерв. Это расчёт по допущениям: фактическая длительность включает дозвон, а лимиты оператора и модели проверяются отдельно.
Матрица поведения: решение для каждого исхода
Тайминги ниже — предлагаемые настройки пилота. Действие выбирает сценарный движок по состоянию заказа, последнему ответу, разрешённым каналам и общей истории контактов.
01
Канал недоступен / сообщение не доставлено
Проверить тип ошибки. Для постоянной недоступности выбрать другой разрешённый канал или звонок; для временного сбоя повторить техническую отправку.
Правило: Не считать техническую попытку контактом с клиентом. Не запускать все каналы одновременно.
02
Сообщение доставлено, ответа нет
Через 15 минут — одно короткое напоминание с действием. Через 45–60 минут в рабочее время — звонок AI или менеджера по выбранной стратегии.
Правило: Это начальная гипотеза таймингов. Наличие статуса «прочитано» зависит от канала; отсутствие статуса не означает, что сообщение не читали.
03
Открыл Telegram, но не нажал Start
Заказ остаётся без привязанного чата. На странице заказа сохраняется подтверждение на сайте и заказ звонка; допустимое SMS/Viber содержит ссылку на продолжение.
Правило: Нельзя считать открытие ссылки согласием или успешным запуском бота.
04
Ответил: сейчас неудобно
Спросить удобное время и канал одним вопросом. Создать конкретную задачу callback_at, отменить текущую цепочку.
Правило: Не отправлять напоминания до согласованного времени. Учитывать часовой пояс.
05
Задаёт вопросы, но не принимает решение
Выделить один барьер: цена, доставка, доверие, пригодность товара, необходимость покупки. Ответить по базе знаний и предложить следующий небольшой шаг.
Правило: После двух циклов без прогресса предложить человека или паузу вместо повторения скрипта.
06
Дорого
Уточнить, сравнивает ли человек цену или не подходит бюджет. Показать ценность, меньший комплект либо разрешённую альтернативу.
Правило: Скидка — только по правилам маржи; не награждать каждый отказ автоматическим снижением цены.
07
Не доверяет магазину / хочет гарантии
Дать проверяемые условия оплаты, возврата, доставки, данные магазина и реальные материалы о товаре. Предложить менеджера.
Правило: Никаких вымышленных отзывов, гарантий результата и искусственного дефицита.
08
Не подходит товар / нет в наличии
Выяснить требование, предложить доступную совместимую альтернативу с явной разницей цены; если её нет — завершить или согласовать уведомление.
Правило: Не заменять позицию без подтверждения покупателя и не обещать неизвестную дату поставки.
09
«Подумаю» / сравнивает предложения
Спросить, какой вопрос остался и когда уместно вернуться. Если клиент не выбирает время — одно согласованное завершение диалога и пауза.
Правило: Отсутствие покупки не равно согласию на бессрочный прогрев.
10
Пропал после ответа / после предложения
Напоминание продолжает последнюю тему: «Оставить первоначальный заказ без набора?» или «Нужна помощь с доставкой?».
Правило: Не начинать знакомство заново. При отказе от допродажи не возвращать её следующим сообщением.
11
Хочет купить, но не проходит оплата
Проверить статус платежа сервером, предложить действующую ссылку или разрешённый способ оплаты; передать техническую проблему.
Правило: Не запрашивать реквизиты карты в переписке. Повторная ссылка не должна создавать второй заказ.
12
Подтвердил / оплатил
Остановить acquisition-цепочку, записать результат, оформить отправку и переключить коммуникацию на обслуживание заказа.
Правило: Подтверждение, оплата и выкуп — разные события. Звонок «подтвердить» после оплаты не нужен.
13
Отказался / просит не писать
Зафиксировать причину и область отказа. Остановить соответствующие продажи во всех каналах; для полного отказа — исключить дальнейшие инициативные контакты.
Правило: Не переносить человека в другой канал для обхода отказа. Сервисные обращения об уже оформленном заказе обрабатываются отдельно.
14
Не тот номер / другой человек
Закрыть контакт для этого заказа, не раскрывать его детали и поставить задачу исправления данных.
Правило: Не связывать чужой чат с заказом только по совпадению имени.
15
Просит менеджера / жалуется / AI не уверен
Мгновенно передать контекст человеку, назвать реалистичный срок ответа. При отсутствии оператора согласовать обратный звонок.
Правило: AI блокирует самостоятельные ответы до возврата управления; не держать клиента в бесконечной очереди.
16
Не ответил на звонок / занято
Записать исход, предложить выбрать время текстом, если канал доступен. Возможна одна следующая попытка в другое допустимое время.
Правило: Автоответчик — отдельный исход; не зачитывать адрес или корзину третьим лицам. Лимит попыток считается по всем каналам.
17
Посылка готова к выдаче, но не забрана
Отправить сервисное уведомление с точкой выдачи и сроком, при необходимости уточнить препятствие через согласованный канал.
Правило: Не смешивать получение заказа с новой допродажей; при возврате оформить причину и поддержку.
Единый бюджет контактов
Начальная гипотеза для неотвечающего лида: первый контакт и максимум два дополнительных инициативных касания за первые 24 часа суммарно по каналам. Одна из попыток может быть звонком. Ответы в активном разговоре не считаются напоминаниями. Дальше — пауза или индивидуально согласованное время. Приоритет имеют выбранное клиентом время, отказ, рабочие часы и доступность менеджера.
Это ограничение не универсальная «правильная частота»: его проверяем по ответам, выкупу, стоимости и жалобам. Планировщик непосредственно перед отправкой повторно читает состояние: клиент уже ответил, заказ изменился или менеджер взял его — задача отменяется.
Допродажа: отдельный движок выбора предложения
Сначала пригодность основного товара. Определяем потребность и убеждаемся, что человек понимает предложение. Когда есть нерешённая претензия, недоверие или риск ошибочного выбора, предложение доптовара откладывается.
Сформировать кандидатов. Комплект из нескольких единиц, полезный сопутствующий товар, больший объём либо более подходящая версия. Правила учитывают категорию, совместимость, остатки, историю покупок, сроки доставки, бюджет и ограничения акций.
Отсечь невыгодное. Рассчитать чистую дополнительную маржу после скидки, дополнительной логистики и ожидаемых возвратов. Нельзя предлагать комплект с отрицательным вкладом только ради среднего чека.
Выбрать один лучший вариант. На старте — проверяемая таблица «основной SKU → предложение → основание → цена → минимальная маржа». Позже ранжирование обучается на экспериментальных данных. Модель формулирует объяснение; товар и цену определяет сервис.
Предложить в подходящий момент. После ответа на основной вопрос, перед финальной сводкой: «Для [задача] можно добавить [товар] за [доплата]. Общая сумма будет [итог]. Добавить или оставить исходный заказ?» Оба выбора одинаково понятны.
Развилка ответа. «Да» — обновить черновик и показать новый итог; «дорого» — одна допустимая альтернатива, если клиент хочет; «нет» — сразу завершать основной заказ; молчание — не добавлять товар, сохранить исходную корзину и уточнить основной заказ.
После подтверждения. До сборки возможное изменение оформляется отдельным явным согласием с повторной проверкой цены и остатков. После отправки не создаём скрытую вторую посылку. Следующее предложение после получения относится к LTV и проходит его правила.
Как оценить эффект допродажи
Прибыль с дополнительного товара может быть перекрыта потерянными основными заказами. Сравниваем весь назначенный поток: общую маржу на лид, выкуп и возвраты, а затем долю принятия предложения и средний чек. Группы «без предложения», «комплект», «сопутствующий товар» должны иметь одинаковый принцип распределения клиентов.
Что видит руководитель
Воронка по каналу, бренду, источнику рекламы и эксперименту; причины потерь; ожидание клиента и менеджера; качество распознавания голоса; доля прерываний, переводов и сбоев; стоимость сообщений, разговоров, модели и труда. Отдельно — незавершённые задачи, конфликтующие изменения заказа и отправления с ошибкой.
Приёмка перед масштабированием: повтор webhook не дублирует заказ; два сообщения обрабатываются последовательно; оплата отменяет напоминание; отказ выключает продажи во всех каналах; человек перехватывает диалог; оборванный звонок сохраняет результат; остаток исчез перед подтверждением — клиент получает альтернативу; ошибка ТТН не теряет заказ; неразборчивый адрес требует уточнения; предложение без согласия не меняет корзину.
РАСШИРЕННЫЙ КОНЦЕПТ · ПРЕДЛОЖЕНИЕ ПО РЕАЛИЗАЦИИ
Как это будет работать в реальном отделе продаж
Ниже — моя проектная схема, а не пересказ Loom. Рабочая гипотеза: 2 000 новых лидов в день, несколько брендов, CRM как источник заказов. Все тайминги и численные настройки — стартовые параметры пилота.
1. Путь клиента: от заявки до отправки
0–5 секунд: принять заявку. CRM присылает событие с ID заказа, составом корзины, языком, контактами и выбранным каналом. Сервис проверяет повтор события и создаёт задачу. Повторный webhook не должен создавать второй диалог.
На странице «Спасибо»: предложить быстрый способ подтверждения. Кнопка «Подтвердить в Telegram» открывает брендированного бота с одноразовым короткоживущим токеном. В ссылке нет телефона, адреса или состава заказа. После Start сервер связывает чат с заказом; чувствительные сведения доступны после проверки привязки.
Если клиент не открыл Telegram: использовать выбранный при оформлении доступный канал. Для Viber — официальный Business Messages через партнёра при наличии необходимого согласия. Если цифровой канал недоступен, задача уходит менеджеру на звонок. Один номер телефона сам по себе не открывает диалог с Telegram-ботом.
Первое сообщение: «Здравствуйте! Я AI-помощник магазина [бренд]. Помогу подтвердить заказ №[номер]. [Товар], [количество], итого [сумма]. Всё верно?» Кнопки: «Подтвердить», «Изменить», «Вопрос», «Менеджер». Цены подставляются из CRM.
Подтверждение и предложение: уточнить только недостающие данные. Если есть релевантный комплект, один раз предложить его с понятной доплатой и кнопкой «Оставить как есть». Отказ от допродажи не мешает оформить основной заказ.
Завершение: показать окончательный состав, сумму, способ оплаты и доставки; получить явное подтверждение. Сервер повторно проверяет остатки и цену, фиксирует версию заказа и создаёт отправление. Если ТТН не создана, заказ остаётся подтверждённым, а доставка попадает в очередь повторной обработки.
Основная развилка для Telegram
Обычный бот не начинает личный диалог первым. Поэтому воронка должна приводить клиента к Start. Подключённый Telegram Business-бот может обслуживать разрешённые диалоги бизнес-аккаунта, но его права и условия ответа нужно проверять отдельно: это не универсальный способ написать любому номеру.
Администратор компании создаёт бота через BotFather. На старте достаточно одного бота на бренд и язык интерфейса можно выбирать внутри него. Для живой поддержки — корпоративные номера SIM/eSIM, приобретённые у оператора, и аккаунты с управляемым компанией восстановлением и двухэтапной защитой.
Несколько сотрудников и AI работают через общий inbox. Клиент видит один брендовый контакт. Покупные аккаунты с чужой историей и доступом продавца я бы в основу не закладывал: потеря номера или сессии означает потерю управляемости общения.
VIBER
Официальный отправитель бренда
Выбрать партнёра из каталога Viber, оформить бизнес-профиль, согласовать сценарии, получить API-доступ, настроить webhook ответов и статусов. До интеграции уточнить двусторонние диалоги, доступность в Украине, тарифы, лимиты, SLA и переносимость истории.
Viber Chatbot и Viber Business Messages — разные продукты. Для сообщений существующей базе по телефону рассматриваем Business Messages; для чатбота отдельно проверяем подписку пользователя и коммерческие условия.
Для Telegram Bot API и Viber Business API отдельный прокси на каждый аккаунт обычно не нужен. Запросы выполняет сервер по HTTPS. Если провайдер требует разрешённые IP, используем статический исходящий IP через управляемый шлюз. Это инфраструктурный сетевой адрес, а не способ увеличить лимит отправителя.
Если у компании уже есть поддерживаемые клиентские сессии Telegram, которым нужен прокси для сетевого доступа, их можно подключать через выделенный SOCKS5/HTTPS-шлюз у инфраструктурного поставщика. В реестре хранится связка «корпоративный аккаунт → session secret → основной маршрут → резервный маршрут». Доступы находятся в хранилище секретов, здоровье маршрута проверяется отдельно от статуса аккаунта.
Смена маршрута выполняется при сетевом сбое. Ограниченный платформой аккаунт останавливается и разбирается оператором; переключение IP не восстанавливает разрешение на рассылку. Я бы не строил рост на ротации купленных аккаунтов и прокси: для этих объёмов прежде надо проверить доступность клиента в канале и качество воронки.
4. Как распределяется нагрузка
Разделяем отправителя и вычислительную мощность. Один бот может обслуживаться множеством серверных обработчиков. Добавление обработчиков ускоряет анализ диалогов, но не повышает лимит Telegram или Viber.
Закрепление клиента. Ключ маршрутизации — бренд + customer_id. Существующий диалог остаётся у того же отправителя; новые заказы клиента добавляются в его историю. Клиент не получает сообщения от пяти разных аккаунтов.
Очереди с приоритетами. Сначала ответы уже общающимся клиентам и подтверждение заказа; затем первый контакт по новым лидам; затем напоминания. У последней очереди есть защита от бесконечного ожидания.
Лимиты на нескольких уровнях. Общий бюджет провайдера, бюджет отправителя и ограничение конкретного чата. Для Telegram-бота стартовый внутренний потолок — 20 сообщений/сек суммарно и не более одного/сек в чат; это запас относительно опубликованных ориентиров, не гарантия пропускной способности.
Последовательность внутри диалога. Один активный обработчик на conversation_id. Сообщения разных клиентов обрабатываются параллельно. Короткие сообщения одного клиента можно собирать в окно 1–2 секунды, чтобы не отвечать на каждое слово отдельно.
Ошибки и паузы. При 429 учитываем retry_after, при временной недоступности — отложенный повтор с нарастающей задержкой. Неуспешные задачи после лимита попыток попадают в отдельную очередь с уведомлением. При сомнительном результате отправки не повторяем её вслепую.
Менеджеры. Передача по языку, группе товаров и числу активных задач, с приоритетом срочных случаев. После принятия человеком AI прекращает самостоятельные ответы до явного возврата. Очередь содержит историю, заказ и краткую причину передачи.
ПРИМЕР РАСЧЁТА · ДОПУЩЕНИЯ ДЛЯ ПЛАНИРОВАНИЯ2 000 × 12 = 24 000исходящих сообщений в день при 12 сообщениях на лид
За 10 активных часов это ≈0,67 сообщения/сек в среднем. При условном десятикратном пике — ≈6,7/сек. Из такого расчёта не следует необходимость сотен аккаунтов. Отдельно измеряем всплески после рекламы, длительность AI-ответа, ограничения CRM и партнёра Viber. Для 3 запросов к модели/сек и средней задержки 4 секунды нужно около 12 одновременных вызовов; начальный резерв в 24 слота проверяем нагрузочным тестом.
Как вариант реализации: сервисы на TypeScript, PostgreSQL для заказов, диалогов и событий; очередь заданий и Redis для краткоживущих блокировок и лимитов. Внешние интеграции вынесены в адаптеры: CRM, каталог, доставка, Telegram, Viber.
Основные сущности: клиент, заказ, диалог, сообщение, отправитель, задача, эксперимент, согласие на контакт. Реестр отправителей содержит бренд, канал, статус, допустимый бюджет, ссылку на секрет, маршрут и последнюю ошибку. На событиях — уникальные ID, на записи заказа — проверка версии.
AI с ограниченными действиями
Модель классифицирует запрос, отвечает по базе знаний и предлагает действие. Сервер исполняет только разрешённые операции: получить товар, проверить остаток, рассчитать комплект, предложить изменение, подтвердить заказ, вызвать менеджера.
Цена и доставка берутся из систем учёта. Модель не придумывает скидки и не создаёт ТТН текстом. Перед изменением состава нужен выбор клиента. Медицинские вопросы о косметике, конфликт, возврат, непонятные условия или ошибка интеграции — причины для передачи специалисту.
Состояния заказа: новый → канал доступен → контакт начат → диалог → подтверждён → отправление создано. Отдельные ветки: клиент отказался, нет контакта, нужна помощь, техническая ошибка. Таймеры отменяются при ответе, отказе и смене статуса. Webhook записывается до подтверждения его получения, а действие во внешней системе выполняется с защитой от дублей.
6. Как повышать конверсию
Оптимизировать нужно маржинальный результат на каждый входящий лид и выкуп. Рост подтверждений за счёт давления или обещаний может закончиться отказами при получении.
Снизить усилие клиента
Заказ и сумма уже заполнены. Вместо длинной анкеты — одно действие за шаг, понятные кнопки, исправление заказа без повторного ввода. В первом сообщении видно магазин, товар и причину обращения. Отвечаем на языке клиента, явно обозначаем AI и оставляем выход к человеку.
Сделать допродажу полезной
Правила выбирают 1–2 подходящих товара по категории, совместимости и остаткам. Клиент видит полную новую сумму и выгоду комплекта. После «нет» предложение не повторяется. Проверяем, лучше ли допродажа до финального подтверждения или отдельным шагом после основного выбора.
Сначала тестировать вход в Telegram. Доля кликов по кнопке, затем доля Start и успешных привязок заказа. Telegram-конверсию нельзя считать только среди тех, кто уже запустил бота: нужно учитывать всех назначенных в этот сценарий лидов.
Затем первое сообщение. Короткая сводка заказа против вопроса «Удобно подтвердить?». Основные показатели — доля ответов и завершённых заказов; текст меняем по одному фактору.
Затем канал и тайминги. Гипотеза старта: одно напоминание через 15 минут, передача человеку через 45–60 минут без подтверждения в рабочие часы. При недоставке можно сразу выбрать доступный согласованный канал. После ответа в одном канале остальные попытки отменяются.
Затем предложение. Базовый заказ против релевантного комплекта. Сравниваем не только средний чек, но и маржу, отмены, выкуп, возвраты и жалобы.
Дизайн эксперимента: случайно закрепляем клиента за вариантом, сохраняем группу для его повторных заявок, выравниваем источники трафика и категории. Для первого сравнения можно взять AI+эскалацию против текущего процесса менеджеров. Окно наблюдения включает доставку и возвраты; объём выборки рассчитываем по базовой конверсии и минимальному полезному улучшению. Результаты «за один день» не считаем достаточным основанием для масштабирования.
7. Как запускать без потери заказов
Теневой режим. AI готовит ответы и действия, менеджеры оценивают их. Проверяем цену, остатки, изменение заказа, дубли, отмену и сбой доставки.
Один бренд, один канал, 5–10% новых лидов. AI получает только понятные сценарии, все эскалации видны оператору. У команды есть выключатель автоматической отправки.
Расширение до 25–50% после проверки. Критерии заранее фиксируем: отсутствие повторных заказов/ТТН, правильные суммы, приемлемое ожидание, конверсия и выкуп без ухудшения относительно согласованного порога.
Подключение Viber и следующего бренда. Масштабируем после проверки первого контура и фактических лимитов. LTV-коммуникацию держим отдельным сценарием с собственными правилами и экспериментами.
Открытые вопросы к вам
Какая CRM, есть ли API/webhooks и кто создаёт ТТН сейчас?
Можно ли менять страницу после заказа и вести клиента в Telegram-бота, или обязательно писать первым по номеру?
Какие корпоративные Telegram-аккаунты, боты и Viber-подключения уже есть? Кому принадлежат номера и доступы?
Зачем нужны прокси в текущей схеме: сетевой доступ, существующие клиентские сессии или предполагаемый рост числа отправителей?
Сколько лидов приходит в пиковые 5–15 минут, сколько брендов и языков, какие часы работы менеджеров?
Каковы текущие подтверждение, выкуп, средний чек, маржа на лид и стоимость работы менеджеров?
Какие допродажи и скидки допустимы? Есть ли актуальные каталог, остатки и готовые ответы на возражения?
Где фиксируются выбранный канал и разрешение на сообщения, как обрабатывается отказ от контакта?
Кто принимает эскалации, какой срок ответа реалистичен и какие действия AI может выполнять самостоятельно?
Какой бюджет на пилот, сообщения и AI; что считаем достаточным результатом для расширения?
Ответы на первые четыре вопроса определяют архитектуру каналов. Остальные нужны для оценки мощности, стоимости и эксперимента.
Ограничения каналов проверены по официальным материалам 7 сентября 2026 года. Конкретные условия Viber подтверждаются у выбранного партнёра. О Viber Business Messages ↗
Показатели из Loom отделены от проектных решений. Доступны описание, главы, фрагменты расшифровки и субтитры; полная расшифровка требует входа. Полнота проектных сценариев не означает дословную полноту пересказа видео.
02
LTV-МАШИНА ПОВТОРНЫХ ПРОДАЖ
Продолжать отношения после первой покупки
Суть концепции
Магазин уже заплатил за привлечение клиента. Если после первой покупки продолжать общение, консультировать и предлагать подходящие товары, клиент может покупать повторно. Автор хочет масштабировать такую работу с помощью AI-агентов, поскольку человеческий отдел охватывает лишь часть базы.
Здесь точка старта — существующий клиент, а не новая заявка. Агент должен поддерживать отношения: писать, консультировать, поздравлять и возвращаться с предложениями. Автор также обсуждает голосовые сообщения, видеокружки и контент в социальных аккаунтах.
Что означает LTV в этом видео
Автор рассматривает LTV360 как суммарную выручку от клиента за год и связывает её с количеством повторных покупок. Выручку нужно отличать от прибыли: затраты на товар, привлечение, обслуживание и коммуникацию учитываются отдельно.
ИЛЛЮСТРАЦИЯ ЛОГИКИ · НЕ ПРОГНОЗ$25 × 2 покупки = $50выручки от клиента за выбранный период
Собрать контекст клиента. Использовать историю покупок и предыдущего общения.
Поддерживать регулярный контакт. Помогать с выбором и возвращаться в подходящий момент.
Предлагать следующую покупку. Переводить диалог в заказ и записывать результат в CRM.
Оценивать эффект на всей базе. Смотреть на повторные покупки и прибыль, а не только на число отправленных сообщений.
Эта последовательность — структурированная интерпретация идеи для разработки, а не дословное техническое задание автора.
«Потенциал ×5» — гипотеза
Автор связывает рост с переходом от частичного охвата к работе со всей базой. Пятикратное расширение охвата не гарантирует пятикратную прибыль: оставшиеся клиенты могут реагировать иначе. Эффект нужно проверить на контрольной группе.
ТЕХНИЧЕСКОЕ ВИДЕНИЕ АВТОРА
Масштабная коммуникация
В видео обсуждается инфраструктура множества социальных аккаунтов и AI-коммуникация, похожая на работу живых консультантов. Для конкретного продукта ещё предстоит определить каналы, доступные интеграции, частоту контактов и правила передачи диалога человеку.
ПАРТНЁРСКАЯ МОДЕЛЬ
Доля от результата
Автор предлагает инженеру 10% от профита и обсуждает ещё 10% для руководителя, сопоставляя это с текущими затратами около 40% маржи. Это предложение из видео: база расчёта, расходы и условия партнёрства отдельно не зафиксированы.
Точка входа — полученный заказ и история клиента. LTV-продукт определяет, кому, когда и с какой пользой предложить продолжить отношения.
Сегменты и причины контакта
Первый полученный заказ. Помочь с использованием товара и уточнить, всё ли в порядке. При проблеме запускать поддержку, а не продажу.
Вероятное окончание продукта. Рассчитать ориентир по объёму, предполагаемой частоте использования и подтверждённой истории. Предложить пополнение; спросить реальный срок, если оценка неточная.
Сопутствующая потребность. Предложить совместимый продукт на основании фактической покупки. Исключить уже купленные позиции и нежелательные сочетания.
Лояльный клиент. Удобное повторение заказа, подходящий набор, доступная программа лояльности. Не требовать заново сообщать все данные.
Давно не покупал. Один содержательный повод: актуальный товар, пополнение наличия или полезная консультация. При отсутствии отклика — увеличить паузу и остановить цепочку после заданного лимита.
Отказ, возврат или жалоба. Отдельная сервисная ветка. До разрешения проблемы клиент исключён из автоматических предложений.
Как принимается решение о следующем действии
Проверить разрешение и доступность канала → исключить открытые заказы, претензии и недавние контакты → выбрать событие → проверить каталог и экономику → предложить один вариант → записать ответ и дату следующего допустимого контакта. Явное «позже» превращается в назначенную дату; «не интересно» подавляет категорию; «не писать» останавливает инициативные продажи.
Чат и голос используют общую память
Текстовые сообщения — основной асинхронный способ. Голосовое сообщение подходит для предпочтения клиента; телефонный ассистент подключается к согласованному звонку, сложной консультации или проверенному эксперименту. История товара, вопросы и отказы общие: смена канала не начинает новый независимый скрипт.
Граница с продуктом 1
После согласия купить LTV создаёт новый заказ и передаёт его в контур исполнения входящих заказов: проверка, подтверждение, оплата, ТТН и доставка. На время активного заказа LTV-предложения приостанавливаются. Инициатор продажи, канал и эксперимент сохраняются, чтобы не засчитать один результат дважды.
Как доказать пользу
Сохраняем случайную контрольную группу клиентов, получающую обычное обслуживание без новых автоматических продаж. Сравниваем маржинальный результат на клиента за одинаковое окно, повторные покупки, возвраты, стоимость общения и отписки. Выручка после сообщения ещё не доказывает эффект: человек мог купить и без него.
Минимальный запуск
Одна категория с понятным повторным потреблением, один канал, чистая история полученных заказов и один триггер. Сначала правила и контрольная группа; затем персонализация, дополнительные категории и голос. Предельная частота задаётся по клиенту суммарно для двух продуктов, приоритет всегда у обслуживания текущего заказа.