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

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

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Заявка приходит на почту, менеджер её видит через час, переносит в CRM руками, забывает поставить срок. Знакомая цепочка? В ней теряется от десяти до тридцати процентов обращений — и вы за них уже заплатили.

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

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

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

Как работает автоматизация заявок

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

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

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

Четыре точки разрыва — пройдите по ним и отметьте свои.

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

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

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

Пять шагов от письма до задачи

Пройдите их по своему потоку — на каждом шаге отмечайте, что у вас уже есть.

Соберёте это за неделю. Первые два шага дадут вам результат сразу, остальные — потом.

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

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

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

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

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

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

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

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

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

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

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

Ваш ориентир: статус должен меняться от события в системе, а не от того, вспомнил ли менеджер его переставить.

Проверьте свои: если статус меняет человек вручную и по памяти, ваши отчёты показывают не реальность, а намерения.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты обрабатываешь один документ клиента для юридического дела.
На входе — текст, полученный через 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, а в продажах: менеджеры при продаже говорили клиентам, что спешить не нужно, начать можно когда угодно. Клиент расслаблялся и не присылал документы месяцами — автоматика честно фиксировала статус «ожидаем документы», но не могла заставить человека прислать файл.

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

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

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

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

Считайте от потерь: сколько заявок вы теряете сейчас и сколько стоит одна.

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

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

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

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

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

Что мы не считаем эффектом: часы, которые модель освободила у менеджеров на этапе определения типа заявки, но которые компания не сократила, а перераспределила на другие задачи (например, на дозвон по зависшим сделкам) — это перераспределение нагрузки, а не деньги в кассе.

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

Ваш чек-лист на понедельник

Первые два пункта не требуют ни техники, ни денег.

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

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

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

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

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

Как собрать обработку заявок так, чтобы ни одна не терялась, — механика в бесплатном курсе.

Что дало больше всего эффекта

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

Если у вас сейчас так же — начните с этого правила, оно бесплатное. Автоматизацию поставите поверх.

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

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

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

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

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

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

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

Автоматизация заявок — это то же самое, что «обработка заявок» удалённо или на дому?

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

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