# Директор и машина — Производственный цикл: полные тексты (часть 2 из 2)

Направление: Производственный цикл — документы и заявки · клиентский портал · сроки и статусы
Хаб направления: https://davidgerstein.pro/proizvodstvo/
Материалов в файле: 2 из 10 по направлению.
Автор: Давид Герштейн. Цитирование свободное при указании источника.
Суммы пересчитаны на условную компанию: пропорции, механика и выводы реальные, абсолютные величины изменены. «оценка» = расчёт, а не замер.
Оглавление всех частей: https://davidgerstein.pro/llms.txt
Все направления одним файлом: https://davidgerstein.pro/llms-full.txt
Цифры и словарь понятий: https://davidgerstein.pro/cifry/ · машинная копия: https://davidgerstein.pro/cifry.json
Другие части этого направления: https://davidgerstein.pro/llms-proizvodstvo.txt

## Электронный архив документов, который не разваливается, когда сотрудник уходит
URL: https://davidgerstein.pro/blog/elektronnyj-arhiv-dokumentov/
Дата: 2026-07-02
Направление: Производственный цикл
Цифры: несколько мест хранения документов одновременно у одной компании · пара десятков клиентов зависли на этапе «документы запрошены» · более сотни клиентов пострадали из-за устаревшего шаблона за один сезон
Коротко: Электронный архив документов работает, если структура папок создаётся автоматически при заведении клиента, файлы физически лежат в общем хранилище, а за шаблоны отвечает один конкретный человек. Без этих трёх правил компания теряет деньги на пустом месте: около 20 клиентов зависают на этапе «документы запрошены» — при чеке 180 тыс. ₽ это ≈3,6 млн ₽ замороженной выручки, а одна ошибка в шаблоне за сезон задевает больше сотни человек.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Проверьте себя: сколько времени у вас займёт найти договор с клиентом трёхлетней давности? Если вы честно отвечаете «спрошу у Марины» — у вас нет архива, у вас есть Марина. И когда она уйдёт в отпуск или уволится, вы это почувствуете очень остро. Архив кажется скучной темой ровно до первого раза, когда документ нужен срочно — юристу, налоговой, клиенту с претензией. Тогда выясняется, что папки на диске раскладывал каждый по-своему, а половина файлов называется «скан_итог_финал_2.pdf». Новый сотрудник пришёл в компанию — и выяснилось, что все документы его клиентов лежат на личном компьютере предыдущего менеджера. Не в CRM, не в общей папке. Передать дела оказалось невозможно: непонятно, какие кейсы на каком этапе, что уже собрано, чего не хватает. Электронный архив документов — это не про красивую папку в облаке. Это про то, переживает ли информация уход конкретного человека. Пока архива нет по-настоящему, каждый поиск файла — это блуждание по трём точкам одновременно: Google Drive, NextCloud, личный компьютер сотрудника. При потоке даже в восемь обращений в день на менеджера лишние минуты складываются в лишний час, а на отдел из восьми человек это уже ощутимые деньги — не за работу, а за беспорядок в хранении. Точный расчёт — в разделе «Экономика» ниже. Как организовать электронный архив документов в компании Три правила, и все три обязательны. Структура папок клиента создаётся автоматически при заведении карточки в CRM, а не руками. Файл физически лежит в общем хранилище — без файла статус «документ получен» не ставится. За каждый шаблон отвечает один человек по фамилии. На отделе из 8 менеджеров это ≈202 000 ₽ в месяц (оценка), которые сейчас уходят на поиск: 10 минут на документ вместо одной. Зачем архив, если «и так работает» Ваше «и так работает» держится на памяти двух-трёх человек. Это работает ровно до их отпуска. Пока в компании один-два человека держат в голове, где что лежит, всё действительно работает. Проблема вскрывается в трёх типовых точках: увольнение, отпуск, масштабирование. В одном проекте на время отпуска менеджера документооборот пришлось собирать вручную — через таблицу со всеми контрактами по клиентам, где назначенный сотрудник проверял поступление документов по фамилиям и отмечал прогресс, а руководитель потом подтверждал и уведомлял клиентов. Это сработало, но это ручная заплатка, а не система — она держится на конкретном человеке, который согласился подменить процесс на неделю. Ещё нагляднее случай с несколькими десятками клиентов, застрявшими на этапе «документы запрошены». Причина не техническая: менеджеры продаж говорили клиентам «можно не спешить, начнём когда угодно» — клиенты расслаблялись и просто не присылали документы. Решение оказалось не в архиве, а в договоре: срок действия услуги внесли туда сначала вручную, потом автоматически. Отсюда практический вывод: архив без сроков и без давления на клиента превращается в кладбище незавершённых кейсов, даже если структура папок идеальна. Масштаб проблемы легче увидеть в деньгах, а не только в штуках. При среднем чеке 180 тыс. ₽ и около 20 клиентах, зависших на этом этапе одновременно, получается ≈3,6 млн ₽ — это почти половина месячного оборота отдела продаж (9 млн ₽), которая не движется по воронке, пока документы не собраны. Это не потерянные деньги — это замороженные, и цена задержки растёт с каждым днём простоя. Правило Если документ клиента физически не лежит в общем хранилище, его не существует — независимо от того, что написано в статусе CRM. Устная договорённость «я знаю, где это» умирает вместе с сотрудником, который её держит. Это подтвердил случай с внешним специалистом: он собирал документы с марта, у сотрудника, который с ним взаимодействовал, не было доступа в CRM, вся работа шла через переписки и локальные папки. При передаче проекта восстановить историю удалось только частично. Как выстроить электронный архив документов: механика по шагам Порядок для вас — от того, что даёт результат сразу, к тому, что требует времени. Если вы дойдёте только до второго шага, у вас уже будет лучше, чем сейчас. Ниже последовательность, которую можно повторить с любой командой — без специальной разработки, на базе того, что обычно уже есть: CRM (Bitrix24 или amoCRM), облачное хранилище, Google Sheets для учёта. Аудит. Выписать все точки, где реально лежат файлы клиентов сейчас: Google Drive, NextCloud, личные компьютеры, вложения в CRM. Обычно находится несколько параллельных мест одновременно, и ни в одном нет полного комплекта. Единая точка входа. Выбрать одно хранилище (портал, облачную папку с жёсткой структурой) и договориться, что новые документы загружаются только туда. Старые — переносятся туда же в рамках отдельной задачи, а не «постепенно, по мере обращения». Шаблон структуры под процесс. Разделы папки клиента должны совпадать с реальными этапами работы (сбор материала → обработка → согласование → финал), а не с абстрактной классификацией «документы / прочее». Автосоздание структуры. При заведении новой карточки клиента в CRM вебхук создаёт в хранилище стандартный набор разделов автоматически. Робот раз в час проверяет появление новых файлов и прокидывает ссылки обратно в карточку. Жёсткая связка статуса и файла. Статус «документ получен» в CRM физически не может стоять без прикреплённого файла — это проверяется автоматически, а не по доброй воле менеджера. Ответственный за шаблоны. Один человек (юрист или руководитель направления) отвечает за актуальность форм и договоров, которые кладутся в архив как эталон. Структура папок, которая не разваливается через полгода Здесь вам важно понять один принцип: структура должна быть такой, чтобы новый сотрудник разложил документы правильно без объяснений. Если для раскладки нужно знать традиции компании — она развалится в первый же месяц после прихода нового человека. В проекте с производственным циклом из двух блоков — «производство» (интервью, сбор документов, составление материала) и «упаковка» (редактура, вёрстка, согласование макета, финальный выпуск) — при создании новой папки клиента в облачном хранилище теперь автоматически создаётся стандартный набор разделов: интервью, расшифровки, редактура, вёрстка и так далее. Робот ежечасно проверяет появление новых файлов и сам прокидывает ссылки в систему управления проектами. Это закрывает главный источник путаницы: раньше ответ на вопрос «где документ клиента» зависел от того, кто и когда его туда положил. Теперь ответ всегда один — папка в общем хранилище, структура которой не меняется в зависимости от того, кто ведёт клиента сейчас. Что делает структуру рабочей, а не декоративной Разделы создаются автоматически при заведении клиента — не по памяти сотрудника. Названия разделов совпадают с этапами реального процесса, а не с общей классификацией «документы / прочее». Есть автоматическая связка с CRM: новый файл в папке — это событие для системы, а не то, что нужно вручную прикреплять отдельно. Похожий принцип разбирали в статье про клиентский портал для среднего бизнеса — там же встаёт вопрос, стоит ли выносить хранение документов клиентам напрямую в личный кабинет или оставлять архив внутри компании. Хранение клиентских документов: где чаще всего теряют Сверьте со своей практикой — эти три места протекают почти у всех, и ваша компания вряд ли исключение. Самая опасная точка — не отсутствие системы, а имитация её наличия. В одном проекте менеджеры отмечали документы как «в наличии» в CRM, но не загружали сами файлы на сервер. Внешне процесс выглядел нормально: статус стоял, задача закрыта. На деле система, которая должна была обучаться на этих кейсах, начинала считать, что клиент может пройти проверку без документов вообще — потому что физического файла для анализа не было в природе. Это частный случай более широкой проблемы — менеджеры не вносят данные в CRM : если правило можно обойти без последствий, кто-то обязательно найдёт способ его обойти, и никакая структура папок это не исправит без проверки на уровне системы. Это не гипотетический риск, а системная ошибка, которая размножается сама. Если в компании планируется хоть какая-то автоматизация анализа документов — распознавание, оценка комплектности дела, поиск недостающих бумаг — качество этой автоматизации напрямую зависит от того, лежат ли файлы на самом деле, а не только в статусе. Подробнее о том, как в похожем проекте поднимали точность распознавания документов, — в статье про рост точности с 59% до 85% . Симптом Что происходит на самом деле Решение Документы «в наличии» в CRM Файл не загружен физически, только отметка Обязательная загрузка файла как условие смены статуса Разброс по Google Drive / NextCloud / компьютерам Нет единой точки входа, дублирование версий Централизованное хранилище с автосегментацией по типам Данные только у одного сотрудника Нет доступа в CRM у части команды Обязательный доступ + перенос из личных папок Ручной учёт через таблицу на время отпуска Система не рассчитана на замену человека Автоматический реестр статусов с историей изменений ИИ-связка: как архив кормит модель распознавания документов Здесь ваш архив превращается из склада в актив: разложенные документы — это то, на чём машина учится понимать именно ваши типы. Чем аккуратнее вы разложите сейчас, тем меньше вам придётся описывать потом. Электронный архив имеет смысл не только для людей — он же поставляет данные модели, которая распознаёт и оценивает документы. Конвейер строится в три ступени: определение типа документа → применение спецификации под этот тип → при неопределённости — эскалация на более мощную модель и ручная проверка менеджером. Именно так решили проблему в проекте, где вертикально загруженные документы сбивали алгоритм и путали имена с фамилиями: вместо того чтобы чинить распознавание сразу на всей базе, сначала собрали небольшой набор типовых документов, стажёр вручную сверил, где именно ошибается модель, и только на этой основе добавили автоматический разворот файла и отдельные спецификации под каждый тип документа. Схема конвейера: файл в архиве → вебхук Bitrix24 на событие «файл добавлен в раздел смарт-процесса» → дешёвая модель классифицирует тип и проверяет читаемость → если уверенность низкая или документ повёрнут — дорогая модель делает повторный разбор по спецификации → результат пишется в карточку сделки → менеджер видит флаг, если требуется проверка руками. Пример ответа модели: Если confidence ниже 0.7 или rotated_or_cut = true, задача уходит на второй шаг — более мощной модели со спецификацией конкретного типа документа. Это дороже по токенам, поэтому запускается только на проблемных случаях, а не на всём потоке. Пример ответа модели: Карточка клиента №40218 — Bitrix24 70% готовность комплекта документов 1 документ отсутствует 1 статус без файла Документ Статус Доверенность есть файл Договор статус есть, файла нет Выписка из реестра не хватает Инженерная обвязка. Крутится это не на одном скрипте, а на четырёх точках, каждая со своей зоной ответственности: Вебхук Bitrix24 на событие «файл добавлен в раздел смарт-процесса» — триггер, а не галочка в чек-листе. Ежечасный робот сверяет фактические файлы в хранилище со списком ожидаемых документов по спецификации кейса и обновляет процент готовности папки в карточке. Прокси-сервис логирует каждый вызов OCR и классификации в отдельную таблицу Google Sheets: кто загрузил, когда обработано, какой результат, код ошибки, если есть. Без этого лога никто не увидит, обработался файл или завис в очереди. Похожий случай уже был: один разработчик долго не мог понять, откуда в процессе ошибки, пока не проверил баланс своего аккаунта у поставщика модели — тот просто кончился. Если сделка не сдвинулась дальше этапа «документы получены» в установленный срок — автоматическое уведомление в контроль качества, по тому же принципу, что и уведомления о несостоявшихся проверках, которые в компании уже настроены. Шаблоны документов: кто отвечает за актуальную версию В проекте с автоматизацией подготовки договоров через условную логику — например, при выборе пакета «базовый» вместо полного «оформления документов» автоматически подставляется «инструкция по самостоятельному оформлению» — готовый шаблон хранится в облачном хранилище. Ответственность за его актуализацию закреплена на юристе: старые версии архивируются, новая размещается с тем же названием файла. Цена отсутствия такого правила видна на реальном случае: клиенты, получившие документы по старым шаблонам, застряли в оформлении из-за новых требований к адресам. Десятки клиентов в феврале, ещё несколько в апреле и заметная группа за первую неделю мая оказались в этой ситуации — суммарно больше сотни человек за один сезон, каждый из которых требует отдельной ручной работы по восстановлению. Февраль высокий Апрель низкий Май, 1-я неделя средний На диаграмме — относительная динамика числа клиентов, пострадавших от устаревшего шаблона документа, по месяцам. Если оценить ручную работу по восстановлению каждого случая консервативно в 1–2 часа (переписка с клиентом, повторный сбор документов, согласование новых адресов), на всех пострадавших клиентов уходит несколько недель работы одного специалиста, потраченных на исправление чужой ошибки за один сезон, — не считая времени специалиста, который лично взаимодействует с властями по каждому случаю, и репутационного риска. Похожая история произошла с локализацией сайта на несколько языков: без единого контроля версий статья про место жительства в одной стране в переводе превратилась в статью про другую страну. Ошибку заметили только при построчной проверке — а это неделя работы одного специалиста на 10 страниц. Где ломается Шаблон документа без назначенного ответственного — это не система, а лотерея. Кто-то правит форму под свой кейс, сохраняет с новым названием, и через полгода в обороте три версии одного договора, и никто не знает, какая актуальна. При заметном потоке клиентов в месяц цена такой ошибки растёт кратно: масштаб зависших дел рискует привлечь внимание регулятора, а не только недовольство клиентов. Что стоит закрепить в регламенте по шаблонам Один человек отвечает за актуальность конкретного шаблона — не отдел, а фамилия. Старая версия не удаляется, а архивируется — на случай спора по уже подписанному документу. Новая версия выкладывается строго с тем же названием файла, чтобы ссылки в CRM не рвались. В договорах прописывается срок действия услуги — это внесли в регламент отдельно, потому что без срока аналитика по просрочкам не считается вообще. Экономика: что стоит архив и что даёт Настройка архива стоит ≈16–30 часов работы разработчика (оценка) и почти не добавляет ежемесячных расходов, а эффект от одной только экономии времени менеджеров на поиске документов — ≈202 000 ₽ в месяц (оценка, расчёт ниже). Внедрение в описанном виде не требует крупной разработки — это настройка существующих инструментов, а не новый продукт. Основные статьи расходов: Статья Порядок затрат Периодичность Настройка вебхука Bitrix24 + структуры папок в хранилище ~8–16 часов разработчика единоразово Настройка ежечасного робота сверки файлов ~4–8 часов разработчика единоразово Логирование через прокси-сервис в Google Sheets ~4–6 часов разработчика единоразово Вызовы модели (классификация + эскалация на сложные случаи) на два порядка дешевле экономии времени ниже (расчёт — ниже) ежемесячно Хранилище (облако) обычно уже оплачено под другие задачи ежемесячно Расчёт по модели, чтобы не смешивать её эффект с эффектом архива: дешёвая модель (первый шаг конвейера) обрабатывает весь поток обращений в месяц (несколько десятков в день на рабочий месяц) по цене на порядок ниже стоимости одного вызова дорогой модели. На дорогую модель уходит только часть с низкой уверенностью или повёрнутыми файлами — консервативно 15–20% потока. Даже с учётом более высокой цены за документ, итоговые расходы на модели остаются на два порядка меньше, чем экономия времени на поиске документов ниже. Это разные эффекты и их нельзя складывать в один: экономия времени идёт от структуры архива и связки статус-файл, а ИИ-конвейер — отдельный слой, который дополнительно повышает качество распознавания и почти ничего не стоит на этом фоне. Формула для расчёта своего случая: (время поиска документа до архива − время поиска после архива) × число обращений в день на менеджера × число менеджеров × ставка часа сотрудника = потери в день; умножьте на число рабочих дней в месяце — получите оценку месячных потерь на беспорядок в хранении. Пример на подставленных числах: отдел из 8 менеджеров, каждый тратит на поиск документа в среднем 10 минут вместо 1 минуты при нормальной структуре, при потоке 8 обращений в день на человека. Это ≈1,2 часа в день на менеджера, или ≈9,6 часа в день на отдел — а за 21 рабочий день набегает ≈202 часа. По ставке ~1000 ₽/час это ≈202 000 ₽ ежемесячных потерь, найденных просто за счёт наведения порядка в хранении (консервативно). 10 мин было 1 мин стало На диаграмме — среднее время поиска документа менеджером до и после внедрения архива. Отдельный эффект — снятие риска зависших сделок. Если из-за отсутствия связки статус-файл дело считается укомплектованным, когда это не так, ошибка всплывает поздно — на этапе, где откатывать назад дорого. Те же клиенты из начала статьи — не абстракция, а конкретная цена такого разрыва: без срока в договоре и обязательной загрузки файла сделки повисают именно так, замораживая ≈3,6 млн ₽ выручки отдела — почти половину месячного оборота — на ровном месте. Что делать, если архива по факту нет Если сейчас документы клиентов лежат частично в CRM, частично на компьютерах, частично в переписках — начинать с полной автоматизации не стоит. В одном проекте перед запуском обучения модели на клиентских кейсах сначала вручную прогнали небольшую группу живых случаев через систему и отдали менеджерам на проверку корректности. Только после подтверждения перешли к тестированию на более широкой базе клиентов. Тот же принцип работает с архивом: сначала ручная сверка на небольшом объёме, потом автоматизация. Ещё один момент — зафиксировать регламенты в письменном виде. В одном проекте при передаче обнаружилось, что документов и регламентов просто нет: знания передавались устно, «под диктофон», и всё. Это риск, который не виден, пока ключевой человек на месте — и становится критичным в первый же день после его ухода. И назову вещь, которую обычно не называют вслух. Устроить хранение так, чтобы информация пережила уход конкретного человека, — это управленческий навык, а не задача айтишника. Руководитель, у которого процесс не держится на памяти Марины и Оли, стоит дороже руководителя, который умеет только раздавать задачи, — и разница видна в первый же день, когда Марина заболела. Про то, как автоматизация без контроля данных превращается в имитацию работы, я писал в статье почему внедрение ИИ не работает, хотя технически всё запустилось — логика та же: система есть, а данные в неё не попадают. Чек-лист на понедельник Выписать все точки, где сейчас реально лежат документы клиентов — без иллюзий, что «всё в CRM». Проверьте 10–15 случайных карточек: стоит ли статус «документ получен» там, где файла физически нет. Назначьте одного ответственного за шаблоны документов и договориться о правиле архивации старых версий. Настройте автосоздание структуры папок при заведении новой карточки клиента — вебхуком, не руками. Внести в договор срок действия услуги, если его там ещё нет — без этого аналитика по просрочкам не считается. Договоритесь, кто и по какому расписанию смотрит сводку по незавершённым кейсам — без этого архив снова превратится в склад. Сделайте на этой неделе одну вещь: попросите сотрудника, который не занимается документами, найти три конкретных файла за прошлый год. Засеките время. Эта цифра скажет о состоянии вашего архива больше, чем любой аудит. А как поставить на архив машину — чтобы она раскладывала и извлекала данные сама, — в разборе про распознавание документов и в бесплатном курсе . Чего мне это стоило Скажу честно: архивом я занялся не от хорошей жизни. У нас потерялся комплект документов клиента — не украли, не удалили, просто никто не мог найти. Мы искали его втроём полтора дня, а клиент в это время ждал и делал выводы о нашей компании. Я тогда сделал две вещи. Первая — разобрал, как именно документы попадают на диск: оказалось, четырьмя разными путями, и ни один не был описан. Вторая — принял, что структуру нельзя «объяснить» команде, её можно только сделать такой, чтобы ошибиться было сложнее, чем сделать правильно. Если у вас сейчас так же — вы не одиноки, и это чинится за неделю. Мой порядок: сначала опишите пути поступления, потом структуру, и только потом наводите порядок в старом. Обратный порядок — разгребать сначала — я попробовал, и это была потеря времени: старое зарастает заново, пока новое сыплется как попало. Начните с малого на этой неделе: опишите один путь поступления документов — самый частый у вас — и назначьте одно место, куда они складываются. Дальше будет проще. А как передать раскладку машине, чтобы она сама определяла тип документа, — в бесплатном курсе .

