Как не дать ИИ обещать покупателям завершившуюся акцию

2026-09-15 14:47:16 Время чтения 17 мин 40

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

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

Представим учебную ситуацию. В пятницу компания завершила акцию: бесплатная доставка больше не действует. Маркетолог снял баннер, менеджер обновил прайс, рекламные объявления остановили. В понедельник покупатель присылает скриншот: ИИ-консультант только что подтвердил бесплатную доставку. Он нашёл условия в прошлой рассылке, которую компания заботливо добавила в базу знаний.

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

У рекламного обещания есть несколько сроков

Маркетинговый календарь обычно отвечает на вопрос, когда показать сообщение. Для ИИ-консультанта этого недостаточно. Ему необходимо понимать, когда предложение можно применить, какое действие клиента закрепляет условия и что говорить после завершения акции. Эти моменты могут не совпадать.

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

Полезно разделить срок показа, период участия и срок исполнения уже принятого обязательства. Это рабочая модель управления информацией, а не универсальное толкование договора. Конкретные формулировки предложения компания должна согласовать внутри до запуска. Автоматизация не должна самостоятельно решать, что именно бизнес имел в виду под словами «до конца месяца».

Есть и четвёртый момент: время, когда сведения обновились в конкретном канале. Акция могла завершиться в десять утра, а выгрузка для консультанта обновиться только вечером. Этот промежуток нужно видеть отдельно. Иначе спор между маркетингом и разработкой будет вращаться вокруг того, кто «всё вовремя поменял», хотя покупатель всё это время получал старый ответ.

Начните с реестра обещаний

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

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

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

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

Уже на заполнении таблицы обнаруживаются полезные вопросы. Что считать новым клиентом? Можно ли совместить два предложения? Распространяется ли бонус на повторную покупку другого юридического лица из группы? Такие неопределённости лучше обсуждать до первого обращения. Они существовали и без ИИ, просто раньше сотрудник закрывал пробел звонком руководителю, а клиент не видел внутренней задержки.

Переведите даты из текста в условия

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

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

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

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

Разделите архив материалов и действующие условия

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

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

В Schema.org существуют свойства validFrom и validThrough, которые описывают начало и окончание действия, в том числе для предложения. Отдельное свойство priceValidUntil обозначает дату, после которой цена больше не доступна. Это полезные примеры явного описания сроков. Однако наличие таких полей само по себе не заставит вашего консультанта соблюдать ограничения: их необходимо включить в логику приложения.

Архив при этом остаётся доступен для другого вопроса: «Какие условия действовали, когда я оформлял заказ?» Здесь система должна искать историческую версию, связанную с конкретным событием. Если смешать историческую справку и предложение новой покупки, даже корректно сохранённые документы начнут давать противоречивые ответы. Различие должно задаваться задачей, которую выполняет консультант.

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

Обновляйте места применения вместе с исходным условием

Одна акция может жить на посадочной странице, в виджете, письмах, базе знаний, товарной выгрузке и заготовках менеджеров. Поэтому у предложения нужен список зависимых материалов. Не просто папка с картинками, а перечень мест, где оно способно повлиять на решение покупателя. Для каждого места укажите ответственного и способ обновления.

Если источник поменялся, полезно запускать связанные изменения из одного события. Сначала обновляются действующие условия, затем страница и данные консультанта; после этого проверяется результат. Полностью одновременное изменение разных систем не всегда возможно. Поэтому команда должна заранее определить допустимую задержку и поведение консультанта, пока подтверждение обновления не получено.

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

Есть материалы, которые нельзя переписать после отправки: электронное письмо, скачанный PDF, скриншот. В них особенно нужны точные условия и ссылка на страницу с актуальным статусом. Если пользователь предъявляет такой материал, консультант сначала выясняет, к какому периоду и заказу он относится. Сам факт наличия изображения не подтверждает, что предложение применимо к новой покупке сегодня.

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

Учтите разговоры на границе акции

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

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

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

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

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

Общая ответственность отдела маркетинга плохо работает в момент срочной правки. У предложения должен быть один владелец, который подтверждает коммерческий смысл, и исполнители, отвечающие за конкретные каналы. Изменение срока — это задача с результатом: новая версия условий опубликована, зависимые материалы обновлены, контрольные обращения пройдены.

Особенно внимательно оформляйте продление. Сообщение руководителя «оставим ещё на неделю» не должно автоматически менять прошлую запись. Создайте новую версию с временем принятия решения и новым сроком. Тогда можно объяснить, почему вчера консультант сообщил об окончании, а сегодня предложение снова доступно. Без истории версий команда теряет возможность восстановить происходившее.

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

Храните и причину изменения: плановое завершение, продление, исправление ошибки, исчерпание лимита. Это помогает разбирать повторные обращения без догадок. Если компания решила сделать индивидуальное исключение, запишите его отдельно для конкретного заказа. Не превращайте персональную договорённость в новое общедоступное условие, которое консультант начнёт предлагать всем последующим посетителям.

Проверьте ответы до и после окончания акции

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

Соберите небольшую подборку вопросов из разных каналов. «Я видел старый баннер», «мне вчера обещали», «доставка бесплатная в моём городе», «у меня уже есть счёт» — каждое обращение проверяет отдельное условие. В ожидаемом результате укажите не красивую реплику, а применённую версию предложения, основание решения и допустимый следующий шаг.

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

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

Проведите одну кампанию по новым правилам

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

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

Маркетинг отвечает не только за убедительность сообщения, но и за возможность выполнить сказанное в конкретный момент. Когда у каждого обещания есть условия, версия и понятная дата окончания, ИИ-консультант получает проверяемую опору для ответа. А команда тратит меньше сил на выяснение, какая из многочисленных копий рекламного текста сегодня считается действующей.