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

Архив документов, который не разваливается, когда сотрудник уходит

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

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

Электронный архив документов: зачем он, если «и так работает»

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

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

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

Механика: как выстроить архив по шагам

Ниже последовательность, которую можно повторить с любой командой — без специальной разработки, на базе того, что обычно уже есть: CRM (Bitrix24 или amoCRM), облачное хранилище, Google Sheets для учёта.

1. Аудит. Выписать все точки, где реально лежат файлы клиентов сейчас: Google Drive, NextCloud, личные компьютеры, вложения в CRM. Обычно находится несколько параллельных мест одновременно, и ни в одном нет полного комплекта.
2. Единая точка входа. Выбрать одно хранилище (портал, облачную папку с жёсткой структурой) и договориться, что новые документы загружаются только туда. Старые — переносятся туда же в рамках отдельной задачи, а не «постепенно, по мере обращения».
3. Шаблон структуры под процесс. Разделы папки клиента должны совпадать с реальными этапами работы (сбор материала → обработка → согласование → финал), а не с абстрактной классификацией «документы / прочее».
4. Автосоздание структуры. При заведении новой карточки клиента в CRM вебхук создаёт в хранилище стандартный набор разделов автоматически. Робот раз в час проверяет появление новых файлов и прокидывает ссылки обратно в карточку.
5. Жёсткая связка статуса и файла. Статус «документ получен» в CRM физически не может стоять без прикреплённого файла — это проверяется автоматически, а не по доброй воле менеджера.
6. Ответственный за шаблоны. Один человек (юрист или руководитель направления) отвечает за актуальность форм и договоров, которые кладутся в архив как эталон.

Структура папок, которая не разваливается через полгода

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

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

Что делает структуру рабочей, а не декоративной

• Разделы создаются автоматически при заведении клиента — не по памяти сотрудника.
• Названия разделов совпадают с этапами реального процесса, а не с общей классификацией «документы / прочее».
• Есть автоматическая связка с CRM: новый файл в папке — это событие для системы, а не то, что нужно вручную прикреплять отдельно.

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

Хранение клиентских документов: где чаще всего теряют

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

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

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

ИИ-связка: как архив кормит модель распознавания документов

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

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

Модель: Claude Haiku (дешёвая — шаг 1, массовая классификация)

Ты классификатор документов клиентского кейса. На входе — текст, распознанный OCR из одного файла.

Определи:
1. Тип документа: паспорт / свидетельство о рождении / свидетельство о браке / архивная справка / другое.
2. Уверенность в определении типа (число от 0 до 1).
3. Есть ли признаки, что документ загружен повёрнутым или обрезанным (текст рваный, даты не читаются, поля смещены).

Верни только JSON без пояснений, без markdown-обёртки:

{
  "client_id": "{{client_id}}",
  "doc_type": "...",
  "confidence": 0.0,
  "rotated_or_cut": true,
  "raw_snippet": "первые 150 символов распознанного текста"
}

Текст документа:
{{ocr_text}}

Пример ответа модели:

{
  "client_id": "40218",
  "doc_type": "свидетельство_о_рождении",
  "confidence": 0.88,
  "rotated_or_cut": false,
  "raw_snippet": "Свидетельство о рождении. Настоящее свидетельство выдано..."
}

Если confidence ниже 0.7 или rotated_or_cut = true, задача уходит на второй шаг — более мощной модели со спецификацией конкретного типа документа. Это дороже по токенам, поэтому запускается только на проблемных случаях, а не на всём потоке.

Модель: Claude Sonnet (дороже — нужен разбор по спецификации кейса, а не просто классификация)

Тебе передан список документов клиента, уже распознанных и классифицированных, и обязательный комплект для его типа дела.

Загруженные документы (JSON-массив из Google Sheets, столбцы: doc_type, status, uploaded_at):
{{uploaded_docs_json}}

Обязательный комплект для типа дела "{{case_type}}":
{{required_docs_list}}

Задача:
1. Сопоставь загруженные документы с обязательным списком.
2. Укажи, каких документов не хватает.
3. Если документ отмечен в CRM как «в наличии», но файла нет в списке загруженных — отдельно пометь как status_without_file (это критичная ошибка, а не пропуск).

Верни JSON:
{
  "client_id": "...",
  "missing_docs": ["..."],
  "status_without_file": ["..."],
  "ready_percent": 0
}

Пример ответа модели:

