директор и машина · производственный цикл · запись № 003 · 8 июня 2026 · Давид Герштейн

Автоматизация обработки заявок: от письма в почте до задачи со сроком

Форма на сайте отвечала клиенту за 3 секунды. Для человека это незаметно. Для системы — риск: если в этот момент падает приёмщик заявки, данные теряются безвозвратно, а заявка просто не появляется нигде. Мы поставили плагин, который снизил отклик до 80 миллисекунд, и добавили буферизацию на случай сбоя. Заявка теперь не пропадает, даже если сервер на другом конце не ответил вовремя.

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

Что теряется между письмом и задачей

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

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

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

Механика автоматизации обработки заявок: пять шагов от письма до задачи

Ниже — пять шагов, которые мы видели в каждой команде, с которой работали.

1. Приём. Форма, почта или мессенджер отправляют данные в приёмщик заявки (вебхук или почтовый коннектор). Приёмщик должен отвечать быстро и буферизовать заявку локально — если основная система недоступна, данные не теряются, а ждут в очереди на повторную отправку.
2. Определение типа. Дешёвая модель или простое правило смотрит на содержимое заявки и присваивает тип: новый лид, запрос документа, жалоба, запрос статуса. От типа зависит, в какую воронку и к какому процессу заявка пойдёт дальше.
3. Маршрутизация. Заявка попадает в нужную воронку CRM и получает ответственного — по правилу (например, по региону или типу услуги), а не по принципу «кто увидел первым».
4. Назначение срока. На основе типа заявки и регламента системе присваивается дедлайн этапа. Без этого пункта заявка формально «в работе», но фактически может лежать сколько угодно.
5. Контроль. Если срок нарушен, система создаёт задачу не только менеджеру, но и контролю качества — отдельным уведомлением, а не строкой в общем отчёте, которую никто не открывает.

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

Маршрутизация заявок: одна воронка или пять

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

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

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

Автоматическая структура при создании клиента

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

Статусы заказов, которые не врут

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

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

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

Статус по расписанию, а не по настроению

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

Подробнее о том, как CRM способна незаметно искажать даты и статусы даже без злого умысла менеджера, я разбирал в статье CRM врёт. Как я поймал Битрикс24 на сдвиге дат.

ИИ-связка: конвейер обработки документа внутри заявки

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

Схема: файл документа попадает в карточку сделки через загрузку в CRM или в клиентский портал → вебхук ловит событие добавления файла → облачная функция прогоняет файл через OCR → текст уходит в языковую модель с промптом ниже → структурированный ответ парсится и записывается обратно в поля сделки → если качество скана низкое или документ перевёрнут — создаётся задача менеджеру на ручную проверку.

Модель на этом шаге — дешёвая (Claude Sonnet, а не Opus): задача массовая, повторяющаяся, не требует «рассуждений» — только извлечение полей по инструкции. Дорогую модель имеет смысл подключать только на втором проходе, если дешёвая вернула низкий скор уверенности или явное несовпадение типа документа.

Модель: Claude 3.5 Sonnet (дешёвая, задача — извлечение и классификация, не финальное решение по кейсу).

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

Входные данные (Bitrix24-вебхук, поля сделки):
{
  "document_text": "{{ocr_text}}",
  "document_type_hint": "{{deal.UF_DOC_TYPE}}",
  "client_id": "{{deal.ID}}"
}

Задача:
1. Определи фактический тип документа из списка:
   [паспорт, свидетельство о рождении, справка, архивная выписка, другое].
2. Если document_type_hint не совпадает с фактическим типом —
   укажи это в поле mismatch.
3. Извлеки ФИО, дату документа, орган выдачи.
   Если поле нечитаемо — ставь null, не придумывай значение.
4. Оцени качество скана по шкале 1–5 (1 — нечитаемо, 5 — отлично).
5. Если текст выглядит перевёрнутым или зеркальным —
   укажи orientation_issue = true.

Формат ответа строго такой:
{
  "detected_type": "...",
  "mismatch": false,
  "extracted": {"full_name": "...", "doc_date": "...", "issuer": "..."},
  "quality_score": 0,
  "orientation_issue": false
}

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

{
  "detected_type": "свидетельство о рождении",
  "mismatch": true,
  "extracted": {
    "full_name": "Иванов Иван Иванович",
    "doc_date": "1985-03-12",
    "issuer": "ЗАГС г. Н."
  },
  "quality_score": 3,
  "orientation_issue": true
}

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

Инженерная обвязка

Конвейер крутится на связке: событие в Bitrix24 (файл добавлен в карточку сделки) → облачная функция как посредник → OCR-сервис → вызов модели по API → запись результата в пользовательские поля сделки через REST API (crm.deal.update). Если quality_score ниже 3 или orientation_issue = true — автоматически создаётся задача менеджеру «проверить документ вручную».

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

