Как ИИ в поддержке меняет правила интернет-торговли
Вендор систем поддержки клиентов анонсировал новую матрицу решений для ИИ-агентов, где автономность определяется не уверенностью модели, а ценой ошибки, определённостью данных и возможностью отката. Это не просто про чат-бота — это про то, как сайт может быть не просто «работающим», а «выигрывающим» у конкурентов.
О чём речь и почему я считаю это важным для бизнеса
ИИ в клиентском сервисе — не про то, чтобы убрать сотрудников. Это про то, чтобы убрать лишние шаги. Каждое обращение в поддержку — это потеря клиента, особенно если он уже почти купил. В интернет-торговле это не просто «обслуживание», это часть конверсии. Я считаю, что для магазина важно не столько, сколько ИИ знает, сколько — насколько он может действовать без риска. Если система может изменить статус заказа, вернуть деньги или перенести доставку — она уже не просто отвечает, а влияет на бизнес. И тогда вопрос не «как сделать быстрее», а «как сделать безопасно и предсказуемо».
Если магазин не умеет автоматизировать простые действия — он теряет время, которое мог бы тратить на продажи. А если автоматизация не проверена — он теряет доверие. И в этом — главная угроза: не технический сбой, а ощущение, что «сайт не понимает, что делает».
Как это устроено — что тут вообще происходит
Речь не о чат-боте, который отвечает по шаблону. Это о системе, которая может видеть данные из CRM, 1С, системы заказов и даже сервис-деска. Она не просто отвечает — она может создать заявку, изменить срок доставки, запустить возврат. Но ключевое: она не может решать всё сама. Даже если модель уверена на 99%, это не значит, что действие разрешено. Всё зависит от трёх вещей: насколько серьёзно последствие ошибки, есть ли полные данные и можно ли отменить действие. Например, если клиент пишет «где мой заказ?» — ИИ может ответить, если заказ найден однозначно, статус актуален, и ответ не содержит обещаний. А если нет — он должен признать, что данных недостаточно. Умение не отвечать — важнее умения выдумать ответ.
То же самое в магазине: система может проверить наличие товара, но не может автоматически вернуть деньги, если нет правила. Иначе — риски нарастят. И не за один день, а за тысячи операций.
Что изменилось на рынке: как делали раньше и как делают сейчас
Раньше магазины думали: «надо автоматизировать поддержку». И делали чат-бота, который отвечал по шаблону. Если не угадал — клиент злился. А если угадал — не знал, что это не его решение. Теперь понимают: автономность — это не про скорость, а про контроль. Не важно, насколько быстро ИИ отвечает, если он может ошибиться. Или если его действия не отслеживаются. Сейчас делают иначе: сначала ИИ анализирует запрос, но ничего не делает. Потом — предлагает решение, которое подтверждает человек. Потом — запускает действие в узком сценарии, где всё проверено. И только потом — расширяют полномочия. Интернет-магазин, который раньше просто «отвечал», теперь должен быть способен «решать» — но только там, где это безопасно и предсказуемо.
Кому это касается и как понять, что это про ваш проект
Если у вас есть: — чат-бот, который не отвечает на вопросы про заказы; — клиенты, которые пишут «а вы вообще понимаете, что я хочу?»; — операторы, которые повторяют одни и те же действия каждый день; — возвраты, которые идут не по правилам; — или просто сомнения, что «сайт не работает» — то это про вас. Сайт устарел не тогда, когда падает. Он устарел, когда начинает мешать. Когда клиенту нужно больше шагов, чем на маркетплейсе. Когда он думает: «а может, лучше там?».
Вы не теряете клиентов из-за цены. Вы теряете их из-за неудобства. И если у вас нет системы, которая может проверить статус заказа, не угадывая, а по данным — вы уже отстаёте. Даже если сайт «работает».
Что с этим делать — порядок действий в общем виде
Начинаем с аудита: какие запросы клиентов можно автоматизировать, какие — нет. Не по количеству, а по риску. Делаем карточки для каждого сценария: что может делать система, что — нет, какие данные нужны, кто может отменить, как отслеживается. Вводим ступенчатое внедрение: сначала ИИ только анализирует, потом — предлагает, потом — действует в одном сценарии. Проверяем: если система предлагает возврат — можно ли его отменить? Если нет — ограничиваем. Проверяем: если ИИ не может ответить — он должен передать человеку, но с полным контекстом. Без повторов. И самое главное: не полагаемся на «уверенность модели». Полагаемся на проверенные правила и возможности отката.
Такой подход не делает магазин умнее — он делает его надёжнее. А надёжность — это конверсия.
Автономность — не про скорость, а про доверие
Самое важное в матрице — не то, что можно автоматизировать, а то, что **можно доверить**. Если система может изменить статус заказа — это хорошо. Если она может вернуть деньги — это опасно. Если она может дать скидку — это ещё опаснее. Именно поэтому мы в Cetera не начинаем с «всё автоматизировать». Мы начинаем с того, чтобы понять: где можно действовать, где — нет. Магазин, который не может ответить на «где мой заказ?» — уже уступил. Магазин, который может — но с риском ошибки — уже проиграл. А тот, кто может — и безопасно — выигрывает.
Иногда самое быстрое решение — это не ответ. Это признание, что данных недостаточно. И передача человеку с контекстом. Это не авария. Это сервис.
Это часть нашей работы — Интеграция данных. Организация обмена информацией с сервисом-поставщиком данных. Интеграция данных
Автор: Святослав Семенов из Cetera Labs