Levity AI помогает разбирать входящие письма и вложения, классифицировать запросы, извлекать из документов реквизиты, строить маршруты обработки и передавать проверенные данные в TMS, CRM, ERP или службу поддержки; в одном рабочем процессе можно добавить правила, генерацию ответа, ручную проверку, аналитику и контроль качества.

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

Основные действия собраны в разделах Connections, Emails, Control Tower, Opportunities, Flows, Activity и Quality Control. Такое устройство интерфейса связывает анализ потока писем с построением автоматизации: сначала команда видит объём, категории и узкие места, затем открывает редактор цепочки, добавляет классификатор, извлечение, правила и интеграции, а после запуска контролирует ошибки и корректировки на тех же операционных данных.

Как устроено рабочее пространство

Левая панель задаёт последовательность работы. В Connections подключаются входные каналы и целевые системы, в Emails просматривается поток сообщений, в Control Tower собраны показатели, в Opportunities оцениваются кандидаты на автоматизацию, а в Flows редактируются действующие цепочки. Activity показывает исполнение шагов, тогда как Quality Control предназначен для разборов исключений, замечаний и повторяющихся дефектов. Пользователю не приходится держать отдельную таблицу для аналитики и отдельный конструктор для маршрутов: категории писем, правила обработки и результаты выполнения связаны между собой.

На главном аналитическом экране видны фильтр, поиск, выбор периода и несколько представлений данных. Пример интерфейса показывает график времени обработки, диаграмму уверенности по категориям писем и вкладки для разных направлений анализа. Справа открывается Ask AI: запрос формулируется обычной фразой, а ответ может содержать объяснение тренда и ссылки на конкретные письма, из которых сделан вывод. Это важно для операционной проверки: специалист видит не только итоговую цифру, но и сообщения, подтверждающие причину задержки или изменения показателя.

Структура не рассчитана на покадровое редактирование PDF. Документ здесь служит входными данными или вложением в коммуникационном процессе. Поэтому команды объединения страниц, наложения подписи, удаления листа, добавления комментария или изменения текста в макете не относятся к задачам Levity AI. Если требуется подготовить сам файл, его сначала приводят в порядок в PDF-редакторе, а затем передают в автоматизированный почтовый маршрут.

Подключение почтовых ящиков и каналов данных

Для анализа нужен доступ к рабочим ящикам. Система поддерживает личные и общие inbox-подключения, а на странице интеграций отдельно указаны Gmail и Outlook. Для Outlook предусмотрено соединение общих ящиков через OAuth или IMAP; Gmail используется для входящих и исходящих сообщений общих адресов. В проекте заранее определяют, какие папки и адреса участвуют в процессе, какие письма нельзя обрабатывать автоматически и куда должны попадать сообщения, не прошедшие классификацию.

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

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

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

Анализ писем и вложений

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

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

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

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

Control Tower и настраиваемые панели

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

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

Для совместной работы предусмотрены варианты Share with Team и Keep Private. Общую панель удобно использовать на ежедневной оперативной встрече, а приватную — для черновой проверки новых метрик. Перед публикацией стоит убрать персональные данные из названий виджетов и убедиться, что аудитория имеет право видеть письма, на которые ведут аналитические переходы. Сам факт доступности графика не означает, что каждому сотруднику должен быть открыт исходный документ.

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

Запросы к данным обычным языком

Chat with your Data используется, когда готового отчёта недостаточно. Вместо SQL-запроса сотрудник спрашивает, какие причины задержек встречались чаще, у каких перевозчиков больше отказов, сколько бронирований обработано за месяц или какие ящики получили максимальный объём. Ответ строится поверх подключённых операционных данных и может стать новым виджетом. Это ускоряет первичное исследование, но формулировка вопроса должна однозначно задавать период, объект и единицу измерения.

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

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

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

Поиск процессов с потенциалом автоматизации

Раздел Opportunities ищет повторяющиеся сценарии в потоке: запросы ставки, track and trace, подтверждения бронирования, документы и другие группы. Для каждой возможности оцениваются объём, средняя трудоёмкость, предполагаемая экономия и сложность внедрения. Команда видит не абстрактную рекомендацию автоматизировать почту, а конкретный кандидат с числом сообщений, шагами подключения и предполагаемым эффектом.

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