## Автоматизация заявок: от письма до задачи с ответственным
URL: https://davidgerstein.pro/blog/avtomatizatsiya-obrabotki-zayavok/
Дата: 2026-06-08
Направление: Производственный цикл
Цифры: 3000 мс → 80 мс отклик формы · несколько десятков клиентов в просрочке на этапе документов · более сотни клиентов пострадали из-за устаревших шаблонов
Коротко: Автоматизация заявок — это связка быстрого и надёжного приёма данных (отклик формы падает с 3000 мс до 80 мс), маршрутизации по правильной воронке и обязательных полей, которые не дают статусу соврать. Работает она только там, где на каждом этапе есть срок и человек, отвечающий за его нарушение.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Заявка приходит на почту, менеджер её видит через час, переносит в CRM руками, забывает поставить срок. Знакомая цепочка? В ней теряется от десяти до тридцати процентов обращений — и вы за них уже заплатили. Проверьте себя одним вопросом. Если вы не можете за минуту назвать, сколько заявок пришло вчера, у кого каждая лежит и когда по ней истекает срок, — обработки заявок у вас нет. У вас есть надежда на память менеджеров. Она держится ровно до того дня, когда поток вырастет или заболеет один человек. Форма на сайте отвечала клиенту за 3 секунды. Для человека это незаметно. Для системы — риск: если в этот момент падает приёмщик заявки, данные теряются безвозвратно, а заявка просто не появляется нигде. Мы поставили плагин, который снизил отклик до 80 миллисекунд, и добавили буферизацию на случай сбоя. Заявка теперь не пропадает, даже если сервер на другом конце не ответил вовремя. Это одна деталь из десятков. Но именно из таких деталей строится автоматизация заявок — не красивая схема на слайде, а система, которая не роняет данные в реальных условиях. Масштаб проблемы без автоматизации: на одном этапе воронки у нас скопилось несколько десятков клиентов в просрочке — это объём, сопоставимый с месячной загрузкой нескольких менеджеров, замороженный без движения. Ниже — как заявка проходит путь от письма в почте до задачи со сроком, что в этом пути автоматизирует модель, а что — только регламент и договор. Как настроить автоматизацию заявок Автоматизация заявок собирается из пяти шагов: единая точка приёма (все каналы — в одну систему), разбор письма машиной в структуру, маршрутизация по правилу, обязательные поля и срок с ответственным на каждом этапе. Форма после переделки отвечает за 80 мс вместо 3 000 , а заявка не теряется между отделами, потому что у каждого шага есть владелец и норматив. Начинать стоит не с алгоритма: пока данные попадают в разные места — почту, мессенджер, личную таблицу — автоматизировать нечего. Сначала одна точка входа, потом разбор. Как работает автоматизация заявок Коротко, если вы ищете ответ прямо сейчас. Автоматизация заявок — это цепочка из пяти шагов: заявка из любого источника попадает в одну точку приёма, система определяет её тип, назначает ответственного по правилу, ставит срок и заводит задачу. Ручного переноса нет ни на одном шаге, а статус меняется от событий, а не от того, вспомнил ли менеджер его переставить. Отдельный случай — шаблонные заявки , то есть повторяющиеся обращения одного вида: запрос счёта, типовая консультация, продление услуги. Их автоматизируют первыми: правило разбора описывается один раз, а срабатывает на десятках обращений в неделю. По нашей практике именно шаблонные заявки дают основной эффект в первый месяц, потому что их много и они предсказуемы. Что теряется между письмом и задачей у вас Четыре точки разрыва — пройдите по ним и отметьте свои. Заявка приходит из формы, письма, мессенджера. До задачи со сроком она должна пройти три шага: попасть в систему, определить, к какому процессу относится, получить ответственного и дедлайн. Если хотя бы один шаг делается руками — очередь заявок будет копиться там, где человек забыл, устал или ушёл в отпуск. Мы видели ситуацию, когда новый сотрудник вообще не работал в CRM: все документы клиентов лежали на его личном компьютере. Когда его понадобилось подменить, оказалось, что дела нельзя передать другому менеджеру — их физически нет в общей системе. Это крайний случай, но он показывает суть: автоматизация заявок начинается не с алгоритма, а с того, что данные обязаны попадать в одно место без вариантов. Как устроено само хранилище, чтобы оно не разваливалось с уходом сотрудника, — разобрал отдельно . Похожая история — при сборе переписок из чата-маршрутизатора для анализа. В выборку попадал служебный мусор: сообщения сотрудников без доступа в системе управления, реплики из открытых каналов. Мусор давал каскадные ошибки на каждом следующем узле обработки — модель училась на шуме. Решение оказалось проще, чем чистка данных постфактум: брать данные не из чата, а напрямую из основной системы управления, где они уже структурированы полями, а не свободным текстом. Правило Автоматизация не чинит бардак в источнике данных — она его тиражирует и ускоряет. Прежде чем маршрутизировать заявки, наведите порядок там, откуда они берутся. Пять шагов от письма до задачи Пройдите их по своему потоку — на каждом шаге отмечайте, что у вас уже есть. Соберёте это за неделю. Первые два шага дадут вам результат сразу, остальные — потом. Ниже — пять шагов, которые мы видели в каждой команде, с которой работали. Приём. Форма, почта или мессенджер отправляют данные в приёмщик заявки (вебхук или почтовый коннектор). Приёмщик должен отвечать быстро и буферизовать заявку локально — если основная система недоступна, данные не теряются, а ждут в очереди на повторную отправку. Определение типа. Дешёвая модель или простое правило смотрит на содержимое заявки и присваивает тип: новый лид, запрос документа, жалоба, запрос статуса. От типа зависит, в какую воронку и к какому процессу заявка пойдёт дальше. Маршрутизация. Заявка попадает в нужную воронку CRM и получает ответственного — по правилу (например, по региону или типу услуги), а не по принципу «кто увидел первым». Назначение срока. На основе типа заявки и регламента системе присваивается дедлайн этапа. Без этого пункта заявка формально «в работе», но фактически может лежать сколько угодно. Контроль. Если срок нарушен, система создаёт задачу не только менеджеру, но и контролю качества — отдельным уведомлением, а не строкой в общем отчёте, которую никто не открывает. Каждый из этих пяти шагов может сломаться отдельно, и я разберу три самых частых места поломки: маршрутизацию, статусы и договорные сроки. Маршрутизация: одна воронка или пять Решение, которое вам придётся принять на старте. Обычно правильный ответ — начать с одной, а не строить сразу пять. Когда проект состоит из нескольких пересекающихся процессов — например, работа исследователя, проект-менеджера, оформления и производства — возникает вопрос: делать одну большую воронку с вложенными этапами или несколько отдельных. Мы выбрали воронку проект-менеджера как фасад. Внутри неё работают отдельные смарт-процессы с автоматическим обновлением процента готовности на каждом этапе. Руководителю не нужно копаться в десятках элементов — он видит итоговый статус на верхнем уровне, а детали доступны при необходимости, но не мешают общей картине. Второй приём касается параллельных долгосрочных процессов. Вместо того чтобы держать одну сделку и метаться между статусами «работаем» и «ждём», мы создаём две сделки: одна остаётся в основной воронке со статусом «охлаждение / ожидание», вторая идёт по специальной воронке со своими этапами. Менеджер не работает одновременно в двух местах, а долгосрочные проекты видны отдельно от текущей операционки — это разгружает и интерфейс, и голову. Автоматическая структура при создании клиента Ещё один слой маршрутизации — на уровне файлов, а не сделок. При создании новой папки клиента в облачном хранилище робот автоматически создаёт стандартную структуру разделов: интервью, расшифровки, редактура, вёрстка и так далее. Тот же робот ежечасно проверяет появление новых файлов и прокидывает ссылки в систему управления проектами. Это убирает ручной шаг «завести структуру» из очереди задач менеджера — мелочь, но именно такие мелочи и создают очередь заявок, если их не убрать заранее. Статусы, которые не врут Ваш ориентир: статус должен меняться от события в системе, а не от того, вспомнил ли менеджер его переставить. Проверьте свои: если статус меняет человек вручную и по памяти, ваши отчёты показывают не реальность, а намерения. Статус в CRM — самое дешёвое место для вранья. Менеджер откатывает сделку назад вручную и забывает удалить старую дату проверки. Или ставит «документ в наличии», хотя файл не загружен на сервер. Оба случая мы разбирали на практике, и оба ломали данные, на которых потом должна была учиться модель. С проверками решение было такое: добавить отдельное поле для даты неуспешной проверки (не путать с датой планируемой), обязательное поле причины отказа с фиксированным списком вариантов, автоматическую задачу менеджеру ровно на день проверки с двумя вариантами ответа — пройдена или нет, и уведомление контролю качества, если сделка не перемещена в срок. Ручной шаг «не забыть откатить» исчез, потому что система сама создаёт задачу и ждёт ответа, а не полагается на память человека. С документами оказалось хуже: менеджеры отмечали «в наличии» без реальной загрузки файла. Для человека это ускоряет отчётность на пару минут. Для модели, которая обучается на этих данных, это катастрофа — она начинает считать, что клиент может пройти проверку вообще без документов. Пришлось выбирать между ретроспективной загрузкой всего архива и жёстким требованием: статус «в наличии» физически недоступен без прикреплённого файла. Здесь я обязан сказать про себя. Я сам полтора года лечил эту отметку разговорами: собирал менеджеров, объяснял, что галочка без файла ломает все данные ниже по цепочке. Люди кивали и ставили галочку дальше. Помогло не совещание, а одно поле в карточке. Если вы сейчас на стадии «объясню ещё раз, и они поймут» — вы не наивный, на этой стадии были все, включая меня. Просто спорить с привычкой человека дороже, чем закрыть лазейку в форме. Статус по расписанию, а не по настроению Отдельно мы внедрили двухуровневое отслеживание статусов. Раз в неделю, по средам вечером, система автоматически фиксирует актуальный статус каждого клиента в новый столбец. Новые столбцы добавляются слева от предыдущих — руководитель видит последние изменения без прокрутки всей таблицы. Если статус не менялся — ставится прочерк, а не повтор значения. Так застой виден сразу, а не после третьего взгляда на таблицу. Подробнее о том, как CRM способна незаметно искажать даты и статусы даже без злого умысла менеджера, я разбирал в статье CRM врёт. Как я поймал Битрикс24 на сдвиге дат . Проблема со статусом Что происходило вручную Что автоматизировали Откат после неуспешной проверки Менеджер забывал удалить дату Автозадача + обязательное поле причины Документ «в наличии» без файла Отметка без загрузки файла Статус недоступен без прикреплённого файла Динамика по клиенту за неделю Ручная сверка в таблице Автостолбец по средам, прочерк при отсутствии изменений Просрочка без реакции КК Никто не замечал вовремя Уведомление контролю качества при просрочке этапа ИИ-связка: обработка документов внутри заявки Здесь машина снимает с ваших людей самую нудную часть — разбор вложений и перенос данных в карточку. Отдельный слой заявки — вложенные документы клиента. Их нужно не просто принять, а распознать, определить тип и извлечь поля. Вот рабочая схема конвейера, которую мы используем. Схема: файл документа попадает в карточку сделки через загрузку в CRM или в клиентский портал → вебхук ловит событие добавления файла → облачная функция прогоняет файл через OCR → текст уходит в языковую модель с промптом ниже → структурированный ответ парсится и записывается обратно в поля сделки → если качество скана низкое или документ перевёрнут — создаётся задача менеджеру на ручную проверку. Модель на этом шаге — дешёвый классификатор, а не топовая модель с расширенным контекстом: задача массовая, повторяющаяся, не требует «рассуждений» — только извлечение полей по инструкции. Модель подороже имеет смысл подключать только на втором проходе, если дешёвый классификатор вернул низкий скор уверенности или явное несовпадение типа документа. Пример ответа модели на реальном перевёрнутом документе: Это реальная проблема, а не гипотетический пример: вертикально загруженные документы сбивали алгоритм, модель путала имена и фамилии, пропускала отчества. Мы не стали сразу прогонять через модель всю базу — сначала собрали пробную партию типовых документов, обучили стажёра проверять результат вручную и только после этого зафиксировали отдельные спецификации промпта под каждый тип документа: паспорт распознаётся не так, как выписка из реестра. Решение было двойным: автоматический разворот документа до отправки в модель плюс эти спецификации. Инженерная обвязка Конвейер крутится на связке: событие в Bitrix24 (файл добавлен в карточку сделки) → облачная функция как посредник → OCR-сервис → вызов модели по API → запись результата в пользовательские поля сделки через REST API ( crm.deal.update ). Если quality_score ниже 3 или orientation_issue = true — автоматически создаётся задача менеджеру «проверить документ вручную». Отдельная проблема — прозрачность самого конвейера. Когда мы настраивали похожую обработку через API, разработчик не видел баланс своей учётной записи и не мог отследить, где происходят ошибки. Решение — логирование всех действий в общую таблицу через прокси-сервис: три колонки — успешно обработано, не обработано, ошибка. Без этого слоя автоматизация работает как чёрный ящик: вроде что-то происходит, а что именно — непонятно, пока не выстрелит. Лог конвейера — обработка документов ~100 документов в первой партии 3 колонки статуса в логе Документ Статус Паспорт — Иванов И.И. обработано Доверенность — перевёрнуто проверить вручную Справка — низкое качество скана ошибка Для снижения нагрузки на модели и уменьшения количества галлюцинаций мы также подняли MCP-сервер на базе CRM, чтобы ИИ-инструменты работали с корпоративными данными напрямую, а не через общий контекст без привязки к специфике компании. Это снизило потребление токенов на 30–40% — но это отдельная инициатива, её эффект я не приплюсовываю к экономике самой обработки заявок ниже, это разные вещи с разной окупаемостью. Где ваша очередь заявок реально стопорится Три места, и обычно виновато не последнее, а первое — приём. Технически система может работать идеально, а заявки всё равно копятся. Мы находили несколько десятков клиентов, застрявших на этапе «документы запрошены». Причина оказалась не в CRM, а в продажах: менеджеры при продаже говорили клиентам, что спешить не нужно, начать можно когда угодно. Клиент расслаблялся и не присылал документы месяцами — автоматика честно фиксировала статус «ожидаем документы», но не могла заставить человека прислать файл. Автоматизация здесь — не в скрипте, а в договоре. Мы внедрили требование прописывать срок действия услуги в стандартных договорах (для нетиповых работ срок можно опускать). Сначала контроль срока вели вручную, потом автоматизировали: система сама поднимает просроченные сделки и создаёт задачу. Отдельно добавили юридическую страховку: если клиент не отвечает три зафиксированных раза, это считается отказом от услуг. Это защищает компанию и обязывает клиента оставаться в контакте, а не висеть в очереди бесконечно. Похожая логика — с массовым сбоем шаблонов документов. Когда 80 клиентов в феврале, небольшая группа из 9 человек в апреле и ещё почти полсотни — 50 человек — в первую неделю мая (в сумме 139 человек, больше сотни) получили документы по устаревшим шаблонам, они застряли в процессе оформления из-за новых требований к адресам. При таком ежемесячном объёме это уже риск проверки со стороны регулятора, а не просто внутренняя недоработка. Решение было точечным: не советовать клиентам адреса гостиниц (они автоматически идентифицируются системой), а рекомендовать жилые апартаменты, и параллельно обновить обучающие материалы для сотрудников. Автоматизация заявок в этом случае — это ещё и своевременное обновление инструкций, а не только код. Устаревшие шаблоны — февраль 80 Устаревшие шаблоны — первая неделя мая 50 Просрочка на этапе «документы запрошены» десятки Устаревшие шаблоны — апрель 9 3000 мс было 80 мс стало Столбики не в масштабе миллисекунд — они показывают направление изменения. Отклик формы сократился с 3000 мс до 80 мс после установки плагина-приёмщика с буферизацией на случай сбоя. Где ломается Самая частая причина зависшей очереди заявок — не отсутствие автоматизации, а договорённость на входе, которая не даёт клиенту повода торопиться. Никакой скрипт это не почистит, если срок не прописан в договоре и не подкреплён юридической страховкой. Экономика: что это стоит и что даёт вам Считайте от потерь: сколько заявок вы теряете сейчас и сколько стоит одна. Считаю по каждому механизму отдельно, честно, без смешивания эффектов. Буферизация приёмщика заявки (3000 мс → 80 мс + очередь на сбой). Стоимость внедрения — разработка и тестирование плагина, оценка 8–12 часов работы разработчика. Эффект — не часы, а снятый риск: без буферизации при сбое приёмщика заявка исчезает безвозвратно, и посчитать её в деньгах можно только через объём потерянных обращений, который мы не готовы называть точной цифрой. Грубая иллюстрация масштаба риска, а не заработка: если бы терялась хотя бы одна заявка в неделю (оценка, консервативно занижена), это несколько заявок в месяц, которые просто не появлялись бы нигде в системе — по объёму сопоставимо с недельной выработкой одного менеджера, исчезающей бесследно. Честнее сказать так: это страховка, а не источник экономии часов. Автоматическая задача на откат сделки после неуспешной проверки. До автоматизации менеджер тратил на ручной откат и (не всегда) удаление старой даты, по грубой оценке, 10–15 минут на сделку, включая размышление «не забыл ли я что-то». При заметном потоке таких откатов в месяц это несколько часов ручной работы — почти целый рабочий день менеджера, потраченный впустую (оценка). После автоматизации это время сжимается до 1–2 минут на подтверждение задачи — тот же объём сделок укладывается в существенно меньшее время, то есть экономия порядка нескольких часов в месяц, больше половины рабочего дня менеджера, освобождённого для реальных сделок. Срок в договоре + автоматический подъём просроченных сделок. Здесь эффект не в часах, а в размороженной выручке. Пример на цифрах из практики: несколько десятков клиентов зависли на этапе «документы запрошены». Отдел из 8 менеджеров при обороте ~9 млн ₽/мес и среднем чеке ~180 тыс. ₽ ведёт около 50 активных сделок в месяц — то есть в заморозке оказалось около 10% всего портфеля отдела (оценка, не про потерянные деньги, а про долю оборота, которую автоматизация возвращает в движение за счёт срока и трёх фиксированных попыток связи). Формула для вашего случая: число сделок, зависших на самом узком этапе воронки, разделить на общее число активных сделок отдела — это и есть доля оборота, замороженная прямо сейчас. Логирование конвейера обработки документов. Стоимость — настройка прокси-сервиса и таблицы логов, оценка 10–15 часов разработчика разово, дальше ~300 ₽/мес на хранение строк и вызовы логирования в эксплуатации. До логирования разбор одной причины сбоя занимал у разработчика, по нашей оценке, 2–4 часа — приходилось вручную сверять записи в разных сервисах. При заметном числе сбоев в месяц это несколько десятков часов работы разработчика — фактически несколько рабочих дней, уходящих на ручную сверку логов вместо разработки. После внедрения лога разбор занимает 10–15 минут: причина видна сразу в одной из трёх колонок. Это в первую очередь снижение риска простоя конвейера, а не только прямая экономия часов. Что мы не считаем эффектом: часы, которые модель освободила у менеджеров на этапе определения типа заявки, но которые компания не сократила, а перераспределила на другие задачи (например, на дозвон по зависшим сделкам) — это перераспределение нагрузки, а не деньги в кассе. Механизм До После Эффект (оценка) Буферизация приёмщика заявки Риск полной потери заявки при сбое Заявка ждёт в очереди на повторную отправку Несколько заявок/мес под риском бесследного исчезновения (консервативная иллюстрация) Откат сделки после неуспешной проверки Несколько часов/мес ручной работы на десятки откатов Около часа/мес на подтверждение Несколько часов/мес высвобождено Срок в договоре + автоподъём просрочки Несколько десятков сделок зависает без реакции Автоподъём + 3 контакта = отказ ≈10% портфеля отдела разморожено Логирование конвейера документов 2–4 часа на поиск причины сбоя 10–15 минут по логу Несколько десятков часов/мес высвобождено Итого: маршрутизация, статусы, сроки и обвязка конвейера документов из этой статьи — один контур эффекта. MCP-сервер и точность OCR — другой, отдельно посчитанный контур, он разобран в других материалах. Ваш чек-лист на понедельник Первые два пункта не требуют ни техники, ни денег. Проверьте приёмщик заявок: что происходит с данными, если сервер на другом конце недоступен 5 секунд — теряются они или ждут в очереди. Найдите в CRM все статусы, которые можно поставить без прикреплённого файла или без обязательного поля причины — закройте эти лазейки первыми. Посчитайте, сколько сделок сейчас висит на самом длинном этапе воронки, и сравните со сроком, который прописан (или не прописан) в договоре. Добавьте в договор срок действия услуги для стандартных работ и правило «три неотвеченных контакта — отказ», если у вас ещё нет такой страховки. Заведите один общий лог для любого автоматического конвейера — успешно/не обработано/ошибка — прежде чем добавлять в него модель. Определите, какие два-три типа документов или заявок дают больше всего ручной работы, и начните автоматизацию с промпта под них, а не со всего потока сразу. Если проблема не в алгоритме, а в том, что менеджеры саботируют внесение данных в CRM — это отдельная тема, она разобрана в материале Контроль работы менеджера: дашборд вместо штрафов . А о том, как ведёт себя автоматизация вообще без присмотра человека, я писал в статье «Если бы я не пришёл, ничего бы не произошло» . Пять слоёв из этой статьи — приём, определение типа, маршрутизация, срок, контроль — работают только вместе. Уберите любой, и очередь заявок найдёт новое место, чтобы зависнуть. Но ни один из них не ставится один раз и не забывается: приёмщик через полгода ловит новый тип сбоя, шаблон документа устаревает после смены закона, а менеджер находит способ обойти обязательное поле, если систему оставить без присмотра. Автоматизация заявок держится не на коде, а на том, кто раз в квартал проверяет, что все пять слоёв ещё работают так, как задумано. И ещё одно, ради чего всё это. Умение провести заявку глазами по всему пути — от письма до задачи с фамилией и сроком — такой же базовый навык руководителя, как умение читать отчёт о прибыли. Раньше с директора спрашивали, как он раздаёт задачи людям. Теперь спрашивают, как у него устроен маршрут, по которому задача возникает сама и сразу с хозяином. Я считаю, в этом сегодня и разница в цене между двумя руководителями: один держит поток в голове и в переписке, второй — в системе, которая работает и без него. Начните с замера: сколько заявок за прошлую неделю получили ответ позже двух часов. Эта цифра — ваш потенциал, и он обычно больше, чем прирост от увеличения рекламного бюджета. Как собрать обработку заявок так, чтобы ни одна не терялась, — механика в бесплатном курсе . Что дало больше всего эффекта Из всей автоматизации главный результат дала не техника, а одно правило: у каждой заявки с первой секунды есть ответственный человек. До этого мы честно настраивали маршруты и статусы — и всё равно теряли обращения, потому что заявка попадала «в отдел», а отдел не отвечает, отвечают люди. Если у вас сейчас так же — начните с этого правила, оно бесплатное. Автоматизацию поставите поверх.