Кейсы внедрения ИИ-агентов и автоматизации: цифры, которые можно проверить

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

Кейс 01 / 07

Дистрибьютор специали­зиро­ванного ПО для живот­новод­ства, около 100 ферм-клиентов

Задача

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

Что сделали

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

Результат

  • Корпус из 236 документов и 1955 фрагментов, 8 тематических карт, ноль битых связей
  • От техзадания до работающего прода на боевом домене — 5 дней
  • Сто клиентов обслуживаются одной инсталляцией: сто учётных записей вместо ста развёртываний
  • Система работает в продакшене на боевом домене с июля 2026; площадка размещения и состав данных, уходящих провайдеру модели, фиксируются в договоре

Стек: FastAPI, PostgreSQL (полнотекстовый поиск + векторный индекс), Redis, React, nginx, Let's Encrypt

Кейс 02 / 07

Поставщик мебели на маркетплейсе: единое окно оператора поддержки

Задача

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

Что сделали

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

Результат

  • Перенос истории один в один: 149 191 заказ, 111 406 сообщений, 54 976 отзывов, 43 шаблона ответов — без потерь и расхождений
  • 749 автотестов зелёные на приёмке переноса платформы
  • Три независимые проверки качества, включая ревью другой модельной семьёй вслепую
  • Полный цикл подтверждён живым ответом реальному покупателю; по проекту подготовлен полный комплект документации по ГОСТ ЕСПД

Стек: FastAPI, PostgreSQL 14, Redis, React / Next.js, API маркетплейса, systemd, git-деплой

Кейс 03 / 07

Реклама на классифайде: статистика, которой годами не было (собственный проект холдинга)

Задача

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

Что сделали

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

Результат

  • Бэкофилл за 30 дней: 108 649 показов и 36 277 ₽ расхода подняты в систему — вместо прежних нулей
  • Посчитана реальная цена контакта: 227 ₽ за контакт при 3,74 ₽ за клик
  • Доказано на данных: ставка почти не влияет на количество контактов (связь 0,02) — рост ставки увеличивал расход, а не результат
  • Решение о рекламном бюджете впервые опирается на цифры площадки, а не на предположение

Стек: Python, FastAPI, PostgreSQL, API статистики площадки, cron-сборщики, сторож данных

Кейс 04 / 07

Сверка денег Wildberries: нашли занижение прихода на 1 953 200 ₽ (собственный проект холдинга)

Задача

Приход с маркетплейса в учётной системе считался по гипотезе: правило вычитало фиксированные 25 % комиссии и было прямо помечено в коде как оценка. Фактических финансовых отчётов площадки в базе не было ни одного. Из-за этого нельзя было ответить на главный вопрос собственника: канал прибыльный или убыточный.

Что сделали

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

Результат

  • Сверка с личным кабинетом сошлась в 0,00 ₽ — 15 отчётов, 12 компонентов расчёта
  • Прогноз занижал приход на 1 953 200 ₽ (21,7 %) за семь месяцев: ошибка систематическая, ни одного месяца в другую сторону
  • Фактические удержания — около 13,1 % вместо зашитых в модель 25 %
  • Канал признан прибыльным — около 1,73 млн ₽ чистыми за семь месяцев; прежний вывод об убыточности опровергнут фактом

Стек: Python, FastAPI, PostgreSQL, API финансовых отчётов маркетплейса, cron-синхронизация, автотесты и сторож сверки

Кейс 05 / 07

Контент для маркетплейса: 648 из 650 описаний приняты модерацией с первого раза (собственный проект холдинга)

Задача

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

Что сделали

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

Результат

  • Написано 650 из 650 описаний — 1,8 млн знаков, медиана 2808 знаков на карточку
  • Модерация приняла 648 из 650, отклонено — ноль
  • Расширенный контент у 647 карточек, медиана контент-рейтинга площадки — 77,5
  • Правило модерации выведено и переиспользуется: один факт — одно предложение, не меньше 18 предложений, средняя длина до 150 знаков
  • Что ещё в работе и мы это не прячем: 127 карточек пока не находятся в поиске площадки — это следующий этап

Стек: Python, генеративный контент-конвейер, валидатор текстов, API маркетплейса, PostgreSQL

Кейс 06 / 07

Собственная разработка: защищённый корпоративный мессенджер

Задача

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

Что сделали

Разработали self-hosted мессенджер: шифрование сообщений, двухфакторная аутентификация, вход только по приглашению, звонки один на один напрямую между устройствами и групповые через собственный медиасервер. Уже после первого релиза прогнали продукт через кросс-вендорное ревью — код смотрели вслепую две разные модельные семьи.

Результат

  • Версия 1.0.0 в собственном контуре с апреля 2026
  • Кросс-вендорное ревью нашло и закрыло 32 дефекта, 12 из них критические, — то, что внутреннее ревью пропустило
  • Групповые звонки до 5 участников через собственный медиасервер, персональные — напрямую между устройствами
  • Данные и переписка хранятся на собственном сервере: внешних облаков в схеме хранения нет

Стек: FastAPI, PostgreSQL, симметричное шифрование, Next.js 16 / React 19, Tailwind 4, медиасервер SFU, TURN

Кейс 07 / 07

Товарное направление инструмента и оснастки (собственный проект холдинга)

Задача

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

Что сделали

Прошли полный цикл: разбор выгрузок продаж и юнит-экономики по каждой позиции, ребрендинг, сбор семантического ядра, новый сайт и деплой. Контент карточек и сцен делала наша же контент-фабрика.

Результат

  • 77 SKU разобраны по юнит-экономике: видно, какие позиции зарабатывают, а какие занимают склад
  • Посчитан результат направления: 4,3 млн ₽ выручки за квартал, 916 тыс. ₽ прибыли, маржа 21,2 %, возврат на вложенные — 92,7 %
  • Семантическое ядро на 110 ключевых запросов, аудит удобства и конверсии по 12 страницам
  • Собственный сайт направления собран и выкачен в прод

Стек: Vite, React, three.js / R3F, генеративный контент-конвейер, nginx

Похожая задача?

Мы покажем ближайший к вашей ситуации проект изнутри — на созвоне, с экрана, без слайдов.

Запросить разбор