Хороший первый кандидат имеет большой объём, понятные входные данные и безопасный выход. Например, классификация входящих подтверждений и маршрутизация в нужную очередь обычно проще, чем полностью автоматическая отправка коммерческой ставки. Сложные процессы разбивают: сначала определить тип письма, затем извлечь поля, после этого получить данные из TMS, и лишь на последнем этапе сформировать ответ. Такой подход позволяет измерять качество каждого шага отдельно.

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

Редактор Flows и логика цепочки

В редакторе поток изображён как последовательность связанных карточек. Типичный пример начинается с Outlook или Gmail, затем проходит через Classifier, Extractor и HTTPS-запрос, после чего Router выбирает ветку, а AI Generation готовит текст. Карточки показывают входы и выходы: классификатор получает тему и тело письма, извлечение возвращает значения, HTTP-шаг передаёт их внешней системе, маршрутизатор проверяет ответ и выбирает дальнейшее действие.

Создание потока начинается с выбора приложения-триггера. В официальном интерфейсе в списке видны Outlook, Gmail, Zendesk, Teams, SharePoint, SAP и логистические системы. После выбора события о новом письме добавляется классификатор. Ветки должны иметь взаимоисключающие и понятные условия. Если категории запроса статуса и общего вопроса пересекаются, автоматизация будет нестабильной; лучше определить приоритет и отдельное правило для сообщений с недостаточной уверенностью.

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

Читаемость схемы влияет на сопровождение. Узлы называют по бизнес-действию, а не по техническому типу: например, Получить статус из TMS понятнее, чем HTTP Request 3. Критические правила размещают отдельными карточками и снабжают ясными условиями. Через несколько месяцев новый специалист должен понять цепочку без расшифровки длинных скрытых подсказок.

Классификация писем и документов

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

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

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

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

Извлечение данных из PDF-вложений

Extractor преобразует текст письма и содержимое документа в поля, пригодные для правил и интеграций. Для логистического запроса это могут быть номер перевозки, отправитель, получатель, пункт отправления, пункт назначения, дата, вес, объём, товар, тип оборудования, ставка и валюта. Для счёта — номер, дата, поставщик, сумма, налог, валюта и реквизиты заказа. Схема полей должна совпадать с тем, что ожидает TMS, ERP или CRM.

До запуска составляют словарь вариантов. Один и тот же номер может называться shipment ID, tracking number, booking reference или load ID. Вес приходит в килограммах, фунтах и тоннах; дата — в разных форматах; десятичный разделитель меняется по региону. Извлечение без нормализации создаст формально заполненные, но несовместимые значения. Поэтому после AI-шага добавляют правила приведения единиц, даты, валюты и адресов к корпоративному стандарту.

PDF с таблицами требует отдельной проверки. Поля могут находиться в шапке, строках спецификации и итогах, а многостраничный документ — повторять заголовки. Для счёта нельзя считать первое найденное число итоговой суммой. Схема должна различать subtotal, tax, total и balance due, а также связывать строки с правильной валютой. Если в одном файле несколько счетов или приложений, его лучше разделить до автоматического извлечения либо направить на ручную обработку.

Публичный интерфейс Quality Control показывает пример некорректного разбора приложенного счёта и отдельный тайм-аут для письма с большим PDF. Это подчёркивает два разных класса проблем: содержательная ошибка и техническое ограничение обработки. В первом случае корректируют схему, подсказку или обучающие примеры; во втором проверяют размер, число страниц, качество изображения и ограничения интеграции, а затем при необходимости уменьшают файл или отправляют его по резервному маршруту.

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

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

Правила, маршрутизация и внешние запросы

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

HTTPS-узел связывает поток с внутренним или внешним API. Перед передачей данных проверяют обязательные поля, формат идентификаторов и права учётной записи. Сетевой ответ также валидируют: код успешного запроса ещё не гарантирует, что в теле есть нужное значение. В Quality Control приведён пример необработанного ответа перевозчика с неверной структурой; для него требуется отдельная ветка исключения, журналирование и безопасный текст пользователю без технических подробностей.

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

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

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