{
  "client_id": "40218",
  "missing_docs": ["архивная_справка"],
  "status_without_file": ["свидетельство_о_браке"],
  "ready_percent": 70
}

Инженерная обвязка. Крутится это не на одном скрипте, а на четырёх точках, каждая со своей зоной ответственности:

• Вебхук Bitrix24 на событие «файл добавлен в раздел смарт-процесса» — триггер, а не галочка в чек-листе.
• Ежечасный робот сверяет фактические файлы в хранилище со списком ожидаемых документов по спецификации кейса и обновляет процент готовности папки в карточке.
• Прокси-сервис логирует каждый вызов OCR и классификации в отдельную таблицу Google Sheets: кто загрузил, когда обработано, какой результат, код ошибки, если есть. Без этого лога никто не увидит, обработался файл или завис в очереди. Похожий случай уже был: один разработчик долго не мог понять, откуда в процессе ошибки, пока не проверил баланс своего аккаунта у поставщика модели — тот просто кончился.
• Если сделка не сдвинулась дальше этапа «документы получены» в установленный срок — автоматическое уведомление в контроль качества, по тому же принципу, что и уведомления о несостоявшихся проверках, которые в компании уже настроены.

Шаблоны документов: кто отвечает за актуальную версию

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

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

На диаграмме — относительная динамика числа клиентов, пострадавших от устаревшего шаблона документа, по месяцам.

Если оценить ручную работу по восстановлению каждого случая консервативно в 1–2 часа (переписка с клиентом, повторный сбор документов, согласование новых адресов), на всех пострадавших клиентов уходит несколько недель работы одного специалиста, потраченных на исправление чужой ошибки за один сезон, — не считая времени специалиста, который лично взаимодействует с властями по каждому случаю, и репутационного риска.

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

Что стоит закрепить в регламенте по шаблонам

• Один человек отвечает за актуальность конкретного шаблона — не отдел, а фамилия.
• Старая версия не удаляется, а архивируется — на случай спора по уже подписанному документу.
• Новая версия выкладывается строго с тем же названием файла, чтобы ссылки в CRM не рвались.
• В договорах прописывается срок действия услуги — это внесли в регламент отдельно, потому что без срока аналитика по просрочкам не считается вообще.

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

Внедрение архива в описанном виде не требует крупной разработки — это настройка существующих инструментов, а не новый продукт. Основные статьи расходов:

Расчёт по модели, чтобы не смешивать её эффект с эффектом архива: дешёвая модель (первый шаг конвейера) обрабатывает весь поток обращений в месяц (несколько десятков в день на рабочий месяц) по цене на порядок ниже стоимости одного вызова дорогой модели (оценка). На дорогую модель уходит только часть с низкой уверенностью или повёрнутыми файлами — консервативно 15–20% потока. Даже с учётом более высокой цены за документ, итоговые расходы на модели остаются на два порядка меньше, чем экономия времени на поиске документов ниже. Это разные эффекты и их нельзя складывать в один: экономия времени идёт от структуры архива и связки статус-файл, а ИИ-конвейер — отдельный слой, который дополнительно повышает качество распознавания и почти ничего не стоит на этом фоне.

Формула для расчёта своего случая: (время поиска документа до архива − время поиска после архива) × число обращений в день на менеджера × число менеджеров × ставка часа сотрудника = потери в день; умножьте на число рабочих дней в месяце — получите оценку месячных потерь на беспорядок в хранении. Пример на подставленных числах: отдел из 10 менеджеров, каждый тратит на поиск документа в среднем 10 минут вместо 1 минуты при нормальной структуре, при потоке 8 обращений в день на человека. Это ≈1,2 часа в день на менеджера, или ≈12 часов в день на отдел — а за 21 рабочий день набегает время, сопоставимое с почти полноценной ставкой ещё одного сотрудника, найденное просто за счёт наведения порядка в хранении (оценка, консервативно).

На диаграмме — среднее время поиска документа менеджером до и после внедрения архива (оценка).

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

Что делать, если архива по факту нет

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

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

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

Чек-лист на понедельник

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

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

С чего начать электронный архив документов в компании?

С аудита: где сейчас реально лежат файлы клиентов — Google Drive, NextCloud, личные компьютеры, CRM. Обычно оказывается, что это несколько разных мест одновременно, и ни в одном нет полного комплекта.

Как организовать структуру папок для клиентских документов?

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

Кто должен отвечать за шаблоны документов?

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

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