Малый бизнес автоматизировал не чат, а переход между системами

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

Американская Stratagem работает с трансформацией розничных компаний, управлением заказами и цепочками поставок. В опубликованном Google Cloud кейсе фирма прямо называет себя малым бизнесом и описывает две внутренние автоматизации на Gemini Enterprise.

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

Источник не публикует длительность операции до и после, долю ошибок, стоимость платформы или результаты независимого аудита. Указанное на странице сокращение обращений в контакт-центр на 30% относится к проекту клиента Stratagem, а не к внутреннему конвейеру «почта — финансы — Jira». Эти факты нельзя смешивать.

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

Почему письмо нельзя считать готовой командой

Email объединяет данные и инструкции в одном тексте. Отправитель, тема, подпись, процитированная переписка, вложение и случайная фраза могут влиять на вывод модели. Для человека контекст привычен; для агента это недоверенный документ.

Поэтому опасна схема «новое письмо → LLM → прямой вызов API». Она не различает три сущности:

  • событие: в почтовом ящике появилось новое сообщение;
  • предложение: модель извлекла реквизиты или сформировала черновик задачи;
  • действие: учётная система приняла запись с определёнными полями и правами.

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

Архитектура контролируемого конвейера

Для малого бизнеса достаточно семи компонентов без «универсального супер-агента».

1. Коннектор получает уведомление о новом сообщении и сохраняет идентификатор события.
2. Фильтр отбрасывает рассылки, автоответы и неподдерживаемые вложения.
3. Извлечение превращает нужный фрагмент письма в типизированный JSON.
4. Валидатор проверяет обязательные поля, справочники, диапазоны и бизнес-правила.
5. Политика решает: выполнить автоматически, запросить подтверждение или отправить в исключения.
6. Детерминированный исполнитель вызывает только заранее разрешённую операцию API.
7. Журнал связывает исходное письмо, версию модели, предложенные поля, решение человека и результат вызова.

Для Jira исполнитель должен иметь право создания задач только в нужных проектах. Официальный REST API возвращает 201 при успешном создании и принимает набор полей, разрешённый экраном создания задачи. Это удобная точка контроля: модель не получает произвольный сетевой инструмент, а формирует параметры строго для одной операции.

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

События могут повторяться и пропадать

Gmail API умеет отправлять уведомления об изменениях ящика через Cloud Pub/Sub. Приложение получает не всё письмо, а указатель historyId, после чего запрашивает изменения. Watch нужно продлевать не реже чем раз в семь дней; документация рекомендует делать это ежедневно. Google также предупреждает, что уведомления иногда задерживаются или теряются, поэтому нужен периодический вызов history.list для сверки.

Есть и обратная проблема: брокер повторит уведомление, если обработчик не подтвердил его вовремя. Значит, один email способен дважды породить одну задачу. Защита строится не на просьбе к модели «не дублировать», а на ключе операции.

Пример ключа для задачи:

  • источник: идентификатор почтового ящика;
  • сообщение: устойчивый messageId или запись истории;
  • тип действия: create_jira_issue;
  • версия правила маршрутизации;
  • целевой проект.

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

Какие права и данные действительно нужны

Не стоит подключать агенту личный ящик руководителя или полный административный токен Jira. Лучше выделить процессный адрес, фильтровать метками и начинать с минимального OAuth-доступа. Для первого этапа часто достаточно читать метаданные и сообщения, а не отправлять почту, удалять письма или управлять всем ящиком.

В Jira сервисная учётная запись получает Browse Projects и Create Issues только для выбранного проекта. Редактирование, удаление, переходы между статусами и управление пользователями подключаются отдельно, если для них есть подтверждённый сценарий.

Дополнительные меры:

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

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

Как считать экономику

Кейс Stratagem не даёт чисел для внутреннего процесса, поэтому расчёт должен быть модельным и основанным на собственном хронометраже.

Для двух недель измерьте:

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

Полезная метрика — стоимость принятого действия:

стоимость платформы и эксплуатации + время проверки и исправлений, делённые на число корректно созданных задач или подтверждённых совпадений.

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

Пилот на 30 дней

Начните с одного общего ящика и одного проекта Jira. Не подключайте финансовую проводку и отправку писем.

Неделя 1: соберите 100–300 обезличенных писем, определите пять типов задач и обязательные поля. Зафиксируйте золотую выборку с решениями сотрудников.

Неделя 2: включите режим черновика. Агент извлекает поля, но человек создаёт задачу. Измеряйте полноту, точность маршрута и объём правок.

Неделя 3: разрешите автоматическое создание только для одного низкорискового типа при прохождении всех проверок. Ограничьте число операций в час и оставьте кнопку остановки.

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

Критерий перехода в продуктив — не эффектная переписка с агентом. Это устойчивый процент корректных задач на новой выборке, отсутствие дублей, ограниченные права, понятное восстановление после сбоя и измеримый выигрыш времени.

Что взять руководителю

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