Генерация черновиков и автоматические ответы

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

Шаблон ответа задаёт структуру, но не должен подставлять отсутствующие данные. Если ETA не получена, лучше написать, что статус уточняется, чем генерировать вероятную дату. Отдельно задают допустимый тон, подпись, язык и список запрещённых формулировок. В международной переписке следует явно определять часовой пояс и формат даты, иначе запись 03/04 может быть понята по-разному.

Для защиты от повторной отправки поток должен учитывать уникальный идентификатор сообщения и состояние обработки. На демонстрационной панели замечаний есть проблема дублированных ответов для одного запроса статуса. Практически это устраняют идемпотентностью: перед отправкой проверяют, не обработан ли тот же message ID, thread ID или бизнес-идентификатор, и сохраняют результат действия.

Черновик должен отвечать на запрос, а не пересказывать внутреннюю обработку. Технические названия узлов, коды ошибок и сырые ответы API остаются в Activity. Клиент получает понятное сообщение: статус, время обновления, недостающие данные или срок ручного уточнения. Для ошибок шаблон не обещает действия, которые система не может гарантировать.

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

Human in the Loop

Шаг Human in the Loop добавляется там, где решение нельзя доверить одному автоматическому результату. Рецензент видит извлечённые значения и контекст, исправляет поля, подтверждает действие или отклоняет его. Проверку можно ставить перед отправкой ставки, обновлением TMS, ответом по спорному статусу, обработкой крупного счёта или любым действием с высокой стоимостью ошибки.

Интерфейс проверки формируется под конкретный сценарий. Для track and trace достаточно номера перевозки, текущего статуса, ETA и кнопки создания ответа; для бронирования нужны перевозчик, маршрут, ставка и подтверждение; для котировки — адреса, вес, объём, тип груза и полученная цена. Чем меньше лишних полей, тем быстрее рецензент принимает решение и тем ниже риск пропустить критическое значение.

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

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

Очередь проверки требует SLA. Критичная ставка или изменение маршрута не должны ждать вместе с низкоприоритетным общим письмом. Записи сортируют по риску, сроку и клиенту; при просрочке уведомляют резервного сотрудника. Автоматизация без управления ручной очередью может лишь перенести задержку из почты в другой экран.

Интеграции с TMS, ERP, CRM и поддержкой

В каталоге подключений представлены транспортные системы, ERP, CRM, почтовые и аналитические инструменты. Среди указанных решений есть CargoWise, McLeod, MercuryGate, Revenova, Riege Scope, TAI, Transporeon, Trimble, Turvo, SAP, Oracle, NetSuite, Microsoft Dynamics 365, Salesforce, HubSpot, Gmail, Outlook, Front, Freshdesk, Intercom, ServiceNow, Zendesk, Slack, Teams, Looker, Power BI, Snowflake и Tableau. Для внутренних или устаревших систем предусмотрены настраиваемые интеграции.

Наличие названия в каталоге не означает, что подключение можно включить без подготовки. Требуются права, тестовая учётная запись, сопоставление полей и согласование направления обмена. Для TMS отдельно проверяют чтение статуса, создание или обновление перевозки, получение ставок и ограничения API. Для ERP — правила проводок, справочники контрагентов и допустимость записи финансовых данных. Для CRM — владельца записи, этап и защиту от дублей.

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

Тестовая и рабочая среды используют разные учётные данные и конечные точки. Случайное подключение staging к производственной почте или ERP может создать реальные записи во время проверки. ENV variables позволяют отделить адреса, токены и параметры, но команда должна документировать, какое значение используется в каждой среде.

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

Повторно используемые модули и компоненты

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

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

Готовые компоненты ускоряют сборку, но не заменяют проверку на корпоративных данных. Order Data Extractor должен быть сопоставлен с конкретной структурой заказа, Track and Trace Extractor — с идентификаторами перевозки, а модуль нормализации адреса — с географией и правилами компании. Универсальное название описывает назначение, а не гарантирует правильный результат без настройки.

