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

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

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

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

Архив кажется скучной темой ровно до первого раза, когда документ нужен срочно — юристу, налоговой, клиенту с претензией. Тогда выясняется, что папки на диске раскладывал каждый по-своему, а половина файлов называется «скан_итог_финал_2.pdf».

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

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

Зачем архив, если «и так работает»

Ваше «и так работает» держится на памяти двух-трёх человек. Это работает ровно до их отпуска.

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

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

Масштаб проблемы легче увидеть в деньгах, а не только в штуках. При среднем чеке 180 тыс. ₽ и около 20 клиентах, зависших на этом этапе одновременно, получается ≈3,6 млн ₽ — это почти половина месячного оборота отдела продаж (9 млн ₽), которая не движется по воронке, пока документы не собраны. Это не потерянные деньги — это замороженные, и цена задержки растёт с каждым днём простоя.

Как выстроить электронный архив документов: механика по шагам

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

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

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

Настройка архива стоит ≈16–30 часов работы разработчика (оценка) и почти не добавляет ежемесячных расходов, а эффект от одной только экономии времени менеджеров на поиске документов — ≈202 000 ₽ в месяц (оценка, расчёт ниже). Внедрение в описанном виде не требует крупной разработки — это настройка существующих инструментов, а не новый продукт. Основные статьи расходов:

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

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

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

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

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

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

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

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

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

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

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

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

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

Чего мне это стоило

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

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

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

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

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

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

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

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

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

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

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

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