Как ИИ перебрал 22 000 файлов и спас историю сделок за 4 года

Мы в агентстве «Спираль» с 2022 года помогаем компаниям и экспертам продвигать бизнес в мессенджерах «Макс» и «Телеграм». CRM у нас не было, поэтому все данные по сделкам и клиентам годами копились в чатах, папках и личных переписках сотрудников.

Проблема: результаты работы компании за четыре года были разбросаны по чатам и папкам

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

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

Первые три попытки разобрать архив провалились

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

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

Что сделали: построили конвейер из ИИ‑агентов

Для начала провели два подготовительных этапа: выгрузили все данные и привели их к одному формату.

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

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

Когда данные были в едином формате, запустили систему агентов.

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

Агент для обработки документов. Основные агенты для нашей задачи, мы их называем их «агенты‑тракторы». Они извлекали из документов ключевые данные: информацию о контрагентах, суммы, даты и перечень услуг. За один проход один такой агент обрабатывал тридцать документов, а чтобы ускорить процесс, мы запускали одновременно от десяти до тридцати агентов‑тракторов.

После этого данные нужно было объединить. Для этого мы использовали два уровня сшивки:

• скрипт‑сшиватель — по формальным признакам объединял очевидно связанные документы. Например, находил совпадения по номерам счетов, суммам или другим реквизитам. Этот этап сокращал объем дальнейшей работы примерно на 20—30% и экономил токены;
• агент‑сшиватель — самый сложный и ресурсоемкий элемент всей системы. Он собрал полную историю каждой сделки: связывал между собой счет, договор, приложение, платежку и акт. К одной сделке могло относиться от десяти до пятнадцати строк таблицы, их нужно было сшить правильно.

Агент для итогового контроля. На старте проекта он перепроверял все результаты и помогал улучшать промпты для остальных агентов. Когда качество обработки стало стабильным, объем проверки сократили до 10% сделок.

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

Весь проект вел один сотрудник — наш финансовый директор. Для этого он не проходил отдельных курсов, просто был интерес и желание сделать работу удобнее и быстрее. Общие расходы на проект — около 30 000 ₽, включая подписки на Claude Code и использование моделей Opus и Sonnet.

Обнаружили неучтенные сделки на 300 000 ₽

Бонусом во время разбора обнаружили почти 30 неучтенных сделок на общую сумму около 300 000 ₽ — по которым работу выполнили, а оплату не получили. Также система выявила расхождения в документах и связи между файлами. В результате мы получили полноценную базу данных за все годы работы компании, и теперь поиск по любой сделке занимает одну‑две минуты.

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