Команда определяет владельца каждого общего модуля. Без владельца разные подразделения начнут менять один компонент под противоречивые требования. Для общего адресного нормализатора, например, фиксируют поддерживаемые страны, формат результата и порядок обработки неоднозначности. Локальные исключения лучше размещать в вызывающем потоке, а не усложнять базовый модуль.

Сценарий: запрос ставки

Поток spot quoting начинается с письма клиента. Классификатор определяет запрос ставки, Extractor получает пункт отправления, пункт назначения, дату, вес, объём, тип груза и дополнительные условия. Далее интеграция обращается к тарифному или транспортному инструменту, а правила проверяют доступность маршрута, валюту и пороги согласования. Результат превращается в черновик ответа либо карточку ручной проверки.

Самые опасные ошибки связаны не с грамматикой ответа, а с пропущенным условием. Опасный груз, температурный режим, особый тип оборудования, несколько участков маршрута или неявная валюта способны изменить цену. На панели Quality Control среди типовых замечаний показаны отсутствие поля для декларации опасного груза, невозможность указать предпочитаемого перевозчика по направлению и неуказанная валюта. Такие случаи требуют явных полей и обязательной проверки, а не свободной интерпретации текста.

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

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

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

Сценарий: track and trace

Для запроса статуса классификатор выделяет письмо, извлечение находит номер перевозки, HTTPS-шаг обращается к TMS или системе видимости, а генератор готовит ответ с текущим статусом и ETA. Если номер отсутствует, система просит уточнение; если найдено несколько записей, задача отправляется сотруднику; если внешний сервис недоступен, клиент получает нейтральное сообщение без выдуманного статуса.

Важна свежесть данных. Ответ должен содержать время последнего обновления и не представлять старую отметку как текущую. Для маршрутов с несколькими участками правила определяют, какой этап показывать и как трактовать пересадки. Демонстрационный Quality Control прямо отмечает потребность в поддержке multi-leg tracking, поэтому сложные перевозки нельзя без проверки сводить к одному статусу.

Слово ASAP нельзя автоматически превращать в точную дату. В списке замечаний есть пример такой неверной интерпретации. Правильнее классифицировать его как высокий приоритет, а срок получать из явного поля, SLA или подтверждённого ответа TMS. Аналогично выражения завтра утром и к концу дня требуют часового пояса и контекста отправителя.

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

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

Сценарий: бронирование и ввод заказа

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

Подтверждения часто приходят в PDF, в теле письма или одновременно в обоих местах. При расхождении заранее определяют приоритет. Например, подписанное подтверждение может считаться подтверждением ставки, а актуальная переписка — подтверждением даты. Решение фиксируют в правилах, иначе модель будет выбирать значение по контексту непредсказуемо.

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

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

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

Сценарий: счета и платёжные документы

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

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

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

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

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

Quality Control и обратная связь

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

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

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

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

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

Тестирование, staging и откат

Для производственных потоков заявлены staging и production, управление изменениями и откаты. Новую логику сначала проверяют в контролируемой среде. Набор тестов включает обычные письма, крайние случаи, пустые вложения, повреждённые файлы, большие PDF, повторные сообщения, сетевые ошибки, несколько совпадений и неожиданные ответы внешних систем. Каждая ветка должна завершаться предсказуемым действием.

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

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

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

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

Права, безопасность и работа с чувствительными данными

Платформа рассчитана на корпоративные процессы и указывает соответствие GDPR, сертификацию ISO 27001 и SOC 2 Type II. Эти признаки описывают организационные и технические меры поставщика, но заказчику всё равно нужно настроить собственную модель доступа. Подключение почты, просмотр исходных писем, изменение потоков, публикация панелей и подтверждение финансовых действий должны быть разделены по ролям.

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

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

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

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

Ограничения при работе с PDF

Levity AI не заменяет редактор PDF, OCR-станцию с ручной разметкой страниц или архивную систему. Его сильная сторона — обработка документа как части бизнес-процесса: распознать назначение, извлечь поля, вызвать систему, подготовить ответ и направить исключение. Для изменения макета, наложения подписи, сборки нескольких файлов, удаления страниц, редактирования текста и настройки защиты нужен отдельный инструмент.

