Обработка писем в Make звучит как что-то скучно-техническое, но именно она часто решает, успевают ли ваши команды жить, а не только разгребать входящий хаос. Когда я впервые показываю на проектах, как настраивается make обработка писем в три шага с AI-классификацией, люди обычно удивляются не тому, что это возможно, а тому, что это вообще можно сделать аккуратно по 152-ФЗ и без серых зон. В российских реалиях автоматизация почты — это не только про удобство, но и про «как бы ничего лишнего не утекло за границу» и «как документально доказать, что всё делали по правилам». В этой статье я разложу по полочкам, как в России можно организовать обработку писем через Make с AI-классификацией, не вынося ПДн за рубеж и не наступив на любимые грабли Роскомнадзора.
У меня есть одна героиня, с которой я часто мысленно пью чай, когда открываю новый почтовый ящик проекта. Света из маркетинга в крупном интернет-сервисе получила «в подарок» общий ящик marketing@ и 250+ писем в день — от лидов, подрядчиков, партнёров и людей, которые просто перепутали адрес. Через месяц она поняла, что больше занимается сортировкой, чем самой маркетинговой работой, а часть писем с заявками на крупные бюджеты просто теряется в потоке. Мы с ней решили: хватит героизма, делаем обработку писем через Make и учим AI раскладывать всё это по «ящикам», но по-белому, без полёта ПДн за океан. Сейчас покажу, как мы к этому пришли и как это можно повторить без боли.
Время чтения: примерно 15-18 минут
Я часто начинаю разбор почтовых процессов одинаково: открываю общий ящик, делаю пару глотков уже остывшего кофе и просто листаю письма подряд минут десять. Это самый честный аудит без слайдов и красивых презентаций — видно всё: хаос тем, вложения с паспортами, клиентские истерики, забытые лиды, диалоги длиной в войну и мир. В российской реальности к этому добавляется ещё один слой: всё это — потенциальные персональные данные, причём иногда очень чувствительные, и просто «скинуть всё в умный зарубежный AI» уже не звучит как хорошая идея. Точнее, звучит, но для Роскомнадзора это будет совсем другая история.
На одном из проектов, где мы потом делали make обработку писем, я насчитала 17 разных типов обращений в одном почтовом ящике: от заявок партнёров и договоров до обращений по 152-ФЗ с просьбами удалить данные. Письма были на русском, с разной степенью вежливости и иногда с вложениями в виде «фото договора на столе у бабушки». Попробуй тут построить аккуратную воронку обработки без AI и правил — руками это либо превращается в пытку, либо в бесконечные ошибки распределения. И вот здесь автоматическая настройка классификации писем перестаёт быть игрушкой и превращается в просто нормальную гигиену процесса.
Зачем вообще трогать обработку писем в Make и какие реальные боли она закрывает
Как понять, что обработка писем переросла «ручной режим»
Я заметила, что почти все компании, которые ко мне приходят, примерно одинаково описывают почту: «ну да, у нас там бардак, но ребята пока справляются». Пока — ключевое слово, потому что при 50-70 письмах в день один человек действительно может держать всё в голове, а вот при 200+ начинается тихий ужас, который снаружи выглядит как вежливые «извините, ваш запрос потерялся». Обработка писем в Make становится актуальной не из любви к красивым диаграммам, а когда в отделе продаж пропадают горячие лиды, саппорт не успевает отвечать в срок SLA, а HR физически не видит часть откликов на вакансии. Это уже не про «удобнее», а про прямые потери денег и репутации.
Представь себе ситуацию: общий ящик support@, три менеджера, у каждого свой стиль работы, свои пометки, свои папки. Один очень дисциплинированный, второй отвечает только на «понравившиеся» письма, третий подключается время от времени. В итоге клиент пишет: «Срочно, не работает оплата», а письмо оказывается между рассылкой и откликом на вакансию, и никто за него не отвечает. Настройка классификации писем здесь решает сразу несколько задач: отделяет критичные обращения от инфошума, отправляет письма нужным людям и одновременно создаёт след в системе — тикет в трекере, задачу в CRM, запись в реестре обработки ПДн. Это означает, что вы перестаёте надеяться на память людей и начинаете опираться на процесс.
Чтобы было на что ориентироваться, я обычно проговариваю с командой несколько простых критериев, по которым видно, что пора автоматизировать:
- Правило: больше 100 писем в день на один общий ящик — ручная сортировка начинает сбоить.
- Правило: хотя бы 30-40 % писем повторяются по структуре и теме — есть смысл подключать AI и правила.
- Правило: есть просроченные ответы клиентам, которые никто не отследил — нужна прозрачность.
- Правило: в почте гуляют ПДн и сканы документов — нужно срочно приводить всё к требованиям 152-ФЗ.
Получается, что обработка писем через Make — это не про моду на нейросети, а про минимизацию человеческого фактора там, где люди уже объективно не справляются.
Почему в России нельзя просто «подключить любой AI и забыть»
Когда я первый раз столкнулась с задачей AI-классификации писем в крупной российской компании, ИТ-директор бодро сказал: «Сейчас подключим зарубежный сервис, он сам всё разберёт, нам же ничего не надо хранить». И вот здесь начинается самое интересное. Любое письмо, где есть ФИО, телефон, email или, не дай бог, паспорт, становится набором персональных данных, а если вы куда-то его отправляете автоматом, это уже трансграничная передача. А 152-ФЗ к 2025 году стал совсем не мягким, особенно в части локализации баз и прозрачности, кто, зачем и как трогает ПДн. Поэтому вариант «погнали, отправим всё в модный иностранный AI» в российских реалиях выглядит романтично, но недолго.
Вместо этого приходится думать архитектурно: где физически лежит почтовый ящик, через какие шлюзы письма проходят, где находится сам Make, и можно ли отправлять туда хоть какие-то куски текста. Иногда на этом этапе вскрывается интересный факт: компания уверена, что у неё всё в России, а почтовый сервис внезапно хостится за рубежом, и это не та неожиданность, которую хочется обнаружить в ходе проверки Роскомнадзора. Я поняла, что обсуждение обработки писем в Make без разговора про инфраструктуру и 152-ФЗ — это примерно как обсуждать ремонт без фундамента.
Чтобы это не повисало в воздухе, я формулирую для команд простую позицию, которую удобно обсуждать и с юристами, и с ИТ:
Если в письмах есть ПДн, то вся цепочка обработки — от почтового ящика до AI — должна либо находиться в РФ, либо работать с обезличенными данными так, чтобы нельзя было восстановить личность.
Света из маркетинга, кстати, именно на этом моменте перестала хотеть «просто подключить зарубежного бота» и согласилась, что придётся подумать на шаг глубже, чем захотелось в первый момент.
Как связать бизнес-эффект и юридическую чистоту процесса
На практике мне приходится балансировать между двумя крайностями: с одной стороны, бизнесу нужен эффект здесь и сейчас — сократить время обработки писем, не потерять ни одного лида, разгрузить людей. С другой — служба безопасности и юристы смотрят на всё это с точки зрения рисков, штрафов и потенциальных утечек. Логика понятна: один неудачный эксперимент с AI-классификацией писем, и потом год придётся объяснять регулятору, кто кому что отправлял и по какому правовому основанию. Это звучит мрачно, но, на мой взгляд, честно.
Я заметила, что рабочий подход всегда строится вокруг трёх простых вопросов, на которые нужно ответить до того, как в Make появится первый модуль обработки писем: откуда приходят письма, какие в них есть типы данных и что мы собираемся с ними делать дальше. Как только эти три точки понятны, становится легче выбирать инструменты и архитектуру: где мы используем AI-модели в РФ, где работаем правилами и регулярками, где оставляем человека в петле. В итоге настроенная обработка писем через Make выглядит как аккуратный конвейер: почта приходит, предфильтруется, классифицируется, ложится в нужную систему, а все чётко знают, что где хранится и сколько живёт.
Получается, что вся красота нейросетей и make обработка писем работают только тогда, когда под ними есть скучная, но честная база — понятные цели обработки, прописанные реестры и договорённость, что ПДн не путешествуют туда, куда им не положено. И вот после этого уже можно переходить к технике.
Как построить первый шаг: приём писем и предфильтрация без дыр в безопасности
Как организовать входящий шлюз для почты, чтобы Make не стал слабым звеном
Когда я первый раз объясняю команде, что обработка писем начинается не с Make, многие удивляются: казалось бы, есть почтовый ящик, есть сценарий, чем не счастье. Но если почтовый ящик живёт где-то за границей, а шлюз не фильтрует вложения, то дальше можно даже не продолжать — строить на этом AI-классификацию рискованно. В российском контексте базовая гигиена такая: почта должна храниться на серверах в РФ или как минимум у провайдера, который может документально это подтвердить, а перед Make письма должны пройти через антивирус, антиспам и, по возможности, санитайзер вложений.
Это критично, потому что Make в этой схеме — оркестратор, а не система защиты, и если в него поползёт вся почта без фильтрации, велика вероятность, что однажды туда же пролезет вредоносное вложение или что-то ещё неприятное. Я часто вижу, как компании сначала всё крутят вокруг «давайте научим AI», а потом вспоминают, что у них ни SPF, ни DKIM толком не настроены. Поэтому я начинаю с инфраструктуры: проверяю, где живёт почта, как настроены доменные записи, есть ли отдельный почтовый шлюз и что он умеет.
Чтобы не превращать это в лекцию по информационной безопасности, я обычно показываю команде один абзац с ключевым акцентом: почтовый ящик — это тоже информационная система, в которой обрабатываются ПДн, и к ней применимы все те же требования по защите и учёту. Как только это осознаётся, многим становится проще принять идею, что шлюз и фильтрация — это не «паранойя ИБ», а обычное условие для запуска автоматизации.
Как аккуратно подключить почтовый ящик к Make
Вот как это выглядит на практике: мы берём корпоративный почтовый ящик (например, на отечественном хостинге или на собственной инфраструктуре в РФ), настраиваем там отдельный ящик для обработки писем, скажем, routing@company.ru, и подключаем его к Make через IMAP или API. В идеале — через API провайдера, потому что это даёт чуть больше контроля и прозрачности, но IMAP тоже вполне рабочий вариант, если доступ ограничен и все соединения шифруются. В Make в качестве триггера выбираем модуль «New email» или его аналог, задаём папку (Inbox, отдельный label), настраиваем интервал проверки — и дальше каждый новый email становится входящим пакетом данных для сценария.
Звучит просто, но есть нюанс: в этот момент мы уже тащим в Make тело письма, заголовки и потенциально ПДн. Я помню один проект, где ИБ-специалист сначала кивнул, а потом через неделю пришёл со списком вопросов: где физически расположены сервера Make, как там шифруются данные, есть ли у нас гарантия, что текст писем не улетит на обучение чужих моделей. И это были очень уместные вопросы. Поэтому в российских реалиях есть два базовых подхода: либо использовать облачный Make только для обезличенных/нечувствительных данных (а тело письма обрабатывать локально), либо размещать рядом с Make дополнительные сервисы в РФ, которые берут на себя работу с ПДн.
Перед тем, как уйти дальше, я обычно проговариваю с командой устное правило в духе: всё, что мы отправляем в облако, должно выдержать проверку вопросом «я спокойно это покажу регулятору?». Это простая проверка на вменяемость архитектуры, и, как ни странно, она хорошо отрезвляет.
Как сразу заложить юридическую прозрачность: учёт и реестр обработки
На этом этапе многие говорят: «Ну мы же просто читаем письма и сортируем, зачем сюда ещё реестры и журналы». А затем, что с точки зрения 152-ФЗ это полноценный процесс обработки ПДн с использованием ИС, и к нему так и будут относиться. Чтобы не было ощущения, что я придираюсь, я показываю короткую формулу для реестра: какая категория ПДн приходит в письмах, в какой системе обрабатывается (почта, Make, CRM), с какими целями, как долго хранится и кому может передаваться. Это не про документы ради документов, это про то, чтобы через год вы сами вспомнили, что именно вы автоматизировали.
Я замечала, что как только появляется этот реестр, всем проще обсуждать спорные моменты. Например, можно сразу договориться, что письма с запросами по удалению данных маркируются и хранятся отдельно, а доступ к ним есть только у ответственных лиц. Или что письма с прикреплёнными паспортами кандидатов вообще не проходят через общий AI-процесс, а попадают сразу в защищённую HR-зону. Здесь работает непопулярная, но честная мысль: автоматизация без прозрачности учёта превращается в юридическую рулетку, и лучше не проверять, насколько вам повезёт.
Получается, что первый шаг обработки писем в Make — это не только подключить ящик, но и создать прозрачный входной шлюз: почта живёт в РФ, фильтруется, доступ в Make ограничен, реестры заведены. И только после этого можно спокойно переходить к самому вкусному — AI-классификации.
Как в Make собрать AI-классификацию писем в три шага и не уронить качество
Как выглядит базовая схема «принять — понять — разложить»
Возвращаясь к нашей Свете из маркетинга, у неё задача была очень приземлённая: автоматически отделять входящие заявки от подрядчиков, партнёров и клиентов, а также агрессивный спам и «непонятные просьбы». На бумаге решение выглядело как формула: принять письма безопасно, понять их с помощью AI и правил, разложить по нужным системам и ответственным. В Make это превращается в три логических шага внутри одного (или нескольких связанных) сценариев. На практике я разложила это ей на доске и сказала: «Смотри, нам нужно не чудо, а аккуратный конвейер».
Первый шаг — предобработка текста письма: забрать body, почистить HTML, выкинуть подписи и автоответы, оставить только смысловую часть. Это сильно повышает качество AI-классификации, потому что модель не путается в «С уважением, Иван» и цитируемых цепочках. Дальше второй шаг — отправить очищенный текст в AI-классификатор, который выдаёт метки, например: «заявка-клиент», «предложение-подрядчик», «жалоба», «спам/реклама» и уровень уверенности. И третий шаг — на основе этих меток и порогов уверенности развести письма по CRM, трекеру задач, отдельным папкам и спискам для ручной проверки.
Чтобы зафиксировать это в голове, я часто формулирую это так: 3 шага: принять безопасно — понять автоматически — положить в правильный ящик. В российской реальности к этому просто добавляется в скобках: «и при этом не вытащить ПДн за рубеж и всё задокументировать».
Как выбрать и подключить AI-классификатор, когда данные — российские
На этом шаге обычно начинается самая жаркая часть обсуждений. Кто-то предлагает взять готовый зарубежный AI-сервис, кто-то говорит «давайте вообще без AI, всё на регулярках», кто-то хочет писать свою модель. Я тестировала разные связки и поняла простую вещь: в российских условиях рабочими остаются два пути, и они не такие уж драматичные, как кажется. Первый — использовать отечественные AI-сервисы и модели, которые развернуты в РФ и готовы документально это подтвердить. Второй — запустить собственный классификатор внутри инфраструктуры компании и подключать его к Make через локальный API.
Звучит серьёзно, но на практике это иногда просто Docker-контейнер с моделью на сервере в РФ, который получает текст и отдаёт список меток. Make в этом случае видит только URL внутреннего сервиса и JSON на вход-выход. Я видела, как это делали и на базе готовых open-source моделей, и на базе коммерческих решений из российской экосистемы. При этом критичный момент — заранее договориться, что в этот AI-сервис мы не отправляем паспорта, номера карт и прочие сверхчувствительные вещи, а если такое в письмах бывает, то предварительно либо обрезаем тело, либо маскируем сущности (нет, подожди, тут не всегда всё так просто, но логика в этом есть).
Чтобы зафиксировать эту идею, я обычно проговариваю одну короткую мысль и показываю её на доске: AI-классификатор — это такой же подрядчик по обработке ПДн, и к нему применяются все те же требования по безопасности и договорам. В этот момент разговор из «давайте прикрутим модную нейросеть» превращается в нормальный диалог бизнеса, ИБ и юристов.
Как настроить в Make ветвление по уровню уверенности и не доверить AI слишком много
Классификация — это прекрасно, но я видела слишком много проектов, где AI получают права «судьи последней инстанции», а люди потом разгребают последствия. Чтобы этого избежать, я всегда закладываю в Make логику порогов уверенности. Например, если confidence модели по метке выше 0.85, письмо уходит в автоматическую обработку — создаётся тикет, лид, задача. Если между 0.6 и 0.85 — попадает в отдельный список для ручного просмотра ответственным. Если ниже 0.6 — вообще маркируется как «неклассифицированное» и никуда не роутится без человека. Это звучит как занудство, но на дистанции экономит очень много нервов.
Чтобы объяснить это визуально, я часто даю такую формулу и прошу её запомнить: AI + правила + человек в петле — только эта комбинация даёт устойчивое качество, особенно на старте. Правила — это регулярки для номеров заказов, явные признаки спама, ключевые слова для типовых запросов. Человек — это тот, кто смотрит на пограничные случаи и подправляет модель (хотя сама я так дообучала её не в первый же день, а когда накопилась хорошая выборка). AI — это ускоритель, но не единственный источник истины.
Помнишь про кофе из начала? Именно на этапе отладки порогов уверенности он обычно как раз и остывает, потому что приходится перебирать граничные кейсы, спорить с командой, где риск выше, и честно признавать, что некоторые письма в ближайшее время всё равно будут требовать человеческих глаз. Это нормально, автоматизация — не про волшебную кнопку, а про баланс скорости и точности.
Какие инструменты и архитектуры для обработки писем с AI работают в российских реалиях
Как выбрать, где будет жить AI и где — Make
Когда мы проектируем make обработку писем для российских компаний, приходится учитывать не только удобство, но и географию. Make как платформа оркестрации живёт в облаке, и нам нужно понимать, в какой юрисдикции фактически обрабатываются данные. Я честно скажу: были случаи, когда после детального разбора мы решали, что Make будет работать только с сильно ограниченным набором данных, а «тяжёлый» AI и обработка ПДн перенесутся в локальные сервисы. Это не поражение, а нормальный компромисс между комфортом и безопасностью.
Я замечала, что рабочая архитектура почти всегда сводится к одной из трёх схем. Первая — максимум логики в Make, AI-сервис в РФ, письма с ПДн разбираются на лету, сущности сохраняются в локальные CRM и трекеры. Вторая — Make используется как координационный слой, а основная логика (включая AI и хранение писем) живёт в инфраструктуре компании, а в Make уходит только метаданные и статусы. Третья — гибридная, когда часть простых процессов (например, классификация без ПДн) живёт в Make, а всё чувствительное обрабатывается отдельно. Звучит сложно, но на схеме обычно получается довольно опрятно.
Чтобы читателю было проще представить, я даю эту мысль с акцентом: Make — это не место хранения ПДн, а диспетчер маршрутов. Там можно и нужно делать логику, ветвления, трансформации, но хранить сканы паспортов и базы клиентов всё же лучше в контролируемых системах на российских серверах.
Как подружить Make, локальные AI-сервисы и системы учёта
Вот как это выглядит в более детальном виде (сейчас будет немного архитектуры, но без фанатизма). Почтовый сервер в РФ принимает письмо, шлюз фильтрует, Make забирает метаданные и тело письма. Дальше текст уходит на локальный AI-сервис по внутреннему API, который бегает в пределах российского контура. AI возвращает метку и, при необходимости, извлечённые сущности: ФИО, номер заказа, номер договора. Make на основе этого: создаёт лид в CRM, тикет в системе поддержки, уведомление DPO о письме, связанном с ПДн, пишет запись в реестр обработки (через DPO-платформу или хотя бы в отдельную БД).
На каких-то проектах для этого использовались готовые российские DPO-сервисы, где удобно вести единый реестр линий обработки, и Make просто писал туда через API, что «поступило письмо такого-то типа, обработано таким-то способом, цель такая-то». На других — всё хранилось в привычных SQL-базах и трекерах. Я поняла, что критично не то, какой именно инструмент выбран, а то, что цепочка остаётся прозрачной: от письма до записи в реестре можно пройти по следу без шаманства.
Здесь хорошо работает одно простое подчеркивание в голове: если вы не можете за пять минут ответить, где хранится каждое письмо и его обработанные сущности, архитектуру нужно упрощать. Звучит жёстко, но проще честно признать это на этапе проектирования, чем объяснять это комиссии после инцидента.
Как использовать опыт коллег и коллективный разум
Я часто вижу, как команды пытаются изобрести свои собственные велосипеды, хотя многие типовые решения уже разжёваны в профессиональных сообществах. У меня, например, в телеграм-канале про автоматизацию и AI-процессы регулярно всплывают вопросы про настройку классификации писем, маршрутизацию в CRM и трекеры, и я вижу, как люди друг друга страхуют: кто-то делится regex-паттернами, кто-то — примерами порогов уверенности, кто-то — аккуратными формулировками для юристов. Иногда одно такое обсуждение экономит неделю экспериментов.
Для тех, кто строит архитектуру «с нуля», я обычно советую не замыкаться в себе, а посмотреть, как эту задачу решали другие: какие типы писем они выделяли, какие ошибки ловили на старте, где у них проходила граница между AI и человеком. И тут уже дело не только в Make, а в общем подходе к автоматизации — он либо гуманистичный к людям и честный к данным, либо превращается в «давайте всё зальём в модель и посмотрим, что будет». Второе иногда кажется быстрее, но живёт недолго.
Получается, что выбор инструментов и архитектуры — это не про «правильно/неправильно», а про честный ответ на вопросы: где наши данные, кто за них отвечает и как Make вписывается в этот ландшафт. Если эти ответы звучат уверенно, дальше всё собирается уже значительно проще.
Какие ошибки в make обработке писем я встречаю чаще всего и как от них уйти
Что происходит, когда AI кормят всем подряд
Помнишь ту самую ситуацию со Светой и её 250 письмами в день? На одном из этапов она очень хотела «просто отправлять весь текст писем в модный AI-сервис, а потом уже разберёмся». Мы сели, выпили ещё один остывший кофе и стали по пунктам разбирать, что именно находится в этих письмах. Там были: полные ФИО клиентов, телефоны, адреса, иногда номера договоров и счёта, а в паре кейсов — вообще сканы договоров с паспортными данными. Отправить всё это в зарубежный сервис — звучит заманчиво, но чревато. В итоге мы договорились, что AI видит только обезличенные фрагменты текста, а всё, что пахнет ПДн, либо маскируется, либо обрабатывается отдельно (звучит строго, но по-другому в России сейчас уже просто опасно).
Я видела и другие крайности: когда компания сначала радостно настраивает отправку всего содержимого писем в внешнюю модель, а потом, уже после запуска, юристы обнаруживают это и начинают срочно всё выключать. Процесс ломается, люди разочаровываются в автоматизации в целом, хотя проблема была не в Make и не в AI, а в том, что никто не сел и не нарисовал границу между допустимым и недопустимым. Это тот случай, когда лучше потратить день на обсуждение политики обработки, чем месяц на ликвидацию последствий.
Я поняла, что рабочее правило звучит очень по-бытовому: если вы стесняетесь показать скриншот запроса с текстом письма регулятору, то такой запрос отправлять не надо. Оно не идеальное, но как быстрый фильтр работает неожиданно хорошо.
К чему приводит слепая вера в классификатор без порогов
Ещё одна ошибка, которую я встречала даже у очень опытных команд — это вера в то, что хорошая модель сама всё знает и не нуждается в контрольных порогах. В одном проекте AI по умолчанию считал почти все письма «некритичными», и автоответчик бодро высылал клиентам шаблонные письма благодарности за обращение, даже когда речь шла о серьёзных претензиях. Команда долго не могла понять, почему в соцсетях копятся негативные отзывы, пока мы не сели и не прошли глазами по выборке реальных писем, которые были отнесены к «простым запросам». Там было всё: от жалоб на недоступность сервиса до вопросов по возврату денег.
На практике я всегда прошу заложить в Make не только пороги уверенности модели, но и список тем, которые никогда не могут обрабатываться полностью автоматически. Это обращения по деньгам, юридическим вопросам, запросы по удалению ПДн, жалобы на сотрудников. Для них максимальная автоматизация — это аккуратное распознавание и быстрый роутинг на человека, но не генерация ответов от имени сервиса (нет, подожди, автоматические ответы тоже могут быть, но только как временное подтверждение, что обращение принято и с ним работает человек).
Чтобы это зафиксировать, я подчёркиваю одну простую идею: AI в обработке писем — это фильтр и помощник, но не заменитель ответственности. Как только это забывается, начинаются странные истории, которые потом разбирают на встречах с формулировками «ну мы думали, что…». Лучше думать чуть дольше до запуска.
Почему без честных метрик всё быстро скатывается обратно в хаос
Здесь я немного уйду вперёд, потому что метрики — это уже почти про результаты, но без них обсуждать ошибки бессмысленно. Когда мы запускали обработку писем через Make у Светы, я сразу попросила зафиксировать две цифры до старта: сколько времени в среднем уходит на разбор одного письма и какая доля писем обрабатывается с просрочкой. Без этого любое «нам стало легче» звучит как самоуспокоение, а не как измеримый эффект. Мы замерили: 2,5 минуты на одно письмо в среднем и около 30 % обращений, которые уходили в просрочку (причём многие из них — важные для бизнеса.
Через месяц после запуска AI-классификации и роутинга в Make те же метрики стали другими: 40-45 % писем разбирались и попадали в нужные системы автоматически, среднее время ручной обработки упало почти вдвое, а доля просроченных писем сократилась примерно до 10-12 %. Да, были шероховатости, да, часть писем всё ещё требовала ручного внимания, но общее ощущение стало совсем другим — не «мы тонем», а «мы разгребаемся и видим, где именно тонко». И это как раз та точка, где ошибки перестают пугать и начинают восприниматься как рабочий материал.
Получается, что самые распространённые провалы в make обработке писем связаны не столько с техникой, сколько с ожиданиями и отсутствием рамок: AI, которому доверили всё сразу, данные, которые отправили не туда, и результаты, которые никто не измерил. Как только эти три слоя приводятся в порядок, автоматизация становится заметно спокойнее.
Как понять, что автоматизация обработки писем в Make действительно работает
Какие метрики я прошу считать в первую очередь
Я заметила, что без измерений автоматизация живёт по принципу «кажется, стало лучше». Это приятно, но мало что даёт для развития процесса. Поэтому ещё до старта я прошу команду договориться о 3-5 базовых метриках. Обычно это: доля писем, которые были обработаны автоматически от входа до создания задачи/тика; среднее время до первого осмысленного ответа клиенту; доля писем, ушедших в просрочку относительно внутренних SLA; количество обращений, где потребовалась ручная переклассификация. Иногда добавляем пятое — время, которое сотрудники тратят на сортировку и поиск писем, но это уже опция.
На примере Светы картина выглядела так: до автоматизации примерно 70 % времени уходило на то, чтобы вообще понять, кому адресовано письмо и что с ним делать. После запуска AI-классификации это время сократилось почти вдвое, при том, что сами сотрудники поначалу были довольно скептичны (это нормально, когда тебя «автоматизируют», доверия мало). Через пару недель, когда люди увидели, что самые скучные, типовые письма действительно разбираются без их участия, а до них доходят более «живые» задачи, напряжение спало.
Чтобы зафиксировать эффект для менеджмента, я иногда суммирую это одним предложением и прошу обратить внимание: если система снимает хотя бы 40-60 % рутинной сортировки писем, это уже экономия нескольких человеко-часов в день. В пересчёте на месяцы и зарплаты это перестаёт быть «мелочью» и начинает выглядеть как очень вменяемый проект.
Чем история Светы закончилась и зачем я её вспоминаю
Помнишь нашу Свету из маркетинга, которая тонула в 250 письмах в день? Когда мы довели обработку писем через Make до рабочей версии, её цифры стали очень показательными. AI-классификация + правила в Make брали на себя в среднем 55-60 % потока: это были типовые запросы от подрядчиков, повторяющиеся вопросы по маркетинговым акциям, приглашения, которые шли в отдельную папку, и прочая рутинная корреспонденция. Оставшиеся 40-45 % писем шли на людей, но уже с понятными метками и маршрутизацией: заявки клиентов — в CRM, юридические вопросы — юристам, сложные кейсы — самой Свете и ключевым коллегам.
По времени получилось примерно так: в первый месяц после запуска количество часов, которые команда тратила именно на сортировку писем, сократилось примерно на 35-40 %. Доля потерянных или сильно просроченных обращений упала до 5-7 %, причём большинство из них были связаны не с AI, а с тем, что письма вообще приходили на неправильный адрес. Самое забавное (ну, для меня) было то, что через пару месяцев Света поймала себя на мысли: ей впервые за долгое время стало спокойно открывать общий ящик, потому что там был не необъятный хаос, а понятная структура.
Я люблю эту историю не за идеальные цифры, а за то, что в ней сошлись все три слоя: make обработка писем дала ощутимый эффект по времени, AI-классификация работала в российских реалиях без нарушения 152-ФЗ, а люди перестали воспринимать автоматизацию как угрозу. В итоге у Светы высвободилось примерно 8-10 часов в неделю, которые она смогла потратить на аналитику каналов и эксперименты, а не на ручной разбор почты. Если совсем приземлить, это почти два рабочих дня в месяц, возвращённых из почтовой бездны.
Получается, что хороший признак здоровой автоматизации — это не когда все в восторге, а когда через пару месяцев все уже спокойно воспринимают работу системы как «ну да, так и должно быть». В этой тишине и есть настоящий эффект.
Что ещё важно знать про AI-классификацию писем в Make
Можно ли отправлять письма целиком в зарубежные LLM для классификации?
Я бы не делала это для писем, где есть персональные данные или чувствительная информация. В российских реалиях такие действия могут считаться трансграничной передачей ПДн, и для этого нужны отдельные основания и меры защиты, которые редко кто реально выполняет. Гораздо безопаснее либо использовать модели, развернутые в РФ, либо обезличивать текст писем так, чтобы нельзя было восстановить личность отправителя.
Как понять, какую часть обработки писем можно автоматизировать без риска?
Самый безопасный старт — это типовые, повторяющиеся запросы без глубоких юридических и финансовых последствий. Например, статус заказа, запросы на материалы, общие вопросы по продукту, технические уточнения. Письма, связанные с деньгами, договорами, жалобами, правами субъектов ПДн, лучше всегда оставлять с человеком в петле, использовав AI только как фильтр и маршрутизатор.
Нужно ли отдельное согласие на обработку ПДн из писем клиентов?
Часто обработка ПДн в почте опирается не на согласие, а на другие основания, например исполнение договора или законный интерес при поддержке сервиса. Но это нужно честно зафиксировать в политике обработки и реестрах, а также описать, что именно делается с письмами и как они защищены. Если вы хотите использовать данные из писем для дополнительных целей, вроде обучения моделей или маркетинга, без отдельного согласия это делать нельзя.
Что делать, если в письмах часто приходят сканы паспортов и договоров?
В таком случае я бы отделила поток таких писем в отдельный защищённый контур и не пропускала их через общий AI-процесс. Можно настроить правила, которые по ключевым словам и типам вложений отправляют такие письма сразу в HR-зону или юридический отдел, где доступ ограничен. Хранить эти вложения стоит в защищённом локальном хранилище, с шифрованием и понятными сроками удаления.
Как встроить Make и AI-классификацию писем в общую систему комплаенса по 152-ФЗ?
Нужно описать этот процесс как отдельную линию обработки ПДн в реестре, указав источники (почтовые ящики), цели (поддержка, продажи, HR и т.д.), используемые системы (почта, Make, AI-сервис, CRM) и сроки хранения. Также важно назначить ответственных, настроить логирование доступа и периодически проверять, не изменились ли типы данных в письмах. Тогда автоматизация перестаёт быть «серой зоной» и становится частью прозрачной архитектуры безопасности.
Можно ли обойтись без AI и сделать всё на правилах и регулярках?
Теоретически да, особенно если у вас мало типов писем и они строго шаблонные. Но по мере роста потока и разнообразия формулировок правила начинают раздуваться и становятся хрупкими, их постоянно нужно поддерживать. AI-классификация даёт гибкость, а гибридный подход с правилами помогает удерживать качество, поэтому в средних и крупных потоках писем сочетание ML и правил обычно выигрывает.
Что делать, если Make по требованиям компании нельзя использовать для ПДн?
В этом случае Make можно оставить как оркестратор для обезличенных данных и метаданных, а работу с ПДн перенести в локальные сервисы и внутренние интеграции. Письма будут обрабатываться внутри инфраструктуры, а в Make отправляются только статусы, типы обращений и технические сигналы для дальнейшей маршрутизации. Такой подход позволяет сохранить удобство визуальных сценариев и при этом не нарушать внутренние политики безопасности.
Если ты дочитала до этого места и мысленно уже раскладываешь свои почтовые ящики по типам писем, это отличный момент сделать паузу и посмотреть, какие из идей можно примерить на свой контур уже сейчас. Для тех, кто хочет глубже разобраться в архитектурах, реестрах обработки и совсем не страшной стороне 152-ФЗ, я собираю разборы и практические кейсы у себя на сайте promaren.ru, а живые обсуждения, спорные вопросы и маленькие победы чаще всего случаются в телеграм-канале. Там мы вместе спорим, как лучше настроить пороги уверенности, делимся рабочими паттернами для Make и n8n и иногда смеёмся над особенно креативными письмами из общих ящиков — ну, чтобы вся эта автоматизация не казалась слишком серьёзной.
Метки: ai-agents, makecom, n8n, автоматизация, автопостинг, контент-план