Почему боты тарифицируют диалоги и чем это грозит при росте трафика

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

почему боты тарифицируют по диалогам, а не по времени работы

Разговор с ботом — это не одна операция, а цепочка запросов к разным сервисам. Сначала текст пользователя проходит через модуль распознавания намерения, затем языковая модель формирует ответ, а если вопрос касается заказа или остатков — бот дополнительно обращается к учётной системе, чаще всего к 1С. Каждый из этих шагов стоит денег провайдеру: аренда вычислительных мощностей под языковую модель, лицензии NLU-движка, трафик к внешним API. Например, обычный диалог с уточнением адреса доставки и статуса заказа состоит из 5-6 обменов сообщениями, и на каждый шаг бот делает отдельный вызов к языковой модели или к 1С — в счёте провайдера это фиксируется как отдельная строка, даже если весь разговор занял меньше минуты.

Фиксированная абонплата при таком устройстве системы невыгодна поставщику: 200 диалогов в месяц и 20 000 диалогов в месяц потребляют совершенно разные ресурсы, а платить клиент за них будет одинаково. Поэтому рынок перешёл на потребительскую модель — оплата за диалог, за уникального пользователя в сутки или за токены сгенерированного текста. Логика та же, что у облачных серверов: ёмкость и цена растут вместе с нагрузкой, а не фиксируются раз и навсегда.

почему возникает резкий рост счёта при всплеске трафика

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

Но тариф провайдера рассчитан на средний объём, а не на пиковый, поэтому счёт за бота приходит в разы больше, чем весь бюджет на саму рекламную кампанию. Проблема не только в деньгах: каждый диалог о наличии товара или статусе заказа дёргает 1С напрямую, а типовая база не рассчитана на десятки параллельных запросов от бота поверх обычной нагрузки бухгалтерии и склада. В пиковые часы ответы начинают идти с задержкой в 10-15 секунд, очередь запросов растёт быстрее, чем база успевает её разбирать, и часть посетителей закрывает чат и уходит к конкуренту.

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

как исправить тарифную модель, если бот съедает бюджет

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

перенести тяжёлые запросы из диалога в кэш

Если бот на каждый вопрос о цене или остатке лезет напрямую в 1С, платный вызов срабатывает даже на типовых вопросах вроде «есть ли доставка» или «работаете ли в выходные». Решение — вынести каталог, цены и остатки в промежуточный кэш с обновлением раз в 10-15 минут, а к 1С обращаться только на финальном шаге, при подтверждении заказа. Это снижает и число платных диалогов, и нагрузку на саму базу. Такую прослойку между ботом и учётной системой обычно делают через доработку 1С — отдельный API-метод, который отдаёт кэшированные данные, не открывая боту прямой доступ к базе.

развести сценарии по стоимости

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

договориться о потолке с провайдером бота

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

что делать, если ошибка повторяется на каждый пиковый период

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

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

Второй момент — вместе с трафиком растёт объём переписки, а значит и объём персональных данных: телефоны, адреса, номера заказов, иногда данные для доставки. По 152-ФЗ такие данные требуют учёта, ограничения доступа и определённого срока хранения. При кратном росте диалогов в сезон стоит заранее проверить, где и как долго хранится история чатов, а не разбираться с этим постфактум, когда объём данных уже вырос в разы.

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

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

Если бот работает поверх 1С:Управление торговлей — оформляет заказы, проверяет остатки по складам, — имеет смысл заложить в план сезона отдельный контур под нагрузку от бота, чтобы он не конкурировал с менеджерами за те же ресурсы базы. Дежурство сисадмина в пиковые дни обходится дешевле, чем сорванные заявки и повторный перерасход по тарифу бота на следующей кампании: сопровождение 1С и сисадмин стоит от 3800 руб/час, и заранее спланированные несколько часов мониторинга в разгар распродажи почти всегда дешевле аварийного разбора после сбоя.

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

сравнение моделей тарификации: что учитывать при выборе

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

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

❓ Частые вопросы

Почему счёт за чат-бота вырос, хотя мы не меняли тариф?

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

Можно ли перейти с оплаты за диалог на фиксированный тариф?

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

Как заранее оценить, сколько будет стоить бот при росте трафика перед распродажей?

Нужно посчитать ожидаемое число диалогов при увеличенном трафике, например при удвоении или утроении посещаемости, и умножить на тариф провайдера. Дополнительно стоит проверить, выдержит ли 1С такое же увеличение параллельных запросов от бота — иначе вырастут не только расходы, но и число сбоев.

Что будет, если бот перестанет отвечать из-за перегрузки 1С в пиковые часы?

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

Нужно ли отдельное согласие клиентов на хранение переписки с чат-ботом?

Если в переписке остаются телефон, адрес или другие персональные данные, на их обработку распространяется 152-ФЗ. Нужны согласие на обработку, ограничение доступа к истории чатов и определённый срок хранения — это стоит продумать до роста объёма диалогов, а не после.