Почему сценарий автоматизации заводит сотрудника сам, а счёт из письма разобрать не может

В конце августа 2026 года директор по ИТ компании, недавно перешедшей на Яндекс 360, попросил у меня механизм автоматического разбора и маршрутизации почты. Пример назвал заказчик: пришёл счёт — он сам заводится в 1С.

Если вы ждёте от автоматизации того же, эта статья для вас. Покажу, что о письме есть в записи события Яндекс 360 и чего там нет, что достаёт сумму из документа и чем за это платят. В разделе «Как посмотреть на свои потоки» — три захода, чтобы разобрать свои документы.

Просьбу я сразу примерил к тому, что мы уже делаем. Компания «+Альянс» собирает в Яндекс 360 сценарии, которые сами заводят и отключают сотрудников, раздают доступы и присылают отчёты. Напрашивается простой ход: раз сценарий делает всё это сам, то и счёт из письма разберёт.

Дальше заказчик уже ни при чём: состав записи о письме изучал я сам. Отдаёт её почтовый метод AuditLogService_Mail в Яндекс 360 API, и полей с суммой, контрагентом и номером договора в ней нет. Если ваш сценарий опирается на эту запись, сумму счёта ему взять неоткуда.

Коротко

• Почтовый метод AuditLogService_Mail отдаёт о письме запись из 22 полей. Отправитель, получатели и тема письма в ней есть — полей о сумме, контрагенте и содержимом вложения нет.
• Данные из документа у компании «+Альянс» достаёт ИИ-конвейер. Его цепочка: источник → распознавание и извлечение данных ИИ → проверка → запись в целевую систему. Второе звено читает счёт и забирает из него все данные, какие возможно, — сумму и контрагента в том числе.
• За распознавание платят проверкой человеком — так оцениваю я. Anthropic, производитель модели Claude, предупреждает, что модель может ошибиться на изображении низкого качества, и просит человеческого контроля там, где ошибка дорого стоит.
• Первый шаг: спросите того, кто настраивал вашу автоматизацию, с какого метода сценарий берёт данные о письме и какие поля приходят в ответе.

Две услуги, между которыми проходит граница

Компания «+Альянс» делает автоматизацию процессов в Яндекс 360. Это те самые сценарии: завести сотрудника, отключить, раздать доступы, прислать отчёт. Программировать для них не нужно, и доступ к вашим паролям нам не нужен. Строим мы их на собственном продукте «+Альянс Поток», без кода и без доработок самого Яндекс 360.

Вторая услуга компании «+Альянс» стоит в другом разделе сайта, «Внедрение ИИ», где у нас пять услуг. Называется она «Создание ИИ-конвейеров обработки данных». Конвейер принимает входящий поток — письма, счета, накладные, заявки. ИИ извлекает из документов данные, и они попадают в 1С, CRM или Яндекс 360 без ручного ввода. Работает конвейер с журналом и с проверкой человеком там, где это важно.

Как понять, какая из двух нужна вам? Я смотрю, с чего начинается работа. Данные уже разложены по полям — это сценарий. Их сначала надо вычитать из документа — это конвейер.

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

Из чего состоит запись почтового метода AuditLogService_Mail

Записью о письме я называю ответ почтового метода AuditLogService_Mail из Яндекс 360 API. В ответе 22 поля. Для метода требуется право ya360_security:audit_log_mail.

Тип события лежит в поле eventType. У почтового метода AuditLogService_Mail значений двенадцать, и получение письма среди них есть: message_receive. О том, что письмо пришло, запись сообщает.

К самому письму я отношу пять полей записи: from, to, cc, bcc и subject. Это отправитель, получатели, адресаты копии и скрытой копии, тема. Ещё четыре поля говорят об обстоятельствах. Время события — date. Источник события — source со значениями server, imap, pop3 и native. Тип папки — folderType: у него 12 значений, среди них inbox, sent, trash. Метки письма — labels, например seen, attached, undo, delayed.

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

