Антон Фокин
Здесь пишу о работе своей компании, запуске продуктов и управленческих решениях сайт https://qtim.pro/ тг @qtim71
Согласны, что у малого бизнеса дорогая строка — человек на проверке. Но её можно уменьшать не только автоматизацией, а выбором, что проверять. Проверять каждый ответ бессмысленно: очередь согласований съест выгоду. Мы проводим границу по последствиям и обратимости: обратимое и дешёвое агент делает сам в лимитах, а деньги, внешние сообщения и удаление ждут человека. Тогда проверка остаётся только там, где ошибка дорогая, и цена операции падает без лишнего риска.
Самое неприятное в этой истории — канал молчал, а интерфейс показывал, что подписка работает. В интеграциях мы на такие случаи держим периодическую сверку поверх событий: события дают скорость, сверка ловит то, что потерялось. Если по расписанию сравнивать, сколько сообщений ушло из CRM и сколько дошло до площадки, «залипший» адрес видно через час, а не по жалобе менеджера. Отсутствие событий — тоже сигнал, если за ним кто-то смотрит.
На вопрос «что будет, если последнюю единицу почти одновременно купят в двух местах» есть ответ, который стоит заложить до запуска сайта, а не после первой отмены. Доступный остаток считается один на все каналы: свободный запас минус резервы минус страховой остаток, и продажа в одном канале сразу уменьшает его в другом. Обмен по расписанию оставляет окно для перепродажи шириной в интервал синхронизации, поэтому критичные изменения мы отправляем по событию, а сверку держим как страховку. Иначе экономия на комиссии уходит на извинения перед покупателями.
Важное уточнение к формуле: минимальная цена в кабинете — не разовое число. Сменился тариф, выросла закупка, поменялась логистика — и вчерашняя граница уже ниже безубыточности. Мы разбирали этот закон со стороны платформ, и там согласие на скидки приходится хранить как историю: версия условий, время, список товаров, отзыв. Продавцу полезна та же дисциплина: фиксировать, какая минимальная цена стояла и когда. Если акция всё же уйдёт ниже, спорить придётся датами, а не ощущениями.
Главный вывод для меня даже не про модели, а про скрытый скрипт. Ботов в AI-проектах мы проверяем так же: набор тестовых диалогов с ожидаемыми ответами, которых модель не видит, и регулярный прогон. Именно он ловит случаи вроде ваших копеек при возврате, когда видимый тест зелёный, а отчёт уверенно ставит галочку. С таким набором выбор модели превращается в расчёт: где младшая проходит все кейсы, там её и берём.
On-premise снимает вопрос «где хранятся данные», но у ИБ следом обычно второй: что система может сделать и как её остановить. Подключая AI-агентов к корпоративным системам, мы закладываем это до первого запроса: у системы своя учётная запись с владельцем, роли раздельно на чтение и запись, журнал действий и способ отозвать доступ одной операцией. С таким пакетом разговор с ИБ идёт по пунктам, а не по ощущению риска.
Схема, где оператор проверяет поля и нажимает «готово», — ровно та ступень, с которой мы сами начинаем внутренних агентов: система готовит, человек подтверждает. Интересно, как у вас устроен автоматический ответ абоненту: он уходит после «готово» или сразу? Внешние сообщения мы оставляем за человеком дольше всего: ошибка в поле исправляется в системе, а неверный официальный ответ уже у адресата. Отпускать отправку стоит, когда доля правок оператора стабильно низкая.
Спасибо за честность про отсутствие замеров, это редкость. Добавлю, что базовую цифру проще всего снять до запуска: неделю отмечать, сколько раз в день отвечаешь на одни и те же вопросы и сколько это занимает. У нашего внутреннего HR-бота экономия по оценке вышла около 3–4 часов в день — и опиралась она как раз на время, которое уходило на повторяющиеся вопросы. Без такого «до» любое «после» остаётся ощущением, а с ним разговор об окупаемости занимает одну строку.
Самая тонкая часть тут — «Вернуть клиентов», потому что агент пишет живому человеку от имени продавца. Мы во внутренних агентах такие действия на старте оставляем черновиком: агент готовит сообщение, человек нажимает «отправить». Причина простая: ошибка в ответе в чате стоит одного неудачного сообщения, а массовая рассылка по старым диалогам повторяет её сотни раз. Когда видно, что сценарий стабилен, отправку можно отпустить. Как у вас устроено — сразу автоматом или через подтверждение?
К пункту про оценку по этапам добавлю: этапы стоит резать не по времени, а по устройству. В одном боте рядом живут ответы из базы знаний, запрос статуса в учётную систему и оформление заявки — снаружи это один чат, а по бюджету и рискам три разные задачи. В проектах с ботами мы считаем их отдельно, и разброс оценок между исполнителями обычно сидит во второй и третьей: там интеграция с чужой системой, про которую вы пишете в пункте 3.