Точность зависит от качества и разнообразия документов. Плохо читаемый скан, сложная таблица, рукописная пометка, несколько языков, нестандартная кодировка или вложенный файл могут потребовать предварительной обработки. Большие PDF способны вызвать тайм-аут; этот тип исключения показан в интерфейсе контроля качества. В рабочем процессе предусматривают ограничение размера, проверку числа страниц, сжатие или ручной маршрут.

Не следует обещать полную автоматизацию на основании демонстрационного примера. Даже платформы IDP требуют ручной валидации для низкой уверенности и исключений. У Levity AI такой контроль встроен в поток, но пороги и интерфейс проверки должен определить заказчик. Чем выше цена ошибки, тем больше внимания уделяют ручному подтверждению и журналу действий.

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

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

Типовые ошибки и способы устранения

Вложение не обработано

Проверяют, действительно ли файл доступен учётной записи, поддерживается ли его структура, не защищён ли он паролем и не превышает ли практический лимит процесса. Затем открывают Activity и Quality Control, определяют шаг отказа и повторяют тест с уменьшенной копией. Если проблема связана с конкретным шаблоном, добавляют примеры и отдельное правило; если с форматом — направляют файл на предварительное преобразование.

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

Поля извлечены неверно

Сравнивают исходный документ, ожидаемую схему и значения на выходе Extractor. Уточняют описание поля, добавляют контрпримеры, разделяют похожие реквизиты и вводят проверку формата. Для суммы задают валюту и допустимый диапазон, для даты — формат и часовой пояс, для номера — регулярность или справочник. Исправление тестируют на старых и новых документах.

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

Ответ отправлен дважды

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

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

Внешняя система вернула ошибку

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

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

AI неверно понял приоритет

Слова ASAP, urgent и immediately используют как признаки срочности, но не как точную дату. Вводят отдельное поле приоритета и правило SLA. Если дата отсутствует, система запрашивает уточнение или передаёт письмо сотруднику. Это предотвращает выдуманные сроки и неверные обещания клиенту.

Приоритет отправителя не всегда равен приоритету бизнеса. Массовое письмо с пометкой urgent может быть менее важно, чем тихое уведомление о таможенной задержке. Финальное правило учитывает категорию, клиента, событие и срок, а не одно слово.

Письмо попало не в ту очередь

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

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

В черновике отсутствует важная оговорка

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

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

Как подготовить пилот

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

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

Перед production определяют пороги ручной проверки, ответственных за исключения, расписание контроля, порядок отката и способ уведомления пользователей. Первые недели сравнивают автоматические результаты с ручным эталоном. Увеличивать автономность следует поэтапно: сначала маршрутизация, затем подготовка черновиков, затем запись безопасных полей и лишь после этого автоматические внешние действия.

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

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

Метрики качества и эффективности

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

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

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

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

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

Доля Human in the Loop сама по себе не является отрицательной метрикой. Для рискованных процессов ручная проверка может быть обязательной и ожидаемой. Важнее, сколько времени занимает проверка, какие поля исправляются и уменьшается ли число повторяющихся дефектов. Если рецензент каждый раз меняет один реквизит, проблема должна перейти в Quality Control и получить владельца.

Управление изменениями в операционной команде

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

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

Изменение роли сотрудника обсуждают заранее. Повторяющееся копирование данных сокращается, но возрастает значение контроля исключений, анализа качества и работы со сложными клиентскими случаями. Очередь Human in the Loop должна быть частью нормального процесса, а не восприниматься как провал автоматизации. Для неё выделяют время, приоритеты и ответственных.

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

Обратная связь должна быть конкретной. Сообщение AI ошибся недостаточно. Пользователь указывает письмо, ожидаемый результат, неверное поле или действие и влияние на процесс. Quality Control затем объединяет похожие случаи и позволяет приоритизировать исправление. Чем точнее исходное замечание, тем легче проверить предложенную правку на регрессионном наборе.

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

Контрольный список перед включением автоматической отправки

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