• организация и пользователь — orgId, userUid, userLogin, userName;
• откуда и от чьего имени — IP клиента clientIp и исполнитель операции от имени ящика actorUid;
• папка — название личной папки folderName;
• письмо — идентификаторы mid, destMid и msgId;
• событие и запрос — идентификатор события uniqId и идентификатор запроса requestId.

Идентификатор запроса requestId может быть неуникальным. Различать события я бы стал по uniqId.

Что с этим перечнем делать вам? Покажите его тому, кто настраивал автоматизацию, и спросите, откуда сценарий узнаёт о письмах. Если он назовёт AuditLogService_Mail, суммы в ответе не будет.

Что из нужного для счёта есть в записи о письме

Верхняя дорожка — путь, который начинается с готовых полей записи почтового метода `AuditLogService_Mail`. Нижняя — путь входящего счёта: красным отмечено, каких полей в структуре ответа нет, дальше идут три звена цепочки из нашей услуги создания ИИ-конвейеров, со второго по четвёртое. Пунктирная стрелка от красного блока к распознаванию — мой вывод.

Отправитель, адресаты, тема и время события в записи почтового метода AuditLogService_Mail есть. Провести по ним счёт нельзя: для проводки нужны сумма, контрагент и номер договора. В этом месте сценарию нужна помощь.

Нода в n8n — это вход, обработка или выход данных

Для сравнения я взял чужой инструмент. В движке автоматизации n8n рабочий процесс собирают из нод, и каждая нода — это вход для получения данных, функция для их обработки или выход для отправки.

Аналогия моя: границу между «письмо пришло» и «что в письме написано» я не считаю особенностью Яндекс 360. Будете менять инструмент автоматизации — задайте новому прежний вопрос: откуда он возьмёт сумму и контрагента.

Что ИИ-конвейер вставляет в разрыв

Если счета у вас разбирают вручную, часы уходят на рутину. Под такую работу компания «+Альянс» строит ИИ-конвейеры обработки данных. Шагов в услуге пять: разбор потока, проектирование конвейера, сборка и интеграция, тест на реальных данных, запуск и передача.

На шаге проектирования мы описываем цепочку из четырёх звеньев: источник → распознавание и извлечение данных ИИ → проверка → запись в целевую систему.

В ИИ-конвейере компании «+Альянс» документ читает второе звено цепочки. Оно достаёт из счёта всё, что возможно, — например, сумму, контрагента и номер договора. Состав записи почтового метода AuditLogService_Mail от этого не меняется: извлечённые данные конвейер передаёт в целевую систему.

На шаге сборки мы подключаем ИИ-конвейер к вашим системам — 1С, CRM, Яндекс 360. Сценарии в Яндекс 360 при этом строим на «+Альянс Потоке». В журнале остаётся след каждого документа: когда он обработан и куда записан.

Инструмент компания «+Альянс» выбирает по задаче и требованиям к данным, а производитель модели Claude просит проверять прочитанное

Инструмент компания «+Альянс» подбирает в услуге «Внедрение ИИ-инструментов в бизнес-процессы». Мы сравниваем варианты под задачу и требования к данным: облачные сервисы — YandexGPT, GigaChat, Microsoft 365 Copilot — или модель в вашем контуре. Работаем и с облаком, и с моделями в контуре заказчика. Выбор определяют ваши требования к данным.

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

Теперь о цене распознавания. Для примера беру модель Claude. В перечне из трёх облачных сервисов её нет, это пример одного производителя.

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

Следом у Anthropic стоит требование, и я привожу его целиком: «Always carefully review and verify Claude's image interpretations, especially for high-stakes use cases. Do not use Claude for tasks requiring perfect precision or sensitive image analysis without human oversight» — всегда внимательно просматривать и проверять, как Claude истолковал изображение, особенно там, где ошибка дорого стоит, и не применять модель без человеческого контроля в задачах, требующих безупречной точности или анализа чувствительных изображений.

