Факты для отчёта живут в переписке: как их достают, размечают и проверяют

Почему цифры отчёта живут в переписке, а не в CRM

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

Масштаб потерь времени известен по двум старым, но всё ещё цитируемым замерам. The social economy McKinsey Global Institute (2012) оценивает: работник, чья работа состоит из взаимодействия, тратит около 28% недели на почту и почти 20% — на поиск внутренней информации и коллег. Там же оценка эффекта: когда внутренние сообщения становятся доступной для поиска записью, время на поиск может сократиться до 35%. Исследование американское и давнее, поэтому проценты показывают порядок величины, а не норму для вашего отдела.

Второй замер свежее и сделан на телеметрии: Work Trend Index 2023 от Microsoft (данные Microsoft 365 и опрос 31 000 человек в 31 стране) показывает, что 57% времени в приложениях уходит на коммуникации — 23% на встречи, 19% на чат, 15% на почту — и только 43% на создание документов. 62% респондентов говорят, что слишком много времени тратят на поиск информации. Оба исследования вендорские, часть данных — самоотчёт, но вывод не слабеет: переписка — место, где работа происходит, а не архив вокруг неё.

Что реально можно достать из письма и чата

Из переписки достают не «всё», а короткий список полей. Для операционного отчёта обычно хватает пяти-семи: кто обратился, по какому поводу, какая сумма, какой срок обещан, на чём остановились и кто следующий. Остальное — контекст для человека, а не колонка. Чем короче список, тем легче проверить извлечение.

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

Путь факта: от сообщения до строки в отчёте

Технически цепочка короткая: получить сообщение, привести к чистому тексту, вытащить поля, проверить, записать, показать. Ломается она обычно не на модели, а на первом и четвёртом шаге — на подготовке текста и на проверке.

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

Разметка: как понять, что извлечение работает

Разметка — это не бюрократия, а единственный способ получить число вместо ощущения. Нужен набор из 50–100 сообщений, размеченных вручную по тем же полям, что уходят в отчёт, и метрика: доля верных полей и отдельно доля пропусков. Дальше любое изменение промпта, модели или формата писем проверяется на этом наборе, а не на фразе «вроде стало лучше».

Публичный пример такого замера — задача Email Extraction в LangChain Benchmarks: 42 реальных письма из спам-папки и схема из шести полей — отправитель, адрес, телефон, тема, тон и список поручений. Точность по оценке модели-судьи — около 49% у GPT-3.5 и 57% у Claude. Набор маленький, состоит из спама, а модели — 2023 года, поэтому переносить эти проценты на свою переписку нельзя. Но порядок величины они передают честно: извлечение «как есть», без разметки, шаблонов и проверки, ошибается примерно в половине полей.

Три уровня доверия к извлечённой цифре

Практичнее делить извлечённые данные на три уровня доверия — и показывать их в отчёте по-разному. Один конвейер может выдавать поля всех трёх уровней, но доверие к ним разное.

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

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

Где извлечение упирается в предел

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

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

Как проверить, что дашборд не врёт

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

1. Доля пропусков: сколько сообщений дали поля, а сколько ушло в «не разобрано». Рост этой доли — первый признак, что изменился формат писем или появился новый канал.
2. Выборка на проверку: 10% сообщений разбираются вручную, причём выбирает их не тот, кто настраивал извлечение. Расхождение считается по полям, а не «в среднем».
3. Свежесть: когда последний раз приходили данные. Панель без даты обновления — не панель, а картинка.
4. Источник у числа: из любой цифры должен быть переход к сообщению, из которого она взята. Если перехода нет, ошибку не найти и не починить.

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

С чего начать: две недели на один отчёт

Порядок работ на старте лучше держать коротким — тогда через две недели будет что показать.

1. Выбрать один отчёт и один канал: например, входящие заявки из общего ящика за месяц. Не «вся переписка компании».
2. Выписать 5–7 полей, без которых отчёт не имеет смысла, и для каждого указать, где он лежит в тексте.
3. Разметить вручную 50–100 сообщений и посчитать, сколько полей извлекается верно. Это базовая точка, с которой потом сравнивают всё остальное.
4. Собрать конвейер: нормализация текста, извлечение по схеме, запись в таблицу со ссылкой на сообщение-источник.
5. Поставить проверку: 10% вручную раз в неделю, доля пропусков на панели, у каждого числа — переход к источнику. Дальше расширять по одному полю за раз.

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