Тестовая выборка включает новые письма, ответы в цепочке, пересылки, несколько вложений, отсутствие вложения, длинный PDF, неизвестный номер, несколько совпадений, временный отказ API и повторное событие. Успешный результат оценивается не только по тексту, но и по тому, что внешняя система получила правильное действие один раз.

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

После включения устанавливают период усиленного наблюдения. Первые автоматические ответы регулярно выборочно проверяют, а критичные категории продолжают проходить через Human in the Loop. При обнаружении системной ошибки отправку приостанавливают, оценивают затронутые письма и откатывают изменение. Исправление выпускают только после повторного прогона всего набора.

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

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

Сравнение Levity AI с аналогами

Программа	Лучше подходит для	Главное ограничение
Levity AI	Логистических писем, вложений, TMS-интеграций и ответов	Требует проектной настройки и доступа через демонстрацию
Rossum	Транзакционных документов, счетов и очередей валидации	Фокус уже, чем комплексная автоматизация переписки
Nanonets	OCR, извлечения данных и документных workflow	Качество зависит от шаблонов и обучающей выборки
UiPath Document Understanding	Документов внутри крупной RPA-экосистемы	Внедрение требует компетенций UiPath
Hyperscience	Высоконагруженного корпоративного IDP и ручной валидации	Ориентирован на масштабные корпоративные проекты

Levity AI выбирают, когда задача начинается в почте и должна закончиться действием в TMS, CRM, ERP или службе поддержки, а логистические сценарии важнее универсального OCR. Rossum удобнее для потока транзакционных документов и валидации счетов. Nanonets подходит командам, которым нужен гибкий документный OCR и извлечение. UiPath Document Understanding логичен в организации, уже использующей роботов UiPath. Hyperscience рассматривают для крупных IDP-процессов с формализованной точностью и масштабной ручной проверкой.

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

PDF Commander не включён в таблицу, потому что решает другой класс задач: редактирует содержимое и страницы PDF, тогда как Levity AI извлекает данные и управляет процессом вокруг документа. Эти инструменты могут дополнять друг друга, но не являются прямыми заменами. Подготовленный в редакторе файл может стать входом автоматизации, а полученный из почты документ — потребовать отдельного ручного редактирования.

Кому подходит Levity AI

Система оправдана у компаний, где значительная часть операций проходит через общие почтовые ящики и требует чтения вложений, обращения к нескольким системам и подготовки ответов. Наиболее очевидные сценарии — экспедирование, брокерские и транспортные команды, централизованный track and trace, ввод заказов, котировки, обработка документов, дебиторская и кредиторская задолженность.

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

Решение также требует владельца процесса. Без человека, который определяет категории, поля, правила и допустимый риск, автоматизация превратится в набор неясных AI-шагов. Хороший владелец связывает техническую схему с операционными показателями, регулярно просматривает Quality Control и принимает решение, когда уменьшать или увеличивать ручной контроль.

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

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

Практический порядок ежедневной работы

Оператор начинает с панели и проверяет объём, исключения и изменения времени ответа. Затем открывает Quality Control, сортирует критичные и высокие замечания, просматривает новые повторяющиеся темы. Если проблема единичная, её обрабатывают вручную; если повторяется, связывают с шагом потока и готовят исправление. Изменение проходит staging и только после тестов попадает в production.

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

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

Каждый день проверяют необработанные и зависшие записи. Длительное ожидание может означать недоступный API, отсутствие рецензента или письмо, которое не попало ни в одну ветку. Для таких случаев нужен тайм-аут и явное уведомление, иначе ошибка останется скрытой до жалобы клиента.

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

Итог

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

Успешное внедрение строится на реальной выборке, чёткой схеме полей, измеримых метриках и постепенном увеличении автономности. Большие PDF, неоднозначные формулировки, пересланные цепочки, неполные реквизиты и нестабильные API заранее рассматриваются как нормальные исключения. При таком подходе Control Tower показывает эффект, Flows выполняет повторяемую работу, Human in the Loop удерживает риск, а Quality Control превращает ошибки в проверяемые улучшения.