Оплата по неверно прочитанной сумме — как раз такой случай. Это уже моя оценка: у Anthropic речь об изображениях вообще.

Тут я остановился и посмотрел на другую сторону: на то, что модели дают на вход.

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

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

Как посмотреть на свои потоки

Разобрать свой поток документов можно в три захода.

1. Выпишите работу, которая начинается с готовых полей: завести сотрудника, отключить, выдать доступ, собрать отчёт. Такие сценарии мы собираем без программирования.
2. Выпишите работу, которая начинается с чтения документа: входящие счета, накладные, заявки в письмах.
3. Возьмите самый частый документ из тех, что приходится читать, и посчитайте, сколько их в месяц, сколько минут уходит на разбор одного и во что обходится ошибка в поле.

С тремя числами из третьего захода уже можно идти к подрядчику. В услуге «Создание ИИ-конвейеров обработки данных» мы начинаем с разбора потока: смотрим, какие документы и данные приходят, в каком виде и куда должны попадать. Всё сразу брать не надо: для пилота хватит одного типа документов.

Если инструментов сотни, а с чего начать и что даст измеримый эффект именно у вас — непонятно, подойдёт другая наша услуга, «Внедрение ИИ-инструментов в бизнес-процессы». Начинается она с аудита процессов. На руки вы получаете карту процессов с оценкой, где ИИ принесёт эффект и где себя не окупит. Инструменты мы встраиваем в рабочие сервисы — Яндекс 360, Microsoft 365, Битрикс24, 1С, — чтобы ИИ работал там, где работают люди.

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

У нас автоматизация уже настроена. Почему она не разбирает входящие счета?

Проверьте, откуда сценарий берёт сведения о письме. Почтовый метод AuditLogService_Mail из Яндекс 360 API сообщает отправителя, получателей и тему, а суммы и контрагента в его ответе нет. Эти данные лежат в самом документе, и его кто-то должен прочитать: сотрудник или ИИ. В услуге создания ИИ-конвейеров у компании «+Альянс» за чтение отвечает звено распознавания и извлечения данных. Сумму, контрагента и остальное, что возможно достать из счёта, даёт оно.

С чего начать, если документов много и все разные?

С одного типа документов, самого частого и однообразного. Так же стартует услуга «Создание ИИ-конвейеров обработки данных» у компании «+Альянс»: разумным стартом мы считаем пилотный конвейер на одном типе документов.

Сколько стоит такой проект?

Цену услуги «Создание ИИ-конвейеров обработки данных» компания «+Альянс» называет после разбора потока. Стоимость зависит от числа конвейеров и подключаемых систем. К разбору подготовьте три числа по самому частому документу: месячное количество, время на один документ и цену ошибки.

У компании «+Альянс» есть внедрённый ИИ-конвейер, на который можно посмотреть?

Нет. Проекты направления «Внедрение ИИ» у компании «+Альянс» сейчас на согласовании, внедрений у клиентов нет. Поэтому цифр эффекта в этой статье тоже нет. Результат вы увидите на своих документах. На шаге теста мы берём ваш исторический поток, прогоняем через ИИ-конвейер и сравниваем с тем, что сотрудники сделали вручную.

Где в ИИ-конвейере остаётся человек

Когда случай сомнительный, ИИ-конвейер компании «+Альянс» отдаёт его на проверку человеку, а не проводит молча. Во время теста на реальных данных мы сравниваем результат конвейера с ручной обработкой и настраиваем точки контроля человеком.

До теста решите, ошибка в каком поле обходится вам дороже всего. С этого поля я бы начинал разговор о проверке.

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

О правиле, по которому документ уходит на проверку, у меня есть отдельная статья с тремя вопросами подрядчику: «Гейтинг без ИИ и гейтинг с ИИ: кто решает, пропустить действие дальше».

Границу между машинной проверкой и человеческой, по-моему, проводит тот, кто отвечает за поток документов. Наше дело — её настроить.

---

Александр Жогов, основатель компании «+Альянс».

---