Для снижения нагрузки на модели и уменьшения количества галлюцинаций мы также подняли MCP-сервер на базе CRM, чтобы ИИ-инструменты работали с корпоративными данными напрямую, а не через общий контекст без привязки к специфике компании. Это снизило потребление токенов на 30–40% — но это отдельная инициатива, её эффект я не приплюсовываю к экономике самой обработки заявок ниже, это разные вещи с разной окупаемостью.

Где очередь заявок реально стопорится

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

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

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

Столбики не в масштабе миллисекунд — они показывают направление изменения. Отклик формы сократился с 3000 мс до 80 мс после установки плагина-приёмщика с буферизацией на случай сбоя.

Экономика: что это стоит и что даёт

Считаю по каждому механизму отдельно, честно, без смешивания эффектов.

Буферизация приёмщика заявки (3000 мс → 80 мс + очередь на сбой). Стоимость внедрения — разработка и тестирование плагина, оценка 8–12 часов работы разработчика. Эффект — не часы, а снятый риск: без буферизации при сбое приёмщика заявка исчезает безвозвратно, и посчитать её в деньгах можно только через объём потерянных обращений, который мы не готовы называть точной цифрой. Грубая иллюстрация масштаба риска, а не заработка: если бы терялась хотя бы одна заявка в неделю (оценка, консервативно занижена), это несколько заявок в месяц, которые просто не появлялись бы нигде в системе — по объёму сопоставимо с недельной выработкой одного менеджера, исчезающей бесследно. Честнее сказать так: это страховка, а не источник экономии часов.

Автоматическая задача на откат сделки после неуспешной проверки. До автоматизации менеджер тратил на ручной откат и (не всегда) удаление старой даты, по грубой оценке, 10–15 минут на сделку, включая размышление «не забыл ли я что-то». При заметном потоке таких откатов в месяц это несколько часов ручной работы — почти целый рабочий день менеджера, потраченный впустую (оценка). После автоматизации это время сжимается до 1–2 минут на подтверждение задачи — тот же объём сделок укладывается в существенно меньшее время, то есть экономия порядка нескольких часов в месяц, больше половины рабочего дня менеджера, освобождённого для реальных сделок (оценка).

Срок в договоре + автоматический подъём просроченных сделок. Здесь эффект не в часах, а в размороженной выручке. Пример на цифрах из практики: несколько десятков клиентов зависли на этапе «документы запрошены». Условно, отдел из нескольких менеджеров ведёт несколько сотен активных сделок в месяц — то есть в заморозке оказалось около 10% всего портфеля отдела (оценка, не про потерянные деньги, а про долю оборота, которую автоматизация возвращает в движение за счёт срока и трёх фиксированных попыток связи). Формула для вашего случая: число сделок, зависших на самом узком этапе воронки, разделить на общее число активных сделок отдела — это и есть доля оборота, замороженная прямо сейчас.

Логирование конвейера обработки документов. Стоимость — настройка прокси-сервиса и таблицы логов, оценка 10–15 часов разработчика разово, дальше почти бесплатно в эксплуатации (стоимость хранения строк в таблице пренебрежимо мала). До логирования разбор одной причины сбоя занимал у разработчика, по нашей оценке, 2–4 часа — приходилось вручную сверять записи в разных сервисах. При заметном числе сбоев в месяц это несколько десятков часов работы разработчика — фактически несколько рабочих дней, уходящих на ручную сверку логов вместо разработки (оценка, консервативно). После внедрения лога разбор занимает 10–15 минут: причина видна сразу в одной из трёх колонок. Это в первую очередь снижение риска простоя конвейера, а не только прямая экономия часов.

Итого: маршрутизация, статусы, сроки и обвязка конвейера документов из этой статьи — один контур эффекта. MCP-сервер и точность OCR — другой, отдельно посчитанный контур, он разобран в других материалах.

Чек-лист: с чего начать в понедельник

• Проверьте приёмщик заявок: что происходит с данными, если сервер на другом конце недоступен 5 секунд — теряются они или ждут в очереди.
• Найдите в CRM все статусы, которые можно поставить без прикреплённого файла или без обязательного поля причины — закройте эти лазейки первыми.
• Посчитайте, сколько сделок сейчас висит на самом длинном этапе воронки, и сравните со сроком, который прописан (или не прописан) в договоре.
• Добавьте в договор срок действия услуги для стандартных работ и правило «три неотвеченных контакта — отказ», если у вас ещё нет такой страховки.
• Заведите один общий лог для любого автоматического конвейера — успешно/не обработано/ошибка — прежде чем добавлять в него модель.
• Определите, какие два-три типа документов или заявок дают больше всего ручной работы, и начните автоматизацию с промпта под них, а не со всего потока сразу.

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

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

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

Что такое маршрутизация заявок в CRM?

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

Как автоматизировать статусы заказов, чтобы они не врали?

Фиксировать статус по расписанию в отдельный неизменяемый столбец и требовать обязательное поле причины при любом откате сделки назад.

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

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

#автоматизация #ии и нейросети #контроль и надёжность