# Директор и машина — полные тексты разборов Автор: Давид Герштейн. Цитирование свободное при указании источника. Суммы пересчитаны на условную компанию; пропорции и механика реальные. Короткий индекс: https://davidgerstein.pro/llms.txt ## Кассовый разрыв: как двухнедельный план финансиста убрал нехватку денег из графика URL: https://davidgerstein.pro/blog/upravlencheskaya-otchetnost-msb/ Дата: 2026-09-03 Направление: Финансы Цифры: 25%→10% доля просроченной дебиторки (60+ дней); ~19 000 ₽/мес экономии времени финансиста (оценка); 40–50 тыс ₽ премия за перевыполнение плана Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Что такое кассовый разрыв и почему его видят в день платежа Кассовый разрыв — это не убыток и не нехватка прибыли, а нехватка денег на счёте в конкретный день: платить уже надо, а поступления ещё не пришли. В отчёте о прибыли он не виден в принципе — только в графике платежей на две-четыре недели вперёд. Если вы держите этот график в голове, а не в таблице, разрыв обнаружится в день платежа. В компании на 40 человек в плохой месяц он доходил до 1,2 млн ₽ — около 13% месячного оборота, и искать эту сумму приходилось за несколько часов. Закрывается он не кредитом, а расписанием: остатки по счетам минус обязательные платежи на ближайшие 7–14 дней, пересчитанные в фиксированный день недели. Та же дисциплина снизила долю просроченной дебиторки старше 60 дней с 25% до 10% . Если вы управляете кассой в голове — вы делаете работу, которую должен делать отчёт. И делаете её хуже отчёта, потому что человек не умеет держать тридцать платежей с датами. Признаю: я сам работал именно так и знаю, чем это кончается. Решения принимаются по ощущению «вроде деньги есть», а потом двадцатого числа выясняется, что не есть. Я долго считал это издержкой роста, а не дырой в управлении, — и платил за это каждый месяц. Ниже — что мы поставили вместо ручного управления кассой и во что обошёлся хаос до этого. Почему ручное управление кассой перестало работать Признак, по которому вы поймёте, что уже перешли эту границу: вы держите в голове больше платежей, чем можете назвать по памяти прямо сейчас. Управленческая отчётность не работает, если она держится на памяти одного человека: любой отпуск, перегрузка или конфликт останавливает выплаты. У нас именно так и было — кассовый календарь жил в голове финансиста Марины, а не в таблице, которую может открыть кто-то ещё. Марина умела закрывать кассовые разрывы на глазок: звонила в банк узнать остаток, прикидывала, кому можно заплатить позже, а кому нельзя. Работало — пока компания была маленькой. Параллельно в офисе жил маленький хаос: дворнику платили 5 000 ₽ наличными каждый месяц из офисного фонда без единого документа. Сам фонд — 50 000 ₽ в месяц — был выдан с устным указанием "ведите реестр". Реестра никто не вёл. Когда собственник поднял вопрос спустя несколько месяцев, никто не смог сказать, куда делись прошлые выплаты. Второй симптом того же хаоса — резервы. В тот период Марина же временно закрывала и функцию финансового директора: она рассчитала прибыль и распределила её между сотрудниками — "мы не можем распределить всю премию, давайте подождём" прозвучало слишком поздно, уже после того, как деньги были обещаны. Через несколько дней выяснилось, что денег на рекламу нет — коллеге пришлось вносить личные средства, чтобы кампания не остановилась. Риск был виден за месяц-два до проблемы, но резервный фонд под такие случаи никогда не формировался. Во что обошёлся кассовый разрыв в цифрах Посмотрите на эти суммы и прикиньте свои: у вас похожие потери просто не собраны в одном месте, поэтому кажутся мелочью. В плохой месяц кассовый разрыв доходил до 1,2 млн ₽ — это около 13% месячного оборота компании (1,2 млн ₽ / 9 млн ₽ ≈ 13%), и искать эту сумму приходилось за несколько часов, а не заранее. Отдельно — долг перед поставщиком услуг, накопившийся именно потому, что резерв на такие случаи никогда не формировался: договорились откладывать 30% от прибыли на резервы, но решение пришло с опозданием, и долг перед поставщиком успел вырасти до величины, сопоставимой с месячным лимитом фонда на подрядчиков. Риск без резервного фонда: пока 30% от прибыли не откладывались системно, любой всплеск расходов — реклама, подрядчик, форс-мажор — закрывался за счёт личных денег сотрудников или задержки других платежей. Резервный фонд снимает этот риск только тогда, когда его пополнение проверяется каждую неделю в отчёте, а не «когда вспомнили». Лимит фонда на оплату подрядчиков утверждали на глазок: цифру подняли с 220 000 до 350 000 ₽ не потому, что кто-то посчитал рост объёма работ, а потому что "тратим больше, не хватает". Такое обоснование собственник в итоге завернул и потребовал пересчёта в привязке к фактическому приросту сделок: сравнить помесячный прирост количества и стоимости договоров по периодам и отдельно проверить, нет ли аномального удорожания отдельных видов работ — но время на повторное согласование уже было потеряно. В отделе продаж из 8 менеджеров при среднем чеке 180 000 ₽ и потоке около 50 сделок в месяц зависание даже 10% сделок на статусе "ждём оплату" дольше обычного цикла — это 5 сделок на сумму 900 000 ₽, зависшую в моменте (расчёт: 50 сделок × 10% × 180 000 ₽ = 900 000 ₽). посчитайте на своих цифрах сделок в месяц средний чек, ₽ % зависших сделок под риском ≈ {X} ₽ формула: сделки × чек × доля зависших ÷ 100; оценка суммы, зависшей на статусе «ждём оплату» Ещё один пример того же периода: фонд оплаты труда вырос на 500 000 ₽ без единого нового сотрудника. Когда собственник запросил разбивку по статьям "к утру", никто в компании не смог дать её сразу — расшифровку собирали в ручном режиме почти сутки. Двухнедельный план, который вы можете повторить Проверьте по ходу, что из этого у вас уже есть: обычно половина элементов существует, просто они не связаны между собой и живут у разных людей. Ничего сложного: два отчёта, один регламент и один человек, который за них отвечает. Бюджет — ноль. Решение — заменить "разбираться по звонку" на спринт: две недели работы, конкретные числовые KPI и премия за перевыполнение вместо расплывчатого месячного бонуса. Формат родился из простого требования собственника: если план перевыполнен, доплата 40–50 тыс ₽ выплачивается в середине месяца вместо запланированного ежемесячного бонуса, а не откладывается до квартального подведения итогов. Работает так: Что. Раз в две недели собственник и финансист фиксируют 3–5 задач с числовой целью — не "разобраться с дебиторкой", а "снизить долю просрочки 60+ дней ниже 15%". Чем. Задачи и KPI попадают в общую таблицу, видимую обеим сторонам — без этого условия план превращается в устную договорённость, которую никто не проверит. Куда. Раз в неделю, в фиксированный день и час, факт сверяется с планом на короткой встрече — 20–30 минут, не больше. Кто и когда. При перевыполнении — доплата в середине месяца. При невыполнении план не наказывается штрафом, а разбирается: что помешало. По итогам двух недель план пересобирается под новые цифры, а не продлевается автоматически. И здесь называется вслух навык руководителя, которого у меня самого долго не было: смотреть не на остаток по счёту сегодня, а на график этого остатка на две недели вперёд. Остаток — это факт, график — это решение. Пока вы читаете только факт, вы узнаёте о разрыве последним, уже когда выбирать не из чего. Навык тренируется быстро: две-три планёрки, на которых вы задаёте один и тот же вопрос — «что у нас со счётом через две недели» — и требуете ответ цифрой, а не словом. День и час встречи — не мелочь. Марина настояла на переносе финансовой планёрки с утра на четверг, 13:00: раньше данные за неделю физически не успевали собраться, и разговор шёл по неполным цифрам. Условие приняли — и это единственное её условие, которое не обсуждалось. О том, как такие короткие встречи можно избавить от ручного протоколирования, — в статье планёрка, которая документирует себя сама . ИИ-связка: отчёт о движении денег без ручного свода Ваша задача — принимать решения по цифрам, а не собирать их. Как только вы поняли, на что смотрите каждую неделю, сборку стоит отдать машине. Я тянул с этим шагом дольше всего: мне казалось, что раз отчёт всё равно проверяет человек, автоматизировать нечего. Оказалось наоборот — проверять готовый черновик вы будете охотнее, чем собирать его с нуля. Автоматизация в этой схеме не заменяет финансиста — она готовит черновик отчёта к четвергу, чтобы Марина тратила время не на сбор данных, а на проверку источника, которому доверяет только она сама. Конвейер: банк-выписка и CRM → таблица → дешёвая модель ищет аномалии → таблица с пометками → финансист проверяет и утверждает. Платформа — Google Sheets плюс Apps Script и вызов LLM API. Раз в сутки скрипт подтягивает свежие транзакции в лист "Операции" (дата, статья, сумма, счёт), затем передаёт срез за 8 недель в модель. Для этой задачи не нужна дорогая модель с рассуждениями — вся арифметика уже посчитана формулами в таблице, модели остаётся сравнить цифры и облечь отклонения в понятный текст. Берём дешёвый классификатор уровня "мини": Пример ответа модели: Google Sheets — лист «Аномалии» 17% отклонение ФОТ от среднего 320 000 ₽ риск разрыва, налоговый счёт Статья Показатель Статус ФОТ рост без новых ставок, +17% Счёт «налоговый» нехватка 320 000 ₽ к 18.09 Счёт «Москва» остаток в норме Формула отклонения по ФОТ, которую модель на самом деле просто применяет к цифрам из таблицы: (текущий_ФОТ − средний_ФОТ_за_3_мес) / средний_ФОТ_за_3_мес × 100%. Например: если среднее за три предыдущих месяца — 3 000 000 ₽, а в текущем месяце ФОТ вырос до 3 500 000 ₽ без единого нового сотрудника, отклонение составит (3 500 000 − 3 000 000) / 3 000 000 × 100% ≈ 17% — модель отметит это как аномалию ещё до планёрки, а не после того, как собственник спросит "откуда рост". Инженерная обвязка простая и в этом её надёжность: Apps Script по триггеру времени в 7:00 забирает данные, дёргает LLM API по HTTPS, пишет ответ в отдельный лист "Аномалии". Если вызов модели падает по таймауту — скрипт не молчит: пишет строку "ERROR, запустить вручную" и присылает уведомление в чат-бот финансисту. Перезапуск — кнопка в меню таблицы или повтор через час по крону. Больше о том, во сколько такие связки обходятся в реальных счетах поставщиков API, — в отдельном разборе сколько на самом деле стоит ИИ в месяц . Дебиторка по срокам: цифры до и после У нас разрыв между «прибыль есть» и «денег нет» держался месяцами, и я честно не понимал, куда они деваются. Ответ нашёлся в этой таблице. Сравните со своей ситуацией — скорее всего, у вас сейчас первая колонка. Собственнику нужны не общие слова про "дебиторку выросла", а три метрики, видимые постоянно: общий объём задолженности, её распределение по срокам возникновения и по видам услуг. После того как эти три метрики стали ежедневно видны в отчёте, доля просроченной дебиторки (60+ дней) упала с 25% до 10%. Дебиторка компании держится в районе 4,5 млн ₽ — при обороте 9 млн ₽ в месяц это разумный уровень для сервисной модели с частичной предоплатой. Проблема была не в объёме, а в структуре: четверть суммы зависала дольше 60 дней, потому что никто не отслеживал сроки системно, а разбирался по звонку клиента. Срок дебиторки Доля, до плана Сумма, до плана 0–30 дней 40% 1 800 000 ₽ 31–60 дней 35% 1 575 000 ₽ 60+ дней (просрочка) 25% 1 125 000 ₽ Итого 100% 4 500 000 ₽ Срок дебиторки Доля, после плана Сумма, после плана 0–30 дней 65% 2 925 000 ₽ 31–60 дней 25% 1 125 000 ₽ 60+ дней (просрочка) 10% 450 000 ₽ Итого 100% 4 500 000 ₽ 25% было 10% после На диаграмме — доля дебиторской задолженности старше 60 дней от общей суммы 4,5 млн ₽: до плана 25% (1 125 000 ₽ под риском), после — 10% (450 000 ₽). Формула риска зависшей дебиторки — просто: сумма_дебиторки × доля_просрочки. До плана: 4 500 000 ₽ × 25% = 1 125 000 ₽ под риском невозврата или списания. После: 4 500 000 ₽ × 10% = 450 000 ₽. Разница — 675 000 ₽, которые сместились из зоны риска в зону "0–30 дней". Это не живые деньги, пришедшие на счёт в моменте, а сумма, переставшая быть проблемной зоной баланса — в формуле сработал ровно один множитель, доля просрочки, а объём дебиторки остался тем же. Подробнее о системном контроле дебиторки без ручных напоминаний — в статье дебиторка растёт: контроль, который не зависит от памяти людей . Экономика: что стоит и что даёт Настройка автоматического отчёта заняла около 8 часов работы (оценка), эксплуатация дешёвой модели для анализа аномалий — около 600 ₽ в месяц при ежедневном запуске. Прямой измеримый эффект — экономия времени финансиста: ручной сбор данных для планёрки занимал около 6 часов в неделю, после автоматизации — около 1,5 часа на проверку и правку черновика. Формула для своего случая: (часы_до − часы_после) × ставка_часа × число_недель_в_месяце = экономия в месяц. В нашем случае: (6 ч − 1,5 ч) × 1 050 ₽/ч (оценка) × 4 недели ≈ 18 900 ₽ ≈ 19 000 ₽/мес. Показатель До После Эффект Сбор данных к планёрке 6 ч/нед 1,5 ч/нед −4,5 ч/нед Стоимость времени (оценка, 1 050 ₽/ч) 6 300 ₽/нед 1 575 ₽/нед −4 725 ₽/нед ≈ −19 000 ₽/мес Затраты на настройку и эксплуатацию — 8 ч разово + 600 ₽/мес окупаемость ≈ 2 недели Окупаемость настройки считается так же просто: разовые затраты на внедрение (8 ч × 1 050 ₽/ч (оценка) ≈ 8 400 ₽) плюс первый месяц эксплуатации (600 ₽) делим на месячную экономию (≈19 000 ₽) — получаем меньше месяца, около двух недель. При этом сама экономия времени — цифра скромная рядом с кассовым разрывом на 1,2 млн ₽, который отчёт как раз и должен не допустить: премия 40–50 тыс ₽ за перевыполнение плана обходится компании дешевле одного незапланированного разрыва. Не отчёт сам по себе стоит денег, а то, что нехватку теперь видно за две недели, а не в момент, когда платить уже нечем. Тот же принцип масштабируется на соседние участки: как только черновик отчёта стал приходить автоматически, финансист начала применять ту же схему к сверке остатков по трём счетам и к контролю лимита на подрядчиков — без дополнительных часов на ручной сбор данных. Начните с одного отчёта на этой неделе — движения денег на четыре недели вперёд. Не ждите, пока найдётся финансист: соберите руками, час работы. Выпишите остатки по счетам, обязательные платежи по датам и вычтите одно из другого. Если поймаете хотя бы один платёж, о котором забыли, — час окупился. А если увидите минус на какой-то дате, у вас есть две недели, чтобы его закрыть спокойно, — ровно то, чего не было раньше. Как поставить сборку на автомат и получать отчёт без ручного свода — в бесплатном курсе для руководителей . ## Просроченная дебиторская задолженность: кейс с крипто-предоплатой и требованием вернуть всё за день URL: https://davidgerstein.pro/blog/debitorka-rastet/ Дата: 2026-09-02 Направление: Финансы Цифры: 900 000 ₽/мес риск зависшей дебиторки (оценка); доля просрочки 30+ дней 24%→11% за 6 недель; 20 минут — автоматизация уведомлений рефералам Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Просроченная дебиторская задолженность растёт не потому, что клиенты плохие. Она растёт, потому что у вас нет правила, что делать в день просрочки, — и каждый случай решается заново, в панике и по-разному. Ниже — история, в которой клиент потребовал вернуть предоплату целиком за один день, и то, что мы перестроили после неё. Если у вас в компании возвраты и просрочки разруливаются «по ситуации» — это про вас. Просроченная дебиторская задолженность: что делать в первую очередь Просроченная дебиторская задолженность копится не из-за плохих клиентов, а из-за отсутствия регламента возврата и ежедневного контроля по срокам. Долг зреет тихо: никто не отвечает за конкретную дату, напоминание уходит, когда сумма уже стала проблемой. После постановки контроля доля просрочки 30+ дней снизилась с 24% до 11% за 6 недель . Автоматизация самих уведомлений заняла около 20 минут работы — узкое место было не в технике, а в том, что никто не назначил ответственного. Просроченная дебиторская задолженность и паника: клиент требует вернуть крипто-предоплату за день Просроченная дебиторская задолженность растёт быстрее всего там, где нет регламента на нестандартный случай — а не там, где клиенты «плохие». Когда клиент требует вернуть предоплату немедленно и на его условиях, компания либо теряет деньги в панике, либо теряет клиента и репутацию в затяжном споре. Правило простое: решение о возврате должно быть принято заранее, до того как позвонит конкретный клиент. У нас в практике был именно такой случай. Клиент внёс предоплату криптовалютой — 300 000 ₽, с учётом конвертации на счёт компании пришло 330 000 ₽ (курсовая наценка около 10%). Через несколько недель клиент потребовал вернуть всю сумму в течение одного дня, той же криптовалютой, ссылаясь на устное обещание менеджера «найти нужные корни» — формулировка, которая нигде не была зафиксирована. Юридически это была серая зона: обещание менеджера — не договор, но и молчать про него было нельзя. Руководитель принял решение за час: вернуть 270 000 ₽, удержав 60 000 ₽ — расходы на уже выполненную работу и бонус менеджера. Логика была не «отдать всё, чтобы не судиться» и не «не отдавать ничего, потому что мы правы». Логика — посчитать реальные издержки и вернуть остаток быстро, чтобы не дать конфликту перерасти в публичный спор. Это разовое решение, а не система: оно сработало на конкретных 330 000 ₽. Вопрос, который встал сразу после — что делать, чтобы следующий такой случай не решался в ручном режиме за час до дедлайна. Честно скажу: я сам несколько лет считал, что регламент возврата — бюрократия для больших компаний, а у нас «и так все всё понимают». Понимали ровно до первого клиента, который потребовал деньги назад за сутки. Если у вас сейчас так же — это не ваша вина и не признак слабого управления: правило возврата почти все пишут после первого болезненного случая. Вопрос только в том, сколько таких случаев вы оплатите, прежде чем сядете его писать. Что мы решили после этого случая Разберу по неделям — вы можете взять этот план как есть, он не требует ни бюджета, ни новых людей. После разбора приняли три правила: возвраты фиксируются в отдельном реестре с обязательным полем «причина и кто согласовал», дебиторка контролируется ежедневно по трём срезам, а решения о возврате свыше 150 000 ₽ проходят через одного человека — финансового директора, а не через того менеджера, который вёл сделку. До этого возвраты «вообще никак не фиксировались, никто не вёл, никто не отвечал» — так сформулировал проблему сам собственник на разборе. Каждый менеджер решал вопрос клиента по своему усмотрению, а руководитель узнавал о крупном возврате постфактум, когда деньги уже ушли. Отдельно всплыла реферальная программа: партнёры узнавали о положенном им вознаграждении с задержкой — иногда только тогда, когда клиент сам просил деньги назад, потому что вознаграждение до этого никто не считал приоритетным. Это тоже растит дебиторку, только в обратную сторону — компания задерживает выплаты партнёрам, и они начинают требовать деньги в моменте, вместо спокойного планового цикла. Неделя 1: фиксируем возвраты и чиним рефералку Первое, что вам стоит сделать, — записать правило возврата на бумаге. Пока его нет, каждый ваш менеджер решает по-своему, а клиент это чувствует и давит. Первая неделя ушла на две вещи, которые можно сделать без разработчика: завести реестр возвратов и настроить автоматические уведомления партнёрам. Обе задачи закрываются за один рабочий день, если не откладывать их на «потом». Реестр возвратов сделали в той же таблице, где уже велась дебиторка — колонки: дата запроса, сумма к возврату, сумма фактического возврата, причина расхождения, кто согласовал. Ничего сложного, но именно этого не хватало в кейсе с криптовалютой: если бы реестр уже существовал, решение о 270 000 ₽ из 330 000 ₽ было бы принято по шаблону, а не с нуля. Автоматизация уведомлений партнёрам заняла по факту около 20 минут работы: бот в мессенджере стал сообщать рефералу о закрытии проекта сразу, а не когда клиент сам напомнит о деньгах. Маленькая правка, но она снимает половину напряжения вокруг реферальных выплат — партнёр видит начисление сразу, а не выясняет его постфактум. Отдельно руководителю отдела добавили обязанность: три метрики дебиторки — общий объём, распределение по срокам возникновения, распределение по пакетам услуг — должны быть видны в системе отчётности каждый день, а не собираться раз в месяц перед совещанием. Неделя 2: что сломалось Обратите внимание на этот момент — у вас сломается похожим образом, и лучше знать заранее, где подстелить. На второй неделе выяснилось, что данные, на которые все опирались, сами по себе ненадёжны — а без точных дат «сроки возникновения» дебиторки становятся фикцией. Это главный урок недели: систему контроля нельзя строить поверх кривых данных, сначала нужно починить сами данные. Разработчик настроил ежечасную сверку дат создания сделок в CRM — и обнаружил, что даты «мигрируют»: сдвиг варьировался от 18 до 36 часов при повторной синхронизации. Для дебиторки это критично: если дата возникновения долга скачет на полтора дня туда-сюда, любой отчёт «просрочка 30+ дней» становится приблизительным. Подробный разбор этой проблемы с Битрикс24 и что с ней делать — в отдельной статье: CRM врёт. Как я поймал Битрикс24 на сдвиге дат . Здесь одно правило: пока даты в CRM нестабильны, контроль дебиторки по срокам будет давать ложные тревоги и ложное спокойствие вперемешку. Второй сбой недели — конфликт по мотивации. Один менеджер настаивал начислять бонус в момент подписания договора, не дожидаясь платежа, второй указывал, что расхождения между «продано» и «оплачено» отслеживает отдельный финансист, не связанный с отделом продаж. Решили начислять по факту получения платежа — иначе дебиторка превращается в фикцию вдвойне: деньги ещё не пришли, а премия уже выплачена, и мотивации следить за оплатой у менеджера больше нет. Третий сбой — главному бухгалтеру Марине не хватало исходных данных, чтобы закрыть вопрос: «без данных это будет непонятно», — так она сформулировала проблему, ожидая отчёт о продажах от маркетингового отдела по уже потраченным деньгам. Дебиторку нельзя контролировать силами одного человека, если данные приходят с задержкой из трёх разных источников. ИИ-связка: ежедневный контроль без ручного свода Ваша цель здесь простая: видеть просрочку в день её появления, а не в конце месяца, когда сумма уже неприятная. Ежедневный контроль дебиторки автоматизируется в три шага: выгрузка открытых сделок из CRM, классификация риска дешёвой моделью по каждой строке, алерт в мессенджер при высоком риске — без участия человека до момента, когда решение действительно нужно принимать. Схема конвейера: Bitrix24-вебхук раз в сутки выгружает сделки со стадией «Ожидает оплату» в Google Sheets → Apps Script построчно отправляет данные в модель → модель возвращает классификацию риска и рекомендацию → результат пишется обратно в таблицу и дублируется алертом в Telegram, если риск высокий. Модель здесь нужна дешёвая — классификация 40-60 строк в день не требует дорогой рассуждающей модели, достаточно недорогого классификатора: задача чисто категориальная — сопоставить срок просрочки, сумму и историю платежей клиента с тремя уровнями риска. Пример ответа модели: Инженерная обвязка простая и без внешних сервисов: сам Bitrix24-вебхук и Apps Script крутятся на стороне Google, ключ API модели хранится в свойствах скрипта, а не в коде таблицы. Если выгрузка падает — Apps Script пишет ошибку в отдельный лист «Errors» с таймстампом и шлёт алерт в тот же Telegram-чат, куда падают алерты по высокому риску; повторная попытка — по расписанию раз в час, без участия человека. Раз в неделю, перед планёркой по четвергам, Марина открывает не сырую выгрузку, а уже классифицированную таблицу — и видит только те строки, где риск средний или высокий. Неделя 6: что показали цифры Ориентир для вас: первые результаты видны через полтора месяца, и они скорее про предсказуемость, чем про разовое взыскание. Через 6 недель после запуска ежедневного дашборда доля дебиторки старше 30 дней снизилась с 24% до 11% — это оценка на основе данных дашборда, а не отдельный аудит. Сдвиг цифр дала связка «ежедневный дашборд + фиксация возвратов», вклад отдельно взятого ИИ-классификатора выделить нельзя. На диаграмме ниже — то же распределение по срокам просрочки в деньгах и сравнение доли просрочки старше 30 дней до и после внедрения дашборда. Срок просрочки Сумма (оценка) Доля от риска 0–15 дней 450 000 ₽ 50% 15–30 дней 270 000 ₽ 30% 30–60 дней 135 000 ₽ 15% 60+ дней 45 000 ₽ 5% 0–15 дней 450 000 ₽ 15–30 дней 270 000 ₽ 30–60 дней 135 000 ₽ 60+ дней 45 000 ₽ 24% до 11% после Доля дебиторки старше 30 дней до внедрения ежедневного дашборда и через 6 недель после (оценка на основе данных дашборда). Сама система — три метрики и конвейер, которые не зависят от памяти людей — разобрана отдельно: «Контроль дебиторской задолженности: три метрики и конвейер» . Здесь я разбираю другую половину задачи: что делать, когда просроченная дебиторская задолженность уже возникла, а решение о возврате нужно принять сегодня, а не выстраивать систему с нуля. Экономика: сколько стоило и что дало Прикиньте свою цену вопроса: возьмите сумму просроченной дебиторки и умножьте на стоимость денег для вас — хотя бы на ставку по вашему кредиту. Это то, что вы платите за отсутствие контроля. Внедрение обошлось в ~6 часов настройки разработчика (~9 000 ₽ разово) и ~500 ₽/мес на эксплуатацию, а суммарный эффект — около 133 000 ₽/мес (117 000 ₽ снижения риска дебиторки + 16 000 ₽ высвобожденного времени финансиста, оценка), не считая разового решения в 270 000 ₽ по кейсу с криптовалютой. Формула для своего случая: риск зависшей дебиторки = доля сделок с просрочкой × средний чек × число сделок в месяц. Возьмём отдел из 8 менеджеров с чеком 180 000 ₽ и оборотом 9 млн ₽ в месяц — это около 50 сделок. Если 10% сделок зависает в оплате (5 сделок), риск зависшей дебиторки — 5 × 180 000 ₽ = 900 000 ₽ в месяц (оценка). Снижение доли просрочки 30+ дней с 24% до 11% на этом объёме эквивалентно освобождению около 117 000 ₽ в месяц (900 000 ₽ × 13 п.п.), которые раньше просто зависали дольше нужного. посчитайте на своих цифрах сделок в месяц средний чек, ₽ % зависших сделок риск ≈ {X} ₽ в месяц формула: сделки × чек × доля зависших; оценка сверху, как 900 000 ₽/мес в разобранном кейсе Отдельно — время финансиста: ручной свод дебиторки по трём срезам занимал около 4 часов в неделю, это 16 часов в месяц; по ставке около 1000 ₽/час (типовая почасовая ставка финансиста) — это 16 × 1000 ₽ = 16 000 ₽/мес высвобожденного времени, которое теперь уходит на анализ аномалий, а не на сведение таблиц вручную. Часы финансиста при этом не сократились — они перераспределены на другую работу, поэтому эффектом «в деньгах» это можно считать только условно, как перенаправленную ценность, а не прямую экономию бюджета. Ещё один ориентир — для тех, кто считает экономику через менеджеров, а не финансистов: менеджер обходится компании примерно в 124 000 ₽ в месяц (100 000 ₽ зарплаты плюс около 24 000 ₽ налогов, 48% от базовой ставки 50 000 ₽) — это около 775 ₽/час при 160 рабочих часах в месяц. Если автоматическая классификация риска освободит хотя бы 10% времени одного менеджера от ручной сверки дебиторки, это ещё около 12 400 ₽/мес на человека; этот эффект мы отдельно не измеряли, потому что основной вклад дал не классификатор, а дашборд и регламент возврата — цифры двух эффектов складывать не стоит, чтобы не задвоить экономику. Стоимость внедрения: настройка вебхука, скрипта и промпта — около 6 часов работы разработчика, это разовая задача. При ставке около 1500 ₽/час (типовая почасовая ставка разработчика на подобных задачах) — это 6 × 1500 ₽ = 9 000 ₽ разово. На фоне суммарного эффекта около 133 000 ₽/мес разовые 9 000 ₽ окупаются меньше чем за сутки работы системы — порог входа несопоставимо ниже эффекта, даже если считать консервативно. Автоматизация уведомлений рефералам — отдельные 20 минут, без дополнительных вложений. Эксплуатация классификатора при объёме 50-60 сделок в месяц — около 500 ₽ в месяц на токены: без контроля лимитов легко переплатить в 20 раз за инфраструктуру, которая при аккуратной настройке стоит около 500 ₽/мес, а не 10 000 ₽. Что мы не считаем эффектом: разовый возврат 270 000 ₽ клиенту по крипто-кейсу — это ускорение решения конкретного спора, а не ежемесячная экономия, и складывать эту сумму с эффектом дашборда нельзя — это запас, а не поток. Показатель До дашборда Через 6 недель Эффект (оценка) Доля просрочки 30+ дней 24% 11% −13 п.п. Риск зависшей дебиторки на объёме 9 млн ₽/мес ~900 000 ₽ ~783 000 ₽ ~117 000 ₽/мес высвобождено Время финансиста на ручной свод 16 ч/мес 16 ч/мес (перераспределено на анализ аномалий) ~16 000 ₽/мес ценности перенаправлено Стоимость внедрения — ~9 000 ₽ разово + ~500 ₽/мес окупаемость < 1 суток эффекта Где ломается: контроль дебиторки по срокам не работает, если сами даты в CRM нестабильны — сначала чините синхронизацию, потом стройте отчёты поверх неё. Промпт-классификатор ошибается на новых клиентах без истории платежей — для них правило «повышаем риск на ступень» просто не срабатывает, нужен ручной первый контакт. Регламент возврата не защищает от репутационного риска, если платёж прошёл в криптовалюте вне юрисдикции — юридически взыскать недостающее почти невозможно, поэтому решение всё равно принимает человек, а не модель. И главное: дашборд показывает симптом, а не причину — если дебиторка растёт из-за отсутствия резервов на аванс поставщикам (частая история в услугах с длинным циклом), никакой контроль сроков это не починит, тут нужен отдельный разговор о резервном фонде — этот сюжет разобран в статье об управленческом учёте с нуля . Чек-лист: с чего начать в понедельник Завести реестр возвратов: дата запроса, сумма к возврату, сумма фактического возврата, причина, кто согласовал. Настроить автоматические уведомления по обязательствам, которые задерживаются дольше суток — на боте или в CRM, это 20-30 минут работы. Вывести три метрики дебиторки — объём, распределение по срокам, распределение по пакетам услуг — в отчётность, которую видно каждый день, а не раз в месяц. Прогнать промпт-классификатор на текущей выгрузке сделок и сверить результат вручную на 10 строках, прежде чем доверять ему алерты. Зафиксировать письменно, кто принимает решение о возврате и в каких пределах суммы — без этого правила каждый крупный возврат снова решается за час до дедлайна. Поставить фиксированное время для разбора дебиторки — например, четверг 13:00 — и обсуждать на нём только цифры, у которых есть источник, а не оценки на глаз. Сделайте на этой неделе одну вещь: попросите список всех клиентов с просрочкой больше недели и суммой. Не отчёт, а список с именами. После него вы сами решите, нужен ли вам регламент возвратов, — обычно решение приходит в тот же день. Как поставить ежедневный контроль дебиторки без ручного свода — механика в бесплатном курсе для руководителей . Назвать сумму и срок раньше, чем их назовёт клиент, — это отдельный навык руководителя, и тренируется он на скучных еженедельных разборах, а не в момент конфликта. Мне потребовалось два таких конфликта, чтобы это понять: пока я смотрел на сводную цифру, а не на список должников по именам, решения принимались по громкости клиента, а не по деньгам. Ваш список должников короче, чем кажется, — и именно поэтому его стоит прочитать глазами. Мой личный вывод после этой истории: правило возврата надо писать не тогда, когда клиент требует деньги, а до того. В момент конфликта вы напишете его хуже — под давлением и в пользу клиента. ## Достоверность данных в плане: одна цифра — три смысла URL: https://davidgerstein.pro/blog/upravlencheskie-resheniya-oshibki/ Дата: 2026-09-02 Направление: Стратегия Цифры: план 50 млн ₽ против 20 млн ₽ в презентации, авансы — 37-40% от суммы договора Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы за последний год утвердили хотя бы один план и ни разу не спросили, что именно означает цифра в нём — подписанные договоры, авансы или деньги на счёте, — у вас уже есть решение, принятое вслепую. Вы просто пока не знаете, какое именно и во сколько оно вам обошлось. Достоверность данных обходится дешевле, чем её отсутствие. Цена — не в сумме, которую вы потратили, а в том, чего вы не сделали, пока занимались не тем. Дальше — разбор одной такой ошибки: две недели работы команды против одного часа, который никто не выделил. Совещание. Собственник смотрит на слайд со стратегией маркетинга и молчит секунд десять. Потом спрашивает: «А эта цифра — это сколько мы должны заработать или сколько к нам должно прийти денег?» Тишина. Никто не отвечает сразу. На слайде план: 50 млн ₽ выручки на год. Ниже — текущая заложенная цифра: 20 млн ₽. Разрыв огромный, и первая реакция команды — списать его на темпы роста, сырую воронку, сезонность. Полчаса уходит на обсуждение, за счёт чего компания доберёт недостающие 30 млн: SEO, Telegram, SMM. Собственник слушает вежливо, а потом задаёт вопрос, который разваливает всю дискуссию: «Стоп. Вот эти 20 млн — это сумма подписанных договоров или деньги, которые реально зашли на счёт?» Достоверность данных в плане: путаница между суммой и авансами Ответить однозначно не может никто. Маркетолог считал, что план — это сумма договоров. Финансист был уверен, что это авансовые платежи. Авансы у компании — 37–40% от суммы договора. Смотрите, как это устроено. Под одним словом «выручка» в компании живут три разные цифры, и разница между ними не в процентах, а в разах. Что называют планом Что цифра измеряет Когда появляется Кто её так понимает Сумма договоров Обязательства клиента на бумаге В день подписания Маркетинг, продажи Авансы 37–40% от суммы договора В первые дни после подписания Финансист Деньги на счёте Всё, что фактически поступило По графику платежей, месяцами позже Бухгалтерия Теперь сама механика ошибки — она разъезжается в обе стороны. Если 20 млн на слайде это авансы, то договоров под ними подписано примерно на всю целевую сумму: разрыва в 30 млн нет, есть другая беда — деньги приходят позже, чем нужно, и чинить надо платёжный календарь, а не рекламные каналы. Если же 20 млн это договоры, то на счёт из них в ближайший месяц зайдёт 37–40%, остальное растянется по графику, и до цели в 50 млн дальше, чем полчаса обсуждали на встрече. Одна строка в презентации — и два противоположных решения. В первом прочтении надо чинить сбор денег, во втором — нанимать людей и заливать бюджет в каналы. Команда полчаса обсуждала второе, ни разу не проверив, не первое ли. Это не уникальная беда одной компании, это типовой дефект. В разборе план-факта я показывал случай, где согласованный план оказался равен 40% от исходной цифры — ровно потому, что один документ считал полную сумму сделок, а другой только авансовую часть. А там, где цифру так и не свели, дело кончается тем, что финмодель расходится с фактом в 2,4 раза . Один и тот же дефект, разные документы. Похожий разрыв между тем, что показывает воронка, и тем, что приходит в кассу, я разбирал в материале о том, где теряются деньги между маркетингом и продажами . Проверьте у себя: когда вам приносят план, вы либо спрашиваете, из чего собрана цифра, либо принимаете её как данность. Второе стоит дорого, и стоимость обнаруживается через квартал. Как исправили: час сверки вместо двух недель оформления Решение простое и обидное по своей очевидности: остановили работу над структурой стратегии и потратили час на то, чтобы явно зафиксировать определение каждой цифры плана. Отдельно — сумма договоров. Отдельно — авансы. Отдельно — фактическое поступление денег на счёт. Только после этого разрешили вернуться к презентации. Что именно фиксировали — четыре вопроса, которые теперь задаются к любому числу в плане: Из чего собрана. Договоры, авансы, поступления или что-то четвёртое — одно слово, записанное рядом с числом. На какой момент. Дата подписания, дата платежа или дата закрытия — от этого цифра гуляет на месяцы. Кто владелец. Один человек, который отвечает за это число и к которому идут с вопросом. Не «финансы посчитают». Где перепроверяется. Конкретный отчёт или выгрузка, по которой цифру поднимают за пять минут, а не «спросим у бухгалтерии». Дальше стратегию пересобрали: сначала совокупная картина на год — какой процент лидов даёт каждый канал и какая по нему конверсия, потом фиксация прогресса по годам («в этом году 5% лидов с SEO, в следующем — 35%»), и только в конце тактика. Так же строится и декомпозиция годовой цифры до задачи на неделю : пока не понятно, что считаем, делить не на что. Подробно о том, как стратегия становится рабочим инструментом, а не презентацией для полки, — в отдельном разборе . Скажу честно: окончательного ответа на момент, когда я это пишу, ещё нет. Команда сверяет цифры вручную, потому что автоматической связки между CRM и платежами в компании нет — а это отдельная и очень частая причина, по которой цифры в системе расходятся с реальностью . Без регулярной сверки они расползаются сами по себе . Навык руководителя: отвечать за достоверность данных до решения Я сам два года подписывал планы, не задавая вопрос «из чего собрано это число». Мне казалось, что разбираться в основаниях — работа финансиста, а моя — смотреть на итог. Это была моя ошибка, и стоила она не денег, а недель, потраченных в неверную сторону. Здесь ошибаются все, кого я знаю: вопрос только в том, на какой год работы это замечают. Отвечать за достоверность данных до того, как по ним приняли решение, — это отдельный управленческий навык, и его придётся освоить. Не «быть внимательнее», а конкретное действие: получив план, за минуту спросить, из чего собрано число, и не двигаться дальше, пока ответ у финансиста и у маркетолога не совпал дословно. Руководитель, который это умеет, стоит дороже руководителя, который умеет красиво собрать презентацию по чужим цифрам. Достоверность данных редко ломается заметно. Чаще это ошибка приоритета: сначала оформить, потом сверить. Две недели ушли на структуру и слайды, и только вопрос «а что это вообще за цифра» вскрыл, что в основании плана лежит неопределённость размером почти с сам план. Что сделать на этой неделе: возьмите последний утверждённый план и напротив каждой строки напишите одно слово — договоры, авансы или деньги. Там, где рука зависла, и живёт ваше решение, принятое вслепую. Это час работы против недель переделок. Как принимать такие решения по данным, а не по ощущению срочности, — в бесплатном курсе . Мы теперь начинаем разбор любого плана с вопроса «из чего собрана эта цифра». Правило скучное, зато сэкономило нам не одну неделю работы не в ту сторону. ## Управленческая отчётность: один источник правды вместо трёх мнений URL: https://davidgerstein.pro/finansy/upravlencheskaya-otchetnost/ Дата: 2026-08-31 Направление: Финансы Цифры: 3 обязательных атрибута показателя, расхождение прибыли 39 879 vs 38 790, выручка в файле и дашборде разошлась в сотни раз Суммы пересчитаны на условную компанию — пропорции, механика и выводы реальные. Вас спрашивают, сколько компания заработала в прошлом месяце. Вы открываете таблицу финансиста — одна цифра. Выгрузка из CRM даёт другую. Сводка коммерческого — третью. Дальше двадцать минут совещания уходит на выяснение, чья цифра правильная, и обычно всё заканчивается тем, что верят самому уверенному голосу. Если на вопрос «сколько мы заработали в прошлом месяце» у вас три ответа из трёх источников — у вас нет управленческой отчётности. У вас есть три мнения. Три спидометра, показывающие разное, — это не приборная панель. Вы не поедете быстрее оттого, что их три. Вы просто перестанете смотреть на приборы и начнёте рулить по ощущениям — что, собственно, и происходит в большинстве компаний вашего размера. Что такое управленческая отчётность Управленческая отчётность — это не набор отчётов, а один источник правды на каждый показатель с назначенным хозяином и сроком обновления. Если на вопрос о прибыли есть три ответа из трёх мест — отчётности нет, есть три мнения. Цена отсутствия правила измерима: на сверке в компании на 40 человек дашборд показал прибыль 39 879 против ожидаемых 38 790 , а выручка в файле и в дашборде разошлась в сотни раз. Причину на встрече не установили. Чем управленческая отчётность отличается от бухгалтерской Первое, обо что спотыкаются: «у нас же есть бухгалтерия, она всё сдаёт». Сдаёт — только не вам. Бухгалтерская и налоговая отчётность собирается по чужому регламенту, в утверждённой форме и к сроку сдачи, а читает её проверяющий. Она отвечает на вопрос «правильно ли оформлено», а не на вопрос «что делать в понедельник». Управленческая отчётность — ваша собственная: состав показателей, форму и периодичность вы назначаете сами. Отсюда и критерий качества у неё другой. Бухгалтерский отчёт хорош, когда он корректен. Управленческий — когда по нему можно принять решение, пока решение ещё что-то меняет. Поэтому идеально сданный баланс не закрывает тему: он верен и опоздал. Как это выглядит в жизни Расскажу нашу сверку — не самый приятный эпизод, но самый показательный. Закрывали месяц. Дашборд показал прибыль 39 879 , ожидалась 38 790 . Расхождение небольшое, можно списать на округления — но полезли дальше и обнаружили: по выручке файл и дашборд расходятся в сотни раз . Не на проценты — на порядки. Причину на встрече не нашли. Разошлись с формулировкой «проверить, все ли расходы тянутся в систему». Накануне финансист сидела над сверкой до одиннадцати вечера — и цифры всё равно не сошлись. Здесь важно сказать прямо: это не её вина и не поломка дашборда. Как та же история разворачивалась дальше, когда за отчётность взялись по-настоящему, — в разборе двухнедельного плана финансиста . И файл, и дашборд считали правильно — каждый по своим правилам. Одно место считало по оплатам, другое по датам сделок; в одном расходы подтягивались автоматически, в другом заводились руками. Оба были честны. Не было только правила, чья цифра главная. Диагноз Спор о цифрах невозможно выиграть аргументами, если у показателя нет назначенного источника. Каждая сторона будет права по-своему, а решение примет тот, кто громче или выше по должности. Это не управление — это переговоры о реальности, и вы в них участвуете каждую неделю. Три атрибута, без которых показателя не существует Управленческая отчётность начинается не с таблиц и не с дашборда. Она начинается с того, что у каждого показателя есть три вещи. Не пять и не десять — три. 1. Источник правды — ровно один Одно место, откуда берётся эта цифра. Не «в CRM и в таблице», а одно. Остальные места либо тянут её оттуда, либо не имеют права её показывать. Если два места считают по-разному, вы обязаны выбрать, какое из них главное, — даже если второе кажется точнее. Практическое правило: как только вы видите один показатель в двух местах, где он вычисляется независимо, — считайте, что у вас уже есть расхождение. Оно просто ещё не обнаружено. 2. Хозяин — конкретный человек Не отдел и не должность, а имя. Тот, кому вы звоните, когда цифра выглядит странно, и кто отвечает не за «предоставление данных», а за их достоверность. Разница принципиальна: предоставить можно и мусор. Это та же логика, что и с владельцем процесса при внедрении ИИ : показатель без имени рядом с ним живёт своей жизнью, пока однажды не подводит на важном решении. 3. Срок обновления — известный заранее Когда цифра становится актуальной. Ежечасно, ежедневно к девяти, еженедельно по четвергам — неважно, важно что это известно всем и не зависит от того, попросил ли кто-то. Мы закрепили еженедельный коммерческий отчёт за четвергом — и он перестал быть «когда соберём данные». Звучит мелочью, но именно фиксированный день превращает отчёт из события в процесс. Показатель Источник правды Хозяин Обновление Выручка месяца Учётная система по оплатам Финансист Ежедневно к 10:00 Пайплайн отдела продаж CRM, дашборд тянет автоматически Руководитель продаж Ежечасно Дебиторка по срокам Учётная система Финансист Ежедневно Конверсия воронки Дашборд на данных CRM Руководитель продаж Ежедневно План-факт по направлению Финмодель Операционный директор Еженедельно, четверг Заполните такую таблицу по своим показателям — и вы сразу увидите дыры. Обычно их две: показатель, у которого источников два, и показатель, у которого хозяина нет вообще. Один отчёт вместо трёх Второй управленческий поворот, к которому мы пришли не сразу. Формулировка была такая: «чем мне создавать два отчёта? мне проще создать один» . Звучит как лень, а на деле — единственный рабочий подход. Мы собрали один интерактивный отчёт вместо стопки разрозненных документов: договоры по источникам, пайплайн по менеджерам и месяцам, оплаты и выставленные счета с разбивкой по каждому сотруднику, с возможностью провалиться в конкретный контракт. Дальше он вырос в дашборд, где руководители смотрят статистику по всем подразделениям — маркетинг, продажи, платёжный календарь, персональное обслуживание — вместо того чтобы лазить по CRM и таблицам. Отдельной вкладкой пошёл контроль крупных клиентов: чек выше порога, ежедневная проверка статусов, переход в карточку одним кликом. Что именно выводить на такой экран и почему половину блоков надо убрать — в отдельном разборе . Ключевое не в красоте интерфейса. Ключевое в том, что перестал существовать вопрос «а где посмотреть» . Пока ответов на него несколько, часть команды всегда смотрит не туда. Поиск и сверка данных — 45% времени на отчётность Оформление и рассылка — 30% Собственно анализ и решения — 25% Так распределяется время на отчётность, пока нет единого источника. Заметьте пропорцию: на то, ради чего всё затевалось — на решения — уходит четверть. Три четверти съедает обслуживание самого процесса. Во что выливаются эти часы в деньгах — посчитал на одном ежедневном отчёте : полчаса в день это около 11 000 ₽ в месяц. Автоматизация без наведения порядка эту пропорцию не меняет, она просто ускоряет первые две строки. Светофор вместо чтения таблиц Отчёт, который надо читать, читают плохо. Отчёт, который сам показывает проблему, работает. Мы сделали динамический отчёт по воронке с обновлением каждый час, где по каждому менеджеру видно: клиент, текущий статус, дата создания сделки, сколько дней она в этом статусе и индикатор — зелёный, жёлтый, красный — по нормативному сроку для этой стадии. Разница с обычной выгрузкой огромная. В выгрузке зависшую сделку надо искать. В светофоре она сама поднимает руку. У нас была сделка, провисевшая 540 дней , и всё это время она попадала в прогноз как живая — просто потому, что никто не считал дни в статусе. Что именно выводить в недельную сводку и почему итоговая выручка там не главная цифра — разобрал отдельно на реальной неделе. Норматив по стадии — самая недооценённая часть конструкции. Без него любой срок выглядит нормальным: сделка «в работе» и месяц, и год. С ним становится видно не только конкретное зависание, но и системная проблема — например, что все сделки встают на одном и том же этапе. Что можно отдать машине, а что нельзя Здесь я должен быть честным, потому что журнал про ИИ, и соблазн сказать «отдайте отчётность нейросети» велик. Не отдавайте целиком. У нас была модель для стратегического планирования — она выдавала убедительно звучащие прогнозы с непроверенными допущениями . Не учла премии сотрудников. Недостаточно обосновала целевые показатели. Проблема не в том, что ошиблась, — проблема в том, что ошиблась убедительно: цифры выглядели правдоподобно и прошли бы, если бы не стали пересчитывать руками. Мы вернулись к пошаговому ручному пересчёту для верификации и автоматизируем поэтапно. Правило, которое из этого выросло: машина считает, человек отвечает. Автоматизировать сбор, сверку, подготовку, рассылку — да, это лучшее применение. Отдать ответственность за цифру — нет, её невозможно делегировать не-человеку. Задача Кому Почему Собрать данные из систем Машине Механическая работа, ошибки видны сразу Свести расхождения между источниками Машине, с показом расхождений человеку Находит быстро, но решать, какая цифра верна, — не её дело Посчитать производные показатели Машине Формулы детерминированы, если записаны явно Объяснить, почему показатель изменился Человеку, машина готовит версии Модель уверенно придумывает причины, которых не было Спрогнозировать Человеку с проверкой допущений Убедительный прогноз с дырой опаснее отсутствия прогноза Отвечать за достоверность Только человеку Ответственность не делегируется машине в принципе Отчёт, которым не пользуются Самая обидная категория провалов — когда всё собрано правильно и никто не смотрит. У нас был дашборд, который сделали, запустили, показали. Через две недели выяснилось, что в него никто не заходит. Причина оказалась не в дашборде: не назвали, кто по нему принимает решения. Красивая витрина без покупателя. Тот же механизм в более дорогом варианте: контур оценки разговоров выдал 7 139 оценок , а в управленческое решение превратилась ровно одна . Данные копились, отчёты формировались, петля обратной связи не замкнулась. Проверка на своей отчётности простая. Возьмите последний отчёт и спросите: какое решение было принято на его основании за последний месяц? Если ответа нет, отчёт не нужен — либо в нём не те показатели, либо у него нет адресата. Отменять его не обязательно, но и считать работающим больше нельзя. Когда отчётность врёт, а все довольны Отдельный сюжет, который стоит знать заранее. Отдел показал результат на 40% выше плана . Казалось бы, праздник. Но похвалить команду не получилось: план был построен на неверной базе, и перевыполнение означало не блестящую работу, а ошибку в исходных допущениях. Цифра формально отличная, управленческого смысла ноль. Причина глубже, чем кажется. Плановые показатели фиксируются один раз, а реальность меняется: спрос, законодательство, внешняя обстановка. Через три месяца план устаревает, но продолжает жить в отчёте как эталон, и по нему меряют людей. Мы вышли из этого через формульные показатели вместо фиксированных : если заложен темп роста, формула сама пересчитывает план при загрузке данных очередного месяца. Стратегия перестала требовать переписывания каждые три недели и осталась рабочим инструментом. Подробнее — в разборе про план-факт без вранья . С чего начать за один вечер Не с покупки системы и не с найма аналитика. С листа бумаги. Шаг первый. Выпишите три показателя, которые вы называете первыми, когда вас спрашивают о состоянии дел. Не десять — три. Обычно это выручка, что-то про пайплайн и что-то про деньги на счету. Шаг второй. Для каждого запишите три строки: откуда цифра, кто отвечает, когда обновляется. Именно записать, а не подумать — разница обнаруживается на второй строке. Шаг третий. Там, где не получилось записать, — там и есть ваша задача на ближайший месяц. Обычно не получается с хозяином: цифра как бы общая, отвечает как бы система. Шаг четвёртый. Назначьте день недели, когда вы смотрите на эти три показателя. Один день, повторяющимся событием в календаре. Это вся конструкция. Дальше её можно наращивать — добавлять показатели, автоматизировать сбор, строить дашборд. Но без этих четырёх шагов любая автоматизация ускорит существующий бардак, а не устранит его. Сколько времени займёт сама автоматизация и от чего зависит срок — считал отдельно . Промпт: собрать паспорт отчётности Самая скучная часть — описать текущее состояние. Её можно свернуть в один заход: расскажите машине про свои отчёты как есть, включая бардак, и попросите разложить. Ответы проверяйте — модель склонна предлагать красивую структуру вместо того, чтобы указать на дыры. Навык, который здесь тренируется Назначать источник правды для каждого показателя — базовая гигиена управления, такая же обыденная, как подписывать договоры. Её отсутствие не выглядит катастрофой: компания годами живёт с тремя версиями выручки и как-то работает. Но каждое решение в такой компании принимается с поправкой на недоверие к цифрам, и поправку эту никто не считает. Проверьте себя на одном вопросе: если ваш финансист и ваш коммерческий назовут разные цифры выручки, вы знаете заранее, чья версия главная? Если да — отчётность у вас есть. Если решать будете на месте, глядя на обоих, — пока нет. Как разводить такие расхождения по шагам — разобрал на сверке платежей . Все компании сейчас на одной беговой дорожке, и обгоняют не те, у кого больше данных. Данных у всех примерно поровну — их девать некуда. Обгоняют те, кто может посмотреть на цифру и сразу принять решение, не тратя двадцать минут на выяснение, откуда она взялась. Возьмите сегодня три показателя и запишите по три строки на каждый. Это пятнадцать минут, и по итогу вы либо успокоитесь, либо увидите, где именно ваша компания живёт вслепую. Оба результата полезны — второй полезнее. Сводка всех наших производственных цифр и определений — на отдельной странице . ## Внедрение ИИ: три развилки, на которых ломаются девять из десяти URL: https://davidgerstein.pro/operacii/vnedrenie-ii-v-biznese/ Дата: 2026-08-31 Направление: Операционное управление Цифры: 3 развилки · пилот от десятков долларов · 2–3 месяца до устойчивой пользы Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы дочитали до решения «надо внедрять» — самое опасное одновременно позади и впереди. Позади сомнения. Впереди три развилки, на которых ломаются девять внедрений из десяти, и ни одна из них не техническая. Я прошёл эти развилки трижды: контроль звонков, разбор документов, протоколы планёрок. Два раза с ошибками, о которых расскажу честно. Ниже — маршрут, по которому можно пройти быстрее меня. Что такое внедрение ИИ и сколько оно занимает Внедрение ИИ — это перевод одного повторяющегося процесса на машинного исполнителя с сохранением человека на приёмке. Технически контур запускается за две-три недели, до устойчивой пользы проходит два-три месяца: неделя ручных прогонов, неделя-две теневого режима со сверкой, месяц эксплуатации с плотной приёмкой. Пилот через API стоит десятки долларов. Настоящая цена — часы руководителя на калибровку и приёмку. Контур оценки звонков в компании на 40 человек обходится примерно в $300 в месяц на весь поток разговоров отдела продаж. Почему технология — не проблема Смотрите, что обычно происходит. Компания решает внедрять ИИ, зовёт подрядчика, тот показывает демо, называет сроки и сумму. Через полгода проект тихо сворачивается: технически всё работало, но люди продолжили делать по-старому. Это не редкость и не невезение — это правило. Технология сегодня доступна и дешева: модель покупается, инструменты открыты, вход стоит десятки долларов. Собрать работающий контур — задача на недели. А вот заставить компанию перестать работать по-прежнему — задача на месяцы, и она не решается ни бюджетом, ни подрядчиком. Поэтому весь этот гайд — про управленческую часть. Технику я разбираю в других материалах: как устроен ИИ-агент и как подключить машину к вашим системам . Технически запустились 10 из 10 Дошли до плотной приёмки ~4 Отключили старый способ 1–2 Пропорция на схеме — не статистика рынка, а то, что я вижу вокруг себя и в собственных проектах: запуск даётся всем, доводит до конца меньшинство. Дальше — три места, где теряются остальные. Развилка первая: какой процесс взять первым Здесь ошибаются чаще всего, и ошибка выглядит логичной: берут самое больное. Отдел, где хуже всего, процесс, который раздражает сильнее прочих. Разумно — и почти всегда неверно. Больное обычно потому и больное, что сложное: там нет правил, нет данных, есть конфликт между людьми. Машина в такой ситуации не спасает, а обнажает — и вы получаете разочарование раньше первого результата. Правильный критерий — три признака сразу: Признак Как проверить у себя Поток Задача повторяется десятки раз в неделю. Пять звонков или три договора в месяц машине отдавать незачем Проверяемое правило Вы можете письменно описать, что считается хорошим результатом. Не получается за полчаса — правил нет, есть привычка конкретного человека Получатель Есть человек, которому результат нужен регулярно и который заметит, если его не будет Наш первый контур — оценка звонков — подошёл по всем трём: 120 разговоров в день, чек-лист качества и руководитель отдела продаж, которому нужны разборы. А вот попытка начать с чего-то более «стратегического» у меня провалилась бы: там нет ни потока, ни проверяемого правила. И отдельно про должности-призраки. Самые быстрые деньги лежат не в отнятой у людей работе, а в той, которую у вас не делает никто : слушать все звонки, читать все входящие договоры, сводить отчёт каждое утро. Там нет сопротивления команды — вы не забираете ничью работу, вы закрываете дыру. Если кандидатов несколько и все выглядят достойными — прогоните каждого через тест из четырёх вопросов: как выбрать первый процесс для автоматизации . Там же разобрано, почему мой самый больной процесс идёт четвёртый месяц, а взлетел совсем другой. Развилка вторая: кто отвечает внутри Теперь неприятная часть, которую подрядчики не проговаривают. Внедряя ИИ, вы получаете в компанию не минус позицию, а плюс две: машину-исполнителя и человека, который ею руководит. Пишет инструкцию, калибрует, принимает работу, разбирает расхождения. Машина не отвечает ни за что — спросить с неё нельзя, уволить бессмысленно. Кого именно назначить и три обязанности, которые нельзя передать подрядчику, — в разборе «Специалист по внедрению ИИ: кого назначить внутри компании» . Там же цифра, объясняющая цену отсутствия хозяина: разрыв в калибровке −25,5 п.п., замеренный ровно один раз. Этот человек — не ИТ-отдел. ИТ поставит и настроит, но принимать результат должен владелец процесса: руководитель продаж для оценки звонков, руководитель операций для разбора документов. Тот, кто заметит, что оценки перестали соответствовать реальности, и кому есть дело до того, чтобы они превращались в решения. Вести внедрение — это не ИТ-компетенция. Это управленческий навык: поставить проверяемую задачу, принять работу, вовремя отключить старый способ. Осваивается на первом же контуре, но кем-то в вашей компании — осваивается. Где ломается Проверка перед стартом ровно одна: назовите имя человека, в чьём календаре появятся приёмка и разборы. Не отдел, не роль — имя. Если его нет, вы покупаете не внедрение, а дорогую имитацию: контур будет исправно работать в стол. Знаю по себе: наш контур оценки звонков выдал 7 139 оценок при одном содержательном отзыве . Разбор этого провала — там же. Инструкция такого человека для машины выглядит буднично — вот каркас, который вы заполните под свой процесс: Сравните с должностной инструкцией сотрудника — совпадение почти дословное. И если написать такую инструкцию не получается, вы узнали о своём процессе главное: правил в нём нет, есть привычка конкретного человека. Это неприятно, но обходится в неделю, а не в бюджет внедрения. Развилка третья: когда отключается старый способ Это то, о чём почти не говорят, а между тем именно здесь умирает большинство внедрений. Пока новый и старый способ работы живут параллельно, команда держится за привычный. Не из вредности: привычный понятен, за него не спросят, он не требует учиться. В итоге компания платит дважды — за машину и за прежний ручной труд, — а эффекта нет ни от одного. Признак, по которому вы отличите живое внедрение от умирающего: назначена ли дата, после которой старый способ перестаёт работать. Не «постепенно перейдём», а конкретное число в календаре. У нас это выглядело так: месяц параллельной работы — контролёр слушала звонки и машина оценивала, расхождения разбирались. Потом дата: с такого-то числа ручная выборочная проверка остаётся, а сплошное прослушивание прекращается. Без этой даты мы бы до сих пор делали и то и другое. Оговорка: отключать можно только после калибровки. Дата назначается не в начале, а в момент, когда цифры показали, что машине можно доверять на этом участке. Подробнее про типовые ошибки этого этапа — в разборе умирающих внедрений . Маршрут внедрения ИИ: два-три месяца по неделям Откуда берутся именно эти два-три месяца и почему у одних выходит 6 недель, а у других полгода при той же работе подрядчика — посчитал в разборе «Внедрение ИИ в компании: сколько времени занимает» : срок меряется циклами приёмки, а их длина целиком в вашем календаре. Этап Что происходит Результат Неделя 1 Ручные прогоны Процесс гоняется в чате руками, на реальных данных. Выясняется, какие правила вы забыли сформулировать Черновик инструкции и список границ Недели 2–3 Теневой режим Машина работает автоматически, результат никуда не идёт — только сверяется с человеческим Цифра доверия вместо ощущения Недели 4–7 Плотная приёмка Результат используется, человек смотрит всё. Всплывают редкие случаи Отлаженные границы, назначенная дата отключения Неделя 8+ Рабочий режим Старый способ отключён, приёмка выборочная и по пометкам машины Контур в эксплуатации Быстрее бывает, но обычно это значит, что пропущен теневой режим — и тогда вы узнаёте о качестве от клиентов, а не от сверки. Что делать с сопротивлением команды Вопрос, который вам зададут раньше технических: «нас что, заменяют?» И от вашего ответа зависит, будет внедрение идти или буксовать. Отвечать надо до старта и честно. Если машина закрывает работу, которую никто не делал, — так и скажите: контроль всех звонков вместо четверти, разбор всех документов вместо выборки. Никто не теряет места, закрывается дыра. Это правда, и её легко проверить. Если же машина забирает часть чьей-то работы — не прячьте это. Скажите, что освободится время, и назовите, на что оно пойдёт. Люди боятся не машины, а неизвестности: непонятно, что будет со мной через квартал. И приём, который снял у нас больше сопротивления, чем все объяснения: делать оценку прозрачной, чтобы её можно было проверить. Как именно — в разборе про внедрение контроля без саботажа . Сколько это стоит на самом деле Три части, и первая — самая маленькая. Операции. Через API это центы за операцию. Наш контур оценки звонков — примерно $300 в месяц на весь поток отдела продаж, то есть около 9 ₽ за разговор против ~130 ₽ при ручной работе контролёра (оценка). Пилот, чтобы просто попробовать, стоит десятки долларов. Настройка. Разовая: описать типы, собрать связку, настроить подключения. Дни или недели работы, в зависимости от того, есть ли у вас разработчик. У нас на разбор документов ушла неделя только на описание 79 типов — и это была основная работа, а не программирование. Внимание руководителя. Здесь настоящие деньги. Первые месяцы это часы каждую неделю: калибровка, разбор расхождений, обновление правил. Дальше меньше, но в ноль не сворачивается никогда . посчитайте цену вашего процесса вручную операций в месяц минут на операцию ставка исполнителя, ₽/час ручная обработка ≈ {X} ₽ в месяц полученную сумму сравнивайте не с нулём: часть работы по приёмке останется людям И главное про деньги: не считайте стоимость нейросети, считайте себестоимость одной вашей операции. Пока вы не знаете эту цифру, вы не управляете процессом — как мы это считаем , разобрано отдельно, включая ночь, которая стоила минус сорок долларов из-за отсутствия лимита. Две ошибки, которые стоили мне месяцев Первая — искал более сильную модель вместо того, чтобы описать свои данные. Разница между моделями оказалась в пределах погрешности, разница от описания типов — двадцать шесть процентных пунктов точности. Как это выглядело в цифрах, разобрано в истории про распознавание документов . Вторая — строил стопроцентную автоматику, считая половинчатые режимы слабостью. Ошибка ровно наоборот, и обошлась она дороже первой: доверие команды восстанавливается медленнее, чем настраивается техника. Обе ошибки об одном: я решал техническую задачу там, где стояла управленческая. Это и есть главный риск внедрения — он не в модели. Внедрять самим или звать подрядчика Решение зависит не от бюджета, а от того, есть ли у вас человек из прошлого раздела. Своими силами реально чаще, чем принято думать: инструменты открыты, вход стоит десятки долларов, а основная работа — управленческая. Так начинали мы, и оглядываясь, считаю это правильным: мы разобрались в собственных процессах глубже, чем разобрался бы любой внешний исполнитель. Подрядчик нужен, когда процесс завязан на ваши системы и требуется разработка подключений. Но требуйте одного: правила и инструкции пишутся вместе с вашим человеком и остаются у вас в читаемом виде. Инструкции, а не код, — главный актив этого проекта. Уйдёт подрядчик, останутся правила — восстановите за недели. Наоборот — начнёте с нуля. И красный флаг при выборе: если вам называют срок в месяцы и сумму в миллионы за один процесс — либо продают платформу вместо контура, либо закладывают в смету собственное обучение за ваш счёт. Как понять, что внедрение ИИ состоялось Не по числу операций и не по аптайму. Три признака: Решения меняются. Из-за работы машины еженедельно случаются управленческие действия: разборы, правки процессов, изменённые скрипты. Две недели без единого решения — контур работает в стол. Старый способ отключён. Не «почти», не «остался на всякий случай». Отключён, и никто не просит вернуть. Себестоимость операции известна. Вы можете назвать её вслух, и она стабильна. Не можете — вы не управляете контуром, а спонсируете его. Что сделать на этой неделе Не искать подрядчика и не изучать рынок платформ. Три вещи за вечер. Первое. Выпишите процессы с потоком — те, что повторяются десятки раз в неделю. Отметьте, у каких из них есть проверяемое правило качества. Второе. По одному такому процессу посчитайте цену операции вручную. Калькулятор выше. Эта цифра решит, стоит ли вообще начинать. Третье. Назовите имя человека, который будет принимать работу машины. Если имени нет — не начинайте: вы точно повторите мой провал с семью тысячами оценок, из которых в решение превратилась одна. Дальше — механика: анатомия исполнителя , подключение к вашим системам , работа с данными . А пройти весь маршрут по шагам, с практикой на своих процессах, можно в бесплатном курсе — он бесплатный и идёт в Telegram. И если вы сейчас читаете это с мыслью «у нас всё то же самое, только хуже» — спокойно. Я потратил на это два года: подступался к очевидно нужной задаче, откладывал, возвращался, снова откладывал. Не потому что был занят, а потому что не понимал, с какой стороны браться. Когда наконец сел — первый работающий результат появился за недели. Дорого обошлось не внедрение, а ожидание. И последнее. Внедрение ИИ сегодня — не про технологический прорыв, а про обычную управленческую работу: выбрать участок, назначить ответственного, отключить старое вовремя. Компании, которые это поняли, обгоняют не потому, что у них лучше модели. У всех одинаковые модели. У них есть человек, который довёл дело до конца. ## Дашборд руководителя: почему красивый умирает за две недели URL: https://davidgerstein.pro/blog/dashboard-dlya-rukovoditelya/ Дата: 2026-08-31 Направление: Финансы Цифры: 2 недели без единого захода, 1 вопрос к каждому блоку, переход в карточку важнее любого графика Цифры пересчитаны на условную компанию — механика и выводы реальные. Если у вас есть дашборд, но вы не можете назвать имя человека, который по нему принимает решения, — дашборда у вас нет, есть витрина. Наш прожил ровно 2 недели с нулём заходов, и данные в нём всё это время были в полном порядке. Что должно быть на дашборде руководителя Только те блоки, из которых следует конкретное действие, и обязательный переход в карточку объекта одним кликом. Полезный минимум для отдела продаж: пайплайн по менеджерам, дата последнего контакта, дни в статусе со светофором по нормативу, конверсия договоров в оплату. Главная причина смерти дашбордов — не данные и не дизайн. Дашборд отдела продаж собрали, запустили, показали, а через 2 недели выяснилось, что в него не заходит никто: не назвали, кто по нему принимает решения. Красивый дом, в который никто не вошёл История, после которой я перестал радоваться готовым дашбордам. Собрали. Данные тянутся, графики строятся, всё аккуратно. Показали команде, все покивали. Через две недели случайно выясняется: заходов ноль . Не «мало» — ноль. Первая реакция была предсказуемой: значит, не те показатели, надо доделать. Полезли разбираться — с показателями всё нормально. Проблема оказалась в другом: мы не назвали, кто по этому дашборду принимает решения. Он существовал как витрина: посмотреть можно, а зачем — непонятно. Если вы не можете назвать имя человека, который принимает решения по вашему дашборду, — он умрёт через две недели, и виноваты будут данные. У нас в периметре была история покрупнее и с той же болезнью. Портал: собрано 400 тысяч вопросов с автоответами, сделан дизайн, контент готов — а технически система не собралась. Формулировка коллеги стала внутренним термином: «красивый дом, но дверей нету, как зайти непонятно» . Дашборд без адресата — ровно тот же дом. Всё построено, войти некому. Один вопрос к каждому блоку Проверка, которой я теперь прогоняю любой экран. Встаньте перед своим дашбордом и на каждом блоке ответьте: какое действие человек совершает, увидев это? Не «понимает ситуацию», не «держит руку на пульсе» — действие. Кому звонит, что открывает, о чём спрашивает. Блок Какое действие следует Вердикт Сделки без касаний дольше норматива Открыть карточку, позвонить менеджеру Оставить Дата последнего контакта по клиенту Написать клиенту сегодня Оставить Конверсия договоров в оплату по менеджерам Разобрать с тем, у кого просело Оставить График выручки по месяцам за 2 года Никакого — прошлое неуправляемо Убрать или спрятать в архив Круговая диаграмма источников лидов Никакого без разреза по качеству Переделать Общее число лидов за период Никакого — цифра для хвастовства Заменить на лиды в работе на менеджера Обычно после такой ревизии остаётся четыре-шесть блоков вместо пятнадцати. И это не обеднение: каждый график, из которого не следует действие, крадёт внимание у того, из которого следует. Человек, открывший экран с пятнадцатью блоками, не изучает их — он скользит взглядом и закрывает. Отбирать проще, когда у каждого показателя заранее записаны источник, хозяин и срок обновления : блок, у которого этих трёх атрибутов нет, почти всегда и оказывается лишним. Переход в карточку важнее любого графика Самое недооценённое место. В нашем дашборде продаж работает не аналитика сама по себе, а то, что из любой строки можно провалиться в конкретную сделку — одним кликом, прямо в карточку. Без этого перехода сценарий выглядит так: руководитель видит проблемную сделку, переключается в CRM, ищет её по фамилии клиента, не находит с первого раза, отвлекается на звонок — и не возвращается. Я наблюдал это десятки раз и сам так делал. С переходом сценарий другой: увидел, кликнул, оказался в карточке, написал менеджеру. Двадцать секунд вместо пяти минут и без потери намерения по дороге. Правило Работающая аналитика заканчивается действием, а не наблюдением. Если из вашего дашборда нельзя попасть в объект, о котором он рассказывает, — вы построили не инструмент, а отчёт с картинками. Разница в том, что отчёт читают раз в месяц, а инструментом пользуются каждый день. Что реально выводим Состав нашего дашборда продаж — не как эталон, а как пример логики отбора. Каждый блок отвечает на вопрос про действие. Пайплайн по менеджерам. Кто чем занят и сколько у кого в работе. Действие: перераспределить нагрузку, если у одного втрое больше. Дата последнего контакта по каждой сделке. Самый работающий блок вообще. Действие: связаться с теми, о ком забыли. Заброшенные сделки без касаний видны сразу, а не при ручной ревизии раз в квартал. Дни в статусе и светофор по нормативу. Зелёный, жёлтый, красный по каждой стадии. Действие: разобраться с красными сегодня. У нас сделка провисела 540 дней и всё это время считалась живой — именно потому, что дней в статусе никто не считал. Конверсия договоров в оплату. Разрыв между «подписали» и «заплатили» — место, где деньги теряются тише всего. Действие: дожать конкретные неоплаченные договоры. Источники сделок. Только в связке с качеством, иначе бесполезно. Действие: перераспределить бюджет. Отдельно был запрос, который многое объясняет про смысл дашборда: показать договоры с разрезом — имя менеджера, клиент, сумма, дата выставления и была ли встреча . Зачем: чтобы видеть, когда сделки закрываются после встреч, а когда без них. Это не любопытство — это проверка гипотезы, что встречи вообще нужны. Хороший дашборд позволяет такие гипотезы проверять, а не только смотреть на итоги. Блоки с явным действием — 60% ценности Переходы в карточки объектов — 30% Обзорные графики и итоги — 10% Отдельная вкладка под то, что нельзя пропустить Приём, который сработал лучше, чем ожидалось. У нас есть категория клиентов, которых нельзя терять по невнимательности: крупный чек, высокая цена ошибки. Формально они видны в общей таблице — вместе со всеми остальными. Мы вынесли их в отдельную вкладку с ежедневной проверкой статусов и переходом в карточку. Ничего технически сложного: тот же список, отфильтрованный по порогу суммы. Эффект оказался непропорционален усилиям, и причина в психологии, а не в данных. В общей таблице такой клиент требует, чтобы про него вспомнили. В отдельной вкладке он сам напоминает о себе фактом её существования. Вспоминать — плохой механизм , он ломается ровно в тот день, когда вы заняты. По той же логике мы вынесли отдельно платёжный календарь и контроль персонального обслуживания. Каждая вкладка — это одна ответственность одного человека, а не срез данных. Разбирал этот случай подробно — платёжный календарь . Кто смотрит: сверху вниз или каждый своё Развилка, которую стоит пройти осознанно. Первый вариант: дашборд смотрит собственник, а остальные получают выжимку. Второй: каждый руководитель смотрит своё подразделение сам — маркетинг, продажи, платёжный календарь, персональное обслуживание. Мы пришли ко второму, и разница оказалась не в удобстве. Пока переходы видит только первое лицо, руководители работают с итоговой цифрой в голове и узнают о проблеме, когда её называют вслух на планёрке. Когда каждый видит свою конверсию рядом с нормативом, часть проблем решается без вашего участия — просто потому, что человек видит своё отклонение. Неприятная сторона: до этого он его не видел годами, а вы были уверены, что он в курсе. Я через это прошёл и рекомендую не обижаться, а исправлять. Данные есть, решений нет Худший сценарий не «дашбордом не пользуются», а «дашбордом пользуются, но ничего не меняется». Он выглядит благополучно и потому живёт годами. Наш пример честнее любого чужого: контур оценки разговоров выдал 7 139 оценок , а в управленческое решение превратилась ровно одна . Данные копились, экран работал, петля не замкнулась. Проверка на своём дашборде: назовите три решения, принятые по нему за последний месяц. Не «посмотрели и обсудили» — решения: кого-то перераспределили, кому-то позвонили, что-то отменили. Если трёх не набирается, у вас витрина. Лечится это не доработкой экрана, а ритуалом: фиксированный день, когда по дашборду проходят и принимают решения вслух. Как это устроено в недельном цикле — разобрал отдельно . Четыре способа убить дашборд, которые выглядят как забота Добавить всё, что попросили Каждый руководитель на демонстрации просит что-то своё, и отказать неловко. Через три итерации экран превращается в свалку, где нужное соседствует с тем, что попросили один раз для проверки гипотезы и забыли. Правило простое: новый блок добавляется только вместе с ответом на вопрос про действие, и раз в квартал проводится ревизия на вылет. Показывать всё за всё время Соблазн вывести историю за два года понятен: выглядит солидно. Но управляемо только ближайшее — эта неделя, этот месяц. История нужна раз в квартал при планировании, а не ежедневно. Уберите её на отдельную вкладку, и главный экран сразу станет читаемым. Обновлять реже, чем принимаются решения Дашборд, обновляющийся раз в сутки, бесполезен для того, кто принимает решения по ходу дня. Мы делали отчёт по воронке с ежечасным обновлением именно поэтому: сделка, которая встала утром, должна быть видна днём, а не завтра. И обратное верно — ежечасное обновление показателя, по которому решают раз в месяц, только создаёт шум. Сделать вход неудобным Самая обидная категория. Отдельный логин, VPN, ссылка, которую надо искать в переписке, — и всё, дашборд не открывают. Не потому что он плох, а потому что каждое открытие стоит усилий. У нас он живёт по своему адресу, открывается с телефона и не требует вспоминать пароль каждый раз. Это не про удобство, это про то, будут им пользоваться или нет. Как понять, что дашборд прижился Три признака, все наблюдаемые без опросов. Первый: на планёрке на него ссылаются, а не приносят свои выгрузки. Пока люди готовят собственные таблицы к встрече, у дашборда нет доверия — и обычно оно отсутствует не зря: где-то он расходится с реальностью, и это стоит найти. Второй: в него заходят не в день разбора. Если пики посещений приходятся строго на четверг перед планёркой, значит, им пользуются как подготовкой к отчёту, а не как рабочим инструментом. Ровный поток заходов среди недели — признак, что он встроился в работу. Третий: вас перестали спрашивать цифры. Самый приятный признак. Если раньше вопрос «а сколько у нас сейчас в пайплайне» прилетал вам, а теперь человек смотрит сам, — дашборд занял своё место. И заодно вернул вам изрядный кусок времени, который раньше уходил на пересказ данных. Промпт: ревизия дашборда Ревизию можно провести самому, но чужой взгляд полезен тем, что не жалеет блоки, на которые потрачена работа. Опишите машине состав экрана и попросите быть безжалостной — а потом решайте сами, потому что она не знает вашего контекста. Навык, который тренируется Проверять любой экран вопросом «какое действие отсюда следует» — навык, который экономит месяцы разработки. Он работает не только на дашбордах: на отчётах, на письмах, на презентациях для команды. Везде одинаково: если из увиденного не следует действие, человек это не запомнит и не применит. Дашборд — самый дорогой способ узнать эту истину, потому что его сначала разрабатывают, потом наполняют, потом презентуют, и только потом обнаруживают, что заходов ноль. Мы прошли этот путь целиком, и я до сих пор считаю те две недели самыми полезными в истории проекта. Все компании сейчас на одной беговой дорожке, и данных на ней у всех примерно поровну. Обгоняют не те, у кого больше графиков. Обгоняют те, у кого от увиденной проблемы до звонка ответственному проходит двадцать секунд, а не пять минут и одно отвлечение. Проверьте сегодня свой дашборд этим вопросом — пройдите по блокам и назовите действие для каждого. Выпишите те, где действия нет, и уберите их на следующей неделе. Экран станет беднее и полезнее. ## Автоматизация бизнес-процессов: первым берут не тот процесс, где болит, а тот, с которым вы встанете URL: https://davidgerstein.pro/blog/kak-vybrat-pervyy-process-dlya-avtomatizacii/ Дата: 2026-08-31 Направление: Операционное управление Цифры: 4 вопроса теста, 6 недель на первый результат, 4-й месяц настройки у неправильного кандидата Цифры в разборе пересчитаны на условную компанию — механика, сроки и выводы реальные. Вы уже решили, что автоматизация бизнес-процессов вам нужна. Список процессов лежит перед вами, в нём 15 строк, и все пятнадцать выглядят достойными. Коммерческий директор тянет на продажи — там деньги. Операционный на документооборот — там боль. Вы смотрите на оба и понимаете, что 3 месяца можно потратить не туда, а второго захода команда вам не простит. Если вы выбираете первый процесс по тому, где сильнее болит, — вы почти наверняка выберете тот, который вас и похоронит. Я потратил на эту ошибку 2 года. Не 3 месяца — 2 года. Самой заметной болью у меня была расшифровка и оценка звонков: сотни разговоров в месяц, руководитель слушает выборочно 10–15, остальное — чёрный ящик. Я подступался к этой задаче снова и снова, потому что она болела громче всех. А взлетел совсем другой процесс — тот, о котором я вообще не думал как о приоритетном. С чего начинать автоматизацию бизнес-процессов Автоматизация бизнес-процессов начинается с того процесса, где машина ошибается дёшево, а не с того, где сильнее болит. Самый болезненный процесс сложен именно потому, что в нём много исключений: контур оценки звонков с 10 сценариями идёт 4-й месяц , а простой процесс с одним набором правил заработал за 6 недель . Тест из 4 вопросов: что будет, если машина ошибётся в 1 случае из 20; опишут ли процесс 2 исполнителя одинаково; виден ли результат за пределами отдела; есть ли конкретный хозяин. Проходить должны все четыре. Почему самый больной процесс — худший кандидат Он больной не случайно. Он больной потому, что сложный. В нём много исключений, много участников и много несогласованности, накопившейся годами. Именно поэтому его до сих пор никто не починил руками. Возьмите наш контроль качества звонков — тот самый, к которому я шёл 2 года. Он сейчас работает: разговоры выгружаются, расшифровываются, классифицируются по типу, оцениваются по чек-листу, результат попадает в кабинет руководителя. Красиво. А теперь честная сторона. Типов разговора оказалось не 2 и не 3 — понадобилось 10 разных чек-листов под разные сценарии. Настройка идёт четвёртый месяц и всё ещё требует доработок. Отдельная история — сама машина: на одном и том же разговоре 5 прогонов подряд дают 5 слегка разных оценок. Это не поломка, это свойство языковых моделей, и с ним приходится проектировать: усреднять, огрублять шкалу, держать человека на калибровке. Всё это — нормальная цена за хороший процесс. Но представьте, что это ваш первый проект. 4-й месяц, 10 чек-листов, оценки пляшут, а команда стоит рядом и делает выводы про всю затею целиком. Сроки при этом множатся, а не складываются — разобрал арифметику отдельно . Первый процесс отвечает не за экономию. Он отвечает за то, поверит ли вам компания на втором. Как выглядит полный маршрут от решения до эксплуатации — разобрал отдельно — маршрут на два-три месяца и три развилки, на которых всё ломается . Что взлетело вместо него Заработал скучный процесс, за который никто не голосовал. Менеджер по найму каждый день руками просматривала отклики на вакансии: заходила на портал, открывала резюме, фильтровала по критериям, вела учёт в голове и блокноте. Сделали так: агент раз в сутки сам ходит в портал через интеграцию, забирает новые отклики, раскладывает в таблицу — просмотры, клики, отказы, статус каждого резюме по критериям. Решения по кандидатам остались за человеком. Машина не выбирает людей — она приносит разложенное. 6 недель от разговора до работающего: 2 недели на описание правил отбора, 3 на сборку и проверку, 1 на приёмку. И главное — понятный результат, который видно снаружи: таблица есть, она пополняется сама, менеджер утром открывает её вместо 10 вкладок. Разница между двумя процессами не в технологии. Она в цене ошибки. Если агент неверно разметил 1 отклик из 20 — менеджер это увидит и поправит за 10 секунд. Если машина неверно оценила разговор менеджера, а вы на этой оценке строите разговор о премии, — вы разрушаете доверие к системе и к себе. Два процесса рядом: почему один взлетел, а другой идёт 4-й месяц Параметр Оценка звонков (шёл первым в моей голове) Мониторинг откликов (взлетел на самом деле) Срок до работающего результата 4 месяца и продолжается 6 недель Вариантов обработки 10 чек-листов под разные сценарии 1 набор критериев Цена одной ошибки машины Разговор о премии на кривой оценке Менеджер поправит за 10 секунд Разброс на повторных прогонах 5 прогонов — 5 разных оценок Разметка стабильна, спорное видно глазом Виден ли результат снаружи Только руководителю отдела Таблица, которую открывают каждое утро Кто хозяин Спорили 2 месяца Назначен в первый день Годится первым? Нет Да Обратите внимание: по величине боли первый выигрывает с разгромным счётом. По пригодности для старта — проигрывает по всем шести строкам. Как раскладываются 15 процессов из типового списка Когда мы прогоняли через тест списки процессов у себя и на разборах, картина получалась примерно одинаковая — и она объясняет, почему автоматизация бизнес-процессов так часто буксует на первом же проекте: выбор наугад почти всегда мимо. Годятся первыми — 20% Годятся, но не первыми — 47% Не годятся вообще: нет регламента или хозяина — 33% То есть из 15 строк вашего списка стартовых кандидатов — 3, максимум 4. Вероятность попасть в них вслепую — 1 к 5. Именно поэтому 20 минут на тест дешевле 3 месяцев на угадывание. Критерий, который стоит выше экономии Спросите не «сколько сэкономим», а «что будет, если она ошибётся в 1 случае из 20». Ответ «ничего страшного, человек поправит» — берём в первые. Ответ «клиент уйдёт, попадём на деньги, поссоримся с командой» — берём, но не первым. Тест из четырёх вопросов Выпишите 3 кандидата и прогоните каждого. Проходить нужно все 4 — 3 из 4 не считается. 1. Дёшево ли она ошибается? Разобрали выше. Добавлю одно: сюда же попадают процессы, где на один и тот же вход нужен строго один и тот же ответ. Машина по своей природе даёт разброс. Там, где разброс недопустим — расчёты, суммы, юридические формулировки, — либо не первый процесс, либо машина готовит, а решает человек. 2. Опишут ли его два исполнителя одинаково? Возьмите 2 человек, кто делает эту работу, и попросите порознь расписать шаги. Не вместе — порознь. Если описания разошлись — остановитесь. Вы автоматизируете не работу, а спор о работе, и машина зафиксирует в коде победу того, кто громче. Если разошлись — поздравляю, вы нашли не задачу для ИИ, а дыру в управлении , которая жила у вас и без всякого ИИ. Сначала регламент, потом машина: описать процесс до одной версии и найти в нём узкое место нужно раньше, чем что-то автоматизировать. Регламент, кстати, теперь пишется за вечер — с той же машиной, по расшифровке разговора с обоими исполнителями. Этому я учу отдельно, в курсе есть модуль ровно про это . 3. Виден ли результат снаружи? Результат должен быть заметен человеку за пределами отдела, без объяснений и презентаций. Таблица, которая пополняется сама. Отчёт, который приходит в 8 утра. Папка, где документы разложены. Внутренние улучшения — «стало удобнее», «меньше ручной работы» — не годятся для первого проекта. Не потому что они хуже, а потому что первый проект вы защищаете перед компанией, и защищать придётся тем, что видно. 4. Есть ли у него хозяин? Не исполнитель — хозяин. Человек, у которого спросят, когда сломается, и который считает этот процесс своим. Самый дорогой мой провал в этом году не имел отношения к технологиям. Рассылка встала на 4 недели. Разбирались — оказалось, менеджер не знала, что техническая часть вообще не её зона: она думала, что должна разобраться сама, не разобралась и молчала. Задача не сломалась. Она просто была ничья. Это самая частая причина, по которой проекты глохнут, — собрал их в разборе «Почему внедрение ИИ не работает» . Похожая история с дашбордом: собрали, запустили, красиво. Через 2 недели выяснилось, что в него никто не заходит, — потому что не назвали, кто по нему принимает решения. Три возражения, которые вы услышите от команды Как только вы назовёте выбранный процесс, начнётся торг. Он предсказуем, и лучше знать ответы заранее — иначе выбор поплывёт обратно к самому больному. «Это же мелочь, зачем на неё тратить силы» Скажет тот, кто голосовал за большой процесс. Ответ короткий: первый проект покупается не эффектом, а доверием. У вас в компании сейчас нет ни одного человека, кто своими глазами видел, что это работает. После первого — будет отдел. После второго — половина компании перестанет спорить и начнёт приносить свои задачи. Это и есть настоящая экономия первого проекта, и она не считается в часах. «Давайте сразу сделаем нормально, на весь объём» Самое опасное возражение, потому что звучит по-взрослому. Мы на этом обожглись: пытались вести разработку и внедрение одновременно — и остановились. Развернули иначе: сперва 40 случаев с ручной проверкой людьми, потом контролируемый сегмент, потом весь объём. Каждый шаг показывает, где машина врёт, пока цена ошибки ещё копеечная. На полном объёме та же ошибка стоит доверия ко всей системе. «У нас процесс сложный, у нас так не получится» Обычно это говорит человек, который боится, что автоматизация покажет, как процесс устроен на самом деле. И тут я на его стороне: она действительно покажет. Поэтому первый проект не должен быть местом, где кому-то станет неуютно. Берите процесс, где сотрудник получает не контроль, а разгрузку, — как менеджер по найму, которая перестала открывать 10 вкладок. Тогда он ваш союзник, а не саботажник. Если ни один кандидат не прошёл Значит, у вас нет процесса для старта — есть 3 слишком крупных. Дробите. Мы так и делали, когда упирались: сначала обучали на 40 случаях с ручной проверкой людьми, потом выпускали на контролируемый сегмент в 5 000, и только потом на весь объём. Скучно, зато на каждом шаге видно, где машина врёт, — и видно это на 40 случаях, а не на 5 000. Возьмите самый крупный процесс и отрежьте от него один слой: не «автоматизировать документооборот», а «собирать входящие документы в одну папку с разметкой типа». Этот кусок пройдёт тест. И сразу закладывайте в него три свойства из разбора «Автоматизация, которая требует надзора» — иначе получите процесс, за которым надо следить. Промпт: прогнать кандидатов через тест за один заход Тест можно пройти в голове, но в голове вы будете жалеть выбранный процесс. Машина не жалеет. Я отдаю ей описание кандидатов и прошу оценить по четырём критериям — на выходе получаю ранжирование и, что важнее, список того, чего я про процесс не знаю. Описание каждого кандидата — 5–7 строк своими словами: кто делает, как часто, что на входе, что на выходе, что бывает, когда ошибаются. Ответы модели проверяйте: она уверенно рассуждает о процессах, которых не видела, и это нормально — вам нужен не вердикт, а вопросы, которые она задаст. Отдельно попросите модель проверить пункт 2 жёстко: пусть найдёт в вашем описании места, где возможны два толкования. Обычно их два-три, и это ровно те места, где два ваших исполнителя разойдутся. Навык, которого у большинства нет Оценивать процесс по цене машинной ошибки — такой же базовый навык руководителя, как оценивать проект по сроку окупаемости. Пока вы его не освоили, вы выбираете вслепую: берёте то, что громче болит, и удивляетесь, почему через 6 месяцев тема закрыта фразой «мы пробовали». Первый процесс — это не самая тяжёлая штанга в зале. Это та, с которой вы точно встанете. Встать надо не один раз: первый проект оплачивает второй доверием, второй третий — деньгами. Все компании сейчас стоят на одной беговой дорожке, и разница между теми, кто побежит, и теми, кто останется, начинается с того, встали вы в первый раз или нет. Сядьте сегодня и выпишите 3 кандидата. Прогоните через 4 вопроса. Тот, что прошёл, — ваш. На это уйдёт 20 минут, а сэкономит 3 месяца. ## Показатели отдела продаж: не «сколько», а «где просело» URL: https://davidgerstein.pro/blog/kakie-otchety-nuzhny-rukovoditelyu/ Дата: 2026-08-31 Направление: Финансы Цифры: 4 перехода вместо 1 итога, конверсия 14% при плане 23%, средний чек +35% к плану на фоне провала Суммы пересчитаны на условную компанию — пропорции, механика и выводы реальные. Какие показатели отдела продаж смотреть в недельном отчёте Если у вас в недельном отчёте стоят выручка и число сделок — вы смотрите на результат, а не на управляемые показатели отдела продаж. Смотреть надо шесть строк: четыре перехода — лид → квалификация → встреча → договор → оплата — плюс средний чек и нагрузку на менеджера. Решение принимается по тому переходу, который просел сильнее всего относительно плана. В разобранной неделе итог был 80 000 € при плане 100 000 , и он не показывал главного: поток лидов был в порядке, конверсия во встречу 55% , а рассыпалось всё на закрытии — из встреч в договор дошли 22% . Некролог вместо сводки Вы открываете недельный отчёт. Там выручка, может быть, число сделок, может быть, сравнение с планом — и ни одного показателя, на который можно повлиять. Вы смотрите на цифру, она вам либо нравится, либо нет, и на этом всё заканчивается — потому что делать с ней нечего. Если ваш недельный отчёт отвечает на вопрос «сколько», а не «где именно просело», — вы читаете некролог, а не сводку. Я годами смотрел на итог недели и был уверен, что управляю. Управлял я тем, что уже произошло: выручка этой недели — следствие решений, принятых недели и месяцы назад. Повлиять на неё в момент чтения отчёта невозможно физически. Разбор одной недели Вот реальная неделя, разложенная так, как я считаю правильным. Сначала — то, что видно в обычном отчёте. Сделано 80 000 € при плане 100 000. Недобор 20 000. Закрыто 7 сделок из 16 запланированных. Всё. На этом обычный отчёт заканчивается, и дальше на планёрке начинается разговор про «надо поднажать» и «где лиды». Теперь то же самое в разложении. Переход Факт План Что это значит Лид → встреча 55% (49 встреч) Норма Поток в порядке, назначаем хорошо Встреча → договор 22% Существенно выше Здесь провал Общая конверсия в продажу 14% 23% Следствие предыдущей строки Средний чек 13,5% 10% Перевыполнение Итог 80 000 € 100 000 € Результат, а не причина Разница между двумя способами смотреть — это разница между «мы недоработали 20 тысяч» и «мы провели 49 встреч и не смогли закрыть четыре пятых из них». Первая формулировка ведёт к требованию больше лидов. Вторая — к разбору того, что происходит на встречах: как проходит презентация, отрабатываются ли возражения, о чём вообще говорят менеджеры. Лиды тут ни при чём, их достаточно. Как отличить реальное зависание от нормального хода сделки — в разборе ошибок воронки : там сделка провисела 540 дней и всё это время считалась живой. Правило чтения Ищите не самое низкое число, а самое большое отклонение от нормы для этого этапа. Конверсия 22% может быть отличной в одном бизнесе и катастрофой в другом — сравнивать надо с вашим же нормативом, а не с чужими эталонами. Хороший показатель, который усыпляет Обратите внимание на строку про средний чек: 13,5% при плане 10% . Перевыполнение на треть. В отчёте, где показатели идут списком, эта строка выглядит успехом и уравновешивает плохие. На планёрке кто-нибудь обязательно скажет: «зато чек вырос». И разговор поедет в сторону от проблемы. А на деле высокий чек при провальной конверсии часто означает противоположное: менеджеры закрывают только крупных клиентов, с которыми проще, а средних и мелких упускают. То есть хороший показатель здесь — симптом той же болезни , а не компенсация. Отсюда правило: показатели нельзя читать по отдельности. Средний чек имеет смысл только рядом с конверсией, конверсия — только рядом с потоком, поток — только рядом с нагрузкой на менеджера. Разложение на переходы как раз и заставляет смотреть на них вместе. Сюжет про количество людей Отдельная история, которая перевернула моё представление о том, что показывать в отчёте. У нас в отделе было три менеджера , включая руководителя. Продажи шли стабильно. Отдел расширили до шести-семи человек — и продажи стали хуже. Не в пересчёте на человека, а в абсолюте. Разбирались долго. Причина оказалась не в людях и не в мотивации: избыток лидов уронил качество работы с каждым . Когда лидов больше, чем можно нормально отработать, менеджер начинает снимать сливки и бросать всё, что требует усилий. Три человека вцеплялись в каждого клиента, семь — перебирали. После того как поставили контроль качества работы с лидами, конверсия начала расти на 1 процентный пункт в месяц . Медленно, зато устойчиво. Отдельно про то, как не превратить разбор отклонений в поиск виноватых, — план-факт без вранья . Это ровно та развилка, на которой недельный отчёт либо становится рабочим инструментом, либо превращается в еженедельную порку. Вывод для отчёта: метрика «лидов на менеджера» важнее метрики «лидов» . Первая управляемая, вторая — просто цифра, которой принято хвастаться. Мы добавили её в недельную сводку и сразу увидели периоды, когда отдел физически не мог отработать входящий поток. Итоговая выручка — 20% управленческой ценности Переходы между этапами — 55% Нагрузка и контекст — 25% Какие показатели отдела продаж вывести в отчёт Показатели отдела продаж, которые я держу в недельной сводке, — это шесть строк, больше не нужно. Избыток показателей возвращает вас к чтению таблиц вместо принятия решений — а мы от этого и уходим. Четыре перехода: лид → квалифицированный лид, квалифицированный → встреча, встреча → договор, договор → оплата. Каждый в процентах и с нормативом рядом. Средний чек — контекст к конверсии, читается только вместе с ней. Нагрузка на менеджера — лидов в работе на человека. Показывает, когда поток перестал быть ресурсом и стал проблемой. Итоговая выручка тоже присутствует, но не как главная цифра — как справка. Она вверху страницы, а разговор идёт по переходам. День недели важнее содержания Скажу вещь, которая звучит мелко и решает больше, чем состав показателей: у отчёта должен быть свой день недели. Мы закрепили коммерческий разбор за четвергом . До этого он существовал в режиме «когда соберём данные», а это означает — регулярно не собирался вовсе: то данные не готовы, то у всех дела, то неделя короткая. Фиксированный день превращает отчёт из события в процесс. К нему готовятся, под него подтягивают данные, о нём помнят без напоминаний. Побочный эффект: результаты накапливаются в единой таблице по неделям, и через пару месяцев становится видно то, что в одной неделе не разглядеть — например, что конверсия проседает не вообще, а конкретно в отсутствие определённого человека. Сборку отдайте машине, чтение оставьте себе У нас аналитик вручную заполняла ежедневный отчёт — основной показатель, средний чек, конверсия — примерно 30 минут в день . Это два с половиной часа в неделю на копирование цифр из одной системы в другую. Сборку такого отчёта машина делает целиком: тянет из CRM, считает переходы, подставляет нормативы, красит отклонения. Освобождённое время уходит на то, ради чего отчёт и нужен, — на разбор причин. Сколько это стоит и за какой срок собирается, считал отдельно : типовой контур такого рода — две-три недели работы. Чего машине отдавать не надо — так это объяснение отклонений. Модель уверенно придумает причину любого падения, и звучать это будет складно. Проверять её версии всё равно вам, поэтому проще сразу смотреть самому. Как разграничить зоны — в руководстве по управленческой отчётности . Три ошибки в недельных отчётах, которые я видел чаще всего Показатели без норматива Конверсия 22% — это много или мало? Без вашего собственного норматива ответа нет, и планёрка превращается в обмен мнениями. Норматив не обязан быть научным: возьмите лучший месяц за год и считайте его ориентиром, пока не наберёте статистику. Главное, чтобы он был записан и не менялся задним числом под результат. Сравнение с прошлой неделей вместо плана Соблазнительно и почти всегда вредно. Прошлая неделя могла быть провальной, и рост к ней — не достижение. Ещё хуже с сезонностью: сравнение соседних недель в период спада показывает падение там, где всё идёт по норме. Сравнивайте с планом и с той же неделей прошлого года, а недельную динамику держите как справку. Отчёт, который читает один человек Если раскладку видите только вы, менеджеры продолжают работать с итоговой цифрой в голове. Переходы должны быть видны тем, кто на них влияет: конверсия из встречи в договор — забота менеджера, а не ваша. Мы дошли до этого через дашборд , где руководители смотрят своё подразделение сами, вместо того чтобы получать выжимку сверху. Что делать с найденным провалом Разложение показывает место, но не причину. Дальше работает простая последовательность, и она короче, чем кажется. Первое: посмотрите руками десять случаев. Не отчёт, а сами сделки, которые не дошли до договора. В нашем случае это означало послушать разговоры со встреч. Десяти хватает, чтобы увидеть закономерность, а если закономерности нет — это тоже ответ: значит, дело не в этапе, а в потоке. Второе: сформулируйте гипотезу проверяемо. «Низкая мотивация» — не гипотеза, её нельзя проверить за день. «Менеджеры не выясняют бюджет до презентации» — гипотеза: берём десять записей, считаем, в скольких прозвучал вопрос про бюджет. Третье: правьте один этап за раз. Если чинить одновременно вход и закрытие, через месяц вы не поймёте, что сработало. Скучно, зато к третьему месяцу у вас появляется знание, а не набор одновременных изменений. Именно так конверсия у нас и росла — на процентный пункт в месяц. Не рывком: рывки в этих цифрах обычно означают, что поменялся способ подсчёта, а не работа. Промпт: разложить неделю на переходы Если у вас нет автоматической сборки, разложение можно сделать руками за пятнадцать минут — или отдать машине выгрузку и получить готовую раскладку с гипотезами. Гипотезы проверяйте, они бывают убедительно неверными. Как это выглядит через полгода Стоит сказать, ради чего вся эта дисциплина, — потому что первые недели она ощущается как лишняя работа. Через два-три месяца еженедельных разборов у вас накапливается ряд по каждому переходу. И вот тут появляется то, чего не даёт ни одна отдельная неделя: вы начинаете видеть не события, а тенденции . Конверсия во встречу держится, а из встречи в договор медленно ползёт вниз третий месяц подряд — в отдельной неделе это тонет в шуме, в ряду видно сразу. Второе, что появляется, — способность отличать случайность от проблемы. Одна плохая неделя ничего не значит: у нас были недели, где всё просело из-за праздников и одного заболевшего менеджера. В ряду такие провалы видны как выбросы, а не как повод устраивать разбор полётов. Это, кстати, снимает изрядную часть нервотрёпки: перестаёшь реагировать на каждое колебание. Третье — самое ценное для планирования. Зная свои переходы, вы можете считать назад: чтобы получить нужную выручку при вашей конверсии, требуется столько-то встреч, а для них — столько-то лидов. План перестаёт быть цифрой, спущенной сверху, и становится расчётом, который команда может проверить. Спорить с расчётом гораздо сложнее, чем с желанием собственника. И последнее наблюдение, неприятное. Когда переходы становятся видны всем, часть проблем решается сама — просто потому, что человек видит свою цифру рядом с нормативом. Неприятно тут то, что до этого он её не видел годами, и вы считали, что он в курсе. Навык, который тренируется Раскладывать результат на переходы — базовый навык чтения любой воронки: продаж, найма, производства, обучения. Везде одна механика: итог неуправляем, управляемы переходы между состояниями. Проверка на себе за минуту. Возьмите последний недельный результат и ответьте: какой конкретно переход просел сильнее всего? Если вы можете назвать только итоговую цифру — отчёт у вас есть, управления по нему нет. Все компании сейчас на одной беговой дорожке. Обгоняют не те, кто быстрее реагирует на плохую выручку, — на неё реагировать поздно. Обгоняют те, кто в понедельник видит просевший переход и правит его, пока он не превратился в выручку следующего месяца. Выпишите сегодня четыре перехода последней недели — на листе бумаги, без всякой автоматизации. Посчитайте проценты, поставьте рядом свой норматив и назовите вслух тот переход, где отклонение самое большое. Пятнадцать минут, и вы либо подтвердите то, что думали, либо обнаружите, что чинили не то место. ## Специалист по внедрению ИИ: не ИТ-директор, не энтузиаст и не вы URL: https://davidgerstein.pro/blog/kto-dolzhen-vesti-vnedrenie-ii/ Дата: 2026-08-31 Направление: Операционное управление Цифры: −25,5 п.п. разрыв на единственной калибровке, 3 неделегируемые обязанности, 400 000 автоответов без дверей Цифры пересчитаны на условную компанию — механика, сроки и выводы реальные. Контур собран. Процесс выбран правильно, подрядчик отработал, на демонстрации всё красиво. Остаётся мелочь — назначить внутри человека, который это поведёт. Вы перебираете: ИТ-директор? операционный? тот аналитик, который сам притащил вам нейросети и горит темой? И где-то на третьем круге ловите себя на мысли, что проще вести самому. Если на вопрос «кто у вас отвечает за это внедрение» вы называете должность, а не имя, — внедрения нет. Есть проект, который какое-то время будет выглядеть живым. У машины нет начальника по умолчанию. Пока вы не назначили человека, она работает на никого — и это состояние держится месяцами, потому что снаружи выглядит нормально: сервер жужжит, данные копятся, отчёты формируются. Кто такой специалист по внедрению ИИ Специалист по внедрению ИИ — это не вакансия на рынке, а роль внутри: владелец процесса, которому результат машины нужен для его собственных решений. Не ИТ-директор: он запустит контур, но не сможет судить о качестве результата, потому что не он читает эти документы и не он разговаривает с клиентами. Цена отсутствия хозяина измерима: сверку машины с людьми провели один раз , разрыв составил −25,5 п.п. , повторного замера не было. Два месяца никто не мог сказать, можно ли верить оценкам. Цифра, которая объясняет всё У нас работает контур оценки разговоров. Машина слушает поток и ставит оценки по чек-листу. Чтобы этим можно было пользоваться, машину надо сверять с людьми: берём выборку, оцениваем руками, смотрим расхождение. Такую сверку у нас провели 1 раз . 25 июня. Разрыв составил −25,5 процентных пункта : машина оказалась систематически строже людей. Вывод записали, правки в промпт наметили. Повторный замер не зафиксирован. Ни через месяц, ни через два. Дальше самое интересное. К концу августа разрыв сжался до −5,5 п.п. — то есть система пришла в норму сама, по ходу правок. И этого тоже никто не измерял. Мы узнали цифру только когда специально полезли проверять, что там происходит. Два месяца процесс жил вслепую. Не сломанный — просто без хозяина. Никто не мог сказать, можно ли верить оценкам сегодня: те, кто их читал, не знали про разрыв, а тот, кто знал про разрыв, не смотрел на оценки. Это тот же механизм, из-за которого внедрения не работают при исправной технике. Что тут важно Контур не упал и не выдал чушь. Он работал. Отсутствие хозяина проявляется не в поломке, а в том, что никто не может ответить на вопрос «этим сейчас можно пользоваться?». И пока ответа нет, результатами не пользуются — тихо, без объявления войны. Почему ИТ-директор — худший из очевидных вариантов Он кажется правильным ответом: технология же. И он действительно запустит. Проблема начинается на следующий день после запуска. Судить о качестве машинного результата может только тот, кто делал эту работу руками. ИТ-директор не читает ваши договоры, не слушает разговоры с клиентами, не разбирает отклики кандидатов. Он видит, что процесс отработал без ошибок. Отработал ли он правильно — не его компетенция и не его интерес. Живой пример из нашего периметра. Портал: собрано 400 000 вопросов с автоответами, сделан дизайн, контент готов. Техническая сборка не доведена месяцами. Формулировка, которой это описали на планёрке, лучше любого моего объяснения: «красивый дом, но дверей нету» . Все компоненты на месте, ответственный есть, а войти нельзя. Второй случай — мельче и потому показательнее. Автоматизация заполняла общую таблицу и затирала строки, которые сотрудники добавляли руками. Человек прямо сказал: я вношу строчку, а оно мне всё обновляет. Проблему обсудили, зафиксировали. Ответственного за исправление и срок не назначили. Она продолжила жить — и продолжала бы сколько угодно, потому что для существования проблемы хозяин не нужен, он нужен для её закрытия. Кого назначить специалистом по внедрению ИИ Владелец процесса. Руководитель, которому результат машины нужен для его собственных решений: начальник отдела продаж, если контур оценивает разговоры; операционный, если разбираются документы; тот, кто нанимает, если речь про отклики. Как выбрать сам процесс — разобрал отдельно ; здесь речь о том, кто его поведёт. Критерий простой: если машина начнёт врать, этот человек пострадает первым. Тогда у него есть личный мотив ловить враньё. У ИТ-директора такого мотива нет, у энтузиаста-аналитика — нет, у подрядчика — тем более нет. Кандидат Что сделает хорошо Где развалится Годится? ИТ-директор Запустит, подключит, обеспечит стабильность Не оценит качество результата — не его работа и не его боль Как исполнитель, не как ведущий Энтузиаст, который принёс ИИ Соберёт быстро и дёшево, будет гореть Ему интересна сборка, а не эксплуатация: через 2 месяца уйдёт в новую игрушку Нет Подрядчик Сделает контур и поддержит технически Не может принимать решения и отключать старый способ — это внутренняя власть Нет Собственник Продавит любое решение Не хватит времени на калибровку; станет узким местом, не заметив этого Только на 1-м процессе Владелец процесса Судит о качестве, принимает работу, отключает старое Нужны 2–4 часа в неделю и прикрытие от текучки Да Три обязанности, которые нельзя делегировать Всё остальное — сборку, поддержку, доработки, мониторинг — отдавайте кому угодно. Эти три остаются на человеке с именем. 1. Приёмка по понятному правилу Не «посмотрел, вроде нормально», а заранее записанное правило: что считается годным результатом. Без правила приёмка превращается в настроение, а настроение меняется, и подрядчик перестаёт понимать, что от него хотят. 2. Калибровка по расписанию Та самая сверка машины с людьми. Раз в месяц на старте, раз в квартал потом. Выборка, ручная оценка, сравнение, запись цифры. Двадцать минут работы, которые никто не делает, потому что они не горят. Именно эти сверки и определяют срок проекта — не сборка контура. Арифметика в разборе сроков: две-три недели до первого результата и два-три месяца до устойчивой пользы . Именно тут теряется больше всего. Наш разрыв в 25,5 пункта был известной величиной — про него знали, его записали. Не было человека, чья обязанность — замерить его снова через месяц. 3. Решение об отключении старого способа Самое политически тяжёлое. Пока живут обе схемы, команда работает по привычной, а компания платит за две. Отключить может только тот, у кого есть на это власть внутри отдела. Подрядчик не может, ИТ не может, вы — можете, но вас не будет рядом в нужный момент. Полный маршрут внедрения по неделям — с какого процесса начинать и когда отключать старый способ работы . Сборка контура — 15% усилий Приёмка и правила — 25% Калибровка и разбор расхождений — 35% Отключение старого и работа с людьми — 25% Так распределяются усилия на нашем контуре по факту первых месяцев. Обратите внимание на пропорцию: то, за что все переживают — сборка, — занимает седьмую часть. Остальное делает человек внутри, и подрядчик за него это не сделает ни за какие деньги. Теперь неприятная часть — про вас У нас проект по интеграции встал на месяцы. Причина не техническая: не могли назначить руководителя. Обсуждали, возвращались, снова обсуждали. Собственник понимал, что тратит собственное время на то, что должен решать не он, и всё равно не отпускал — опасался потерять контроль . Сроки горели, решение не принималось. Я видел эту схему у нескольких компаний и назову её прямо: вы не назначаете человека не потому, что некого. Вы не назначаете, потому что не готовы отдать контроль. Пока это не признано вслух, проект стоит, а вы уверены, что он идёт — потому что вы им регулярно занимаетесь. Проверка на себе занимает минуту. Ответьте: если вы уедете на 3 недели без связи, кто примет работу машины и кто заметит, что она поехала? Если ответ «никто» или «подождут до моего возвращения» — ведущего нет, есть вы в роли узкого места. Признак перегруза, который я слышал дословно: «я прям теряюсь от количества задач». Так звучит не лень и не слабость — так звучит отсутствие делегирования, доведённое до предела. Лечится оно назначением имени, а не удвоением собственных часов. Что делать с сопротивлением сотрудника Здесь я обязан сказать про свою ошибку. Долгое время я разговоры про «я не хочу с этим работать» решал давлением: надо, значит надо, разберёшься. Работало плохо. Перелом случился на одном разговоре. Сотрудница, объективно сильная — сделала анализ экономики, нашла проблемы, построила модели, — говорила о себе «я ничего не делаю». А дальше сформулировала настоящий страх: «боюсь, что мы потеряем живое общение, люди и жизненность — это главное» . Она боялась не машины. Она боялась перестать быть нужной и потерять то, за что любит свою работу. На это давление не действует — действует только конкретика: что именно останется за ней, что заберёт машина, и почему первое важнее второго. Плюс поддержка расписанием, а не лозунгом: короткая сессия на следующий день, потом чек-лист на неделю вперёд. Правильная раскладка ролей снимает половину страха сама. В нашем HR-контуре агент собирает отклики и раскладывает по критериям, а решения по кандидатам остаются за менеджером . Человек не потерял работу — он потерял её худшую часть. Это надо проговаривать вслух до запуска, а не после. Когда специалист по внедрению ИИ становится отдельной должностью Частый вопрос: не пора ли завести человека, который занимается только этим. Отвечаю по опыту: на первых двух-трёх контурах — нет. Это доп. нагрузка на владельца процесса, 2–4 часа в неделю, и её надо честно снять с него в другом месте, а не добавить сверху. Отдельная роль появляется, когда сходятся два признака. Первый: контуров больше пяти, и калибровка перестаёт помещаться в чужой календарь — она всегда проигрывает горящим задачам, потому что не горит сама. Второй: между контурами появляются связи, и кто-то должен держать картину целиком. У нас такой момент наступил на перегрузе, а не по плану. Формулировка была прямая — задач столько, что руководитель теряется в их количестве и раздаёт без внятного приоритета. Решением стало не «нанять ещё маркетолога», а вывести отдельного человека, который держит процессы и разгружает первое лицо. Это дорого, и на месте собственника я бы дотерпел до пятого контура — но дотерпеть надо осознанно, а не выяснить постфактум, что полгода всё стояло. И маленькое предупреждение про красивое название. Вакансия «специалист по внедрению ИИ» притягивает кандидатов, которые умеют рассказывать про ИИ. Вам нужен не рассказчик, а человек, который в состоянии сказать «эта оценка неверна, вот почему» — то есть знающий вашу работу изнутри. Такого проще вырастить, чем нанять. Как понять через месяц, что вы назначили правильно Три проверки, каждая занимает минуту. Первая. Спросите этого человека, какая сейчас цифра расхождения между машиной и людьми. Если он назовёт число и дату замера — роль работает. Если ответит «в целом нормально» — не работает, вы назначили номинально. Вторая. Посмотрите, к кому команда идёт с вопросами про контур. Если к подрядчику или к вам — ведущего не признали. Признание роли видно по маршруту вопросов, а не по приказу. Третья. Спросите, что уже отключено из старого способа. Ответ «ничего, пока параллельно» на втором месяце — тревожный: значит, человек боится принять решение, и надо разбираться, не хватает ему полномочий или уверенности. Второе лечится вашим публичным «я его поддержу», первое — вашим приказом. Промпт: собрать паспорт роли за один заход Самая частая отговорка — «не знаю, что именно ему поручить». Это решается за 15 минут: опишите процесс и попросите машину развести зоны. Ответ проверяйте — она склонна раздувать роль до отдельной должности, а вам нужны 2–4 часа в неделю на живом руководителе. Навык, которого нет ни в одной должностной инструкции Принимать работу машины — отдельный управленческий навык. Он не совпадает ни с одной существующей ролью: это не про технологии, не про аналитику и не про управление людьми. Это умение сказать, годится ли результат, по правилу, а не по ощущению, и поймать момент, когда машина начала врать. На рынке его не купить — нет ни специальности, ни диплома. Значит, придётся вырастить внутри, на первом же процессе, из человека, который у вас уже работает. Я на это трачу вечера с руководителями и собрал методику в курс , потому что объяснять одно и то же по десять раз оказалось дороже, чем один раз записать. Компании на беговой дорожке отличаются не моделями — модели у всех одинаковые. Отличаются тем, есть ли внутри человек, который умеет судить о работе машины. У кого он есть, тот прибавляет каждый месяц. У кого нет, у того контуры работают на никого, как наш разрыв в 25,5 пункта, о котором два месяца никто не знал. Назовите имя сегодня. Вслух, при команде, с тремя строками: что принимает, как часто сверяет, когда отключаем старое. Это разговор на 20 минут, и он определяет, будет у вас через полгода работающий контур или красивый дом без дверей. ## Финансовая модель, которой никто не пользуется: типичные причины провала URL: https://davidgerstein.pro/blog/pochemu-finmodel-ne-rabotaet/ Дата: 2026-08-31 Направление: Стратегия Цифры: 2,4× — разрыв плана и факта; 37–40% — доля авансов от суммы договора; 90→7 дней — цикл пересчёта модели Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас план и факт расходятся в разы, а на совете директоров никто не может объяснить, откуда взялась разница, — дело не в ошибке расчёта. В вашей модели живут два разных определения одного слова, и пока вы их не сведёте, любая цифра будет врать. Ниже — четыре типовые ошибки, из-за которых ваша финмодель показывает не то, включая ту, на которой обжёгся я сам. Разбор пригодится, если модель у вас уже есть и она разошлась с реальностью. Если вы только собираете её с нуля или ищете готовый шаблон в Excel — вам в другую сторону, здесь про ремонт, а не про сборку. Почему финансовая модель не работает Потому что под одним словом в ней живут разные базы. В компании на 40 человек годовую цель считали по сумме подписанных договоров — 120 млн ₽, а план отдела продаж — по фактически поступившим авансам, которые составляют 37–40% от суммы договора, — 50 млн ₽. Разрыв в 2,4 раза возник не из арифметики, а из двух определений слова «выручка» на одном слайде. Дальше добавляются ещё три причины: показатели зашиты константами вместо формул, у строк нет владельца, который отвечает за цифру, и допущения никто не перепроверяет. Лечится это в одном порядке: сначала зафиксировать источник каждой цифры, потом перевести показатели на формулы, назначить владельца каждой строки и ввести недельный ритм сверки. Цикл пересчёта модели после этого упал с 90 дней до 7, и расхождение перестало доживать до совета директоров. С чего начался разрыв плана и факта в 2,4 раза Финансовая модель перестаёт работать в первый же месяц, если её строили не от факта платежей, а от желаемой цифры сверху. У нас так и вышло: в стратегии стояла годовая цель 120 млн ₽ выручки, а в план, который отдел продаж реально мог закрыть, заложили 50 млн ₽ — разрыв в 2,4 раза. Никто не мог объяснить, откуда он взялся, пока не разобрались: 120 млн считали по сумме подписанных договоров, а 50 млн — по фактически поступившим авансам, которые обычно составляют 37–40% от суммы договора. Это были две разные модели, которые случайно оказались на одном слайде. Марк смотрит презентацию и задаёт один вопрос: «за счёт SEO или за счёт SMM он даст больше лидов?» Ответа в модели нет — цифры слились в одну обтекаемую формулировку: «рост будет». На встрече выясняется, что SEO-специалист вообще не может назвать источники лидов из органического поиска — аналитика не настроена на связь между запросом, страницей и продажей. Похожий разрыв между лидами и деньгами я разбирал отдельно — там же видно, на каком именно шаге теряются продажи между маркетингом и отделом продаж: лиды есть, а продаж нет . Модель, которая не может ответить на прямой вопрос собственника за час, а не за квартал, для него бесполезна — он и так не читает отчёты длиннее страницы. Во что обошлась путаница между договором и авансом Путаница между двумя базами обошлась не в потерянное на споры время, а в конкретные деньги, потраченные на решения, принятые вслепую. У нас план по найму строился на цифре 120 млн, которую отдел продаж физически не мог закрыть авансами: реальный приток денег держался около 50 млн. Наняли на рост, которого не было ни в деньгах, ни в загрузке. Как это устроено, разобрал отдельно: прогноз продаж, которому можно верить . Чтобы прикинуть цену такой путаницы на своих цифрах, нужны две формулы. Первая — прямые расходы на лишний найм: число лишних сотрудников × зарплата с бонусом × месяцы до обнаружения ошибки = прямые потери на найм . Вторая — управленческое время, потраченное не на решения, а на споры о происхождении цифр: число вовлечённых руководителей × часы в неделю на споры × число недель × ставка часа руководителя = потери управленческого времени . Обе формулы консервативные: если у вас разрыв плана и факта больше 2,4×, оценка вырастет пропорционально. посчитайте на своих цифрах лишних менеджеров зарплата с бонусом, ₽ месяцев до исправления прямые потери на найм ≈ {X} ₽ формула: лишние менеджеры × зарплата с бонусом × месяцы до обнаружения ошибки; оценка консервативная Статья потерь Формула Подставленные цифры (оценка) Итог Лишний найм в отдел продаж число лишних менеджеров × зарплата с бонусом × месяцы до исправления 2 × 150 тыс ₽/мес × 3 мес ≈ 900 тыс ₽ Управленческое время на споры о цифрах число руководителей × часы в неделю × число недель × ставка часа 4 × 2 ч × 4 нед × 1 500 ₽/ч ≈ 48 тыс ₽ Итого около 950 тыс ₽ прямых и косвенных потерь — это цена одной путаницы «договор vs аванс», а не всей модели в целом: дальше будут ещё три ошибки, и каждая добавляет свою часть счёта. Четыре ошибки, которые есть почти у всех Проверьте свою модель по этому списку — на каждой из четырёх я в своё время споткнулся лично. Модель умирает не от одной большой ошибки, а от четырёх типовых: смешение баз, фиксированные цифры вместо формул, отсутствие владельца у каждой строки и слепое доверие тексту, который сгенерировал ИИ. Вот как каждая выглядела у нас. Ошибка Как проявлялась у нас Чем аукнулось Смешение выручки и договоров годовая цель — 120 млн ₽ по сумме подписанных договоров, план — 50 млн ₽ по фактическим авансам (37–40% от договора) разрыв плана и факта в 2,4×, спор на уровне собственника Фиксированные цифры вместо формул план менялся вручную раз в квартал, хотя спрос двигался быстрее из-за внешних факторов — новостей, законодательства отдел показал результат на 40% выше плана, но похвалить не за что: сам план оказался некорректным Нет владельца цифры руководитель направления не мог назвать маржу и конверсию своего участка на встрече решения о найме и бонусах принимались вслепую ИИ-генерация без проверки допущений стратегию для одного из направлений целиком написал ИИ-инструмент — убедительно, но без учёта бонусов продаж в расходах, с необоснованным прогнозом объёма вернулись к ручному пересчёту, часть отведённого на запуск времени потеряна Третья ошибка держится на одной короткой фразе, которую Марк повторяет каждому новому руководителю направления: «Ты должна знать юнит-экономику каждого направления как свои пять пальцев. Сколько зарабатываем, какая маржа, какие точки бизнеса. Это база, база, база. Любой финансовый директор знает всю эту юнит-экономику». Умение назвать экономику своего участка без подготовки — это базовый навык руководителя, такой же обязательный, как умение провести планёрку: сам он не появляется, его ставят повторением на каждой сверке. Если этого не знает никто, кроме финансиста в Excel раз в квартал — модели у направления фактически нет, есть только цифра, которую один раз кто-то куда-то вписал. Отдельный разбор на эту тему: юнит-экономика направления . Пять шагов пересборки, которые выдержали проверку Пройдите их по своей модели — каждый шаг отвечает на конкретный вопрос, который вам зададут на совете директоров. Рабочая модель держится на пяти вещах: явном источнике каждой цифры, формулах вместо констант, назначенном владельце строки, структуре «от общего к частному» и фиксированном ритме сверки. Ниже — порядок, в котором мы это делали, шаг за шагом. Зафиксировать источник каждой цифры. Выручка — это то, что зашло на счёт, а не сумма подписанных договоров. Мы приняли жёсткое правило по образцу решения с продажами: «действуем по факту — если в течение двух дней деньги заходят, это продажа», а не то, что обещано клиенту на встрече. Что → откуда: CRM/платёжный шлюз → поле «оплачено» → лист модели «Факт». Перевести ключевые показатели на формулы. План = факт предыдущего месяца × (1 + темп роста), где темп роста — параметр, а не переписанное вручную число. При отклонении факта модель пересчитывается автоматически, а не переписывается заново каждые три недели. Назначить владельца по каждому направлению. Тот, кто отвечает за строку, обязан знать маржу, средний чек и конверсию своего участка — без этого юнит-экономика превращается в цифру «для отчёта», а не в рабочий показатель. Структурировать отчётность по кругам. Сначала общая картина (доля лидов по каналам, конверсия по каждому), потом детализация по годам с фиксацией прогресса, и только потом — тактика по каналу. Подробно про такую структуру и про то, как выглядит стратегия, которая не превращается в презентацию для полки, я разбирал отдельно — там же пример, как доля лидов с одного канала выросла с 5% до 35% за год: стратегия как рабочий инструмент, а не презентация для полки . Ввести регулярный ритм сверки. Фиксированный день — четверг, коммерческий отчёт по трём блокам (маркетинг, продажи, авансы), результаты копятся в одну таблицу к концу недели. Цикл пересчёта модели упал с квартала — это около 90 дней — до недели, 7 дней между сверками: цифра просто не успевает устареть до следующего четверга. Так сразу видно, где проблема системная, а где просто конкретный менеджер не выполняет план. 90 дней было 7 дней стало На диаграмме — как сократился цикл пересчёта модели: с квартала (≈90 дней) до недели (7 дней) после перехода на регулярный ритм сверки по четвергам. Коммерческий отчёт · четверг 2,4× разрыв плана и факта 37–40% доля аванса от договора 7 дней цикл пересчёта модели Блок отчёта Источник данных Владелец Маркетинг CRM / UTM-метки назначен Продажи CRM, поле «оплачено» назначен Авансы платёжный шлюз назначен Параметр До пересборки После пересборки Источник цифры «выручка» сумма подписанных договоров оплаченные поступления (факт на счёте, окно 2 дня) Доля аванса от договора не учитывалась в плане параметр формулы, 37–40% Цикл пересчёта модели ≈ 90 дней (раз в квартал) 7 дней (еженедельно, по четвергам) Владелец цифры по направлению не назначен назначен, отвечает за маржу/конверсию/чек Источник данных для первого шага — тема отдельного разбора: если контроль движения денег не выстроен системно, любая формула сверху будет считать мусор. Похожий принцип я описывал на примере авансов и дебиторки — контроль, который не держится на памяти конкретного человека: дебиторка растёт: контроль, который не зависит от памяти людей . Рекомендую как предварительный шаг перед пересборкой модели. Может ли ИИ построить вашу финмодель Короткий ответ: посчитать — да, отвечать за допущения — нет. Разберём, где проходит эта граница. ИИ хорошо генерирует убедительно звучащий текст стратегии и плохо проверяет собственные допущения — поэтому его место в модели не автор, а критик уже готовых расчётов. Тот случай с ИИ-стратегией из таблицы выше — тому пример: цифры и тренды выглядели стройно, а по сути в расходах пропали бонусы продаж, и весь прогноз держался на продолжении линии тренда, ничем не подкреплённом. Марк сформулировал точно: «стратегия выглядит убедительно, но содержит объективно бредовые вещи». Конвейер, который мы выстроили после этого: Google Sheets (черновик модели) → скрипт-триггер по четвергам → API модели-критика → лист «Проверка допущений» → уведомление в Telegram, если найдены проблемы. Модель для этой задачи нужна дорогая, топ-уровня — не дешёвый классификатор: задача не сгенерировать текст, а найти логическое противоречие в цифрах, и ошибка здесь стоит дороже разницы в цене токенов между моделями. Сколько такой конвейер съедает в реальных счетах — отдельная тема, я считал это на своих проектах: сколько на самом деле стоит ИИ в месяц . Промпт работает только если модель-критик получает структурированный JSON, а не текстовое описание — иначе она сама начинает генерировать убедительные, но непроверяемые ответы, повторяя ту же ошибку, которую должна ловить. Формат «таблица с уточняющим вопросом» важен отдельно: без него ИИ склонен формулировать проблему абстрактно («данные требуют уточнения»), а конкретный вопрос владельцу строки заставляет либо назвать источник, либо признать, что цифра действительно ничем не подтверждена. Что может пойти не так при такой пересборке Формулы вместо констант не спасают, если источник данных сам по себе ненадёжен: CRM с незаполненными полями или платёжный шлюз без сверки даст формуле мусор на входе, и результат будет выглядеть точным, оставаясь неверным по сути. Назначенный владелец строки — не гарантия, если у него нет доступа к самим данным и он вынужден раз в неделю просить выгрузку у другого отдела: ритм сверки по четвергам держится только там, где данные приходят автоматически, а не по запросу. Отдельный риск — модель-критик на базе ИИ может пропустить противоречие, если черновик написан достаточно гладко: дорогая топ-модель снижает вероятность такой ошибки, но не исключает её полностью, поэтому финальную проверку цифры по-прежнему делает человек, который за неё отвечает. И последнее: пересборка модели требует времени владельцев строк, а не только финансиста — если направления не выделят на это часы в первую неделю, ритм по четвергам не приживётся и всё вернётся к ручному пересчёту раз в квартал. С чего начать, если ваша модель уже разошлась с фактом Не переделывайте всё: найдите одно расхождение и разберите его до конца. Обычно там же лежит причина остальных. Если план и факт разошлись сильнее, чем в полтора-два раза, разбираться в причине стоит не с формул, а с источника: спросить, что именно каждая цифра называет — оплату, договор или обещание — и свести всё к одной базе, прежде чем менять что-либо ещё. Дальше формулы, владельцы строк и ритм сверки достраиваются поверх уже согласованного источника, а не вместо него. У нас на это ушло около месяца, но цена ошибки — 2,4-кратный разрыв плана и факта — того стоила: без пересборки та же путаница повторилась бы в следующем квартале с теми же потерями на найм и тем же управленческим временем на споры, вместо которых теперь есть еженедельный четверговый отчёт на трёх блоках. Сделайте одну вещь на этой неделе: выпишите определения, которыми пользуется ваша модель — что такое выручка, когда она признаётся, что входит в маржу. Половина расхождений живёт именно там. Как собрать модель, которой пользуются, а не любуются, — в бесплатном курсе . И главное для вас: модель, с которой не сверяются, не нужна никому, какой бы точной она ни была. Начните с одной сверки в месяц — и вы быстро увидите, какие ваши допущения не выдерживают встречи с реальностью. ## Внедрение ИИ в компании: считайте срок в циклах приёмки, а не в неделях URL: https://davidgerstein.pro/blog/skolko-vremeni-zanimaet-vnedrenie-ii/ Дата: 2026-08-31 Направление: Операционное управление Цифры: 2–3 недели техники против 2–4 месяцев внедрения, 5–8 циклов приёмки, 4-й месяц у контура с 10 сценариями Цифры пересчитаны на условную компанию — механика, сроки и выводы реальные. Вам надо назвать срок. Партнёру, совету, себе в план года. Вы спрашиваете подрядчика — он говорит «две недели». Спрашиваете знакомого, который проходил, — «полгода, и то не факт». Оба звучат уверенно, и вы понимаете, что один из них врёт, только не знаете который. Не врёт никто. Они отвечают на разные вопросы. Срок внедрения на 80% состоит из вашего календаря, а не из работы подрядчика. Поэтому вопрос «сколько это займёт» вы задаёте не тому человеку. Сколько времени занимает внедрение ИИ в компании 2–3 недели на сборку работающего контура и 2–4 месяца до устойчивой пользы. Технической работы в этом сроке меньше четверти — остальное занимают циклы приёмки и калибровки. Считать надо в циклах: их всегда 5–8 на процесс, а длина одного зависит только от того, за сколько дней руководитель посмотрел результат. При ответе в тот же день шесть циклов проходят за 3 недели, при ответе раз в неделю — за 3 месяца. Что занимает 2 недели, а что — 4 месяца Собрать работающий контур — 2–3 недели. Это правда, и это не маркетинг: подключение к источнику данных, промпт, обработка, выгрузка результата. Через 2 недели у вас на руках штука, которая берёт реальные данные и выдаёт реальный результат. Дальше начинается то, о чём в коммерческих предложениях не пишут. Результат надо посмотреть. Сравнить с тем, как это делает человек. Найти расхождения, понять их причину, поправить правило, прогнать снова. И так по кругу, пока результату можно будет верить без проверки. Вот здесь и живут ваши месяцы. Не в коде — в кругах. Техническая сборка — 22% срока Циклы приёмки и калибровки — 48% Отключение старого способа и работа с людьми — 30% Считайте в циклах, а не в неделях Главная мысль этой статьи одна: проект меряется числом циклов приёмки, а не календарным временем. Циклов всегда примерно одинаково — 5–8 на процесс, и это число почти не зависит от вас. Первый круг показывает грубые ошибки. Второй — что правило сформулировано неоднозначно. Третий — редкие случаи, о которых никто не вспомнил. Дальше идёт шлифовка. Меньше пяти не бывает: если вам кажется, что хватило двух, значит вы не проверяли, а посмотрели. А вот длина одного цикла зависит целиком от вас. Подрядчик отдал результат в понедельник. Вы посмотрели в пятницу через неделю. Цикл — 12 дней. Умножаем на 6 кругов — три месяца, из которых работы было десять дней. Тот же проект при вашем ответе за сутки: цикл 3 дня, шесть кругов — три недели. Ваша скорость ответа Длина цикла 6 циклов Что вы скажете в конце В тот же день 2–3 дня 2–3 недели «Оказалось быстро» За 2–3 дня 5 дней 1,5 месяца «Нормальный темп» Раз в неделю 10–12 дней 3 месяца «Затянулось» Когда вспомню 3–4 недели 6 месяцев «Не взлетело» Обратите внимание: работа подрядчика во всех четырёх строках одинаковая. Меняется только ваша строка календаря — и итог отличается в 8 раз. Два наших контура и почему они разошлись в разы Мониторинг откликов на вакансии: 6 недель от разговора до работающего. Один набор критериев отбора, один человек принимает результат, критерии описаны за пару вечеров. Оценка разговоров: 4-й месяц и продолжается. И вот честная причина — не сложность кода. Типов разговора оказалось не два: понадобилось 10 разных чек-листов под разные сценарии. Каждый чек-лист — это отдельный цикл калибровки со своей выборкой, своим разбором расхождений, своей правкой правил. Десять сценариев — это десять очередей в один и тот же чужой календарь. Умножьте: 10 сценариев × 5 циклов × неделя ожидания. Получите ровно тот срок, который мы и наблюдаем. Это, кстати, ещё один довод не брать самый больной процесс первым : сложность процесса умножается на срок, а не складывается с ним. Правило прикидки Срок ≈ (число сценариев в процессе) × (5–8 циклов) × (ваша скорость ответа в днях). Прикиньте по своему процессу до старта — и вы либо перестанете удивляться срокам, либо сократите число сценариев на входе. Второе, кстати, обычно правильнее. Самая дорогая фраза в вашей компании Я вытащил из разборов за это лето все места, где что-то встало надолго, и увидел одну повторяющуюся конструкцию. Она звучит безобидно: «отправлено на доработку». Без даты возврата. Концепция мероприятия — отправлена на доработку, срок не назван, слот не забронирован. Тексты вакансий — обсудили половину, вторую не успели, дата не поставлена. Ошибка в таблице, которая затирала ручные строки: проблему нашли, зафиксировали, ответственного и срок не назначили. Рассылка встала на 4 недели, потому что человек не знал, что техчасть — не его зона, и молчал. Ни одна из этих задач не была отменена. Все они формально «в работе». Работа при этом не идёт, и узнаёте вы об этом через месяц, случайно. Во внедрении эта фраза стоит дороже всего, потому что она попадает точно в цикл приёмки — в то самое место, где и живут ваши месяцы. Введите правило: любая передача результата сопровождается датой, когда его посмотрят. Не «на неделе», а числом. Это одно правило сжимает срок проекта вдвое, и оно ничего не стоит. Реалистичный график внедрения ИИ в компании: что и когда Так выглядит нормальный ход для одного процесса с одним-двумя сценариями. Не идеальный — нормальный, с учётом того, что у вас есть основная работа. Период Что происходит Ваше время Признак, что идёте по графику Неделя 1 Описание правил: что считается годным результатом 2–3 часа Правило записано так, что по нему может судить другой человек Недели 2–3 Сборка контура, первые прогоны на реальных данных 1 час Есть результат на ваших данных, пусть кривой Недели 4–7 Циклы калибровки: сверка с людьми, разбор расхождений, правка правил 40 мин в неделю, стабильно Расхождение с людьми сокращается от цикла к циклу и записывается цифрой Недели 8–10 Теневой режим: машина работает параллельно с людьми, решения ещё за людьми 30 мин в неделю Сюрпризов больше нет, расхождения только в редких случаях Недели 10–12 Отключение старого способа Разговоры с командой Никто не ведёт параллельную ручную копию «на всякий случай» Итого — 2–3 месяца до состояния, когда процессом пользуются не из-под палки. Если вам обещают тот же результат за 3 недели, спросите, в какую неделю встроена калибровка. Ответа обычно нет. Где я сам потерял больше всего Не на плохом подрядчике и не на сложной технологии. На том, что не начинал. Задача с расшифровкой и оценкой разговоров висела у меня 2 года . Не два месяца — два года. Всё это время она была очевидно нужной, очевидно окупаемой и очевидно решаемой. Я к ней подступался, откладывал, возвращался. Когда наконец сел — первый работающий результат появился за недели. Два года ожидания против нескольких недель работы. Вот настоящая арифметика сроков внедрения, и она не про подрядчиков. Второй урок — из истории с сайтом. Мы собрали 12 типов страниц скриптом, посмотрели, увидели ошибки в оформлении и уже собрались доводить до идеала перед показом. Развернули иначе: взяли одну утверждённую страницу за эталон и приняли принцип — запускать с текущим качеством и проверять на реальных пользователях, а не полировать до релиза. С внедрением ИИ то же самое, только жёстче: пока машина не поработала на ваших настоящих данных, вы не знаете о ней ничего. Все ваши представления о том, где она ошибётся, — фантазии, и проверяются они за один прогон. Общий маршрут внедрения по неделям — в разборе маршрута по неделям: с какого процесса начинать и когда отключать старый способ . Как сжать срок вдвое, ничего не доплачивая Поставьте приёмку в календарь заранее Не «посмотрю, когда пришлют», а фиксированный слот: 40 минут раз в неделю на весь период внедрения. Он должен стоять до того, как проект начался, иначе будет проигрывать всему горящему — калибровка никогда не горит сама, в этом её главная беда. Режьте число сценариев на входе Раз срок умножается на количество сценариев, самый быстрый способ сократить его — начать с одного. Не «оценивать все типы разговоров», а один самый частый тип. Остальные добавляются потом, уже на отлаженной механике, и идут в разы быстрее первого. Дробите обучение машины Мы пришли к схеме: сперва 40 случаев с ручной проверкой людьми, затем контролируемый сегмент в 5 000 , и только потом весь объём. Кажется, что это удлиняет — на деле сокращает: ошибка, найденная на 40 случаях, стоит вечер, та же ошибка на полном объёме стоит доверия команды и месяца на его восстановление. Назначьте того, кто отвечает за скорость У циклов должен быть хозяин — человек, который следит, чтобы результат не лежал непосмотренным. Обычно это владелец процесса, он же специалист по внедрению ИИ , и у него на это должно быть выделено время, а не «в свободные минуты». Что происходит после «внедрили» Есть срок, о котором не спрашивают вообще, а он самый длинный: сколько живёт внедрённое. Ответ неприятный — ровно столько, сколько за ним смотрят. У нашего контура оценки разговоров сверку с людьми провели один раз , 25 июня. Разрыв составил −25,5 п.п. : машина оказалась строже людей. Повторный замер не зафиксирован ни через месяц, ни через два. К концу августа разрыв сжался до −5,5 п.п. — сам, по ходу правок, и этого тоже никто не измерял. Два месяца система работала вслепую. Формально проект был «внедрён» ещё весной. Фактически всё это время нельзя было ответить на простой вопрос: можно ли сегодня верить её оценкам. Поэтому в график добавляйте строку, которой нет ни в одном коммерческом предложении: калибровка раз в квартал, бессрочно. Двадцать минут работы, которые определяют, останется ваш контур рабочим инструментом или превратится в декорацию, о которой все помнят, что она есть, и никто не пользуется. Три ситуации, когда сроки поплывут гарантированно Их видно заранее, и лучше их назвать до старта, чем объяснять потом. Правила процесса не записаны. Если исполнители описывают работу по-разному, вы потратите первые 2–3 цикла не на калибровку машины, а на выяснение, как вообще должно быть. Это нормальная работа, но её надо считать отдельно и делать до сборки контура, а не во время. Приёмщик не тот человек. Когда результат принимает тот, кто не делает эту работу руками, циклы идут вхолостую: он не видит ошибок, которые видит практик, и они всплывают на третьем месяце, когда всё уже собрано. Возврат к правильному приёмщику стоит половины проекта. Старый способ никто не отключает. Пока обе схемы живут параллельно, у проекта нет конца — он бесконечно «дорабатывается». Дата отключения ставится в план на старте, вместе с датой запуска, иначе не наступает никогда. Промпт: посчитать срок по своему процессу Прикидка в голове всегда оптимистична — в ней вы отвечаете мгновенно. Отдайте расчёт машине и попросите быть пессимистом там, где данных нет. Дальше сверьте её число со своим ощущением: разница между ними и есть ваш личный коэффициент оптимизма, полезно знать. Навык, который здесь тренируется Считать проект в циклах приёмки, а не в неделях, — базовый навык для всего, что делается итерациями, а итерациями сейчас делается почти всё. Кто считает в неделях, тот всегда опаздывает и всегда искренне удивляется. Кто считает в циклах, тот заранее видит, что шесть кругов при его загрузке — это три месяца, и либо принимает это, либо меняет свою загрузку. Сжать цикл приёмки — отдельная работа, и она про правила, а не про скорость чтения. Этому я учу в курсе : как записать правило приёмки так, чтобы проверка занимала 10 минут вместо часа. Все компании сейчас на одной беговой дорожке, и обгоняют не те, у кого быстрее подрядчик. Обгоняют те, у кого короче цикл: посмотрел, сказал, поправили, посмотрел снова. Внедрение всегда идёт со скоростью самого медленного участника, и почти всегда самый медленный — тот, кто спрашивает про сроки. Откройте календарь и поставьте 40 минут в неделю на приёмку — на ближайшие три месяца, повторяющимся событием. Это займёт минуту и сократит ваш следующий проект вдвое. ## Финансовое моделирование: во что обходится и когда возвращает деньги URL: https://davidgerstein.pro/blog/stoimost-finmodeli/ Дата: 2026-08-31 Направление: Стратегия Цифры: 140 000 ₽ разово · 6 000 ₽/мес эксплуатация · окупаемость ~7–8 мес (оценка) Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Смотрите. Если вы не можете за минуту назвать, во сколько вам обходится один пересчёт финмодели, — у вас не финансовая модель, у вас таблица, которую иногда сводят, и решения вы принимаете вслепую. Я сам держал в голове «дорого, нужен финдиректор» — пока не посмотрел на раскладку: наш счёт оказался в разы меньше ожиданий. Как сделать так, чтобы модель пересчитывалась сама при загрузке месяца, — динамическая финмодель . Марк написал в пятницу вечером, коротко: «Слушай, сколько вообще стоит сделать так, чтобы финмодель сама пересчитывалась? Не хочу больше ждать три дня, пока сведут таблицы». Вопрос по делу — его задаёт себе любой руководитель, глядя на очередной Excel с формулами, которые давно никто не проверял. Отвечаю развёрнуто, сколько стоит финансовое моделирование и когда оно окупается, — как коллеге, а не слайдом на презентации. Сколько стоит финансовое моделирование: если коротко Если у вас план на месяц до сих пор сводят руками и никто не может назвать цену одного пересчёта — вот порядок цифр, от которого стоит отталкиваться. Финансовое моделирование для компании на 40 человек — 8 менеджеров, оборот около 9 млн ₽ в месяц — стоит разово 120–160 тыс ₽ на настройку и 5–7 тыс ₽ в месяц на работу самой модели (оценка, это часы аналитика и разработчика плюс стоимость обработки данных ИИ). Окупаемость зависит от того, что считать эффектом: если только сэкономленное время финансиста — около 7–8 месяцев; если хотя бы один предотвращённый кассовый разрыв из-за неверного прогноза — в первый же квартал. Складывать эти два эффекта нельзя: один считается временем, другой — вероятностью инцидента, и складывать их в одну сумму нельзя. Дальше Марк спросил то, что спрашивает всегда: «за счёт чего конкретно, не просто скажи, что дорого или дёшево». Разбираю по частям: почему ручная модель обходится дороже, чем кажется на бумаге, как устроена автоматизация по шагам, что в ней делает ИИ, а что — обычная формула, и во сколько это выливается в деньгах. Почему ручное финансовое моделирование обходится дороже, чем кажется Считайте не стоимость сборки, а стоимость каждого пересчёта, умноженную на то, сколько раз в год он вам нужен. Ручной пересчёт финмодели съедает не столько зарплату аналитика, сколько скорость решений: пока три дня сводятся таблицы, собственник уже принял решение по интуиции, а не по цифрам. Отдельная и более дорогая проблема — путаница между суммой договора и суммой авансового платежа: если модель считает выручку по факту подписания, а кассу нужно планировать по поступлениям (обычно это 37–40% от суммы договора на старте), прогноз кассы уезжает на десятки процентов от реальности. Я сам сидел на разборе, где так и было: план кассы держался на цифре в 53 млн ₽, а по факту заложено было 22 млн — и никто на встрече не мог сразу ответить, это сумма договоров или сумма реально поступивших авансов. Разница в трактовке — это разница в 2,4 раза в том, сколько денег компания якобы должна увидеть на счету. Похожая история — с дебиторкой: искажение видимости денег на счету часто растёт из того же корня, что и рост просроченной задолженности, — см. разбор дебиторка под контролем, который не зависит от памяти людей . Дальше все числа в этом разделе — оценка, основанная на пропорциях легенды; отдельно по каждой цифре это уже не помечаю. Переведу в цифры нашей легенды. При обороте 9 млн ₽/мес и среднем чеке 180 тыс ₽ компания закрывает около 50 сделок в месяц — по 6–7 на менеджера. Если модель путает 10% этих сделок (записывает аванс как уже поступившую выручку или наоборот), это 5 сделок × 180 тыс ₽ = 900 тыс ₽ искажения видимости кассы в месяц. Это не потеря денег — это потеря зрения: собственник либо решит, что денег больше, чем есть, и одобрит закупку или найм, либо решит, что денег меньше, и придержит инвестицию, которая была бы оправдана. Порядок цены одной такой ошибки — от нескольких сотен тысяч до нескольких миллионов рублей неверного решения, что уже само по себе выше стоимости всей автоматизации. Плюс время. Ручной пересчёт финмодели и сверка отклонений от плана съедают у аналитика или финансиста около 20 часов в месяц — не потому что расчёт сложный, а потому что данные разбросаны по CRM, банку и голове менеджера. Каждое внеплановое изменение — акция, потерянный клиент, задержка оплаты — это ещё один ручной прогон таблицы. 20 ч было 6 ч после На диаграмме — время ручного пересчёта и сверки финмодели в месяц: 20 часов вручную против 6 часов при автоматизации (проверка и сверка). Считаем экономию времени: формула и пример на числах Формула словами, чтобы прикинуть свой случай: часы ручного пересчёта в месяц × доля, которую снимает автоматизация, × ставка специалиста в час = сумма экономии в месяц; из неё вычитаем стоимость эксплуатации модели — получаем чистую экономию; разовые затраты на внедрение делим на чистую экономию — получаем срок окупаемости в месяцах. Числа нашей легенды я подставляю консервативно — так, как считал бы для себя, а не для слайда. Ручной пересчёт — 20 часов в месяц. Автоматизация не убирает работу финансиста целиком: он всё ещё проверяет план на сверке по четвергам — берём консервативную долю снятой нагрузки в 70%. Это 14 часов в месяц. При типовой ставке финансиста около 1 700 ₽/час для позиции такого уровня экономия — 14 × 1 700 = 23 800 ₽/мес. Минус эксплуатация модели 6 000 ₽/мес — чистая экономия около 17 800 ₽/мес. Разовые затраты 140 000 ₽ (середина вилки 120–160 тыс) делим на чистую экономию: 140 000 / 17 800 ≈ 7,9 месяца. Отсюда и цифра в 7–8 месяцев в оценке окупаемости по времени — она не взята с потолка, а собрана из трёх допущений, каждое из которых можно поправить под свою компанию. посчитайте на своих цифрах часов ручного пересчёта в месяц доля, которую снимет автоматизация, % ставка специалиста, ₽/час экономия ≈ {X} ₽ в месяц формула: часы ручного пересчёта × доля автоматизации × ставка; из результата отдельно вычтите стоимость эксплуатации модели (обычно 5–7 тыс ₽/мес) Второй эффект — предотвращённые ошибки прогноза — считается иначе и складывать его с первым нельзя: он не про часы, а про вероятность и цену одного инцидента. Если за квартал модель хотя бы раз поймает искажение кассы порядка 900 тыс ₽ (как в примере выше) до того, как оно превратится в решение о найме или закупке, — это перекрывает всю стоимость внедрения за один раз, независимо от того, сколько месяцев прошло. Считать эти два эффекта в одной сумме — типовая ошибка презентаций: время экономится постепенно, ошибка предотвращается разово, и годовой эффект — это не сумма, а два разных сценария, которые стоит показывать раздельно. Показатель Вручную С автоматизацией Эффект Время пересчёта модели в месяц ~20 часов ~6 часов (проверка и сверка) экономия ~14 часов/мес Стоимость этого времени (ставка ~1 700 ₽/час) ~34 000 ₽ ~10 200 ₽ ~23 800 ₽/мес экономии Эксплуатация модели (ИИ-обработка) — 5 000–7 000 ₽/мес вычитается из экономии Чистая экономия времени в месяц — — ~17 800 ₽/мес Разовые затраты на внедрение — 120 000–160 000 ₽ окупаются за ~7–8 мес Искажение видимости кассы при 10% спутанных сделок до 900 000 ₽/мес отслеживается еженедельно риск снимается системно, не накопительно Как это делается по шагам Автоматизация финмодели строится в три шага: сначала обучение на исторических данных с ручной проверкой, потом тест на контролируемом сегменте, и только затем — масштабирование на всю базу. Прыгать сразу в продакшн — гарантированный способ получить красивый, но неверный прогноз, который на совещании звучит убедительно, а при проверке разваливается. По шагам это выглядит так: Собрать обучающую выборку. Берём 40–50 закрытых сделок за последний месяц (для нашей легенды это как раз месячный поток отдела продаж) и сводим их вручную с финансистом: где договор, где аванс, где сделка сорвалась после частичной оплаты. Это не автоматизация — это разметка, на которой модель потом будет учиться отличать одно от другого. Заменить фиксированные цифры формулой. Вместо «план на месяц — Х рублей» пишем «план = база текущего месяца × (1 + темп роста в %)», где темп роста подтягивается из факта предыдущих периодов. Это снимает главную причину, по которой стратегии и финмодели устаревают за несколько месяцев: план перестаёт быть застывшим числом и пересчитывается сам при каждой новой загрузке факта. Этот же приём я подробно разбирал на уровне стратегии в целом — см. «Стратегия как рабочий инструмент, а не презентация для полки» , здесь не повторяю механику, беру только принцип. Подключить выгрузку данных. CRM (в нашем случае Bitrix24) отдаёт данные по сделке через вебхук при смене стадии — сумма, дата, статус оплаты. Данные летят в Google Sheets, где живёт сама модель. Если сомневаетесь, что даты и суммы из CRM вообще можно доверять напрямую — стоит сначала прочитать, как Битрикс24 сдвигает даты сделок , и заложить эту проверку в конвейер заранее. Протестировать на контролируемом сегменте. Не запускаем на весь отдел сразу — берём 20% сделок или одного менеджера, гоняем модель две недели, сверяем с ручным расчётом финансиста построчно. Масштабировать и закрепить ритм проверки. После сходимости — подключаем весь отдел и вводим фиксированный день сверки, например четверг: маркетинг, продажи и авансы сводятся в одну таблицу к концу недели. Кто смотрит. Финансист проверяет модель на сверке раз в неделю, собственник смотрит итог раз в месяц — и не читает отчёт длиннее одной страницы. Риск. Если пропустить шаг с контролируемым сегментом и сразу подключить вебхук на весь отдел, первая же неверно размеченная сделка (аванс, принятый моделью за полную оплату) уйдёт в план без проверки — и всплывёт не на тестировании, а на встрече с собственником, когда касса не сойдётся с фактом. Две недели на 20% сделок стоят дешевле, чем одно ошибочное решение о найме или закупке на основе неверного плана. Мой порядок здесь жёсткий: сначала сегмент, потом весь отдел. ИИ-связка: чем в моделировании занят ИИ, а чем формула В конвейере финансового моделирования ИИ решает две разные задачи, и для них нужны разные модели: дешёвая — для рутинной разметки данных по формальным признакам, дорогая — для еженедельного критического аудита допущений, где нужно рассуждение, а не классификация. Схема конвейера: Bitrix24 (сделка меняет стадию) → вебхук → Google Apps Script дописывает строку в лист «Сделки» → дешёвая модель размечает договор/аванс/статус и подставляет цифры в формулу плана → раз в неделю дорогая модель прогоняет весь план целиком и ищет нестыковки → результат — в отдельный лист «Аудит» и уведомление в Telegram, если модель нашла подозрительное допущение. Промпт 1 (дешёвая модель — например, лёгкая версия GPT для формальных задач). Задача разовая и структурная: разметить строку сделки, не нужно рассуждение — нужна скорость и низкая цена за вызов. Пример ответа модели: Здесь же видно масштаб проблемы: 72 000 ₽ из 180 000 ₽ — это 40% от суммы договора, ровно та доля аванса на старте, которая в ручной модели чаще всего путается с полной выручкой. Если бы модель на этой строке ошиблась и записала в кассу 180 000 ₽ вместо 72 000 ₽, искажение по одной сделке составило бы 108 000 ₽ — больше половины месячной стоимости эксплуатации всей системы. Промпт 2 (дорогая модель — уровня GPT-4o/Claude Sonnet). Задача еженедельная и требует рассуждения: найти в готовом плане допущения, которые формально верны, но по факту не учтены или не обоснованы — это ровно то место, где ИИ обычно ошибается уверенно и гладко, если его не проверять. Пример ответа модели: Лист «Аудит» — сверка по четвергам 9 500 000 ₽ план на месяц 3 найденные проблемы 1 severity: high issue severity бонусы не включены в план high рост 5% без учёта сезонности mid найм 2 сотрудников не учтён в ФОТ mid Дальше решает severity. Проблему с меткой «high» финансист получает в Telegram сразу, не дожидаясь четверговой сверки — бонусы, не вычтенные из маржи, искажают план сильнее, чем любая формальная неточность в разметке сделки. Это тот же класс ошибки, который на практике уже случался: план выглядел убедительно, но не учитывал бонусы продаж, а прогноз объёма на следующий год был не обоснован ничем, кроме гладкого текста модели — именно такие вещи и должен ловить еженедельный аудит, а не ежемесячная презентация собственнику. Собственник видит план только после того, как метка снята или проблема объяснена руками, а не спрятана в примечании на второй странице. Это тот же принцип, что и в других задачах, где автоматизация работает только под присмотром человека, а не сама по себе — см. «Если бы я не пришёл, ничего бы не произошло»: автоматизация, требующая надзора . Как прикинуть цену моделирования на ваших цифрах Формула простая: часы на сборку плюс часы на каждый пересчёт, умноженные на их количество за год. Чтобы не переносить чужую легенду один в один, посчитайте по своей компании три числа: часы ручного пересчёта в месяц, долю этой работы, которую реально снимет автоматизация, и ставку часа своего финансиста или аналитика по факту, а не по окладу за месяц. Первое — спросите у того, кто делает пересчёт вручную, сколько часов в месяц он на это тратит, а не оценивайте сами. Второе — если данные уже в одной CRM, можно закладывать долю снятой нагрузки в 70–80%; если данные разбросаны по трём системам и экселю — консервативнее, 40–50%. Третье — ставка часа именно в пересчёте на час, а не оклад делённый на 160. Дальше формула та же: часы × доля автоматизации × ставка = экономия в месяц; минус стоимость эксплуатации (у вас она может отличаться от 5–7 тыс ₽, если сделок в разы больше); разовые затраты делим на чистую экономию — получаем свой срок окупаемости по времени (оценка, поскольку зависит от трёх ваших собственных допущений). Отдельно, не складывая с этим числом, прикиньте вторую цифру: сколько стоила бы вам одна ошибка прогноза кассы такого масштаба, как в примере с путаницей договор/аванс. Если эта цифра выше стоимости внедрения — у вас есть второй, более быстрый аргумент для решения, независимо от того, что покажет расчёт по времени. Прикиньте свою цифру: сколько часов уходит у вашей команды на пересборку модели и сколько раз в год вы это делаете. Дальше решение принимается само. Механика сборки — в бесплатном курсе . Ваш ориентир при разговоре с подрядчиком: спрашивайте не цену сборки, а цену одного пересчёта. Именно она определяет, будете ли вы пользоваться моделью или она умрёт после первой презентации. И то, ради чего это всё считается. Умение перевести свою экономику в формулу и отдать пересчёт машине — это управленческий навык, такой же обязательный, каким когда-то стало умение читать отчёт о прибылях и убытках. Не «полезная штука для финансиста», а навык руководителя, за который платят: тот, кто держит цифру живой и решает по ней в тот же день, стоит дороже того, кто раз в квартал заказывает сведение таблиц. Осваивается он не за вечер — я сам считал руками дольше, чем стоило. Мой ориентир по этой задаче: если вы пересчитываете модель чаще раза в месяц, автоматизация окупится за квартал. Реже — считайте руками, вам это дешевле. Первое движение на этой неделе — не искать подрядчика, а спросить своего финансиста, сколько часов у него уходит на один пересчёт. Без этой цифры разговор о стоимости — торг вслепую. ## Искусственный интеллект заменит человека? За два года «найма» машин мы не заменили никого — заменять оказалось некого URL: https://davidgerstein.pro/blog/ii-sotrudniki/ Дата: 2026-08-30 Направление: Люди Цифры: 75% разговоров с клиентами не слушает никто · ~130 ₽ → ~9 ₽ за операцию · 7139 оценок и 1 отзыв Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Вам продают страх. «Искусственный интеллект заменит человека», «уволь колл-центр», «ИИ-агент вместо отдела». Вы читаете это третий месяц, не верите — и одновременно боитесь, что не верите зря. Знакомое состояние: подожду, пока прояснится. Так вот. Пока вы решаете, хайп это или нет, вопрос уже решается за вас — тем, что вы не делаете. И считать придётся не упущенную выгоду в презентации, а вещь попроще: у вас прямо сейчас никто не слушает три четверти разговоров с вашими клиентами. Не потому что сотрудники плохие. Потому что это стоило дорого, и вы, как все, махнули рукой. Мы «нанимаем» машинных исполнителей два года. Главный факт этих двух лет звучит скучнее рекламы и полезнее её: ни один человек не был заменён. Ни разу. Не потому что мы добрые — а потому что заменять оказалось некого. Каждый раз машина садилась на стул, которого в компании не существовало. Заменит ли искусственный интеллект человека на самом деле Нет — во всяком случае, не так, как обещает реклама. За два года «найма» машинных исполнителей в компании на 40 человек не заменили ни одного сотрудника: заменять оказалось некого. Машина села на работу, которую не делал никто: 75% разговоров с клиентами не слушал вообще никто , потому что на это не было ресурса. Экономический смысл в другом: стоимость одной операции контроля упала с ≈130 ₽ до ≈9 ₽ . Не сокращение штата, а закрытие дыры, которая годами была открыта. Должности-призраки: работа, которую не делает никто Смотрите. В любом среднем бизнесе есть слой работы, которая нужна и которую не делает ни один человек. Не по лени — по арифметике: она никогда не окупалась. Наш контролёр качества — ровно этот случай. До машины человек успевал прослушать четверть звонков за полный рабочий день. Остальные 75% не слушал никто и никогда. Должность «контролёр всего потока» была призраком: полезная, очевидная — и нерентабельная при любой зарплате. Проверьте себя. Эти призраки есть почти у всех: Кого у вас нет Почему нет Чем платите Тот, кто слушает все звонки и читает все переписки Нужны 3–4 ставки ради «профилактики» Сорванное обещание клиенту всплывает через скандал Тот, кто читает каждый входящий договор Юрист занят сделками, «типовые и так нормально» Нестандартный пункт находит суд, а не вы Тот, кто каждое утро сводит отчёт из всех систем Час ручной сборки ежедневно — «дорого» Решения принимаются по вчерашним ощущениям Тот, кто пишет протокол каждой планёрки Стенографистка в 2026 году — экзотика Половина решений переспрашивается заново Тот, кто разбирает каждый входящий документ Монотонно, текучка, никто не держится Очередь, ошибки ввода, потерянные комплекты Отсюда и ответ на вопрос, с которым сюда обычно приходят. Искусственный интеллект заменит человека — но не того, о ком вы подумали: он занимает не занятый стул, а пустой. Списков исчезающих профессий здесь не будет: у меня нет данных о рынке труда, у меня есть два года собственной приёмки. Заметьте: ни в одной строке нет живого человека, у которого забирают работу. Этих людей нет. Поэтому правильный вопрос звучит не «кого мне заменит машина», а «какую из моих дыр она наконец закроет» . И разговор с командой сразу становится другим: машина на пустом стуле не вызывает саботажа. Саботаж вызывает машина, нацеленная на занятый. Где искусственный интеллект действительно заменил человека — и почему именно сейчас Давайте рационально, через деньги. Ручная оценка звонка: контролёр со ставкой 1 000 ₽/час разбирает 7–8 разговоров — около 130 ₽ за штуку (оценка). Машинная оценка того же звонка по тому же чек-листу: примерно 9 ₽. Это не «дешевле на треть». Это порядок. Человек ~130 ₽ Машина ~9 ₽ И вот здесь главное, ради чего стоило читать. Когда операция дешевеет в десять раз, меняется не себестоимость старой работы. Меняется список работ, которые вообще имеют смысл. Слушать все звонки при 130 ₽ за штуку — это 340 тысяч рублей в месяц на профилактику. Ни один директор такое не подпишет, и правильно сделает. При 9 ₽ вопрос просто исчезает. То же самое с договорами, документами, ежедневными сводками. ИИ-сотрудник — это не «дешёвый работник». Это сдвиг границы: целый слой управленческой гигиены, который вы хотели и не могли себе позволить, впервые стал по карману. Посчитайте на своём призраке — сколько стоит одна операция руками: посчитайте на своих цифрах минут на операцию вручную ставка исполнителя, ₽/час одна операция ≈ {X} ₽ руками а теперь разделите на десять — и посмотрите, какая работа перестала быть «слишком дорогой» Не можете назвать это число для своих процессов? Тогда вы не управляете ими, вы их спонсируете. Считать себестоимость операции — такой же базовый навык руководителя, как читать отчёт о прибылях. Раньше без него жили. Сейчас — уже нет. Мой провал: сотрудник года, работавший в стол Теперь про то, где я сам сел в лужу — чтобы вы не повторяли. Наш контролёр — техническое совершенство: 7 139 оценок, около $300 в месяц, аптайм месяцами . Охват вырос с четверти до ста процентов. Красивый кейс, хоть на конференции показывай. А теперь цифра, которую я публикую как прививку. Из этих тысяч оценок в управленческое решение — разбор с менеджером, правку скрипта, хотя бы содержательный отзыв — превратилась одна . Одна. Машина исправно выдавала продукт, который никто не превращал в управление. Петля «оценка → разбор → изменение» умерла, пока мы радовались охвату. Это моя недоработка, не машины. Я построил образцового сотрудника и забыл им руководить. Технически всё зелёное, управленчески — ноль. Поэтому если вы сейчас думаете «звучит сложно, я не потяну» — вот вам моя ошибка целиком, повторять её не нужно. Она обошлась в год работы контура почти вхолостую. И она же дала главную мысль всей темы, к которой я веду. Нанять ИИ-сотрудника нельзя Реклама обещает вам минус одну позицию в штате. По факту вы получаете плюс две : машину-исполнителя и — обязательно — человека, который ею руководит. Пишет инструкцию, калибрует, принимает работу, разбирает расхождения. Отвечает за результат, потому что машина не отвечает ни за что: спросить с неё нельзя, уволить бессмысленно, совесть отсутствует. Отсюда формулировка, которую я считаю самой честной в этой теме: нанять ИИ-сотрудника нельзя. Можно только стать его руководителем. Или не стать — и остаться руководителем, который умеет управлять только людьми. И вот это уже не про технологии, а про вас лично. Дефицитный ресурс 2026 года — не модели, они у всех одинаковые. Не бюджеты: вход стоит десятки долларов. Дефицит — руководители, способные управлять машинным подчинённым : ставить проверяемую задачу, принимать работу, разбирать расхождения, держать границы роли. Это новый управленческий навык, он осваивается примерно за месяц практики — и кем-то этот месяц уже прожит, а вами ещё нет. У навыка, кстати, есть приятная сторона. Менеджер, ставший руководителем машинного контролёра, получает управленческий опыт, не дожидаясь подчинённых-людей: постановка, приёмка, разбор. Похоже, первая профессия, которую ИИ реально создал, — не промпт-инженер, а руководитель машин . Спрос на неё внутри компаний уже выше предложения, и растёт он быстрее, чем вы читаете эту статью. Подробный разбор — дебиторка растёт . «У меня не тот бизнес» Отдельно про возражение, которое я слышу чаще всех остальных: «у нас специфика, это для айтишников». Смотрите, что за этим обычно стоит. Специфика есть у всех, и она действительно мешает — но не там, где думают. Машине безразлично, продаёте вы металлопрокат или юридические услуги: она работает не с вашей отраслью, а с вашим потоком однотипной работы. Звонок — это звонок, договор — это договор, планёрка — это планёрка. Специфика влияет на правила оценки, и это ровно та работа, которую всё равно придётся сделать: описать, что для вас хороший звонок. А вот что действительно мешает и о чём говорят реже: если у вас нет потока — нет и задачи. Пять звонков в неделю не нуждаются в машинном контролёре, их прослушает руководитель за полчаса. Три договора в месяц юрист прочитает сам. Здесь честный ответ — вам это пока не нужно , и любой, кто продаёт вам «нейросотрудника» на таком объёме, продаёт воздух. Порог, за которым разговор становится осмысленным, простой: работа повторяется десятки раз в неделю и её пропуск создаёт риск. Ниже порога — закройте вкладку и займитесь ростом, вернётесь позже. Инструкция для машины — рентген вашей компании Первое, что делает будущий руководитель машины, — пишет ей инструкцию: что делать, по какому правилу оценивать, что запрещено. И тут вскрывается то, о чём не предупреждают продавцы: чаще всего это оказывается первым настоящим регламентом в компании. Люди годами работали по понятиям: опыт, интуиция, «Ира знает». Машина по понятиям не умеет. Чтобы она оценивала звонки, нам пришлось впервые письменно ответить на вопросы, которые контролёр решала на слух. Что считается обработанным возражением? Обязан ли менеджер назвать срок? Как оценивать звонок, где клиент бросил трубку? Десять чек-листов под десять типов разговора — это не «настройка нейросети». Это формализация отдела продаж, которой у нас не было. Побочный продукт оказался ценнее автоматизации: с этими чек-листами стало можно вводить новых менеджеров, разбирать споры, обучать. А если инструкция не пишется — вы узнали о своей компании самое важное, и узнали дёшево: неудачная попытка стоит недели, а не бюджета внедрения. Три метрики вместо восторга Из моего провала выросла система приёмки. Три числа, по которым мы судим машинного исполнителя, — и ни одно из них не «количество операций». Решения в неделю. Сколько управленческих действий случилось из-за его работы: разборов, правок процесса, изменённых скриптов. Ноль две недели подряд — сотрудник работает в стол. Чинить надо руководителя, а не настройки. Доля пометок «отдаю человеку». Здоровая машина знает границы роли и стабильно возвращает нестандартное. Ноль пометок подозрительнее, чем ноль ошибок: значит, она уверенно перемалывает и то, что перемалывать нельзя. Цена операции в динамике. Себестоимость должна быть известна и стабильна. Если её никто не может назвать — вы не управляете сотрудником, а спонсируете его. Наша ночь за минус $40 случилась ровно в тот период, когда цену операции никто не смотрел. Где ломается Купить «нейросотрудника под ключ» и ждать результата, как от программы, — самый дорогой сценарий темы. Подрядчик честно поставит машину, и она честно начнёт работать в стол с первого дня, потому что руководителя ей не назначили. Проверка перед покупкой ровно одна: назовите имя человека, в чьём календаре появятся приёмка и разборы. Нет имени — вы покупаете не сотрудника, а дорогую имитацию его наличия. А ваши люди уже наняли себе машин И последнее, что стоит знать, пока вы взвешиваете. Ваши сотрудники уже всё решили без вас: пишут письма через чат-боты, суммируют документы, переводят — молча, с личных аккаунтов, без правил. Теневой штат машинных помощников в вашей компании уже работает. Спросите команду анонимно — доля вас удивит. Значит, выбор у вас не «внедрять или нет». Выбор — управлять этим или не знать об этом . Запрет загонит практику глубже в тень, где персональные данные клиентов утекают в публичные чаты без всякого злого умысла. Рабочий ответ — короткий регламент: чем разрешено пользоваться и что компания оплачивает, что запрещено всегда (персональные данные — с примерами), и правило ответственности: отвечает тот, кто подписался под результатом, а не тот, кто его напечатал — рука или машина. Что сделать на этой неделе Не внедрять. Не покупать. Сделать три вещи, на которые уйдёт вечер. Первое. Выпишите свои должности-призраки — работу, которая нужна и которую не делает никто. Таблица выше как подсказка, но своих вы найдёте больше. Второе. Возьмите одну и посчитайте цену операции руками. Калькулятор выше. Разделите на десять — и посмотрите, что изменилось в вашем отношении к этой работе. Третье. Назовите имя. Кто в вашей компании станет руководителем этой машины — вы или конкретный человек с фамилией. Если имени нет, дальше идти незачем: без него вы повторите мой провал в точности. А дальше — механика: как устроен такой исполнитель , как он подключается к вашим системам . Если своими руками пока не видно как — у меня есть бесплатный курс , там всё по шагам: с чего начать разбор своей рутины и как довести первый контур до работы. Он не про технологии — он про то, как этим управлять. И последнее. Все компании сейчас стоят на одной беговой дорожке, и она уже включена — вне зависимости от того, приняли вы решение или ещё думаете. Кто побежал первым, тот и прибежит первым. Кто стоит — уезжает назад, ничего при этом не нарушая. Через год этот текст будет читаться как описание очевидного. Разница между вами и вашим конкурентом окажется в том, кто из вас начал считать сегодня. ## Цели стратегического планирования: как ИИ нарисовал рост ×2,4 без механики URL: https://davidgerstein.pro/blog/ii-strategicheskoe-planirovanie/ Дата: 2026-08-30 Направление: Стратегия Цифры: план роста ×2,4, пересчёт 6ч → 1ч, ошибка 567 тыс ₽/мес поймана агентом Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Дневник внедрения: как мы за квартал перевели стратегическое планирование с ручной сборки на машинную. Со всеми граблями, включая неделю, когда всё сломалось. Если вы думаете, повторять ли — читайте до конца: половина полезного здесь именно в ошибках. Я эти грабли собрал лично, и мне до сих пор неловко их пересказывать — но вам дешевле прочитать, чем повторить. Это дневник о том, как цели стратегического планирования сервисной компании (услуги для бизнеса, около 40 человек в штате) считала нейросеть: сначала она обманула совет директоров красивыми графиками, а потом стала инструментом пересчёта плана и проверки допущений. Финдиректор (отдел продаж — 8 менеджеров, оборот около 9 млн ₽ в месяц, средний чек по контракту — 180 тыс ₽, цикл сделки — около 6 недель) принесла на совет директоров презентацию стратегии на год. Собственник — назовём его Марк — требует, чтобы план пересчитывался за час, а не за квартал, и не читает отчёты длиннее страницы. На совете он открыл третий слайд и спросил: «Это годовая цифра или из месячного бюджета?» Ответа не было. Часть цифр в таблице оказалась годовой, часть — месячной, и никто их не свёл к одному знаменателю. Разрыв обнаружился не сразу, а через квартал, когда отдел продаж показал результат на 40% выше заложенного плана. Похвалить менеджеров не вышло: сама база для сравнения была кривой, и премию считать было не от чего. В деньгах это означало, что компания три месяца управляла вслепую — не понимала, сколько маркетингового бюджета, менеджеров и специалистов на проектах ей реально нужно под тот рост, который она сама себе обещала. Может ли ИИ поставить цели стратегического планирования Если у вас цель на год уже утверждена, а на вопрос «за счёт чего» в таблице ответа нет — цель у вас есть, а механики под ней нет. Собрать структуру и посчитать сценарии за вечер машина может. Отвечать за цифры — нет. Первая модель компании на 40 человек, написанная нейросетью по выгрузке из таблицы, показала рост ×2,4 и не заложила ни авансы (37-40% от суммы контракта), ни бонусный фонд менеджеров. Одна эта дыра искажала прогноз прибыли на 567 тыс ₽ в месяц. Работает другая связка: машина считает по формуле, человек проверяет допущения. Если вы отдаёте машине выгрузку с фактом и планом, держите за собой три точки — кассовый разрыв, бонусный фонд, механика роста по каналам. После запуска такой связки пересчёт плана при новых данных занимает 1 час в неделю вместо 6, а невычтенный бонусный фонд ловится автоматически. Что мы решили в начале квартала Три правила, которые вы можете взять себе целиком — они не зависят от отрасли и размера компании. Марк поставил условие: каждый руководитель приносит трёхмесячную стратегию, посчитанную, а не нарисованную на глаз. Критерии успеха утверждают заранее с вышестоящим руководителем — чтобы не спорить о них по итогам периода. План разбивается по неделям, а не «на квартал в целом». Отдельно — макрозадача: к концу мая у каждого направления должна быть пятилетняя стратегия с ожидаемыми показателями, и написать её предлагается с помощью нейросети, чтобы не тратить месяц на ручной пересчёт сценариев. Мы решили не делать это через одну универсальную «супермодель». Вместо этого — три отдельных шага: собрать данные, обучить модель на реальных кейсах с проверкой человеком, протестировать на контролируемом сегменте и только потом масштабировать. Это медленнее, чем «дай ChatGPT весь Excel и попроси план» — но именно этот короткий путь и провалился уже на второй неделе. Неделя 1: финансовую модель за вечер написала нейросеть Скорость, которая вас обманет — как обманула меня. Красивый результат за вечер ещё не значит верный. Я сам купился на ту презентацию первым: она выглядела как готовый ответ, а была красивой картинкой на месте ответа. Первая попытка была простой и наивной. Финдиректор выгрузила годовую выручку, разбивку по каналам и текущий план, скормила это модели с промптом «построй финансовую модель роста на год» — и за вечер получила готовую презентацию. Выглядело убедительно: рост с текущего плана до целевой цифры, разбивка по кварталам, красивые графики. Цифры совпадали с реальной задачей компании: цель совета директоров была в 2,4 раза выше текущего плана — 108 млн ₽ в год (без роста, ровно оборот ×12) против 260 млн ₽ цели. Разрыв огромный, и модель ИИ бодро нарисовала, как его закрыть за счёт «усиления всех каналов на 30-40%». На совете директоров план приняли предварительно. Через неделю Марк задал вопрос, который снёс презентацию: «Я не говорю, за счёт чего. Я хочу понимать, за счёт SEO он даст больше лидов или за счёт SMM?». Ответа в модели не было — только агрегированная цифра роста без механики. Неделя 2: что сломалось Читайте внимательно: у вас сломается там же. Это не наша особенность, а свойство самого подхода. Моя ошибка тут простая, и я увидел её не сразу: я поставил машине задачу целиком — «построй модель», — вместо того чтобы спросить, из чего эта модель складывается. При детальной проверке всплыло три проблемы разом. Во-первых, модель не различала выручку и авансы. В контрактах на услуги аванс — 37-40% от суммы, остальное поступает по факту закрытия проекта. ИИ считал «пришедшие деньги» выручкой текущего месяца, из-за чего кассовый разрыв на бумаге не был виден вообще. Во-вторых, в модели не был заложен бонусный фонд менеджеров по продажам. Такие бонусы обычно составляют 5-8% от закрытой сделки. При обороте 9 млн ₽/мес это 450-720 тыс ₽/мес искажения прогноза операционной прибыли (оценка) — модель считала «чистую» выручку без вычета премий, и итоговая маржинальность выглядела на бумаге выше реальной. В-третьих, прогноз роста на 40% по каналам был просто утверждением без обоснования — модель не связывала рост с конкретными действиями (бюджетом на рекламу, числом новых менеджеров, сроками найма). Где ломается: ИИ звучит убедительно даже там, где врёт в цифрах — он не сверяет себя с реальностью, если его не попросить об этом отдельно. Наш вывод после недели: любую модель, построенную ИИ с нуля, нельзя ставить на совет директоров без ручной сверки хотя бы трёх точек — кассовый разрыв, бонусный фонд, механика роста по каналам. Похожая история с надзором за автоматизацией уже разбиралась отдельно: «Если бы я не пришёл, ничего бы не произошло» — про то, что любой автоматический процесс без точки контроля человека рано или поздно начинает врать красиво, а не грубо. Неделя 3: цели стратегического планирования и вопрос «за счёт чего» Здесь я назову вещь своим именем: умение спросить у машины «за счёт чего» и проверить три допущения руками — это управленческий навык, такой же обязательный, как чтение отчёта о прибыли. Руководитель, который им владеет, стоит дороже того, кто умеет только утвердить красивый слайд. Вам этот навык понадобится в любом случае — купите вы агента или нет. Главный вопрос, которому стоит научить и себя, и свою команду: за счёт чего именно вырастет эта цифра. Без ответа любой план — пожелание. Мы откатились на ручной пересчёт — без права на автопилот. Марк на планёрке произнёс фразу, которая стала внутренним стандартом: «Ты должна знать юнит-экономику каждого направления как свои пять пальцев. Сколько зарабатываем, какая маржа, какие точки бизнеса. Это база, база, база». Подробнее о том, как строить систему учёта, которая не зависит от памяти одного человека, — в разборе контроля дебиторки и денежных показателей . Заодно вскрылась вторая проблема, не связанная с ИИ напрямую: SEO-специалист не мог назвать конкретные источники лидов из органического поиска — аналитика не отслеживала связку «запрос → страница → продажа». Без этой связки любая ИИ-модель роста по каналам была фикцией: нечего было закладывать в формулу — классический разрыв, который отдельно разобран в статье про лиды, которые не доходят до продаж . Собственник предложил новую структуру стратегии, которую мы и взяли за основу дальше: сначала совокупная картина на год (доля лидов по каналам, конверсия по каждому), потом детализация по годам с фиксацией прогресса — например, «в 2025-м было 5% SEO-лидов, в 2026-м стало 35%», и только после этого — тактические детали. Никаких смешанных годовых и месячных цифр на одном слайде. ИИ-связка: формула вместо мёртвых цифр Ключевая идея, которую вам стоит забрать: просите машину выдавать формулу, а не результат. Формулу вы проверите, число — нет. К четвёртой неделе стало ясно: главная проблема не в том, что ИИ считает, а в том, что план — статичен. Стратегия писалась один раз в квартал и морально устаревала через месяц-полтора, особенно если внешние условия (спрос, курс, законодательство) двигались быстрее плана. Переписывать презентацию заново — трата целого дня аналитика каждый раз. Решение: заменить фиксированные цифры формулами. Если темп роста — плюс 5% ежемесячно, план должен пересчитываться сам при загрузке факта за месяц, а не переписываться вручную. Схема конвейера получилась такая: Google-таблица с фактическими данными (выручка по каналам, конверсия, авансы) → скрипт раз в неделю по расписанию дёргает вебхук → дешёвая модель пересчитывает прогноз по формуле роста и подсвечивает отклонения → раз в две недели дорогая модель проверяет, не сломались ли допущения → итог попадает в ту же таблицу отдельным листом, который смотрит финдиректор по четвергам вместе с коммерческим отчётом. Пример ответа модели: Проверка по формуле: 9 000 000 ₽ × (1 + 0,05) = 9 450 000 ₽ — план на следующий месяц. Аванс: 9 450 000 ₽ × 0,38 = 3 591 000 ₽, остаток по факту закрытия проекта — 5 859 000 ₽. Именно эту арифметику и делает дешёвая модель за секунды вместо ручного пересчёта в Excel. Дешёвая модель хороша именно тут: задача — арифметика по чёткой формуле, а не поиск смысла. Она не рассуждает «почему», она считает «сколько». За рассуждение отвечает второй промпт — уже на дорогой модели, раз в две недели, в роли внутреннего критика. Пример ответа модели: Проверка цифры: 6% от 9 450 000 ₽ прогнозной выручки = 567 000 ₽ — именно эту сумму дорогая модель и указала как невычтенный бонусный фонд. Без этой проверки план на совете директоров выглядел бы на 567 000 ₽ прибыльнее, чем есть на самом деле. Инженерная обвязка простая и сознательно небольшая: Google Apps Script по расписанию (раз в неделю для первого промпта, раз в две недели для второго), вызов через HTTP к API модели, запись ответа в отдельный лист таблицы. Ошибка вызова (таймаут, лимит токенов) пишется в тот же лист красной строкой с меткой времени — если строка не обновилась за неделю, значит скрипт упал, и это видно на глаз без отдельного мониторинга. Перезапуск — вручную, кнопкой в меню таблицы: для отдела из 8 человек этого достаточно. Недели 5–6: учим агента на своих кейсах Тот момент, где ваша специфика начинает работать на вас: машина, обученная на ваших случаях, становится полезнее любого универсального решения. Параллельно шла вторая линия — не просто пересчёт цифр, а модель, которая училась бы отличать реалистичный сценарий роста от красиво звучащего, но необоснованного. Внедряли поэтапно, без забегания вперёд: сначала обучили нейросеть на реальных данных — 40 исторических кейсов сделок с валидацией менеджерами (было это реалистично или нет, и почему), потом протестировали на контролируемом сегменте из 5 000 записей, и только после этого начали масштабировать на весь портфель. Разметка 40 кейсов обошлась в 1,5-2 доллара за кейс — итого 60-80 долларов на весь пилот. Дёшево по сравнению с ценой одной ошибки в квартальном плане: одна только невычтенная премия менеджеров, как показал пример выше, искажала прогноз на 567 тыс ₽ в месяц. Правило на будущее: дёшево и качество приемлемое — берём в работу. Дорого и качество всё равно не дотягивает — не тащим в продакшн, ищем другой путь. Что показали цифры за квартал Сравните со своими: важна не абсолютная величина, а то, стали ли ваши планы точнее. Показатель Значение Стратегическая цель роста к текущему плану ×2,4 Доля SEO-лидов, 2025 → 2026 5% → 35% Авансовый платёж от суммы контракта 37-40% Целевой темп роста в формуле +5% в месяц Кейсов для обучения агента / тестовая выборка 40 / 5 000 Стоимость разметки одного кейса $1,5-2 На диаграмме ниже — рост доли SEO-лидов в общем потоке заявок за год, тот самый прогресс, который потом закладывали в формулу пересчёта плана. 2025 5% 2026 35% Экономика: что это стоит и что даёт Полная раскладка цены — в отдельном разборе: сколько стоит автоматизация стратегического планирования , с разделением разовых затрат и ежемесячных. Прикиньте на своей команде: сколько человеко-часов уходит у вас на квартальное планирование сейчас. Настройка связки заняла ~10-15 часов аналитика плюс разметку данных (60-80 $, ≈5-7 тыс ₽) — это разовые затраты; эксплуатация — несколько запросов к моделям в неделю, дешевле подписки на любой BI-сервис; эффект — пересчёт плана сократился с 6 часов до 1 часа в неделю, а агент-критик поймал невычтенный бонусный фонд на 567 тыс ₽/мес, который иначе ушёл бы в план незамеченным (оценка). Ставка настройки — 1500 ₽/час (это работа аналитика или финдиректора, не рутинная задача линейного менеджера): 10 ч × 1500 ₽ = 15 000 ₽, 15 ч × 1500 ₽ = 22 500 ₽. Вместе с разметкой данных суммарные расходы на внедрение — 20-30 тыс ₽ разово. Результат считаем отдельно от эффекта самой стратегии: рост выручки — заслуга канала и продаж, а не инструмента пересчёта. Отделить вклад именно ИИ-связки от вклада более точной SEO-аналитики (см. раздел «Неделя 3») тоже нельзя — обе меры внедрялись параллельно. Честно можно посчитать только то, что не зависит от стратегии в целом: скорость пересчёта. Ручной пересчёт плана при поступлении новых данных занимал у финдиректора около 6 часов каждый раз, когда менялись входные цифры. С формулой и агентом-критиком на это уходит около 1 часа проверки в неделю. Формула для своего расчёта: (часы ручного пересчёта в неделю − часы с формулой и агентом) × ваша ставка в час × 4 недели в месяце = экономия в месяц. В нашем случае: (6 ч − 1 ч) × 1500 ₽/час × 4 = 30 000 ₽ в месяц — то есть 7-8 тыс ₽ в неделю рабочего времени финдиректора. При разовых затратах на внедрение в 20-30 тыс ₽ окупаемость связки по времени — меньше месяца эксплуатации, без учёта того, что план больше не расходится с реальностью на 2,4 раза незамеченным. Что мы не считаем эффектом: сам рост выручки по стратегии (×2,4 в цели) — это результат работы каналов продаж, а не инструмента пересчёта. Пойманные 567 тыс ₽/мес невычтенного бонусного фонда — это не разовая экономия, а повторяющаяся ошибка, которая раньше проходила незамеченной каждый месяц и теперь ловится автоматически; в доход компании эта сумма не превращается, она просто перестаёт искажать прогноз. посчитайте на своих цифрах часов до, в неделю часов после, в неделю ставка в час, ₽ экономия ≈ {X} ₽ в месяц формула: (часы ручного пересчёта − часы с формулой и агентом) × ставка × 4 недели На диаграмме — сколько времени финдиректор тратила на пересчёт плана вручную и сколько уходит теперь. 6 ч было 1 ч стало Время на пересчёт плана при поступлении новых данных: было ~6 часов вручную при каждом изменении входных цифр, стало ~1 час в неделю на проверку с формулой и агентом-критиком. Отдельно — цена невычтенного бонусного фонда, которую поймал агент-критик: 6% от 9,45 млн ₽ прогнозной выручки — это 567 тыс ₽ в месяц искажения прогноза прибыли. Если бы план с этой ошибкой ушёл на совет директоров, решения по найму и бюджету принимались бы на основе картины, которая на 567 тыс ₽ оптимистичнее реальности. Показатель До (ручной пересчёт) После (формула + агент) Эффект Время на пересчёт плана при новых данных ~6 ч ~1 ч в неделю -5 ч/нед Стоимость этого времени при ставке 1500 ₽/час ~9 тыс ₽ за пересчёт ~1,5 тыс ₽/нед ~30 тыс ₽/мес экономии Невычтенный бонусный фонд в прогнозе не учтён учтён, флаг риска 567 тыс ₽/мес искажения прибыли пойманы Затраты на внедрение (разметка + настройка) — — ~20-30 тыс ₽ разово Окупаемость связки — — <1 месяца эксплуатации Что осталось нерешённым Честная часть — чтобы вы не строили ожиданий на неполной картине. Не всё закрылось за квартал. Не решён вопрос, кто персонально отвечает за проект ИИ-агента — Марк сам признаёт, что боится делегировать и теряет время, но решение так и не принято, а сроки горят. Стратегия по-прежнему требует детализации по каждому рынку отдельно, а не общими цифрами — этого агент пока не умеет, потому что нет размеченных данных по региональным различиям. И главное: формула роста +5% в месяц — это гипотеза, а не константа. Она сама требует пересмотра, если внешние условия (спрос, законодательство, курс) меняются быстрее, чем раз в квартал — а это в 2026 году происходит регулярно. Чек-лист: с чего начать в понедельник Сверить в текущей стратегии годовые и месячные цифры — найдётся минимум одна нестыковка, проверено на практике. Выписать три допущения плана, которые ИИ (или аналитик) обычно забывает: бонусный фонд, авансы vs выручка, ресурс найма под темп роста. Завести таблицу с формулой пересчёта плана вместо фиксированных цифр — хотя бы в Google Sheets, без агента на старте. Собрать 30-50 исторических кейсов сделок с оценкой менеджера «реалистично / нереалистично» — это основа для обучения агента-критика. Назначить день недели для сверки факта с планом (у нас — четверг) и одного ответственного, а не «всех вместе». Не отдавать финальное решение по стратегии модели без прогона через второй промпт-аудит на дорогой модели. Похожий разбор того, как стратегия становится рабочим инструментом, а не презентацией для полки, — в статье «Стратегия как рабочий инструмент» . Что взять вам из этого дневника: начинайте с недельного ритма и одной модели, не пытайтесь сразу построить систему. И держите правило, которое мы вывели болью: машина считает, решение остаётся за вами. Я для себя свёл это к одной строчке и держусь её: считает машина, а допущения раз в неделю проверяю я — руками, по списку из трёх пунктов. Как пройти этот путь без наших ошибок — по шагам в бесплатном курсе для руководителей . ## Почему стратегия компании остаётся на бумаге: пять управленческих ошибок URL: https://davidgerstein.pro/blog/pochemu-strategiya-ne-rabotaet/ Дата: 2026-08-30 Направление: Стратегия Цифры: 40% перевыполнение плана при неверной базе · 37–40% авансов путают с выручкой · доля SEO-лидов выросла с 5% до 35% за год Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. «Стратегия — бумажка, которая устареет через месяц». Слышали такое от своих? Я слышал и, честно говоря, сам так думал, пока не разобрался, почему у нас она действительно устаревала. Если вы открываете файл со стратегией раз в квартал, каждый раз переписываете цифры заново и не можете за минуту сказать, за счёт какого канала придёт рост, — у вас не стратегия, а протокол о намерениях. Он рассыпается на первом же месяце, где факт разошёлся с планом: у нас отдел однажды дал на 40% больше плана, и это оказалось не победой, а диагнозом. Дело оказалось не в стратегии как жанре, а в пяти конкретных ошибках — и все пять исправляются без консультантов. Почему стратегия компании не доживает до конца квартала Потому что план записан фиксированными числами, а не формулой, и никто не пересчитывает его по мере поступления факта. Проверить себя можно за неделю: если отдел перевыполнил план на 40%, а вы не можете назвать канал, за счёт которого это вышло, — база плана посчитана неверно, и цифра в документе ничего не измеряет. Вторая по частоте причина — выручку в отчёте складывают с авансами. В компании на 40 человек авансы дают 37–40% суммы по договору; пока эти две строки слиты в одну, спор о выполнении плана идёт про разные величины и ничем не заканчивается. «Стратегия — это бумажка, которая устареет через месяц» Если так думают ваши люди — они не саботажники, они просто видели десяток таких бумажек. Стратегия компании перестаёт работать не потому, что рынок непредсказуем, а потому что план написан фиксированными цифрами, которые никто не пересчитывает. Отсюда и разброс: документ протухает за один-три месяца, хотя рынок тут ни при чём — дело в формате. Этот разговор у нас с финансовым директором повторялся раз в квартал. «Стратегия — это бумажка, которая устареет через месяц, — говорил он, когда я приносил очередной документ на подпись. — Зачем тратить три недели на план, если через квартал его всё равно перепишут заново?» Аргумент звучал разумно: у компании отдел продаж из 10 менеджеров, оборот около 4 млн ₽ в месяц, средний чек в районе 150 тысяч — и любой скачок спроса, цен на рекламу или новостной повод из внешнего мира сносил план быстрее, чем его успевали согласовать. Он был не одинок. Отдел однажды показал результат на 40% выше запланированного — и вместо радости собственник растерялся: похвалить менеджеров он не мог, потому что сама база плана была рассчитана неверно. При этом собственник направления, который курирует стратегию (в тексте — Марк), формулировал претензию иначе: «Я не говорю, за счёт чего. Пиши тексты или не пиши. Я хочу понимать: за счёт SEO он даст больше лидов или за счёт SMM?» Это два разных упрёка к одной и той же стратегии — и оба справедливые. Пять ошибок стратегического планирования, из-за которых ваша стратегия не работает Отметьте, какие из них есть у вас. Обычно набирается три из пяти. Скептик прав в половине претензий: статичный план и непроверенный ИИ-текст действительно ломают стратегию. Но он ошибается там, где считает, что от документа вообще нет пользы — проблема не в самой стратегии, а в пяти конкретных привычках управления, которые можно поймать за одну неделю. Ошибка 1. Стратегия — список чисел, а не формула У нас, как и в большинстве компаний, годовой план был таблицей с фиксированными цифрами на 12 месяцев вперёд. Изменился темп роста на пару процентов — и весь план летит в корзину: пересчитать по частям нечего, цифры между собой формулой не связаны. У нас план на год стоял неподвижным, пока отдел не обогнал его на 40% — и стратегия перестала быть ориентиром, оставшись просто исторической записью того, что думали в январе. Как это устроено, разобрал отдельно: декомпозиция целей . Ошибка 2. Показатели агрегированы, а не разложены по каналам Фраза «план даст рост на 20%» ничего не говорит о том, что делать в понедельник. Марк формулировал это резко: он не хочет знать общий процент роста, он хочет знать, за счёт какого канала — SEO, Telegram, SMM — этот рост случится, потому что от ответа зависит, кому давать бюджет. Стратегия без разбивки по каналам и рынкам — красивая цифра без управленческого смысла, и именно здесь чаще всего теряются деньги между маркетингом и продажами . Ошибка 3. Выручку путают с авансами Когда в презентации фигурирует «план — 53 млн, а по факту заложено только 22», первый вопрос не «почему отстаём», а «мы вообще сравниваем одно и то же?». У нас в легенде компании авансовые платежи составляют 37–40% от итоговой выручки по договору. Разница между «пришли деньги» и «подписан договор» — это не бухгалтерская тонкость, это дыра в стратегии, если её не проговорить явно. Ошибка 4. Никто не знает свою юнит-экономику «Ты должна знать юнит-экономику каждого направления как свои пять пальцев. Сколько зарабатываем, какая маржа, какие точки бизнеса. Это база, база, база» — эту фразу собственник произносит не как лозунг, а как диагноз: без неё стратегия — это гадание. У нас всплыл частный случай: SEO-специалист не смог назвать источники лидов из органического поиска, потому что аналитика не была настроена на связку «запрос → страница → сделка». Он выполнял свою часть стратегии вслепую — похожая история с недостоверными данными разобрана в тексте о том, как мы поймали Битрикс24 на сдвиге дат . Ошибка 5. ИИ-стратегии верят на слово Текст от нейросети звучит убедительно почти всегда — и именно поэтому он опасен без проверки. Мы прогнали через ИИ мини-стратегию по одному из региональных филиалов — и получили гладкий план, который не учитывал бонусы продавцов и содержал необоснованный прогноз объёма на следующий год. Модель не врала специально, она честно выдала правдоподобный текст. Проблема была не в модели, а в том, что план приняли без пошаговой сверки — это тот же сценарий, что описан в разборе, почему внедрение ИИ не работает , даже когда технически всё запустилось. Если вы насчитали три из пяти — это нормально, и вины вашей тут нет. Я сам подписывал такие планы несколько лет подряд и не понимал, почему к марту документ никто не открывает: списывал на рынок, на сезон, на кого угодно. Моя ошибка была проще: я утверждал таблицу с фиксированными числами и ни разу не спросил, кто и как будет её пересчитывать. Пока этот вопрос не задан, стратегия обречена — независимо от того, насколько толковые люди её писали. Что мы изменили за шесть недель Повторите этот путь — он не требует ни бюджета, ни внешней помощи, только вашего решения изменить ритм. Мы не переписали стратегию — мы заменили её формат и добавили один шаг проверки перед каждым запуском. Из пяти ошибок закрыли три за шесть недель, ещё две потребовали месяца дисциплины. Формула вместо цифры. Вместо «план на год — 50 млн ₽» ввели правило: базовый темп роста +5% в месяц, план пересчитывается автоматически при каждой загрузке факта. Формула словами: план_следующего_месяца = план_текущего_месяца × 1,05. Пример на наших числах: план января — 4 000 000 ₽ → план февраля по формуле — 4 200 000 ₽ → план марта — 4 410 000 ₽, без переписывания документа. Переписывать документ раз в три недели больше не нужно — обновляются только вводные. Разбивка по каналам и рынкам. Для каждого направления зафиксировали долю лидов по источникам с фактом за предыдущий год, чтобы прогресс был виден: например, доля SEO-лидов выросла с 5% в 2025 году до 35% в 2026-м. Без этой цифры «рост на 20%» не значит ничего. Явная привязка терминов. Разделили в отчётности «сумма договоров» и «поступившие авансы» как две отдельные строки, а не одну цифру с пояснением мелким шрифтом. Один ответственный за показатель. По аналогии с правилом бонуса юристам за выигранное дело («бонус — тому, кто официально отвечает за кейс, остальным — отдельное поощрение вне привязки к результату») закрепили за каждым каналом одного явного владельца показателя. Верификация ИИ-стратегии на контролируемом сегменте. Прежде чем распространять план на всю компанию, обучили модель на 40 реальных кейсах с валидацией менеджерами, протестировали на контролируемом сегменте из 5 тысяч записей — и только после этого масштабировали. Еженедельный коммерческий отчёт по четвергам. Блоки: маркетинг, продажи, авансы — фиксированный день, единая таблица, накопление к концу недели. ИИ-связка: пересчитывать, а не переписывать Сколько это стоит на практике — в разборе про автоматизацию стратегического планирования . Ваша цель — чтобы обновление стратегии стоило вам часа, а не двух недель работы команды. ИИ в этой механике решает две разные задачи — и для них нужны две разные модели: дешёвая для рутинного пересчёта формул по факту и дорогая для критики готового плана на пропущенные допущения. Конвейер выглядит так: факт из CRM и таблицы авансов → еженедельный вебхук в Google Sheets → дешёвая модель пересчитывает план по формуле и обновляет строки → раз в месяц дорогая модель прогоняет итоговую мини-стратегию руководителя через роль критика → результат уходит в Telegram-канал руководителей с пометкой «принять» или «на доработку». Модель — дешёвый классификатор (модель попроще из линейки любого крупного провайдера): задача чисто арифметическая, риск ошибки низкий, а частота вызовов высокая — раз в неделю на каждый канал и рынок. Модель — постарше и подороже, уровня reasoning: здесь цена ошибки высокая — план на квартал для целого рынка, а вызов происходит редко, раз в месяц на руководителя. Пример ответа модели на первый промпт: Еженедельный отчёт · четверг, 9:00 1 543 500 ₽ план SEO на месяц (пересчитан) -3,1% отклонение факта от плана 35% доля лидов из SEO в 2026 37–40% доля авансов в выручке Строка отчёта Статус Сумма по договорам отдельная строка Авансы (37–40%) отдельная строка План SEO на месяц под угрозой срыва (-3,1%) Обвязка простая и без экзотики: триггер в Google Apps Script запускается по четвергам в 9:00, тянет факт из amoCRM API через промежуточную вкладку Sheets, вызывает модель по HTTP-запросу, пишет результат в отдельный лист. Если API недоступен или JSON пришёл битым — скрипт не молчит, а кидает сообщение в Telegram-канал с текстом ошибки и номером строки. Перезапуск — вручную одной кнопкой в меню таблицы, без обращения к разработчику. До и после: что показала таблица по четвергам Сравните со своим ритмом: как часто вы возвращаетесь к целям и что при этом происходит с задачами команды. Главный результат — не рост цифр, а то, что стратегия стала видна по частям: за каждым отклонением теперь стоит канал, руководитель и неделя, а не общий процент. Показатель Было (жёсткий план) Стало (формула + разбивка) Доля лидов из SEO 5% (факт 2025 года, зафиксирован в плане) 35% (факт 2026 года, видна динамика по неделям) Доля авансов в отчёте о выручке смешана с суммой договоров в одной строке отдельная строка, 37–40% от суммы договоров Ответственный за показатель канала не зафиксирован явно один явный владелец на каждый канал Частота пересчёта плана раз в квартал вручную раз в неделю автоматически 5% в 2025 35% в 2026 Доля лидов из SEO выросла почти в семь раз — с 5% в 2025 году до 35% в 2026-м, после перехода на еженедельный пересчёт по каналам. Отдельно разошлось непонимание вокруг годового плана. В презентации значилось 53 млн ₽ выручки на год, а в оперативном плане была заложена цифра 22 млн — и полкоманды решили, что план провален вдвое. На деле, если 22 млн — это авансовые платежи, а не подписанные договоры, то при доле авансов 37–40% выручка по контрактам оценивается в 55–60 млн (22 / 0,4 ≈ 55, 22 / 0,37 ≈ 59) — план не провален, а почти выполнен. Спор занял два часа планёрки и решился одним уточняющим вопросом, который никто не задал раньше: «мы про договоры или про деньги на счету?» Экономика: сколько стоит держать стратегию живой Ваши затраты — час в неделю. Цена бездействия — год работы по устаревшему плану, который все давно перестали воспринимать всерьёз. Формула для быстрой прикидки собственного случая: доля зависших сделок × число сделок в месяц × средний чек = потерянная выручка в месяц (оценка) . Подставьте свои цифры вместо наших — и увидите, сколько стоит путаница в отчётности именно у вас. посчитайте на своих цифрах сделок в месяц средний чек, ₽ % зависших сделок потери ≈ {X} ₽ в месяц формула: сделки × чек × доля зависших из-за путаницы аванс/договор; оценка сверху Внедрение: настройка таблицы, вебхука и двух промптов заняла у нас около 25 часов работы (оценка) — по ставке аналитика/инженера 1500 ₽/час это разово около 37 500 ₽ (25 × 1 500 ₽). Эксплуатация: еженедельные вызовы дешёвой модели на 4 направления и ежемесячная проверка дорогой моделью укладываются в несколько сотен рублей в месяц — подробный разбор стоимости токенов и счетов за ИИ есть в отдельном материале о реальных расходах на ИИ . Эффект считаем отдельно от прочих инициатив — только по устранённой путанице выручка/авансы и явной ответственности за канал, без учёта общего роста продаж, который дали другие меры (иначе цифры смешаются и станут неправдоподобными). Пример с подставленными числами: отдел из 10 менеджеров, средний чек 150 тысяч ₽, около 27 сделок в месяц отделом. Если 10% сделок зависает из-за путаницы между авансом и договором — а в наших планёрках так и было, — по формуле выше это 27 × 10% × 150 000 ₽ ≈ 400 000 ₽ в месяц (оценка), которые вовремя не отследили и не поторопили. За квартал набегает больше миллиона. Разовые затраты на настройку (37 500 ₽) при таком эффекте отбиваются меньше чем за неделю применения новой отчётности: 37 500 / 400 000 ≈ 0,1 месяца. Это не значит, что окупилась вся стратегия целиком за неделю — окупился именно инструмент разделения строк «договор» и «аванс», без изменения самой стратегии продаж. Что мы не считаем эффектом: время, которое SEO-специалист и аналитик тратили на разбор путаницы раньше — оно не исчезло, а перераспределилось на другие задачи, и в деньгах мы его не учитываем. Что может пойти не так Формула роста +5% в месяц держится только пока рынок растёт сопоставимыми темпами — при резком спаде спроса или сезонном провале план нужно пересчитывать вручную, а не доверять автоматике вслепую. Разбивка по каналам полезна лишь настолько, насколько корректно настроена атрибуция в CRM — если лид приписан не тому источнику, формула посчитает аккуратно, но неверно. Дорогая модель-критик снижает риск пропущенной ошибки, но не исключает его полностью — раз в квартал стоит вручную сверять её выводы на одном контрольном кейсе. И главное, ради чего это всё. Держать стратегию живой — это отдельный управленческий навык, такой же прикладной, как умение читать отчёт о движении денег. Раньше он сводился к «умею планировать», сейчас в него входит ещё одно: собрать машину, которая пересчитывает план сама, и оставить себе только решение. Руководитель, который так умеет, стоит дороже того, кто раз в квартал сажает команду на две недели переписывания таблицы. Дело не в моде на ИИ, а в том, сколько вашего времени уходит на арифметику вместо управления. Проверьте себя: спросите двух своих руководителей, какая у компании цель на год и что лично они делают для неё на этой неделе. Расхождение в ответах покажет, где ваша стратегия обрывается. Как связать годовую цифру с недельными задачами и держать её живой — механика в бесплатном курсе для руководителей . И короткое напутствие. Ваша стратегия жива ровно до тех пор, пока к ней возвращаются. Не раз в год на выездной сессии, а каждую неделю — коротко, по цифрам, без презентаций. Заведите себе этот ритм: он стоит вам часа и меняет всё остальное. ## Разработка стратегического планирования: цена, механика и наша ошибка URL: https://davidgerstein.pro/blog/stoimost-strategicheskogo-planirovaniya/ Дата: 2026-08-30 Направление: Стратегия Цифры: 120–150 тыс ₽ разово (оценка), 3–5 мес окупаемость (оценка), 1 час вместо 3 дней на пересчёт Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. История о том, как мы чуть не сожгли бюджет, доверив стратегию нейросети целиком. Рассказываю, чтобы вы не повторяли: машина отлично считает и совершенно не отвечает за результат. Разработка стратегического планирования: цена и порядок работ Если у вас план на год написан, а объяснить, за счёт чего берётся цифра, в компании не может никто — вам нужна не очередная презентация, а конвейер пересчёта. Разработка стратегического планирования в таком виде обходится компании среднего размера в 120–150 тыс ₽ разово плюс 4–5 тыс ₽/мес на модель и окупается за 3–5 месяцев, если план пересчитывается хотя бы раз в месяц. Порядок работ, который я вывел дорогой ценой: сначала обучение модели на 40 выверенных кейсах, потом тест на одном направлении, и только потом подключение всей компании. Обратный порядок — сразу на боевых цифрах — стоил нам около 232 тыс ₽, и треть этой суммы оказалась чистой потерей. Ваша роль в готовой схеме одна: проверять допущения, которые машина в план не заложила. Как мы чуть не сожгли бюджет, доверив стратегию нейросети целиком Короткий ответ на вопрос, сколько стоит разработка стратегического планирования: дорого, если начать неправильно — нельзя запускать модель сразу на боевых цифрах компании, сначала её нужно обучить на выверенных кейсах и проверить на контролируемом сегменте, иначе первая версия плана обойдётся в разы дороже второй. Мы это узнали не из статьи, а на своей ошибке — и она стоила примерно 230 тысяч рублей (оценка, в пересчёте на условную компанию), из которых треть — чистая потеря от неправильного порядка действий. Началось всё с простого требования собственника. Марк поставил цель на следующий год — оборот 130 млн ₽. В плане, который лежал у него на столе, была цифра 54 млн ₽. Разница в 2,4 раза, и никто в компании не мог внятно объяснить, откуда она берётся: то ли план считали от суммы договоров, то ли от авансовых платежей, которые обычно составляют 37–40% от итоговой выручки. Марк задал вопрос, который потом стал внутренней поговоркой: «Я не спрашиваю цифру. Я спрашиваю — за счёт чего. За счёт SEO или за счёт SMM?» Ответа не было. Решили: раз человек не может свести план за час, пусть это делает модель. Дальше — ошибка, из-за которой я и пишу этот раздел первым, а не в середине статьи. Команда взялась делать ИИ-модель стратегического планирования для одного из региональных направлений. Разработку синхронизировали с внедрением: модель обучали и сразу же тестировали на реальном плане, без промежуточного контролируемого шага. Результат выглядел убедительно — гладкий текст, обоснованные на вид проценты роста, разбивка по кварталам. Проверка вручную вскрыла две дыры: в расчёте не были учтены бонусы отдела продаж, а прогноз объёма на следующий год был построен на экстраполяции без учёта сезонности. Стратегия «выглядела убедительно, но содержала объективно бредовые вещи» — так это назвал финансист, когда сверял цифры построчно. Похожие истории — когда автоматизация технически работает, но результат оказывается непригодным, — мы разбирали в статье Почему внедрение ИИ не работает, хотя технически всё запустилось . Во что обошлась ошибка Показываю цифры, чтобы вы могли прикинуть свой риск: у нас это были часы команды и почти принятое неверное решение. Прямой ответ: разработка первой, непроверенной версии модели плюс ручной пересчёт после того, как ошибку поймали, обошлись условной компании примерно в 232 тысячи рублей (оценка) — и это без учёта риска, если бы ошибку не поймали вовсе. Раскладка по часам. На разработку первой версии ушло около двух недель работы аналитика и подрядчика — примерно 80 часов по ставке около 2 000 ₽/час (оценка для специалиста уровня стратегического аналитика) — это 160 000 ₽. Когда ошибку нашли, план пришлось пересчитывать вручную: аналитик и руководитель отдела продаж потратили на это по три дня каждый, суммарно около 48 часов по ставке 1 500 ₽/час (оценка) — ещё 72 000 ₽. Итого 232 000 ₽, из которых чистая потеря от неверного порядка действий (сначала внедрение, потом обучение, а не наоборот) — примерно треть, остальное всё равно пришлось бы потратить на первичную настройку. Отдельно — риск, который мы не оплатили деньгами только потому, что ошибку поймали до утверждения плана у собственника. Региональное направление в пересчёте на легенду даёт около 2,7 млн ₽ выручки в месяц (30% от оборота условной компании). Бонусный фонд продавцов там — около 8% от выручки, то есть 216 000 ₽ в месяц. Модель этот фонд в прогноз не заложила. Прими Марк такую стратегию как есть — компания получила бы ежемесячную дыру в бюджете в размере 216 тысяч рублей (оценка), которую заметили бы только по факту первой же выплаты бонусов. Где ломается. Модель, обученная сразу на боевых данных без промежуточной проверки, выдаёт текст, неотличимый от нормальной стратегии: тот же уверенный тон, та же структура разделов — на глаз не различить, где реальный план, а где красиво оформленная ошибка. Отличить ошибку можно только построчной сверкой с фактическими статьями расходов: премии, бонусы, сезонные скидки. Если в компании некому сделать эту сверку — не запускайте автоматизацию, сначала настройте ручной регламент. Что автоматизируется в стратегическом планировании Три вещи, и только они. Сборка данных — план и факт подтягиваются из систем сами, без ручного сведения таблиц. Пересчёт — модель считается по формулам, а не переписывается заново при каждом изменении вводных. Контроль отклонений — расхождение плана и факта выше порога приходит уведомлением, а не обнаруживается на квартальном разборе. Что не автоматизируется: выбор целей, проверка допущений и решение, за счёт чего вырастет цифра. Это остаётся за вами — и попытка отдать это машине описана ниже как наша ошибка. Этапы стратегического планирования: механика по шагам Ваша роль в этой схеме — проверять допущения. Всё остальное можно отдать машине, но именно это оставьте себе. Правильный порядок обратный тому, что мы сделали в первый раз: сначала обучение на выверенных кейсах, потом тест на ограниченном сегменте, и только потом — масштабирование на всю компанию. Это дороже по времени на старте, но дешевле по итоговой стоимости ошибки. Шаг 1. Сбор и разметка эталонных кейсов. Что: 40 реальных решений по планированию за прошлые периоды — с фактическим результатом и объяснением, почему план разошёлся с фактом. Чем: таблица в Google Sheets, где каждую строку валидирует руководитель направления вручную. Куда: эта таблица становится обучающим датасетом для модели. Шаг 2. Тест на контролируемом сегменте. Что: прогон модели не на всей компании, а на одном направлении или выборке из 5 000 записей (сделок, лидов, платежей — в зависимости от того, что кормит модель прогнозом). Чем: та же модель, что пойдёт в продакшн, но с обязательной ручной сверкой каждого выхода с фактом. Куда: результат сравнения — в отдельный лист «расхождения», который смотрит финансист. Шаг 3. Масштабирование. Что: после того как расхождение на тестовом сегменте стабильно укладывается в приемлемый коридор (у нас — не больше 10–15% по ключевым метрикам), модель подключают ко всем направлениям. Чем: тот же конвейер, но с еженедельным автоматическим пересчётом. Куда: сводная таблица стратегии, которую видит собственник по четвергам вместе с коммерческим отчётом. Шаг 4. Регламент проверки допущений. Что: перед каждым показом плана собственнику ответственный аналитик отвечает на три вопроса — учтены ли премии и бонусы, обоснован ли рост чем-то кроме экстраполяции, разбит ли план по каналам, а не только по общей цифре. Куда: чек-лист прикладывается к каждой версии плана. Отдельная деталь, без которой вся механика снова превращается в квартальную презентацию для полки: план должен пересчитываться по формулам, а не переписываться руками. Если темп роста направления — плюс 5% в месяц, формула должна сама пересчитывать плановые показатели при загрузке новых фактических данных, а не требовать, чтобы кто-то раз в три недели садился и переписывал таблицу заново. На числах это выглядит так: база месяца — 9 000 000 ₽, формула «+5% к базе» на следующий месяц сама даёт 9 450 000 ₽, ещё через месяц — 9 922 500 ₽, без единого ручного пересчёта в таблице. Иначе стратегия устаревает быстрее, чем её успевают обсудить — у нас так было: отдел показал результат на 40% выше плана, а похвалить менеджеров не получилось, потому что сам план оказался некорректным ещё до того, как отдел его перевыполнил. Подробнее о том, как сделать стратегию рабочим инструментом, а не презентацией — в отдельном разборе: Стратегия как рабочий инструмент, а не презентация для полки . ИИ-связка целиком: конвейер, промпт, обвязка Возьмите эту схему как основу для вашего случая — подставите свои источники данных и свои горизонты планирования. Связка строится на двух моделях с разной ролью: дешёвая модель делает рутинный еженедельный пересчёт по формулам, дорогая — раз в квартал объясняет, почему план разошёлся с фактом и что с этим делать. Смешивать эти роли не стоит: дорогая модель на еженедельном пересчёте — переплата, дешёвая на квартальном анализе причин — потеря качества. Конвейер по шагам — так это выглядит в виде рабочего листа, который видит аналитик: Конвейер пересчёта стратегии Шаг Периодичность Статус Факт вносится в CRM менеджерами ежедневно Bitrix24-вебхук выгружает воронку в таблицу по расписанию Дешёвая модель пересчитывает план по формулам еженедельно, чт Дорогая модель разбирает расхождения >15% ежеквартально Результат уходит собственнику в Telegram по четвергам Пример промпта для еженедельного пересчёта — привязан к Google Sheets как источнику данных и дешёвой модели (gpt-4o-mini или аналог по стоимости), потому что задача чисто арифметическая и не требует глубокого рассуждения: Пример ответа модели по одному каналу: Инженерная обвязка: таблица Google Sheets — единственный источник правды для факта, Bitrix24-вебхук выгружает воронку в неё автоматически раз в сутки, скрипт по расписанию (Apps Script) раз в неделю по четвергам собирает JSON и отправляет в API модели, результат записывается обратно в лист «Стратегия» с меткой времени. Если API не отвечает или возвращает не-JSON — бот в Telegram шлёт алерт ответственному аналитику, а в таблице остаётся пометка «не обновлено с [дата]», чтобы никто не принял решение по устаревшим цифрам. Раз в квартал тот же конвейер, но с дорогой моделью, получает не только цифры, но и текстовые комментарии менеджеров по красным клиентам — и выдаёт объяснение причин расхождения, а не просто цифры. Где ломается. Если менеджеры не вносят факт в CRM вовремя или вносят с искажениями, вся связка пересчитывает план на основе мусора — модель не отличает достоверные данные от неполных. Мы разбирали эту проблему отдельно: Контроль работы менеджера: дашборд вместо штрафов . Без решённой проблемы с дисциплиной ввода данных автоматизация стратегии — это автоматизация ошибки, просто быстрее. Сколько это стоит на самом деле Раскладка для вашей прикидки — с разделением на разовые затраты и то, что вы будете платить каждый месяц. Для компании масштаба условной — отдел продаж 8 человек, оборот около 9 млн ₽/мес — разовое внедрение обходится в 120–150 тысяч рублей (оценка), эксплуатация — 4–5 тысяч рублей в месяц (оценка). Окупается это за 3–5 месяцев при еженедельном использовании. Отдельно от разовой стоимости внедрения стоит держать в уме и текущие расходы на сами модели в целом — мы разбирали это в статье Сколько на самом деле стоит ИИ в месяц . Этап Что включает Стоимость (оценка) Сбор и валидация 40 эталонных кейсов ручная разметка руководителями направлений, ~1 час на кейс ~40 000 ₽ разово API-обработка кейсов при разметке если часть разметки прогоняется через модель, а не только вручную — типовая цена 1,5–2 $ за кейс (оценка по практике проекта) ≈40 × 1,5–2 $ ≈ 5 000–7 000 ₽ разово Тест на контролируемом сегменте (5 000 записей) прогон модели + ручная сверка расхождений ~20 000 ₽ разово Настройка конвейера (Sheets + вебхук + бот) инженерная обвязка, отладка алертов ~60 000–90 000 ₽ разово Еженедельный пересчёт (дешёвая модель) API-вызовы по расписанию, 4 раза в месяц ~2 500 ₽/мес Ежеквартальный анализ расхождений (дорогая модель) интерпретация причин, объяснение отклонений ~6 000 ₽/квартал Эффект считается не «в целом от автоматизации стратегии», а конкретно от того, что пересчёт перестал требовать ручной работы аналитика при каждом отклонении факта от плана. До внедрения формулы и конвейера пересчёт занимал у аналитика около трёх дней (24 часа) каждый раз, когда план расходился с фактом больше чем на 15% — а с учётом геополитики и сезонности это происходило почти ежемесячно. После — пересчёт по формуле занимает меньше часа, ручная работа остаётся только на этапе ежеквартального разбора причин. На диаграмме ниже — сравнение времени на пересчёт до и после автоматизации. 24 часа было 1 час стало Пересчёт стратегии вручную занимал у аналитика около трёх дней работы (24 часа) при каждом отклонении факта от плана больше 15%; после автоматизации формула справляется меньше чем за час. Формула для вашего случая, словами: (число пересчётов плана в год) × (часы ручного пересчёта минус час на автоматический) × (ваша ставка часа аналитика) = годовая экономия времени. Разделите разовые затраты на внедрение на (годовая экономия ÷ 12) — получите срок окупаемости в месяцах. посчитайте на своих цифрах пересчётов плана в год часов экономится за раз ставка аналитика, ₽/час экономия ≈ {X} ₽ в месяц формула: пересчётов в год × сэкономленные часы за раз × ставка аналитика ÷ 12 месяцев Подставляем свои числа: 12 пересчётов в год × 23 сэкономленных часа (24 минус 1) × 1 500 ₽/час (ставка аналитика, оценка) — это около 414 000 ₽ в год, или примерно 34 500 ₽ в месяц. Берём среднее по разовому внедрению — 135 000 ₽ — и делим на месячную экономию: 135 000 ÷ 34 500 ≈ 3,9 месяца. Отсюда и вилка «3–5 месяцев»: при более скромной ставке аналитика или более редких пересчётах срок сдвигается к пяти месяцам, при более высокой ставке или частых отклонениях — ближе к трём. Разовое внедрение в 120–150 тысяч рублей отбивается меньше чем за полугодие такой экономии, даже без учёта того, что план перестаёт содержать ошибки вроде неучтённого бонусного фонда. Это эффект именно от конвейера пересчёта — не смешиваю его с параллельными инициативами вроде перестройки отчётности по каналам, у той свой отдельный эффект. Где ломается. Если стратегия не разбита по каналам и рынкам, а существует как одна агрегированная цифра — автоматизация бессмысленна, потому что формуле не с чем работать. Это тот же вопрос, что Марк задавал в самом начале: за счёт чего растёт цифра, SEO или SMM. Пока в компании нет отчётности, которая привязывает каждый канал к конкретному результату, автоматизировать нечего — сначала нужна детализация, потом формула. Чек-лист: с чего начать в понедельник Собрать 30–40 реальных решений по планированию за последний год с фактическим результатом — это будущий обучающий датасет, не меньше. Разбить текущую стратегию по каналам и направлениям, а не по общей цифре — без этого формула пересчёта не работает. Проверить, что аналитика связывает источник лида с конкретной продажей — если нет, сначала чинить это, а не автоматизацию плана. Заменить хотя бы одну фиксированную цифру в стратегии на формулу от темпа роста — и проверить, пересчитывается ли она при загрузке новых данных. Назначить день недели и ответственного за проверку допущений модели перед показом плана собственнику — без ручной сверки не запускать. Протестировать конвейер на одном направлении или ограниченной выборке, прежде чем подключать всю компанию. Смотрите, что здесь поменялось на самом деле. Раньше руководителя оценивали по тому, сведёт ли он план. Теперь план сводится за час — и отвечаете вы уже не за арифметику, а за допущения, которые в него зашиты. Читать чужой убедительный расчёт и находить в нём то, чего там нет, — это отдельный управленческий навык, и его придётся освоить. Машина не забыла бонусный фонд из вредности, она просто не знает, что в вашей компании он есть, и сама об этом не скажет. Я после того случая держу к любой принесённой цифре три вопроса: за счёт чего она растёт, что в неё не заложено и кто отвечает, если она не сбудется. Руководитель, который умеет так спросить машину, стоит дороже руководителя, который умеет только утвердить красивую таблицу. Правило, которое я вывел дорогой ценой: машина считает — вы решаете. Как только эта граница размывается, вы получаете красивый план, за который никто не отвечает. Как выстроить работу с моделью правильно — в бесплатном курсе . Ваш чек-лист безопасности: любое число, которое машина выдала как факт, проверяется до того, как попадёт в план. У нас это правило родилось после случая, описанного выше, — и с тех пор ни один подобный промах не повторился. ## Нейросеть для работы с текстом: гайд по Claude — от чата до агентов и MCP URL: https://davidgerstein.pro/operacii/claude-dlya-rukovoditelya/ Дата: 2026-08-29 Направление: Операционное управление Цифры: 6 ступеней возможностей · 3 контура в проде · ~$300/мес за 100% звонков Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваш опыт с нейросетями закончился на «спросил — получил ерунду», вы попробовали не тот инструмент и не тем способом. Это как судить об автомобиле, посидев в нём на парковке. Я тоже начинал с ерунды на выходе. Месяц был уверен, что тема раздута: просишь письмо клиенту — получаешь вежливую пустоту, просишь разбор — получаешь пересказ очевидного. Потом дошло, что дело не в машине. Сегодня Claude у нас не помощник. Он работает: три производственных участка, круглосуточно, с понятной себестоимостью операции. Ниже — что это за инструмент, шесть ступеней его возможностей и на какой застряли лично вы. Нейросеть для работы с текстом: что это даёт руководителю Нейросеть для работы с текстом читает и пишет деловые документы: письма, договоры, расшифровки, протоколы, жалобы. В компании на 40 человек это не помощник в чате, а исполнитель на трёх производственных участках: оценивает 100% телефонных разговоров примерно за $300 в месяц , разбирает документы 79 типов с точностью 85% и собирает управленческую отчётность. Порог входа ниже, чем принято думать: пилот через интерфейс программиста стоит десятки долларов. Дорого обходится не модель, а время руководителя на приёмку в первые месяцы — и именно его надо планировать. Как нейросеть работает с текстом у нас в компании Обзоров «что умеет Клод» в интернете достаточно, поэтому начну не с описания, а с производственных участков: везде на входе текст, на выходе — управленческое решение или документ. Оценка звонков отдела продаж. Раньше контролёр успевала прослушать четверть потока — на большее не хватает рук ни у кого. Сейчас машина оценивает каждый разговор по чек-листу своего типа: 7 139 оценок, около $300 в месяц , охват вырос с 25% до 100%. Доверие настраивалось не верой, а калибровкой на 66 звонках с параллельной ручной оценкой и разбором каждого расхождения. Человек, полный рабочий день ~25% Контур на Claude 100% Разбор входящих документов. Поток 79 типов, которые раньше сортировали и переносили руками. Стартовая точность машины была удручающей — 59%. После работы с эталонной выборкой и правилами её довели до 85%, а полтора часа возни с комплектом сжались до минут . Оставшиеся 15% никуда не делись — их держит человек на приёмке, и это честная часть картины. Протоколы планёрок. Расшифровка совещания превращается в решения, задачи и ответственных. На отдел из 15 человек — порядка 70 часов экономии в месяц (оценка) . Не потому, что протокол долго писать, а потому, что без него половину решений переспрашивают заново. Общее у всех трёх: машина здесь не собеседник, а исполнитель в процессе — с регламентом, ценой операции и человеком, который принимает результат. Как считаются деньги на всё это — в разборе реальных расходов . Справка: что это за инструмент и сколько стоит Claude (по-русски — Клод) сделала американская компания Anthropic; официальный сайт — claude.ai, там же приложения для компьютера и телефона. Про доступ из России скажу честно и без инструкций: напрямую сервис в РФ не представлен, поэтому российский бизнес чаще работает через API — шлюзы и корпоративные контуры. Все наши участки устроены именно так. Специализация — работа с текстом: длинные документы, расшифровки, договоры. Договор на тридцать страниц или часовая расшифровка для него штатная задача. Есть «проекты» — папки с накопленным контекстом, чтобы не объяснять свою компанию заново в каждом чате. Русский язык полноценный, деловой тон держит. Форматов два, и путать их дорого. Чат — работаете вы: бесплатная версия для знакомства, платная — десятки долларов в месяц. API — работают ваши процессы без вас, оплата за объём. Вся автоматизация живёт во втором, и экономика там другая: не подписка, а себестоимость операции. Формат Кто работает Цена Для чего Чат бесплатный вы 0 ₽, лимит объёма знакомство, разовые задачи Чат по подписке вы десятки $/мес ежедневная работа руководителя API, контур машина, вы принимаете за объём: у нас ~$300/мес за 100% звонков регулярные процессы Ещё пара слов о характере инструмента, потому что это влияет на выбор. Anthropic делает ставку на предсказуемость: Claude реже уходит в фантазии на деловых текстах и лучше держится в рамках инструкции. Для развлекательных задач это скорее минус, для писем клиентам и договоров — ровно то, что нужно. И да, «чем отличается от ChatGPT» — вопрос, который задают первым. Отвечаю как практик: для деловых задач рабочие оба, разница между ними меньше, чем разница между внятной и невнятной постановкой задачи. Шесть ступеней. На какой застряли вы Смотрите, вот вся тема на одной лестнице. Каждая следующая ступень требует не более мощной модели, а большей готовности передать ответственность . Ступень Что делает машина Что требуется от вас 1. Тексты Письма, протоколы, ТЗ, разбор жалоб и договоров Внятно поставить задачу 2. Документы Читает PDF, сканы, длинные расшифровки, сравнивает версии Дать файл и вопрос к нему 3. Таблицы и данные Анализ выгрузок, аномалии, формулы, сводные срезы Выгрузку и понимание, что ищем 4. Изображения Читает скриншоты, схемы, фото документов Картинку и контекст 5. Подключения (MCP) Сама берёт данные из ваших систем: диск, таблицы, CRM Решить, какие доступы дать 6. Агентный режим Выполняет многошаговую работу: не «ответь», а «сделай» Регламент, границы и приёмку Первые четыре доступны в обычном чате с первого дня. И вот неприятная правда: подавляющее большинство руководителей застряло на первой ступени — просят тексты, получают тексты, делают вывод об инструменте целиком. Дело не в том, что они не умеют. Дело в том, что первая ступень — единственная, где ничего не надо решать: ни доступов, ни регламента, ни ответственности. Понимать, что можно передать машине, а что нельзя, — это новый управленческий навык. Не технический, подчёркиваю. Управленческий: он про делегирование и границы, а не про кнопки. Ступень 3: таблицы — то, что недооценивают почти все Про тексты знают все, про данные — почти никто. Claude принимает выгрузку из CRM, из учёта, из банка и отвечает на вопросы, ради которых обычно зовут аналитика: где просела конверсия по месяцам, какие клиенты дают 80% выручки, какие строки выбиваются и похожи на ошибку ввода. Пишет формулы для Excel и Google Sheets по описанию на русском — и объясняет чужие формулы, доставшиеся от уволившегося сотрудника. Два правила, которые мы вывели болью. Первое: машине нужна выгрузка, а не доступ «в голову» — данные выгружаем и обезличиваем. Второе: просите показывать логику расчёта, а не только ответ. Одна строка в постановке, а снимает половину рисков. Подробно, с готовыми постановками и разбором аномалий, — в статье про анализ таблиц . Ступень 5: MCP — машина сама ходит за данными Пока вы носите машине выгрузки руками, любая регулярная задача упирается в вас. «Сводка по зависшим сделкам каждый понедельник» означает, что кто-то каждый понедельник делает выгрузку. Автоматизация ломается не об ум машины, а об подноску данных. MCP (Model Context Protocol) — открытый протокол, который Anthropic опубликовала в конце 2024 года и который стал отраслевым стандартом. Аналогия простая: USB для ИИ. Один раз настраиваете коннектор — и машина сама читает нужное из диска, таблиц, календаря, CRM, в рамках выданных прав. Вопрос «какие сделки висят дольше двух недель и у кого» перестаёт требовать выгрузки. Оборотная сторона, которую я говорю всем: каждый коннектор — это выданный доступ, и относиться к нему надо как к доступу нового сотрудника. Права по минимуму, чтение раньше записи, боевые системы — в последнюю очередь. У нас машина читает, но в боевые системы не пишет до сих пор — это решение, а не техническое ограничение. Устройство, сроки настройки и правила безопасности — в детальном разборе MCP . Ступень 6: агенты — от «ответь» к «сделай» Верхняя ступень. В чате машина отвечает на реплику; агент получает цель и сам планирует шаги: читает данные, вызывает инструменты, проверяет промежуточный результат, доделывает. «Собери сводку по недельным продажам, сверь с планом, отметь отклонения больше 15% и подготовь черновик разбора» — четыре шага, которые агент проходит сам. Мой вывод из эксплуатации: агенты не «умнее», они самостоятельнее — и потому требования к постановке растут , а не падают. Агенту нужны границы (что нельзя), бюджет (сколько операций и денег вправе потратить) и точка приёмки. По сути — должностная инструкция. Компании с внятными регламентами встраивают агентов легче: у них половина работы уже сделана. Все три наших контура — это агенты с узкой специализацией; анатомия, инструкция и три типовых провала — в разборе про агентов . И раз уж речь о верхней ступени: у Anthropic есть собственная агентная среда — Claude Code. Родилась как инструмент разработчиков, но переросла в универсального исполнителя, который работает с файлами и системами напрямую. Инструменты этого класса стоят и за нашими контурами. Как выглядит рабочая задача Один пример из контура протоколов — чтобы было видно, чем рабочая постановка отличается от «сделай красиво»: Обратите внимание на «не придумывай». Без этой строки машина услужливо заполнит пропуски — назначит сроки, которых никто не называл. Такие мелочи и отличают работающий контур от красивого демо. Составлять такие постановки — отдельный навык, и в статье я его не преподаю: этому посвящён курс, ссылка в конце. Где ошибается — и где ошибался я Ошибается уверенным тоном. Неверная цифра, несуществующая ссылка на закон, додуманное обещание клиенту выглядят так же гладко, как правда. Частота ошибок невысокая, но место ошибки непредсказуемо — поэтому всё, что уходит наружу, проходит человека. Требует надзора, и это работа. Калибровки, разборы расхождений, обновление правил. Я писал об этом отдельно: автоматизация, которая требует надзора, — это вторая работа . Она легче первой, но она есть, и её надо закладывать в план. Не прощает небрежности с данными. Персональные данные клиентов и сотрудников в публичный чат не идут никогда. Обезличиваем: не «Иванов Пётр, +7 916…», а «клиент К., постоянный, чек 180 тыс.». На качество ответа не влияет, а штрафы за утечки с 2026 года выросли кратно — разбор правовой стороны . Где ломается Самый дорогой сценарий — не ошибка машины, а отсутствие приёмки: текст с непроверенной цифрой ушёл клиенту, потому что «нейросеть же написала». Живой сотрудник ошибается не реже — просто его черновики принято вычитывать, а машинные почему-то нет. Правило простое: у каждого результата машины есть человек с фамилией, который его принял. Как отличить работающий контур от красивого демо Вам будут показывать ролики: агент бронирует переговорку, пишет стратегию, «заменяет отдел». Три вопроса, которыми я пользуюсь сам. Где цифры за месяц, а не за минуту? Демо показывает одну удачную операцию, эксплуатация — распределение: сколько прошло, сколько вернулось на доработку, сколько стоил месяц. Наши 7 139 оценок — это и есть ответ на вопрос «что будет, если гонять каждый день», включая неудобную часть: выяснилось, что обрезанный транскрипт машина оценивает как полный, и это пришлось ловить отдельной проверкой. Кто принимает результат? Если в демо нет человека на приёмке — либо цена ошибки нулевая, либо вам не договаривают. Что происходит при сбое? У настоящего контура есть ответ: очередь повторов, уведомление, деградация в ручной режим. Демо при сбое перезапускают за кадром. Этот же фильтр работает и на себя. Не можете ответить на три вопроса по своему пилоту — он ещё не в эксплуатации, что бы ни показывали слайды. Почему большинство застревает именно здесь — разбор с пятью типовыми ошибками . Кому это пока не нужно Для равновесия — три случая, когда закрывайте вкладку и занимайтесь другим. Если в работе нет текстового потока — писем, документов, расшифровок, отчётов, — выгода будет косметической: нейросеть для работы с текстом окупается объёмом текста, а не самим фактом покупки. Если некому принимать результаты — машина без приёмки не экономит время, а создаёт риск. И если задача звучит как «поднять продажи вообще» — нейросеть не стратегия, она исполнитель: ускорит понятные операции, но не придумает за вас, какие операции нужны. Что сделать сегодня Не внедрять. Не покупать корпоративный тариф. Сделать три вещи за вечер. Первое. Откройте чат и прогоните одну настоящую задачу — не тестовую. Письмо клиенту в сложной ситуации, разбор входящего договора, протокол вчерашней планёрки. Настоящую: с вашим контекстом и вашими требованиями к результату. Второе. Посмотрите на лестницу выше и честно отметьте, на какой ступени стоите. Если на первой — вы не «попробовали ИИ», вы посидели в машине на парковке. Третье. Выберите одну повторяющуюся задачу, которая съедает у вас от получаса в неделю. Это ваш кандидат на вторую ступень, а через пару месяцев — на контур. Дальше механика: данные и таблицы , подключения к системам , агенты . А если хочется не собирать по кускам, а пройти путь по порядку — у меня есть бесплатный курс для руководителей : от разбора собственной рутины до первого работающего контура, без программирования. И главное. Год назад я был там же, где вы сейчас, — с ощущением, что это раздутая тема для айтишников. Сегодня три участка работают без меня, а я занимаюсь тем, чем должен заниматься директор. Разница между этими двумя точками — не в бюджете и не в гениальности. В одном вечере, с которого начинается счёт. ## Разработка финансовой модели вместо таблицы на один раз URL: https://davidgerstein.pro/blog/dinamicheskaya-finmodel/ Дата: 2026-08-29 Направление: Стратегия Цифры: 37–40% аванс от выручки, разрыв плана 2,4×, пересчёт за 1–2 часа вместо 16 часов вручную Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас финмодель делалась один раз — под кредит, под инвестора или просто «чтобы была», — то на вопрос «что будет с прибылью, если завтра ключевой клиент попросит скидку 15%» ответа у вас нет. Есть файл, который никто не пересчитывает: за час не посчитаете, за день не посчитаете, а через неделю финансист вернётся из отпуска и скидку уже дадут без него. У большинства ответ — «никогда», и это не преувеличение. Финмодель делается один раз под инвестора или под кредит, красиво печатается и умирает в папке. А решения потом принимаются на глаз, потому что пересчитывать эту красоту руками никто не станет. Разница между мёртвой таблицей и живой моделью — не в сложности формул. Она в том, можете ли вы задать вопрос «а что если» и получить ответ до того, как ситуация изменится. Что такое разработка финансовой модели Разработка финансовой модели — это сборка расчёта, в котором план задан формулами от факта , а не зафиксированными числами: источник данных (CRM) отдаёт факт, формулы пересчитывают план, а допущения вынесены на отдельный лист и подписаны словами. Первая рабочая версия делается в обычной таблице за вечер, дальше пересчёт занимает 1–2 часа вместо 16 часов ручной пересборки. Порядок сборки: развести строки «сумма договора», «аванс» и «выручка по факту»; заменить числа плана на формулу от факта прошлого периода; разбить план по каналам; назначить день недельной фиксации факта; прогнать допущения через ИИ-аудит перед показом собственнику. Полная сборка со связкой с CRM — 50 000–67 500 ₽ разово, экономия времени аналитика — около 29 000 ₽/мес, окупаемость 2–2,5 месяца. Я сидел на встрече, где собственник условной компании принёс презентацию стратегии на год. Он открыл её на второй странице и спросил: «Это выручка или авансы?» Финдиректор задумался. В компании принято, что аванс — это 37–40% от суммы договора. Если оборот в 9 миллионов рублей в месяц — это авансовые платежи, то полная сумма заключённых договоров за тот же месяц — около 23 миллионов. Если это уже выручка по факту исполнения — то 9 миллионов и есть потолок. Разница между двумя трактовками одной и той же строки — около 14 миллионов рублей в месяц. Ни один план не выдерживает такой неопределённости в базовом определении. Именно с этой путаницы и начинается разговор о динамической финансовой модели: без чёткого разделения понятий любая таблица считает не то, что нужно. Где машина реально помогает в планировании, а где уверенно врёт, — проверял отдельно . Это не разовая накладка. Это симптом таблицы, которая не понимает, что считает. Финмодель, собранная один раз в феврале, к маю уже врёт: изменились каналы, вырос курс закупки, отдел продаж перевыполнил план на 40%, а хвалить некого — сама стратегия оказалась неверной изначально. Переписывать её вручную каждые три недели — это 16 часов работы аналитика при ставке около 1500 ₽/час, то есть 24 000 ₽ каждый раз, когда меняется хоть один канал или курс (оценка). А если рынок штормит сильнее обычного и переписывать план приходится не раз в квартал, а каждый месяц — нагрузка на финансовую функцию утраивается, притом что она и так тонет в текучке. Чем обычная таблица отличается от динамической финансовой модели Классическая финмодель — это таблица с зафиксированными цифрами: план продаж на январь, на февраль, на март. Как только реальность отклоняется от плана хотя бы на один канал — таблица не пересчитывается, она просто становится неправдой. Дальше два варианта: либо её тихо игнорируют, либо кто-то садится и переписывает вручную, теряя день-два. Похожий разрыв между целью и планом — предмет отдельного разбора: в статье о стоимости стратегического планирования показано, как компания получила расхождение в 2,4 раза между целью стратегии и текущим операционным планом. Причина там была не в саботаже — часть цифр считалась в договорах, часть в авансах, часть просто устарела за пару месяцев. Собственник в такой ситуации обычно задаёт один и тот же вопрос — «за счёт чего мы дадим больше?» — и таблица с зафиксированными числами на него ответить не может: она не знает, за счёт какого канала растёт цифра, потому что канал не привязан к формуле, он вписан руками. Динамическая модель отличается одним: цифры в ней — не числа, а формулы, ссылающиеся на факт. Растёт SEO на 5% в месяц — план на следующий месяц меняется сам. Меняется доля авансов — модель это видит и не путает с выручкой. Это не про Excel против сервиса, это про архитектуру: где источник истины, кто его обновляет и что делает с этим формула. Разработка финансовой модели по шагам: от источника факта до формулы Дальше — сборка по шагам. Вам не нужен финансовый директор и не нужна дорогая система: первая рабочая версия делается в обычной таблице за вечер. Нужна дисциплина в одном: отделить факты от допущений. Ниже — последовательность, которую можно повторить с командой из финансиста, аналитика и одного разработчика на стороне (или без него, если хватает Google Apps Script). Зафиксировать источник факта. Продажи и авансы — из CRM (amoCRM/Bitrix24) через API или выгрузку. Лиды по каналам — из сквозной аналитики или рекламных кабинетов. Один источник на одну метрику, без ручного ввода «на глаз». Если CRM сама искажает даты сделок — вся модель наследует эту ошибку; про типичный случай такого сдвига — в разборе, как Битрикс24 подменял даты сделок . Развести понятия. Отдельные строки для «сумма договора», «аванс к оплате», «выручка по факту исполнения». В компании из легенды это даёт разницу около 14 млн ₽/мес — без разведения строк модель врёт по определению. Заложить формулу роста, а не число. Вместо «план на февраль — 10 млн» пишем «план = факт прошлого месяца × (1 + темп_роста)», где темп_роста — отдельная ячейка, которую меняет финансист по факту, а не переписывает весь план. Разбить по каналам и рынкам отдельно. Общий план ничего не говорит о механике. Собственник требует конкретики: за счёт SEO или за счёт SMM. Модель должна показывать долю каждого канала в приросте, а не агрегированную цифру. Настроить еженедельный слепок. Каждый четверг — фиксация факта по трём блокам: маркетинг (лиды), продажи (сделки), авансы (₽). Это не отменяет месячный пересчёт стратегии, а даёт ранний сигнал, если что-то пошло не так внутри месяца. Проверять допущения перед тем, как показывать план собственнику. Не учтены бонусы менеджеров, необоснован скачок продаж — это типовые дыры, которые нужно ловить до совещания, а не на нём. Это ровно то, о чём один раз уже писал коллега в разборе стратегии как рабочего инструмента — там про то, зачем стратегия вообще нужна руководителю среднего звена. Здесь — про то, как сделать, чтобы цифры в ней сами не устаревали. ИИ-связка: пересчёт и аудит допущений Здесь машина даёт вам то, чего у вас скорее всего нет: свежий взгляд на собственные допущения. Вы к ним привыкли, они кажутся очевидными — а именно в них обычно и сидит ошибка, из-за которой модель показывает прибыль там, где её не будет. Формулы делают арифметику. ИИ в этой связке решает две задачи: объясняет отклонение простыми словами для еженедельного отчёта и ловит логические дыры в сгенерированной стратегии — тот самый случай, когда прогноз звучит убедительно, но не учитывает бонусы продаж или строится на непроверенном допущении. Схема конвейера: CRM (amoCRM/Bitrix24) → выгрузка факта в Google Sheets по расписанию (Apps Script, триггер по четвергам в 9:00) → формулы пересчитывают план → облачная функция дергает LLM с промптом на анализ отклонений → результат пишется в отдельный лист «Комментарии» → уведомление в Telegram, если отклонение больше 15%. Модель для этого шага — дешёвая (уровня GPT-4o-mini или аналог): задача рутинная, формат жёсткий, риск ошибки невысокий, а гонять её нужно каждую неделю по нескольким менеджерам и трём блокам — дорогая модель тут не окупается. Пример ответа модели: Второй промпт — аудит стратегии, которую сгенерировал сам ИИ (или человек в связке с ИИ) перед показом собственнику. Здесь цена ошибки выше: если пропустить пункт про бонусы или необоснованный прогноз роста, план утвердят и потом будут удивляться, откуда дыра в бюджете. Здесь нужна модель дороже (уровня GPT-4o или o1-подобная): задача — не арифметика, а логический аудит длинного текста, ошибка стоит дороже, чем разница в цене токенов. Инженерная обвязка: Apps Script крутится в самой таблице, вызов LLM — через облачную функцию (чтобы не хранить ключ API в открытом скрипте), лог ошибок пишется в отдельный лист «Errors», при сбое вызова — повторная попытка через 10 минут, при второй неудаче — сообщение в Telegram-канал финансового отдела. Если источник факта (CRM) не отдал данные — модель не запускается вообще, а не считает по пустым ячейкам: это частая причина «красивых, но лживых» отчётов. Что видно в цифрах Сравните со своей ситуацией: скорее всего, вы узнаёте о проблеме в тот момент, когда она уже случилась. Живая модель даёт вам месяц форы — и это единственное, что отличает управление от реагирования. Пример разбивки по каналам, которую собственник требовал от каждого руководителя направления: не агрегированный процент роста, а доля каждого канала в лидах, с фиксацией прогресса год к году. Конверсии по каналам ниже — ориентировочные (оценка), сам факт роста доли SEO с 5% до 35% — по опыту практики. Канал Доля лидов, 2025 Доля лидов, план 2026 Конверсия в сделку (оценка) SEO 5% 35% 18% Telegram 40% 30% 12% SMM 30% 20% 9% PR и прочее 25% 15% 7% SEO 35% Telegram 30% SMM 20% PR 15% Такая таблица отвечает на вопрос собственника «за счёт чего?» — SEO дал самый резкий рост доли (с 5% до плановых 35%), при этом конверсия по нему выше всех остальных каналов (по оценке). Без разбивки по каналам эта информация тонет в общей цифре «плюс 20% лидов». Второй срез — разрыв между целью и текущим планом, который и запускает всю историю с динамической моделью. Ниже — свой пример на цифрах текущей компании, чтобы показать, откуда берётся такой разрыв при путанице с авансами и выручкой. 45 млн план 108 млн цель В текущий операционный план на год заложено 45 млн ₽. Цель по стратегии — 108 млн ₽, это ровно годовой темп при сохранении текущего оборота 9 млн ₽/мес. Разрыв — 2,4×. Дело не в арифметике — план собирался вручную из разных источников с разными единицами измерения (часть строк — по договорам, часть — по авансам), отсюда и просвет между целью и планом. Формула роста при загрузке факта такой разрыв показывает сразу, а не через квартал, когда собственник случайно откроет обе цифры рядом. Экономика: что это стоит и что даёт Прикиньте свою цену вопроса: во сколько вам обошлось последнее решение, принятое без расчёта? Скидка, которую дали на глаз, найм, который не окупился, направление, которое запустили по ощущению. Обычно одна такая история дороже, чем вся работа по сборке модели. Возьмём условную компанию из легенды: 8 менеджеров продаж, оборот 9 млн ₽/мес, средний чек — около 180 тыс. ₽ (около 50 сделок в месяц). Стоимость внедрения (разово, оценка): сборка формул и связки с CRM — 20–25 часов аналитика (~1500 ₽/час) и 10–15 часов разработчика на Apps Script и вебхук (~2000 ₽/час). Итого около 30 000–37 500 ₽ у аналитика плюс 20 000–30 000 ₽ у разработчика — совокупно 50 000–67 500 ₽ разово (оценка). Эксплуатация (в месяц, оценка): вызовы LLM для еженедельного анализа отклонений (4 запуска в месяц на дешёвой модели) и для месячного аудита стратегии (1 запуск на модели подороже) — ориентировочно 2 000–4 000 ₽/мес суммарно на токены. Подробный разбор счетов за ИИ-инструменты — в отдельном материале про реальные расходы на ИИ . Эффект: ручная пересборка стратегии занимала около 16 часов аналитика за раз (оценка). По опыту такой практики это происходило вынужденно каждые три недели — план устаревал из-за смены канала, курса закупки или просто хода месяца. С формулами пересчёт занимает 1–2 часа проверки допущений, значит экономия — порядка 14 часов на цикл × 1500 ₽/час ≈ 21 000 ₽ за один пересчёт. Три недели — это примерно 1,4 цикла в месяц (30 дней ÷ 21 день), поэтому месячная экономия времени аналитика — около 21 000 ₽ × 1,4 ≈ 29 000 ₽/мес. Формула для своего случая: (часы ручной пересборки − часы проверки с формулами) × ставка аналитика в час × число пересчётов в месяц. Отдельно не учтён риск утверждения плана с разрывом в 2,4 раза — в деньгах он точно не измеряется, но стоит дороже одного часа работы, если дойдёт до совета директоров необнаруженным. Что мы не считаем эффектом: время, которое аналитик освободил, но потратил на другую отчётность, а не на новые задачи с добавленной стоимостью, — это перераспределение часов, а не деньги в кассе. посчитайте на своих цифрах часы ручной пересборки часы проверки с формулами ставка аналитика, ₽/час пересчётов в месяц экономия ≈ {X} ₽ в месяц формула: (часы ручной пересборки − часы проверки с формулами) × ставка аналитика × число пересчётов в месяц; оценка сверху При вложениях в 50 000–67 500 ₽ на старте и экономии около 29 000 ₽/мес система окупается примерно за 2–2,5 месяца эксплуатации — и это без учёта снятого риска ошибочного плана, который сложнее оценить в деньгах, но который дороже одного цикла пересборки. Этот эффект — только от самой механики формул и еженедельного слепка. Он не включает эффект от отдельного решения ввести финансиста на сбор дебиторки или от смены схемы мотивации руководителей — это отдельные инициативы с отдельной экономикой, которые нельзя суммировать с эффектом модели напрямую. Если параллельно менялась и мотивация, и модель — сдвиг даёт связка этих мер, а вклад отдельно взятой финмодели выделить в чистом виде нельзя. Где ломается: формула роста работает только пока темп относительно стабилен. Как только выручка направления скачет от 300 тыс. до 9 млн ₽ в разные месяцы, простая экстраполяция «+5% в месяц» превращается в шум. В таких случаях формулу роста нужно заменять на диапазон (пессимистичный/базовый/оптимистичный сценарий), а не на одно число — иначе модель будет уверенно врать, просто по другой формуле. Где ломается ИИ-часть: LLM, сгенерировавшая стратегию, звучит убедительно даже когда пропускает бонусы менеджеров или строит прогноз на неподтверждённом росте. Один раз мы приняли такой прогноз почти без проверки — вернулись к ручному пошаговому пересчёту, чтобы верифицировать каждое допущение, и только потом снова начали доверять автоматике частично. ИИ в этой связке — инструмент проверки и объяснения, а не источник финальных цифр. Мой урок: модель, в которую никто не верил Первая наша модель была технически безупречной и абсолютно бесполезной. Я собрал её сам, гордился формулами — и через месяц заметил, что решения по-прежнему принимаются мимо неё. Спросил напрямую и получил честный ответ: «мы не понимаем, откуда там берутся цифры». Оказалось, я спрятал все допущения внутрь формул. Красиво, компактно и непрозрачно: чтобы понять, почему в феврале прибыль падает, нужно было раскопать три вложенных расчёта. Мы переделали: допущения вынесли на отдельный лист, каждое подписано словами, любое можно поменять и увидеть результат. Если ваша модель существует, но решения принимаются без неё — проблема почти наверняка та же. Проверьте: сможет ли ваш коммерческий директор за минуту найти, где меняется конверсия, и увидеть, что будет с прибылью? Если нет, у вас не инструмент, а документ. Отсюда я и вынес главное. Разработка финансовой модели — это не разовый проект для финансиста, это управленческий навык самого руководителя: держать в голове, откуда берётся каждая цифра, и уметь спросить у собственной таблицы «что будет, если». Осваивается он так же, как чтение отчёта о прибыли, — практикой, а не образованием. Я осваивал его дольше, чем следовало: полтора года считал, что достаточно смотреть на итоговую строку. Мне потребовалось два неверных решения по скидкам, чтобы понять простую вещь — итоговая строка не отвечает ни на один вопрос, который на самом деле задаёт собственник. Юнит-экономика как основа, без которой формулы бессмысленны Динамическая модель пересчитывает верхнеуровневые цифры правильно только если знает маржу и точки экономики на уровне направления. Без этого формула роста в 5% в месяц может расти при падающей марже — и план будет «зелёным», пока касса не покажет обратное. Собственнику стоит требовать от каждого руководителя направления знание юнит-экономики буквально наизусть: сколько зарабатывает направление, какая маржа, какие где растёт и где проседает — это база, без которой любая динамическая модель считает красивые, но пустые числа. Похожая логика разбора по разрывам — в материале о том, где теряются деньги между лидами и продажами : без верных единиц измерения на каждом шаге воронки любая модель считает красиво, но неправильно. Чек-лист: с чего начать разработку финансовой модели в понедельник Порядок для вас — от простого к сложному, каждый пункт можно сделать за один подход. Развести в текущей таблице строки «сумма договора», «аванс», «выручка по факту» — если сейчас это одна строка, разрыв в трактовке уже где-то есть. Заменить хотя бы одну зафиксированную цифру плана на формулу от факта прошлого периода — начать с одного канала, не с всей модели сразу. Назначьте день фиксации факта (четверг — по опыту практики) и три блока: маркетинг, продажи, авансы. Разбейте план по каналам и рынкам отдельно — агрегированная цифра не отвечает на вопрос «за счёт чего». Прогнать текущую стратегию через промпт-аудит на пропущенные бонусы и неподтверждённые допущения, прежде чем нести её на совет. Проверьте, знает ли руководитель каждого направления свою маржу и юнит-экономику наизусть — без этого формула роста бессмысленна. И вот что я вам скажу напоследок. Компании, которые пересчитывают модель раз в неделю, принимают решения быстрее конкурентов — не потому что умнее, а потому что не боятся считать. Каждый пересчёт для них стоит десять минут, а не два дня работы аналитика. Сделайте свою первую версию на этой неделе: три листа, десяток допущений, вопрос «что будет, если». Час работы даст вам то, чего нет у большинства ваших конкурентов, — возможность проверить решение до того, как оно принято. Как довести это до контура, который считает сам и предупреждает об отклонениях, — разбираю по шагам в бесплатном курсе . ## ИИ-агенты для бизнеса: пять элементов рабочего агента и три способа его угробить URL: https://davidgerstein.pro/blog/ii-agenty-dlya-biznesa/ Дата: 2026-08-29 Направление: Операционное управление Цифры: 5 элементов анатомии · 7139 операций за ~$300/мес · ночь без стоп-крана = −$40 Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. «ИИ-агенты» сейчас продают как новую магию: агент сам ведёт клиента, сам закрывает сделки, сам работает вместо отдела. Если вы это читали и подумали «звучит слишком хорошо» — правильно подумали. Но и обратное неверно: агенты работают, у нас их три, и они делают то, что раньше не делал никто. Разница между этими двумя картинами — не в модели и не в бюджете. Она в пяти скучных вещах, которых нет ни в одном рекламном ролике. Про них и поговорим — на разборе агента, который третий месяц крутится у нас в проде. Что такое ИИ-агенты для бизнеса и когда они работают ИИ-агент — это модель, которой выданы цель, инструменты и границы, чтобы делать многошаговую работу без человека на каждом шаге. От чат-бота отличается входом: боту дают реплику, агенту — цель, и шаги он планирует сам. Рабочий агент собирается из пяти элементов: цель с критерием приёмки, инструменты с минимальными правами, явный список границ, бюджет со стоп-краном и человек на приёмке. Модели в этом списке нет — её покупают, а строят как раз эти пять. Агент оценки звонков в отделе продаж на восемь менеджеров сделал 7 139 оценок примерно за $300 в месяц и поднял охват с 25% до 100% потока разговоров. Работают агенты там, где есть поток однотипной работы, формализуемое правило оценки и человек, которому результат нужен регулярно. Нет хотя бы одного признака — задача пока не для агента. Чем агент отличается от чата — на одной задаче Возьмём задачу: оценить звонок менеджера по чек-листу. В чате это делаете вы: открыли транскрипт, вставили, попросили оценить, прочитали. Двадцать звонков — двадцать ручных заходов, и через неделю вы это бросите, потому что у директора есть занятия поинтереснее. Агент делает иначе. Раз в час сам забирает новые записи, определяет тип разговора, выбирает под него чек-лист, оценивает, пишет результат в таблицу, раз в день собирает сводку по менеджерам. Человек появляется дважды: когда задал правила и когда смотрит сводку. Формально разница с чатом — кто нажимает кнопки. По сути — принципиальная: агенту передают не задачу, а процесс , и вместе с ним ответственность за промежуточные решения. Какой чек-лист выбрать. Что делать с обрывком записи. Когда остановиться. Именно поэтому агент без правил опасен ровно настолько, насколько полезен агент с правилами. Пять элементов. Уберите любой — получите инцидент За три месяца эксплуатации я пришёл к тому, что рабочий агент собирается из пяти вещей. Это не теория, каждая строчка оплачена. Элемент Что это Что будет без него 1. Цель + критерий приёмки Что должно получиться и признак, по которому результат принят Агент «работает», результат никому не нужен 2. Инструменты и права Что читает, куда пишет — по минимуму Доступ «на всякий случай» = дыра в безопасности 3. Границы Явный список запретов Машина услужливо сделает то, что вы забыли запретить 4. Бюджет Лимит операций и денег, стоп-кран Ошибка в цикле съедает месячный бюджет за ночь 5. Приёмка Человек и точка, где он смотрит результат Ошибки копятся молча до первого скандала Заметили, чего в списке нет? Модели. Она важна, но её покупают, а не строят, — что именно покупается и на что оно способно, разложено по шести ступеням: от текста и таблиц до подключения к вашим системам . Строят ровно то, что в таблице, и это на восемьдесят процентов управленческая работа, а не программистская. Ту же самую работу вы делаете, вводя в должность нового сотрудника, — просто с людьми она делается на автопилоте, а с машиной приходится проговаривать вслух. Разбор: наш агент по пяти элементам Цель. «Каждый звонок отдела продаж оценён по чек-листу своего типа в течение часа после появления записи». Критерий приёмки закладывался не на глаз: месяц калибровки на 66 звонках с параллельной ручной оценкой, расхождения разбирались по одному — пока не стало ясно, каким пунктам можно доверять сразу, а какие держать под выборочной проверкой. Инструменты и права. Читает записи и транскрипты, пишет в свою таблицу оценок. В CRM не пишет ничего. Это решение, а не ограничение технологии: таблица — черновик, который человек может целиком выбросить, CRM — боевая система, где ошибка расползается по отчётам. Границы. Выглядят прозаично, но каждая появилась после конкретного случая. Не оценивать звонок по обрывку транскрипта — после того как выяснилось, что оборванный на середине разговор машина уверенно оценивает как полный. Не пересчитывать уже принятые оценки задним числом. Не делать выводов о менеджере — только о звонке: обобщения делает руководитель, а не машина. Бюджет. Лимит вызовов в час и денежный потолок в день. Звучит перестраховкой ровно до первого случая: у нас есть разбор ночи, которая стоила минус $40 — зацикленный процесс жёг деньги до утра, и остановил его лимит, а не человек. У сотрудника есть здравый смысл и усталость. У машины нет ни того, ни другого — бюджет заменяет ей и то и другое. Приёмка. Ежедневная сводка руководителю отдела, выборочная сверка с прослушиванием, ежемесячный разбор расхождений. И здесь мой самый неприятный урок, который я расскажу отдельно. Как я угробил идеального агента Технически контур работал безупречно: 7 139 оценок, около $300 в месяц, аптайм месяцами . Охват вырос с четверти потока до ста процентов. Кейс, который не стыдно показывать. А теперь цифра, которую я публикую как прививку: из этих тысяч оценок в управленческое решение — разбор с менеджером, правку скрипта, хотя бы содержательный отзыв — превратилась одна . Одна. Агент исправно выдавал продукт, который никто не превращал в управление. Знаете, что обиднее всего? Все данные для решений лежали в таблице — открывай и разбирай. Не открывали. Это моя недоработка, не машины. Я построил образцового исполнителя и забыл, что у исполнителя должен быть руководитель. Технически — зелёное, управленчески — ноль. И если вы сейчас думаете «ну у меня-то так не будет» — я думал так же, и у меня были все цифры перед глазами. Поэтому единственная метрика, по которой стоит судить агента, — не количество операций, а количество решений, изменившихся из-за его работы . Сводка, по которой неделю не принято ни одного решения, — сигнал тревоги уровня «упал сервер». И назову вслух то, чего мне самому не хватило. Агент требует от директора отдельного умения: регулярно снимать урожай с машины — открывать то, что она произвела, и доводить до решения. Это такой же управленческий навык, как разбор отчётов или планёрка, и держится он на том же — на расписании, а не на энтузиазме. У меня он появился только после этого провала: до него я считал, что достаточно построить контур, а дальше цифры сами кого-нибудь убедят. Не убеждают. Убеждает человек, который в четверг в 10:00 открывает таблицу. Должностная инструкция агента Всё описанное сводится в один документ — системную постановку. Вот каркас; это не наш боевой текст, но структура ровно та же: Сравните с должностной инструкцией контролёра качества — совпадение почти дословное. Это не случайность: агент и есть исполнитель на узкой роли. И отсюда практический вывод, который экономит месяцы: компании с внятными регламентами собирают агентов в разы быстрее. У них инструкция уже написана — осталось перевести её в постановку. Если у вас регламентов нет, попытка собрать агента станет их первой версией. Неприятно, но полезно. Сколько это стоит вам Три числа для масштаба — прикиньте на свой поток. Себестоимость одной оценки — центы: месяц работы на 100% потока звонков обходится примерно в $300. Ручной аналог — контролёр, успевающий за полный рабочий день разобрать четверть потока. И третье, о котором забывают: стоимость надзора — калибровки, разборы, обновление чек-листов — это часы руководителя каждый месяц, и они не бесплатны. Автоматизация, которая требует надзора, — это вторая работа : меньше первой, но в ноль не сворачивается. Контролёр, полный день ~25% потока Агент, ~$300/мес 100% потока Про цену разработки. Узкий агент на готовой модели — дни или недели: код небольшой, дорога управленческая часть. Если подрядчик оценивает «агента» в месяцы и миллионы — либо это платформа, а не агент, либо вам продают то, о чём стоит прочитать разбор про умирающие внедрения . Три способа угробить агента Дальше — три сценария, в которых вы почти наверняка окажетесь, если пойдёте по этому пути. Знать их заранее дешевле, чем узнать на практике. Агент-максималист. Первая версия пытается делать всё: оценивать, обобщать по менеджерам, советовать увольнения. На демо выглядит эффектно, в эксплуатации разваливается — приёмку такого объёма никто не тянет. Лечится сужением: один процесс, один результат, один принимающий. Агент без стоп-крана. Цикл, ретраи, «ещё одна попытка» — и утренний счёт на месячный бюджет. Лечится лимитами, причём лимит должен останавливать, а не ставить в очередь. Агент-сирота. Технически жив, но принимающий человек сменил приоритеты, и результаты копятся в таблице, которую не открывают. Самый коварный: снаружи всё зелёное. Это ровно мой случай, описанный выше. Где ломается Общий корень всех трёх — отношение к агенту как к программе, а не как к исполнителю. Программу написал и забыл; исполнителя вводят в должность, ограничивают в правах, дают бюджет и спрашивают результат. Как только команда начинает относиться к агенту по-сотруднически, максималисты и сироты исчезают сами: появляются те же механизмы, что для людей — роль, руководитель, отчётность. Жизненный цикл: два-три месяца до пользы Если вы решитесь, вот что вас ждёт по календарю. У агента, дожившего до пользы, путь всегда один и тот же, и попытки перепрыгнуть этап возвращают вас на него же, только дороже. Неделя-две: ручной прогон. Процесс гоняется в чате руками, на реальных данных. Здесь выясняется, какие правила вы забыли сформулировать — у нас на этом этапе родилась половина границ, включая правило про оборванные транскрипты. В кабинете такое не придумывается. Неделя-две: теневой режим. Агент работает автоматически, результат никуда не идёт — только сравнивается с ручным. Это этап калибровки, он и отвечает на вопрос «можно ли доверять» цифрой, а не ощущением. Месяц: эксплуатация с плотной приёмкой. Результат используется, человек смотрит всё. Дорого по времени и намеренно: здесь всплывают редкие случаи, которых не было в калибровке. Дальше: рабочий режим. Приёмка сужается до выборочной и до пометок самого агента. Полностью не исчезает никогда. Где ИИ-агенты для бизнеса оправдываются уже сегодня Чтобы приземлить: контроль качества — оценка звонков, писем, чатов по чек-листам; первичная обработка входящего — разбор заявок, классификация, черновик ответа, маршрутизация, у нас это разобрано на потоке заявок ; документы — определение типа, извлечение полей, сверка комплектности, 79 типов с точностью 85% ; отчётность — ежедневные сводки с пометкой отклонений; протоколы — расшифровка совещаний в решения и задачи. Что объединяет эти случаи: везде есть поток однотипной работы, формализуемое правило оценки и человек, которому результат нужен регулярно. Проверьте свою задачу по этим трём признакам. Нет хотя бы одного — она пока не для агента, и это нормальный ответ, а не приговор. И предостережение к подборкам «лучших ИИ-агентов», заполонившим интернет: агента не выбирают из каталога — его собирают под процесс. Готовый «агент-продажник из топ-10» без ваших регламентов остаётся чат-ботом с амбициями. По той же причине осторожнее с модой на локальные агенты на собственном железе: локальность решает вопрос, где живут данные, но не отменяет ни одного из пяти элементов. Ваш первый агент — на этой неделе Начинайте с читающего: он берёт данные и готовит черновик. Испортить может только черновик, поэтому цена ошибки нулевая, а все пять элементов отрабатываются по-настоящему. Кандидаты почти в любой компании одинаковы: ежедневная сводка по продажам из CRM, еженедельный разбор новых договоров, протоколы планёрок — как у нас, с экономией порядка 70 часов в месяц на отдел (оценка) . Ориентир по срокам и деньгам: неделя ручных прогонов, неделя-две теневого режима, первый месяц эксплуатации с плотной приёмкой. Бюджет пилота через API — десятки долларов. Дорогим будет только ваше внимание, и это правильные расходы: именно они превращают игрушку в инструмент. Что сделать сегодня: выберите процесс с потоком, напишите для него четыре строчки — цель, две границы, кто принимает. Если написать не получилось — вы нашли не проблему с ИИ, а дыру в собственном процессе, и это лучшее, что могло случиться с вами за неделю. Как подключить такого исполнителя к вашим системам — в разборе про MCP , а если хочется пройти путь по порядку и с практикой — у меня есть бесплатный курс , там всё разложено по шагам. ## Анализ данных компании через ИИ: срезы, аномалии, формулы Excel — и границы доверия URL: https://davidgerstein.pro/blog/ii-analiz-tablic-i-dannyh/ Дата: 2026-08-29 Направление: Операционное управление Цифры: 4 класса задач на выгрузках · логика расчёта обязательна в каждой постановке · аномалии дат ловились именно так Суммы и примеры пересчитаны на условную компанию — пропорции, механика и выводы реальные. Ответьте себе честно: когда вы последний раз задавали своим данным вопрос, ответа на который не было в готовом отчёте? Не «сколько продали», а «почему у М8 конверсия вдвое ниже — он плохо работает или ему валятся худшие лиды?». Если вы не вспоминаете такого случая за последний месяц — диагноз простой: решения у вас принимаются на ощущениях, а данные лежат мёртвым грузом. И стоят они ровно столько, сколько стоят ошибки, которых можно было избежать. Если давно или никогда — дело не в лени. Дело в том, что раньше между вопросом и ответом стоял аналитик, которого у вас нет. Теперь не стоит. И это, пожалуй, самая недооценённая штука во всей теме: про тексты знают все, про данные — почти никто. Что умеет ИИ в анализе данных компании Анализ данных компании через ИИ — это работа с обычной выгрузкой: вы отдаёте машине CSV из CRM или учётной системы и задаёте вопрос словами, по-русски. На выгрузке сделок за полгода (~1 200 строк) машина уверенно закрывает четыре класса задач: срезы и динамику, поиск аномалий, формулы Excel и Google Sheets по описанию, объяснение чужих расчётов. Цикл «выгрузка → постановка → проверка логики → контрольная сверка» занимает 10–20 минут на вопрос (оценка) — порядка 5–8 часов управленческого времени в месяц, которые раньше уходили на сводные таблицы или на «спрошу потом». Обязательное условие ровно одно: в каждой постановке требовать показать логику расчёта, иначе красивый ответ нечем проверить. Почему это важнее, чем кажется Смотрите, в чём перекос. У руководителя среднего бизнеса данных больше, чем аналитики: CRM пишет каждую сделку, учёт — каждый платёж, телефония — каждый звонок. Аналитика при этом чаще всего нет — есть таблицы, которые никто не открывает, и вопросы, которые некому задать. Разрыв закрывался двумя способами: нанимать (долго и дорого) или не спрашивать (бесплатно и грустно). Появился третий: выгрузка плюс машина, отвечающая на вопросы к данным по-русски. Он не отменяет аналитика на сложных задачах — он закрывает пустоту там, где аналитика не было и не будет. По нашей практике, регулярное «спрашивание данных» меняет и сами совещания: спор мнений заметно чаще упирается в предложение «давайте спросим выгрузку» — а это культурный сдвиг, который стоит дороже сэкономленных часов. Четыре класса задач, которые машина делает на выгрузках Класс Примеры вопросов Что важно в постановке Срезы и динамика Конверсия по месяцам; структура выручки; сравнение менеджеров Точные определения: что считаем сделкой, что периодом Поиск аномалий Ошибки ввода; дубли; сдвиги дат; выбросы сумм Просить не «найди странное», а проверить конкретные гипотезы Формулы и расчёты Формула Excel/Sheets по описанию; проверка чужой формулы Описать словами, что должно получиться, с примером Объяснение данных Что значит эта колонка; почему отчёты расходятся Дать обе версии данных, а не пересказ по памяти Общий принцип для всех четырёх: машина берёт вычислительную и черновую часть, определения и приёмка остаются за вами. Выгрузки — только один из жанров, где это работает: тот же принцип на текстах, документах и подключении к вашим системам . Дальше — три разобранных примера с постановками, которые можно скопировать и переделать под свои данные; в каждом обратите внимание не на «магию», а на то, сколько в постановке управленческих решений — что считать, что исключить, чему не верить. Пример 1: срез по воронке из сырой выгрузки Ситуация, в которой вы наверняка бывали. Исходные данные условной компании: выгрузка сделок за полгода, ~1 200 строк, колонки «дата создания», «стадия», «сумма», «менеджер», «источник». Вопрос владельца: где именно проседает воронка и у кого. Здесь три приёма, которые отличают вашу рабочую постановку от бесполезного «проанализируй таблицу». Первый — правила счёта прописаны явно : что исключаем, к какому месяцу относим. Без них машина примет разумные, но свои решения, и цифра разойдётся с вашей сводной — не потому, что кто-то ошибся, а потому, что считали разное; мы разбирали этот эффект в истории про «CRM врёт» , где три способа счёта давали три разных числа из одних данных. Второй — требование логики к каждой цифре. Третий — разрешение сказать «не могу» : без него машина услужливо посчитает даже то, что считать нельзя. Пример 2: поиск аномалий, который окупил месяц подписки Аномалии — класс, где машина сильна по-настоящему: у неё нет привычки к «так всегда было». Реальный тип находки из нашей практики — даты в CRM, тихо сдвинутые задним числом : доля лидов месяца меняла дату создания, и отчёты расходились в зависимости от дня выгрузки. Поймано именно сравнением двух выгрузок машиной. Обратите внимание на последнюю строку: гипотезы о причинах здесь запрещены сознательно. Причины — работа руководителя с админом системы; смешивание фактов с гипотезами в одном ответе — типичный способ получить убедительный, но неверный вывод. Пример 3: сравнение менеджеров без обид Третий частый запрос — сравнить людей. Здесь машина полезна не скоростью, а дисциплиной: она сравнивает по заявленным метрикам и не подмешивает впечатлений. В условной компании из восьми менеджеров срез по оплаченным сделкам за квартал выглядел так (оценка): Менеджер М1 31% Менеджер М2 25% Медиана отдела 20% Менеджер М8 12% Ценность не в самой картинке — её нарисует любая CRM. Ценность в вопросах вторым шагом: «у М8 низкая доля — проверь, отличается ли структура его сделок по источникам и суммам от медианных». Часто «слабый менеджер» оказывается менеджером, на которого валятся заявки худшего качества, — и это меняет решение с «ругать» на «чинить распределение». Машина делает такие проверки за минуты, и именно они защищают от управленческих выводов по одной цифре — мы писали об этом в разборе про конверсию и менеджеров . Большие выгрузки: как не утопить машину Практические пределы существуют: выгрузку на сотни тысяч строк со всеми колонками загружать не стоит — и не нужно. Рабочие приёмы: сузить период (квартал вместо трёх лет), оставить только участвующие в вопросе колонки, а для по-настоящему больших данных — попросить машину сначала спроектировать агрегацию («какими срезами мне выгрузить это из системы, чтобы ответить на вопрос X»), сделать агрегированную выгрузку и анализировать её. Парадокс, знакомый любому аналитику: сужение данных под вопрос почти всегда улучшает ответ, потому что заставляет сформулировать вопрос. Формулы по-русски: маленькая экономия каждый день Самый недооценённый режим — переводчик между человеческим и табличным. «Сумма оплат по клиенту за квартал, но только со статусом „закрыто" и без возвратов» — машина отдаёт формулу под ваш Excel или Google Sheets и объясняет её по частям. Обратное тоже работает: доставшаяся от уволившегося сотрудника формула на четыре строки вложенных условий расшифровывается в понятный текст за минуту. Мелочь на фоне контуров — но именно эти мелочи возвращают по 10–20 минут несколько раз в неделю, не требуют вообще никакой настройки и, что важно для команды, не пугают: с формул удобно начинать приучение сотрудников к машине — цена ошибки видна сразу, а польза очевидна с первого дня. Про то, как вводить инструменты без сопротивления команды, у нас есть отдельный опыт в разборе внедрения контроля звонков . Где анализ данных компании машине лучше не отдавать Для равновесия — три класса задач, где на сегодня я бы машине выгрузку не доверил или доверил с оговорками. Проверьте, нет ли вашей задачи в этом списке. Точная сверка до копейки. Бухгалтерская сверка, где важна каждая строка из десяти тысяч, — не задача для языковой модели: она может «устать» и обобщить. Для сверок — скрипты и формулы (которые машина, к слову, отлично напишет); ей самой — анализ расхождений, найденных скриптом. Прогнозы. «Спрогнозируй продажи на квартал» машина выполнит охотно и красиво — и это будет экстраполяция без понимания сезонности вашего рынка, запланированных акций и ушедшего ключевого клиента. Прогноз — работа человека с моделью в руках, не наоборот; про уверенные машинные прогнозы у нас есть отдельный скепсис в разборе про стратегию . Выводы о людях. Машина сравнит менеджеров по метрикам — но интерпретация «М8 ленится» против «М8 достаются худшие лиды» требует контекста, которого в выгрузке нет. Правило то же, что в примере 3: машине — проверку гипотез по данным, человеку — выводы о людях. Граница доверия: правила приёмки результата Теперь про то, где вас может подвести. Машина считает быстро и оформляет убедительно — это её сила и ваша опасность: неверный расчёт выглядит так же красиво, как верный. Наши правила приёмки аналитики от машины — те же, что для отчёта младшего аналитика: Логика — обязательная часть ответа. Какие строки вошли, какие исключены, по какой формуле счёт. Строка «покажи логику» стоит ноль, а превращает чёрный ящик в проверяемый расчёт. Контрольная сверка. Одну-две цифры из ответа сверьте с независимым источником — сводной таблицей, отчётом системы. Расхождение — почти всегда разница определений, и её полезно найти до совещания, а не на нём: про честный план-факт у нас есть отдельный разбор. Обезличивание перед загрузкой. В публичный чат данные идут без ФИО, телефонов и паспортов: имена — кодами («менеджер М3», «клиент К17»), анализу это не мешает. Полные данные — только в корпоративном контуре; правовая сторона разобрана в статье про персональные данные и нейросети . Где ломается Главный провал — не ошибка машины, а вопрос без определений. «Какая у нас конверсия?» — вопрос-ловушка: из лидов в сделки или из сделок в оплаты, за какой период, с дублями или без. Машина выберет трактовку сама, оформит красиво, и цифра уйдёт в решения. Лечится привычкой: каждый вопрос к данным начинается с определений — и это дисциплинирует не только машину, но и совещания, где годами спорили о «конверсии», считая её по-разному. Экономика вопроса Посчитаем на условной компании. Аналитика в штате нет; вопросы к данным возникают три-четыре раза в неделю, и раньше каждый решался одним из двух способов: полчаса-час ручной возни руководителя со сводными таблицами — или «спрошу потом», то есть никогда. С машиной цикл «выгрузка → постановка → проверка логики → контрольная сверка» занимает 10–20 минут на вопрос (оценка) — экономия порядка 5–8 часов управленческого времени в месяц только на срезах, не считая находок-аномалий, у которых цена штучная и непредсказуемая: одна пойманная ошибка ввода на крупной сделке окупает годовую подписку. Сравнение с альтернативами тоже честное. Джуниор-аналитик стоит от сотни тысяч рублей в месяц и решает эти же задачи медленнее, зато растёт и берёт на себя постановку вопросов. BI-система даёт красивые дашборды по заранее придуманным вопросам, но молчит на вопросы новые. Машина закрывает ровно зазор между ними: быстрые ответы на новые вопросы без найма — при обязательной вашей приёмке. Это не «или-или»: у зрелой компании со временем есть и BI для регулярного, и машина для нового, и человек для главного. Регулярная аналитика: следующая ступень Всё выше — ручной режим: выгрузил, спросил, проверил. Когда вопросы становятся регулярными — еженедельная воронка, ежемесячный срез по клиентам — подноску данных пора убирать: через MCP-подключения машина читает таблицы и CRM сама, а агент по расписанию приносит готовую сводку с пометками отклонений: сбор отчётности перестаёт быть отдельной ручной работой. Ручной режим при этом не умирает — он остаётся местом, где вы задаёте новые вопросы, прежде чем сделать их регулярными. С чего начать: упражнение на один вечер Ритм, который у нас прижился: раз в неделю — 20 минут «вопросов к данным» по свежей выгрузке, с сохранением удачных постановок в библиотеку. Через месяц-полтора у постановок появляется характер вашей компании — свои определения, свои известные ловушки в данных, свои контрольные цифры, — и это уже половина регламента для будущего агента-аналитика. И назову вещь своим именем. Умение задать вопрос собственным данным и принять на него ответ — это новый управленческий навык, такой же базовый, как чтение отчёта о прибылях. Я считаю его сегодня обязательным: руководитель, который умеет спросить выгрузку и проверить логику ответа, стоит дороже руководителя, который ждёт, пока отчёт принесут. Навык осваивается не курсом, а повторением — примерно за месяц регулярных попыток. Не откладывайте до «когда будет время» — его не будет. Возьмите одну выгрузку, которая у вас и так есть: сделки за квартал, платежи за месяц. Обезличьте. Задайте машине три вопроса по нарастающей: срез («посчитай по месяцам…» — с правилами счёта), аномалии («проверь дубли и пустые суммы»), объяснение («что в этих данных выглядит странно для компании нашего профиля — только наблюдения, без советов»). Час вечера почти гарантированно даст вам две вещи: пару настоящих находок в собственных данных (дубли и пустые суммы есть у всех, кто не искал их специально) — и личное ощущение границы, где машине можно верить, а где нужна сверка. Это ощущение дороже любого чужого чек-листа, включая мой. И маленькое замечание напоследок. Компании, где вопросы к данным задают регулярно, отличаются от остальных не технологиями. Они отличаются тем, что там спор мнений на совещании заканчивается словами «давайте спросим выгрузку» — а не тем, кто громче. Разница в качестве решений накапливается месяцами и становится видна в цифрах через год. Начать этот отсчёт можно сегодня вечером. Если хочется не наощупь, а по шагам — у меня есть бесплатный курс для руководителей : работа с данными там отдельным блоком, с практикой на ваших выгрузках. ## Личный кабинет на 400 тысячах вопросов: красивый интерфейс без работающей логики URL: https://davidgerstein.pro/blog/lichnyy-kabinet-klienta/ Дата: 2026-08-29 Направление: Производственный цикл Цифры: 92 примера на OCR, 27 клиентов в просрочке, 30–40% экономии токенов Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас есть личный кабинет, а клиенты всё равно звонят менеджерам с теми же вопросами — вы платите дважды: за интерфейс и за людей, которых он должен был разгрузить. И дело почти никогда не в дизайне. У нас на столе лежал готовый личный кабинет клиента. База — 400 тысяч вопросов из публичного источника, красивый интерфейс, чат, форма загрузки документов. Разработчик передавал его техническому лиду несколько дней подряд. Система не собиралась. Технический лид сказал фразу, которую я записал дословно: «Получается красивый дом, но дверей нету, как зайти непонятно». Дело было не в коде. Личный кабинет клиента — это стык трёх систем: формы, куда клиент вводит данные, модели, которая их разбирает, и CRM, где живёт сделка. Если стык не проверен, кабинет выглядит рабочим и не работает ни дня. В нашем случае разрыв на одном только этапе «документы запрошены» держал 26–27 клиентов в просрочке одновременно — притом что менеджеры отчитывались, что документы получены. Почему личный кабинет клиента не работает при красивом интерфейсе Потому что интерфейс и логика — разные слои, и проверяют их по-разному. Экран показывают на демонстрации, а данные под ним не сверяет никто. В клиентском портале компании на 40 человек за готовым фасадом лежали пять разрывов логики: документ отмечен «в наличии», но файл не загружен; проверка провалена, но статус не откатился; портал считает рекомендации, но не пишет их в CRM. Эти пять разрывов держали 27 клиентов в просрочке одновременно — притом что менеджеры отчитывались, что всё получено. Первый шаг починки не дизайнерский: выгрузить список документов, отмеченных «в наличии», и сверить с файлами, физически лежащими на сервере. Процент разрыва и есть размер проблемы. До: экран, на который не стыдно позвать инвестора Показать такой кабинет никому не стыдно. Клиент заходит, видит статус заказа, форму загрузки, чат с ответами на частые вопросы — база в тысячи записей закрывала почти любой типовой вопрос без участия менеджера. Сверху — план: обучить алгоритм на 40 живых кейсах, отдать менеджерам на проверку, при подтверждении корректности протестировать на сегменте в 5 000 клиентов и через полгода иметь достаточный массив данных для MVP. План выглядел разумным. Проблема была не в плане, а в том, что данные, которые должны были обучать модель, оказались недостоверными ещё до того, как до модели дошли. Пять поломок логики за красивым фасадом Прежде чем чинить логику, стоит ответить на вопрос, нужен ли вам вообще клиентский портал — там три условия, при которых он окупается. Сверьте со своим кабинетом — эти ошибки повторяются почти в каждом, который я разбирал. Когда мы стали разбирать кабинет по частям, а не смотреть на него целиком, вскрылись пять конкретных разрывов. Первое. Менеджеры отмечали документ «в наличии» в системе, но не загружали файл на сервер. Для клиента и для отчёта менеджера всё выглядело завершённым. Для модели обучения это означало одно: она начинала считать, что проверку можно пройти без документа вообще. Обучающая выборка врала сама себе. Второе. Рекомендации, которые формировал портал после анализа документов, не долетали до CRM автоматически. Собственник обнаружил это случайно, когда сопоставил массив данных портала со списком клиентов, прошедших проверку с первого раза, — и увидел, что связи между двумя базами попросту нет. Третье. Если клиент не проходил внешнюю проверку, система это не фиксировала. Менеджер вручную откатывал сделку назад и должен был удалить дату уже назначенной проверки — и часто забывал это сделать. В CRM оставалась сделка с датой в прошлом и статусом «ожидание», которую никто не видел как проблемную. Четвёртое. OCR-распознавание документов работало отлично внутри самого сервиса модели и разваливалось при вызове через API — повёрнутые документы система не распознавала корректно. Технически это два разных пути обработки одного и того же файла, и никто не тестировал их отдельно. Пятое. Знания о том, как вообще работает кабинет, существовали только в голове разработчика. Ни таблиц, ни регламентов — «падают под запись, под диктофон, и всё». При передаче проекта техническому лиду не оказалось ни одного документа, по которому можно было бы собрать систему заново. Если вы сейчас узнали свой кабинет — выдохните. Я сам собирал его ровно в этом порядке: сначала экран, потом логика, данные в последнюю очередь. Это нормальная последовательность для того, кто делает такое впервые, и на ней спотыкаются все, включая меня. Дорого стоит не то, что вы в неё попали, а то, сколько месяцев вы в ней просидели, не проверив данные. Где ломается. Личный кабинет клиента почти всегда собирают в обратном порядке: сначала интерфейс, потом логика, в последнюю очередь — данные. Красивый экран проходит демонстрацию инвестору и собственнику. Данные, которые он якобы собирает, проверяют только тогда, когда модель начинает откровенно врать. К этому моменту в базе уже месяцы искажённых записей, и их придётся вычищать вручную. Как мы перебирали кабинет по частям Ваш путь будет короче, если начнёте с проверки данных, а не с дизайна. Мы не стали переписывать интерфейс — он был готов. Пересобирали логику по стыкам, в порядке, в котором они ломались чаще всего. Аудит фактических данных. Выгрузили список документов, отмеченных «в наличии», и сверили с файлами, физически лежащими на сервере. Разрыв — процент документов без файла — стал главной метрикой первой недели. Обязательное поле причины отказа. При провале внешней проверки система теперь требует выбрать причину из закрытого списка (недостаток документов, несоответствие данных, иное) и отдельное поле даты неуспешной проверки — отдельное от даты запланированной. Без заполнения сделка не двигается дальше. Автозадача на день проверки. В день назначенной проверки менеджеру автоматически ставится задача с двумя вариантами ответа: пройдена / не пройдена. Если задача не закрыта в срок, уведомление уходит контролю качества, а не остаётся в личных напоминаниях менеджера. Централизация загрузки документов. Вместо разброса по облачным дискам и локальным компьютерам — единая точка загрузки в портале с автоматической сегментацией по типу документа. Многоступенчатый анализ вместо одной модели на всё. Сначала определяется тип документа, затем применяется спецификация под этот тип, при необходимости подключается более мощная модель, финальную проверку всегда делает менеджер. Вебхук из портала в CRM. Рекомендации и статус документа сразу пишутся в карточку клиента — без ручной сверки раз в неделю. На этапе аудита OCR мы не стали гонять всю базу документов через новую логику сразу. Собрали 92 типовых примера, отдали стажёру на ручную проверку результатов и по итогам составили отдельную спецификацию под каждый тип документа — с описанием, что именно сбивает распознавание (чаще всего — вертикальная загрузка и разворот страницы). Похожий путь — от процента ошибок к спецификации по типам — подробно разобран в статье о том, как точность распознавания документов подняли с 59% до 85% . ИИ-связка: конвейер распознавания и рекомендаций Конвейер обработки одного документа выглядит так: загрузка в портал → определение типа документа дешёвой моделью → применение спецификации и OCR → при сложном случае — эскалация на более мощную модель → проверка менеджером → запись в CRM. На диаграмме ниже — относительное время каждого этапа: видно, что три автоматических шага занимают секунды, а «бутылочное горлышко» конвейера — ручная проверка менеджером. Определение типа документа ~2 сек OCR + спецификация по типу ~5 сек Эскалация на мощную модель ~10 сек Проверка менеджером ~3 мин Первый промпт — классификация типа документа и подготовка к OCR. Он должен быть дешёвым: запускается на каждый файл без исключения, поэтому дорогая модель здесь — деньги на ветер. Отправляется через вебхук из Bitrix24 при создании новой записи в разделе документов. Пример ответа модели: Дешёвая модель (условно — Claude Haiku или аналог) достаточно точна для типизации и оценки ориентации. Она не должна принимать решение по существу документа — только маршрутизировать. Второй промпт, для сложных случаев, работает уже на более мощной модели и формирует структурированное описание кейса. Пример ответа модели: Инженерная обвязка. Портал крутится на облачном хранилище с единой точкой загрузки — вместо трёх разрозненных дисков. Все действия конвейера (успешно обработано / ошибка / требует ручной проверки) логируются через прокси-сервис в отдельную таблицу Google Sheets — это дало руководителю видимость того, что раньше видел только разработчик через личный кабинет провайдера модели. Обновление карточки клиента идёт через вебхук в CRM. Для доступа ИИ-инструментов к данным CRM напрямую поднят MCP-сервер поверх базы. Он снижает расход токенов на 30–40% и меньше галлюцинирует — модель получает точный контекст вместо пересказа через промежуточный слой. Подробный разбор счетов за ИИ-инфраструктуру — в статье о реальных расходах на ИИ . После: каким стал личный кабинет клиента Ориентир для вашего кабинета: клиент должен понять статус за секунду и без вопросов к менеджеру. Таблица ниже — сравнение состояния личного кабинета клиента по ключевым узлам логики, до пересборки и после. Узел логики До После Отметка документа «в наличии» Ставится вручную, без проверки файла Невозможна без загруженного файла Фиксация неуспешной проверки Ручной откат, дата часто не удаляется Обязательное поле причины + отдельная дата Уведомление о просрочке Не формируется Автоматически, контролю качества Хранение документов Облачный диск + личный компьютер + мессенджер Единая точка загрузки в портале Связь портал → CRM Отсутствует, сверка вручную раз в неделю Вебхук, обновление в реальном времени OCR повёрнутых документов Не распознаёт Автоматический разворот + спецификация по типу Ниже — то же самое в цифрах: сколько клиентов держало в просрочке узкое место «документы запрошены» до пересборки и сколько остаётся при консервативном сценарии после. 27 в просрочке ≈19 после Оценка, консервативный сценарий: снижение на ~30% за счёт обязательного поля причины отказа, отдельной даты неуспешной проверки и автоматического уведомления контролю качества. Отдельно подчеркну: снижение просрочки в этом узле дало не только исправление личного кабинета. Параллельно в договор внесли срок действия услуги — раньше клиенту говорили «можно начать когда угодно», и он расслаблялся. Это отдельная мера, и её вклад я не смешиваю с пересборкой кабинета: договорный срок сокращает поток новых зависаний, а логика кабинета — снимает потери на уже зависших случаях. Экономика: что стоит пересборка Ваши затраты зависят от того, насколько в порядке данные. Если бардак — считайте вдвое. Возьмём условную сервисную компанию из легенды: отдел из 8 менеджеров, оборот 9 млн ₽ в месяц, средний чек 180 тыс. ₽ — это около 50 сделок в активной работе одновременно (оценка, с учётом цикла сделки ~6 недель). Формула для своего кейса. Риск задержки выручки = доля зависших на этапе документов сделок × количество сделок в работе × средний чек. Потери часов = количество зависших случаев × время ручной обработки одного случая × ставка сотрудника. посчитайте на своих цифрах сделок в активной работе % зависших на этапе документов средний чек, ₽ риск задержки выручки ≈ {X} ₽ в месяц формула: сделки × доля зависших ÷ 100 × средний чек; это оценка риска задержки цикла, а не списанные деньги Если на этапе документов зависает 10% сделок — консервативная оценка по нашей практике — это 5 сделок, «замороженных» без движения: 10% × 50 = 5. В деньгах это риск задержки выручки на уровне 5 × 180 000 ₽ = 900 000 ₽ в месяц (оценка, не потеря — именно риск задержки цикла, а не списанные деньги). Ручная обработка каждого такого зависшего случая — поиск причины, откат сделки, повторный запрос документов — занимает у менеджера примерно 1,5 часа (оценка). При 5 случаях это 5 × 1,5 = 7,5 часа в месяц. По ставке 1 000 ₽/час (оценка, линейная ставка менеджера) — 7,5 × 1 000 = 7 500 ₽/мес прямых часов, которые автоматический откат и обязательное поле причины отказа возвращают менеджерам на продажи. Стоимость внедрения: доработка полей CRM, автозадач и вебхука — это разовые часы разработчика, по нашей оценке 40–60 часов. По ставке разработчика 2 000 ₽/час (оценка) — 80 000–120 000 ₽ разово. Настройка спецификаций OCR под 92 примера документов — ещё 15–20 часов стажёра и разработчика совместно. Если считать окупаемость только по возврату часов менеджеров, разовые ~100 000 ₽ (среднее по вилке) окупаются за 100 000 ₽ ÷ 7 500 ₽/мес ≈ 13,3 месяца (оценка) — и это без учёта риска задержки выручки. На деле экономика доработки держится не на часах, а именно на разморозке зависших сделок: если логика снимает даже треть зависаний (5 → 3, оценка), это 2 сделки × 180 000 ₽ = 360 000 ₽ оборота, разблокированного за один месяц — тогда доработка окупается практически сразу, в пределах одного цикла сделки (~6 недель). Разница между двумя оценками — это разница между «часы менеджеров» и «скорость движения денег», и на своём кейсе стоит считать оба слоя отдельно, не складывая их в одну цифру. Эксплуатация: расход на модели в конвейере распознавания и MCP-сервер — это регулярная статья, которую стоит считать отдельно от разовой доработки; ориентиры по счетам за ИИ — в статье про реальные расходы, ссылка выше. Риск, о котором забывают: история вне портала Проверьте у себя: если клиент написал в мессенджер, а не в кабинет, эта переписка попадёт в его историю? Обычно нет — и вы теряете половину контекста. Второй риск. Пока личный кабинет не был единственной точкой хранения документов, у нас был сотрудник, который вёл клиентов через переписки и локальные папки, не имея доступа в CRM. При передаче его дел выяснилось, что часть истории работы попросту не восстановить — она существовала только в его почте. Централизованный портал решает это только если доступ в него обязателен для всех, кто касается клиента, без исключений «пока разберёмся». Ваш чек-лист на понедельник Прежде чем к нему перейти — про то, чему здесь придётся научиться. Умение сказать «покажите мне данные, а не экран» — это отдельный управленческий навык, такой же базовый, как чтение отчёта о прибыли. Руководитель, который принимает работу по демонстрации, всегда узнаёт правду последним. Руководитель, который умеет проверить систему по её же данным, стоит дороже — и я считаю, что этот навык придётся освоить каждому, кто заводит у себя ИИ. Дальше — пять пунктов, начиная с проверки данных. Выгрузить список документов, отмеченных «в наличии», и сверить с файлами на сервере — процент разрыва даст реальную картину, а не отчёт менеджеров. Добавить обязательное поле причины отказа и отдельную дату неуспешной проверки — без этих двух полей сделка не может закрыться как «отказ». Поставить автозадачу менеджеру на день проверки с бинарным выбором «пройдена / не пройдена» и уведомлением контролю качества при просрочке. Прогнать 5–10 живых кейсов через новую логику вручную, прежде чем включать автоматизацию на всю базу — это дешевле, чем чистить обучающую выборку постфактум. Проверить, есть ли у каждого сотрудника, работающего с клиентом, доступ в общую систему — переписки и локальные папки не восстанавливаются при передаче дел. Свести чек-лист по интеграции портал → CRM в документ, а не диктовать его на планёрке — при передаче проекта устные договорённости теряются первыми. Похожий разрыв между красивым фасадом и рабочей логикой я разбирал на примере CRM — там причиной было не отсутствие данных, а их искажение задним числом, см. разбор про сдвиг дат в Битрикс24 . А если вы только решаете, нужен ли вашей компании личный кабинет вообще, у меня есть отдельный разбор — когда клиентский портал оправдан, а когда нет . Что сделать вам: соберите за неделю список вопросов, с которыми клиенты обращаются к вашим менеджерам. Кабинет должен закрывать первые пять из них — всё остальное вторично, каким бы красивым оно ни было. Как выстроить логику вокруг реальных вопросов клиентов — в бесплатном курсе для руководителей . Чего мне стоил красивый фасад Кабинет, которым я гордился на демо, оказался бесполезным в работе: логика была построена от того, что удобно показать, а не от того, что нужно клиенту. Переделка заняла больше времени, чем первая сборка. Ваш способ этого избежать: до первой строчки кода соберите реальные вопросы клиентов за месяц и стройте от них. Скучно, зато не придётся переделывать. ## Model Context Protocol: как ИИ подключается к CRM, таблицам и диску компании URL: https://davidgerstein.pro/blog/mcp-podklyuchenie-ii-k-sistemam/ Дата: 2026-08-29 Направление: Операционное управление Цифры: 3 слоя архитектуры · права по принципу нового сотрудника · чтение раньше записи Примеры пересчитаны на условную компанию — механика и выводы из живой практики. Спросите себя: сколько раз за последний месяц вы или ваши люди делали выгрузку из CRM, чтобы что-то посчитать? А теперь умножьте на год. Вот это и есть цена того, что машина у вас не подключена к системам, — и платите её вы не деньгами, а вечерами. В гайде по Claude подключения занимают одну секцию. Здесь — по-настоящему: как устроено, что настраивается за час, а что за неделю, где вас ждёт дыра в безопасности и почему главное решение тут принимает не программист, а вы. Что такое Model Context Protocol простыми словами Model Context Protocol (MCP) — открытый стандарт, по которому ИИ-ассистент подключается к системам компании: облачным таблицам, диску, календарю, CRM — и читает оттуда данные сам, вместо ручной выгрузки. Подключение собирается из трёх слоёв: хост (где работает машина), коннектор (переводчик к конкретной системе) и права (что именно разрешено). Готовый коннектор к массовой системе настраивается за час-день, к самописной — пишется за 2–5 дней работы одного разработчика (оценка). Управленческая часть тут одна: решить, что открыть и в каком режиме. Какую проблему решает Model Context Protocol Смотрите, в чём тупик. Без подключений любой разговор с машиной о ваших данных начинается с ручного труда: выгрузить, почистить, вставить, объяснить, что в какой колонке. Для разовой задачи терпимо. Для регулярной — смертельно: «сводка по зависшим сделкам каждый понедельник» на практике означает, что кто-то каждый понедельник делает выгрузку. И этот кто-то — обычно самый занятой человек в компании. Автоматизация ломается не об ум машины. Она ломается об подноску данных. MCP — Model Context Protocol — решает ровно эту проблему. Это открытый протокол, опубликованный Anthropic в конце 2024 года и с тех пор поддержанный остальной индустрией: стандартный способ дать машине доступ к внешней системе. Аналогия, которая нам кажется точной: USB для ИИ. До стандарта каждое устройство требовало свой шнур; после — один разъём подходит ко всему. До MCP каждая связка «модель × система» программировалась отдельно; теперь коннектор пишется один раз — и работает с любым ИИ-хостом, который понимает протокол. Как это устроено: три слоя Слой Что это Решение на этом слое Хост Где живёт машина: приложение Claude, серверный агент, среда разработчика Кто и в каком режиме пользуется подключением Коннектор (MCP-сервер) Переводчик между протоколом и конкретной системой: таблицами, CRM, диском Какие операции вообще возможны Права Учётка и область доступа, под которыми работает коннектор Что из возможного разрешено именно этой машине Вот деталь, которую упускают в восторженных обзорах, а она стоит денег: коннектор определяет возможное , права — разрешённое , и это разные слои. Коннектор к CRM может уметь и читать, и создавать, и удалять сделки — но учётка, под которой он работает у вас, может иметь право только на чтение двух воронок. Правильная настройка живёт на слое прав, и это управленческое решение, а не техническое. Что это даёт руководителю: три сценария Вопросы к живым данным. «Какие сделки висят без движения дольше двух недель и у кого их больше всего?» — машина отвечает по текущему состоянию CRM, а не по позавчерашней выгрузке. Класс задач, где раньше стоял аналитик с выгрузкой, сжимается до вопроса, заданного по-русски. Что важно: вопросы не нужно программировать заранее — в этом отличие от классических интеграций с жёстким сценарием. Документы из папки. Машина читает договор прямо с корпоративного диска: «разбери риски в последней версии договора с клиентом К., сравни с нашей типовой формой». Двух шагов — найти файл и вспомнить, где лежит типовая форма, — больше нет. Регулярные сводки без подноски. Связка с агентом (подробно — в разборе про ИИ-агентов ): по расписанию машина сама собирает данные из подключённых систем и готовит отчёт. Именно на этой связке — подключения плюс агент — построены наши контуры: оценка звонков читает записи и пишет в свою таблицу, разбор документов берёт файлы из потока и возвращает извлечённые поля. Цена ручной подноски данных Чтобы решение о подключениях принималось не на ощущениях, посчитайте свою «подноску». В нашей условной компании еженедельная сводка по воронке до подключения выглядела так: выгрузка из CRM, чистка колонок, загрузка в чат, объяснение контекста — порядка 40 минут работы, 52 раза в год. После подключения тот же вопрос задаётся одной постановкой — около 5 минут на прочитать результат и уточнить (оценка). Выгрузил — почистил — вставил ~40 мин Через подключение ~5 мин посчитайте на своих цифрах регулярных задач с выгрузками в неделю минут на одну подноску данных ручная подноска ≈ {X} часов в год формула: задачи в неделю × минуты × 52 недели ÷ 60 Три задачи по 40 минут в неделю — это больше сотни часов в год, съеденных не анализом, а транспортировкой данных. Против этой цифры и взвешивается неделя на настройку подключений. Как это настраивается: реалистичный план Разберём три типовых случая по нарастанию сложности — с честными сроками из практики. Прикиньте, к какому случаю относится ваша ситуация. Случай 1: массовая система, готовый коннектор — час-день. Облачные таблицы, диск, календарь, популярные таск-трекеры: коннектор ставится из каталога, настройка сводится к авторизации и выбору области доступа. Единственная содержательная работа — решить, что именно открывать: не «весь диск», а папку; не «все таблицы», а нужные. Случай 2: массовая CRM — день-неделя. Коннекторы к популярным CRM — Битрикс24, amoCRM и другим — существуют, но здесь добавляется работа с правами внутри самой CRM: отдельная учётка для машины с ролью «только чтение нужных воронок». Неделю занимает не техника, а согласование: кто отвечает за эту учётку, кто видит журнал её действий, как её отзывают. Случай 3: самописная система — дни разработки. Коннектор — это небольшая программа, которая переводит запросы протокола в запросы к вашей системе. По нашей практике, для системы с готовым внутренним API это дни работы одного разработчика; сложность растёт не от MCP, а от состояния вашего API. Хорошая новость: писать коннектор нужно один раз — дальше он работает с любым хостом. Постановка для машины при работе через подключение выглядит буднично — и в этом суть: данные перестают быть событием: Обратите внимание на строку «ничего не меняй»: она дублирует ограничение прав. Это осознанная избыточность — граница, прописанная и в правах, и в постановке, переживает ошибку в любом одном из двух мест. Что внутри коннектора: для порядка величин Вам не нужно писать коннекторы. Но понимать масштаб полезно — иначе вы не сможете оценить ни срок, ни смету подрядчика. Коннектор — это небольшая программа, которая объявляет машине список своих «умений» (например: «найти сделки по фильтру», «прочитать карточку клиента», «список файлов в папке») и переводит каждое умение в запрос к вашей системе. Умение описывается названием, параметрами и текстом-подсказкой, по которой машина понимает, когда его применять. На этом устройство протокола, по сути, исчерпывается — остальное детали реализации. Отсюда, если вы заказываете коннектор снаружи или ставите задачу своему разработчику, два практических вывода. Первый: смета «коннектор к вашей CRM — три месяца работы команды» должна вызывать вопросы — либо в CRM нет вменяемого API и три месяца уйдут на него, либо вам продают лишнее. Второй: качество коннектора — это качество подсказок к умениям; если машина «не видит» данные или дёргает не тот инструмент, чинится обычно текст описаний, а не код — работа на часы. Безопасность: относитесь к подключению как к найму Теперь то, из-за чего я бы не спал, если бы делал это неаккуратно. Каждый коннектор — это доступ, выданный исполнителю, пусть и нечеловеческому. И решать, какой именно доступ выдать, придётся вам: раздача прав машине — базовый навык руководителя в компании, где работает автоматизация, тот же самый, которым вы решаете, кому из людей открыть договоры, а кому — только их реестр. Мои правила, выработанные там, где машина третий месяц читает рабочие данные: Права по минимуму. Не «доступ к CRM», а «чтение двух воронок под отдельной учёткой». Соблазн выдать пошире «чтобы два раза не ходить» — тот же, что при найме, и лечится так же: расширить доступ на порядок проще, чем разгребать последствия лишнего. Чтение раньше записи. Первые месяцы машина только читает. Право записи выдаётся по одной операции за раз — и в наши боевые системы машина не пишет до сих пор: таблица-черновик, которую человек может выбросить целиком, есть у каждого контура. Это решение, а не ограничение технологии. Учёт подключений. Список «какая машина куда подключена под какой учёткой» — такой же обязательный документ, как реестр доступов сотрудников : без него первый же аудит превращается в археологию. И персональные данные: если система содержит ФИО и контакты клиентов, подключение к ней — это обработка персональных данных со всеми выводами, разобранными в статье про нейросети и персданные . Где ломается Самый опасный сценарий — не взлом, а услужливость: машина с правом записи, получив двусмысленную задачу, «наводит порядок» в живых данных — переименовывает, дозаполняет, архивирует. Каждое действие по отдельности выглядит разумным, объём делает это катастрофой. Потому боевые системы и закрыты на запись: цена двусмысленной формулировки при чтении — плохой отчёт, при записи — восстановление базы из бэкапа. Типовые ошибки внедрения — по горячим следам Эти четыре ошибки я видел столько раз, что рискну предсказать: минимум одну вы совершите. Лучше заранее знать какую. Подключить всё сразу. Ваш энтузиаст за вечер цепляет к машине диск, почту, CRM и календарь. Через неделю никто не помнит, что открыто, через месяц это выясняет проверка. Правильный темп — одно подключение, одна регулярная задача на нём, и только потом следующее: подключение без задачи — это открытая дверь без причины. Одна учётка на всех. Машину подключают под личной учёткой владельца «потому что у него есть все права». Теперь машина видит всё, что видит владелец, включая то, что ей не нужно, а в журналах системы её действия неотличимы от действий человека. Отдельная учётка с именем вроде «ai-reader» решает обе проблемы и стоит десять минут. Доверить машине помнить контекст безопасности. «Мы же ей сказали не трогать боевые данные» — сказали в одном чате, а работает она в десяти. Ограничения живут в правах учётки, а не в памяти разговора; постановка их только дублирует. Любое правило, существующее лишь в виде просьбы к машине, следует считать несуществующим. Забыть про офбординг. Реестр подключений нужен не только для аудита: когда меняется система, увольняется ответственный или отзывается ключ, кто-то должен знать, что перевыпустить и где отключить. У доступа, как у сотрудника, есть не только первый день, но и последний. Когда Model Context Protocol не нужен И для честности — три случая, когда я бы вам это пока отсоветовал. Если регулярных задач с данными ещё нет — сначала месяц поработайте с выгрузками в чате: станет ясно, какие подключения реально нужны, обычно их две-три, а не десять. Если в компании не назначен ответственный за доступы — сначала наведите порядок с человеческими учётками, машинная станет ещё одной строкой в том же реестре, а не первой записью в пустом. И если единственная цель — «чтобы было как в демо у вендора»: интеграция без регулярной задачи под ней — это работающий, но бесполезный кран. Model Context Protocol и агенты: где сила связки По отдельности каждая технология — половина решения. Подключение без агента экономит подноску данных, но вопросы по-прежнему задаёте вы. Агент без подключений умеет действовать, но слеп — работает только с тем, что принесли. Настоящая автоматизация начинается в точке пересечения: агент, который через подключения сам берёт данные, сам выполняет регламент и приносит человеку готовый результат на приёмку. Практическое следствие для очерёдности внедрения: сначала подключения (они полезны сразу и без агентов), затем регламент на ручных прогонах, и только потом агент поверх. Обратный порядок — сначала «купить агента», потом думать, откуда он возьмёт данные, — регулярно встречается в коммерческих предложениях и стабильно заканчивается пилотом, который «почти работает». Подробно про очерёдность и жизненный цикл — в разборе про агентов . С чего начать И последний совет из опыта: заведите привычку раз в квартал перечитывать реестр подключений с одним вопросом — «пользуемся ли мы этим?». Подключения имеют свойство переживать задачи, под которые создавались; неиспользуемый доступ — чистый риск без пользы, и отключается он одной строкой. Порядок, которым шли сами и который советую вам. Первое подключение — к таблицам или диску: безобидно и полезно с первого дня. На нём — одна регулярная задача уровня еженедельной сводки. Месяц спустя — CRM в режиме чтения. Агенты поверх подключений — когда появится задача с потоком, см. разбор про агентов . И держите экономику на виду с первого дня — как мы считаем расходы , чтобы удобство не стало неучтённой статьёй бюджета. Что сделать на этой неделе: возьмите одну задачу, ради которой регулярно делается выгрузка, и посчитайте её по калькулятору выше. Дальше решение примете сами — цифра обычно убеждает лучше любой статьи. А если хочется пройти путь по шагам, с практикой на своих системах, — у меня есть бесплатный курс для руководителей , подключения там разобраны отдельным блоком. И имейте в виду одну вещь. Через год подключённая к системам машина будет такой же обыденностью, как сегодня телефон с почтой. Разница между компаниями будет не в том, у кого она есть, а в том, кто научился ею управлять раньше — и успел за это время перестроить работу. ## Согласование договоров: сколько стоит автоматизация — смета на 32 000 ₽ URL: https://davidgerstein.pro/blog/soglasovanie-dogovorov-stoimost/ Дата: 2026-08-29 Направление: Производственный цикл Цифры: 27 зависших клиентов, 32 000 ₽ на доработку (оценка), 3 неответа = отказ Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы не можете назвать цену автоматизации ни одного своего процесса — ни точную, ни хотя бы порядок, — вы эту автоматизацию не покупаете, вы её опасаетесь. А пока вы опасаетесь, подрядчик называет любую цифру, и вам нечем её проверить. Наш счёт за автоматизацию согласования договоров — 32 000 ₽. Вместе со всеми переделками. Это меньше пятой части одной сделки при среднем чеке 180 000 ₽. И в полтораста раз меньше оборота, который в тот момент стоял у нас без движения из-за пустой строки в шаблоне договора. Раскладку я показываю не ради дешевизны. А чтобы вы видели, из чего цена складывается и в каких местах вас будут пробовать развести на порядок дороже. Откуда взялась цифра Планёрка по средам, отчёт по воронке. Координатор — он держит сроки заказов в голове и в трёх табличках — смотрит на столбец «документы запрошены» и молчит дольше обычного. Потом говорит: «У меня тут 27 клиентов, которые не двигаются вообще. Не неделю, не две. Просто стоят». Первая реакция — «менеджеры не дожимают», почти рефлекс. Стали смотреть по факту: клиенты не отвечают, но просроченными их система не считает. Формально всё в порядке. Причина оказалась смешной в своей глупости: в договоре нет срока действия услуги. Ни строчки. Клиент подписал документ, где не сказано, до какого числа он обязан прислать документы или ответить менеджеру. Юридически — тишина. Системно — тоже: если в договоре нет даты, CRM неоткуда взять точку отсчёта для просрочки. Условная компания из легенды: сервисная, 8 менеджеров в продажах, около 40 человек всего, оборот около 9 млн рублей в месяц, средний чек 180 тысяч, цикл сделки около 6 недель. При таком цикле в работе одновременно держится примерно 75 сделок. 27 зависших — больше трети воронки. По деньгам это не потеря, а заморозка: 27 × 180 000 ₽ ≈ 4,86 млн рублей оборота стоят без движения (часть из них всё равно доедет до финала, просто позже). Сколько стоит автоматизация согласования договоров: смета целиком Решение оказалось скучным до неприличия: вписать в регламент требование указывать срок действия договора для типовых работ, а для нестандартных проектов оставить исключение — не насиловать то, что в шаблон объективно не укладывается. Дальше две статьи расходов, и обе внутренние. Строка сметы Часы Ставка Сумма Юрист: правка шаблонов, архив старых версий, простановка дат в активных сделках 8 1 500 ₽/ч 12 000 ₽ Разработчик: условная логика — срок подставляется в договор по пакету услуг 10 2 000 ₽/ч 20 000 ₽ Новая CRM или платформа — — 0 ₽ Подписка за автоматизацию, ежемесячно — — 0 ₽ Итого разово 18 — 32 000 ₽ (оценка) Смотрите на эту таблицу не по итогу, а по структуре. Десять часов из восемнадцати — программирование, восемь — юрист и регламент. То есть почти половина сметы уходит на то, чтобы решить, что вообще должно быть написано в договоре, и только вторая половина — на то, чтобы машина это подставляла сама. Сначала мы и внедрили руками: юрист правил активные шаблоны, менеджеры проставляли даты в существующих сделках. Разработчик подключился вторым шагом — чтобы срок приезжал в договор из формы, в зависимости от пакета услуг, а не ждал, пока кто-то вспомнит. Дорожает такая смета предсказуемо. Дороже всего — когда вместо доработки регламента вам продают новую систему: к сумме добавляется лицензия, миграция и полгода, пока отдел привыкает. Дальше идут исключения: каждый нестандартный случай, для которого нельзя назвать срок, превращается в отдельную ветку логики и в лишние часы разработчика. И тише всего бюджет съедают согласования — юрист несёт формулировку руководителю продаж, тот собственнику, и восемь часов юриста незаметно становятся двадцатью. Скажу про свою ошибку, раз уж разговор про деньги. Я сам долго смотрел на такие сметы с другой стороны: видел итоговую сумму и торговался по ней, а не по строкам. Я не понимал простой вещи — платят здесь не за код, а за решение, которое кто-то должен принять и подписать. Пока решение не принято, любая сумма выглядит завышенной, потому что непонятно, за что именно. На этом ошибаются почти все, кто заказывает автоматизацию впервые, и я в том числе. Почему в договоре важно прописывать срок действия Дальше стали разматывать, откуда взялась пустая строка. Дело оказалось не только в юристах, которые когда-то делали шаблон. Менеджеры на закрытии сделки сами говорили клиентам: «Не переживайте, можно начать когда угодно, спешить некуда». Это снимает возражение о нагрузке и помогает продать. Но клиент слышит буквально и потом действительно не спешит. А система не подсветит проблему, потому что формально сделка не просрочена: срока-то нет. Срок в договоре — не юридическая формальность, а точка отсчёта для машины. Без неё любой автоматический контроль бессмыслен: нечего сравнивать с сегодняшним числом. Заодно вписали второе условие: три подтверждённых неответа клиента считаются отказом от услуг. Одна строка, а закрывает риск бесконечного зависания без вины компании. Координатор оценил сразу: «Наконец-то будет что показывать в отчёте, а не гадать, жив клиент или просто забыл». Тот же класс сбоя — просрочка, которую система не видит, потому что не от чего считать, — разобран подробнее в тексте про контроль дебиторки, который не зависит от памяти людей . А как согласование ломается уже на финальной проверке — в соседнем разборе . Чем кончится — пока не знаем Честно: финальных цифр по возврату сделок в срок у меня ещё нет. Прошло меньше месяца, а цикл сделки здесь около 6 недель — раньше конца квартала выводы делать рано. По предварительным снимкам статусов зависших уже не 27, но динамику будем смотреть на горизонте квартала. Что можно сказать сейчас: замороженный оборот стал видимым. Раньше система не умела показать, что 4,86 млн рублей стоят без движения. Теперь это строка в отчёте, а не ощущение менеджера, что «что-то как-то не очень». Что мы в эффект не записываем: часы юриста и разработчика — разовая работа, а не освободившееся время, которое можно пересчитывать в деньги каждый месяц. И сокращение числа зависших сделок — не заслуга одной строки: параллельно поменялся скрипт менеджеров на закрытии, и выделить вклад условия про срок из общей связки честно нельзя. Будут цифры за квартал — опубликую, включая неудобные. Читать смету автоматизации по строкам, а не по итогу — это отдельный управленческий навык, и его придётся освоить. Руководитель, который умеет спросить «сколько тут часов того, кто принимает решение, сколько — того, кто закрепляет его в системе, и что мы покупаем в каждой строке», платит за один и тот же результат в разы меньше, чем тот, кто торгуется по конечной сумме. Проверяется навык за один разговор с подрядчиком. Возьмите на этой неделе один процесс, который у вас буксует, и попробуйте назвать его смету в двух строках — часы решения и часы закрепления. Не сойдётся — значит, вы пока не знаете, что покупаете, и торговаться вам нечем. Когда назовут сумму на порядок выше нашей раскладки, просите разложить по пунктам: нормальный подрядчик объяснит, ненормальный заговорит про уникальность вашего бизнеса. Как считать такие проекты и что в них правда дорого — разбираю в бесплатном курсе для руководителей . ## Распознавание документов: как мы снизили ошибки с 20% до 7% на 92 эталонных документах URL: https://davidgerstein.pro/blog/ii-raspoznavanie-dokumentov/ Дата: 2026-08-28 Направление: Производственный цикл Цифры: 92 эталонных документа · ошибки 20% → 7% · токены −30–40% Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Дневник внедрения: как мы запускали распознавание документов на реальном потоке и что из этого вышло. Я вёл эту задачу и полтора месяца был уверен, что она чисто техническая. Если вы собираетесь делать то же самое — читайте про грабли, они здесь подробнее, чем успехи: мои обойдутся вам дешевле, чем ваши собственные. Какую точность даёт распознавание документов На старте доля сбойных комплектов доходила до 20% : модель путала имена с фамилиями и не читала повёрнутые сканы. После доработки на 92 эталонных документах ошибки снизились до 7% . Точность растёт не от смены модели, а от эталонного набора и правил разбора: тот же путь на другом наборе дал переход с 59% до 85% без замены нейросети. Мы сразу запустили распознавание документов — и получили путаницу в именах клиентов Разберём на примере: сервисная компания, отдел продаж из 8 менеджеров, оборот около 9 млн ₽ в месяц, средний чек услуги — 180 000 ₽. Это примерно 50 сделок в месяц на отдел — то есть на каждого менеджера приходится около 6 сделок в месяц, чуть больше одной новой сделки в неделю (цикл сделки — около 6 недель, у каждого менеджера обычно несколько сделок одновременно в работе). Всего в компании около 40 человек. Каждая сделка — это комплект из нескольких документов: удостоверение личности, справка, договор, иногда рукописная форма. Именно на этом потоке мы и включили распознавание документов — с этого стартовал весь разбор ниже. Мы решили не тратить полгода на пилот и запустили распознавание документов сразу на живом потоке. Логика была простая: в интерфейсе Клода мы прогнали десяток сканов — модель прекрасно читала имена, даты, номера документов. Значит, думали мы, через API будет так же. Не было. Через API модель путала имя и фамилию местами, пропускала отчество, а часть сканов, загруженных вертикально (люди фотографируют документы телефоном как придётся), распознавала как случайный набор символов. Координатор производственного цикла получал карточки клиентов, где в поле «фамилия» стояло имя, и разбирался вручную — почему у клиента вдруг «сменилось» отчество между двумя проверками. «Задним числом никто ничего не менял, — говорил он, — просто модель второй раз прочитала документ иначе». Ошибка в имени клиента — это не мелочь. Это переделка карточки, повторная проверка менеджером и, в худшем случае, конфликт с клиентом, который увидел свои данные с ошибкой в личном кабинете. При потоке около 50 комплектов в месяц каждый пятый в первые недели — то есть около 10 комплектов — требовал ручной пересборки: дополнительные 30–40 минут работы менеджера сверх обычных 10–15 минут на проверку (оценка). Скрытая нагрузка на отдел, которую никто не считал при запуске. Почему в чате работало, а через API — нет Ловушка, в которую попадёте и вы, если будете тестировать в чате, а запускать через API: это разные условия, и результат отличается. Я сам в неё зашёл первым: показал руководству прогон в чате, получил «отлично, запускаем» — и потом месяц объяснял, почему на живом потоке всё иначе. Мне это стоило доверия к проекту на старте, вам не обязательно повторять. Разработчик, который вёл эту задачу, сформулировал причину точно: «Получается красивый дом, но дверей нету, как зайти — непонятно». В чат-интерфейсе модель получает не просто картинку, а картинку, уже прошедшую предобработку интерфейса: разворот, обрезку, иногда улучшение контраста. Через API вы отдаёте модели то, что реально загрузили — а грузили документы кто в лежачей ориентации, кто в портретной, кто со смартфона под углом. Вторая причина глубже: одна универсальная инструкция «распознай документ и извлеки данные» работает плохо на разнородном потоке. Паспорт, справка о доходах и рукописная форма читаются моделью совершенно по-разному — разное расположение полей, разный шрифт, разная логика, где искать фамилию. Один промпт «на всё» — это и есть тот самый провал: модель либо перегружена универсальностью, либо теряет точность на нетиповых случаях. Третья причина — организационная, а не техническая: часть менеджеров отмечала документы как «в наличии» в CRM, но не загружала сами файлы на сервер. Модель, которую предполагалось дообучать на этих данных, начинала считать, что клиент прошёл проверку вообще без документов. Это ломало не текущую сессию, а будущее обучение — самую дорогую часть проекта, потому что ошибку в разметке находишь не сразу, а через месяц, когда пробуешь анализировать накопленный массив. Как мы переделали: механика по шагам Ваш путь будет короче, если сразу заложите то, к чему мы пришли через месяц проб. Я закладывал на переделку неделю — ушло больше месяца, и почти всё это время съела не техника, а описание типов документов. Вместо того чтобы чинить универсальный промпт, мы откатились назад и собрали процесс заново, на маленьком контролируемом объёме. Собрали эталонную выборку. 92 реальных документа разных типов — не случайных, а специально подобранных так, чтобы в них были все проблемные варианты: повёрнутые сканы, рукописные вставки, документы с низким контрастом. Разметили вручную. Стажёр прошёл все 92 документа и зафиксировал, что модель распознала правильно, а что — нет, с указанием конкретной причины ошибки (ориентация, почерк, качество скана). Написали спецификации по типам документов. Для каждого типа — отдельная инструкция: где искать нужные поля, какие нюансы у этого типа (например, в рукописных формах отчество часто пишут через запятую после имени, а не отдельным полем). Добавили автоматический разворот. Перед вызовом модели изображение проверяется и разворачивается в правильную ориентацию — это убрало большую часть ошибок с вертикальными сканами. Построили каскад из двух моделей. Дешёвая модель сначала определяет тип документа, затем к нему применяется своя спецификация, и только на этом этапе подключается более мощная модель для извлечения данных. Добавили проверку человеком на выборке, а не на всём потоке. Менеджер смотрит не каждый документ, а случайную часть — если ошибок нет, доля проверки снижается. Перепроверили промпты на разных моделях. На наборе из 10–15 полных первичных консультаций прогнали одну и ту же задачу через несколько моделей разного уровня — сравнили, где точнее и где дешевле. Логика по модели разработки была такая: сначала пишем промпт под самую мощную модель, добиваемся, чтобы правила распознавания были выстроены безупречно, и только потом адаптируем этот же промпт под более простую и дешёвую модель, у которой уже есть готовая логика — ей не нужно «изобретать» правила, только следовать им. Где ломается. Если менеджер отмечает документ как «загружен», а файла на сервере нет — модель никогда не увидит эту ошибку сама. Мы столкнулись с этим напрямую: часть карточек в CRM выглядела «полной», а по факту обучающий массив содержал дыры. Без обязательной проверки «есть файл физически, а не просто галочка» любое дальнейшее дообучение будет тренироваться на пустоте. ИИ-связка целиком Возьмите схему за основу и подставьте свои типы документов и свои критичные поля. Конвейер выглядит так: клиент или менеджер загружает документ в общую папку → скрипт по расписанию проверяет новые файлы → дешёвая модель классифицирует тип документа → к нему применяется соответствующая спецификация → мощная модель извлекает данные → результат уходит в CRM через вебхук → менеджер видит статус и, если нужно, проверяет вручную. Шаг 1. Классификация типа документа. Модель: дешёвая (лёгкий уровень) — задача простая, вариантов ответа мало, переплачивать за мощную модель здесь бессмысленно. Пример ответа модели: Шаг 2. Извлечение данных по спецификации. Модель: мощная — здесь цена ошибки высокая, экономить нельзя. Инструкция берётся под конкретный тип документа, определённый на шаге 1. Пример ответа модели: Инженерная обвязка. Скрипт крутится на облачном триггере, который раз в час проверяет папку с документами: появился новый файл — робот подхватил его в очередь. Все вызовы моделей логируются в отдельную таблицу: тип документа, использованная модель, уверенность ответа, флаги. Если модель вернула низкую уверенность или флаг «требует проверки», в CRM через вебхук ставится задача на менеджера, а не автоматически заполняется карточка. Если сам скрипт падает (нет ответа от API, таймаут) — в таблицу пишется строка с ошибкой и статусом «не обработано», и раз в день кто-то один просматривает эту колонку целиком, а не каждый сбой в моменте. Отдельно: модель получает данные напрямую из CRM через отдельный слой между ИИ и базой данных компании, а не через ручную выгрузку файлов — это снижает расход токенов на 30–40%, потому что запрос не тащит за собой лишний контекст. Например: если типовой запрос на извлечение данных с ручной выгрузкой и склейкой файлов обходился условно в 1500 токенов на документ, то через прямой слой к CRM — ориентировочно 900–1050 токенов на тот же документ при том же качестве ответа (оценка, цифры иллюстративные). Заодно это снижает долю галлюцинаций модели — она не додумывает то, чего нет в обрезанном контексте. Тема отдельная и подробно разобрана в статье о реальных счетах за ИИ — Сколько на самом деле стоит ИИ в месяц . Так может выглядеть карточка очереди документов в CRM — с реальными числами из нашей выборки: Очередь документов — CRM 92 эталонных документа в выборке 7% доля ошибок после каскада 30–40% меньше токенов со связкой CRM Клиент Тип документа Уверенность Статус Соколова М. В. рукописная_форма 0.74 проверка Иванов П. С. удостоверение_личности 0.96 готово Что показало сравнение моделей Задача была не найти «самую точную вообще», а разложить конвейер так, чтобы дорогая модель работала только там, где без неё точность реально падает. Шаг конвейера Модель Почему именно она Классификация типа документа Дешёвая (лёгкий уровень) Задача с ограниченным набором ответов, ошибка здесь дешёво чинится на следующем шаге Извлечение данных по типовой спецификации Мощная Ошибка в имени или дате напрямую попадает в карточку клиента Документы с рукописным текстом Мощная, с проверкой человеком Даже сильная модель на почерке ошибается чаще — проверка обязательна Повторная проверка при низкой уверенности Мощная, другой промпт Второй проход с уточняющим промптом иногда исправляет то, что не увидел первый Часы, которые уходили у менеджеров на ручное исправление ошибок распознавания, до и после внедрения спецификаций и автоповорота — на диаграмме ниже: поток около 50 комплектов в месяц, ставка менеджера ~1000 ₽/час. 7ч было 2ч стало ≈7 часов/мес на исправления до внедрения спецификаций и автоповорота против ≈2 часов/мес после — оценка на основе потока около 50 комплектов в месяц. Экономика: что стоил провал и что даёт починка Настройка каскада заняла ~30 часов работы разработчика (≈60 000 ₽ по ставке 2000 ₽/час), а даёт снижение потерь на ручной пересборке документов с ≈7 000 до ≈2 000 ₽/мес — то есть эффект около 5 000 ₽/мес (оценка). Формула для потерь простая и её легко пересчитать под свой поток: число комплектов в месяц × доля ошибок × лишние минуты на пересборку ÷ 60 = дополнительные часы менеджеров в месяц . У нас: 50 комплектов × 20% ошибок в первые недели × 40 минут (верхняя граница диапазона 30–40 минут) ÷ 60 ≈ 7 часов в месяц. При ставке менеджера 1000 ₽/час это около 7 000 ₽/мес прямых потерь на ручную пересборку. посчитайте на своих цифрах комплектов в месяц доля ошибок, % минут на пересборку ставка менеджера, ₽/час потери ≈ {X} ₽ в месяц формула: комплекты × доля ошибок × минуты на пересборку × ставка ÷ 6000 (перевод процентов и минут в рубли); расчёт по верхней границе диапазона минут Вторая часть стоимости провала не считается в часах — это риск, что клиент увидит ошибку в своих данных в личном кабинете и потеряет доверие к сервису ещё до того, как получит результат. Стоимость починки — это не покупка новой лицензии, а время разработчика: сбор и разметка эталонной выборки (92 документа, разметка стажёром — примерно 3–4 часа), написание спецификаций по 4–5 типам документов (примерно 2–3 часа на тип, итого 10–12 часов разработчика) и настройка каскада моделей с обвязкой — промпты, вебхуки, логирование (примерно 15–20 часов разработчика). Итого около 30 часов разработчика. При условной ставке разработчика 2000 ₽/час это порядка 60 000 ₽ разовых затрат. После починки доля сбойных комплектов снизилась примерно до 7%: 50 × 7% × 40 минут ÷ 60 ≈ 2 часа в месяц — именно эта цифра стоит на диаграмме выше. Экономия на ручной работе: (7 − 2) часов × 1000 ₽/час = 5 000 ₽/мес. При разовых затратах на починку около 60 000 ₽ и экономии 5 000 ₽/мес окупаемость — около 12 месяцев, и это без учёта снижения репутационного риска от ошибок в карточках клиентов, который в часах не считается вовсе. Что мы не считаем эффектом: снижение репутационного риска не переводим в рубли — честно оценить вероятность потери клиента из-за ошибки в личном кабинете нельзя, поэтому в расчёт выше эта часть не входит. Освободившиеся часы менеджеров тоже не автоматически превращаются в новые продажи — это высвобожденное время для другой работы, а не гарантированная выручка. Цифра в 5 000 ₽/мес скромная в абсолютах, а окупаемость почти год — не быстрый результат. Но именно эта связка переводит распознавание документов из источника ручной работы в фоновый процесс, за которым не нужно следить каждый день, и при росте потока (например, при расширении отдела продаж) окупаемость только ускорится. Похожий по духу, но количественно другой результат — рост точности распознавания с 59% до 85% на другом наборе документов и с другими вводными — разобран отдельно в статье Распознавание документов: как мы подняли точность с 59% до 85% ; не путайте эти два кейса. Показатель До каскада После каскада Эффект Доля комплектов с ошибкой ~20% ~7% снижение примерно в 3 раза Доп.часы менеджеров в месяц ~7 ч ~2 ч −5 ч/мес Доп.расходы на ручную пересборку ~7 000 ₽/мес ~2 000 ₽/мес экономия ~5 000 ₽/мес Токены на один запрос через связку с CRM ~1500 (иллюстративно) ~900–1050 −30–40% токенов Разовые затраты на починку — ~60 000 ₽ окупаемость ~12 мес Все числа в таблице привязаны к потоку ~50 комплектов в месяц — это оценка для примера, проценты ошибок и экономия токенов взяты из фактических результатов эксперимента. Где ещё ломается. Если тип документа не описан ни в одной спецификации, каскад по умолчанию отправляет его на самую дорогую модель «на всякий случай» — и если доля таких нетиповых документов растёт, счёт за API растёт вместе с ней незаметно для того, кто не смотрит лог по типам. Раз в месяц стоит смотреть, какие типы документов система относит к «другое», и добавлять для них спецификации, а не оставлять на откуп дорогой модели навсегда. Что дальше: от 92 документов к пилоту на тысячи клиентов Механика выше — это не финал, а промежуточный, контролируемый шаг. Дальше по плану — прогнать систему ещё на 40 живых клиентских кейсах и отдать менеджерам на прямое подтверждение точности: совпадает ли распознанное с тем, что видит человек. Только если менеджеры подтверждают результат на этом объёме, имеет смысл переходить на сегмент около 5000 клиентов — тестировать не столько точность (она уже проверена на меньшем масштабе), сколько отклик и накопление достаточного массива данных для полноценного дообучения модели. Именно так — от эталонных 92 документов, через 40 живых кейсов, к тысячам — а не сразу на всю базу, как в первой, неудачной попытке. Чего я не понимал, когда начинал распознавание документов Я два месяца искал, какая модель «лучше читает документы», и всё это время ответ лежал в другом месте. Распознавание документов — задача не про модель, а про описание собственного потока: пока никто в компании не может назвать, какие типы документов у нас ходят и какие поля в них критичны, любая модель будет угадывать. Мой вывод из этого проекта простой: умение описать свой процесс до того, как покупать под него инструмент, — базовый навык руководителя, и окупается он не в этом внедрении, а во всех следующих. Проверьте это на себе прямо сейчас, не откладывая: перечислите типы документов, которые проходят через вашу компанию за неделю, и для каждого назовите два-три поля, ошибка в которых дорого вам обойдётся. Если список даётся тяжело — начинать надо с него, а не с выбора модели: ваш подрядчик или ваш разработчик всё равно спросят у вас то же самое, только через месяц и за ваши деньги. Чек-лист на понедельник Не запускайте распознавание сразу на всём потоке — соберите 50–100 эталонных документов и разметьте вручную, где модель ошибается. Проверьте, действительно ли документы, отмеченные в CRM как «загружены», физически лежат на сервере — расхождение здесь ломает любое будущее обучение. Разбейте документы на типы и напишите отдельную короткую инструкцию для каждого, а не одну универсальную «распознай документ». Добавьте автоматический разворот изображения перед вызовом модели — если работаете через API, а не через чат-интерфейс, это не опция, а обязательный шаг. Постройте каскад: дешёвая модель на классификацию, дорогая — на извлечение данных, человек — на выборочную проверку, а не на весь поток. Прикиньте свою экономику по той же формуле: поток комплектов × доля ошибок × лишние минуты на пересборку ÷ 60 = ваши часы потерь в месяц — и сравните с разовыми затратами на починку, чтобы понять свою окупаемость. Перед тем как отправлять документы клиентов в любую модель, свежим взглядом перечитайте, что вообще можно передавать наружу — коротко об этом в статье Персональные данные и нейросети . Что забрать вам из этого дневника: запускайтесь на реальном потоке, а не на чистых сканах; считайте точность по критичным полям, а не по документам; и заложите время на описание типов — это ваша основная работа, а не настройка модели. Полная механика — в разборе про точность и в бесплатном курсе . Чек-лист для вашего запуска Проверьте перед стартом: у вас есть эталонная выборка реальных документов; вы знаете, какие поля критичны; вы решили, что делать с неуверенными случаями; и у вас есть человек, который принимает результат. Без любого из четырёх пунктов вы получите наш первый результат — путаницу и потерянное время. ## Разработка личного кабинета: как один скрипт превратил 12 страниц в проблему URL: https://davidgerstein.pro/blog/klientskiy-portal-oshibki/ Дата: 2026-08-28 Направление: Производственный цикл Цифры: 12 страниц одним скриптом · 0 интеграций с CRM · 30–40% меньше токенов на MCP Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы заказали кабинет подрядчику, приняли работу по демонстрации и ни разу не открывали его глазами клиента — у вас там сейчас лежит минимум одна из трёх поломок, о которых ниже, и вы про неё пока не знаете. Я эти грабли собрал своими ногами: разбор ниже — про наш собственный кабинет, а не про чужие кейсы. У нас сервисная компания: отдел продаж 8 менеджеров, оборот около 9 млн ₽ в месяц, средний чек по сделке — 180 тысяч ₽. Это значит примерно 50 сделок в месяц проходят через один и тот же экран — клиентский портал, личный кабинет, куда контрагент грузит документы для оформления заявки. Когда этот экран собран криво, теряются не абстрактные «удобство» и «имидж», а конкретные сделки: если из 50 сделок в месяц застревает на этапе документов хотя бы 10% — это 5 сделок по 180 тысяч, то есть 900 тысяч ₽ отложенной выручки в месяц (оценка). Формула для своего случая: число сделок в месяц × доля зависших на этапе документов (%) × средний чек = сумма отложенной выручки в месяц — подставьте свои цифры и получите свою оценку. Отдельный случай, когда интерфейс уже есть, а логики под ним нет, — личный кабинет клиента . посчитайте на своих цифрах сделок в месяц средний чек, ₽ % зависших на документах риск ≈ {X} ₽ отложенной выручки в месяц формула: сделки в месяц × средний чек × доля зависших на этапе документов; результат — верхняя граница риска Я расскажу, как один и тот же экран портала прошёл путь от «страшно показать клиенту» до рабочего инструмента с ИИ-проверкой документов. По дороге вскрылись три отдельные поломки: скрипт, который генерировал страницы, кривая интеграция с CRM и сотрудники, которые обходили систему честнее, чем она это предполагала. Разработка личного кабинета: где чаще всего ошибаются? Ошибок три, и они повторяются почти у всех: страницы генерируют одним скриптом без построчной сверки с брендбуком, данные из кабинета не долетают до CRM автоматически, а статус «документ получен» ставится без прикреплённого файла. В клиентском портале компании на 40 человек это вылилось в пересборку 12 типов страниц — 30–50 часов дизайнера и разработчика. Порядок важнее скорости: сначала данные и валидация, потом логика и только в конце интерфейс. Я делал наоборот и потерял на этом месяц. Зачем вообще затевают разработку личного кабинета Ваша логика при заказе портала обычно такая же: клиенты сами всё увидят, менеджеры разгрузятся. Дальше — что этому мешает. Идея была простая: клиент заходит в личный кабинет, грузит документы — карточку организации, доверенность, спецификацию — и видит статус: одобрено, нужен доп. документ, лимит согласован. Менеджер освобождается от рутинной переписки «а вы прислали скан?». Под капотом — нейросеть, которая анализирует загруженные документы и формирует рекомендацию. Чтобы не тратить месяцы на полноценный продукт, решили запустить обучение алгоритма на реальных кейсах прямо сейчас: взять 40 живых случаев, прогнать через систему, отдать менеджерам на проверку. Если менеджеры подтвердят корректность — протестировать на сегменте из 5 тысяч клиентов и оценить отклик. Логика: за полгода набрать адекватный массив данных, чтобы к концу года запустить полноценный MVP. Разумный план. Экран подвёл раньше, чем модель. Как выглядело «до» Если у вас портал делал подрядчик и вы не смотрели внутрь — там может быть примерно то же самое. Под личный кабинет разработали 12 типов страниц: главная с дашбордом статуса, загрузка документов, история заявок, договор и тарифы, поддержка, база знаний, уведомления, счета, аналитика по заказам и ещё несколько служебных экранов. Чтобы не собирать каждую вручную, поручили одному скрипту сгенерировать все сразу по гайдлайнам бренда. Результат открыли и не узнали компанию. Скрипт формально «следовал» брендбуку, но на разных страницах — разные отступы, не тот акцентный цвет на кнопках, заголовки набраны шрифтом, которого в гайдлайне нет вовсе. На одной странице карточка документа выглядела как в брендбуке, на соседней — как шаблон конструктора сайтов десятилетней давности. Клиенту, который до этого получал аккуратные счета и договоры, показывать такой кабинет было стыдно. Мой первый инстинкт был именно такой — доводить каждую из 12 страниц до идеала вручную, страница за страницей. Это тупик: 12 страниц, у каждой десяток мелких расхождений — на полную вычитку и правку уйдут недели, а сзади уже стоит вторая проблема, куда более серьёзная. Что вскрылось при аудите Проверьте свой портал так же: возьмите пять реальных клиентов и сверьте то, что они видят, с тем, что в системе. Расхождения найдутся. Пока разбирались с вёрсткой, собственник обнаружил вторую поломку: документы клиентов загружаются в портал, там же формируются рекомендации нейросети — но эти данные не долетают до CRM автоматически. Менеджер видит статус в портале, а в карточке сделки — пусто. Чтобы обучить модель, нужно было вручную выгрузить весь массив данных портала и сопоставить его с клиентами, которые прошли проверку с первого раза. Без этого сопоставления модель не понимает, какие признаки в документе реально коррелируют с успешным исходом. Третья поломка была самой тихой и самой опасной. Менеджеры отмечали в CRM статус «документ в наличии» — но физически файл на сервер не грузили: экономили время, ставили галочку по памяти. Для человека разницы нет: документ где-то есть, все в курсе. Для модели, которая обучается на этих статусах, разница катастрофическая — она начинает считать, что клиент может пройти проверку без документа вообще. Обучающая выборка тихо портится, и никто этого не видит, пока не начинают сыпаться рекомендации по реальным сделкам. Где ломается: если в системе можно поставить статус «готово» без прикреплённого файла — рано или поздно кто-то так и сделает, не по злому умыслу, а чтобы не тормозить работу. Любая ИИ-модель, обученная на таких статусах, унаследует эту дыру и начнёт занижать требования к комплекту документов. Проверяйте не «отмечено ли», а «прикреплён ли файл» — это разные вещи. Пересборка личного кабинета: механика по шагам Ваш порядок: сначала данные, потом логика, и только в конце интерфейс. Мы делали наоборот и потеряли на этом месяц. Я принял решение не доводить каждую из 12 страниц до идеала перед тестированием, а изменить сам процесс сборки. Эталон вместо генерации. Взяли единственный утверждённый прототип главной страницы — тот, что прошёл дизайн-ревью без замечаний — и сделали его образцом для всех остальных 12 типов. Комплексный аудит вместо точечных правок. Собрали все 12 типов страниц в одну таблицу (Google Sheets: тип страницы → элемент брендбука → статус «совпадает / не совпадает» → кто чинит) и прогнали разом с привлечением дизайнера и разработчика, а не по одной странице за раз. Обязательная привязка статуса к файлу. На уровне формы и API запретили менять статус документа на «в наличии», пока файл физически не загружен на сервер. Это убрало третью поломку сразу — модель больше не видит «пустых успехов». Выгрузка и сопоставление данных. Массив документов и рекомендаций портала выгрузили и сопоставили с клиентами, прошедшими проверку с первого раза — так появился первый размеченный датасет для обучения. Точечное обучение OCR вместо запуска на всей базе. Вместо прогона через всю накопленную базу собрали 92 типовых документа, обучили стажёра проверять результат вручную и по каждому типу документа написали отдельную спецификацию — с описанием нюансов распознавания (развороты, качество скана, положение печати). Многоступенчатый анализ. Сначала система определяет тип документа, затем применяет нужную спецификацию, при затруднении эскалирует на более мощную модель, и только после этого документ уходит на подтверждение менеджеру. Координатор, который в других процессах компании держит статусы в трёх табличках, на этой пересборке сформулировал главное требование к системе одной фразой: «Статус меняется один раз и в одну сторону. Если менеджер откатывает дату проверки назад — я должен это видеть, а не гадать, что случилось на самом деле». Требование вошло в техзадание почти дословно. ИИ-связка целиком Возьмите эту схему за основу — она не зависит от того, на чём сделан ваш портал. Конвейер обработки документа выглядит так: клиент грузит файл на портал → вебхук уходит в обработчик → OCR извлекает текст → лёгкая модель определяет тип документа и полноту пакета → при низкой уверенности передаёт сложный случай на более мощную модель → результат пишется в карточку сделки в CRM → менеджер подтверждает или отклоняет. Загрузка файла на портал ~1 мин OCR + определение типа ~2 мин Анализ по спецификации ~3 мин Эскалация на сильную модель ~1,5 мин Проверка менеджером ~1 мин На шаге определения типа и полноты пакета работает дешёвая модель: задача формальная (классификация + извлечение полей), ошибка стоит немного, а объём документов большой. На шаге эскалации, когда документ повёрнут, скан плохого качества или тип нестандартный, — подключаем более дорогую модель с расширенным контекстом. Разница в стоимости запроса ощутима при потоке в сотни документов в месяц, поэтому маршрутизация «дешёвая → дорогая только по необходимости» — не экономия ради экономии, а единственный способ не сжечь бюджет на рутине. Пример ответа модели: Инженерная обвязка. Обработчик крутится на отдельном сервере, принимает вебхук из Bitrix24 при появлении нового файла в карточке сделки (входные данные: ID сделки, ссылка на файл, тип документа из формы). Результат анализа пишется обратно в кастомное поле сделки через API. Каждый шаг конвейера логируется в отдельную Google-таблицу: время, ID документа, модель, результат, ошибка — по образцу того, как в другом процессе компании настроили логирование обработки резюме, чтобы руководитель видел не только успешные случаи, но и зависшие. При сбое обработчик переставляет задачу в очередь на повтор и, если попытка проваливается трижды, кидает сообщение в общий чат команды, а не молчит. Отдельно для доступа ИИ-инструментов к данным CRM без раздувания промпта настроили MCP-сервер поверх базы CRM. Это снижает расход токенов на 30–40% и уменьшает долю галлюцинаций, потому что модель обращается к структурированным данным напрямую, а не получает их вставленными текстом в каждый запрос. Условный пример: запрос без MCP — это вставка текстового дампа карточки сделки в промпт, порядка 3000 токенов (оценка); тот же запрос через MCP обращается к структурированным полям и укладывается в 1800–2100 токенов — те самые 30–40% экономии на каждом вызове. При потоке в несколько сотен вызовов в месяц разница заметна на счёте за токены, но точную сумму в рублях считайте по своему тарифу у провайдера модели — универсальной цифры тут нет. Экран «после»: что показал аудит Ориентир для вашей проверки: данные на экране должны сходиться с системой на всех пяти проверенных клиентах, а не на одном показательном. Тип страницы портала Проблема на аудите Часов на исправление Личный кабинет / дашборд статуса Не тот акцентный цвет, шрифт заголовков не по брендбуку 3–4 Загрузка документов Статус менялся без привязки к файлу 6–8 (включая правку API) История заявок Расхождение в стилистике карточек 2–3 Договор и тарифы Вёрстка не соответствовала эталону 3–4 Остальные 8 типов страниц Точечные расхождения того же рода 2–4 на каждую, то есть 16–32 суммарно Итого по 12 страницам — 30–51, консервативно берём 30–50 (оценка) 0 из 12 было 12 из 12 стало До пересборки ни одна из 12 страниц не проходила аудит без замечаний по брендбуку; после сборки по единому эталону — все 12 страниц прошли аудит комплексно, за один цикл. Дело не в самих правках — их можно было сделать и раньше. Дело в порядке действий: раньше страницу доводили до идеала и только потом показывали; теперь берут эталон, собирают по нему всё сразу и лишь затем аудируют комплексно. Разница — недели точечной доводки против одного цикла аудита с понятным списком правок. Экономика: что это стоило и что дало Прикиньте свою: сколько времени ваши менеджеры тратят на ответы про статусы и сколько стоит переделка портала, если данные под ним неверны. Настройка ИИ-конвейера и MCP-сервера (вебхук, OCR, маршрутизация «дешёвая → дорогая модель», подключение к CRM) заняла ориентировочно 20–30 часов разработчика, эксплуатация моделей — около 3 000–5 000 ₽/мес, а эффект — сокращение затрат на ручную проверку документов примерно на 6 500–11 000 ₽/мес (оценка). Дальше — раскладка по инициативам: пересборку экрана и ИИ-модуль считаю раздельно, потому что это разные инициативы с разной окупаемостью и их нельзя складывать в один эффект. Пересборка вёрстки по эталону. По таблице выше сумма нижних оценок часов — 30, верхних — 51; берём консервативный диапазон 30–50 часов дизайнера и разработчика на аудит и доводку 12 типов страниц. При ставке около 1500 ₽/час это 45 000–75 000 ₽ разовых расходов — не эксплуатационных, а разового цикла пересборки. Обязательная привязка статуса к файлу. Стоимость внедрения — около 3–4 часов на изменение формы и валидации API, то есть на порядок дешевле, чем пересборка вёрстки. Эффект не в часах, а в риске: без этой правки модель обучается на искажённых данных, и любые рекомендации от неё становятся ненадёжными — а это уже не часы, а качество всего проекта. ИИ-конвейер анализа документов. При потоке около 50 сделок в месяц и в среднем 3–4 документах на сделку это 150–200 документов ежемесячно. Формула для своего случая: количество документов в месяц × время ручной проверки одного документа (мин) / 60 × ставка часа сотрудника = затраты на ручную проверку. Подставляем: ручная проверка каждого документа менеджером занимает 5–7 минут — 150×5/60 ≈ 12,5 и 200×7/60 ≈ 23,3, то есть 12–23 часа в месяц на весь отдел, или 12 500–23 000 ₽ по ставке 1000 ₽/час менеджера. Автоматическая маршрутизация «дешёвая модель → эскалация только сложных случаев» оставляет менеджеру только проверку результата — консервативно это сокращает время проверки вдвое (точная доля зависит от того, сколько документов ушло на эскалацию), то есть высвобождает 6 500–11 000 ₽/мес в пересчёте на часы менеджеров. Расходы на сами модели при таком потоке — условно 3 000–5 000 ₽/мес, то есть в разы меньше, чем экономия на времени менеджеров; подробный разбор счетов за ИИ есть в материале про реальные расходы на ИИ . Показатель До автоматизации После автоматизации Документов в месяц 150–200 150–200 Время проверки менеджером 5–7 мин/документ ~2,5–3,5 мин/документ (в среднем вдвое меньше) Часы отдела в месяц 12–23 6–12 Стоимость времени менеджеров (1000 ₽/час) 12 500–23 000 ₽ 6 000–12 000 ₽ Расходы на модели — 3 000–5 000 ₽/мес Риск зависших сделок. Если 10% из 50 месячных сделок зависает на этапе документов — это 5 сделок по 180 тысяч ₽, то есть 900 тысяч ₽ отложенной выручки в месяц (формула — в начале статьи). Пересборка экрана и обязательная привязка статуса к файлу не гарантируют, что этот риск исчезнет полностью, но убирают одну из его причин — искажённые статусы, из-за которых сделка стоит на месте, пока никто не замечает, что документа фактически нет. Что мы не считаем эффектом: устранение этой причины — это снижение вероятности зависания, а не гарантированная экономия; складывать эту цифру с экономией на ИИ-конвейере напрямую нельзя — это разные механизмы эффекта, один снижает трудозатраты, другой снижает вероятность потери сделки. Где ломается: качество OCR через API и через веб-интерфейс модели — разные вещи. Мы тестировали распознавание в самом сервисе — работало отлично. При запуске через API повёрнутые документы переставали распознаваться корректно. Если тестируете модель только в интерфейсе, а в продакшне работаете через API — закладывайте отдельный цикл тестирования именно на API-вызовах, желательно на 90–100 типовых документах с разными углами поворота и качеством скана. С чего начать вам в понедельник Четыре шага, и первый — не про интерфейс. Выгрузить список всех типов страниц/форм портала и построчно сверить с брендбуком — не выборочно, а полностью. Найти один утверждённый экран и объявить его эталоном для всех остальных, вместо доводки каждого по отдельности. Проверить в CRM: можно ли поставить статус «документ получен» без прикреплённого файла. Если можно — закрыть это в первую очередь. Собрать 50–100 типовых документов из потока, прогнать через OCR именно через тот канал, который будет в проде (API, а не веб-интерфейс), дать проверить человеку. Настроить логирование каждого шага обработки документа в отдельную таблицу — сколько успешно, сколько зависло, сколько с ошибкой. Назначить одного ответственного за актуализацию спецификаций и шаблонов — без владельца документация устаревает за первый же квартал. Про то, когда клиентский портал вообще нужен компании, а когда это лишние деньги на пустом месте, — отдельный разбор в материале о клиентских порталах для среднего бизнеса . Как поднять точность распознавания документов с 59% до 85% на конкретном кейсе — в разборе по OCR . Главный вывод для вас: портал нужен не тогда, когда его хочется, а когда клиенты уже спрашивают одно и то же, и вашим людям это надоело отвечать вручную. До этого момента вы строите красивую витрину, которой никто не пользуется. Как понять, дозрели ли вы до портала, — в отдельном разборе , а механика внедрения — в бесплатном курсе . Мой вывод из этой пересборки Я потратил месяц на красивый интерфейс, прежде чем понял, что проблема была в данных. Клиенты видели статусы, которые не соответствовали реальности, — и портал не экономил время менеджеров, а добавлял им работы по объяснению расхождений. Если вы делаете свой портал — начните с проверки данных. Это скучно и это единственное, что определит, будет он работать или нет. И назову вещь, которую раньше не считал работой руководителя. Это отдельный управленческий навык: читать не экран, а данные под ним. Руководитель, который умеет спросить «что физически лежит в системе за этим статусом» и получить ответ цифрой, стоит дороже руководителя, который принимает решения по красивой картинке. Мне этот навык обошёлся в месяц работы команды — вам он может достаться за один вечер проверки. И назову вещь, которую раньше не считал работой руководителя. Это отдельный управленческий навык: читать не экран, а данные под ним. Руководитель, который умеет спросить «что физически лежит в системе за этим статусом» и получить ответ цифрой, стоит дороже руководителя, который принимает решения по красивой картинке. Мне этот навык обошёлся в месяц работы команды — вам он может достаться за один вечер проверки. Проверьте свой портал на этой неделе так же, как проверили мы: пять реальных клиентов, сверка того, что видят они, с тем, что в системе. ## Почему согласование договоров стопорится на финальной проверке — и как перестать терять клиентов URL: https://davidgerstein.pro/blog/soglasovanie-dogovorov-oshibki/ Дата: 2026-08-28 Направление: Производственный цикл Цифры: 900 000 ₽ риска в месяц, 12 зависших сделок, 35→3 мин на случай отказа (обе оценки) Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы не можете за десять секунд назвать, сколько договоров прямо сейчас висит на согласовании и у кого именно, — у вас уже идут потери, вы их просто не видите. Клиенты уходят на том этапе, где они вам уже сказали «да». Это самая обидная точка потерь в бизнесе. Не «дорого», не «подумаем», не конкурент увёл. Клиент готов подписать — и ждёт, пока договор проходит круг по вашей компании. Иногда неделю. Иногда до тех пор, пока ему не надоест. Ниже — месяц перестройки этого процесса по неделям: что сломалось, что сработало и сколько это стоило. Я специально оставил в хронике собственные грабли: они полезнее гладкой истории успеха. У нас отдел из 15 менеджеров, оборот около 18 млн ₽ в месяц, средний чек по сопровождению сделки — 150 тысяч ₽. Это значит, что через воронку каждый месяц проходит примерно 120 сделок, и каждая из них проходит через процесс согласования договоров перед подписанием. Часть сделок дополнительно обязана пройти финальную проверку — комплаенс-проверку контрагента на стороне заказчика или банка. Пока эта проверка идёт, сделка живёт своей жизнью в CRM. И вот тут начинается дыра. Если проверка провалена, менеджер должен откатить сделку назад, зафиксировать причину и запустить повторную подготовку. На практике он делал это руками — и часто забывал снять дату уже прошедшей проверки. Сделка зависала: система считала, что проверка ещё впереди, хотя она уже провалена. По грубой оценке, на этом держится риск в 900 000 ₽ выручки в месяц — я покажу расчёт ниже. Дальше — хроника, как мы это чинили, по неделям, с тем, что сломалось на каждом шаге. Почему согласование договора зависает и как это чинится Согласование ломается не на подписании, а на финальной проверке: её отрицательный результат никто не заносит в систему, сделка остаётся в статусе «на проверке» и выпадает из работы. При обороте 18 млн ₽ в месяц и среднем чеке 150 тыс. ₽ это держит под риском около 900 000 ₽ выручки ежемесячно — шесть сорванных сделок из ста двадцати. Дисциплиной это не лечится, лечится архитектурой: результат проверки становится обязательным полем с закрытым списком причин, откат сделки — автоматическим действием CRM, а просроченный статус уходит не менеджеру, а контролю качества. После этого один случай отказа стал занимать 3 минуты вместо 35 . Что решили на старте: как перестроить процесс подписания Поводом стал не абстрактный аудит, а обычная планёрка по воронке. Собственник посмотрел на отчёт и не увидел ни одной сделки со статусом «проверка провалена» — только «на проверке» и «подписан». Провалы были, менеджеры о них рассказывали устно, но в системе они не существовали. Решили втроём с руководителем продаж и разработчиком: систему нужно заставить фиксировать отказ так же строго, как она фиксирует оплату. Задача на старте звучала так: убрать зависимость от памяти менеджера в трёх точках — фиксация даты неуспешной проверки, причина отказа, откат сделки на этап повторной подготовки. Четвёртым пунктом добавили контроль: если сделка не перемещена в установленный срок, об этом должен узнать не только менеджер, но и контроль качества. Неделя 1: диагностика — сколько дел уже потеряно из виду С этого начнёте и вы: не с внедрения, а с честного замера. Вам понадобится список всех договоров в работе с датами — и готовность увидеть неприятную картину. Прежде чем чинить, подняли карточки сделок за три месяца. Картина оказалась хуже, чем думали. У части сделок дата плановой проверки стояла в прошлом, а сама сделка всё ещё висела на этапе «ожидание проверки» — то есть либо проверка не проводилась, либо результат никто не внёс. Это тот же класс сбоя, что мы разбирали в материале про то, как Битрикс24 сам сдвигает даты сделок : система не спорит с пользователем, если её об этом не попросили. Причина отказа, если её вообще писали, лежала свободным текстом в общем поле комментария — что-то вроде «не прошло, документов не хватило» вперемешку с другими заметками по сделке. Отдельно нашли соседнюю проблему на более раннем этапе цикла — «ожидание документов от клиента»: там скопилось 26–27 просроченных дел одновременно. Причина оказалась не техническая, а человеческая: менеджеры на продаже говорили клиентам, что спешить не нужно, можно прислать документы когда удобно. Это тот же класс проблемы — процесс не давит на дедлайн, пока кто-то не заставит систему это делать. Мы решили не чинить это отдельно, а сразу закладывать дедлайны и жёсткую фиксацию статуса во весь цикл согласования, а не только в точку финальной проверки. Этап цикла Что нашли (факт) Кто должен был заметить Ожидание документов 26–27 просроченных дел одновременно Менеджер — не заметил, срок не был зафиксирован в договоре Ожидание проверки Дата в прошлом, сделка не сдвинута Никто — система не фиксировала провал После отказа Причина в свободном тексте или отсутствует Менеджер — писал по памяти, если вспоминал Повторная подготовка Запускалась вручную, с задержкой 1–3 дня Контроль качества — не видел провалов вообще Неделя 2: первое решение — и что сразу сломалось Обратите внимание на этот этап: у вас будет так же. Я обжёгся здесь ровно тем же способом — первое решение ломается о привычки людей, а не о технику, и это нормальная часть пути, а не признак того, что вы что-то делаете не так. Добавили в CRM три вещи: отдельное поле «дата неуспешной проверки» (не путать с датой плановой), обязательное поле «причина отказа» с фиксированным списком из четырёх вариантов — критическое несоответствие данных, риски по контрагенту, недостаток документов, другое — и автоматическую задачу менеджеру на день проверки с двумя кнопками: «пройдена» и «не пройдена». На бумаге это закрывало всю дыру. На практике за первую неделю сломалось две вещи. Первое: менеджеры по привычке продолжали писать причину в старое общее поле комментария — новое обязательное поле физически существовало, но не было частью их рабочего маршрута, они его просто не видели. Мы уже сталкивались с похожей инерцией, когда разбирали, почему менеджеры не вносят данные в CRM , и решили не повторять ошибку уговоров, а сразу менять архитектуру полей. Второе: даже когда кто-то нажимал «не пройдена», сделка не откатывалась сама — это по-прежнему было ручным действием. То есть мы автоматизировали фиксацию факта, но не автоматизировали следствие. Менеджер видел на экране «не пройдена», разводил руками и всё равно тратил 20–30 минут (оценка) на ручной перенос сделки и повторную настройку задач — то есть время почти не сократилось по сравнению с полностью ручным процессом (≈35 минут на случай, оценка, — из расчёта в разделе про экономику ниже). Где ломается. Если новое обязательное поле не встроено в тот же экран, где менеджер и так работает — он его не заметит, сколько бы раз вы ни объясняли на планёрке. У нас поле стояло на вкладке «Дополнительно», а не на основной карточке сделки. Перенесли на первый экран — заполняемость выросла сразу, без единого разговора с отделом продаж. Скажу честно: я сам годами держал такие статусы в голове. Раз в неделю пробегал глазами по списку сделок, помнил, у кого что застряло, и был уверен, что процесс под контролем. Здесь ошибаются все, включая меня: пока провал не обязан появиться в системе, его в системе и не будет. Это не разгильдяйство менеджеров — это дыра в процессе, которую спроектировал руководитель. Неделя 3: ИИ-связка — автоматический откат и разбор причины Раз ручной откат не работает, решили убрать его из процесса вовсе. Как только менеджер выбирает «не пройдена», Bitrix24-вебхук должен сам: снять сделку с этапа проверки, поставить причину отказа, создать задачу на повторную подготовку и — отдельно — разобрать текстовый комментарий менеджера (если он есть) на структурированную категорию для аналитики, потому что «другое» без расшифровки бесполезно для отчётности. Схема конвейера: смена поля «Результат проверки» в сделке → триггер вебхука → сценарий в n8n на нашем сервере → вызов дешёвой модели для классификации комментария → запись категории обратно в сделку через REST API Bitrix24 → если сделка не сдвинута автоматом за час — сообщение в Telegram ответственному разработчику. Для классификации причины отказа модель не нужна дорогая — задача короткая, закрытый список вариантов, риск ошибки невысокий, а объём — до 12 сделок в месяц с отказом. Взяли модель уровня Haiku / GPT-4o-mini. Пример ответа модели: Второй промпт — сложнее и запускается реже: сверка комплекта договора с условной логикой пакета. У нас в договорах зашита подстановка: пакет «базовый» тянет за собой облегчённую услугу (инструкция по самостоятельной подготовке), пакет «расширенный» — полное сопровождение. Шаблон лежит в общем облачном хранилище, за его актуализацию отвечает юрист: старые версии архивируются, новая версия размещается под тем же названием файла. Проблема в том, что скрипт подстановки иногда путает пакеты, если менеджер поменял тип услуги в форме уже после того, как договор сформирован. Здесь нужна модель, которая понимает контекст текста договора, а не просто ищет ключевые слова — взяли уровень Sonnet. Из чего собирается сам шаблон и какие пункты в нём страхуют от суда — разобрал отдельно . Инженерная обвязка: все вызовы модели логируются в отдельную Google-таблицу — какая сделка, какой промпт, какой ответ, сколько токенов — по той же схеме, что мы уже обкатали на другой задаче с логированием обработки резюме через прокси-сервис. Отдельно подняли MCP-сервер поверх базы CRM: он даёт модели прямой безопасный доступ к нужным полям сделки без выгрузки лишнего контекста, это снижает расход токенов на 30–40% и уменьшает долю галлюцинаций на классификации. Ошибки — в Telegram-бот на ответственного разработчика, retry — три попытки с очередью, если сервис модели недоступен. Неделя 4: контроль качества и статусы без напоминалок Здесь ваша задача как руководителя — не дать процессу вернуться к ручным напоминаниям. Если статус приходится спрашивать голосом, система не работает, как бы красиво она ни выглядела на схеме. Отдельно добавили правило: если сделка с результатом «не пройдена» не переместилась на нужный этап автоматически в течение установленного срока — уведомление уходит не менеджеру, а контролю качества. Это страховка на случай, если сам вебхук упал или модель вернула низкую уверенность и пометила needs_manual_review. Тот же принцип контроля, не зависящего от памяти сотрудников, мы применяли для контроля дебиторки — работает он одинаково хорошо на любых зависающих статусах, не только на договорах. На этой же неделе всплыла идея с соседнего фронта — от координатора производственного цикла Димы, который держит статусы заказов в трёх табличках и каждую неделю делает «снимок» — фиксирует состояние на конкретный момент, чтобы через месяц видеть, где реально стояло дело, а не где его задним числом подвинули. «Если статус не менялся — ставь прочерк, не заставляй меня гадать, кто забыл нажать кнопку», — сказал он на общей планёрке, когда обсуждали именно эту проблему с забытыми откатами. Взяли этот принцип буквально: теперь каждую среду вечером система автоматически фиксирует текущий статус каждой сделки в отдельный столбец таблицы контроля. Новые столбцы добавляются слева от предыдущих — руководитель видит последние изменения без прокрутки. Если статус не изменился — прочерк, а не пустая ячейка, потому что пустая ячейка неотличима от «забыли посчитать». Таблица контроля — срез по средам Сделка 28.08 21.08 14.08 #48213 не пройдена — на проверке #48219 подписан на проверке — #48225 — не пройдена на проверке На диаграмме ниже — во сколько раз сократилось время на один случай отказа после того, как откат и классификация стали автоматическими. 35 мин было 3 мин стало Среднее время на один случай отказа: ручной откат и поиск зависшей сделки — против автоматического отката с классификацией причины (обе цифры — оценка). Что осталось нерешённым Дальше — честная часть, которую я в кейсах подрядчиков ни разу не встречал. У нас тоже не всё закрылось, и вам стоит знать, где будет сопротивляться ваш процесс. Три вещи мы сознательно не стали закрывать в этом же спринте. Первое — шаблоны договоров по-прежнему актуализирует юрист вручную в облачном хранилище, автоматической проверки версии (не устарел ли шаблон, из которого собран конкретный договор) пока нет. Это уже аукнулось на смежном участке: часть клиентов получила документы по старому шаблону, не соответствующему новым требованиям к комплекту, и застряла на этапе финальной проверки. По месяцам это выглядело неровно: например, около 76 случаев в одном месяце, 8 в следующем и 47 — за одну только первую неделю ещё одного месяца, но на пике масштаб доходил до 100–150 дел в месяц. Чинили точечно, руками, ответственный сотрудник лично отслеживал версии шаблонов. Второе — правило «три зафиксированных случая, когда клиент не отвечает, приравниваются к отказу» внесено в регламент и в договор, но фиксация самих попыток связи всё ещё держится на менеджере, а не на автоматическом счётчике звонков и сообщений. Третье — срок действия договора для типовых работ теперь обязателен по регламенту, но проставлен вручную только в новых договорах, ретроспективно старые не пересчитаны. Во сколько обходится автоматизация этого участка — посчитал отдельно . Где ломается ещё. Автоматизация отката и классификации не спасает, если сам шаблон договора устарел или сформулирован неоднозначно. Модель добросовестно сверит договор с правилом подстановки услуги — но если правило само устарело (например, изменились требования проверяющей стороны к адресу или формату документа), ИИ подтвердит соответствие несуществующему стандарту. Это не баг классификатора, это дыра в исходных данных, и никакой промпт её не закроет — только регламент пересмотра шаблонов с фиксированной периодичностью. Это ровно тот случай, который мы разбирали в тексте о том, что автоматизация требует постоянного присмотра , а не разовой настройки и забвения. Экономика: что это стоит и что даёт Прикиньте свои потери прежде, чем смотреть на мои цифры. Возьмите средний чек, умножьте на число сделок, которые в прошлом квартале зависли на согласовании дольше недели. Это и есть ваш бюджет на решение задачи — обычно он в разы больше, чем стоит сама перестройка процесса. При обороте 18 млн ₽/мес и среднем чеке 150 тыс. ₽ через воронку проходит около 120 сделок в месяц (18 000 000 ₽ ÷ 150 000 ₽ = 120). По нашей оценке, порядка 10% сделок в моменте виснут без движения дольше нормы на любом из этапов согласования — это 120 × 0,10 = 12 сделок в месяц. Из них до автоматизации примерно половина (оценка) реально срывалась из-за забытого статуса или потерянного контакта с клиентом, а не из-за объективного отказа — то есть 12 × 0,5 = 6 сделок в месяц, или 6 × 150 000 ₽ = 900 000 ₽ выручки под риском (оценка). Экономия времени отдельно от снятого риска: до автоматизации ручной откат и поиск зависших дел занимал у менеджера и контролёра качества суммарно около 35 минут на каждый случай отказа; после — около 3 минут (проверка, что вебхук отработал корректно, и в редких случаях — разбор карточек с needs_manual_review). Разница — 32 минуты на случай. При 12 случаях отказа в месяц: 32 мин × 12 = 384 минуты = 6,4 часа работы отдела в месяц. По ставке 1000 ₽/час (оценка, усреднённая для менеджера и контролёра качества) это 6,4 × 1000 ≈ 6 400 ₽/мес прямой экономии времени. Чтобы прикинуть свой случай: возьмите долю сделок, которые у вас реально зависают на этапах согласования, умножьте на число сделок в воронке за месяц — получите число зависших; из них оцените долю тех, что срываются именно из-за забытого статуса, а не по объективным причинам, и умножьте на средний чек — получите сумму риска. Отдельно: возьмите разницу в минутах между ручной и автоматической обработкой одного случая отказа, умножьте на число таких случаев в месяц, переведите в часы и умножьте на часовую ставку сотрудника, который этим занимается, — получите экономию времени в деньгах. посчитайте на своих цифрах сделок в воронке / мес % зависших сделок % из них — из-за статуса средний чек, ₽ риск ≈ {X} ₽ в месяц формула: сделки × доля зависших × доля потерянных из-за статуса × чек (проценты приведены к долям); оценка сверху Сама по себе цифра экономии времени скромная. Я считаю главным эффектом не сэкономленные минуты, а в том, что 900 000 ₽ выручки, которые раньше утекали через забытый статус, теперь остаются в воронке — потому что зависшую сделку больше не нужно случайно заметить, система сама не даёт ей провисеть незамеченной. Эти два эффекта — снятый риск выручки и экономия времени — считаются раздельно и не складываются в одну сумму: первое про то, что не потеряно, второе — про то, что не потрачено. Показатель Значение Оборот в месяц 18 млн ₽ Средний чек сделки 150 тыс ₽ Сделок в воронке / мес 120 (18 000 000 ÷ 150 000) Доля зависших сделок (оценка) 10% → 12 сделок Из них теряется из-за забытого статуса (оценка 50%) 6 сделок Риск выручки 6 × 150 000 ₽ = 900 000 ₽ (оценка) Время на случай отказа до автоматизации ≈35 мин (оценка) Время на случай отказа после автоматизации ≈3 мин (оценка) Случаев отказа в месяц до 12 Экономия времени в месяц 32 мин × 12 = 6,4 часа Экономия времени в деньгах (ставка 1000 ₽/час, оценка) ≈6 400 ₽/мес Умение вынести собственную память в поле, которое система обязана заполнить, — такой же базовый навык руководителя, как чтение отчёта о деньгах. Я понял это поздно: пока причина отказа живёт в голове менеджера и в устном рассказе на планёрке, управления процессом нет — есть ощущение управления. Руководитель, который умеет заставить систему фиксировать плохие новости, стоит дороже того, кто узнаёт о них последним. Что сделать на этой неделе: попросите показать вам все договоры, которые сейчас на согласовании, с датой отправки. Не отчёт — реальный список. Обычно после этого разговор о необходимости менять процесс заканчивается сам собой: цифры убеждают лучше меня. Как собрать такой контроль так, чтобы он работал без вашего участия и напоминаний, — механика в бесплатном курсе : там же готовые постановки для разбора договоров машиной. ## Как управлять бизнес-процессами: от описания до автоматизации URL: https://davidgerstein.pro/operacii/upravlenie-biznes-processami/ Дата: 2026-08-27 Направление: Операционное управление Цифры: риск зависших сделок 900 000 → 540 000 ₽/мес (оценка) · снижение риска на 40% Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы не можете назвать, сколько дней ваш заказ идёт от заявки до денег, — у вас нет процесса. У вас есть привычка, которую каждый исполняет по-своему, и вы узнаёте о сбое от клиента. Описывать все процессы компании — плохая идея: вы потратите квартал и получите папку, которую никто не откроет. Начинать надо с одного процесса, который приносит вам больше всего боли. Что такое управление бизнес-процессами на практике Это не документ на полке, а цикл: описать как есть → найти узкое место → поставить норматив → автоматизировать → мерить. Процесс без норматива срока не управляется: в компании на 40 человек сделка провисела 540 дней и всё это время считалась живой. Автоматизация даёт эффект только после описания: она ускоряет то, что есть. В том же отделе продаж риск зависших сделок снизился с 900 000 до 540 000 ₽/мес — не потому что купили систему, а потому что появились дни в статусе и ответственный на каждом этапе. Скажу сразу, чего мне самому не хватало, когда я брался за это впервые: не методики, а понимания, что описывать процесс целиком не нужно. Мне казалось, что пока не опишу всё, начинать нельзя — и я не начинал. Когда вам это действительно нужно Признак простой: вы перестали помнить, как именно у вас происходит работа от заявки до денег, и вам приходится спрашивать. Управление бизнес-процессами — это не регламент и не схема в презентации. Это три действия по кругу: описать, кто что делает и сколько это занимает; найти стадию, где всё стоит дольше нормы; автоматизировать именно эту стадию, а не процесс целиком. Нужно это тогда, когда компания выросла настолько, что никто больше не помнит всю цепочку наизусть — по моим наблюдениям, это происходит где-то между 25 и 40 сотрудниками. Масштаб проблемы виден в одной цифре, и она неприятная. По исследованию «Яков и Партнёры» (2026) ИИ в процессах уже применяют 71% компаний, но значимый финансовый эффект фиксируют только 9%. При этом 89% таких проектов остаются пилотами — данные TAdviser и MWS AI, 2026, 2026 — запустили, показали на демо, забыли. Разница между 71% и 9% — это не про модель и не про бюджет. Это про то, довели ли разбор до конкретной метрики и до человека, который за неё отвечает. Ещё одна цифра, из исследования SpeShu.AI по малому и среднему бизнесу (86 глубинных интервью, 2026): 47% руководителей принимают решение о масштабировании ИИ-инициатив по кейсам с измеримыми результатами, а не по описанию функционала на демо. Проблема в том, что публичных кейсов с прозрачной экономикой на рынке почти нет: конкуренты по кругу повторяют одни и те же четыре цифры — «−30–50% рутины», «до 80% операций», «−40% издержек», «окупаемость 3–6 месяцев» — без единого числа, которое можно взять и проверить на своих данных. Этот гайд собран так, чтобы цифры можно было пересчитать: с ценой внедрения, а не только с эффектом, и с отдельным разделом про то, где расчёт не сработал. Управление процессами не равно регламентам на полке: сам по себе документ ничего не меняет, если по нему не сверяются. И это не разовый аудит: без цикла повторения любой аудит устаревает за один квартал. Как описать процесс, чтобы его можно было анализировать Ваша задача — не красивая схема, а пять-семь шагов со временем каждого. Схему нарисуете потом, если понадобится. Процесс описан достаточно, если по нему можно посчитать время каждого шага и назвать одного ответственного за шаг. Три поля минимум: шаг, кто делает, сколько занимает. Без числа «сколько занимает» описание — это красивая картинка, а не рабочий инструмент. Самый быстрый способ получить такое описание — не сажать человека за Excel на день, а дать ему полчаса и голос. Рабочая механика, которую я видел не раз: руководитель просит менеджера наговорить дорожную карту по воронке — что есть на каждой стадии сейчас, что работает, что нужно внедрить, — а потом это передают тому, кто расписывает автоматизации. Полчаса голосом дают больше, чем два часа мучений с таблицей: человек не редактирует себя на лету и не забывает мелкие детали, которые обычно выпадают при формальном описании. Готовое описание бесполезно, если оно не привязано к живому месту хранения, которым реально пользуются — про это подробно: дом без дверей: как сделать базу знаний, которой реально пользуются . Там разбор, почему один и тот же процесс на бумаге и в базе — это два разных процесса. Описание процесса и регламент по нему — разные документы с разной судьбой. Описание фиксирует, как есть сейчас; регламент диктует, как должно быть, и его гораздо чаще кладут на полку и забывают. Чтобы регламент не превращался в мёртвый текст, важны те же три поля, что и в описании, плюс явный критерий готовности каждого шага — как сделать регламент, который реально читают: регламенты, которые читают: от полки к инструменту . Отдельно стоит зафиксировать формат хранения самого описания — версию, дату последнего обновления и того, кто внёс правку. Без этих трёх полей описание живёт ровно до первого спора: два человека приносят на встречу два разных файла с одинаковым названием и разными шагами, и никто не может сказать, какой из них актуальный. Простое правило «одна ссылка — один актуальный файл» закрывает эту проблему почти полностью, но требует дисциплины именно от того, кто процесс описывал, а не от всех подряд. Где ломается. Описание живёт, если по нему сверяются хотя бы раз в квартал. Если не сверяются — оно превращается в документ, который читают один раз при найме и больше никогда. Как найти узкое место: метрики, а не ощущения Спросите своих людей, где им тяжелее всего, — а потом проверьте цифрами. В моей практике эти два ответа совпадали примерно в половине случаев. Узкое место — это стадия процесса, где доля объектов (сделок, заявок, документов), стоящих дольше нормы, превышает 20–25% от числа объектов на этой стадии . Знаменатель тут решает всё: считать надо от того, что стоит на стадии сейчас, а не от всего месячного потока — иначе любая стадия выглядит благополучной и узкое место не находится никогда. Находится это выгрузкой времени прохождения по стадиям из CRM за месяц, а не опросом «где у нас тормозит» — на опрос каждый отдел честно скажет, что тормозит у соседей. Пример на цифрах нашей условной компании. Оборот 9 млн ₽/мес при среднем чеке 180 тыс. ₽ — это 50 сделок в месяц на 8 менеджеров, то есть около 6 сделок на менеджера. Выгрузка по стадиям показала: на согласовании находятся 12 сделок, и 5 из них стоят дольше нормы — это 42%, вдвое выше порога. Риск таких зависших сделок = 5 × 180 000 = 900 000 ₽/мес (оценка) — не выручка, которую точно потеряют, а сумма, которая под угрозой, если сделки не разморозить. Как считать риск зависших сделок (формула, не готовый вывод для любой компании) Берём одну стадию — ту, что признана узким местом. Знаменатель тот же, что и в диагностике: сделки, находящиеся на этой стадии, а не месячный поток. Зависших сделок = сделок на стадии × доля стоящих дольше нормы (целыми штуками, не «2,5 сделки»). Риск = зависших сделок × средний чек. Пример: на согласовании 12 сделок; 12 × 42% ≈ 5 сделок; 5 × 180 000 ₽ = 900 000 ₽/мес (оценка). После того как на стадию согласования назначили владельца и поставили ежедневный алерт о сделках старше 10 дней, доля стоящих дольше нормы упала с 42% до 25% — с 5 сделок до 3. Риск снизился с 900 000 ₽ до 540 000 ₽/мес, то есть на 360 000 ₽/мес (оценка). Это снижение риска, а не гарантированный прирост выручки: часть из этих сделок и без вмешательства закрылась бы сама. На диаграмме — риск зависших сделок до и после того, как нашли стадию и назначили владельца. 900 000 до 540 000 после Риск = число зависших сделок × средний чек (180 000 ₽). Было 5 сделок, стоящих дольше нормы, из 12 на стадии (42%), стало 3 из 12 (25%) — снижение риска на 360 000 ₽/мес, оценка. Стадия Сделок на стадии Стоят дольше нормы, до % до Стоят дольше нормы, после % после Согласование 12 5 42% 3 25% Договор 8 2 25% 2 25% Оплата 6 1 17% 1 17% Важная деталь про эту таблицу: доли на стадиях «Договор» и «Оплата» не изменились — там узкого места не было и мы туда не вмешивались. Это специально: автоматизация точечная, а не «давайте улучшим всё сразу». Если начать чинить сразу все стадии, ресурсов и внимания владельцев не хватит ни на одну, и через месяц окажется, что метрика не двинулась ни там, ни там. Где ломается. Если метрику посчитали один раз и не обновляют, узкое место «находят» заново каждый квартал вручную, а разные выгрузки одного и того же показателя расходятся почти в 5 раз — подробный разбор с цифрами: узкие места в процессах: как найти то, что тормозит всю компанию . Кого назначить владельцем Того, кто видит ваш процесс каждый день и может на него влиять. Не топ-менеджера «для веса» — иначе владелец будет узнавать о проблемах последним. У каждого процесса должен быть один именованный человек, который отвечает за метрику стадии — не отдел, не «продажи в целом», а конкретная должность. Без этого любая автоматизация превращается в надзор вручную: бот шлёт алерты, а разбираться с ними всё равно приходится тому, кто случайно их заметил. На одной из планёрок операционный директор Лена задала простой вопрос: «Кто владелец этого процесса?» — про стадию согласования договоров. Молчание длилось секунд десять. Отдел продаж считал, что это забота юристов; юристы — что это забота продаж; проект-менеджер думал, что процесс вообще ничей, потому что документооборот всегда «как-то сам разбирался». Через неделю владельца назначили — и оказалось, что у него физически нет времени на эту роль: он уже вёл три параллельных проекта. Роль пришлось переносить на другого человека. Сам разговор о том, кто владелец, стоит фиксировать не в памяти участников планёрки, а в протоколе, который не зависит от того, кто что запомнил через неделю. Мы стали автоматически расшифровывать планёрки в текст именно из-за таких историй: раньше на следующей неделе каждый вспоминал разговор по-своему, и спор шёл не по делу, а по памяти. Механика такой автоматизации — в разборе: планёрка, которая документирует себя сама . Автоматизация без владельца почти всегда требует надзора — сколько это стоит в деньгах и какие три свойства обязательны у рабочей автоматизации, разбирали здесь: «если бы я не пришёл, ничего бы не произошло» . А как выстроить контроль, который не держится на памяти одного человека — в разборе про делегирование: делегирование без хаоса . Ещё одно наблюдение по этой теме: должность владельца не должна плыть по тексту документов компании. Если в одном регламенте он «руководитель отдела продаж», а в другом — «ответственный за воронку», через полгода никто не может быстро найти, кто это. Зафиксируйте должность один раз в одном месте и ссылайтесь на неё, а не переизобретайте название роли под каждый новый документ. Где ломается. Владелец назначен формально, но перегружен другой работой — роль превращается в фикцию, а метрика продолжает расти в тишине. Какие каналы связи незаметно душат процесс Разросшиеся каналы связи не ускоряют процесс — они прячут узкое место, потому что информация расползается по местам, которые никто не сверяет между собой. Типичный симптом: число оплаченных каналов вырастает в разы без роста числа сотрудников, которые ими пользуются. Реальный случай: в апреле было оплачено 7 каналов связи, в мае — уже 52, хотя на каждого сотрудника при этом просто задублировали WhatsApp и Telegram по отдельным тарифам, реально работая в одном из двух. Такая переплата обычно всплывает вместе с зависшими сделками — оба симптома растут из одного и того же неконтролируемого процесса. За этим ростом почти всегда стоит одна и та же причина: у канала связи, как и у процесса, должен быть владелец, который отвечает за состав подключений, а не просто оплачивает счёт по факту. Пока эту роль не зафиксировали письменно, разрастание каналов идёт быстрее, чем любой квартальный аудит успевает его заметить. Проверка, которая занимает 15 минут раз в месяц и почти всегда себя оправдывает: выгрузить список активных подписок на связь из бухгалтерии, сверить с числом реально работающих сотрудников и спросить прямо — «этот канал кто-то использует сегодня, или это наследство от прошлого сотрудника, которого уже нет в компании». Обычно один такой вопрос закрывает 3–5 ненужных подписок за раз. Где ломается. Аудит каналов делают раз в год «для отчётности», а разрастание происходит за один-два месяца — к следующей проверке всё уже вернулось на исходную. С чего начать за одну неделю Минимальный рабочий контур на неделю — это не «внедрить систему управления процессами», а четыре конкретных действия: выбрать один процесс, выгрузить по нему цифры, назначить владельца, поставить один автоматический алерт. Дальше — по результатам первой недели решать, что делать со вторым процессом. Понедельник — выбрать процесс. Не тот, что кажется важным вам, а тот, на который чаще жалуются клиенты или коллеги: спросите прямо на планёрке. Вторник и среда — выгрузка из CRM: время прохождения каждой стадии за 30 дней, медиана и доля тех, кто застрял дольше нормы. Четверг — вслух назвать владельца стадии, где дольше нормы стоит больше 20% находящихся на ней сделок. Пятница — включить один алерт (вебхук в Bitrix24 или формула в Google Sheets), который сам напомнит о превышении нормы, — и на этом неделя заканчивается, дальше идёт по результатам. Вот как может выглядеть дашборд, который собирает владелец процесса после этой недели — те же цифры по стадии согласования, что и на диаграмме выше, но в виде рабочего экрана. Мониторинг: риск зависших сделок 12 сделок на согласовании 42%→25% стоят дольше нормы на согласовании 900 000→540 000 ₽ риск зависших, оценка Стадия Стоят дольше нормы Статус Согласование 25% (было 42%) Договор 25% Оплата 17% Дашборд не заменяет живой разговор на планёрке — он его сокращает. Раньше на обсуждение этой стадии уходило 20–30 минут, потому что цифры собирали на ходу устно; с готовым экраном на это нужно 5 минут — цифры уже перед глазами у всех, спорить не о чём, обсуждать можно сразу решение. Где ломается. Пытаются сразу описать все процессы компании — и застревают на описании, не доходя до автоматизации ни одного. Лучше один процесс за неделю, чем десять за квартал без результата. ИИ-связка: три промпта под разные задачи процесса Для управления процессами нужно минимум три разных промпта на трёх разных этапах: найти узкое место в данных (дешёвая модель, потому что задача формальная), оценить качество взаимодействия по чек-листу (дорогая модель, потому что нужно понимать контекст диалога), проверить структуру документа перед публикацией (снова дешёвая модель, задача техническая). Смешивать их в один универсальный промпт — способ получить средний результат по всем трём направлениям. Промпт 1 — найти узкое место в воронке (amoCRM API, дешёвая модель для классификации). На входе — выгрузка сделок с полями стадии и датами входа-выхода. Пример ответа модели: Промпт 2 — оценить звонок по внутреннему чек-листу (дорогая модель, нужен разбор смысла разговора). На входе — транскрипт звонка менеджера с клиентом. Пример ответа модели: Дорогую флагманскую модель для этой задачи иногда берут по привычке, хотя более дешёвая версия на том же промпте давала идентичный результат — мы проверяли на одних и тех же текстах, разницы не было. При десятках звонков в день экономия на токенах ощутимая, а дорогую модель стоит держать для случаев сложнее — например, для разбора конфликтных диалогов. Промпт 3 — проверить структуру документа перед публикацией (Google Диск + скрипт-триггер, дешёвая модель). На входе — текст инструкции или регламента. Пример ответа модели: Такая проверка снимает необходимость перечитывать документ на 20 страниц вручную каждый раз, когда его редактируют: автор загружает файл на Google Диск, триггер запускает скрипт, отчёт приходит в Telegram за минуту. Общее правило для всех трёх промптов: они возвращают только цифры и факты, без выводов и рекомендаций. Решение — чинить стадию, менять скрипт разговора или дописывать раздел документа — всегда принимает человек-владелец. Если дать модели право сразу советовать «что делать», решения начинают приниматься без разбора контекста, а ответственность за результат размывается между человеком и моделью так, что спросить потом не с кого. Экономика: что стоит автоматизация узкого места и что она даёт Настройка мониторинга одной стадии процесса занимает около 8 часов работы аналитика, эксплуатация — примерно 1 500 ₽/мес на API и хранение данных, а эффект от снижения риска зависших сделок в разобранном примере ≈ 360 000 ₽/мес (оценка). Отдельно от этого экономия часов на ручной сверке — около 20 000 ₽/мес (оценка). Это две разные строки, складывать их в один «эффект» нельзя: одна показывает снижение риска, другая — освободившееся время сотрудника, переведённое в деньги. Статья Часы / сумма Комментарий Настройка выгрузки и алерта ~8 часов разово труд аналитика или подрядчика, ставка ~1 500 ₽/час Разовая настройка, итого ~12 000 ₽ оценка Эксплуатация ~1 500 ₽/мес API, хранение, лёгкий скрипт-триггер Экономия часов на ручной сверке ~20 часов/мес × 1 000 ₽/час ≈ 20 000 ₽/мес оценка, поток, не разовая сумма Снижение риска зависших сделок ~360 000 ₽/мес оценка, это не гарантированная прибыль Посчитайте риск зависших сделок на своих цифрах — формула та же, что и в разобранном примере: сделки в месяц × средний чек × доля зависших. посчитайте на своих цифрах сделок на стадии средний чек, ₽ % стоящих дольше нормы риск ≈ {X} ₽ в месяц формула: сделки на стадии × доля стоящих дольше нормы, округление вниз до целых сделок, × средний чек; это оценка сверху, а не гарантированная потеря Пример с подстановкой: на стадии согласования 12 сделок, средний чек 180 тыс. ₽, доля стоящих дольше нормы падает с 42% до 25% — это 2 сделки, которые раньше стояли бы дольше нормы. 2 × 180 000 ₽ = 360 000 ₽/мес риска, который перестаёт висеть (оценка). Окупаемость по консервативной части (только экономия часов 20 000 ₽/мес против разовых 12 000 ₽ настройки) — меньше месяца. Окупаемость по риску в месяцах не считаем: это не гарантированный денежный поток, а вероятность потери, которая снизилась. Если в компании узких мест несколько, считать риск нужно по каждой стадии отдельно, а не суммировать риски всех стадий в одну общую цифру: риски по разным стадиям почти всегда частично перекрывают одни и те же сделки, и сложение задвоит проблему. Начинайте с той стадии, где абсолютная сумма риска больше — обычно это не самая заметная стадия по числу жалоб, а та, где чек выше среднего. Что мы не считаем эффектом. Если освободившиеся от ручной сверки часы никуда не пошли — просто «стало свободнее», а нагрузка не изменилась, — деньги здесь считать нельзя. Это перераспределение времени, а не эффект в кассе; фиксируйте его отдельно и проверяйте через квартал. Ещё одно уточнение по этой таблице: снижение риска зависших сделок — результат связки из двух мер, назначенного владельца стадии и автоматического алерта, а не одного алерта отдельно. Разделить их вклад по отдельности честно нельзя: без владельца алерты просто копились бы непрочитанными, без алерта владелец не знал бы, когда вмешаться. Пишем это прямо, а не выдаём эффект связки за эффект одного инструмента. Где это не сработало у меня Голосовые роботы для обзвона клиентов — пример автоматизации, которая заработала технически, но не окупилась экономически: при нашем объёме звонков срок окупаемости превышал два года. Мы отказались от разработки внутри и взяли оператора на часть ставки — дешевле и быстрее. Разработка «естественной» речевой системы требует записи тысяч комбинаций диалогов и обучения нейросети на них — это отдельный проект, а не настройка на пару часов. По прикидкам, она стоила бы около 350 000 ₽ разово (оценка) плюс постоянные правки под новые сценарии. Задача, которую должен был решать робот, — обзвон с напоминанием об оплате, около 50 звонков в месяц по 15 минут, то есть 12,5 часов человеческого труда; при ставке 1 000 ₽/час это 12 500 ₽/мес (оценка). Разовые 350 000 ₽ на робота против 12 500 ₽/мес живого оператора — вот и весь расчёт по срокам. Вторая история: без явного владельца автоматизация требует надзора буквально — бот слал алерты о зависших сделках три недели, но их читали и забывали, пока ответственного не назначили письменно. Третья история короче, но обиднее: мы автоматизировали сбор отчётов по звонкам через речевую аналитику, а разбираться в присланных цифрах всё равно приходилось руководителю отдела вручную — формат выгрузки не совпадал с тем, как он привык читать отчёт, и он просто пересобирал всё заново в своей таблице. Технически система работала правильно. Просто никто не спросил заранее, в каком виде человек реально готов эти цифры принимать. Общая причина у всех трёх провалов одна: мы запускали инструмент, а не решали измеримую заранее задачу, и цель либо не была сформулирована в цифрах, либо была занижена настолько, что успех и провал было невозможно отличить друг от друга. Пять типовых ошибок, из-за которых технически работающий проект не даёт результата, разобраны здесь: почему внедрение ИИ не работает — хотя технически всё запустилось . Зрелость по уровням: старт, квартал, год Зрелость управления процессами измеряется не количеством внедрённых инструментов, а тем, есть ли у компании привычка регулярно возвращаться к описанному процессу и перепроверять метрику. На старте достаточно одного описанного процесса и одной цифры; через квартал — системы алертов и владельцев на ключевых стадиях; через год — регулярного аудита, который проводится по календарю, а не по случаю. Старт (0–1 месяц). Один процесс описан в таблице «шаг — ответственный — время». Найдено одно узкое место по цифрам, а не по ощущениям. Назначен владелец стадии. Квартал (3 месяца). Автоматизирован мониторинг зависших сделок или задач хотя бы на одной стадии. Введён регулярный (не разовый) аудит каналов связи. У 2–3 ключевых процессов есть именованные владельцы, а не «отдел в целом». Год. Работает связка дашбордов по нескольким подразделениям, а не только по продажам. Регламенты действительно читают, а не держат на полке. Планёрки документируются автоматически, и это освобождает часы менеджеров. Ручные ежедневные отчёты, на которые раньше уходило по 30 минут в день, автоматизированы — что стоит за этими получасами, если их никто не считал заранее, показано в заметке: во что выливаются полчаса ручного отчёта, который никто не считал . Между уровнями нет жёсткой границы по календарю — есть граница по признаку. Компания переходит со старта на квартальный уровень не по календарю, а тогда, когда первое узкое место разобрано до конца: владелец назначен, метрика стабилизировалась, алерт работает без напоминаний. Если этого не произошло, лучше остаться на уровне старта дольше и не хватать второй процесс — распылённое внимание хуже, чем медленный, но доведённый до конца один разбор. Где ломается. Компания перескакивает со старта прямо на «год» — покупает дорогой дашборд без единого описанного процесса под ним. Инструмент работает, но показывает цифры, которым никто не доверяет, потому что источники данных не сверены. Чек-лист первого понедельника Выбрать один процесс с наибольшим числом жалоб за последний месяц. Выгрузить из CRM время прохождения каждой стадии этого процесса за 30 дней. Посчитать долю сделок или задач, застрявших дольше нормы на каждой стадии. Назвать вслух на планёрке: «Владелец этой стадии — [конкретное имя]». Настроить один автоматический алерт о превышении нормы (Bitrix24-вебхук, Google Sheets с формулой или Telegram-бот). Зафиксировать текущую сумму риска зависших объектов как точку отсчёта — сравнивать с ней через месяц. Поставить в календарь повторную проверку через 4 недели — без этого пункта всё остальное держится только на энтузиазме. Ваш первый шаг на этой неделе: выберите процесс, на который у вас больше всего жалоб, и опишите его в пять-семь шагов с временем каждого. Дальше вы сами увидите, что чинить. Как связать описание с автоматизацией и не увязнуть в бумажной работе — в бесплатном курсе . С чего начать именно вам Не пытайтесь описать всё. Возьмите один процесс, который вас раздражает больше всего, и пройдите по нему сами — от начала до конца, вместе с вашими людьми. Отметьте, где ждут, где переспрашивают, где переделывают. Дальше у вас будет выбор: чинить организационно или автоматизировать. И в вашем случае, скорее всего, первое даст результат быстрее. И про навык, ради которого всё это. Читать процесс по цифрам — дни на этапе, доля возвратов, кто ответственный — такой же базовый навык руководителя, как читать отчёт о прибылях. Я сам годами обходился без него: спрашивал у людей «как идёт» и получал ответ «нормально». Нормально означало 540 дней у одной сделки. Пока вы не видите процесс числами, вы им не управляете — вы его сопровождаете. ## Оценка работы менеджера по звонкам: как нейросеть разбирает весь поток и где она расходится с человеком URL: https://davidgerstein.pro/blog/ai-call-scoring/ Дата: 2026-08-27 Направление: Контроль качества Цифры: 66 звонков сверки · 25%→100% охват · 10 чек-листов Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Есть отчёт, которому никто не верит. У вас такой наверняка тоже есть — дашборд, который сделали, показали на планёрке и с тех пор не открывают. Наш был про качество звонков. Разбираю честно: почему цифрам не верили, что мы пересобрали и чем это кончилось. Если вы будете строить у себя оценку разговоров — здесь весь путь, включая места, где мы потеряли время. Старший менеджер отдела контроля качества — назовём её Ира — слушала звонки ушами. Тридцать в день, больше физически не помещалось: прослушать, сверить со скриптом, выставить оценку, записать замечание. В отделе продаж — восемь менеджеров, суммарно они закрывают порядка 120 звонков в день (около 2600 в месяц при 22 рабочих днях) — то есть Ира физически успевает разобрать примерно четверть общего потока, и не из-за лени отдела ОКК, а потому что на большее не хватает рук ни у кого. Так родилась идея ИИ-оценки звонков менеджеров: пусть нейросеть проверяет все разговоры, а не только четверть потока вручную. Цена необнаруженной ошибки здесь не абстрактная. Один сорванный контракт с ключевым дистрибьютором — менеджер на этапе согласования условий обещал не то, что было в прайсе, и это никто не услышал вовремя — обходится, по грубой оценке, до 2,4 млн ₽ (около 27% месячного оборота условной компании — оценка, легенда). А сама Ира тратит на прослушивание около четырёх часов в день — при ставке 1000 ₽/час и 22 рабочих днях это около 88 часов и 88 000 ₽ в месяц (оценка), которые уходят на то, чтобы просто услышать разговор, а не на то, чтобы что-то с ним сделать. Формула для прикидки на своих цифрах простая: часы прослушивания в день × рабочие дни в месяце × ставка контролёра = сколько компания платит за ту долю покрытия, которую физически вытягивает один человек. Оценка работы менеджера по звонкам: как это устроено Оценка работы менеджера по звонкам — это разбор его разговоров, а не отчёт по плану. Машина получает транскрипт, определяет тип разговора и оценивает его по чек-листу именно этого типа — с цитатой из разговора под каждым пунктом. В отделе продаж на восемь менеджеров таких чек-листов десять — по одному на каждый тип разговора. Доверять оценкам можно только после калибровки: 66 звонков отдел контроля качества оценил параллельно машиной и человеком и разобрал каждое расхождение. Это подняло охват контроля с 25% потока до 100% — при том, что человек физически успевал слушать четверть. посчитайте на своих цифрах часов прослушивания в день рабочих дней в месяце ставка контролёра, ₽/час ручное прослушивание ≈ {X} ₽ в месяц формула: часы прослушивания в день × рабочие дни × ставка контролёра Экран, которому никто не верил Если у вас есть отчёт, который вы сами не открываете неделями, — история дальше про вас. Первый вариант контроля выглядел как таблица в Excel: дата, менеджер, тема звонка, оценка от 1 до 10, комментарий. Заполняла её Ира вручную, после прослушивания. Экран честный, но узкий: он показывал мнение одного человека о четверти звонков компании. Остальные три четверти существовали только в записи на сервере телефонии — если вообще существовали, потому что часть звонков не сохранялась из-за сбоев интеграции. Когда решили автоматизировать оценку нейросетью, первая версия отчёта тоже не внушала доверия — уже по другой причине. ИИ оценивал звонки, но результат не с чем было сверить. Руководитель отдела прямо сформулировал условие: «Я не готов автоматизировать контроль качества, потому что не понимаю, работает ли методология, и не понимаю, сколько это будет стоить. Пока нет цифр, пока нет доказанной эффективности, я не готов». Похожий разрыв между «технически запустилось» и «реально работает» я разбирал в статье о том, почему внедрение ИИ не работает, хотя технически всё запустилось . Здесь это и стало задачей — не просто запустить оценку, а построить экран, на котором видно, где ИИ прав, а где нет. Что было не так: три причины Проверьте свои отчёты на эти три вещи — если найдёте хотя бы одну, вашим цифрам тоже не верят, просто вам об этом не говорят. Прежде чем сравнивать ИИ с человеком, пришлось понять, почему сама автоматическая оценка «плавала». Причины оказались разными, и чинить их пришлось по одной. Первая — не тот звонок. «Проблема любой ИИ, которая связана с любой CRM, заключается в том, что как система должна понять, что это именно тот звонок, который нужно оценить», — и это не риторика. Первый звонок клиенту может быть холостым (не дозвонились), следующий система может не захватить, а менеджер переводит сделку на нужный этап нерегулярно — значит, привязка «оценивать звонок при переходе на этап» ловит не всё и не всегда. Вторая — обрезанный транскрипт. Технически это выглядело так: расшифровку звонка вставляли в ячейку Google-таблицы, а у ячейки есть лимит на количество символов. Длинный разговор обрезался, и нейросеть оценивала неполный текст — соблюдение скрипта проверить по обрывку на середине фразы невозможно. Ира заметила это первой: несколько раз оценка ИИ по одному и тому же менеджеру резко расходилась с её собственной, и при разборе оказалось, что модели просто не хватило текста. Третья — нестабильность самой модели. «Оценка, она не всегда адекватна» — и это подтвердилось: один и тот же звонок при повторной обработке мог получить разные баллы. Для чек-листа с чёткими критериями (сказал/не сказал, спросил/не спросил) это не должно происходить, но происходило — из-за температуры генерации по умолчанию и из-за того, что модель иногда достраивала контекст там, где расшифровка была неоднозначной. Готового решения на все три проблемы на рынке не нашлось: «Нет ни одной системы на рынке, которая готова была бы оценивать вначале тип звонка, дальше его сегментировать и подключать к каждому типу отдельный промпт» — пришлось собирать конвейер самостоятельно, а не покупать коробочный сервис. Оценка работы менеджера после пересборки: что считает машина Схема, которую вы можете повторить. Ничего экзотического: запись, транскрипт, определение типа разговора, чек-лист под тип, оценка с обоснованием. Решение по каждой из трёх проблем было отдельным, но вместе они сложились в конвейер из пяти шагов. Триггер выгрузки — не переход по этапам, а обязательное поле. Вместо того чтобы заставлять менеджеров дисциплинированно двигать сделку по воронке, систему перестроили: аудиозапись прикрепляется к обязательному полю на этапе «встреча проведена» (или отмечается по факту завершения разговора для звонков). Именно заполнение этого поля — триггер для выгрузки, а не факт смены статуса сделки. Выгрузка с уникальными идентификаторами. Каждый звонок выгружается из CRM с тройкой: ID сущности (сделки), менеджер, время звонка. Это позволяет системе не путать, какой из нескольких звонков по одному клиенту нужно оценивать, и анализировать контекст предыдущих разговоров с этим же клиентом перед оценкой встречи. Определение менеджера и типа звонка. Нейросеть по записи определяет, кто говорит (по имени, названному в разговоре) и к какому из десяти типов относится звонок: первичный звонок лида, звонок продаж, вторичный звонок, встреча и так далее. Тип определяет, какой чек-лист применить — единого чек-листа «на все звонки» не бывает. Транскрибация с защитой от обрезки. В таблицу теперь попадает краткий фрагмент расшифровки плюс ссылка на полный текст, хранящийся отдельно (в Google Drive). Модель, оценивающая звонок, всегда обращается к полному тексту по ссылке, а не к обрезанному фрагменту в ячейке. Оценка по релевантному чек-листу и запись в личный кабинет руководителя. Результат — оценка, ключевые нарушения и цитаты из разговора — попадает в отчёт, доступный руководителю отдела продаж без ручной обработки. Настройка этого конвейера заняла не одну итерацию — на момент последнего разбора она шла уже четвёртый месяц и продолжает дорабатываться: то всплывает новый тип звонка, для которого нет чек-листа, то CRM возвращает запись без указания менеджера. ИИ-связка целиком: промпты и обвязка Схема конвейера: Bitrix24 (сделка, этап «встреча проведена», аудиозапись) → вебхук выгружает запись и метаданные (ID сделки, менеджер, время) → сервис транскрибации (Whisper API) кладёт полный текст в Google Drive и краткий фрагмент + ссылку — в Google Sheets → LLM-классификатор определяет тип звонка → LLM-оценщик берёт чек-лист под этот тип и выставляет баллы с цитатами → результат пишется обратно в таблицу и подтягивается в личный кабинет руководителя. Модель для транскрибации — дешёвая по определению (Whisper), она не «думает», а переводит звук в текст. Для классификации типа звонка и для оценки по чек-листу мы берём тоже недорогую модель (уровня GPT-4o-mini) — задача формализована чек-листом, дорогая модель почти не даёт прироста точности, зато счёт за токены растёт кратно при объёме в сотни звонков в месяц. Пример ответа модели: Второй промпт нужен не для оценки конкретного звонка, а для калибровочной сессии — он собирает расхождения между ИИ и человеком по менеджеру за период и ищет системные закономерности. Инженерная обвязка простая, без экзотики: скрипт на Google Apps Script по расписанию (раз в сутки) тянет новые записи из Bitrix24 по вебхуку, кладёт файлы в Drive, дёргает API транскрибации и LLM, пишет результат в Sheets. При сбое любого шага — сообщение в Telegram-канал отдела контроля качества с call_id и текстом ошибки, а не тихий пропуск строки. Ретраи ограничены тремя попытками на звонок: без этого ограничения легко повторить чужую историю, где ошибка в коде вызвала циклический запрос на 40 долларов за одну ночь — разбор этого случая есть в статье о реальных счетах за ИИ . Калибровка: 66 звонков и разговор с контролёром Это этап, который вы захотите сократить. Не сокращайте: без него вы не сможете ответить менеджеру на вопрос «а почему машина решила, что я плохо отработал возражение». Здесь обязан сказать про себя, иначе получится, что я умный задним числом. Я и сам долго считал калибровку перестраховкой: чек-лист формальный, модель читает текст — что там сверять. Обрезанный транскрипт нашёл не я. Его заметила Ира, и заметила ровно тем способом, который я считал лишним: её ручная оценка не сошлась с машинной, и она пошла разбираться. Так что если вам сейчас кажется, что месяц двойной работы можно проскочить, — это не глупость и не лень. Это нормальная первая мысль. Просто она дорогая: я на ней потерял время, которое мог потратить на доработку чек-листов. Прежде чем доверять автоматической оценке, отдел на протяжении месяца вёл параллельный учёт: каждый звонок оценивался и ИИ, и вручную — Ирой или другим специалистом контроля качества. Набралось 66 звонков с двумя оценками рядом. По каждому считалась дельта — разница между баллом ИИ и баллом человека. Именно на этом массиве стало видно то, что нельзя было увидеть на единичных примерах: расхождение не было равномерным. По формальным пунктам (назвал ли сроки, представился ли, уточнил ли объём) ИИ и человек почти всегда сходились. По пунктам, завязанным на тон и эмпатию — «проявил ли менеджер заинтересованность», «снял ли возражение мягко» — расхождение было заметно чаще. Это ожидаемо: такие критерии субъективны даже для двух живых оценщиков, не только для модели. Дальше — калибровочная сессия с каждым менеджером: руководитель разбирает одну его встречу, показывает автоматическую оценку и чек-лист, обсуждает точки согласия и расхождения. Смысл не в том, чтобы менеджер «принял» оценку, а в том, чтобы он помог её донастроить — указал, где чек-лист не учитывает специфику разговора. Без этого шага автоматику саботируют молча: соглашаются на словах, а по факту продолжают считать её несправедливой. Похожий сценарий тихого сопротивления команды разобран в статье о том, как внедрить контроль звонков и не остаться без менеджеров . Показатель До После Охват контролем звонков максимум 25% 100% Кто оценивает 1 специалист ОКК вручную ИИ + выборочная сверка ОКК Чек-листов на все типы звонков 1 универсальный 10, по типу звонка Транскрипт для оценки обрезался лимитом ячейки краткий фрагмент + ссылка на полный текст Проверено на расхождение с ручной оценкой — 66 звонков за месяц Срок параллельного запуска (человек + ИИ) — минимум 3 месяца На диаграмме — охват звонков контролем до внедрения ИИ и после. 25% до 100% после До: 660 звонков в месяц из ~2600 проверяла вручную Ира. После: все 2600 звонков проходят через ИИ-оценку, часть — с выборочной сверкой ОКК. Экран сегодня: что видит ваш руководитель отдела Правило, которое мы вывели: если для понимания «что делать сегодня» нужно больше двух кликов, отчётом пользоваться не будут. Ваш дашборд должен отвечать на вопрос, а не показывать данные. Личный кабинет руководителя теперь показывает не список случайных оценок, а срез по каждому менеджеру: тип звонка, балл по чек-листу, отмеченные нарушения с цитатой из разговора, и — отдельным столбцом на период калибровки — дельта с ручной оценкой. Провалиться в конкретный звонок можно одним кликом: открывается полный транскрипт по ссылке, а не обрезанный кусок. Личный кабинет руководителя · оценка звонков 2 600 звонков в месяц оценено 100% охват после внедрения 66 звонков сверки ИИ/человек Менеджер Тип звонка Балл Дельта с ОКК Менеджер 1 sales_call 75% 0.5 Менеджер 2 meeting 60% 2.0 Менеджер 3 first_call 90% 0.0 Похожую задачу — построение отчёта, который выдерживает придирчивый взгляд руководителя, а не просто «красиво выглядит» — я разбирал в материале о контроле звонков без отдела ОКК : там другая механика и другие цифры, но принцип тот же — сначала считать расхождение, потом доверять. После настройки компания планирует сократить минимум две штатные единицы контроля качества. Но это решение про штат, а не про сам инструмент — экономику ИИ-оценки я считаю отдельно, ниже. Экономика: что это стоит и что даёт Прикиньте свою: сколько у вас звонков в месяц, сколько из них слышит хоть кто-нибудь и во что вам обошёлся последний случай, когда менеджер пообещал клиенту то, чего не мог. Внедрение. Настройка конвейера — не разовая задача на день: она шла четвёртый месяц с постоянными доработками (новый тип звонка, отсутствие менеджера в записи, обрезка транскрипта). По грубой оценке — это 60–80 часов работы специалиста по автоматизации, при ставке около 1500 ₽/час — 90 000–120 000 ₽ (оценка, легенда). Эксплуатация. При объёме около 120 звонков в день (порядка 2600 в месяц) транскрибация Whisper API стоит примерно $0,006 за минуту звучания — для среднего звонка 5–7 минут это около $0,04 за звонок. Классификация типа и оценка по чек-листу дешёвой моделью (уровня GPT-4o-mini) добавляют ещё $0,02–0,04 за звонок (оценка: точная сумма зависит от длины транскрипта и промпта). Итого — около $0,06–0,08 на звонок, или при 2600 звонках в месяц — $150–210, то есть примерно 15 000–20 000 ₽ (оценка, курс ~100 ₽/$). Экономия. Ставка специалиста контроля качества в легенде — около 70 000 ₽ в месяц с налогами. Два освобождающихся места — это около 140 000 ₽ в месяц ФОТ, которые компания перестаёт платить за прослушивание вручную. Разовые затраты на внедрение (90–120 тыс. ₽) окупаются меньше чем за месяц такой экономии, а ежемесячные 15 000–20 000 ₽ за токены и транскрибацию — это около 10–15% от прежних затрат на ручной контроль. Если считать по стоимости одного звонка, разница нагляднее. Ручная проверка при охвате 25% (660 звонков в месяц из общего потока) обходилась в 88 000 ₽ ÷ 660 ≈ 133 ₽ за звонок. Автоматическая оценка при охвате 100% (2600 звонков) — это 15 000–20 000 ₽ ÷ 2600 ≈ 6–8 ₽ за звонок. То есть каждый проверенный звонок стал примерно в 15–20 раз дешевле, а число проверенных звонков выросло вчетверо. Формула для своего случая: возьмите объём звонков в месяц, умножьте на стоимость транскрибации и оценки одного звонка (обычно доли цента — несколько центов у дешёвых моделей), сравните с тем, что сейчас платите за ставки контролёров, умноженные на долю звонков, которую они физически успевают прослушать. Если разница в разы — есть смысл считать дальше; если нет, вероятно, объём звонков слишком мал, чтобы настройка конвейера окупилась. Показатель Значение (оценка, легенда) Разовые затраты на внедрение 90 000–120 000 ₽ (60–80 часов × ~1500 ₽/час) Ежемесячная эксплуатация ИИ (транскрибация + оценка) 15 000–20 000 ₽ при ~2600 звонках в месяц Стоимость одного звонка вручную (охват 25%) ≈133 ₽ (88 000 ₽ ÷ 660 звонков) Стоимость одного звонка через ИИ (охват 100%) ≈6–8 ₽ (15–20 тыс. ₽ ÷ 2600 звонков) Экономия ФОТ после сокращения 2 ставок ОКК ≈140 000 ₽ в месяц Срок окупаемости разовых затрат меньше месяца экономии ФОТ — но не раньше окончания 3-месячного параллельного запуска риск, который легко упустить Три месяца параллельного запуска — это период, когда компания платит дважды: и за автоматику, и за ставки тех же специалистов, которые пока проверяют её выводы. Экономика начинает работать только после того, как параллельный контроль закончен и решение о сокращении штата принято по факту, а не на веру. Ира теперь не слушает тридцать звонков в день руками — она разбирает расхождения и калибрует модель. Работа не исчезла, она сместилась туда, где действительно нужен человек: не выявить нарушение по формальному пункту чек-листа, а понять, почему модель и человек по-разному слышат одну и ту же интонацию. И вещь, которую стоит назвать вслух. Умение сверить машину с человеком и предъявить цифру расхождения — это отдельный управленческий навык, такой же базовый, как чтение отчёта о продажах. Руководитель, который может показать менеджеру дельту в 0,5 балла и объяснить, из какого пункта чек-листа она взялась, управляет качеством. Руководитель, который умеет только сказать «нейросеть поставила 60%», управляет ощущением качества. Разницу между ними видно на первой же планёрке, где менеджер начинает спорить. Я этот навык осваивал уже по ходу внедрения, отдельно ему меня никто не учил. Если вы будете собирать похожий конвейер, начните не с промптов, а с калибровки: тридцать-шестьдесят звонков, оценённых параллельно машиной и человеком, покажут вам, каким пунктам можно доверять сразу, а какие держать под ручной проверкой. Без этого шага вы получите красивые цифры, которым не верит ни один менеджер. Остальные узлы контура — выгрузка записей, транскрибация, чек-листы, экономика — собраны в полном разборе механики контроля звонков . Полная механика с разбором расхождений — в бесплатном курсе для руководителей . ## Мотивация отдела продаж: процент, который перестали платить URL: https://davidgerstein.pro/blog/kpi-menedzherov-oshibki/ Дата: 2026-08-27 Направление: Продажи Цифры: 20% маржа, 30% сокращение цикла, 1% комиссия РОПа Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы хоть раз меняли условия мотивации отдела продаж после того, как человек уже отработал квартал под старые, — у вас в компании лежит мина. Рванёт она не в отчёте, а в заявлении об уходе. Я рассказываю эту историю, чтобы вы не повторили: одно решение по мотивации обрушивает продажи быстрее любого кризиса. Планёрка, обсуждаем мотивацию отдела. Восемь менеджеров, оборот около 9 млн в месяц, средний чек в районе 180 тысяч. Саша, РОП, молчит, потом говорит: «Вот смотрите, у меня в таблице всё сходится третий месяц. А вы опять хотите пересчитать формулу». Классика — он верит только тому, что сам проверил на своей неделе. Разговор быстро сворачивает к главной теме встречи — ошибкам KPI менеджеров, которые обычно вылезают не в цифрах, а в правилах игры. Какие метрики ставить взамен — KPI менеджеров по продажам . И тут кто-то вспоминает старую историю. Год назад одному менеджеру обещали процент от прибыли — не от выручки, именно от прибыли его портфеля клиентов. Человек под это перестроил работу: меньше гнался за количеством сделок, больше — за маржой и за тем, чтобы клиент не отваливался через три месяца. Прибыль портфеля росла, но медленнее, чем закладывал собственник. И тогда долю забрали. Объяснение было простым: «Рост слабый — значит, управление неправильное». Это тот самый разрыв, о котором мы писали в материале лиды есть, а продаж нет — только тут разрыв был не между маркетингом и продажами, а между продажами и реальной прибылью. Вот это и есть ошибка KPI, о которой почти никто не пишет. Не в формуле дело. Дело в том, что правила поменяли после того, как человек уже сделал ставку на них. Как построить мотивацию отдела продаж, чтобы она работала Мотивация отдела продаж держится не на формуле, а на неизменности правил: условие действует только вперёд и никогда задним числом. В компании на 40 человек менеджеру начислили 3% от прибыли его портфеля, через 4 месяца долю забрали — человек недополучил 36 000 ₽ (оценка) и ушёл из компании. Сама формула при этом должна считать прибыль, а не вал: рабочая формула раскладывается на веса 0,5 на рост выручки, 0,3 на сокращение цикла и 0,2 на удержание клиента и считается автоматически по выгрузке из CRM. Ошибка, которую мы нашли на планёрке Проверьте, нет ли у вас такой же: она встречается везде, где мотивацию считают от вала, а не от прибыли. Мы стали разбираться, почему это вообще всплыло именно сейчас. Оказалось, у нас похожая мина заложена в текущей мотивации РОПа. Саша получает двойную выгоду: 1% с продаж своей команды и отдельно — комиссию за личные сделки. На бумаге это выглядит нормально. На практике это значит, что развивать команду ему невыгодно: личные продажи дают доход быстрее и предсказуемее. Собственник предложил перейти на единую схему — 1% что с личных продаж, что с командных, чтобы стимул был один: растить отдел, а не тянуть одеяло на себя. Решение правильное. Но внедрять его прямо сейчас побоялись. Причина честная: Саша пока мыслит горизонтом в один месяц. У него уже сложился определённый доход, и резкий переход мог демотивировать его раньше, чем он увидел бы эффект от роста команды. Договорились: два месяца двойная схема остаётся как переходная мера, к августу — только командная комиссия. Критерий перехода — полный боевой состав из четырёх менеджеров, а не календарная дата. О том, как мы вообще выстраиваем ввод новых людей в команду, — отдельная тема: онбординг, который работает без наставника-энтузиаста . Дальше — второй слой той же проблемы. Собственник посмотрел на классический KPI «рост продаж на 100 тысяч в месяц даёт плюс 20 тысяч прибыли» (это 20% маржи — цифра, которой мы дальше и оперируем) и спросил: а что, если тот же эффект на прибыль даёт не рост продаж, а сокращение цикла обслуживания на 30%? Или снижение операционных расходов на 20–30%? Деньги в компанию эти метрики приносят быстрее, чем новый вал сделок — просто потому что оборот денег ускоряется и затраты падают сразу, а не через квартал. То есть KPI, завязанный только на рост продаж, вознаграждает не того, кто реально усилил прибыль компании, а того, кто нагнал воронку. Ровно то же самое случилось год назад с тем менеджером: его судили по темпу роста, хотя он в это время улучшал маржу и удержание — метрики, которые в KPI просто не были заложены. Сколько потерял менеджер: расчёт, которого никто не делал Сделайте такой же расчёт по своим людям — вы увидите, за что они на самом деле получают деньги. На планёрке эту историю обсудили эмоционально, но никто не посчитал в рублях, о чём вообще шла речь. Восстановили задним числом, по памяти и по остаткам таблиц — получилось следующее (цифры оценочные, на легендированных пропорциях): Портфель клиентов менеджера давал оборот около 1,5 млн ₽ в месяц — это примерно одна шестая от оборота отдела в 9 млн ₽. При марже 20% прибыль портфеля — около 300 тыс ₽ в месяц. Обещанная доля — 3% от этой прибыли, то есть 9 000 ₽ в месяц сверху оклада. Совокупный доход менеджера с этой надбавкой был около 54 000 ₽ в месяц — то есть бонус за прибыль составлял примерно 17% его дохода. Схема продержалась 4 месяца, после чего долю забрали — менеджер недополучил ≈ 9 000 × 4 = 36 000 ₽ (оценка). При этом рост прибыли портфеля за этот период был — просто не такой, как хотел собственник: около 8% вместо ожидаемых 15%. То есть человека наказали не за отсутствие результата, а за то, что результат оказался медленнее плана, который никто заранее не проговаривал как порог. Именно отсутствие порога — это и есть корень ошибки. Если бы в условиях изначально стояло «доля выплачивается при росте прибыли от 15% за квартал, иначе действует базовая ставка», конфликта бы не было: человек знал бы правила заранее и либо согласился на них, либо нет. А так правила появились постфактум, и 36 тысяч стали не ценой невыполненного плана, а ценой доверия. Что сделали (или ещё думаем) Формулу целиком мы пока не переписали, и я не буду врать, что всё решено. Моя недоработка тут простая: год назад я не настоял, чтобы условия зафиксировали письменно, — казалось, что и так всем понятно. Сделали три вещи: Первое — зафиксировали письменно, что если KPI меняется, он не может действовать задним числом на уже отработанный период. Звучит очевидно, но именно это правило год назад никто не проговорил вслух, и получился конфликт, из-за которого человек ушёл с ощущением, что его обманули. Второе — двойную мотивацию РОПа не отменили резко, а дали переходный срок с понятным критерием выхода, а не просто «на глазок отменим, когда почувствуем». Третье — договорились, что в следующем цикле пересчёта KPI для менеджеров возьмём не только рост продаж, но добавим вес на скорость цикла обслуживания и на удержание клиента после оплаты. Ниже — как именно мы это считаем технически, а не просто «идея на словах». Саша, кстати, после истории про забранный процент перестал спорить про переходный период для своей мотивации. Сказал коротко: «Ну хоть предупредили заранее — уже не как в тот раз». Мотивация отдела продаж: как считать вклад в прибыль, а не вал Ваша формула должна учитывать маржу сделки, иначе вы платите одинаково за прибыльные и убыточные продажи. Формула, которую мы тестируем сейчас (веса черновые, откалибруем после первого месяца по факту): 0,5 на рост выручки, 0,3 на сокращение цикла и 0,2 на удержание клиента. При таких весах менеджер с меньшим ростом продаж, но быстрым циклом и высоким удержанием, набирает больше баллов, чем тот, кто просто нагнал вал — и это ровно та справедливость, которой год назад не хватило. kpi_score = 0.5 × revenue_growth_pct + 0.3 × cycle_reduction_pct + 0.2 × retention_rate × 100 Вес на рост продаж остался самым большим — 0.5, потому что выручка всё ещё главный источник кэша. Но 0.3 идёт на сокращение цикла (по факту — те самые 30%, о которых спрашивал собственник) и 0.2 на удержание клиента через 90 дней после оплаты. Это не заменяет план продаж, это его дополняет. Данные для расчёта берём из Bitrix24 через вебхук — выгрузка сделок за квартал по каждому менеджеру: ID, ASSIGNED_BY_ID, STAGE_ID, DATE_CREATE, CLOSEDATE, OPPORTUNITY, CONTACT_ID . Дальше это идёт в модель — считать средний цикл, ретеншн и рост к прошлому периоду руками для восьми менеджеров каждый месяц никто не будет, значит нужен промпт, который делает это по выгрузке. Пример ответа модели по двум менеджерам: Менеджер Рост выручки Сокращение цикла Удержание (90 дн.) KPI-скор 142 4,1% 28% 62% 22,7 158 11,3% −6% 41% 12,4 Менеджер 142 — KPI-скор 22,7 Менеджер 158 — KPI-скор 12,4 Видно сразу: у менеджера 142 рост продаж скромнее (4,1%), но он сильно сократил цикл (28%) и держит клиентов (62% ретеншн) — по старой формуле «только рост продаж» он проиграл бы менеджеру 158, хотя реально приносит компании больше устойчивой прибыли. Это ровно та ошибка, которая год назад случилась с человеком, у которого забрали процент. Инженерная обвязка: без дашборда формула — просто таблица на бумаге Отдельно от формулы мы делаем то, что нужно было сделать ещё год назад — динамический отчёт по воронке, обновляемый не раз в месяц, а ежечасно. Для каждого менеджера отчёт показывает: клиента, текущий статус, дату создания сделки, число дней в статусе и цветовой индикатор — зелёный/жёлтый/красный — по нормативным срокам стадии. Это тот же принцип, что мы описывали при разборе контроля качества звонков без ОКК : система не заменяет решение человека, она просто не даёт данным потеряться до момента, когда решение принимается. Без этого дашборда формула с весами на цикл и удержание — фикция: посчитать вручную для восьми человек за квартал средний цикл сделки и ретеншн через 90 дней никто физически не будет делать каждый месяц, значит расчёт просто не будет происходить, и разговор снова свернёт к вопросу «а кто сколько продал в штуках». Где ломается: первое — менеджер может искусственно держать сделку открытой подольше, если знает, что цикл ускорения оценивают только на закрытых сделках — тогда нормируйте расчёт по дате входа в стадию, а не только по факту закрытия. Второе — ретеншн через 90 дней ломается, если клиент ушёл не по вине менеджера, а потому что услугу оказали один раз и она больше не нужна — формула должна учитывать тип клиента, иначе накажет за физику продукта. Третье — если данные в CRM внесены с опозданием или задним числом (это отдельная и частая беда, разобранная в материале CRM врёт: как я поймал Битрикс24 на сдвиге дат ), скоринг посчитает искажённую картину, и KPI снова станет источником недоверия — тем же самым, из-за которого мы вообще затеяли пересчёт. Экономика: во что обходится ошибка KPI, если её не чинить Отдельный менеджер потерял 36 тысяч рублей (оценка выше). Но цена для компании считается иначе — через риск потери человека и стоимость его замены. Возьмём отдел из восьми менеджеров с оборотом 9 млн в месяц — то есть в среднем 1,125 млн на человека. Если из-за подобных историй с KPI хотя бы один менеджер в год увольняется (консервативная оценка — обычно уходит не «лучший», а тот, кто держит важный портфель), компания теряет: Простой и недобор нового человека — новый менеджер первые два месяца даёт в среднем 50% от нормы выработки: потеря ≈ 1,125 млн ₽ × 50% × 2 = 1,125 млн ₽ (оценка). Время РОПа и HR на подбор и онбординг — примерно 40 часов суммарно × 1 000 ₽/час (оценка ставки) = 40 000 ₽. Итого риск на одного ушедшего менеджера — около 1,17 млн ₽ в год (оценка), без учёта репутационного эффекта на остальных семь, которые теперь тоже не верят в письменные условия. Это не абстрактный «риск демотивации» — это конкретная цифра, которая объясняет, почему переходный период для Саши и письменная фиксация правил обошлись компании дешевле, чем повторение прошлогодней истории. Чек-лист на понедельник Проверить все действующие схемы мотивации на пункт: может ли условие измениться задним числом — если да, зафиксировать письменно, что не может. Для любой двойной или переходной схемы прописать не календарную дату отмены, а событие-критерий (как «четыре менеджера в штате» у нас). Выгрузить из CRM за прошлый квартал среднюю длину цикла и долю клиентов с активностью через 90 дней после оплаты — по каждому менеджеру, а не по отделу в целом. Прогнать промпт выше на реальной выгрузке и сравнить kpi_score с текущим рейтингом по валу продаж — посмотреть, кто теряет место в рейтинге и почему. Посчитать для своего отдела ту же экономику: оборот на менеджера × риск потери × стоимость замены — и решить, стоит ли откладывать пересчёт формулы ещё на квартал. Один вывод Ошибку KPI видно не в момент, когда считаешь формулу, а позже — когда человек чувствует, что его обманули по старым правилам. Поэтому единственное, что мы теперь проверяем перед любым пересчётом: не меняется ли KPI за спиной у того, кто уже сделал ставку на прежние условия. Если меняется — сначала предупреждаем и даём переходный срок, как с Сашей. Спор про саму формулу — веса 0.5/0.3/0.2, дашборд, промпт — это уже второй разговор, не первый. Пока формула не откалибрована на реальных месяцах, мы держим её как черновик и не привязываем к ней выплаты напрямую — только используем как второе мнение рядом с классическим планом продаж. За этой историей стоит навык руководителя, который придётся осваивать отдельно от умения считать формулы: проектировать мотивацию как контракт — с порогом, сроком и правилом изменения, — а не как настроение владельца в конкретном квартале. Мне этот навык дался дороже всего: я привык договариваться на словах, а словесные договорённости рассыпаются первыми, как только цифры идут не по плану. Проверьте свою систему мотивации на один вопрос: если вы завтра поменяете в ней правило, сможете ли объяснить каждому менеджеру, почему это справедливо? Если нет — не меняйте, пока не сможете. Как строить KPI, которые не разрушают доверие, — в бесплатном курсе . Что забрать вам из этой истории Любое изменение в мотивации ваших людей должно быть объяснимо на их языке и просчитано на их примерах до объявления. Иначе вы получите не рост показателей, а тихую потерю лучших сотрудников — самых мобильных на рынке. ## Транскрибация звонков обрывается на полуслове: техническая изнанка URL: https://davidgerstein.pro/blog/speech-analytics-fails/ Дата: 2026-08-27 Направление: Контроль качества Цифры: 66 звонков/мес сверки · дельта оценок · лимит символов в ячейке Если вы купили речевую аналитику и она не окупилась — вы не одиноки, и дело почти наверняка не в вендоре. Разбираю на своём примере, где именно теряется смысл. Речевая аналитика в CRM должна была снять с Иры рутину прослушивания звонков — и почти сняла, пока не начала путать несделанную работу с сделанной. Ира на планёрке кладёт на стол распечатку одного звонка и говорит: «Я не понимаю, за что ему поставили тройку. Он же весь скрипт отработал». Смотрим оценку ИИ — действительно тройка, комментарий модели: «менеджер не выявил потребность, не назвал цену». Слушаем запись — потребность выявлена на второй минуте, цена названа на седьмой. Звонок на девять минут. Значит, дело не в звонке. Ира почти три года слушала звонки ушами — сначала по тридцать в день, потом меньше, когда добавились текстовые каналы. Она первая сказала фразу, которая потом стала поводом для отдельного разбора: «оценка плывёт», когда транскрипт какой-то… короткий. Мы сначала подумали, что дело в качестве записи — шум, обрыв связи. Оказалось, дело не в записи. Цифры, с которых всё стало понятно Прежде чем разбирать причину, три числа для масштаба. Контролёр успевала слушать около 30 звонков в день — это примерно 25% потока при 120 разговорах ежедневно. Средняя длина разговора — 8–12 минут, то есть на прослушивание уходило до 4 часов рабочего дня. А ячейка таблицы, куда складывалась расшифровка, вмещала около 50 000 знаков — примерно 40 минут разговора. Всё, что длиннее, обрезалось молча. Последнее число и есть причина: система оценивала неполные разговоры как полные, и делала это уверенно. Проверьте у себя этот же лимит — он есть почти в любой таблице. Где транскрибация звонков теряет ваши данные Три места, и все три вы можете проверить у себя за полчаса, не привлекая подрядчика. Расшифровки хранились прямо в таблице — одна ячейка на один звонок. Удобно: открыл строку, увидел весь текст, рядом оценка. Но у ячейки в таблице есть технический лимит на количество символов. Длинные звонки — от десяти минут и дольше — в этот лимит не влезали. Текст обрезался молча, без ошибки, без предупреждения. ИИ получал не весь разговор, а его начало, и честно оценивал только то, что видел. Система не ошибалась — она оценивала то, что ей дали. Дело было не в модели, а во входных данных. Честно скажу: это моя недоработка. Я сам согласовал схему, где расшифровка лежит прямо в ячейке, и не проверил, сколько туда влезает. Ира приносила мне «оценка плывёт» трижды — и трижды я отвечал, что дело в качестве записи. Если вы сейчас узнали свою ситуацию, это нормально: на такой лимит наступают все, кто складывает длинный текст в таблицу. Дальше выяснилось второе: даже когда транскрипт полный, оценка одного и того же звонка при повторном прогоне не всегда совпадает сама с собой. «Оценка, она не всегда адекватна» — так это сформулировали на разборе. Прогнали один звонок трижды — получили не три одинаковых результата, а три близких, но разных. Для менеджера, у которого от этой оценки зависит премия, разница в один балл — это не мелочь. Что сделали: ссылка на расшифровку вместо текста в ячейке С обрезкой транскрипта решение нашлось простое, хотя дошли до него методом исключения. Вместо полного текста в ячейке таблицы теперь хранится короткий фрагмент — начало разговора для ориентира — и ссылка на полную расшифровку, которая лежит отдельно и открывается по клику. ИИ для оценки берёт полный текст из документа, а не то, что видно в таблице глазами человека. Разделили «что показываем человеку» и «что скармливаем модели» — вопрос, который вообще стоит держать в голове, когда решаете, какие данные можно отправлять в нейросети , а какие нет. Половина проблемы закрылась. Со вторым — нестабильностью оценки — решили не бороться в лоб, а сначала измерить масштаб. Ввели ручную сверку: каждый месяц отдел контроля качества берёт часть звонков — набралось 66 за первый месяц — и оценивает их вручную параллельно с ИИ. По каждому звонку считается дельта: разошлись ли оценки и насколько. Это не финальное решение, это диагностика — мы пока не готовы полностью довериться автоматической оценке, если не понимаем, насколько она вообще адекватна. Заодно ручная сверка помогает не превратить запуск автоматической оценки в саботаж со стороны тех, кого она оценивает — эта часть внедрения устроена так же, как в кейсе про контроль звонков без саботажа . Честно: если раньше Ира могла ушами прослушать от силы тридцать звонков в день, то ручная сверка 66 звонков в месяц с оценкой ИИ — это ещё около трёх часов её времени каждую неделю, которые раньше не тратились. Пока это не экономия, это цена за то, чтобы вообще понять, можно ли автоматизации доверять. Почему это касается не только транскрибации Проблема шире одной ячейки в таблице. Любая CRM-интеграция речевой аналитики сталкивается с вопросом: как система понимает, что это именно тот звонок, который нужно оценивать. Первый звонок может быть холостым, следующий — система не захватит, менеджер не всегда переводит сделку на нужный этап вовремя — это отдельная головная боль, разобранная в материале о том, почему менеджеры не вносят данные в CRM . Мы в итоге ушли от привязки к действиям менеджера — систему настроили так, что она сама выгружает все звонки по клиенту с уникальными идентификаторами и смотрит контекст предыдущих разговоров перед тем, как оценить последний. Про то, как это устроено технически на стороне речевой аналитики целиком — отдельный разбор в «Контроль качества звонков без ОКК» . Вывод с этой конкретной планёрки простой: прежде чем доверять оценке ИИ по звонкам, проверьте не модель, а трубу, по которой в неё льются данные. Обрезанный лимитом транскрипт и гуляющая от прогона к прогону оценка — не повод отказываться от речевой аналитики. Это повод не запускать её на всех менеджеров сразу, пока дельта между машиной и человеком не посчитана хотя бы на паре месяцев данных. Как эта труба устроена целиком, узел за узлом, — в разборе механики контроля качества звонков . Мы пока эту дельту считаем. Чем кончится — расскажем отдельно. И вот что я считаю главным во всей этой истории. Умение спросить у автоматики «а весь ли текст ты вообще видела» — это теперь навык руководителя, такой же обычный, как умение прочитать отчёт о деньгах. Раньше хватало доверия к подрядчику и к красивому интерфейсу. Сейчас тот, кто умеет проверить трубу с данными, стоит дороже того, кто умеет только требовать отчёт. Как замкнуть петлю «оценка → разбор → изменение» — в бесплатном курсе . И короткий чек-лист для вас: проверьте лимит ячейки, в которую складываются расшифровки; проверьте, доходят ли оценки до разбора с менеджером; проверьте, кто в вашей компании отвечает за то, чтобы по этим оценкам что-то менялось. Три проверки, полчаса времени — и вы будете знать, работает ваша аналитика или просто крутится. Мы месяцы платили за аналитику, которая исправно работала и никому не помогала. Не повторяйте мой заход: начните сегодня с лимита ячейки. ## Почему конверсия отдела продаж падает, если менеджеры работают как обычно URL: https://davidgerstein.pro/blog/konversiya-prodazh-oshibki/ Дата: 2026-08-26 Направление: Продажи Цифры: 14% вместо 23%; 20 зависших сделок; +1 п.п. конверсии в месяц Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы открыли отчёт, увидели, что конверсия отдела продаж падает, и первым делом пошли искать, кто из менеджеров просел, — вы уже идёте не туда и потеряете на этом недели. Я тоже так начинал. В большинстве случаев это неверный вопрос. Ниже — причины, по которым конверсия отдела продаж падает без предупреждения, и порядок проверки, который вы пройдёте за вечер вместо месяца поисков виноватого. Понедельник, утро, планёрка. РОП присылает сводку за прошедшую неделю: план продаж — 1 500 000 ₽, факт — 1 200 000 ₽. Закрыто 7 сделок из 16 запланированных. Конверсия отдела продаж — то есть доля лидов, доходящих до сделки, — упала до 14% при плане 23%. Разница в девять процентных пунктов — это не «немного не дотянули». В деньгах это 300 000 ₽ за неделю, пятая часть недельного плана, которая просто не случилась. Показатель План Факт Продажи за неделю 1 500 000 ₽ 1 200 000 ₽ Закрыто сделок 16 7 Конверсия лид → продажа 23% 14% Конверсия в встречу — 55% (49 встреч) Конверсия встреча → договор — 22% Отклонение среднего чека от базы +10% +13,5% план конверсии 23% факт конверсии 14% лид → встреча 55% встреча → договор 22% Дальше — разбор одной такой истории. Я прогонял похожую диагностику в нескольких отделах продаж, и каждый раз первая версия — «менеджеры расслабились» — оказывалась либо неверной, либо верной от силы на четверть. Настоящая причина пряталась глубже, и в обычном отчёте по конверсии её не видно вообще. Почему падает конверсия отдела продаж Чаще всего конверсия отдела продаж падает не из-за менеджеров, а из-за грязных данных в воронке: в разобранном кейсе 20 сделок, не двигавшихся дольше 90 дней, сидели в знаменателе и превращали честные 23,3% в 14% в отчёте. Проверка занимает вечер: выгрузите из вашей CRM сделки старше 90 дней без движения и пересчитайте конверсию отдела продаж без них. Разница в 5–10 процентных пунктов означает, что у вас проблема в данных, а не в людях. Цифра, которая не сходится Если у вас сейчас похожая ситуация — отчёт показывает одно, а ощущение от продаж другое, — начните с проверки самой цифры, а не с поиска виноватых. РОП — назовём его Саша, скептик со стажем, у которого «моя таблица меня ни разу не подводила», — открывает еженедельную выгрузку и видит: 14% против плановых 23%. Первая реакция — паника пополам со злостью. Вот его слова с той планёрки: «Конверсия очень низкая в продажу... менеджеры, которые очень сильные, стоят на 21 число, ну просто смешные показатели, и тут уже мне становится страшно, я начинаю переживать конкретно». Странность в том, что показатели, которые обычно падают вместе с конверсией — число звонков, количество встреч, — держались на месте. Встреч провели 49, конверсия в них — 55%, из встречи в договор — 22%. Отдел работал в том же темпе. Значит, дело не в лени. Саша начинает перебирать версии — и первые две отваливаются одна за другой. Версии, которые не подтвердились Показываю их специально: вы наверняка начнёте с тех же гипотез, и полезно знать заранее, что они, скорее всего, окажутся ложными. Версия первая: менеджеры разучились продавать. Самая простая мысль руководителя: сменить мотивацию, забрать лиды у слабых и отдать сильным, устроить разбор полётов. Но при проверке по каждому менеджеру картина не бьётся: у тех же людей неделей раньше конверсия была в норме. За семь дней навык продавать не пропадает. Версия вторая: лидов стало меньше или они хуже качеством. Проверили — поток на входе не просел, встреч проводили не меньше обычного. Тема отдельная, я разбирал её подробно в другом материале: если лиды приходят, а сделки не закрываются, смотрите « Лиды есть, а продаж нет ». Версия третья: сезонность. Отклонили быстро — сравнили с тем же периодом прошлого года, разница объясняла максимум пару процентных пунктов, не девять. Три версии — и ни одна не тянет на причину такого провала. Значит, дело не в людях, не в потоке лидов и не в рынке. Оставалось лезть в саму воронку. Раскопки: сделка, которой полтора года Вот тут и нашлась настоящая причина — и в вашей воронке она, скорее всего, тоже есть. При разборе воронки по каждому менеджеру вылезла деталь: у одного из «сильных» висела сделка без единого реального движения полтора года. Саша смотрел на неё как на живую — помнил разговор с клиентом, помнил его интерес. Проверка показала: последний реальный контакт был 17 месяцев назад, а все «активности» в карточке — технические пересохранения полей другими сотрудниками, которые с клиентом даже не разговаривали. Это классический случай, когда менеджеры не вносят в CRM реальные данные , а система вместо этого фиксирует технические правки как признак живой работы. Сделка все эти месяцы сидела в общей воронке и в знаменателе конверсии — как будто по ней идёт живая работа. Дальше выяснилось: таких сделок в отделе набралось двадцать. И вот здесь версия наконец сходится с арифметикой. Формула простая: конверсия = закрытые сделки ÷ (все сделки в воронке − зависшие без движения). Подставляем числа Саши: в воронке 50 сделок (7 закрытых ÷ 14% факта), из них 20 зависли без движения дольше 90 дней. Убираем зависшие — остаётся 30 живых сделок. Пересчитываем: 7 ÷ 30 = 23,3%. Это и есть плановая цифра, с точностью до десятых. Двадцать мёртвых карточек в знаменателе — это и есть те девять процентных пунктов, которые искали три дня. На диаграмме ниже — как меняется конверсия, если убрать зависшие сделки из знаменателя. 14% было 23,3% стало До чистки воронка считалась по 50 сделкам, из них 20 висели без движения 90+ дней (одна — 17 месяцев). После исключения зависших знаменатель — 30 живых сделок, и конверсия 7 ÷ 30 = 23,3% почти в точности совпадает с плановой цифрой. Показатель До чистки После чистки Сделок в воронке 50 30 Из них без движения 90+ дней 20 0 Закрыто сделок 7 7 Конверсия лид → продажа 14% 23,3% Решение по самой долгоживущей сделке было не «закрыть и забыть», а вынести её (и подобные) в отдельную воронку по типу работ — так она перестаёт искажать сроки и конверсию по основному потоку, но остаётся в работе, если по ней когда-нибудь снова пойдёт движение. Риск, о котором молчат гайды по CRM: не спешите удалять зависшие сделки, увидев провал в девять процентных пунктов. Пока карточка не разобрана вручную, неизвестно, мёртвая она реально или просто плохо промаркирована — например, клиент попросил вернуться к разговору через квартал, и это тоже нужно учитывать в воронке, просто отдельным статусом. Опасность в другом: если почистить воронку один раз, но не починить процесс — не завести светофор по срокам, не сверить критерии KPI с отделом, — через три месяца накопится новая партия зависших сделок, и разбор придётся начинать с нуля. Ещё две причины, о которых вы вряд ли подумали Обе встречаются часто и обе не видны в стандартном отчёте — проверьте их у себя отдельно. Зависшие сделки — самая частая находка, но не единственная. Здесь важна оговорка: обе причины ниже всплыли не в кейсе Саши, а в двух других отделах, где я проводил ту же диагностику по той же схеме. Эффекты ниже не складываются в одну сумму с недельным провалом Саши — это отдельные, самостоятельные случаи, показывающие, что за одинаковым симптомом («конверсия упала») может стоять разная причина. Причина вторая: менеджер тонет в задачах без контроля. В одном отделе при трёх продавцах (руководитель, его напарник и ещё один менеджер) продажи держались стабильно выше, чем после расширения до 6–7 человек. Причина оказалась не в квалификации новых людей, а в качестве работы с лидами: их стало больше, чем отдел успевал нормально обрабатывать. Конкретный эпизод: в мае отдел отвлёкся на разовый апсейл (сделка на 80 000 ₽ по отдельному запросу) и сделал за месяц всего 15 звонков новым контактам вместо плановых 60+. При этом по 19 тёплым лидам из апреля, до которых всё же дошли руки для повторного касания, получили 4 рекомендации — то есть один звонок редко решает всё, нужна регулярная работа с базой. Считаем цену этого простоя (оценка). Формула: (план звонков − факт звонков) × совместная конверсия «звонок → договор» × средний чек = недополученная выручка. Совместная конверсия в примере Саши — 55% × 22% = 12,1% (звонок → встреча → договор). Недостача звонков в майском эпизоде — 60 − 15 = 45. Подставляем: 45 × 12,1% ≈ 5 сделок, которые не случились. При среднем чеке по плану (1 500 000 ₽ ÷ 16 сделок ≈ 93 750 ₽) это 5 × 93 750 ₽ ≈ 469 000 ₽ упущенной выручки за месяц — оценка консервативная, конверсия взята из другого отдела как ориентир, а не как точное значение для майского эпизода. посчитайте на своих цифрах план звонков в месяц факт звонков конверсия звонок→договор, % средний чек, ₽ недополученная выручка ≈ {X} ₽ в месяц формула: (план звонков − факт звонков) × конверсия «звонок→договор» × средний чек; оценка сверху После того как контроль вернули — еженедельные отчёты по звонкам и напоминания по базе вместо разовых закрытий крупных сделок в ущерб потоку, — конверсия начала расти на 1 процентный пункт в месяц. Это тот же прирост, что получил в итоге и Саша после чистки воронки, но причина и лекарство — разные. Причина третья: KPI, которых отдел не видел в глаза. В третьем случае при анализе вторичных звонков выяснилось: систему оценки для этих звонков настроили под конкретные критерии, но менеджерам о них никто не сообщил. В результате люди «звонили, как звонили», а система штрафовала их за несоответствие правилам, о существовании которых они не знали. Формально — низкая оценка качества звонков и просевшая конверсия по этому участку воронки. По факту — конфликт не между менеджером и клиентом, а между менеджером и невидимой ему инструкцией. Решение здесь не «дообучить менеджеров», а сначала сверить ручную оценку с автоматической на одной выборке звонков за неделю: если расхождение большое, значит дело в критериях, которые нужно сначала показать отделу, а потом уже спрашивать за их выполнение. О том, как устроен такой автоматический контроль качества звонков без отдела ОКК , я писал отдельно. Причина Что нашли Эффект (оценка) Зависшие сделки в знаменателе 20 сделок без движения 90+ дней, одна — 17 месяцев конверсия 14% → 23,3% после чистки Менеджер без контроля тонет в задачах 15 звонков вместо 60+ за месяц из-за отвлечения на разовый апсейл ≈469 000 ₽ недополученной выручки за месяц KPI, неизвестные отделу критерии оценки вторичных звонков не доведены до менеджеров штраф системой за невыполнение правил, о которых не сообщили Что делать, если конверсия отдела продаж падает, а причина не ясна Порядок проверки: сначала данные, потом процесс, и только потом люди. Обратный порядок стоит вам отношений с командой и всё равно не даёт ответа. Читать воронку как данные, а не как ощущение, — это отдельный навык руководителя, и он стоит дороже умения давить на отдел: давление даёт всплеск на неделю, чистый знаменатель — управляемую цифру на год. Порядок действий простой, но именно его обычно пропускают, бросаясь сразу к людям. Сначала — чистка воронки. Выгрузите сделки старше 90 дней без движения и посчитайте конверсию без них по формуле выше: закрытые ÷ (все сделки − зависшие). Если разница с текущим отчётом — 5–10 процентных пунктов, вы только что нашли грязные данные, а не плохих менеджеров. Долгоживущие нетипичные сделки лучше не удалять из системы, а выносить в отдельную воронку — так они не портят сроки и конверсию по основному потоку. Дальше стоит завести отчёт, который обновляется чаще, чем раз в неделю: по каждому менеджеру — клиент, статус сделки, дата создания, число дней в текущем статусе и простой индикатор-светофор (зелёный/жёлтый/красный) по нормативным срокам стадии. Это не убирает саму проблему, но делает застрявшие сделки видимыми до того, как они накопятся до двадцати штук и испортят месячный отчёт. Следующий шаг — проверка критериев. Возьмите одну и ту же выборку звонков за неделю и оцените её вручную и автоматически. Большое расхождение значит, что дело в самих критериях оценки, а не в людях, которые по ним работают. И отдельно стоит спросить у отдела: они вообще знают, по каким KPI их меряют? Если ответ «нет» — сначала сверьте оценки, потом уже вводите санкции за невыполнение правил. И отдельно — контроль потока задач менеджера. Если человек параллельно с плановыми звонками тянет разовые крупные сделки или административные задачи, отчёт по конверсии этого не покажет, а звонки при этом молча просядут вдвое-втрое. Простое сравнение «план звонков / факт звонков» за неделю ловит это быстрее, чем недельный отчёт по деньгам. Саша после чистки воронки получил не идеальные 23%, но честные 23,3%, с которыми можно работать — рост пошёл дальше, на 1 процентный пункт в месяц, потому что усилия перестали тратиться на разбор несуществующей проблемы. Отдельная и куда более мелкая статья расходов — время самого разбора: на диагностику одной зависшей карточки (поднять историю, найти последний реальный контакт, обсудить с менеджером) уходит в среднем 15–20 минут (оценка). На 20 карточек это 5–6 часов рабочего времени руководителя, при ставке около 700 ₽/час (оценка) — порядка 3 500–4 000 ₽ прямых временных затрат. Сумма скромная по сравнению с 469 000 ₽ упущенной выручки из майского эпизода — но именно эти полтора часа в неделю на разбор мёртвых сделок чаще всего оказываются той работой, которую руководитель не находит времени сделать, пока не приходит в панику от цифры 14% на планёрке. Готовый промпт: проверьте свою воронку за 10 минут Это ваш инструмент первой помощи: подставляете выгрузку — получаете гипотезы с оценкой влияния на деньги. Возьмите его как есть, подставьте свою выгрузку — и получите список гипотез, отсортированных по влиянию на деньги. Если под рукой выгрузка CRM, но разбираться в формулах руками некогда — скопируйте промпт ниже в любую нейросеть вместе с выгрузкой сделок (клиент, статус, дата создания, дата последнего движения, сумма): Пример ответа модели на такую выгрузку: Сделайте это на своей выгрузке сегодня, а разговор с отделом отложите до завтра: с цифрами он займёт двадцать минут вместо часа взаимных претензий. Как встроить такую диагностику в еженедельный ритм — в бесплатном курсе . И короткий вывод для вас. Падение конверсии почти никогда не бывает там, где его ищут в первый день. Начинайте с данных: проверьте, не тянутся ли в отчёт старые сделки, не изменился ли состав источников, не сдвинулись ли даты. В моей практике три из четырёх «падений» объяснялись именно этим — и ни одно из них не было виной менеджеров. ## Работа с клиентской базой, до которой семь лет не доходили руки: лиды, отказавшие когда-то, и дневник их реанимации URL: https://davidgerstein.pro/blog/reanimaciya-bazy-avtomatizaciya/ Дата: 2026-08-26 Направление: Продажи Цифры: 7 лет паузы · 1,5 года без движения одна сделка · 600 000 ₽ за первый месяц реактивации Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы за последний год ни разу не открывали список тех, кто когда-то интересовался и не купил, — у вас в CRM лежит выручка, за которую вы уже заплатили. Дважды: рекламой и зарплатой менеджеров. Я сам годами смотрел на этот список как на архив. Оказалось — это склад. У вас в базе лежат сотни клиентов, которые когда-то интересовались и не купили. Вы за них уже заплатили — рекламой, временем менеджеров, работой маркетинга. И почти наверняка сейчас с ними никто не работает. Это самая дешёвая выручка, которая у вас есть: не нужно платить за привлечение, человек уже знает вашу компанию. Ниже — месяц работы по неделям: что мы сделали с такой базой, что сломалось и сколько это дало. В марте у нас случайно всплыла база отказников семилетней давности. Причины отказа стояли в CRM с тех времён: «не готов платить», «не готов разговаривать», «заявка не оставлена». Часть этих людей взяла трубку сейчас — и купила. И дело тут не в нашей гениальности: семь лет назад с ними работали менеджеры низкой квалификации, которые не дожали живого клиента. Так родилась идея автоматизации реанимации клиентской базы: не звонить всей истории руками, а сначала прогнать её через ИИ-классификатор. Дальше мы посчитали, во что это обходится, если так и оставить базу лежать. У нас 8 менеджеров, оборот около 9 млн ₽ в месяц, средний чек — 180 тысяч. Если хотя бы 10% сделок в pipeline зависает без движения дольше нормативного срока — это около 900 000 ₽ в месяц (9 млн × 10%), которые просто стоят и портят статистику. Не теряются безвозвратно, а замораживаются: никто не звонит, никто не закрывает, никто не убирает из воронки. Один такой замороженный контакт нашёлся уже в первую неделю работы — и стал личным уроком для нашего РОПа Саши. Подробности — ниже. Работа с клиентской базой: как реанимировать отказников и что это даёт Реанимация базы — это выгрузка сделок, которые стоят без движения дольше 90 дней, автоматическая классификация причины паузы и тона обращения дешёвой моделью, и звонок живого менеджера по готовой рекомендации. В компании на 40 человек первый месяц такой работы дал 4 сделки на 600 000 ₽ — из контактов, которые отказали до семи лет назад. Настройка стоила около 25 часов работы аналитика и разработчика, эксплуатация — единицы тысяч рублей в месяц на токены. Оговорка, без которой цифра врёт: деньги приносит не модель, а менеджер. Бот отбирает, с кем безопасно разговаривать, и подсказывает тон; закрытие сделки остаётся человеческой работой. И начинать нужно на «паузниках», а не на активной воронке — один неудачный тон в живой сделке съест всю экономию. Неделя 0: что решили Идея простая до банальности: не звонить всей базе руками, а сначала прогнать историю диалогов через модель, чтобы понять — с кем вообще имеет смысл разговаривать и как. Решили тестировать не на активных клиентах (там цена ошибки высокая — можно спугнуть человека, который платит прямо сейчас), а на «паузниках»: тех, кто стоит без движения месяцами и годами. Логика — минимизировать риск на тех, кому терять уже нечего, и только потом масштабировать на живую воронку. Задача бота на входе: прочитать историю переписки и звонков, определить причину паузы, выбрать тон обращения — и контролируемо, не массово, а пакетами, пинговать. Не «у нас акция, возвращайтесь», а обращение, которое отталкивается от того, почему человек ушёл в тот раз. Неделя 1: сегментация и неожиданная находка Первое, что вам нужно сделать со старой базой, — разделить её. Обзванивать всех подряд бессмысленно: у вас там и те, кто ушёл к конкуренту, и те, кому было просто рано. Первым делом полезли смотреть воронку целиком — иначе бот классифицировал бы мусор вперемешку с живыми сделками. И почти сразу нашли клиента без движения полтора года. Саша, наш РОП, сначала уверял, что это активная сделка: «моя таблица меня ни разу не подводила, я её помню, там просто долгий цикл». Открыли карточку — последний контакт полтора года назад, ни одного звонка, ни одного письма с тех пор. Решение — не удалять и не пытаться дожать здесь и сейчас, а вынести такие случаи в отдельную воронку по типу работ. Иначе они искажают среднюю длительность сделки и путают аналитику: система думает, что у нас нормальный цикл — полтора года, хотя на деле это просто забытая карточка. Саша после этого перестал спорить с дашбордом. Не потому что поверил в ИИ вообще, а потому что конкретно эта сделка была его личной, и он был уверен в обратном. Это тот случай, когда одна найденная ошибка убеждает сильнее десяти презентаций. Неделя 2: что сломалось Читайте внимательно — у вас сломается то же самое, и лучше знать об этом заранее. Сломалось не на стороне бота, а на стороне людей. Мы включили контроль вторичных звонков по паузникам — то есть после того как бот определял тон и повод, живой менеджер должен был позвонить в соответствии с этими рекомендациями. Оказалось, что менеджеры вообще не знали, по каким критериям система оценивает их звонки. Критерии были заведены в CRM для оценки ИИ, но их никто не довёл до отдела. В итоге менеджеры звонили «как звонили всегда», а система штрафовала их за несоответствие правилам, о которых они не подозревали. Скажу прямо: это была моя ошибка, не менеджеров. Критерии я завёл в CRM сам и решил, что раз они записаны — значит, отдел про них знает. Отдел не знал. Я две недели читал отчёты, где люди «нарушают правила», и злился на людей, вместо того чтобы проверить, доводил ли эти правила до них хоть кто-нибудь. Если у вас так же — вы не одиноки: на этом спотыкается почти каждый, кто включает контроль раньше, чем объясняет. Пришлось откатиться на шаг назад: сначала свести оценки бота и оценки РОПа вручную на одной и той же пачке звонков, убедиться, что они совпадают хотя бы в половине случаев, и только после этого объявлять отделу правила игры. Запускать контроль до того, как правила прозрачны — гарантированный саботаж. Параллельно всплыла ещё одна причина, почему база вообще зависла: в мае отдел отвлёкся на побочную задачу (апсейл по стороннему направлению) и вместо плановых 60+ звонков новым контактам сделал 15. 60 план в мае 15 факт в мае На диаграмме — план и факт звонков новым контактам в мае: отдел отвлёкся на побочную задачу по апсейлу, и база осталась без плановых касаний. Зато повторное касание по 19 тёплым лидам из апреля дало 4 рекомендации от клиентов — это около 21% конверсии повторного касания в рекомендацию, для сравнения: конверсия «первого звонка в никуда» в этой базе была близка к нулю. Повторное касание (19 лидов) 21% Один звонок в холодную ≈0% На диаграмме — разница между разовым холодным звонком и повторным касанием по той же базе. Вывод для нас был предельно практический: один звонок ничего не решает, работает только регулярный повторный контакт — именно это мы и заложили в логику бота дальше. Неделя 3–4: как выглядит автоматизация реанимации базы целиком Схема пайплайна, до которой мы дошли к концу месяца: Выгрузка сделок без движения из CRM (по расписанию) Классификация причины паузы и тона — дешёвая модель Фильтр «безопасно для контакта» — только те, кто когда-то отвечал Запись рекомендации в карточку + очередь на звонок менеджеру Платформа — amoCRM. Триггер — вебхук по смене статуса сделки на «долгая пауза» (мы завели отдельное правило: если 90+ дней без активности — статус меняется автоматически). Обработчик — облачная функция, которая забирает карточку через API, собирает историю переписки и отправляет в модель. Модель на первом шаге — дешёвая (класса GPT-4o-mini): это массовая пакетная разметка тысяч старых карточек, где важна стабильность и цена, а не креативность. Дорогая модель включается только на следующем шаге — когда нужно сгенерировать персональный текст обращения для уже отфильтрованного, «безопасного» сегмента. Промпт для первого шага — тот, с которого мы начали и который почти не меняли за месяц: Пример ответа модели на реальной по структуре карточке: Инженерная обвязка: обработчик крутится на облачной функции с ежедневным крон-запуском по выгрузке через API amoCRM, плюс отдельный вебхук на ручную смену статуса. Результат классификации пишется в кастомное поле сделки и дублируется в гугл-таблицу для контроля РОПа — так Саша видит очередь на звонок без захода в CRM. Если модель не вернула валидный JSON — два автоматических повтора, при третьей ошибке лид падает в очередь «на ручной разбор», а в Telegram-канал отдела уходит алерт с ID сделки. Расходы на токены мы отслеживаем отдельно — как именно считать реальные счета за ИИ, писал в разборе по своим счетам . Визуализация: что показала первая пачка Ниже — то, что было видно на дашборде к концу первого месяца. Это не эффект только от бота: часть цифр — это провал в работе с базой ещё до автоматизации, который и стал поводом её запустить. Метрика Значение Что показывает Звонки новым контактам (май, план vs факт) 15 из 60+ отдел отвлёкся на побочную задачу, база осталась без касаний Повторное касание тёплых лидов (19 контактов) 4 рекомендации (≈21%) один контакт не работает, нужна серия касаний Прирост конверсии при усиленном контроле (3 менеджера vs 5 без контроля) +1 п.п./мес дисциплина в работе с базой решает больше, чем численность отдела Мартовская реактивация паузников 4 сделки / 600 000 ₽ результат совместной работы бота-классификатора и живых менеджеров Прямая связь между звонком «как обычно» и звонком «по рекомендации бота» пока не измерена отдельно — мы не разносили эти два потока в первый месяц, и это наша методическая ошибка, о которой честно пишу ниже. Экономика: что это стоит и что дало Ваша арифметика будет похожей: затраты — время менеджеров на обзвон отобранных контактов, отдача — сделки, за привлечение которых вы уже заплатили однажды. Внедрение здесь не про покупку модели — про часы, которые ушли на выгрузку, разметку и обвязку. По нашей оценке ушло около 25 часов работы аналитика и разработчика суммарно: настройка вебхука, тестовый прогон на 200 карточках, доработка промпта после первых ошибок классификации. При условной ставке 1 500 ₽/час (для специалиста уровня middle) это порядка 37 500 ₽ разовых затрат на настройку. Эксплуатация — токены на пакетную классификацию тысяч старых карточек стоят немного: единицы тысяч рублей в месяц (берём консервативно 3 000 ₽/мес) при разовой обработке базы такого объёма, дальше — только новые «паузники», которых прибавляется по несколько десятков в месяц. Вклад бота отдельно от менеджеров — это не деньги в кассе, а сэкономленное время на квалификацию базы. Формула для своего случая: время на карточку вручную × количество карточек × ставка часа менеджера = стоимость ручной квалификации. У нас: 15 минут на карточку × 200 контактов = 3 000 минут = 50 часов; 50 часов × 1 000 ₽/час (ставка менеджера) ≈ 50 000 ₽ ручной работы, которую забрал на себя классификатор за пару дней прогона. посчитайте на своих цифрах минут на карточку карточек в партии ставка менеджера, ₽/час стоимость ручной квалификации ≈ {X} ₽ формула: минуты на карточку × количество карточек × ставка часа ÷ 60; оценка сверху, без учёта разгона на новые партии Если сложить это в грубую окупаемость первого месяца: 50 000 ₽ сэкономленного времени на квалификацию минус 37 500 ₽ настройки минус 3 000 ₽ токенов ≈ 9 500 ₽ чистой экономии уже в первый месяц — и это без учёта самих закрытых сделок, только время. С каждым следующим месяцем настройка не повторяется, платить нужно только за токены и время на новые партии карточек, поэтому реальная экономия со второго месяца растёт. Статья Сумма (оценка) Разово / ежемесячно Настройка (25 ч × 1 500 ₽/ч) ≈ 37 500 ₽ разово Токены на классификацию ≈ 3 000 ₽ ежемесячно Ручная квалификация 200 карточек вручную (альтернатива) ≈ 50 000 ₽ разово, если делать руками Чистая экономия в первый месяц (без учёта закрытых сделок) ≈ 9 500 ₽ разово Эффект от самой реактивации нельзя целиком приписать боту — здесь эффект составной. Бот отфильтровал безопасный сегмент и подсказал тон, но разговор и закрытие сделки — целиком работа живого менеджера с опытом. Без A/B-теста (мы его не ставили — см. методическую ошибку выше) честная консервативная раскладка вклада выглядит так: бот дал точный список «с кем можно говорить и как» и снял часы ручного разбора старых карточек — это ускорение и снижение риска спугнуть паузника неудачным тоном, а не сама конверсия в оплату. Решающий разговор, дожим и закрытие 4 сделок на 600 000 ₽ — заслуга менеджеров, а не модели. Если бы не бот, эти же 4 сделки, скорее всего, тоже нашлись бы — но позже, ценой ручного прогона всей базы, и с риском, что часть «паузников» получила бы неподходящий тон обращения и окончательно ушла. Отдельно — риск, который бот снял, а не создал: 900 000 ₽/мес зависшего pipeline при 10% сделок без движения (оценка) — это не деньги, которые бот заработал, а деньги, которые перестали быть невидимыми. Дальше их всё равно нужно закрывать руками. Где ломается. Не согласовали правила вторичного звонка с отделом заранее — менеджеры саботируют рекомендации бота молча: просто звонят по-старому, а в отчёте это выглядит как «бот ошибся». Тестировали сразу на активной базе, а не на замороженной — один неудачный тон обращения стоит живой сделки, а не только раздражённого «паузника». База не сегментирована по срокам паузы — классификатор одинаково относится к лиду, который молчит месяц, и к тому, кто молчит семь лет, а это разные разговоры и разная вероятность закрытия. Что осталось нерешённым Мы прогнали через бота только паузников старше 90 дней с суммой сделки выше среднего чека — то есть меньшую часть базы. Остальное ждёт: часть контактов вообще не сохранила читаемую историю переписки, и классификатору там нечего анализировать. Отдельно не решён вопрос со скорингом и распределением реактивированных лидов под конкретного менеджера — по опыту, если отдать их первому свободному, а не тому, кто умеет закрывать сложные случаи, конверсия провалится так же, как семь лет назад. Это следующий шаг, и пока это ручная работа Саши. Похожая проблема с квалификацией отказников без прозрачных критериев разбиралась ещё в одной статье — если у вас в отделе тоже штрафуют менеджеров за невыполнение правил, о которых те не знают, там есть разбор, как навести порядок без репрессий: внедрение контроля звонков без саботажа . Чек-лист: с чего начать в понедельник Выгрузить из CRM все сделки без движения дольше 90 дней и отдельно — дольше года. Вынести долгожителей в отдельную воронку по типу работ, чтобы не портили аналитику по срокам. Прогнать первые 100–200 контактов через классификатор причины паузы на дешёвой модели, не масштабируя сразу на всю базу. Посчитать свою окупаемость по формуле: часы настройки × ваша ставка + токены — против часов ручной квалификации × ставка менеджера на то же количество карточек. Согласовать с РОПом единые критерии вторичного звонка до включения бота в работу отдела. Настроить лог ошибок и алерт в Telegram на случай сбоя классификации или пустого ответа модели. Тестировать только на «паузниках» минимум месяц, прежде чем трогать активную воронку. Кстати, если после запуска подобной автоматизации выясняется, что без ручного контроля она перестаёт работать через пару недель — это не редкость, а типовой сценарий, разобранный в статье про автоматизацию, требующую надзора . И главное, что я вынес из этого месяца: новое здесь не бот. Новое — управленческий навык смотреть на базу как на актив со сроком годности и уметь поставить машину на ту часть работы, где человек просто устаёт. Я считаю, руководитель, который это умеет, скоро будет стоить заметно дороже руководителя, который умеет только раздать список на обзвон. Навык осваивается за месяц. Сам он не появится. Что сделать вам: выгрузите контакты, которые обращались полгода-год назад и не купили. Посчитайте, сколько их. Если больше сотни — у вас есть недельная задача, которая может закрыть месячный план без единого рубля на рекламу. Как сегментировать базу и поставить реактивацию на автомат — механика в бесплатном курсе для руководителей . ## Почему UTM-метки теряются у части лидов — и как ИИ восстанавливает источник URL: https://davidgerstein.pro/blog/utm-metki-ii/ Дата: 2026-08-25 Направление: Маркетинг Цифры: 10–15% лидов без источника, до 30% в декабре, ~18 лидов/мес теряют разметку (оценка) Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас в отчёте есть строка «источник не определён» — вы принимаете решения по неполной картине. Вопрос только в том, насколько неполной: у нас таких лидов было около 15%, и это оказались не случайные крохи, а вполне конкретные деньги. Скажу сразу: я эту строку полгода считал погрешностью и не трогал. Моя ошибка — смотрел на процент, а не на деньги за ним. Ниже — как мы отдали «ничью» часть машине, что вышло и что пока нет. Планёрка, вторник, отчёт по лидам за месяц. Оля показывает воронку — и в самом низу таблицы строка «источник: —», то есть без UTM-метки. Пятнадцать процентов. Все молчат секунды три, потом кто-то спрашивает: «Это баг?» Не баг. Это люди, которые почистили куки, включили блокировщик рекламы или зашли с приватной вкладки. UTM-метки теряются ещё до того, как форма отправлена. В обычный месяц таких 10–15%. В декабре, когда трафик другой и часть заявок идёт через мессенджеры без ссылки на конкретное объявление, доля подскочила до 30%. Треть лидов — и мы не знаем, откуда они. Дальше выясняется вторая часть проблемы, ещё неприятнее первой: часть лидов, наоборот, размечена — но два-три раза. Одна точка входа плодит дубликаты в CRM, и конверсия по отчёту падает день ото дня, хотя реальная ситуация не меняется. Руководитель нашёл это случайно, листая утренний отчёт: цифры не бились, а виноват оказался не отдел продаж, а склейка данных. Что делают с лидами без UTM-метки — и почему это дорого Скорее всего, у вас сейчас первый вариант — и он самый дорогой. Первый инстинкт — доразметить руками. Оля неделю сидела и вручную сопоставляла заявки без метки с рекламным кабинетом: смотрела время визита, страницу входа, текст обращения, пыталась угадать источник по стилю формулировок. Неделя рабочего времени маркетолога — это примерно 40 часов. По ставке около 1 000 ₽/час (оценка) — 40 000 ₽ в месяц уходит просто на то, чтобы понять, откуда пришли люди, которые и так уже стали лидами. При этом решение неточное: человек угадывает источник по интуиции, а не по системе признаков. И в отчёт всё равно попадает пометка «предположительно», которую руководитель на планёрке видит как повод не доверять цифре целиком. Один из участников тогда прямо сказал: «Отсутствие информации — это отсутствие рычагов давления, и это меня прям очень сильно бесит». По сути — без источника нельзя ни хвалить канал, ни резать его бюджет с уверенностью. Разделить конверсию по каналам (условно Директ и Яндекс) без нормальной атрибуции вообще не получается — и это одна из причин, почему лиды есть, а куда уходят деньги между маркетингом и продажами — непонятно . Здесь же речь только про один узкий кусок: что делать с лидами, у которых просто нет метки. Что попробовали: машина вместо ручной разметки Логика, которую вы можете повторить: если человек по косвенным признакам понимает, откуда пришёл лид, значит эти признаки формализуемы — а раз формализуемы, их можно отдать машине. Решили не гадать руками, а отдать черновую сортировку модели. Идея простая: у лида без UTM всё равно остаётся след — referrer, user agent, страница входа, время визита, текст заявки. По этим косвенным признакам модель не восстановит метку дословно, но может дать вероятностную гипотезу источника и объяснить, почему так решила. Дальше маркетолог смотрит только на те случаи, где уверенность низкая, а не разбирает всю пачку заново. Технически это выгрузка из amoCRM по вебхуку — каждый новый лид без поля utm_source уходит в отдельную обработку. На входе — JSON с полями, которые CRM и так собирает: Пример ответа модели на этот лид: Отдельным промптом та же модель ищет дубликаты: сравнивает email, телефон и временной интервал между заявками с одной точки входа — и тут стоит помнить, что из этих данных можно отправлять в нейросеть, а что нельзя . Помеченные повторы не считаются отдельными лидами в отчёте по конверсии. Что получилось, а что ещё нет Из пятнадцати процентов «ничьих» лидов модель уверенно (confidence выше 0.7) размечает примерно половину — дальше это ложится в ваш отчёт с пометкой источника, а не прочерком. Остальные так и остаются «unknown», и это честно: лучше открытый пробел, чем красиво угаданная неправда. На ваш отдел с полутора сотнями лидов в месяц это означает, что из примерно 18 неразмеченных заявок (оценка, 12% от 150) девять получают вероятный источник автоматически, а не ждут, пока у Оли будет свободная неделя. Дедупликация сработала быстрее и понятнее: за первый же месяц отчёт по конверсии перестал «проседать» из-за задвоенных карточек — это было видно сразу, без сложных расчётов. А вот с восстановлением источника мы пока в процессе: часть гипотез модели маркетолог перепроверяет вручную, потому что «reasoning» иногда цепляется не за тот признак. Ещё не знаем, стабилизируется ли точность на новых данных или придётся дообучать промпт под конкретные паттерны трафика. Где ломается: если отдавать модели решение об оптимизации бюджета на основе «вероятного» источника без пометки уверенности — вы урежете рабочий канал только потому, что модель ошиблась в гипотезе. Вероятностная разметка годится для отчёта и для сортировки задач, но не для автоматического перераспределения денег между кампаниями без человека в контуре — это тот самый случай, когда автоматизация требует надзора . Вывод такой: ИИ не заменяет UTM-метки и не чинит блокировщики кук — это вообще не про него. Он снимает самую нудную часть работы — не сидеть и не гадать по каждому лиду вручную, а получать пачку гипотез сразу с пометкой, где модель уверена, а где нет. По деньгам это та самая неделя маркетолога в месяц, около 40 000 ₽ (оценка) — и это без учёта того, сколько на самом деле стоит сам ИИ в месяц — именно эффект от разметки, без остальных изменений в отделе. И вещь важнее самой разметки. Умение открыть отчёт и спросить, чего в нём нет, — это управленческий навык, и его придётся освоить. Руководитель, который видит дыру в данных раньше подчинённых, стоит дороже того, кто читает готовые проценты. У меня этот навык вырос дорого — через месяцы решений вслепую. Проверьте сегодня одну цифру — долю лидов без источника. Больше десяти процентов — значит, на эту часть бюджета вы платите вслепую, и никакая аналитика это не вылечит, пока дыра в разметке открыта. Как собрать разметку и что делать с дублями — разложено в бесплатном курсе . ## Анализ воронки продаж врёт: клиент завис на 540 дней, а отчёт считал его живым URL: https://davidgerstein.pro/blog/voronka-prodazh-oshibki/ Дата: 2026-08-25 Направление: Продажи Цифры: 540 дней максимального простоя сделки · +1 п.п. конверсии/мес после контроля · 15 000 ₽/мес экономии времени РОПа Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваш анализ воронки продаж показывает красивую картинку, а деньги не сходятся — отчёт врёт. Почти всегда по одной из трёх причин, которые разберу ниже на своём случае. Проблема не в CRM и не в аналитике. Проблема в том, что воронка собирается из данных, которые заносят люди, — и пока вы не проверили, как именно они это делают, любые выводы из отчёта строятся на песке. Саша, РОП отдела продаж на производстве под заказ (шесть менеджеров, оборот около 4 млн ₽ в месяц, средний чек — 180 тысяч), открыл фильтр «сделки старше 90 дней» и увидел клиента в статусе «Согласование договора». Дата создания сделки — полтора года назад (540 дней). Всё это время клиент числился активным: попадал в отчёт по конверсии, в план по срокам закрытия месяца, в разговор на планёрке «ну, работаем». На деле с ним никто не разговаривал восемь месяцев. Один такой клиент не разоряет компанию. Но это классическая ошибка воронки продаж: она врёт в статистике по всем сделкам сразу, а не только по одной. Конверсия по стадии «Согласование» считается по всем сделкам на этой стадии, включая мёртвую. Средний срок закрытия сделки в отчёте раздувается на недели. А менеджер, который её ведёт, раз в неделю тратит 10–15 минут на то, чтобы упомянуть её на планёрке. Формула проста: минуты на упоминание × число недель в месяце ÷ 60 × ставка часа = потери. У Саши это 10–15 минут × 4 недели ≈ 40–60 минут, округлим до часа; час × ~1 000 ₽/час (ставка менеджера, оценка) ≈ 1 000 ₽ в месяц ни за что. Само по себе не страшно. Страшно то, что пока команда обсуждает мёртвую сделку, никто не смотрит на сорок живых, у которых, возможно, тот же самый диагноз — просто их ещё не поймали. Почему анализ воронки продаж не видит зависшие сделки Потому что стандартный отчёт показывает стадию, а не время на ней. В компании на 40 человек сделка провисела 540 дней и всё это время попадала в прогноз: в CRM не было ни счётчика дней в статусе, ни даты последнего контакта, ни норматива по сроку этапа. Три этих поля — минимальный набор, после которого зависание становится видно в день его возникновения, а не через полтора года при ручной ревизии. Три системные причины, по которым врёт ваша воронка продаж Сверьте с собой: если хотя бы одна из трёх есть у вас, цифрам в отчёте верить нельзя. Стандартный отчёт по воронке в Bitrix24 у Саши выглядел так: колонка «Стадия», колонка «Сумма», колонка «Ответственный». Всё. Ни даты последнего контакта, ни количества дней в текущем статусе, ни норматива, с которым можно сравнить. Воронка показывала, ГДЕ клиент, но не показывала, сколько он там уже стоит. «Моя таблица меня ни разу не подводила», — сказал Саша, когда я предложил переделать отчёт. Через неделю его же таблица подвела его на этом самом клиенте: он был уверен, что сделка «в работе», потому что стадия называлась «Согласование», а не «Заморожено». Стадия — это не статус активности. Это ловушка, в которую попадают почти все воронки: название этапа подменяет собой факт движения. У отчёта «до» было три системные проблемы, и ни одна не про конкретного менеджера: Время в статусе не фиксировалось — видна только текущая стадия, а сколько сделка там уже провисела, никто не считал. Разовые заказы, годовые контракты и нестандартные долгие проекты сидели в одной воронке и портили друг другу статистику. Норматива по срокам не было в принципе — «долго» и «нормально» каждый менеджер определял на глаз, и глаза у всех разные. Похожая история с датами есть в CRM почти у каждого — иногда система сама сдвигает даты создания сделки, и тогда врёт не отчёт, а исходные данные. Это отдельная поломка, я разбирал её в статье про сдвиг дат в Битрикс24 . Здесь другой случай: даты честные, просто их никто не считает. Пересборка: как мы собирали новый отчёт Повторите этот путь у себя — он занимает неделю и не требует ни бюджета, ни подрядчика. Пересборка заняла три итерации, каждая — по результатам разговора с Сашей, который проверял всё на своей неделе и заворачивал то, что не билось с реальностью. Аудит стадий и нормативных сроков. Взяли реальную воронку производства на заказ: заявка → расчёт КП → согласование договора → производство → приёмка → оплата. По каждой стадии выставили норматив в днях — не из головы, а по медиане фактических сроков закрытых сделок за полгода. Сегментация по типам работ. Нестандартные проекты с индивидуальным циклом (заказчик тянет решение месяцами по объективным причинам — например, ждёт финансирование) вынесли в отдельную воронку. Это тот самый случай зависшего клиента: он не «плохая сделка», он просто из другой категории, и в общей статистике ему не место. Добавили поля в карточку сделки. Дата создания, дата последнего контакта, количество дней в текущем статусе (вычисляемое поле), источник сделки. Светофор по нормативам. Зелёный — в пределах норматива стадии. Жёлтый — превышение до 50%. Красный — превышение больше 50% или полное отсутствие контакта дольше 14 дней. Ежечасное обновление и переход в карточку. Отчёт тянет данные напрямую из CRM по вебхуку, обновляется каждый час, из строки отчёта можно кликом уйти в саму сделку — без поиска по ID. Кто и когда смотрит. Красные сделки — на утренней летучке РОПа, до разбора плана на день. Жёлтые — раз в неделю на общей планёрке отдела. Саша принял идею не сразу — со скрипом, после того как отчёт нашёл вторую такую же зависшую сделку, которую он лично считал живой ещё неделю назад. ИИ-конвейер поверх отчёта Машина здесь не рисует вам новые графики, а объясняет старые: почему сделка встала, что было последним касанием, есть ли смысл её реанимировать. Светофор — это арифметика: даты и нормативы, без ИИ. Ум в конвейер добавили на следующем шаге — когда встал вопрос, что делать с красными сделками. Их набиралось 6–8 штук на весь отдел одномоментно, и по каждой нужно было понять: сделка мёртвая или просто клиент взял паузу по объективной причине. Разбирать вручную — минимум 10 минут на сделку: 6–8 сделок × 10 минут ≈ час РОПа в день только на диагностику. Схема конвейера: CRM (Bitrix24) → вебхук по расписанию (раз в час) → облачная функция считает дни в статусе и красные/жёлтые сделки → для каждой красной сделки формируется запрос к языковой модели с историей переписки и комментариев → модель определяет вероятную причину паузы и предлагает тон обращения → результат пишется обратно в поле сделки и падает уведомлением в чат РОПа. Пример ответа модели: Модель на этом шаге — дешёвая (уровня GPT-4o-mini или аналог): задача классификационная, текста немного, объём запросов маленький — 6–8 сделок в день на весь отдел. Дорогая модель здесь избыточна, разница в качестве классификации причины паузы на этом объёме не окупает разницу в цене токена. Инженерная обвязка простая и в этом её ценность: облачная функция (или скрипт по крону на сервере компании) дёргает Bitrix24 REST API, считает дни в статусе, для красных сделок вызывает модель, пишет ответ обратно в кастомное поле сделки и дублирует в Google Sheets как лог. Если вызов к CRM или к модели падает — запись уходит в отдельный лист «ошибки» с таймстампом, и в чат РОПа летит короткое уведомление «отчёт не обновился, час X». Без такого лога вы не отличите «сделок сегодня мало» от «скрипт упал вчера ночью». Экран «после»: что видно теперь Ориентир для вашего отчёта: с одного взгляда должно быть понятно, где стоит очередь и кто за неё отвечает. Пример строк актуального отчёта (обезличено): Отчёт по пайплайну — светофор по срокам 45 сделок в пайплайне 7 сделок в красной зоне 540 дней — рекорд простоя Менеджер Клиент Стадия Дней в статусе Статус Менеджер 1 Клиент А Расчёт КП 4 зелёный Менеджер 2 Клиент Б Согласование договора 18 жёлтый Менеджер 3 Клиент В Производство 62 красный Менеджер 4 Клиент Г Приёмка 9 зелёный Менеджер 6 Клиент Е Оплата 27 жёлтый Клиент менеджера 5 (540 дней в «Согласовании договора») в этот отчёт больше не попадает — он вынесен в отдельную воронку нестандартных проектов, чтобы не искажать статистику остальных. Распределение открытых сделок отдела по светофору после трёх месяцев работы отчёта (оценка на основе типового пайплайна из 45 открытых сделок) — на диаграмме ниже: Зелёный 60% Жёлтый 28% Красный 12% Доля сделок без движения дольше 60 дней (то есть фактически зависших, а не просто медленных) снизилась с 20% до внедрения светофора до 5% после — оценка на типовом пайплайне отдела. Отдельно: качество работы с этим же пайплайном заметно зависит не только от отчёта, но и от численности отдела. У Саши уже был период, когда три менеджера (он сам, напарник и ещё один) продавали стабильно больше, чем позже шесть-семь человек — просто потому что лидов на каждого стало больше, а внимания на каждого — меньше. После того как ввели контроль по пайплайну, конверсия начала расти на 1 процентный пункт в месяц. Это заслуга комплекса мер — контроль пайплайна плюс перераспределение нагрузки, а не одного только светофора, и вклад именно отчёта здесь нельзя выделить в чистом виде. Что это стоит и что даёт Ваши затраты — время на разбор данных, а не деньги на инструменты. Отдача считается просто: возьмите свой средний чек и умножьте на количество сделок, которые сейчас висят в воронке мёртвым грузом. Внедрение: аудит стадий, нормативов и настройка вебхука с полями — 10–14 часов работы аналитика или толкового менеджера по CRM. По ставке ~1 500 ₽/час (оценка, инженерное время дороже линейного) это 10 × 1 500 = 15 000 ₽ — 14 × 1 500 = 21 000 ₽ разово. Эксплуатация: ежечасный опрос CRM — бесплатно в рамках лимитов вебхука; вызовы к дешёвой модели на 6–8 сделок в день — по опыту такие объёмы укладываются в единицы долларов в месяц, подробный разбор счетов за похожие сценарии — в статье про реальные расходы на ИИ . Эффект в деньгах, оценка на условной компании: отдел из 6 менеджеров, средний чек 180 тыс. ₽, в пайплайне одномоментно около 45 открытых сделок. Если 15% из них зависает дольше норматива — это 45 × 0,15 ≈ 7 сделок. Даже если из них закрывается позже половина, а половина теряется навсегда — это 7 × 0,5 ≈ 3–4 сделки в квартал без выручки, то есть 3,5 × 180 000 ≈ 630 000 ₽ в квартал недополученных продаж (оценка, консервативно). Отчёт не гарантирует, что все эти сделки будут спасены — но без него их даже не видно. посчитайте на своих цифрах сделок в пайплайне % зависших сверх норматива средний чек, ₽ % теряемых безвозвратно риск ≈ {X} ₽ за квартал формула: сделки в пайплайне × доля зависших сверх норматива × средний чек × доля потерянных безвозвратно; оценка сверху Отдельная выгода — время РОПа. Ручной разбор 6–8 красных сделок в день занимал у Саши около часа. Со скринингом моделью он тратит на ту же диагностику 10–15 минут — просматривает готовые причины и решает, что делать. Экономия примерно 45 минут в день: 45 мин × ~20 рабочих дней ÷ 60 ≈ 15 часов в месяц; 15 часов × ~1 000 ₽/час (ставка РОПа, оценка) ≈ 15 000 ₽ в месяц высвобожденного управленческого времени, которое пошло на работу с живыми сделками, а не на археологию мёртвых. Чтобы прикинуть цифру на своём отделе: возьмите число открытых сделок в пайплайне, умножьте на вашу долю зависших сверх норматива стадии, умножьте на средний чек и на долю тех, кого вы реально теряете (консервативно берите половину) — получите оценку риска за период. То же самое с временем: минуты ручной диагностики одной сделки × число красных сделок в день × рабочие дни ÷ 60 × ставка часа — это то, что вы платите за отсутствие скрининга сейчас. Показатель Значение Открытых сделок в пайплайне (пример) 45 Доля зависших сверх норматива (оценка) ≈15% → 7 сделок Из них теряются безвозвратно (оценка) ≈50% → 3–4 сделки/квартал Средний чек 180 000 ₽ Риск недополученной выручки за квартал ≈630 000 ₽ (оценка) Стоимость внедрения светофора (разово) 15 000–21 000 ₽ Экономия времени РОПа в месяц ≈15 000 ₽ (15 часов × 1 000 ₽/час) Срок окупаемости внедрения меньше полутора месяцев эксплуатации Где ломается. Светофор врёт, если менеджеры научились вручную «освежать» дату последнего контакта пустым комментарием, чтобы уйти из красной зоны — это гейминг метрики, а не работа с клиентом, и его нужно ловить отдельно. Нормативы по стадиям врут, если их не пересматривать: цикл производства меняется по сезону, а норматив остаётся прежним. И самое частое: сделка ведётся не в CRM, а в переписке в мессенджере — тогда для отчёта её не существует, светофор молчит, а клиент реально висит. Похожий случай был с крупным нестандартным проектом: переговоры шли в личных чатах, в CRM появилась только финальная стадия — отчёт увидел сделку, когда она уже была почти закрыта, и толку от диагностики не было. Та же логика — сначала честные критерии метрики, потом контроль по ней — сработала и в другом месте того же отдела: менеджеров стали оценивать по вторичным звонкам, не объяснив правил, по которым система их сравнивает. Подробный разбор этого случая без саботажа и цифры внедрения — в статье про контроль звонков . Чек-лист: с чего начать в понедельник Откройте воронку и отфильтруйте сделки старше 60–90 дней без указания причины — их не должно быть больше нескольких единиц на отдел. Проверьте, есть ли в карточке сделки поле «дата последнего контакта» и заполняется ли оно реально, а не автоматически при любом клике. Выпишите нормативный срок по каждой стадии — по медиане уже закрытых сделок за полгода, а не «как кажется». Вынесите нестандартные, долгоцикловые кейсы в отдельную воронку — не удаляйте и не мешайте с обычным потоком. Настройте вычисляемое поле «дней в статусе» и элементарный светофор — это делается без ИИ, за один день работы с CRM. Только после того как светофор устойчиво работает вручную минимум две недели, добавляйте автоматическую диагностику причины через модель — иначе автоматизируете хаос, а не процесс. Начните с проверки, а не с перестройки: выгрузите свою воронку и найдите сделки, которые стоят на этапе дольше нормы. Если таких больше четверти — ваш отчёт показывает вам не воронку, а склад. Как навести порядок и поставить контроль без ручного разбора — механика в бесплатном курсе для руководителей . Мой урок из этой истории Я почти месяц спорил с руководителем отдела о цифрах, пока не понял, что мы оба правы: он смотрел в CRM, я — в отчёт, и данные там расходились, потому что часть сделок заводилась задним числом. Спор был не о продажах, а о качестве данных, и никто из нас этого не осознавал. С тех пор у нас правило: любой спор о цифрах начинается с вопроса «откуда взялось число», а не «кто виноват». Экономит часы совещаний. Отличать «сделка идёт» от «сделка стоит» — отдельный навык руководителя, и он не про CRM, а про вопрос, который вы задаёте на планёрке. Не «что там у нас по клиенту», а «сколько дней мы с ним не разговаривали». На этой неделе откройте свой отчёт и задайте этот вопрос по трём самым крупным сделкам — если ответа в отчёте нет, вы уже знаете, что чинить первым. ## Рекламный бюджет: во что обходится контроль расходов на плане 220–332 лида URL: https://davidgerstein.pro/blog/reklamnyy-byudzhet-stoimost/ Дата: 2026-08-24 Направление: Маркетинг Цифры: 220→332 лида/мес; 40% лидов качественных при плане 80%; 15 лидов/день — порог выхода в план Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Рекламный бюджет: короткий ответ Если у вас рекламный бюджет уходит каждый месяц, а внятного ответа «сколько стоил лид по каждому каналу» нет — дело почти никогда не в настройке кампаний. Дело в учёте после клика: заявки задваиваются, часть лидов не привязывается к источнику, счёт на следующий месяц оплачивают позже дедлайна. Подрядчик по рекламе этим не занимается, и в его отчёте вы этих потерь не увидите. Контроль рекламного бюджета — отдельный конвейер: сбор в одну точку, дедупликация, статус для лидов без источника, скоринг и сигнал о неоплаченном счёте. На плане 220–332 лида в месяц он стоит 60 000–100 000 ₽ разово и 3 000–5 000 ₽/мес на эксплуатацию, измеримый эффект — 30 000–50 000 ₽/мес, окупаемость 1,5–3 месяца. Собирается конвейер в шесть шагов, и раскладка расходов считается до запуска, а не после. Сколько стоит держать рекламный бюджет под контролем? Показываю раскладку по шагам — она окажется меньше, чем вы думаете, и меньше, чем стоит один месяц работы вслепую. Если вы сейчас узнаёте свою ситуацию — отчёт по рекламе у вас есть, а доверия к нему нет, — вам дальше по пунктам: откуда берётся расхождение, во что обходится его закрыть и как проверить это на своих цифрах. Почему план в 220 и 332 лида — это в первую очередь вопрос денег, а не креатива На планёрке в мае прозвучала фраза, которую я записал дословно: «Тенденция по лидам идёт вниз. Если мы берём отдел продаж по плану, а маркетинг столько лидов не даст, мы снова в такой ситуации находимся, что будем в жопе». Грубо, но точно. За этой фразой стоят конкретные цифры: план — 220 качественных лидов в мае и 332 в июне. Рост на 51% за месяц. Не потому что кто-то придумал красивую цель, а потому что отдел продаж из 8 менеджеров рассчитан именно на такой поток при обороте около 9 млн ₽/мес и среднем чеке сделки в 180 тыс. ₽. Проблема в том, что план считают одним числом в конце месяца, а деньги теряются каждый день внутри него. Условная точка входа для лида (форма на сайте, чат-бот, реклама в соцсети) в реальности иногда создаёт 2–3 дубликата одной заявки. Маркетолог Оля увидела это не в отчёте, а случайно — утром, разбирая цифры вручную, потому что показатели конверсии день ото дня падали, хотя реальная ситуация была другой. «Отсутствие информации — это отсутствие рычагов давления. И это меня прям очень сильно бесит», — сказала она чуть позже, когда выяснилось, что разделить конверсию по Google и Яндексу тоже нельзя из-за ограничений интеграции. Добавьте сюда 10–15% лидов, которые физически нельзя атрибуцировать к каналу — люди блокируют куки, чистят историю, ставят блокировщики рекламы. В декабре доля таких лидов подскочила до 30%. Без разметки это выглядит как «маркетинг не досчитался лидов», хотя на деле часть трафика просто невидима для системы аналитики. Вот в такой обстановке вопрос «сколько стоит автоматизация рекламного бюджета» перестаёт быть абстрактным — это вопрос, сколько стоит не видеть половину правды о собственных деньгах. Механика: из чего состоит «автоматизация рекламного бюджета» по шагам Под этим названием обычно понимают разное. У нас в итоге получился конвейер из шести шагов — от сырого лида до записи в CRM с приоритетом для менеджера. Сбор. Все источники (реклама в соцсетях, поиск, органика, формы на сайте) льют лиды в одну точку — вебхук в CRM. Дневной объём — около 50 валовых лидов со всех каналов. Дедупликация. Скрипт сверяет телефон/email/UTM за последние 24 часа и схлопывает дубликаты до отправки менеджеру. Без этого шага одна заявка может «размножиться» на 2–3 карточки в CRM и исказить и конверсию, и загрузку отдела. Атрибуция. Лиды без явного источника (10–15% в обычный месяц, до 30% в декабре) помечаются отдельным статусом «неатрибутируемый» с указанием вероятной причины (блокировщик, приватный режим, чистка истории) — вместо того чтобы тихо портить статистику канала. Скоринг. ИИ-модель оценивает лида по поведению на сайте и данным из внешних источников, присваивает приоритет и короткое обоснование. Синхронизация с оплатой бюджета. Отдельный контроль: чтобы получить лиды 3-го числа, счёт на рекламу нужно оплатить 28-го числа предыдущего месяца. Система заранее сигналит, если счёт не оплачен вовремя — а сейчас это происходит почти в половине случаев. Сверка с планом. Ежедневная сводка: сколько лидов пришло, сколько нужно для выхода на 220 или 332 к концу месяца, где отставание. Отличие от «просто настроенной рекламы» в другом: система не про то, как получить больше кликов, а про то, чтобы не терять деньги на этапе между кликом и записью в CRM менеджера. ИИ-связка: как лид получает оценку раньше, чем до него доходит менеджер Схема конвейера простая: реклама/сайт → вебхук в CRM → скрипт дедупликации и атрибуции → запрос к модели для скоринга → запись приоритета обратно в карточку → уведомление менеджеру . Дедупликация и атрибуция — это правила, их считает обычный скрипт без ИИ. А вот скоринг — задача для языковой модели, потому что данные неструктурированные: обрывки поведения на сайте, сегмент, тип интереса. Для скоринга не нужна дорогая модель — это классификация по понятным признакам, без творческой задачи. Дешёвая модель уровня GPT-4o-mini справляется с этим за секунды и стоит на порядок дешевле топовых моделей — разница в реальных счетах за ИИ ощутима, что критично при потоке 300+ лидов в месяц. Пример ответа модели: Второй промпт нужен не для лида, а для контроля самого бюджета — той самой синхронизации оплаты, которая рвёт цикл привлечения. Он превращает сухие данные о статусе счетов в человекочитаемую сводку для планёрки. Пример ответа модели: Инженерная обвязка простая и без экзотики: скрипт на Google Apps Script дёргает вебхук CRM ( Bitrix24 или amoCRM API — конвейер одинаковый для обеих), пишет сырые и обработанные данные в Google Sheets как журнал, а вызовы модели идут через отдельный шлюз с логированием токенов, чтобы расходы на ИИ не потерялись в общем счёте за рекламу. Если вебхук не отвечает дольше 15 минут или доля неатрибутируемых лидов за день превышает 25% — бот пишет алерт в Telegram. Перезапуск — вручную по кнопке в таблице, без сложной оркестрации: на потоке 15–20 лидов в день сложная инфраструктура не нужна, важнее, чтобы кто-то видел ошибку сразу, а не через неделю. Контрольные точки: план по дням против факта Руководитель требовал не общее число в конце месяца, а понедельную и подневную детализацию — где именно отстаём. Вот как это выглядело по факту на середину мая. Показатель Значение Комментарий Валовые лиды в день (все источники) ~50 до дедупликации и атрибуции Качественные лиды в день (неделя без выходных) 16–17 после отсева Накоплено качественных за месяц 200+ на момент проверки, 5–6 рабочих дней до конца месяца Требуется в день до конца месяца 15 чтобы выйти на план 220 Доля неатрибутируемых лидов 10–15% (обычный месяц), до 30% (декабрь) отдельная категория с коэффициентом сезонности 0,8 для декабря Доля качественных лидов при контроле качества 40% (план — 80%) 60% отбраковки против плановых 20% На диаграмме ниже — доля качественных лидов против плановой отбраковки: факт заметно хуже цели. Качественные лиды (факт) 40% Отбраковано (факт) 60% Плановая отбраковка 20% (цель) Без дедупликации и атрибуции эта таблица не собирается вообще — руководитель либо верит менеджерам на слово, либо тратит вечер на ручную сверку выгрузок. Отдельно интересна динамика конверсии органического трафика — она наглядно показывает, почему нельзя судить об эффективности рекламного бюджета только по числу лидов. На диаграмме — падение конверсии органики за три месяца. Январь 17% Март 15% Апрель 9% Конверсия органики упала с 17% до 9% за три месяца — и без разметки по каналам эта просадка выглядит как «маркетинг перестал справляться», хотя причина может быть в качестве самого трафика, а не в объёме рекламного бюджета. Признаю: я сам полгода читал сводку по рекламному бюджету как готовую правду и спорил с маркетологом о процентах, которых в цифрах не было — расхождение давали дубли, а не работа отдела. Я потратил на эти споры больше вечеров, чем занял бы скрипт дедупликации, и жалею, что не начал с проверки самих данных. Если у вас сейчас идёт такой же спор — начинайте не с людей, а с выгрузки: вы почти наверняка спорите о цифре, которой нет. Отделять стоимость трафика от стоимости учёта — это отдельный навык руководителя, и тренируется он на одном вопросе: за что я плачу в этой строке — за показы или за то, чтобы видеть, что из показов выросло? Пока оба числа лежат в одной графе «реклама», любой ваш разговор о рекламном бюджете сводится к спору о вкусах. Как только вы их разделили, разговор становится арифметикой — и его можно выиграть. Экономика: что стоит система и что она возвращает Разделяю два вопроса: сколько стоит сама система учёта бюджета и лидов — и сколько стоит рекламный бюджет, который она обслуживает. Это разные деньги, их нельзя смешивать. Статья расходов Сумма Тип Разработка конвейера (дедуп + атрибуция + скоринг + алерты) 60 000–100 000 ₽ разово оценка, 25–35 часов подрядчика Эксплуатация (API модели, хостинг скрипта, таблицы) 3 000–5 000 ₽/мес оценка, ~300 лидов/мес Рекламный бюджет 500 000 ₽/мес отдельная статья расходов, не входит в стоимость автоматизации Отдельно от разработки — эффект. Считаю его консервативно и только для того, что даёт именно эта система, не смешивая с другими инициативами вроде смены оффера или подбора инфлюенсеров. Формула для своего случая: (число некачественных/лишних лидов в месяц) × (среднее время на квалификацию одного лида в часах) × (ваша ставка часа сотрудника) = месячные потери на ручной обработке. Дальше сравниваете эту сумму с разовой стоимостью разработки и эксплуатацией — и получаете свой срок окупаемости. посчитайте на своих цифрах лишних лидов в месяц время на квалификацию, часов ставка часа сотрудника, ₽ потери ≈ {X} ₽ в месяц на ручной обработке формула: лишние лиды × время на квалификацию одного лида × ставка часа; сравните с разовой стоимостью разработки 60 000–100 000 ₽ Пример расчёта (скоринг). Отдел из 8 менеджеров, план 300 лидов в месяц. При факте 40% качественных вместо плановых 80% в обработке остаётся 120 «лишних» некачественных лидов, которые всё равно требуют звонка или переписки — в среднем 15 минут (0,25 часа) на квалификацию. Это 120 × 0,25 = 30 часов в месяц ручной работы менеджеров. По ставке около 1000 ₽/час (оценка) — 30 000 ₽/мес. Предварительный скоринг не убирает эту работу полностью, но снимает часть: консервативно закладываю треть (10 000 ₽/мес), в оптимистичном сценарии — до половины (15 000 ₽/мес), если скоринг отсекает лидов ещё до звонка, а не только приоритезирует их. Пример расчёта (дедупликация и автосверка). Раньше маркетолог тратил около часа в день на ручную проверку данных по утрам, чтобы отличить реальное падение конверсии от искажения дублями. Это 20 часов в месяц × 1000 ₽/час = 20 000 ₽/мес высвобожденного времени — при условии, что дедупликация закрывает эту задачу полностью, а не частично. Это два разных источника эффекта, и я не смешиваю их в одну непроверяемую цифру: 10 000–15 000 ₽/мес даёт скоринг, 20 000 ₽/мес — дедупликация и автосверка. Консервативная сумма (нижние границы обеих оценок) — 30 000 ₽/мес, менее консервативная (верхняя граница по скорингу плюс полный эффект дедупликации) — до 50 000 ₽/мес. При разовых вложениях 60 000–100 000 ₽ это даёт окупаемость от 1,5 до 3 месяцев: 1,5 месяца — если вложения ближе к нижней границе (60 000 ₽), а эффект — к верхней (50 000 ₽/мес); 3 месяца — если вложения на верхней границе (100 000 ₽), а эффект консервативный (30 000 ₽/мес). Что не считаю эффектом: срыв синхронизации оплаты бюджета, способный обвалить весь план на месяц вперёд — этот риск вероятностный, а не гарантированный, и в деньгах я его не считаю. Показатель До автоматизации После Эффект (оценка) Ручная сверка дублей маркетологом ~1 час/день, 20 ч/мес 0 (дедупликация автоматом) −20 000 ₽/мес (1000 ₽/час) Ручная квалификация некачественных лидов менеджерами 30 ч/мес на 120 «лишних» лидов ~20 ч/мес после скоринга (снята треть) −10 000 ₽/мес (1000 ₽/час) Видимость риска по оплате счёта риск замечен постфактум, ~50% счетов не вовремя алерт заранее, до наступления дедлайна не оцениваю в деньгах — вероятностный риск Совокупный измеримый эффект — — 30 000–50 000 ₽/мес Где ломается конвейер: два типичных сбоя Автоматика бессильна против неоплаченного счёта. Систему можно построить идеально, но если счёт за рекламу не оплачен 28-го числа — лиды 3-го числа физически не появятся. У нас половина счетов оплачивалась не вовремя. Алерт в Telegram решает половину проблемы (кто-то видит риск заранее), вторую половину решает только изменение процесса оплаты — например, автосписание за 5 дней до дедлайна, а не ручное согласование. Автоматизация без владельца деградирует незаметно. У партнёра, работавшего в похожей связке, неделю не работал бот для сбора лидов — команда клиента не спешила это чинить, потому что «общий бизнес и так приносит деньги». За это время данные о потенциальных клиентах просто исчезли. Разбирал похожий случай подробнее в статье про автоматизацию, которая требует надзора — вывод там тот же: без явного ответственного за мониторинг любой конвейер рано или поздно тихо останавливается. Чек-лист на понедельник Выгрузить за последнюю неделю все лиды по одному источнику и вручную проверить на дубликаты — если находите больше 5%, дедупликация нужна уже сейчас. Посчитать долю неатрибутируемых лидов за последний месяц — если больше 15%, стоит завести для них отдельный статус в CRM вместо общей графы «источник неизвестен». Сверить график оплаты рекламного бюджета с датой начала показов — если между оплатой и лидами разрыв в несколько дней, поставить напоминание за 5 дней до дедлайна счёта. Проверить, кто в команде смотрит на работоспособность рекламных ботов и форм ежедневно — если ответ «никто конкретно», это и есть точка риска. Сравнить фактическую долю качественных лидов с плановой (у нас — 40% против 80%) и решить, где отсев: на входе (таргетинг) или на обработке (скоринг). Составить понедельную раскладку годового плана лидов с учётом сезонности — как минимум для одного провального месяца (у нас декабрь — коэффициент 0,8). Прикиньте на своих цифрах: возьмите месячный бюджет и умножьте на долю, которую вы тратите на каналы без понятной отдачи. Это и есть сумма, ради которой стоит потратить неделю на настройку. Механика — в бесплатном курсе для руководителей . И ориентир для вашего решения: если ваш рекламный бюджет больше двухсот тысяч в месяц, автоматизация окупится за квартал только на сокращении слепых трат. Если меньше — начните с ручного разбора каналов, вам это даст больше. И ваш ориентир при выборе: считайте не стоимость настройки, а сколько ваш бюджет теряет каждый месяц без неё. У нас эта разница окупила работу за первый же месяц, и я жалею, что не сделал этого раньше. Проверьте свой бюджет по одному признаку: можете ли вы назвать выручку по каждому каналу за прошлый месяц? Если нет — начинать надо не с автоматизации, а с этой цифры. И начните вы не с подрядчика, а с этой цифры по вашим каналам — она обычно решает вопрос сама. ## Заявки с сайта: где они теряются на пути от формы до оплаты URL: https://davidgerstein.pro/blog/zayavki-s-sayta-oshibki/ Дата: 2026-08-24 Направление: Маркетинг Цифры: качество лидов 40% при плане 80% · органика 17%→<10% · неатрибуция до 30% в декабре Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Заявка с сайта — самый дорогой контакт из всех, что у вас есть: за него заплачено рекламой, сайтом и работой маркетолога. И самый уязвимый: цепочка от формы до оплаты рвётся минимум в четырёх местах. Смотрите. Если вы до сих пор считаете заявки с сайта одной цифрой «сколько пришло» — у вас не отчёт, а экран для успокоения. И бюджет вы двигаете вслепую, даже если графики аккуратно рисуются каждое утро. Утро понедельника, отдел маркетинга смотрит на дашборд с заявками с сайта: конверсия органики упала. В январе было 17%, в марте — почти 15%, в апреле — уже ниже 10%. Руководитель произносит вслух: «Тенденция по лидам идёт вниз. Если отдел продаж работает по плану, а маркетинг столько лидов не даст — мы снова там, где не хотим быть». Логичная реакция — резать бюджет на органику и переливать деньги в платный трафик. Проблема в том, что цифра 10% — не про трафик. Она про то, как отчёт считает лидов. Одна точка входа на сайте генерит два-три дубликата в CRM. Каждый десятый-пятнадцатый лид вообще не атрибутируется — пользователь заблокировал куки или почистил историю, а в декабре доля таких «ничейных» заявок доходит до 30%. И конверсия в отчёте зависит от того, по какой дате её считать: по дате создания заявки или по дате оплаты. На одном и том же массиве данных эти два среза дают расхождение в разы. Отдел продаж здесь — 8 менеджеров с планом около 50 сделок в месяц при обороте ~9 млн ₽ и среднем чеке ~180 тыс. ₽; похожий разбор того, как искажённые цифры ломают план продаж, — в статье про ошибки согласования договоров . Если решение «резать органику» принято на кривых цифрах — это удар не по строчке в таблице, а по реальному потоку сделок. Где теряются заявки с сайта Не в форме, а в отчёте. Одна точка входа на сайте создаёт 2–3 записи в CRM, 10–15% лидов в обычный месяц и до 30% в декабре не привязываются к каналу, а конверсия считается то по дате создания, то по дате оплаты — и на одном и том же массиве данных даёт разные ответы. Первое действие — не резать трафик, а развести в вашем отчёте валовые и уникальные заявки, вынести неатрибутируемые в отдельную категорию и считать план/факт по одной дате. В разобранном случае качественными оказались 120 лидов из 300 — 40% при плане 80%. Экран, который врал по-тихому Вот как выглядел дашборд до пересборки. Одна вкладка, три колонки: дата, число заявок с сайта, конверсия в продажу. Автообновление раз в сутки. Если у вас на экране те же три колонки — дальше можно не гадать, где именно теряется. Красиво, но бесполезно для управленческого решения — потому что за каждой цифрой в колонке «заявки» стоят как минимум четыре разных явления, слитых в одну сумму. Руководитель наткнулся на разрыв случайно, пока разбирался с падением конверсии: похожий кейс, где смена фильтра «дата оплаты / дата создания» меняла итоговую сумму отчёта в разы, я уже подробно разбирал в статье про то, во сколько на самом деле обходится реклама . В своей ситуации руководитель обнаружил то же самое: сумма по одному и тому же месяцу отличалась почти вдвое в зависимости от того, по какой дате её считать — по дате создания сделки или по дате поступления оплаты. Один и тот же массив данных, два разных вывода — смотря кто и как считает. Ещё одна цитата с той же планёрки: «Отсутствие информации — это отсутствие рычагов давления. И это меня прям очень сильно бесит». Речь шла о невозможности разделить конверсию по Google и по Яндексу из-за ограничений интеграции — а без этого разреза непонятно, куда лить бюджет, а откуда его убирать. Пять причин, по которым заявки с сайта теряются Отметьте, какие есть у вас. Три из пяти встречаются почти в каждой компании. После разбора набралось пять причин, по которым один и тот же экран показывал разные версии реальности. Дубли на входе. Одна точка входа на сайте (форма, чат-бот, звонок с сайта) создаёт два-три лида в CRM — например, если форма отправляет данные и в CRM напрямую, и через рекламный пиксель отдельным вебхуком. Отчёт считает валовые заявки, не различая уникальные обращения. Неатрибутируемый трафик. 10–15% лидов в обычный месяц и до 30% в декабре невозможно привязать к каналу — блокировщики рекламы, приватный режим, очистка cookies. Эти лиды либо выкидываются из отчёта по каналам (искажая конверсию платных источников вверх), либо приписываются случайному каналу (искажая её вниз). Дата создания vs дата оплаты. Сделка может быть создана в одном месяце, а оплачена в другом. Если отчёт не разделяет эти два среза явно, любое сравнение план/факт по месяцам становится нечестным — это тот же механизм, что подробно разобран в статье про сдвиг дат в Отчёты Битрикс24: почему цифры не сходятся и как доказать . Валовый объём вместо качества. Из потока лидов только 120 из 300 (40%) проходили проверку качества, хотя план предполагал отвал не более 20%. Отчёт со строчкой «заявки с сайта: 300» без разбивки на качество выглядит отлично и полностью врёт про реальный поток годных обращений. Смешение источников без разреза. Конверсия органики падала три месяца подряд (17% → 15% → менее 10%), но в общем отчёте это тонуло среди платного трафика — никто не видел тренд, пока кто-то не построил отдельный срез вручную. Маркетолог Оля, разбирая похожий случай, формулирует это так: продажи кричат «лиды плохие», а на деле часть «плохих» лидов — просто дубли одного и того же человека, посчитанные трижды (подробнее — Лиды есть, а продаж нет ). Пересборка: что делать по шагам Техническая часть разобрана отдельно: автоматизация обработки заявок — пять шагов от письма до задачи, включая шаблонные обращения. Ваш порядок: сначала проверка данных, потом логика отчёта, и только затем внешний вид. Дальше — не абстрактная «оптимизация воронки», а конкретная последовательность действий, которую вы можете повторить с любой CRM, где есть вебхуки. Дедупликация на входе. Что: каждая новая заявка. Чем: скрипт-обработчик вебхука сравнивает телефон и email с последними 30 днями лидов. Куда: если совпадение найдено — заявка помечается флагом «дубль» и не увеличивает счётчик валовых лидов в отчёте, а лишь дописывается как повторное касание к существующей карточке. Маркировка неатрибутируемых. Что: заявки без utm-меток и с пустым referrer. Чем: правило в CRM плюс серверная (не только клиентская) фиксация источника через IP и таймстемп сессии. Куда: отдельная категория в отчёте «источник не определён», не смешанная ни с одним платным каналом. Две даты вместо одной. Что: момент создания сделки и момент поступления оплаты. Чем: два отдельных поля в CRM, оба выводятся в отчёт как независимые срезы. Куда: план/факт по месяцам считается по дате оплаты, скорость цикла — по разнице между датами. Скоринг качества на входе, а не через две недели. Что: поведенческие данные с сайта (время на странице, посещённые разделы) плюс данные из внешних источников (сегмент, тип услуги). Чем: модель присваивает предварительную вероятность сделки сразу при создании лида. Куда: приоритет менеджеру — кому звонить в первую очередь, а не общий список без сортировки. Разрез по каналу без смешения. Что: конверсия по каждому источнику отдельно (органика, Google, Яндекс, соцсети). Чем: отдельная вкладка отчёта с недельной динамикой, а не общий агрегат. Куда: еженедельная сверка на планёрке, где смотрят не общее число лидов, а тренд по каждому каналу отдельно. Контрольная точка по дням. Что: план 220 лидов в мае, 332 в июне при плановых 15 качественных лидов в день. Чем: детализация по неделям и дням — например, за прошлую неделю (без выходных) факт был 16–17 качественных лидов в день, за месяц накопилось больше 200, и при оставшихся 5–6 рабочих днях видно уже к вечеру среды, догоняет компания план или нет. Куда: короткий чат-алерт, если факт дня ниже 70% от плана два дня подряд. ИИ-связка: разметка и скоринг Это снимет с ваших менеджеров разбор мусорных обращений и покажет реальную картину по источникам. Схема простая: сайт → вебхук CRM → скрипт дедупликации → вызов модели для скоринга и разметки → запись результата обратно в карточку лида → отчёт читает уже размеченные данные, а не сырые. На шаге дедупликации и скоринга модель нужна дешёвая — задача классификационная, не творческая, а поток большой (полторы тысячи лидов в месяц при 50 заявках в день). Дорогая модель здесь — деньги на ветер, точность та же. Пример ответа модели: Инженерная обвязка. Вебхук Bitrix24 (или amoCRM API) ловит событие создания лида и кладёт JSON во временную очередь — таблицу Google Sheets или отдельный лист. Скрипт-обработчик раз в минуту забирает необработанные строки, вызывает модель, пишет результат обратно в карточку лида двумя полями: «дубль/не дубль» и «скоринг». Если API не ответил за 15 секунд — три повторные попытки с задержкой, при финальном отказе строка помечается «требует ручной проверки» и уходит алертом в Telegram-канал маркетинга. Логика перезапуска простая: скрипт идемпотентен, повторный вызов на уже обработанном лиде просто перезаписывает те же поля, ничего не задваивая. Экран после пересборки Ниже — таблица, которая заменила собой три колонки старого отчёта. Каждая строка — отдельный, проверяемый срез. Срез отчёта Значение Что это даёт Валовые лиды в день ~50 сырой поток без очистки Из них дубли (одна точка входа) 2–3 записи на 1 обращение отдельный флаг, не в общем счётчике Неатрибутируемые (обычный месяц / декабрь) 10–15% / до 30% отдельная категория, не смешана с каналами Качественные лиды после фильтра 120 из 300 (40%) план предполагал отвал не более 20% Конверсия органики (январь → апрель) 17% → 15% → <10% виден тренд, не разовая просадка План качественных лидов (май / июнь) 220 / 332 раскладка по неделям и дням для контроля отставания На диаграмме ниже — доля дублей, неатрибуции и брака по качеству на одном и том же потоке лидов. Дубли на точку входа до 66% Неатрибуция, декабрь 30% Неатрибуция, обычный месяц 10–15% Брак вместо плановых 20% 60% На диаграмме — как менялась конверсия органики: с 17% в январе до уровня ниже 10% в апреле, три месяца подряд вниз. 17% в январе <10% в апреле Падение фиксировали три месяца подряд, но реального обвала трафика не было — отчёт путал источники и смешивал органику с платным трафиком, тренд был виден только в отдельном разрезе. SEO-специалист, который взялся за пересборку, обещал уложиться в два дня — сделал за выходные, добавив реал-тайм отслеживание лидов и конверсий по страницам. Дальше команда параллельно тестирует две ключевые позиции в топ-3 Яндекса до 15 июня, чтобы проверить, коррелирует ли рост трафика с ростом продаж, или проблема остаётся не в трафике, а в обработке. Отдельно ввели коэффициент сезонности 0,8 для декабря — чтобы не сравнивать провальный по объективным причинам месяц с остальными наравне. Где цепочка рвётся ещё раз — на стыке с оплатой Даже с идеально размеченным дашбордом цепочка «клик → лид → сделка» может рваться не в аналитике, а в операционке рядом с ней. В том же отделе всплыла отдельная проблема: чтобы лиды пришли в начале месяца, счёт за них нужно оплатить заранее — например, 28-го числа предыдущего месяца, чтобы получить поток 3-го числа следующего. При этом, по признанию менеджера, около половины счетов оплачивается не вовремя. Результат предсказуем: даже безупречный отчёт о заявках не спасает, если сам поток лидов физически не запущен из-за просроченного счёта — тогда «дно» на графике конверсии на самом деле «дно» на графике оплат, а не на графике трафика. Это тот же тип ошибки, что и путаница дат создания/оплаты сделки, только на шаг раньше в цепочке — перед тем, как лид вообще появится. Что это стоит и что даёт Разработчик потратил на пересборку дашборда и вебхука дедупликации примерно 16 часов (оценка, по факту «выходные»). При ставке около 1000 ₽/час это разово 16 000 ₽ (оценка). Скоринг лидов дешёвой моделью при потоке 1500 заявок в месяц — расходы на API около 3–5 тысяч рублей в месяц; точный разбор счетов за токены — тема отдельной статьи Сколько на самом деле стоит ИИ в месяц . Эффект считаю отдельно от прочих маркетинговых мер — только то, что даёт именно очистка отчёта и скоринг на входе, без учёта параллельных изменений в SEO, рекламе или SMM. Формула для своего случая словами: (фактическая доля отвала минус плановая доля) × поток лидов в месяц = число лишних лидов, которые кто-то должен вручную посмотреть и закрыть; дальше это число × время на один лид в часах × ставка часа сотрудника = потери в месяц на обработку мусора. посчитайте на своих цифрах поток лидов в месяц факт отвала, % план отвала, % минут на лид ставка часа, ₽ потери ≈ {X} ₽ в месяц на обработку мусора формула: (факт отвала − план) × поток лидов × минуты на лид × ставка часа / 6000 (перевод минут в часы и рубли) Подставляю числа этого случая: поток 1500 лидов в месяц, факт отвала 60% вместо плановых 20% — это (60% − 20%) × 1500 = 600 лишних лидов, которые кто-то формально обрабатывает (смотрит, звонит, закрывает карточку). Время на такую обработку — около 10 минут на лид (оценка, консервативно, без учёта времени на повторные касания). Это 600 × 10 мин = 6000 минут = 100 часов в месяц — больше половины ставки одного менеджера. При ставке около 1000 ₽/час (оценка) это 100 × 1000 = 100 000 ₽/мес чистых потерь на обработку мусора, который скоринг на входе мог бы отсеять сразу. Показатель Значение Поток лидов в месяц 1500 Факт отвала vs план 60% vs 20% Лишних лидов на ручную обработку 600 Время на лид (оценка) ~10 мин Итого часов в месяц 100 Ставка часа (оценка, типовая для менеджера) ~1000 ₽ Потери на обработку мусора в месяц (оценка) ~100 000 ₽ Разовые затраты на пересборку (оценка) ~16 000 ₽ + 3–5 тыс. ₽/мес на скоринг Окупаемость пересборки (оценка) меньше недели Разово потраченные на пересборку ~16 000 ₽ плюс 3–5 тыс. ₽/мес на скоринг при экономии порядка 100 000 ₽/мес на разгрузке менеджеров от мусорных лидов окупаются меньше чем за неделю (оценка, консервативно — если хотя бы половина из этих 100 часов реально высвобождается, а не уходит на другие задачи). Это только вклад дедупликации и скоринга на входе — эффект от исправления путаницы дат и разреза по каналам в этой сумме не учтён, потому что он управленческий, а не почасовой. Отдельная выгода — управленческая, а не только временная: расхождение отчётов из-за разных фильтров дат означает, что решения о премиях, плане на следующий месяц и бюджете рекламы принимались на неверных цифрах. Цена такой ошибки не считается в часах — она считается в качестве решений, которые вы уже приняли и отменить не сможете. Где ломается. У клиента похожей компании неделю не работал автоматизированный бот для сбора лидов с сайта — и команда клиента не спешила это чинить, потому что общий бизнес всё равно приносил деньги, а поломка одного модуля не выглядела критичной. Итог — потеря данных о потенциальных клиентах за весь этот период, которую никто не заметил без внешнего контроля. Это тот же риск, что разобран в статье про автоматизацию без надзора: «Если бы я не пришёл, ничего бы не произошло» . Скоринг и дедупликация ломаются точно так же: без владельца, который раз в неделю сверяет отчёт с CRM руками, любая автоматика тихо деградирует, и об этом узнают только когда цифры становятся совсем абсурдными. Чек-лист на понедельник Сравнить число заявок на форме сайта, число событий в вебхуке CRM и число карточек лидов за одну неделю — посчитать расхождение в процентах. Проверить, есть ли в CRM явный флаг «дубль» и отдельная категория «источник не определён» — если нет, завести их до пересборки отчёта. Развести в отчёте две даты: создания сделки и оплаты — и пересчитать план/факт по каждой отдельно. Проверить синхронизацию оплаты счетов за лидогенерацию с датой их фактического поступления — просроченный счёт выглядит на графике как провал трафика, хотя это провал платежей. Выгрузить за месяц долю лидов, прошедших контроль качества, и сравнить с плановым отвалом — если факт выше плана вдвое-втрое, разбираться до пересборки скоринга. Назначить человека, который раз в неделю сверяет автоматический отчёт с CRM вручную — без этого шага любая автоматика через месяц начнёт врать незаметно. Запустить скоринг на тестовой выборке 100–200 лидов и сравнить приоритет модели с тем, что менеджеры делают интуитивно — расхождение покажет, где модель ошибается. И отдельным пунктом, поверх всего списка: отправьте тестовую заявку через свою же форму со своего телефона. Засеките время до звонка, послушайте, что вам скажут, посмотрите, появилась ли заявка в CRM и с каким источником. Пятнадцать минут. Если хотя бы одно из четырёх сработало не так, как вы ожидали, — вы нашли свою дыру. Как я это нашёл у себя Я отправил такую заявку с личного телефона в четверг вечером. Мне перезвонили в понедельник днём. При этом наш отчёт показывал среднее время ответа — сорок минут, и я этому отчёту верил. Разгадка оказалась простой: в среднее не попадали заявки, которые вообще не обработали, — их просто не было в выборке. Мы считали среднее по тем, кому ответили, и радовались цифре. Это моя ошибка, а не ошибка отчёта: я не понимал, что цифру, посчитанную машиной, надо выборочно проверять руками, — и не проверял. Здесь ошибаются все, включая меня; чинится это за один вечер, так что закрывать вкладку от стыда не надо. Умение не верить собственному отчёту, пока не проверил его руками, — это отдельный навык руководителя, такой же рабочий, как чтение отчёта о деньгах. Раньше без него жили: цифры собирали люди, с людей и спрашивали. Сейчас их собирает машина, и спросить с неё не с кого — отвечаете вы. Считаю так: пока вы своими глазами не увидели, что происходит с обращением клиента, все настройки, интеграции и скрипты преждевременны. Отправьте тестовую заявку сегодня, до конца дня, — а как закрыть найденные разрывы и поставить контроль, разобрано в бесплатном курсе . ## Автоматизация отчётности: во что выливаются полчаса ручного отчёта в день URL: https://davidgerstein.pro/blog/zametka-otchet-rukami/ Дата: 2026-08-23 Направление: Операционное управление Цифры: 30 мин/день · ~11 000 ₽/мес (оценка) · 22 рабочих дня Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас кто-то каждое утро руками собирает отчёт из CRM — вы уже платите за это шестьдесят часов в год. Полторы рабочие недели человека уходят на копирование цифр из одного окна в другое. Строки «перенос данных вручную» в бюджете нет, поэтому вы этих денег и не видите. Планёрка, вторник, утро. Лена спрашивает аналитика: «Слушай, а почему у тебя отчёт по отделу продаж каждый день в 10:40 приходит, а не в 9:00, как договорились?» Аналитик пожимает плечами: «Я его руками собираю. Захожу в CRM, смотрю сделки за вчера, считаю средний чек, конверсию, свожу в таблицу. Минут тридцать уходит, иногда больше — если что-то не сходится и надо перепроверять». Тридцать минут в день звучит несерьёзно. Настолько несерьёзно, что три квартала подряд никто не спросил, зачем это делает человек, а не система. Если вы сейчас мысленно перебираете свои регулярные отчёты — считайте, что диагноз уже поставлен. Ручной отчёт из CRM: что показал разбор цифр Отдел, для которого она считает три показателя — выручку, средний чек, конверсию, — это 12 менеджеров с оборотом около 4 млн ₽ в месяц. Средний чек по опту — около 90 000 ₽. Все эти цифры уже лежат в CRM. Аналитик просто набирает их заново в таблицу — руками, каждый день, в одно и то же время. Я задал ей вопрос в лоб: «Ты сверяешь данные, когда переносишь, или просто копируешь?» Оказалось — второе. Проверка «сходится ли» происходит раз в неделю, по пятницам. То есть 30 минут в день — не аналитическая работа, а механический перенос цифр из одного окна в другое. При ставке аналитика около 1000 ₽/час (оценка) это 500 ₽ в день. При 22 рабочих днях — примерно 11 000 ₽ в месяц (оценка). За год — больше 130 тысяч ₽ (оценка). Деньги не космические, но это стоимость получаса, который никто специально не выделял: просто так сложилось. Настоящая цена не в деньгах. Вот что сказала сама аналитик, когда мы спросили, что мешает ей заниматься содержательной работой: «Я бы хотела погруженно работать — взял задачу, погрузился, час ей занимался. А в большинстве случаев, если мне 15 минут удалось что-то поделать — это прям невероятная удача». Полчаса переноса цифр каждое утро — это ещё и разбитое начало дня: вы платите за час аналитики, а получаете полчаса. Что сделали: автоматизация отчётности вместо ручного переноса Лена задала свой любимый вопрос: «Кто владелец этого процесса — ты как аналитик или CRM как система?» Ответ очевиден: данные и так лежат в CRM, задача — не считать их руками, а вытащить. Вопрос про владельца здесь не риторический — с него начинается любой разбор процесса до узкого места и его хозяина . Настроили выгрузку трёх показателей напрямую из CRM в таблицу с автообновлением раз в час. Без нового софта и без разработки — штатный API системы, в которой уже ведутся сделки. Аналитик теперь ничего не переносит: цифры приходят сами, ей остаётся объяснять, почему конверсия просела в четверг. Скажу честно: автоматизировали три показателя, а не весь отчёт. Возвраты и региональная разбивка всё ещё требуют ручной сверки — источники в CRM и в бухгалтерии расходятся. Если у вас несколько версий одних и тех же цифр в разных выгрузках, это отдельная и более глубокая проблема, я разбирал её в статье про то, как поймал Битрикс24 на сдвиге дат . Здесь кейс проще: данные не врали, их просто перепечатывали. Вывод: чем обернулась история с отчётом Мы ещё не знаем, сколько времени в итоге освободится — через месяц смотрим, ушла ли аналитик от переноса цифр к объяснению, почему они такие. И следим, чтобы автоматизация не осталась без присмотра: по этой ловушке я отдельно разбирал кейс, где без ежедневного контроля процесс останавливался сам собой . Но первый эффект уже виден: отчёт приходит в 9:00, а не в 10:40, потому что его больше никто не собирает. Я и сам три квартала смотрел на этот отчёт и вопроса не задал — так что упрёк тут в первую очередь ко мне. Урок сформулировал так: если сотрудник каждый день в одно и то же время делает одно и то же механическое действие с данными, которые уже есть в системе, — это не про его дисциплину. Это про то, что никто не спросил, зачем здесь вообще человек. Спрашивать — отдельный навык руководителя, такой же рабочий, как умение читать бюджет: смотреть на регулярную работу и отделять перенос данных от выводов из них. Нужен ещё и контроль, который не зависит от памяти людей, — похожий принцип я разбирал на примере дебиторки . Что делаю теперь: раз в месяц прохожу по всем регулярным отчётам компании и по каждому решаю, где тратится время — на перенос данных или на выводы. Если на перенос — ищу, откуда вытащить цифры напрямую, вместо того чтобы поручать это человеку ещё раз, но быстрее. Ваш шаг на этой неделе: возьмите один регулярный отчёт, посчитайте его цену за год и покажите эту цифру тому, кто собирает его руками. Обычно после такого разговора автоматизация перестаёт быть «когда-нибудь» и становится задачей на неделю. Таких отчётов у вас почти наверняка больше одного, и каждый исполнитель уверен, что его случай особенный. Если вам непонятно, с какого конца за это браться, — разбираем по шагам в бесплатном курсе . Как выстроить отчётность целиком, чтобы такие получасовые дыры не появлялись, — там, где договариваются об одном источнике правды на каждый показатель . ## Риски внедрения ИИ: почему проект умирает уже после запуска URL: https://davidgerstein.pro/blog/pochemu-vnedrenie-ii-ne-rabotaet/ Дата: 2026-08-22 Направление: Операционное управление Цифры: 5 ошибок · 1 отзыв на 7139 оценок · цель занижена в 3 раза Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваш пилот с ИИ заглох — вы в большинстве. Разбираю пять причин, по которым внедрения умирают, хотя технически всё работало. Четыре из пяти я прошёл лично. За последний год я поставил в операционку среднего бизнеса несколько ИИ-контуров: оценку качества звонков, распознавание документов, отчётность для руководителей. Часть из них работает и приносит измеримую пользу. Часть — работает технически и не приносит ничего. Эта статья про вторую категорию, потому что про неё не пишет никто: агентства продают кейсы успеха, а самое дорогое знание лежит в провалах. Все ошибки ниже — мои собственные. Каждая стоила недель работы, и каждую можно было предвидеть. Какие риски у внедрения ИИ в компании? Главный риск не технический: система работает, а отдел — нет. Контур оценки качества звонков в компании на 40 человек сделал 7139 оценок, порядка 177 в день, и получил за весь период ровно один разбор от руководителя. Оценки были, ритуала разбора не было — и 25 000 ₽/мес эксплуатации ушли впустую. Остальные четыре риска той же природы: процесс, который молча останавливается и ждёт человека; данные CRM, которым поверили без проверки (12,9% лидов с изменённой задним числом датой); пилот, выданный за продакшен; эффект, посчитанный в технологиях вместо денег. Все пять проверяются одним вопросом: кто и когда в следующий раз посмотрит на результат системы и что после этого изменится в работе отдела. Ошибка 1. Вы считаете это технической задачей Самая частая и самая дорогая: вы отдаёте проект в ИТ и ждёте результата, а результат зависит от того, изменят ли люди свою работу. Технический запуск и управленческое внедрение — разные задачи. Система может оценивать сотни разговоров в месяц безупречно и не изменить ни одной цифры в продажах, если результаты этой оценки никто не разбирает с сотрудником. Мой самый поучительный провал выглядит так. Система оценки качества звонков: слушает все разговоры менеджеров, оценивает по чек-листу, показывает провалы. Технически — образцовая: за период эксплуатации она оценила 7139 разговоров, порядка 177 в день, себестоимость эксплуатации — около 25 000 ₽ в месяц. Ни один отдел контроля качества не даст такой охват за такие деньги. А теперь цифра, которая важнее: за весь период руководители оставили на эти оценки один отзыв . Один. Калибровка критериев оборвалась через месяц после запуска. Система продолжала оценивать — результаты никто не разбирал. 7139 — оценок звонков сделано 1 — разобрано с руководителем Технология заработала. Управленческая петля — нет. Оценка звонка что-то меняет только тогда, когда руководитель садится с менеджером и разбирает разговор. Этот ритуал никто не спроектировал: считалось, что «система покажет — люди увидят». Не увидят. У людей есть текущая работа, и новый экран с оценками в неё не встроен. Правило Ритуал разбора результатов проектируется раньше, чем модель. Если в плане внедрения нет строки «кто, когда и что делает с выводами системы» — внедрения нет, есть эксперимент за деньги компании. Ошибка 2. Робот, за которым приходится следить Автоматизация, которая требует, чтобы за ней следили, — это не автоматизация. Это вторая работа: вы не убрали задачу, а добавили к ней слежку за роботом, который её выполняет. Почему так выходит и как из этого выбираться, я разбирал отдельно — в тексте про автоматизацию, которая требует надзора . Вторая история короче. Автоматический процесс публикации контента упёрся в ошибку и молча остановился. Утром я обнаружил, что ничего не вышло, запустил руками, разобрался. Через неделю — снова. Фраза, которую я тогда сказал своему же ИИ-ассистенту, стала для меня определением проблемы: «Если бы я не пошёл к тебе, ничего бы не произошло» . У каждого автоматического процесса должны быть три вещи, и они дороже самой автоматизации: перезапуск после сбоя без человека, громкое оповещение, когда перезапуск не помог, и ответ на вопрос «работаешь ли ты прямо сейчас», который можно получить за десять секунд. Пока этих трёх вещей нет — процесс нельзя считать внедрённым. После того как я добавил все три компонента, картина изменилась: за следующий месяц процесс падал дважды, но оба раза перезапустился сам, а я узнал об этом из уведомления, а не из отсутствия публикации утром. Разница не в том, что процесс перестал ломаться — он ломается так же. Разница в том, что я перестал быть частью его схемы восстановления. Ошибка 3. Доверие к данным, на которых всё стоит ИИ-отчётность строится на данных CRM — а данные врут. Не метафорически: в один из месяцев я обнаружил, что у 12,9% лидов дата создания изменилась задним числом . Сдвиги накапливались, две выгрузки за один и тот же период давали разные числа. Отчёты, построенные на этих данных, были красивыми, убедительными и неверными — подробно я разобрал это в статье про враньё данных в CRM . Отдельный случай той же болезни — модели, которые убеждают сильнее, чем заслуживают. Первая версия стратегической модели, которую я собирал для совета директоров, показала рост выручки на 9 млн ₽ в год против утверждённого плана в 27 млн ₽ — ровно втрое меньше. Поймали до показа — сверкой с утверждённым планом. Если бы не поймали, руководство приняло бы решения на основе цифры, которая выглядела идеально и была неверна. Правило Дашборд на недостоверных данных опаснее отсутствия дашборда: он придаёт уверенность. Аудит достоверности данных — обязательная часть любого проекта отчётности, и он всегда находит расхождения. Всегда. Ошибка 4. Ваш пилот так и остаётся пилотом Признак: у проекта нет даты, после которой старый способ работы отключается. Пока она не назначена, ваша команда будет держаться за привычное. Рынок устроен так, что подрядчику выгодно продать пилот: быстро, дёшево, красиво на демо. Пилот почти всегда «успешен» — и почти никогда не доживает до ежедневной работы, потому что между демо и продакшеном лежит всё самое дорогое: обработка граничных случаев, права доступа, поведение при сбоях, обучение людей, встраивание в существующий процесс. На распознавании документов я прошёл этот путь целиком. На демо всё распознаётся прекрасно. В реальном потоке: сканы вверх ногами, один документ в пяти файлах, рукописные вставки, типы документов, которых нет в библиотеке. Точность извлечения ключевых полей у нас выросла с 59% до 85% — но не сменой модели, а месяцами калибровки под каждый из 79 типов документов и, главное, честным разделением потока на режимы: что обрабатывается автоматически, что — автоматически с проверкой человеком, что — только руками. Без этого разделения первая же ошибка на важном документе убивает доверие ко всей системе. После разделения структура потока выглядела примерно так: около 70% документов проходят полностью автоматически, порядка 25% — автоматически, но с обязательной проверкой человека, и около 5% система сама отправляет в ручную обработку, не пытаясь угадать (оценка). Именно эти 5% и были демонстрационным провалом на этапе пилота — подрядчик показывал только первую категорию. Ошибка 5. Считать эффект в технологиях, а не в деньгах «Мы внедрили нейросеть» — не результат. Результат — это «комплект документов, который менеджер раскладывал полтора часа, теперь раскладывается за минуты, и менеджер за день обрабатывает втрое больше клиентов». Если эффект нельзя сформулировать в часах и деньгах — его, скорее всего, нет, и технология поставлена ради технологии. Сколько это стоит в живых деньгах, я разбирал отдельно, на своих счетах за использование моделей — см. статью про реальные расходы на ИИ . Как встроить ритуал без ручного контроля Ритуал разбора результатов автоматизируется тем же контуром, что и сама оценка: вебхук раз в неделю выгружает данные и формирует готовую повестку встречи — тогда он не зависит от того, вспомнит ли руководитель отдела продаж открыть отчёт сам. Ниже — рабочая связка для CRM на Bitrix24, где оценки звонков уже пишутся в поля сделки. Вебхук раз в неделю собирает JSON с оценками, модель отбирает проблемные звонки и формирует повестку. Это ровно та часть, которой не хватило в моём кейсе из ошибки №1. Пример ответа модели на приведённых данных: Такая связка не заменяет встречу руководителя с менеджером — она убирает единственный шаг, на котором мой ритуал развалился: «зайти и посмотреть отчёт». Повестка приходит готовой, встречу остаётся провести. Экономика: во что обошлась ошибка №1 Настройка системы оценки звонков заняла ~20 часов, эксплуатация — ~25 000 ₽/мес. Потенциальный эффект при работающем ритуале разбора — если он всего на 2 сделки из 50 в месяц меняет исход — ≈ 360 000 ₽/мес (оценка). Мы получили не эту цифру, а ноль: ритуал не заработал, и все 25 000 ₽/мес ушли в эксплуатацию системы, которую никто не использовал по назначению. Пример на цифрах отдела. Восемь менеджеров, оборот отдела ~9 млн ₽/мес, средний чек ~180 000 ₽ — это 50 сделок в месяц. Если оценка звонков стабильно выявляет и чинит один типовой сбой у одного менеджера — например, менеджер не проговаривает следующий шаг, и сделка «подвисает», — и это спасает 2 сделки в месяц, эффект составил бы 2 × 180 000 = 360 000 ₽/мес. Это оценка потенциала, а не измеренный факт: у нас ритуал так и не заработал, проверить цифру на практике не удалось. Что мы не считаем эффектом: сам факт наличия 7139 оценок в системе. Оценки — это запас информации, а не поток денег. Пока их никто не разбирает с менеджером, они не конвертируются ни в одну сделку. За два месяца эксплуатации без ритуала расходы составили 25 000 × 2 = 50 000 ₽ чистых потерь — система работала, отдел продаж не изменился. Атрибуция здесь простая, потому что инициатива в этот период была одна: весь эффект — и его отсутствие — на счету системы оценки звонков, без наложения других изменений в отделе. Сводка: где именно возникают риски внедрения ИИ Пять ошибок дают одну и ту же картину: технический результат почти всегда лучше управленческого. Ниже — сведённая таблица по каждому случаю из этой статьи. Ошибка Технический результат Управленческий результат Цена простоя Оценка звонков 7139 оценок, 177/день 1 отзыв руководителя за весь период 50 000 ₽ за 2 месяца без ритуала Автопубликация Работает без сбоев большую часть времени Останавливается молча, нужен человек для перезапуска ручной контроль каждую неделю CRM-отчётность Дашборд построен и выглядит убедительно 12,9% лидов с изменённой задним числом датой решения на основе неверных цифр Стратегическая модель Модель считает и визуализирует прогноз Занизила цель по выручке в 3 раза (9 млн ₽ вместо 27 млн ₽) риск утверждения неверного плана советом директоров Распознавание документов Точность выросла с 59% до 85% Итог дали месяцы калибровки, а не смена модели месяцы дополнительной настройки Общий знаменатель виден без комментариев: в каждой строке техническая часть выполнена, а управленческая — нет. Это не совпадение, это структура проблемы. Чек-лист на понедельник Пять проверок из этой статьи можно сделать за один рабочий день, не дожидаясь следующего провала. Проверить, кто и когда в последний раз разбирал результаты работающей ИИ-системы — если ответа нет, ритуал не работает. Найти в каждом автоматическом процессе точку молчаливого падения — и проверить, есть ли на неё оповещение. Сверить одну и ту же выгрузку из CRM дважды с интервалом в неделю — если числа разошлись, отчётности пока нет. Сравнить любую модель прогноза с утверждённым планом вручную, прежде чем показывать её руководству. Спросить у подрядчика, что происходит с кейсом, который не подходит под стандартный сценарий — ответ «такого не бывает» означает пилот, а не продакшен. Что из этого следует Внедрение ИИ проваливается не там, где ожидают. Не в модели — модели сейчас хороши. Оно проваливается в четырёх местах: в отсутствии управленческого ритуала вокруг системы, в автоматизации без самоконтроля, в данных, которым поверили без проверки, и в пилоте, который выдали за продакшен. И назову вслух то, что за этими пятью рисками стоит. Довести машину до эксплуатации — это отдельный управленческий навык, такой же осваиваемый, как бюджетирование или постановка задач. Он складывается из трёх умений: спроектировать ритуал разбора раньше, чем модель; потребовать у процесса самоконтроль вместо вашего внимания; проверить данные до того, как на них построен ваш отчёт. Руководитель, который этим владеет, стоит дороже руководителя, умеющего только раздавать задачи людям: первый масштабирует отдел через машину, второй — только через найм. Я этот навык осваивал задним числом, на своих же провалах, и это самый дорогой способ. Все четыре — управленческие задачи, а не технические. Поэтому и заниматься ими должен тот, кто отвечает за результат отдела, а не тот, кто сдаёт проект по акту. Как эти места проходят по календарю — маршрут на два-три месяца и три развилки, на которых всё ломается . Если вынести из этой статьи одно правило, пусть это будет такое: перед тем как подписывать акт о внедрении, спросите не «работает ли система технически», а «кто и когда в следующий раз посмотрит на её результат и что после этого изменится в работе отдела». Если ответа нет — акт подписывать рано, сколько бы разговоров система ни успела оценить. Проверьте свой проект по этим пяти пунктам прямо сейчас. Если найдёте хотя бы два — у вас есть недели две, чтобы что-то исправить, прежде чем команда окончательно потеряет к нему интерес. Как доводить до эксплуатации, а не до демо, — по шагам в бесплатном курсе для руководителей . И проверьте ваш проект на главный признак: назначена ли дата, когда старый способ работы отключается. Если нет — ваш пилот останется пилотом, каким бы хорошим он ни был. ## Текучесть кадров: причины ухода и что делать руководителю URL: https://davidgerstein.pro/blog/tekuchka-kadrov-prichiny/ Дата: 2026-08-19 Направление: Люди Цифры: 5–7 тыс. ₽ — забытая надбавка, которая запустила увольнение · 3-й месяц — точка первого управляемого кризиса менеджера · 80% — разрыв в зарплате руководителя и линейного сотрудника Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Текучесть кадров: причины и что делать руководителю Коэффициент текучести нужен вам для отчёта, а управлять приходится причинами. Люди уходят из отдела по трём причинам: невыполненное обещание , предсказуемый кризис третьего месяца и недоверие внутри отдела . Деньги в этом списке обычно четвёртые, а не первые. Один цикл замены менеджера съедает около 69 часов управленческого и наставнического времени — примерно 69 000 ₽ прямых затрат. Поэтому первое действие — не «нанять нового», а разложить каждое увольнение по причине и заранее поставить точку контроля на 3-й, 6-й и 9-й месяц работы каждого вашего менеджера. Люди уходят, вы нанимаете новых, и через полгода история повторяется. Знакомо? Тогда у вас не проблема с наймом — у вас проблема с тем, что происходит после него. Разбираю, как считать причины текучести, а не людей: с цифрами, которые можно собрать за неделю. Сотрудница взяла на себя чужую задачу в ноябре — помогла другому отделу по просьбе коллеги. Обещали доплату 5–7 тысяч рублей. Не дали. Через несколько месяцев ей снова предлагают ту же нагрузку. Руководитель приходит с запросом: инициировать надбавку, но аккуратно, чтобы не подорвать авторитет её прямого начальника. Вот тут и живёт текучесть кадров — не в зарплатной ведомости, а в этом зазоре между обещанием и фактом. Когда меня спрашивают, текучесть кадров что делать, я не отвечаю сразу про деньги или мотивационные программы. Сначала предлагаю посчитать: сколько человек ушло за последние полгода, по какой причине — реальной, а не той, что написана в заявлении, — и во сколько часов управленческого времени обходится каждый такой уход. Дальше в статье — как это считать и как ловить сигнал риска до заявления, а не после. Текучесть кадров: что делать в первую очередь Первая ошибка — лечить симптом. Уволился менеджер — ищем нового. Ещё один ушёл — снова ищем. Через квартал новых людей больше, чем старых, а проблема не решена, потому что она вообще не в людях. Я считаю причины по каждому увольнению отдельно, а не сваливаю их в графу «не сошлись характерами». В нашей практике причины делятся на три группы: невыполненные обещания, отсутствие доверия и предсказуемые кризисы роста, которые никто не отследил вовремя. Плюс отдельная структурная причина — разрыв в оплате труда между руководителем и его же подчинёнными. Причина ухода Как выглядит на практике Что делать Невыполненное обещание Доплату за доп. нагрузку обещали — не дали. Поездку за результат обещали — проект закрыли Фиксировать обещания письменно, выполнять или явно отменять с объяснением Кризис третьего месяца Новый менеджер выгорает, падает продуктивность Плановый отпуск, «контролируемое падение» вместо ожидания срыва Недоверие / фасад Руководитель говорит «мы сделали», но лично не применяет инструменты Личная ответственность вместо коллективного «мы» Разрыв в оплате труда Руководитель получает меньше подчинённых Пересмотр модели дохода руководителя, привязка к результату отдела Обещания — самый дорогой источник текучести Пример с доплатой в 5–7 тысяч рублей — не мелочь. Дело не в сумме. Человеку один раз сказали «сделаем» — и не сделали. А потом попросили ту же работу снова. Второй раз доверия к словам руководителя уже нет, даже если деньги в итоге придут. Похожая история — с поездкой за границу. Компания планировала мотивировать лучшего менеджера по продажам трёхмесячной поездкой за результаты. Проект закрыли из-за внешних обстоятельств, обещание не выполнили. Руководитель позже признал это критической ошибкой. Формулировка честная: люди приходят за деньгами, а остаются не из-за денег. Молодых сотрудников в отделе продаж мотивируют не оклад, а поездки, события, ощущение, что о них помнят. Как только это ощущение ломается один раз — начинается тихий отток, который не виден в отчётах до момента увольнения. Правило Не давайте обещаний, которые не готовы выполнить при любом раскладе. Лучше сказать «пока не знаю» и вернуться к разговору позже, чем пообещать и не сдержать. Второе стоит доверия команды дороже, чем сама несделанная выплата. Кризис на третьем месяце — это не характер, а физика У новых менеджеров есть закономерность: первый кризис случается на третий месяц работы. Потом либо на шестой, либо на девятый. Это не индивидуальная слабость — это предсказуемый цикл выгорания у людей, только вышедших на активную нагрузку. Если руководитель ждёт, пока сотрудник сам сорвётся, — получает увольнение или конфликт. Если управляет циклом заранее — отправляет человека в отпуск на пике продуктивности, до того как маятник качнётся в другую сторону. Задача — выровнять сотрудника на плато, а не позволить ему рухнуть до нуля. То же самое случилось с сотрудницей, которая провела серьёзный анализ юнит-экономики, построила модели — а на встречу пришла со словами «я ничего не делаю». Дело было не в результате работы, а в навыке защищать этот результат перед руководством. Решение — не отругать, а дать структуру поддержки: короткая сессия на следующий день, потом еженедельный чек-лист. Это дешевле, чем нанимать и обучать нового человека с нуля. Удержание сотрудников без иллюзий про доверие Точная фраза про управленческую культуру: если руководитель приходит и лично разбирается в чужой работе, значит, он не доверяет тому, кто эту работу должен делать. Верно и обратное. Если сотрудник вынужден каждый раз доказывать очевидное — например, запрашивать письменное распоряжение на каждого нового человека, хотя заявка от HR уже подана, — доверия в системе тоже нет. Оно просто спрятано в бюрократии. Реальный пример: новых сотрудников нужно оснастить техникой, но процесс тормозит требование дополнительного письменного распоряжения руководителя на каждое включение в систему — при том что заявка от отдела кадров уже есть. Итог — люди не выходят на работу в оговорённый день. Для нового сотрудника это первое впечатление о компании. Оно формирует решение уйти быстрее, чем любая зарплатная ведомость. Похожая ловушка — руководитель отдела, который на встречах с собственником говорит «мы это сделали», а при личном разборе признаётся, что лично инструментами не пользовался из-за нехватки времени. Команда это чувствует. Если начальник не берёт личную ответственность, а прячется за «мы», подчинённые быстро понимают: спрашивать будут не с него, а с них. Такая асимметрия — тоже причина текучести, просто она не в зарплате, а в структуре ответственности. Мотивация сотрудников нематериальная: что реально работает Нематериальная мотивация — не про корпоративы для галочки. В нашей практике сработали три конкретных инструмента. Анонимная обратная связь как основа для бонусов Компания внедрила анонимную метрику оценки коллег, на основе которой считаются бонусы. Это снимает субъективность: сотрудник видит, на какие именно критерии влияет размер доплаты, а не гадает, почему коллеге дали премию, а ему нет. Профилирование вместо усреднённого подхода Собственник запросил у руководителей подробные профили сотрудников: сильные и слабые стороны, специализация по клиентам, успехи и провалы. Цель — точнее распределять задачи и обучение, чтобы человек не занимался не своим делом и мог передать навыки коллегам. Это тоже форма нематериальной мотивации: человек видит, что его особенности учитывают, а не просто затыкают им дыры в графике. Выбор направления вместо угрозы увольнением При автоматизации части процессов развивающиеся сотрудники оказались перед выбором — куда двигаться дальше. Руководитель формулирует это так: терять ценного человека нельзя, а у него есть амбиции расти — значит, ему предлагают выбрать направление самому, а не ставят перед фактом сокращения. Так же поступили и с отделом контроля качества: штат сократился заметно за счёт нейросетей, но людей не уволили, а переквалифицировали в специалистов, которые управляют ИИ-системами и аудируют коммуникацию. Это отдельная инициатива, её экономия ФОТ не пересчитывается в этой статье — здесь важен только принцип: смещать роль, а не убирать человека. Где ломается Профилирование и анонимная обратная связь работают только если результаты реально влияют на решения — доплаты, задачи, обучение. Если данные собрали и положили в стол, сотрудники замечают это за один цикл и перестают воспринимать инструмент всерьёз. ИИ-связка: сигнал риска увольнения раньше, чем человек напишет заявление Ручной разбор того, «как сотрудник себя чувствует», масштабируется плохо — руководитель физически не может слушать все звонки и планёрки каждую неделю. Но текстовые сигналы выгорания и недоверия повторяются: самоуничижение при объективно хорошем результате, безличное «мы» вместо «я», оправдания нехваткой времени. Это можно ловить автоматически. Схема конвейера: Расшифровки звонков и планёрок (Google Sheets, лист «Расшифровки») → Apps Script по расписанию раз в сутки → запрос к API дешёвой модели с промптом-скорингом → запись risk_score и рекомендации в соседние колонки → при превышении порога — уведомление руководителю в Telegram → руководитель сам решает, назначать встречу или нет. Модель здесь — дешёвая (GPT-4o-mini или аналог), не дорогая reasoning-модель. Задача рутинная: классификация текста по чётким критериям на большом ежедневном потоке, творческое рассуждение не нужно, а стоимость запроса должна оставаться копеечной при сотнях расшифровок в месяц. Пример ответа модели: Так этот результат ложится в саму таблицу — лист «Скоринг», по которому руководитель видит, у кого назрел разговор: Google Sheets — лист «Скоринг» 72 risk_score, mgr_014 employee_id дата risk_score рекомендация mgr_014 2026-08-12 72 срочная встреча Инженерная обвязка простая и без внешнего сервера. Таблица Google Sheets — единственное хранилище: лист «Расшифровки» (сырые данные), лист «Скоринг» (результат модели), лист «Лог ошибок». Apps Script по time-driven триггеру раз в сутки читает новые строки без оценки, вызывает API, парсит JSON и пишет результат. Если модель вернула невалидный JSON или API не ответил за отведённое время — строка помечается статусом «ошибка» и пишется в лог с таймстампом; после трёх ошибок подряд бот шлёт алерт администратору в отдельный Telegram-чат. Ручной перезапуск — через пункт кастомного меню в самой таблице, без доступа к серверу. Для расшифровок звонков логично использовать тот же источник, что и в контроле качества — я разбирал его отдельно в статье про контроль качества звонков без ОКК . Где ломается Скоринг ловит текстовые маркеры, а не диагноз. Модель ошибается на сарказме, цитатах клиента внутри расшифровки и коротких формальных звонках без эмоциональной окраски. Нельзя принимать кадровое решение по одному risk_score — это триггер для разговора, а не приговор. И нельзя отправлять в API расшифровки с персональными данными клиентов без обезличивания — здесь у меня отдельный разбор в статье про персональные данные и нейросети . Онбординг как фильтр текучести на входе Часть текучести закладывается ещё до того, как человек толком начал работать. Новый менеджер получает клиента, не понимая реальной ценности услуг компании. Когда клиент спрашивает «за что я платил?», менеджер не может ответить убедительно — потому что сам не верит в предложение. Это часто приводит к расторжению контракта при первом же контакте с клиентом — и увольнению менеджера следом. Решение оказалось системным, а не разовым инструктажем. Разработан пятидневный курс: первый день — о компании и партнёрах, дальше — клиентский путь, точки касания, типы клиентов, скрипты, реальные кейсы. Каждый день заканчивается тестом на отдельном экране, чтобы нельзя было подсмотреть ответы. Курс лежит на портале с личным кабинетом для каждого менеджера, прогресс отслеживает Telegram-бот. Раньше на такое обучение опытный коллега тратил несколько дней в режиме живых созвонов, отвлекаясь от клиентов. Теперь новичок учится сам, никого не отвлекая — это отдельный эффект именно от курса, не от скоринга звонков из предыдущего раздела. Планируется расширение: шаблоны документов с примерами, видеоинструкции по оформлению документов, чек-лист в конце обучения и видеозадания по стадиям работы. Подробный разбор того, как выстроить такую систему обучения без наставника-энтузиаста, который тянет всё на себе, — в статье про онбординг как систему . Экономика текучести: что стоит система и что она экономит Разберу по отдельности две вещи, которые нельзя смешивать: стоимость одного увольнения (диагностика) и стоимость инструментов удержания (лечение). Во сколько обходится один уход менеджера — оценка в часах управленческого и обучающего времени, без учёта потерянной выручки от простаивающих клиентов: Поиск и найм замены ~20 ч Онбординг вручную (созвоны) ~24 ч Просадка до выхода на план ~15 ч Риск ухода на 3-м месяце ~10 ч Итого около 69 часов управленческого и наставнического времени на один цикл замены (оценка). При ставке около 1000 ₽/час это даёт примерно 69 000 ₽ прямых управленческих затрат на одного ушедшего менеджера (оценка), не считая просевших сделок с клиентами, которых он вёл. Возьмём условный отдел из 12 менеджеров с оборотом ~6 млн ₽/мес и средним чеком ~150 тыс. ₽ — это примерно 500 тыс. ₽ выручки в среднем на одного менеджера в месяц. Если за квартал из отдела ушло 2 человека — это около 17% состава, — компенсация потерь по расчёту выше обходится примерно в 138 000 ₽ управленческого и наставнического времени за квартал (оценка), не считая клиентов, которые за это время могли уйти вслед за менеджером. Формула для вашего случая: сумма часов на один цикл замены (найм + онбординг + просадка + риск повторного ухода) × ваша ставка часа управленческого/наставнического времени × число уходов за период = потери на закрытие текучести за этот период. Дальше эту сумму сравниваете со стоимостью инструментов удержания ниже — так считается окупаемость, а не берётся на веру. Теперь стоимость самих инструментов. Курс онбординга снимает большую часть блока «онбординг вручную» — по фактуре это те самые несколько дней живых созвонов опытного коллеги, то есть условные 24 часа на одного новичка, около трети от общих ~69 часов на цикл замены (оценка). Это эффект именно курса, отдельно от скоринга звонков — складывать их напрямую нельзя, они закрывают разные строки в расчёте выше. Скоринг риска увольнения (Google Sheets + Apps Script + дешёвая модель) — это про блок «риск повторного ухода на 3-м месяце». Внедрение: настройка таблицы, промпта и Telegram-бота — оценка 15–20 часов работы аналитика, то есть 15 000–20 000 ₽ по той же ставке (оценка) — меньше трети стоимости одного цикла замены менеджера. Эксплуатация при потоке до сотни расшифровок в месяц на дешёвой модели — около 500–800 ₽ в месяц (оценка, зависит от объёма и длины расшифровок). Пример окупаемости: если скоринг помогает поймать сигнал и провести разговор хотя бы у одного менеджера в квартал, который иначе ушёл бы на третьем месяце, — предотвращённый цикл замены (≈69 000 ₽, оценка) окупает разовую настройку и несколько месяцев эксплуатации в разы. Сам эффект — не гарантированное удержание, а более раннее вмешательство: разговор до заявления вместо разбора причин после него. Инструмент Разовые затраты (оценка) Регулярные затраты (оценка) Какой блок потерь закрывает Курс онбординга время на разработку курса (не пересчитано в этой статье) ≈0 ₽ — новичок проходит самостоятельно Онбординг вручную: ≈24 ч экономии на одного новичка — около трети всего цикла замены Скоринг риска увольнения 15–20 ч ≈ 15 000–20 000 ₽ — меньше трети стоимости одного цикла замены ≈500–800 ₽/мес на API Риск повторного ухода на 3-м месяце: ≈10 ч на цикл, плюс шанс предотвратить весь цикл замены целиком Что считать вместо того, чтобы менять людей — чек-лист на понедельник Назову навык руководителя, который здесь решает всё: считать причину, а не человека. Я сам годами путал эти две вещи — вёл список уволившихся вместо списка причин, и каждый раз выходило, что виноват конкретный человек: этот не потянул, тот не вписался. Список причин выглядит скучнее и работает честнее: в нём сразу видно, что одна и та же поломка вынесла трёх менеджеров подряд, и чинить надо её, а не искать четвёртого. Вернусь к вопросу, с которого начал: текучесть кадров что делать. Мой практический ответ — считать, а не заменять. По каждому увольнению фиксировать: было ли невыполненное обещание, был ли это предсказуемый кризис на 3–6–9 месяце, была ли асимметрия доверия между руководителем и командой, была ли структурная причина — например, зарплата руководителя ниже, чем у подчинённых, из-за волатильности премий. Последний пункт — не абстракция. Есть случай, где руководитель подразделения получает в среднем на 40% больше других руководителей и на 80% больше линейных сотрудников своего отдела — это здоровая структура. А в другом случае руководитель производства получает меньше своих сотрудников, включая стажёра, пришедшего месяц назад. Демотивированный руководитель демотивирует всю команду под собой, и текучесть там начинается не с линейного персонала, а сверху. С чего начать в понедельник: Выгрузить список уволившихся за последние 6–12 месяцев и распределить причины по четырём категориям из таблицы выше — не по формулировке из заявления, а по реальной причине. Проверить, есть ли в компании хоть одно неисполненное обещание сотруднику прямо сейчас, — закрыть его или явно снять с объяснением в течение недели. Отметить в календаре 3-й, 6-й и 9-й месяц работы каждого менеджера и заранее запланировать точку контроля или отпуска, а не ждать срыва. Собрать 15–20 расшифровок звонков одного отдела и прогнать через промпт выше вручную, прежде чем автоматизировать поток целиком. Сравнить зарплату руководителей с зарплатой их подчинённых — найти инверсии и решить, что с ними делать в первую очередь. Ввести анонимную обратную связь коллег хотя бы в одном отделе на квартал и убедиться, что результаты реально влияют на доплаты. Если в компании нет системы, которая фиксирует такие разрывы и обещания, — их не видно до момента, пока человек не напишет заявление. Тогда уже поздно считать причины, остаётся только считать затраты на новый найм и обучение. Начните с простого замера: сколько человек ушло за год и на каком сроке работы. Если большинство уходит в первые три месяца — дело в найме и адаптации. Если после года — в развитии и деньгах. Это две разные задачи, и лечатся они по-разному. Как собрать этот расчёт и разбирать причины по типам — в бесплатном курсе для руководителей . И вопрос, который стоит задать себе прямо сейчас: вы знаете, почему ушёл ваш последний сотрудник? Не формулировку из заявления, а настоящую причину. Если нет — вы не управляете текучестью, вы за ней наблюдаете. И самое неудобное для вас: спросите себя честно, знаете ли вы, кто из ваших людей сейчас на выходе. Обычно руководитель узнаёт об этом в день заявления, хотя решение человек принял месяц назад — и весь этот месяц подавал сигналы, которые вы не читали. И последнее для вас: считайте не только тех, кто ушёл, но и тех, кто остался и перестал стараться. Вторых обычно больше, и обходятся они дороже. Ваш замер на неделю: сколько человек ушло за год, на каком сроке и по какой настоящей причине. Три колонки — и вы увидите свою систему, а не отдельные истории. Как поставить это на регулярную основу — в бесплатном курсе . ## Персональные данные и ИИ: что можно доверить машине, а что запрещено законом URL: https://davidgerstein.pro/blog/personalnye-dannye-i-neyroseti/ Дата: 2026-08-17 Направление: Право и риски Цифры: фильтр ПД дешевле ручной проверки в 25–80 раз · окупаемость запуска фильтра меньше месяца · ревизия доступов с чек-листом короче в 2 раза Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Ваши сотрудники прямо сейчас вставляют данные клиентов в нейросети. Не со зла — просто им так удобнее, а правил вы не давали. Если вы не можете за минуту назвать, в каких ИИ-сервисах работает ваша команда и через чьи учётные записи они подключены, — у вас нет контроля над персональными данными. У вас есть надежда на аккуратность людей, а это не контроль. Разбираю, что можно и нельзя отправлять в ИИ, и как объяснить это команде так, чтобы правило соблюдалось. Аудит одной компании нашёл JavaScript-файл на публичном сервере с кошельками, данными менеджеров и информацией о клиентах. Файл индексировался поисковиками. Любой человек мог найти его обычным запросом в поиске — без взлома, без пароля, просто через выдачу. Никто в компании об этом не знал, пока не пришёл аудитор. Это и есть точка, где персональные данные и ИИ сталкиваются на практике: удобство автоматизации оборачивается дырой, о которой узнают последними. Это тема, которая всплывает в таких аудитах регулярно, потому что бизнес спешит автоматизировать процессы и не задаёт себе простой вопрос: куда уходят данные, которые в него заливают. Ревизия доступов на компанию среднего размера с несколькими юрлицами — это, по грубой оценке, 15–20 часов работы одного специалиста. Цена утечки, которую находит конкурент или регулятор раньше вас, не считается в часах. Персональные данные и ИИ: что нельзя отправлять в нейросеть В публичный чат нельзя: персональные данные клиентов и сотрудников (ФИО с контактами, паспорта, адреса, зарплаты), коммерческую тайну, доступы и ключи. Правило простое: если по данным можно опознать конкретного человека — они не идут в чат ни в каком виде. Рабочее решение — обезличивание до отправки: не «Иванов Пётр, +7 916…», а «клиент К., постоянный, чек 180 тыс. ₽». На качество ответа это не влияет, а автоматический фильтр обходится в 25–80 раз дешевле ручной проверки. Где именно ваш риск Не в том, что «ИИ украдёт данные». В том, что ваш сотрудник вставит в публичный чат таблицу с клиентами, потому что так быстрее. Когда сотрудник копирует переписку с клиентом в ChatGPT, чтобы «пусть ИИ ответит красивее», данные уходят на серверы сервиса, который физически находится за пределами страны. Это не абстракция. В одной компании юрист специально проверял это: документы клиентов лежали на американских серверах 2–3 месяца. Нужно было убедиться, что в договорах есть согласие клиента именно на трансграничную передачу данных. Без этого согласия компания нарушает закон, даже если ИИ используется из лучших побуждений и экономит менеджеру час в день. При аудите безопасности в другой компании выяснилось: вебхуки лежат без защиты, система имеет доступ к данным клиентов через внешний портал. Ошибки в коде оказались не главной бедой — хуже дыры в архитектуре доступа, через которые к чувствительным данным может добраться кто угодно со стороны. Сначала закрыли технические дыры и только потом занялись самим инструментом. Порядок важен: подключать нейросеть к процессу с дырявой архитектурой доступа — то же самое, что ставить сигнализацию на дверь, а окно оставлять открытым. Правило Прежде чем подключать нейросеть к рабочим процессам, проверьте архитектуру доступа. Промпт не спасёт, если данные утекают через незащищённый вебхук или таблицу с доступом «по ссылке для всех». Как проверить свой процесс перед подключением ИИ Четыре вопроса, на которые вам нужно ответить до того, как машина увидит первые данные. Всё это можно повторить со своей командой за одну-две недели. Вот последовательность, которую я использую сам. Инвентаризация. Составить список всех мест, откуда сотрудники берут данные для ИИ: CRM (Bitrix24, amoCRM), Google Таблицы, мессенджеры, файлы на сервере. Отдельно — список сервисов ИИ, к которым есть доступ, и через чьи учётные записи они подключены. Классификация данных. Разметить, какие поля в этих источниках относятся к персональным данным: ФИО, телефон, адрес, паспорт, платёжные реквизиты, данные о здоровье и происхождении. Это делает юрист или ответственный за комплаенс, не разработчик «на глаз». Фильтр перед моделью. Между источником данных и запросом к нейросети ставится промежуточный шаг — дешёвая модель или скрипт, который проверяет текст на наличие ПД и либо маскирует его, либо блокирует отправку. Это и есть техническая часть, разобранная в следующем разделе. Согласия и договоры. Проверить, есть ли в договорах с клиентами формулировка о согласии на трансграничную передачу данных — если ИИ-сервис зарубежный. Без неё юридически рискует не разработчик, а компания-оператор ПД. Контроль доступов. Развести права по принципу «один человек — одна таблица», токены и вебхуки хранить не в общих файлах, а в переменных окружения кода. Раз в квартал — повторный аудит, особенно после расширения команды. ИИ-связка: фильтр перед отправкой Техническое решение вашей проблемы: данные обезличиваются до того, как уйдут наружу, а не по памяти сотрудника. Конвейер простой: данные лежат в Google Таблице (или приходят вебхуком из Bitrix24) → перед тем как текст уходит в основную модель для анализа или генерации ответа, он проходит через дешёвую модель-классификатор → если найдены персональные данные, текст маскируется или блокируется → результат и лог решения пишутся в отдельный лист, ответственному падает уведомление в Telegram. Схема конвейера текстом: Google Sheets / Bitrix24-вебхук → Apps Script (триггер по расписанию) → дешёвая модель-классификатор → маскирование/блокировка → лист «Проверено» + алерт в Telegram при high-риске → только после этого текст может уйти в основную (дорогую) модель для содержательной работы . Для классификации персональных данных не нужна дорогая модель — задача формальная, не творческая: найти категории и вернуть структуру. Для такой задачи достаточно недорогой модели-классификатора начального уровня — она справляется не хуже старших моделей, а стоимость обращения на порядок ниже, чем даже одна SMS-верификация номера, которая в одной из компаний обходилась заметно дороже одного обращения к такому фильтру. Структура входных данных, которые Apps Script отправляет в модель (пример строки из Google Таблицы с заявками клиентов): Промпт для дешёвой модели-классификатора (system + user, отправляется через Apps Script UrlFetchApp на эндпоинт модели): Пример ответа модели на строку выше: Дорогая модель — старшая версия того же семейства — подключается только на следующем шаге, когда текст уже промаскирован, и работает с содержанием: формирует ответ клиенту. Распознавать ПД ей незачем — не потому что она хуже справляется, а потому что гонять сложную модель на формальную задачу классификации попросту дорого. Как это выглядит в самом листе «Проверено», куда Apps Script пишет результат каждой проверки: Google Sheets — лист «Проверено» ~1 200 обращений к фильтру в месяц ×25–80 дешевле ручной проверки doc_id risk_level action статус row_57 high block_before_ai row_58 medium mask row_59 low pass Обе цифры — оценка по потоку документов условной компании, расчёт — в разделе «Экономика». Инженерная обвязка Где крутится. Google Apps Script с триггером по времени (каждые 10–15 минут) читает новые строки таблицы или принимает вебхук от Bitrix24/amoCRM. Как перезапускается. Триггер идемпотентен: если модель не ответила или вернула невалидный JSON, строка помечается статусом «retry» и берётся в следующий проход. Без ручного вмешательства. Как сообщает об ошибке. Ошибки API (таймаут, невалидный ответ) пишутся в отдельный лист «Errors» с timestamp и текстом ошибки; при risk_level = high и при трёх подряд ошибках — уведомление ответственному в Telegram-бота. Учёт расходов. Каждый вызов дешёвой модели логируется отдельной строкой — это тот же принцип, что и учёт SMS-верификаций: мелкие операционные расходы должны быть видимыми, а не растворяться в общих счетах за ИИ. Персональные данные и ИИ: что требует 152-ФЗ Без юридических формулировок: что именно вам нужно иметь, чтобы спать спокойно. Коротко и по делу — без юридического языка, но с указанием, где вам стоит привлечь юриста. В одной группе компаний юрист провёл проверку: все юрлица группы зарегистрированы как операторы персональных данных в РКН. Это база, без которой любая автоматизация с ПД незаконна с самого начала. Но регистрация — только первый шаг. Дальше вопрос трансграничной передачи: если данные обрабатываются на серверах за границей (а большинство ИИ-сервисов работают именно так), нужно согласие клиента конкретно на такую передачу, а не общее согласие на обработку персональных данных. Регулирование быстро меняется, и не только у нас. На одной из встреч прозвучала формулировка, которая многое объясняет: «В Европе есть законопроект о запрете работы с персональными данными через ИИ без спецразрешения надзорного органа. В Америке разглашение персональной информации с расовыми, этническими признаками — уголовная статья». Это касается любой компании, которая работает с иностранными клиентами или использует зарубежные ИИ-сервисы, а не только международных корпораций. Категория данных Можно в ИИ без ограничений Требует согласия / обезличивания Обезличенная статистика (число звонков, конверсия) да — Имя, телефон, адрес клиента нет да, согласие на обработку и трансграничную передачу Паспортные данные, финансовые реквизиты нет да, отдельное согласие + минимизация доступа Раса, этническая, религиозная принадлежность нет в ряде юрисдикций — уголовная ответственность за разглашение Роль Доступ к сырым ПД Доступ к ИИ-фильтру Менеджер клиентского отдела да, в рамках своих сделок нет, только через фильтр Разработчик интеграции нет да, к коду фильтра, не к данным Ответственный за комплаенс да, для аудита да, полный доступ к логам Что нельзя отправлять — практический список Ваш ориентир: если по данным можно узнать конкретного человека — они не идут в публичный чат ни в каком виде. Распечатайте его и повесьте рядом с командой. Это дешевле любого штрафа. Правило простое, но его постоянно нарушают: если данные можно связать с конкретным человеком, их нельзя копировать в публичный чат ИИ без обезличивания. На практике это значит: Паспортные данные, номера документов, адреса — только через защищённые внутренние системы, не через веб-интерфейс общедоступной нейросети. Финансовые реквизиты и суммы платежей клиентов — обезличивать перед анализом, оставлять только агрегаты. Данные о здоровье, расе, религии — не передавать вообще, даже обезличенными, если нет отдельного юридического основания. Переписки с клиентами целиком — прежде чем отдавать ИИ на анализ тональности, вычищать имена, телефоны, адреса. Отдельная история — таблицы с доступом «у кого есть ссылка». В одной компании собственница попросила провести аудит всех таблиц и удалить посторонние адреса из совместных документов. Оказалось, что множество таблиц с финансовой информацией и данными клиентов были открыты для всех, у кого есть ссылка, включая людей, которые уже не работают в компании. Это не проблема ИИ напрямую, но именно из таких таблиц данные чаще всего попадают в промпты — сотрудник копирует строку в чат с нейросетью, не задумываясь, что таблица вообще не должна была быть открытой. Таблицы с доступом «по ссылке» 2 случая Вебхуки без защиты 1 случай JS-файл в открытом доступе 1 случай Личная учётная запись вместо служебной 1 случай На диаграмме — распределение зафиксированных случаев по типам утечки в наших аудитах, не статистика по рынку. Доступы сотрудников: где ломается контроль Ваша машина — такой же пользователь, как человек, и учитывать её доступы нужно так же. Один из самых частых источников проблем — не злой умысел, а разгильдяйство с учётными записями. При создании обучающего курса разработчик использовал личную учётную запись для авторизации вместо служебной. Прошло время, понадобилось дать доступ нескольким новым сотрудникам — и выяснилось, что отследить прохождение курса невозможно, потому что вся система завязана на личный аккаунт одного человека. С доступами к CRM та же болезнь: подробнее я разбирал её в статье о том, почему менеджеры не вносят данные в CRM — привычка обходить систему через личные каналы одна и та же. С доступами к ИИ-инструментам логика та же, только риски выше. Если промпты и API-токены привязаны к личной учётке сотрудника, компания теряет контроль в момент его увольнения или конфликта. На практике так и делали при настройке одной из интеграций: чувствительные ссылки доступа хранятся только в коде, локальные файлы не пересылаются во внешние каналы, доступ ограничивается минимально необходимыми правами. Это не бюрократия ради бюрократии — единственный способ не зависеть от одного человека и одной учётной записи. Похожий принцип звучал в цитате с одной из встреч: «Именно поэтому мы работаем в коде. Потому что единственный способ поставить работу, если вдруг случится какая-то блокировка, — это работать в коде, чтобы все файлы были у тебя и ты не зависела от доступа к учётной записи». Применительно к ИИ это значит: не собирайте всю автоматизацию вокруг личного кабинета одного сотрудника в ChatGPT или другом сервисе. Правило «один человек — одна таблица» Ещё один принцип разграничения прав пригодится и в работе с ИИ: «один человек — одна таблица» — правило против конфликтов между автоматическим и ручным редактированием. Когда несколько сотрудников и бот одновременно правят один документ, данные путаются, а отследить, кто передал строку в промпт нейросети, становится невозможно. Где ломается Автоматизация с доступом к персональным данным требует того же надзора, что и любая другая автоматизация — только цена ошибки выше. Подробнее о том, почему автоматизация без контроля превращается во вторую работу, — в статье про автоматизацию, которая требует надзора . Экономика: что стоит фильтр и что он даёт Сравнивайте не с нулём, а с размером штрафа за утечку: с 2026 года эта арифметика стала однозначной. Настройка фильтра занимает 12–18 часов работы разработчика и юриста, эксплуатация — 350–1 150 ₽ в месяц, а экономия по сравнению с ручной проверкой того же потока документов — около 28 000 ₽ в месяц (оценка). Возьмём условную сервисную компанию из легенды: отдел продаж 8 менеджеров, оборот ~9 млн ₽ в месяц, средний чек ~180 000 ₽ — это около 50 закрытых сделок в месяц. При таком масштабе поток входящих обращений с персональными данными (заявки, переписки, документы) — порядка 40 штук в день на весь отдел. Это и есть базовый поток, на который дальше считается экономика. Внедрение: настройка Apps Script-фильтра с классификатором и подключением к таблице/вебхуку — 8–12 часов работы разработчика. Дополнительно нужен юрист на проверку договоров на согласия — 4–6 часов. Итого разовые затраты на запуск — 12–18 часов специалистов среднего уровня. Эксплуатация фильтра считается по формуле «цена одного обращения к модели × число документов в день × 30 = расходы в месяц». При потоке 40 документов в день это 1 200 обращений в месяц. Цена короткого запроса к недорогой модели-классификатору — ориентировочно на два порядка меньше стоимости одной SMS-верификации, точная цифра зависит от длины текста и провайдера; совокупно это укладывается в 350–1 150 ₽ в месяц. Теперь — сколько стоит делать ту же проверку руками, без фильтра. Если человек тратит на ручную проверку одного документа около 2 минут, то при потоке 40 документов в день это 80 минут, или 1,3 часа в день, а за 22 рабочих дня — около 29 часов в месяц. По ставке ~1 000 ₽/час менеджера это 29 000 ₽ в месяц — потери рабочего времени на рутину, которую при этом человек всё равно частично пропускает. Разница между ~29 000 ₽ ручной проверки и 350–1 150 ₽ автоматического фильтра — это и есть заявленные 25–80 раз. Разовые затраты на внедрение (12–18 часов специалистов) окупаются меньше чем за месяц эксплуатации. Показатель Ручная проверка Автоматический фильтр Поток документов 40 в день 40 в день Время / нагрузка на человека в месяц ~29 часов без участия человека, кроме разбора high-риска Стоимость в месяц ~29 000 ₽ 350–1 150 ₽ Разовые затраты на запуск — 12–18 часов специалистов Окупаемость запуска — меньше месяца Эффект фильтра ПД мы считаем по двум составляющим: снятый юридический риск нарушения 152-ФЗ (в рублях напрямую не выражается) и экономия времени на ручной проверке документов, посчитанная выше. Ускорение продаж, конверсию сделок и прочие метрики отдела фильтр не трогает — это не его эффект, и смешивать его с другими ИИ-инициативами компании не стоит: если параллельно внедряются боты и распознавание документов, их экономику считайте отдельно — я разбирал это в статье о том, сколько реально стоит ИИ в месяц . Отдельная статья экономики — ревизия доступов на компанию с несколькими юрлицами: вручную, по грубой оценке, это несколько десятков часов — по 4 часа на юрлицо, если искать все таблицы, вебхуки и токены без структуры. С чек-листом из этой статьи то же самое укладывается в 15–20 часов — время короче примерно вдвое. На диаграмме — сравнение времени на ревизию доступов при нескольких юрлицах: без чек-листа и с ним. без чек-листа с чек-листом Время на ревизию доступов при нескольких юрлицах: без чек-листа и с чек-листом, часы специалиста. Знать, куда уходят данные из вашего процесса, — такой же базовый навык руководителя, как читать отчёт о деньгах. Без него вы управляете не компанией, а её видимой частью: пока никто не спросил про JS-файл на публичном сервере или таблицу «по ссылке», кажется, что всё в порядке. Я этот навык добирал задним числом — по итогам аудита, где мне показали то, чего я про собственную архитектуру доступов не знал. Отдельной должности он не требует: достаточно раз в квартал уметь ответить, кто и через какой доступ подаёт данные в машину. С чего начать вам в понедельник Регламент на одну страницу — и объявить его открыто. Выгрузить список всех ИИ-сервисов, к которым подключены сотрудники, и проверить, через чьи учётные записи — личные или служебные. Проверить все Google Таблицы и документы с доступом «по ссылке» — сменить на «только для приглашённых», удалить посторонние адреса. Найти все вебхуки и API-токены в коде и конфигурациях — перенести из открытых файлов в переменные окружения. Проверить договоры с клиентами на формулировку о согласии на трансграничную передачу данных, если используются зарубежные ИИ-сервисы. Поставить между источником данных и моделью промежуточный фильтр-классификатор ПД — хотя бы в виде скрипта на 20–30 строк, даже без дорогой модели на входе. Убедиться, что все юрлица компании зарегистрированы как операторы персональных данных в РКН. Что сделать вам на этой неделе: напишите короткий регламент на одну страницу — что запрещено всегда, чем можно пользоваться, кто отвечает за результат. И объявите его открыто, а не рассылкой в никуда. Полный разбор правовой стороны и рабочие формулировки — в бесплатном курсе для руководителей . Ваш минимум на эту неделю: одна страница правил и открытое объявление команде. Всё остальное — фильтры, контуры, договоры об обработке — можно достроить потом, но без правил вся эта техника защищает вас только на бумаге. У нас правило обезличивания появилось после того, как я сам чуть не отправил в чат таблицу с контактами клиентов — остановился на полсекунды. С тех пор мы не полагаемся на внимательность: данные обезличиваются до отправки, автоматически. ## Речевая аналитика на практике: 7139 оценок, $300 в месяц — и один отзыв URL: https://davidgerstein.pro/blog/kontrol-kachestva-zvonkov-ii/ Дата: 2026-08-15 Направление: Контроль качества Цифры: 7139 оценок · $300/мес · 1 отзыв Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Сколько разговоров ваших менеджеров с клиентами вы слышали за последний месяц? Скорее всего, ноль. И это нормально: у директора есть занятия поважнее. Ненормально другое — что их не слышал вообще никто, включая руководителя отдела. Если вы прямо сейчас не можете назвать, сколько разговоров разобрали в вашем отделе на прошлой неделе и что после этого изменилось, — контроля качества у вас нет. Есть ощущение контроля. Разница между этими двумя состояниями стоит денег, и ниже я посчитаю, сколько именно. Несколько месяцев назад я поставил в отделе продаж конвейер, который слушает все сто процентов звонков и оценивает каждый по чек-листу. Это разбор работающей системы, а не обзор сервисов: реальные цифры, устройство, промт — и главный вывод, который дороже всей технической части. На седьмой тысяче оценок я понял, что построил дорогую бессмыслицу. Вот это, честно говоря, полезнее всего остального. Сколько стоит речевая аналитика на нейросети Оценка всего потока разговоров обходится около $300 в месяц : за период машина поставила 7 139 оценок там, где вручную закрывалось четверть звонков. Это дешевле одной ставки контролёра. Но цена — не главный вопрос. За тот же период руководители оставили один отзыв на все 7 139 оценок. Контур, чьи результаты не превращаются в решения, стоит ровно $300 в месяц и не приносит ничего. Цифры Конвейер оценивает 100% звонков отдела — 7139 за отчётный период, около 177 в день, — и стоит около $300 в месяц. Это дешевле одного дня работы штатного контролёра качества. Но за тот же период руководители оставили на оценки ровно один отзыв, и это число говорит о системе больше, чем все остальные. Показатель Значение Оценено разговоров за период 7139 Средний темп ~177 разговоров в день Себестоимость обработки ~$300 в месяц Охват 100% звонков, а не выборка Отзывов от руководителей на оценки 1 (один) за весь период Последняя строка — самая важная в этой таблице. К ней и придём. Как устроен конвейер Описываю подробно, чтобы вы могли прикинуть, что из этого есть у вас, а чего не хватает. Ничего экзотического в схеме нет — она собирается из того, что уже стоит в большинстве компаний. Схема воспроизводима в любой CRM с телефонией: запись → расшифровка → оценка по чек-листу → агрегация в дашборд. Три технических этапа и один управленческий, который в нашем случае так и не заработал. Каждый узел этой цепочки разобран отдельно — выгрузка, транскрибация, чек-листы, калибровка и экономика контроля . Записи звонков из телефонии складываются в хранилище. Первый этап — расшифровка: речь в текст, с разделением по говорящим. Второй — оценка: языковая модель получает расшифровку и чек-лист (приветствие, выявление потребности, работа с возражением, следующий шаг — у вас будет свой) и возвращает структурированную оценку с цитатами. Третий — агрегация: оценки складываются в базу, руководитель видит сводку по менеджерам и может провалиться в конкретный разговор. Что важно из неочевидного: Не экономьте на расшифровке. Ошибки распознавания речи умножаются на этапе оценки: модель уверенно оценивает то, чего человек не говорил. Дешёвая расшифровка — главный источник несправедливых оценок, а несправедливая оценка — самый быстрый способ настроить менеджеров против системы. Чек-лист должен быть короче, чем хочется. Пять-семь пунктов, по которым возможен однозначный ответ. Пункты вида «менеджер был доброжелателен» порождают споры, пункты «менеджер назвал следующий шаг и дату» — нет. Оценка обязана цитировать. Каждый балл — с цитатой из разговора. Без цитат разбор превращается в спор с роботом. Отдельный вопрос — хранение. Записи и расшифровки 7139 звонков в месяц — это не просто база для оценки, а полноценный архив разговоров с клиентами, к которому со временем накапливаются вопросы доступа: кто может слушать записи, сколько они хранятся, кто отвечает за их удаление по истечении срока. Мы решили это заранее — доступ к аудио есть только у руководителя отдела и у самого менеджера по его звонкам, доступ к текстовым оценкам — шире, у коммерческого директора. Если этот вопрос не закрыть на старте, он всплывёт в худший момент — когда записи понадобятся для разбора конфликтной ситуации с клиентом, а выяснится, что их уже удалили по умолчанию через 30 дней. Промт: как модель оценивает звонок Вся оценка держится на одном промте, который получает расшифровку и чек-лист и возвращает структурированный JSON с баллом, цитатой и флагом риска по каждому пункту — без этого промта дальнейшая агрегация не имеет смысла, и его можно скопировать целиком. В нашей связке источник данных — amoCRM. После завершения звонка прилетает вебхук примерно такого вида: Сервис скачивает запись, прогоняет через распознавание речи с разметкой по говорящим и подставляет расшифровку в промт ниже вместо плейсхолдера {transcript} . Пример ответа модели на реальный (обезличенный) звонок: risk_flag — единственное поле, ради которого весь промт и затевался: это фильтр, по которому руководитель может за минуту отсортировать 7139 звонков и открыть только проблемные, не слушая остальные. Что выводить на дашборд, чтобы им реально пользовались Здесь вы можете сэкономить себе месяц: дашборд, который никто не открывает, — самый частый результат таких проектов. Правило простое: если вашему руководителю отдела нужно больше двух кликов, чтобы понять, что делать сегодня, — вы построили витрину, а не инструмент. Дашборд должен отвечать на один вопрос за один взгляд: «кого разбирать на этой неделе» — а не превращаться в ещё один отчёт, который открывают раз в квартал перед советом директоров. Мы ошиблись именно здесь: изначально вывели общий средний балл по отделу и красивый график динамики, но ни то, ни другое не подсказывает, что делать в понедельник утром. Рабочий минимум — четыре виджета: количество звонков с risk_flag: true за неделю по каждому менеджеру; топ-3 худших звонка недели со ссылкой на аудио и цитатой из оценки; доля выполнения по каждому пункту чек-листа отдельно (не общий балл, а именно «выявление потребности — X%», «следующий шаг — Y%»), потому что общий балл смешивает разные проблемы в одно число и прячет, что именно чинить; и счётчик «дней с последнего разбора» — простая метрика-триггер, которая делает пропуск ритуала заметным, а не тихим. Именно последний счётчик, если бы он у нас стоял на видном месте с первого дня, вероятно, не позволил бы месяцу тишины остаться незамеченным. Инженерная обвязка: очередь, ретраи, деньги Настройка конвейера заняла около 20 часов: 8 часов — распознавание речи и хранение записей, 8 часов — промт и тестирование чек-листа на живых звонках, 4 часа — интеграция с amoCRM и вывод результатов в таблицу (оценка). ASR и хранение записей 8 ч Промт и тест чек-листа 8 ч Интеграция с amoCRM 4 ч Из невидимого снаружи, но важного для устойчивости: очередь на обработку звонков должна переживать пиковые часы без потерь, а на сбои ASR и модели нужны ретраи с ограничением попыток (у нас — три), иначе часть звонков молча выпадает из статистики и руководитель видит неполную картину, даже не подозревая об этом. Второй момент — лимиты запроса: модель вызывается на каждый звонок отдельно, и при росте штата стоимость растёт линейно, а не скачками, что как раз и держит счёт в районе $300 при нынешнем объёме. Третий момент, который мы недооценили на старте, — длинные звонки. Разговор на 40–50 минут не помещается в один запрос к модели целиком без потери качества оценки: расшифровку приходится резать на смысловые куски и оценивать чек-лист по всей склейке, а не по последнему фрагменту. Решение простое — отправлять модели полную расшифровку, но с явным указанием в промте оценивать разговор целиком, а не последнюю реплику; в этом и есть весь фокус, специальная логика разбиения не потребовалась. Экономика Сравнивайте не с нулём, а со своей текущей ситуацией: сколько у вас стоит человек, который слушает четверть потока, и во что обходится один сорванный контракт, который никто не услышал вовремя. Настройка обошлась примерно в 20 часов работы, эксплуатация — около 27 000 ₽ в месяц (доллары по текущему курсу), а фактический эффект в деньгах за всё время работы — 0 ₽, потому что оценки никто не разбирал с менеджерами. При 7139 оценённых звонках это около 3,8 ₽ за звонок — конвейер сам по себе дешёвый, вопрос не в нём. Возьмём отдел из 8 менеджеров при обороте 9 млн ₽ в месяц и среднем чеке 180 тыс. ₽ — это около 50 сделок в месяц. Если 10% зависает именно из-за плохо отработанного звонка (не назначен следующий шаг, проигнорировано возражение), это 5 сделок и риск ≈ 900 000 ₽ в месяц (оценка). Конвейер этот риск сам не снижает — он только помечает флагом, в каких из 7139 звонков риск есть. Снижает риск разбор: 30 минут в неделю с каждым из 8 менеджеров — это около 16 часов управленческого времени в месяц при ставке руководителя ~1500 ₽/час, то есть 24 000 ₽ в месяц. Это на порядок дешевле риска в 900 000 ₽, но требует ритуала, которого у нас не было. Что мы не считаем эффектом: раньше звонки слушали выборочно и время на это никто не фиксировал — «экономию» этой ручной практики в деньгах мы не пересчитываем, потому что это просто исчезнувшее действие, а не высвобожденные часы сотрудника. Если разбор всё же заработает и повлияет на конверсию, сдвиг даст связка ИИ-оценки и управленческого ритуала целиком — вклад одной только модели отдельно выделить будет нельзя. Почему это не окупилось — честная часть Главный вывод Речевая аналитика не окупается не потому, что нейросеть плохо оценивает. Она не окупается, потому что результаты никто не разбирает. Ритуал разбора — еженедельный, обязательный, с конкретными разговорами — проектируется до запуска системы, и у него должен быть владелец. Если владельца нет, не тратьте деньги на технологию. Система оценивает 177 разговоров в день. Раньше выборочно слушали единицы. Казалось бы — прорыв. Но за весь период работы руководители оставили на оценки один отзыв, а калибровка критериев (совместный разбор спорных оценок, поправки в чек-лист) оборвалась через месяц. Оценка звонка меняет что-то в одном-единственном случае: когда руководитель садится с менеджером и разбирает конкретный разговор. Этот ритуал не был спроектирован. Все считали, что достаточно дать доступ к экрану с оценками. Недостаточно: у руководителя есть текущая работа, и новый экран сам в неё не встраивается — про эту же ловушку я писал в разборе того, почему внедрение ИИ не приживается , там она общая для любых инструментов, не только для звонков. Отдельно стоит сказать про сопротивление менеджеров, которое почти всегда возникает на старте таких систем и которое мы недооценили. Первая реакция — не «удобно», а «меня теперь слушает робот». Это снимается только практикой: если оценки первое время используют исключительно для наказаний, саботаж гарантирован; если первые недели показывают, что оценка помогает получить конкретный совет («на этом месте стоило спросить про бюджет») — сопротивление проходит за 2–3 недели. У нас этой фазы толком не было, потому что не было и самих разборов — отсюда и один отзыв за весь период вместо постепенного привыкания. Считать ли это провалом Отвечу так, как ответил бы вам за столом: технически — нет, управленчески — да. И если вы будете строить у себя похожий контур, я бы хотел, чтобы вы вынесли отсюда именно эту часть, а не цифры про охват. Технически — нет: конвейер стабилен, дёшев и точен. Управленчески — да: он несколько месяцев производил оценки, которые никто не читал. Разрыв между «технология работает» и «люди работают по-другому» — это самая частая причина того, что цифры из отчёта не превращаются в деньги; о том, как вообще правильно считать эффект ИИ-проектов, чтобы не путать поток с разовым запасом, я подробно писал в отдельном разборе про окупаемость ИИ-проектов . И вот что я вынес для себя лично. Довести машинную оценку до разговора с живым человеком — это отдельный навык руководителя, такой же осваиваемый, как чтение отчёта о прибылях. Раньше он не требовался: данных о работе людей было мало, добывались они вручную и поштучно. Теперь данных больше, чем управленческого времени, и руководитель, который умеет превращать поток машинных оценок в еженедельные решения, стоит дороже руководителя, который умеет только раздавать задачи. Я этим навыком в тот момент не владел — и никакая настройка промта этого не компенсировала. Я публикую этот разбор именно потому, что таких историй в открытом доступе почти нет — все продают кейсы успеха, и у читателя складывается ощущение, что у всех работает, а у него одного нет. Не у всех. Чек-лист на понедельник, если хотите повторить Порядок для вас — с поправкой на мою ошибку: приёмку ставим первой, а не последней. Сначала договоритесь с руководителем отдела: полчаса в неделю на разбор трёх худших и одного лучшего разговора. Письменно, с датой первой встречи. Только потом стройте конвейер — иначе получите точную систему без единого пользователя. Первую неделю оценивайте вручную вместе с системой — это калибровка чек-листа и прививка доверия к оценкам. Показывайте менеджерам их собственные оценки сразу: система, которую от людей прячут, воспринимается как слежка и саботируется. Раз в месяц пересматривайте чек-лист: продажи меняются, критерии отстают. Назначьте владельца ритуала разбора — не «руководитель отдела в целом», а конкретный человек с этим пунктом в еженедельном плане. Поставьте на дашборд счётчик «дней с последнего разбора» — если он есть на видном месте, месяц тишины заметят раньше, чем через месяц. Стоимость всей затеи — сотни долларов в месяц, а не миллионы на проект. В деньгах это доступно любому среднему бизнесу; в дисциплине — не любому. Дисциплина и есть цена. Если после этой статьи вы сделаете одну вещь — пусть это будет не запуск контура, а простой вопрос руководителю отдела продаж: «сколько звонков ты послушал на прошлой неделе и что после этого изменилось?». Ответ покажет, нужна ли вам вообще автоматика или сначала нужна управленческая привычка. Потому что машина, как выяснилось на моём опыте, отлично производит оценки — и совершенно не умеет заставлять людей ими пользоваться. Это по-прежнему ваша работа. Как выстроить и то и другое — в бесплатном курсе для руководителей . ## Финансовый контроль бизнеса: где расходятся цифры CRM и кассы URL: https://davidgerstein.pro/blog/sverka-platezhej-crm/ Дата: 2026-08-15 Направление: Финансы Цифры: сдвиг дат 18–36 часов · дефицит кэша ~700 тыс. ₽/мес (оценка) · возврат сокращён примерно на пятую часть Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас каждый месяц повторяется одна и та же сцена — маркетолог показывает выручку из CRM, бухгалтер поступления по банку, цифры расходятся на десятки процентов, а вы сидите между ними и не понимаете, какой отчёт брать в работу, — финансовый контроль бизнеса у вас существует на бумаге, а не в работе. Обе стороны при этом правы. Они считают разные вещи, и пока вы не развели это явно, спор будет повторяться каждый месяц. Речь тут не про акт сверки взаиморасчётов с контрагентом — бланк документа ничего не чинит. Речь про то, сходится ли ваша выручка в CRM с деньгами, которые дошли до счёта. Сверка платежей и CRM обычно выглядит формальностью — пока не начинает всплывать необъяснимая разница в цифрах. Разработчик настроил бота на ежечасную выгрузку данных из CRM и сравнение с предыдущей версией. Через несколько часов после синхронизации сделки «переезжали» в другие дни — сдвиг от 18 до 36 часов. В моменте версия показывала правильные даты, потом цифры расходились сами собой. Никто это не трогал руками. Просто так работала синхронизация. Это частный случай общей проблемы. Сверка платежей в компаниях среднего размера почти никогда не заканчивается словами «всё сошлось». Обычно она заканчивается вопросом «а почему у нас расхождение в 300–500 тысяч рублей, и с какого месяца оно копится». Если сверку делает человек вручную — это полтора-два часа в день на поиск расхождений, письма с уточнениями, ожидание ответа от смежного отдела. При типичной часовой ставке такого сотрудника это выливается в кратные десятки часов в месяц, потраченные только на поиск расхождений, — притом что сверка всё равно опаздывает на месяц-два от момента, когда деньги реально разошлись. Я собрал несколько историй с рабочих встреч — все они об одном: CRM и бухгалтерия смотрят на одну и ту же сделку с разных точек, и точки эти системно не совпадают. Ниже — где конкретно расходится, как это чинить механикой, а не разговорами, и во что это обходится, если не чинить вообще. Почему в финансовом контроле бизнеса цифры CRM и банка не сходятся Три причины по убыванию частоты. Первая — разный момент признания дохода: коммерческий считает выручку по подписанному договору, бухгалтер по поступлению. Вторая — возвраты, которые не уменьшают выручку менеджера в отчёте. Третья — технические сбои интеграции, когда часть оплат просто не доезжает до CRM. Начинать надо не с таблиц, а с определений: договоритесь письменно, что считается выручкой и в какой момент. Половина расхождений исчезает на этой встрече. Это управленческая задача, а не бухгалтерская: бланк акта сверки взаиморасчётов её не закрывает. Решение принимает руководитель — какой момент в компании считается выручкой и кто отвечает за расхождение. Момент признания дохода — ваш главный источник расхождений Спросите своего коммерческого и своего бухгалтера по отдельности, когда сделка считается выручкой. Ответы будут разными — и вот вам первая причина расхождения. Классический разговор с одного из разборов: менеджер хочет получить бонус в момент подписания договора с клиентом, не дожидаясь платежа. Ему возражают — в компании такие расхождения отслеживает финансовый контролёр и напрямую докладывает о них собственнику. В итоге договорились считать по факту получения платежа. Свести две системы к одной методологии — это навык руководителя, а не задача бухгалтерии. Бухгалтер отвечает за корректность проводок; за то, что вся компания считает выручку одинаково, отвечаете вы сами. Я сам долго считал это технической мелочью, которую финансист с коммерческим разрулят между собой, — и получал один и тот же спор каждый месяц, пока не сел и не написал определение на одну страницу. Спор о цифрах вообще не выигрывается аргументами — он снимается тем, что вы договариваетесь об одном источнике правды на каждый показатель . Это не бюрократическая придирка. Если CRM признаёт доход в момент подписания, а касса — в момент поступления денег, зазор между «продано» и «оплачено» будет всегда. В отчёте для собственника этот зазор может выглядеть как воровство, хотя это просто разные точки отсчёта в двух системах, которые никто не свёл в одну методологию. Пример с криптовалютным возвратом Клиент внёс предоплату криптовалютой, компания получила сумму заметно больше исходной — курсовая разница на входе дала прирост около 10%. Позже клиент потребовал полный возврат в течение дня той же криптовалютой, ссылаясь на обещание менеджера. Руководитель решил вернуть клиенту сумму, удержав примерно пятую часть на расходы и бонус, чтобы избежать судебного разбирательства. С точки зрения сверки: в CRM по сделке проходит одна сумма, в кошельке — другая на входе и третья на выходе, а разница нигде не документируется как отдельная операция. Если не завести это явным полем «удержано за расходы и бонус», при следующей сверке кто-то откроет выписку, увидит недостачу и начнёт разбираться с нуля — без единой точки, где записана причина. Правило Каждый возврат клиенту — отдельная операция с отдельным обоснованием суммы, а не корректировка исходной сделки задним числом. Иначе через полгода никто не вспомнит, почему цифры разошлись, и разбор снова упрётся в «а кто это удержал и зачем». Возвраты как чёрная дыра вашего учёта Спросите себя: в вашем отчёте по продажам возврат уменьшает выручку менеджера? Если нет — ваши цифры завышены, и вы платите бонусы за деньги, которых нет. Проверьте, как возвраты отражаются у вас: в половине компаний они просто не попадают в отчёт по продажам, и выручка в презентации оказывается выше реальной. Отдельная история: реферальная программа, где партнёры задерживают информацию о вознаграждениях до момента, когда клиент сам запросит возврат денег. Пока никто не спрашивает — деньги как бы «не начислены». В момент запроса выясняется, что обязательство уже давно возникло, просто о нём не сообщили. Решение технически простое: автоматизация уведомлений в боте, которая мгновенно информирует партнёров о закрытии проекта реферала — настройка заняла около 20 минут работы. Но это чинит только один канал. По другому направлению звучит прямая цитата с разбора: «Возвраты абсолютно никак не фиксируются, никто никак не ведёт, никто не отвечает. Нужен инструмент, нужен регламент». Если возвраты — единственный процесс без владельца, они всегда будут точкой расхождения между тем, что видит продажник в CRM (сделка закрыта, деньги пришли), и тем, что видит бухгалтерия (часть денег уже ушла обратно). Технические сбои, похожие на финансовые дыры У нас был случай, когда мы неделю искали пропавшие платежи, а виновата оказалась интеграция: часть оплат просто не доезжала до CRM. Я тогда чуть не устроил разбор полётов на пустом месте. Прежде чем искать злой умысел, проверьте технику: у нас часть расхождений оказалась банальными сбоями интеграции. Отдельная категория проблем — не про людей, а про то, как работают сами системы. Платёж перенесли, но система не подхватила его автоматически — заявку нужно было заново запускать руками. Никто этого не сделал, платёж, согласованный на понедельник, завис, и рекламная кампания чуть не встала: на счёте не хватало денег. С точки зрения CRM сделка отмечена «оплата запланирована». С точки зрения кассы денег нет вообще, потому что заявка технически «зависла», и никто не заметил, что её нужно поднять заново. Это тот же тип бага, что и сдвиг дат — я разбирал похожий случай отдельно: CRM врёт, и что делать, если от неё зависят деньги . Разница между «система показывает» и «система сделала» — то место, где сверка обязана быть регулярной, а не разовой. В мае так же не вовремя выплатили финансирование части рекламных кампаний. Рекламные площадки работают на предоплате, поэтому задержка платежа привела не просто к паузе, а к тому, что кампании начали хуже отрабатывать после возобновления. В CRM это никак не отразилось — сделки как шли, так и идут. А в реальности конверсия просела из-за финансового сбоя, который бухгалтерия видела, а маркетинг — нет. Тип расхождения Что происходит на практике Что чинит Дата сделки сдвигается Синхронизация CRM меняет дату создания/закрытия задним числом на 18–36 часов Регулярная выгрузка и сравнение версий (бот раз в час) Момент признания дохода Бонус считается по дате договора, деньги приходят позже или не приходят вовсе Единая методология: начисление только по факту поступления Возврат не зафиксирован Клиенту вернули часть суммы, в CRM сделка осталась «оплачена полностью» Отдельная операция «возврат» с обоснованием суммы Платёж не переисполнился Заявка на перенесённый платёж требует ручного повторного запуска Автоматический повтор вместо ручной переинициализации Механика сверки: что → чем → куда Ваша схема будет такой же независимо от систем: берёте выручку из CRM за период, поступления из банка, сопоставляете по клиенту и дате, разбираете расхождения по причинам. Соберёте это за день. Дальше сверка займёт у вас минуты в неделю вместо разбирательств в конце месяца. Рабочая последовательность, которую можно повторить с любой командой из бухгалтера и разработчика: Что: выгрузка сделок и платежей за период. Чем: Bitrix24 REST API (метод crm.deal.list ) для CRM-стороны плюс банковская выписка или выгрузка из 1С для кассовой стороны. Куда: промежуточная таблица — Google Sheets на старте, база данных, когда объём вырастет. Что: сопоставление по сумме, контрагенту и периоду с допуском на курсовые и комиссионные расхождения. Чем: скрипт-обвязка плюс модель для нечётких случаев — частичные оплаты, разное написание контрагента, объединённые платежи. Куда: лист или таблица «Расхождения» с типом и суммой отклонения. Что: классификация каждого расхождения — дата съехала, доход не признан, возврат не зафиксирован, технический сбой платежа. Чем: тот же ИИ-модуль по фиксированным правилам. Куда: тикет в CRM или карточка задачи финансисту. Кто и когда смотрит: финансист — ежедневно, руководитель отдела — на еженедельном разборе. В одной из компаний время финансового планирования специально перенесли с утра на 13:00 четверга, чтобы к моменту разбора данные успевали собраться полностью, а не наполовину. Похожий принцип действует и для дебиторки: руководителю отдела поставили задачу ежедневно отслеживать три метрики — объём задолженности, распределение по срокам возникновения, распределение по пакетам услуг, — и держать их постоянно видимыми в отчётности, а не собирать раз в месяц перед совещанием. Логику разбора дебиторки без ручного контроля я раскладывал отдельно: дебиторка под контролем без памяти людей . ИИ-связка: сопоставление CRM и кассы Здесь машина делает за вас скучную часть: сопоставляет строки и приносит список расхождений с причинами. Вам остаётся решить, что с ними делать. Схема конвейера простая: почасовой или ежедневный вебхук из CRM → таблица с историей версий → сравнение текущей и предыдущей выгрузки → модель классифицирует найденные отклонения → уведомление финансисту при превышении порога. Для шага классификации не нужна дорогая модель — задача сводится к сопоставлению по чётким правилам, а не к творческой генерации. Дешёвая модель уровня GPT-4o-mini справляется с этим за секунды и обходится примерно в 200–400 ₽/мес при объёме в сотни строк в день (оценка). Дорогую модель имеет смысл подключать только там, где нужно разобрать неструктурированный комментарий менеджера о причине расхождения — это отдельный, более редкий шаг. Пример ответа модели на реальной структуре данных: Так выглядит итоговый отчёт, который финансист открывает по утрам вместо разбора сырых таблиц: Отчёт сверки — риски за сегодня 36 ч сдвиг даты, сделка 48213 180 000 ₽ платёж не найден, 48250 8 000 ₽ расхождение суммы, 48266 Сделка Тип риска Статус 48213 дата сдвинулась проверить 48250 платёж не найден просрочен 6 дн 48266 расхождение суммы в пределах порога Инженерная обвязка: скрипт крутится по расписанию — облачная функция или сервер компании, запуск раз в час, дёргает Bitrix24 REST API и выгрузку из банка/1С. История версий хранится в отдельной таблице, чтобы было с чем сравнивать текущую дату создания. При ошибке вебхука — таймаут или 5xx от Bitrix24 — три повторные попытки с интервалом 5 минут, после чего алерт в телеграм-канал финансиста. Отдельный алерт — если сумма найденного расхождения превышает заданный внутренний порог: такие случаи не должны ждать еженедельного разбора. На диаграмме ниже — движение одного резервного фонда за месяц из практики разбора: при обороте компании около 9 млн ₽/мес расхождение даже в 3–5% от согласуемых расходов — это 270 000–450 000 ₽ в месяц (оценка), которую никто не объяснит постфактум, если не сверять регулярно. Согласуемые расходы 100% Потрачено из резерва 44% Вернули в резерв 33% Остаток после авансов 26% В другом разборе — не связанном с этим фондом — точно так же всплыл необъяснённый рост фонда заработной платы без единого нового найма, в объёме около 300 000 ₽ — сопоставимо с месячным резервом на непредвиденные расходы (оценка на масштабе условной компании): к нему я вернусь ниже отдельно, чтобы не смешивать два разных кейса в одной сумме. Экономика: что стоит и что даёт Посчитайте своё: сколько часов в месяц ваши люди тратят на объяснение расхождений и сколько раз вы принимали решение по цифре, которая оказалась неверной. Настройка сверки — 12–22 часа разработчика на старте, эксплуатация — 200–400 ₽/мес на вызовы модели, эффект — высвобождение около 48 000 ₽/мес стоимости рабочего времени финансиста (оценка, расчёт ниже) плюс более раннее обнаружение кассовых разрывов на десятки-сотни тысяч рублей. Формула для прикидки своего случая: (часы в день на ручную сверку) × (часовая ставка сотрудника, который её делает) × (рабочих дней в месяце) = скрытые трудозатраты в месяц. Разовые часы на настройку × ставка разработчика — это стоимость внедрения. Разделите одно на другое — получите срок окупаемости в месяцах. Этап Оценка часов Комментарий Настройка выгрузки из CRM (вебхук/API) 4–8 ч зависит от того, есть ли уже интеграция Скрипт сопоставления + хранение истории версий 6–10 ч разово, дальше только доработки правил Промпт и тестирование классификации 2–4 ч основная работа — подбор пороговых значений Эксплуатация в месяц — вызовы дешёвой модели на объёме в сотни строк в день — около 200–400 ₽/мес Пример расчёта окупаемости: суммарно на настройку уходит 12–22 часа, возьмём верхнюю границу. При типичной ставке разработчика это разовое вложение, которое соотносится с ежемесячной экономией времени сотрудника (расчёт ниже) как примерно 1,5 к 1 — то есть окупаемость около полутора месяцев. Считаю эффект только от самой сверки, не смешивая с соседними инициативами вроде контроля дебиторки или прослушки звонков. Полная стоимость сотрудника, который вручную ищет расхождения, для компании обычно выше, чем его оклад: базовая ставка плюс налоги и отчисления (около половины ставки сверху) плюс сопутствующие затраты на рабочее место и инструменты — полная стоимость такого специалиста для компании обычно вдвое превышает оклад «на руки». Возьмём для примера финансиста с окладом 80 000 ₽ на руки — полная стоимость для компании тогда около 160 000 ₽/мес. Если автоматическая сверка освобождает порядка 30% его времени — это около 48 000 ₽/мес его стоимости для компании, которую можно перераспределить на работу с дебиторкой или клиентами вместо ручного поиска расхождений в таблицах. Это оценка, а не измеренный факт: часы финансиста не исчезают из штатного расписания, они переходят на другую работу — сам по себе этот сдвиг не equals прямому доходу компании. Второй эффект — не количество часов, а скорость обнаружения риска. В одном из разборов при типичных для компании такого масштаба месячных расходах и выручке компания обнаружила дефицит кэша около 700 000 ₽ — это около 8% месячного оборота — только по факту: когда денег не хватило даже на зарплаты. Регулярная сверка с ежедневным просмотром метрик не устраняет сам дефицит, но переносит момент его обнаружения на недели раньше, пока ещё есть время договориться о кредитной линии или перенести необязательный платёж — а не решать вопрос за полчаса, потому что подрядчику «нужно прямо сейчас». Что мы не считаем эффектом: ускорение получения денег по отдельной сделке (запас, а не поток) и высвобожденные часы финансиста сами по себе — они становятся деньгами только если реально сокращают штат или заменяют наём, а не просто перераспределяются на другие задачи. На диаграмме — разрыв между плановым лимитом и фактической потребностью из истории с проектной услугой: лимит факт. потребность Лимит фонда на финансирование этапа работ был установлен на уровне, который оказался на порядок меньше нужного, а реальная потребность на пике оказалась почти в девять раз выше плана. Разрыв не виден ни в CRM, ни в плановом бюджете, если не сверять фактический расход с фактическим объёмом работ помесячно. Где ломается Сверка превращается в формальность, если её делают «когда попросят», а не по расписанию. К моменту, когда расхождение замечают, оно уже успевает накопиться за несколько месяцев — и разбираться приходится не с одной цифрой, а с цепочкой из десятка мелких. Автоматическая часть тоже не панацея: если менеджеры вообще не приучены аккуратно вести CRM — пропускают статусы, дублируют сделки, — любое сопоставление упрётся в мусор на входе раньше, чем дойдёт до анализа сумм. Что делать вам, если расхождения уже накопились Не пытайтесь разобрать всю историю: закройте период, договоритесь о правилах и ведите сверку с этого дня. Раскопки прошлого съедят месяц и ничего не дадут. Я и сам дважды уходил в такие раскопки — и оба раза бросал их на середине, потому что данные за прошлые периоды уже не восстановить, а время ушло. Если вы сейчас стоите перед этим выбором: полугодовая история расхождений стоит ровно столько, сколько стоит правило, которое вы из неё выведете, — а правило можно написать за час. В одном из разборов собственник потребовал к утру следующего дня детализацию всех статей расходов по двум месяцам с объяснением причин изменений — не совместный анализ, а готовую расшифровку. Повод — непонятный и резкий рост фонда заработной платы при том, что новых сотрудников не нанимали. Расхождение такого масштаба обычно означает, что сверка не велась вообще, а не что кто-то один раз ошибся. Рабочий алгоритм для похожих ситуаций тот же, что использовали при пересчёте лимита на проектную услугу, только применённый к прошлым периодам: выгрузить закрытые документы за базовый период с расчётом себестоимости, выгрузить сделки текущего периода, сравнить помесячный прирост количества и стоимости по направлениям, выявить аномалии по типам операций. Вместо аргумента «нам не хватает, давайте увеличим» — пересчёт в привязке к фактическому росту объёма и выручки. Прежде чем строить автоматическую сверку, стоит навести порядок с дисциплиной ввода данных в CRM — иначе автоматика упрётся в тот же мусор, о котором шла речь выше. Я разбирал это отдельно в статье менеджеры не вносят данные в CRM: что делать без репрессий , а уже потом можно накладывать сверку поверх. Чек-лист: с чего начать в понедельник Выгрузить сделки за последний месяц из CRM и платежи из банка или кассы в одну таблицу — вручную, без автоматизации, просто чтобы увидеть масштаб расхождения. Договориться об одной методологии признания дохода на всю компанию: по факту поступления денег, а не по дате договора. Завести отдельный регистр возвратов с полями «удержано», «возвращено», «причина» — и назначить, кто его ведёт. Настроить регулярную, хотя бы ежедневную, выгрузку данных из CRM с сохранением истории версий, чтобы ловить сдвиги дат до того, как они превратятся в расхождение по сумме. Назначить фиксированное время и владельца еженедельной сверки — не «когда попросят», а по календарю. Проверить, что перенесённые или отложенные платежи не «зависают» технически и не требуют забытого вручную повторного запуска. Начните с определений, а не с таблиц: договоритесь с финансистом и коммерческим, что считается выручкой и в какой момент. Половина расхождений исчезнет прямо на этой встрече, без всякой автоматизации. Как автоматизировать сопоставление и получать расхождения списком, а не искать их руками, — в бесплатном курсе . Проверьте себя на этой неделе одним действием: возьмите любой прошедший месяц и сведите выручку из CRM с поступлениями по банку. Расхождение больше пяти процентов — у вас есть задача, и она важнее любой новой аналитики. ## Стратегическое планирование: рабочий инструмент, а не презентация для полки URL: https://davidgerstein.pro/blog/strategiya-rabochiy-instrument/ Дата: 2026-08-14 Направление: Стратегия Цифры: план разошёлся с фактом более чем в 2 раза Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы за последний месяц ни разу не открывали файл со стратегией — у вас не стратегия, а протокол о намерениях, и работаете вы по ситуации. Я говорю это не в упрёк: так живёт большинство компаний вашего размера, и до первого честного разбора это никому не мешает. Я к этому пришёл не сразу: у нас была красивая стратегия на три года, и она устарела за квартал. Не потому что рынок поменялся — потому что в ней не было механизма пересчёта. Отдел показал результат на 40% выше плана. Руководитель ждал похвалы. Собственник её не дал — потому что сам план был написан неправильно: в одной из компаний стратегия закладывала определённый годовой уровень выручки, а в текущий рабочий план была внесена цифра почти в 2,5 раза меньше. Превышение на 40% от заниженного плана не доказывает ничего и не даёт оснований ни для премии, ни для управленческого решения — это типичный сбой стратегического планирования в среднем бизнесе, когда план и факт живут разной жизнью. Это не единичный случай, а системная проблема: план устаревает быстрее, чем его успевают выполнить, а расхождения между цифрами по выручке и по факту поступления денег вскрываются на разборе постфактум, а не на этапе составления плана. Дальше — как эту проблему разбирали на реальных встречах: через декомпозицию целей, финансовую модель и еженедельный план-факт, а не через презентацию раз в год. Что такое стратегическое планирование в компании Стратегическое планирование в частной компании — это не пакет документов для отчёта наверх и не глава из учебника по менеджменту. Это три связанных элемента: декомпозиция цели от пятилетнего горизонта до задачи на неделю, финансовая модель на юнит-экономике каждого направления и еженедельная сверка плана с фактом по фиксированной структуре. Признак, что оно работает у вас: план пересчитывается за час после закрытия месяца. В разобранном кейсе такого механизма не было — исходная стратегия и рабочий план весь год расходились почти в 2,5 раза, и обе цифры при этом назывались стратегией. Почему ваше стратегическое планирование устаревает за три месяца Три причины, и все три — про устройство документа, а не про рынок. Что именно пошло не так в примере из начала: исходный план не учитывал ни изменение спроса, ни геополитику, ни новостную повестку, а заметно меньший рабочий план, с которым реально сверялись весь год, никто не привёл в соответствие с исходной стратегией. Отдел перевыполнил именно эту заниженную цифру — и оказался в неловком положении не по своей вине. Проблема не в том, что менеджеры плохо считали. Проблема в формате: фиксированные цифры на 12 месяцев вперёд в среднем бизнесе живут максимум квартал. Дальше их либо переписывают заново, либо продолжают сверяться с числами, которые уже никак не отражают реальность. Здесь стоит остановиться. Если вы узнали свою компанию — виноватых в отделе искать не надо, их там нет. Я сам делал ровно так же: считал, что стратегия — это хорошо продуманные цифры, которые достаточно один раз написать, а дальше просто идти по ним. Та самая красивая стратегия на три года — моя ошибка, а не тех, кто её считал. Я не заложил в неё пересчёт, а потом сам же переписывал её вручную и раздражался на людей, будто это они сломали документ. Решение, которое обсуждалось на встречах: перейти от фиксированных цифр к формулам. Если темп роста составляет +5% в месяц, план пересчитывается автоматически при загрузке фактических данных за период — а не переписывается вручную каждые три недели. Стратегия превращается из документа в живой расчёт, который обновляется вместе с фактом. Правило Если план невозможно пересчитать за час после закрытия месяца — это не рабочий инструмент, а презентация. Рабочий план обновляется быстрее, чем меняется рынок вокруг него. От пятилетней цели до задачи на неделю Проверьте, где у вас обрывается эта цепочка. Обычно она держится до квартала, а дальше превращается в «работайте лучше». В одной из компаний собственник выдал каждому руководителю макростратегию на 5 лет с ожидаемыми показателями. Дальше каждый руководитель обязан был написать свою мини-стратегию: как достичь этих цифр понедельно или подневно, с помощью ИИ как инструмента расчёта, а не как источника решений. Отдельное требование — для новых руководителей: трёхмесячная стратегия развития. Порядок такой: сначала согласовать критерии успеха с вышестоящим руководством — до старта, а не по итогам периода; разбить план по неделям и дням; зафиксировать показатели письменно, чтобы не было претензий задним числом. Логика простая: если критерии успеха не согласованы заранее, любой результат можно объявить провалом или удачей — в зависимости от настроения. Декомпозиция целей закрывает этот разрыв: пятилетняя цель превращается в годовую, годовая — в квартальную, квартальная — в недельную задачу конкретного человека. Отдельно вставал вопрос детализации по рынкам. Собственник прямо отклонил агрегированные цифры: «Я не говорю, за счёт чего. Я не говорю, пиши тексты или не тексты. Конечно, я хочу понимать, за счёт чего он даст больше лидов. За счёт SEO или за счёт SMM?» Стратегия без механики роста — это просто число, которое кто-то придумал. Требование — показать долю каждого канала по каждому рынку отдельно, с прогрессом по годам. Пример структуры презентации стратегии Первая версия презентации стратегии маркетинга провалилась: годовые цифры по выручке не совпадали с месячным бюджетом, не было временных маркеров, порядок подачи был хаотичным. Собственник потребовал переделать по жёсткой схеме: сначала общая картина за год, потом детализация по источникам, потом разбивка по годам с фиксацией прогресса. Уровень стратегии Горизонт Кто отвечает Макростратегия 5 лет Собственник Мини-стратегия руководителя Год / квартал Руководитель направления Оперативный план Неделя / день Исполнитель по каналу Пример прогресса, который требовал собственник: доля лидов из SEO выросла с 5% в 2025 году до 35% в 2026-м. На диаграмме — это конкретная механика роста, а не абстрактный процент к выручке. 5% в 2025 35% в 2026 Доля лидов из SEO в общем объёме лидов компании: было 5% в 2025 году, стало 35% в 2026-м — именно эту механику роста требовал показать собственник вместо общего процента к выручке. Финмодель: юнит-экономика вместо общей выручки Мы долго планировали общей выручкой и не видели, что одно направление тянет остальные вниз. Разделили — и решение о его закрытии стало очевидным за один вечер. Я до сих пор помню это ощущение: по компании в целом цифра нормальная, поэтому вопросов никто и не задаёт. Общая выручка отлично прячет убыточное направление — ровно до того момента, когда денег на счету перестаёт хватать. На этом месте среднему бизнесу постоянно ломает планирование: выручку путают с деньгами, которые реально дошли до счёта. В компании из примера выше стратегия закладывала определённый уровень годовой выручки, а в текущем плане стояла цифра почти в 2,5 раза меньше. Разница вызвала прямой вопрос: это сумма договоров или авансовые платежи, которые составляют 37–40% от итоговой выручки? Пока это не разведено явно, обе цифры выглядят «стратегией», но говорят о разных вещах. Если прикинуть от обратного: при доле аванса 37–40% от суммы договоров цифра в текущем плане может соответствовать сумме договоров, близкой к исходной цифре из стратегии (оценка, среднее значение диапазона). То есть разрыв в 2,5 раза может быть не про провал плана, а про то, что сравнивали разные по природе величины: аванс с суммой договоров. Это не отменяет проблему — наоборот, показывает, почему развести две метрики нужно ещё на этапе составления плана, а не на разборе постфактум, когда уже поздно разбираться, кто прав. Отдельная цитата с одной из встреч закрывает вопрос, насколько глубоко должен понимать цифры руководитель направления: «Ты должна знать юнит-экономику каждого направления как свои пять пальцев. Сколько зарабатываем, какая маржа, какие точки бизнеса. Это база, база, база. Любой финансовый директор знает всю эту юнит-экономику. Все.» Без этого стратегия — красивое число сверху, под которым нет расчёта. Похожая история с точкой безубыточности: компания знала точную цифру — из общей планки в 2 000 000 ₽ в месяц было собрано 63%, около 1 260 000 ₽, и оставалось собрать ещё 740 000 ₽ до порога. На момент встречи по другому проекту той же группы была собрана похожая сумма — около 700 000 ₽, это близко к недостающим 740 000 ₽ по первому проекту. На диаграмме — прогресс сбора к точке безубыточности по первому проекту. Такая конкретика возможна только тогда, когда финансовая модель строится не на среднегодовой выручке, а на разложенных по направлениям юнитах. Собрано к точке безубыточности 63% Обратная ситуация — компания без резервов: два источника дохода выпали, один на два месяца, другой на дольше, объём обращений упал до нескольких десятков в месяц, денег не хватает ни на рост продаж, ни на удержание прежнего уровня. Прямая цитата с той встречи: «У нас нет денег на то, чтобы вложиться в увеличение продаж». Финансовая модель в этом случае — не бумага для инвестора, а единственный способ понять, сколько времени осталось до кассового разрыва. План-факт еженедельно, а не по итогам квартала Ваша скорость реакции определяется этим ритмом: при квартальном разборе вы узнаёте о провале, когда исправлять поздно. Стратегия, которую не с чем сверять раз в неделю, превращается в презентацию для полки. Рабочий формат, который обсуждался: коммерческий отчёт по блокам — маркетинг, продажи, авансы — с фиксированным днём встречи, каждый четверг. Данные накапливаются за неделю и сводятся в одну таблицу. Это позволяет быстро отличить, где проблема системная (просадка по всей воронке), а где локальная (не хватает конкретного менеджера). Тот же принцип фиксированной сверки применим и к дебиторской задолженности — подробнее в статье о том, как контролировать дебиторку без памяти людей . Похожий принцип — трёхуровневый контроль по клиентам: таблица каждого клиента со сроками и статусом (зелёный/жёлтый/красный), сводная таблица по стадиям с суммами, и отдельный список «красных» клиентов для приоритетной работы. Это тот же план-факт, только применённый не к выручке компании, а к движению каждой сделки. Ещё один случай показывает, зачем план-факт нужен на уровне отдельного канала. Руководитель обнаружил, что SEO-специалист не может назвать конкретные источники лидов из органического поиска — аналитика просто не была настроена на связь между запросами, страницами и продажами. После этого отчётность перестроили так, чтобы каждый исполнитель стратегии понимал, за какой конкретный результат он отвечает. Похожая проблема с достоверностью данных для сверки разобрана в статье о том, почему CRM врёт с датами — принцип тот же: без сверки по факту любой отчёт можно подогнать под желаемую картину. Где ломается План-факт анализ бесполезен, если аналитика не настроена на источник данных. Сначала чинят измерение, потом строят отчёт — а не наоборот. ИИ-связка: пересчёт плана по формуле Цена вопроса и что именно автоматизируется — в разборе автоматизации стратегического планирования . Ваша цель — чтобы пересчёт занимал минуты. Тогда вы будете делать его при каждом изменении, а не раз в квартал под давлением обстоятельств. Механика, которую обсуждали для замены ручного пересчёта: план хранится не как набор фиксированных чисел, а как формула роста (например, +5% в месяц к базовому значению), и при загрузке факта за период модель пересчитывает оставшиеся месяцы и объясняет отклонения словами, а не только цифрами. Конвейер выглядит так: Google Sheets с фактическими данными за месяц (план, факт, канал, направление) → Apps Script по расписанию (каждый понедельник утром) → вызов модели с промптом ниже → ответ записывается в отдельный лист «Пересчитанный план» → руководитель смотрит на четверговой встрече вместе с общим коммерческим отчётом. Модель на этом шаге — дешёвая (класса GPT-4o-mini или аналог): задача — арифметика по заданной формуле и структурирование текста-объяснения, а не творческая генерация прогноза. Дорогую модель здесь подключать не за что: она не даст более точный расчёт, а стоить будет в разы больше. Пример ответа модели на такие входные данные: Так выглядит лист «Пересчитанный план», который руководитель открывает на четверговой встрече: Пересчитанный план — SEO 100% план на июнь (база) 94,1% факт на июнь, % от плана -5,9% отклонение факта от плана Месяц Пересчитанный план (к факту июня) Статус Июль ×1,05 норма Август ×1,10 норма Инженерная обвязка простая и без лишних сервисов: Google Sheets как источник и хранилище, Apps Script как триггер и вызов API модели, отдельный лист как журнал ошибок. Если вызов API падает — скрипт пишет статус в ячейку и присылает сообщение в рабочий Telegram-чат, чтобы пересчёт не потерялся молча. Перезапуск — вручную кнопкой в меню таблицы или повторным запуском по расписанию на следующий день. Где ломается ИИ в стратегии Команда создала ИИ-модель для стратегического планирования по региональному филиалу. При проверке выяснилось: инструмент генерировал убедительно звучащие прогнозы, которые на деле содержали непроверенные допущения — не учитывались премии сотрудников, целевые показатели ничем не обосновывались. Цитата с той встречи: «Стратегия выглядит убедительно, но содержит объективно бредовые вещи — например, не учтены бонусы продаж, а прогноз объёма на будущий год выглядит необоснованным». Команда вернулась к ручному пошаговому пересчёту для верификации и только потом стала поэтапно внедрять автоматизацию заново. ИИ хорош как калькулятор для декомпозиции: разбить годовую цель на недели, посчитать формулу роста, свести таблицу. Он плохо годится как источник допущений — сколько стоит премия, насколько реалистичен рост рынка. Эти цифры всё равно берёт на себя человек, который отвечает за результат. Подробнее о типовых причинах таких провалов — в разборе почему внедрение ИИ не работает . Экономика: цена ручного пересчёта Посчитайте свою: сколько часов уходит у вашей команды на пересборку плана и сколько раз за год вы её делаете. Возьмём типовой пример, чтобы посчитать эффект честно, без абсолютных внутренних цифр компании. Сведение еженедельного коммерческого отчёта вручную (три блока: маркетинг, продажи, авансы) занимает у аналитика или РОПа около 4 часов в неделю на сбор данных из разных источников — это оценка, основанная на объёме разбираемых на встречах таблиц. В пересчёте на месяц это около двух полных рабочих дней, уходящих только на ручной свод одной таблицы, без учёта времени руководителя на её разбор. Полуавтоматический свод через Google Sheets и скрипт из промпта выше сокращает время сбора примерно вдвое (оценка) — то есть высвобождает около одного рабочего дня в месяц на одном отчёте. Это вклад именно автоматизации свода данных; ускорение реакции на просадку конверсии — отдельный эффект, который зависит уже от управленческих решений на встрече, а не от самого скрипта, и его отдельно не суммируем. Окупаемость самой настройки: разработка скрипта и промпта (Apps Script + вызов модели + лист ошибок) занимает у разработчика около 8 часов (оценка) — это меньше одного рабочего дня. При высвобождаемом за счёт автоматизации времени такая настройка окупается по трудозатратам примерно за полтора месяца (оценка), дальше эффект работает без дополнительных затрат, кроме стоимости самих вызовов модели — доли цента за запуск при коротком JSON и дешёвой модели. Второй пример — риск от отсутствия план-факта на уровне отдельных клиентов, а не только сводного отчёта. Формула для своего случая выглядит так: число менеджеров × среднее число активных сделок на менеджера × средний чек направления × доля сделок, зависающих незамеченными без контроля (оценочно 5–15%, зависит от длины и текучести воронки) = риск в деньгах в месяц. Возьмём условный отдел оптовой торговли из 10 менеджеров при обороте отдела около 6 млн ₽ в месяц и среднем чеке направления 300 000 ₽: при нагрузке около 4 активных сделок на менеджера в месяц (оценка) в работе одновременно находится около 40 сделок. Если без трёхуровневого контроля (зелёный/жёлтый/красный) зависает незамеченными хотя бы 10% сделок — это 4 сделки на сумму около 1,2 млн ₽ в месяц (оценка риска, не факт потерь — часть сделок в итоге закрывается позже), то есть примерно пятая часть месячного оборота отдела. Внедрение сводной таблицы по стадиям и списка «красных» клиентов не устраняет риск полностью, но переводит его из невидимого в отслеживаемый — дальше решение принимает руководитель, а не таблица. Статья Оценка затрат Оценка эффекта Ручной свод еженедельного отчёта ~4 ч/нед (около 2 рабочих дней в месяц) — Свод через Google Sheets + скрипт (разово + окупаемость) ~8 ч разово (меньше 1 рабочего дня) экономия ~1 рабочий день/мес, окупаемость ~1,5 мес Отсутствие трёхуровневого контроля клиентов — риск ~1,2 млн ₽/мес (около 20% оборота отдела) из-за незамеченных зависших сделок (оценка) Стоимость самого пересчёта через модель по промпту выше — на уровне долей цента за вызов при дешёвой модели и коротком JSON на входе, это несопоставимо ни с ручным трудом аналитика, ни с риском по зависшим сделкам. Основные деньги в этой механике не в стоимости ИИ, а в том, смотрит ли кто-то на пересчитанный план каждую неделю. Что из этого сработало у нас Из всего списка вам стоит начать с одного элемента — того, который дал нам больше половины эффекта при минимуме усилий. Стратегическое планирование в среднем бизнесе перестаёт быть презентацией, когда выполняются три условия одновременно: план разложен на уровни с конкретным ответственным на каждом, финансовая модель построена на юнит-экономике, а не на общей выручке, и есть еженедельный ритуал сверки плана с фактом. Если хотя бы одного из трёх нет, стратегия превращается в документ, который красиво выглядит на встрече и ничего не решает через месяц. И главное, ради чего это всё. Умение держать план как формулу, а не как одно записанное число — отдельный управленческий навык, такой же базовый, как умение читать отчёт о прибылях и убытках. Руководитель, который за час пересобирает свою часть плана под новую вводную, стоит дороже руководителя, который раз в квартал приносит красивую презентацию. Я считаю это водоразделом — и советую честно проверить, есть ли такой человек у вас в компании. Ответственность за результат нужно закладывать на уровне конкретного человека, а не отдела целиком. Правило с одной из встреч звучало так: один сотрудник официально отвечает за конкретный результат, остальные помогают без претензии на равную долю признания. Это работает и на уровне бонусов за выигранное дело, и на уровне стратегии в целом — если непонятно, кто отвечает за цифру, спрашивать не с кого. С чего начать в понедельник Выписать текущую стратегию компании построчно и отметить, какие цифры — это формулы (пересчитываются от факта), а какие — фиксированные числа, вписанные один раз в начале периода. Для каждого направления явно развести выручку по договорам и фактические авансовые платежи — не оставлять эту разницу «подразумеваемой». Назначить фиксированный день недели для план-факт встречи (например, четверг) и завести одну таблицу с тремя блоками: маркетинг, продажи, авансы. Ввести для клиентской воронки трёхуровневый статус (зелёный/жёлтый/красный) и отдельный список «красных» клиентов, который проверяется на той же встрече. Проверить у каждого руководителя направления, может ли он назвать маржу и точки убытка своего направления без подготовки — если нет, юнит-экономику считать заново. Если стратегию считает ИИ — прогнать хотя бы один расчёт вручную параллельно и сверить, не пропущены ли премии, бонусы и разовые расходы. Проверьте свою стратегию одним вопросом: можете ли вы за час пересчитать её при изменении одной вводной — ушёл ключевой клиент, выросла ставка, подорожал закуп? Если нет, у вас документ, а не инструмент. Как собрать стратегию, которая пересчитывается, и связать её с недельными задачами команды, — механика в бесплатном курсе для руководителей . Из моего опыта: стратегия начинает работать в тот момент, когда её пересчёт становится дешевле, чем спор о ней. У нас это заняло два месяца и одну переделку модели — зато теперь любое «а что если» закрывается за час, а не за неделю совещаний. ## Клиентский портал для бизнеса: когда нужен, а когда только кажется URL: https://davidgerstein.pro/blog/klientskiy-portal-zachem/ Дата: 2026-08-12 Направление: Производственный цикл Цифры: несколько десятков кейсов на пилот · 3000→80 мс отклик формы · ~88 ч/мес экономии (оценка) Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы уже обсуждаете с подрядчиком макеты личного кабинета, а на вопрос «где физически лежат документы клиентов» в вашей компании нет одного короткого ответа — вы покупаете не портал, а витрину над бардаком. Узнаете об этом через полгода, когда переделка будет стоить дороже, чем стройка с нуля. Клиентский портал — из тех вещей, которые все хотят и мало кому нужны. Разберу честно: когда он окупается, а когда становится дорогой игрушкой. Мы сейчас строим такой портал у себя — самообслуживание с нейросетью для анализа документов клиентов. Логика понятная: клиент сам загружает бумаги, система их проверяет, статус обновляется без звонка менеджеру. Я настоял на том, чтобы не запускать продукт целиком: сначала прогнать несколько десятков живых кейсов через алгоритм и отдать на проверку менеджерам. Только если результат подтвердится — тест на 20% клиентской базы. MVP запланирован к концу года, но уже сейчас понятно: месяцы уйдут не на код, а на то, чтобы данные вообще стали пригодны для обучения модели. Так происходит почти в любом подобном проекте: все хотят красивый личный кабинет, а упираются в то, что данные под ним не готовы. Менеджер тратит 5–10 минут на каждый ответ «на каком я этапе», при 30 активных клиентах на менеджера это набегает в часы каждую неделю. Расскажу, где портал реально экономит эти часы, а где он просто дублирует бардак, только с красивым интерфейсом. Нужен ли вам клиентский портал: проверка по 4 признакам Если на вопрос «где физически лежат документы клиентов» у вас нет одного короткого ответа — клиентский портал вам пока не нужен, каким бы хорошим ни был макет. Портал — это витрина поверх CRM: клиент сам видит статус заказа, документы и историю обращений, не звоня менеджеру, но данные берутся оттуда, где они уже лежат. Четыре признака, что портал пока не нужен: документы клиентов лежат больше чем в одном месте; однотипные вопросы отнимают у менеджеров меньше рабочего дня в неделю; статус клиента нельзя показать без пояснения менеджера; после запуска портал некому вести. Ни один признак не совпал — считайте экономику: в разобранном примере кабинет со статусами снимал с отдела из 15 менеджеров около 88 часов в месяц (оценка). Что такое клиентский портал и когда он нужен Клиентский портал — это раздел, где ваш клиент сам видит статус своего заказа, документы и историю обращений, не звоня менеджеру. Технически это витрина поверх вашей CRM: данные те же, доступ другой. Нужен он не тогда, когда «у конкурентов есть», а когда к вам не относится ни один из четырёх признаков: документы клиентов лежат больше чем в одном месте; однотипные вопросы съедают у ваших людей меньше рабочего дня в неделю; статус клиента нельзя показать без пояснения менеджера; после запуска портал некому вести. Совпал хотя бы один — вы строите красивый фасад, которым никто не пользуется. Ниже разбираю каждый признак по отдельности. Что показывать клиенту в кабинете Правило простое: показывайте то, ради чего вам звонят. Всё остальное можно не делать. Личный кабинет решает одну конкретную задачу — снимает с менеджера повторяющиеся вопросы. «На каком я этапе», «что ещё нужно прислать», «когда будет готово». Если поток клиентов идёт волнами, а вопросы предсказуемы, портал со статусами окупается быстро. Если вопросы каждый раз уникальные — портал не поможет, там нужен живой человек. В одной компании не стали ждать портал и завели двухуровневую систему статусов прямо в CRM. Каждую среду вечером система фиксирует актуальный статус клиента в отдельный столбец. Новые столбцы добавляются слева от старых — руководитель видит последние изменения сразу, без прокрутки. Если статус не поменялся — ставится прочерк, а не повторяется старое значение. Это не портал в классическом смысле, но принцип тот же: понятный, регулярно обновляемый статус вместо «спросите у менеджера». Для клиента полезная версия портала — не витрина с анимацией, а простой список: что загружено, что проверено, что ждём. Отдельная сложность — статусы, которые критичны, но неудобны для прямого показа. Пример: система долго не фиксировала случаи, когда клиент не прошёл внешнюю проверку. Менеджер вручную откатывал сделку назад и должен был удалить дату проверки — но часто забывал. В CRM месяцами висела дата «пройдено» у клиента, который проверку не прошёл. Решение мы собрали из четырёх частей: отдельное поле для даты неуспешной проверки — не путать с датой плановой проверки; обязательное поле с причиной отказа: фиксированный список вариантов, а не свободный текст; автоматическая задача менеджеру на день проверки с бинарным выбором «пройдена / не пройдена»; уведомление контролю качества, если сделка не перемещена в срок. Для клиентского портала вывод простой: статус «отказ» нельзя показывать как есть — нужна причина и понятный следующий шаг. Иначе клиент видит слово «отказано» и звонит в панике, а у менеджера нет готового ответа, потому что причину никто не зафиксировал в структурированном виде. Портал без порядка в CRM — красивый фасад Если у вас в CRM бардак, портал покажет клиенту ваш бардак — только быстрее и круглосуточно. Здесь вылезает главная проблема. В одной компании документы клиентов загружались в портал, там же формировались рекомендации — но данные не попадали в CRM автоматически. Получилась параллельная система: клиент видит один статус в портале, менеджер работает с другим в CRM. Пришлось вручную выгружать массив портала и сопоставлять с данными о клиентах, прошедших проверку с первого раза, чтобы вообще накопить материал для обучения модели. Похожая история с документами: менеджеры отмечали документы клиента как «в наличии», но не загружали сами файлы на сервер. Система при обучении начинала считать, что клиент может пройти проверку без документов — потому что видела только галочку, а не файл. Пришлось либо ретроспективно грузить все документы заново, либо жёстко обязывать менеджеров загружать файлы вперёд, до того как ставить галочку. Третий пример вообще не про портал, но про ту же болезнь. Новый сотрудник не работал в CRM: все документы клиентов хранились на его личном компьютере. Когда встал вопрос передачи дел, оказалось, что проанализировать кейсы и передать их другому менеджеру невозможно — данные существовали в единственном экземпляре на одном ноутбуке. Портал в такой ситуации бесполезен: показывать клиенту нечего, источника данных нет. Здесь ошибаются все, включая меня. Я долго смотрел в отчёт, где напротив клиентов стояли галочки «документы в наличии», и был уверен, что база готова к обучению модели. Файлов за галочками не было. Моя недоработка: я не проверил, что именно ложится в CRM, — принял отметку менеджера за факт и построил на ней план. Если у вас сейчас так же — это не приговор и не повод закрывать проект. Чинится одним правилом: файл сначала, галочка потом. Где ломается №1 Не начинайте разработку портала, пока не проверили, куда физически падают документы клиентов. Личный компьютер, Google Drive, NextCloud, локальные папки — если хотя бы часть данных живёт вне CRM, портал будет показывать неполную или устаревшую картину. Сначала наводите порядок в источнике, потом стройте витрину поверх него. Подробнее о том, как CRM врёт данными и почему сверку нужно вести по ID, а не по датам — в статье про сдвиг дат в Bitrix24 . Разработка клиентского портала: сколько стоит и с чего начинать Вопрос про деньги обычно звучит первым, поэтому отвечу прямо: разработка клиентского портала стоит ровно столько, сколько стоит порядок в данных под ним. Сам интерфейс — самая дешёвая часть проекта. Порядок расходов на нашем опыте: собрать рабочий экран со статусами и загрузкой документов — недели, а не месяцы, если данные уже лежат в одном месте. Если не лежат — сначала считайте наведение порядка в учёте, и это основная статья. Портал поверх кривых данных обойдётся дороже вдвое: сперва заплатите за разработку, потом за переделку. С чего начинать. Не с дизайна и не с выбора подрядчика, а с одного вопроса: какие три вещи клиент спрашивает у менеджера чаще всего? Обычно это статус заказа, какие документы ещё нужны и когда будет результат. Портал, который отвечает на эти три вопроса без человека, уже окупается — всё остальное можно добавлять потом. Что бывает, когда портал собирают наоборот — от интерфейса, — показал на 12 страницах одного скрипта . Обработка заявок: автоматизация, которая не роняет данные Если портал принимает заявки от клиентов напрямую — форму обратной связи, загрузку документов, запрос статуса — узкое место чаще не в интерфейсе, а в приёмнике данных. В одном проекте разработали плагин для формы, который снизил время отклика с 3 секунд до 80 миллисекунд (на диаграмме — до и после), и добавили буферизацию заявок на случай сбоя приёмщика. Раньше при падении системы заявка терялась молча. Теперь она встаёт в очередь и обрабатывается, как только сервис поднимается. Решение признали достаточно надёжным, чтобы раскатать на всю группу компаний. 3000 мс было 80 мс стало Отклик формы обратной связи снизился благодаря новому плагину и буферизации заявок на случай сбоя приёмщика. Второй пример из той же области — обработка заявок через API: данные шли из портала в облачную систему анализа, потом записывались в таблицу. Проблема была в том, что разработчик не видел баланс своей учётной записи и не мог отследить, где заявка потерялась. Решили логировать каждое действие процесса в общую таблицу через прокси-сервис — теперь видно три категории: успешно обработано, не обработано, ошибка. Похожий отчёт получается на выходе — примерный вид такой таблицы ниже. Без такого лога любая автоматизация заявок превращается в чёрный ящик: заявки вроде идут, но проверить это можно только руками, перебирая переписки. Лог обработки заявок — прокси-сервис 3 категории статуса Заявка Статус doc_00918 успешно обработано doc_00919 не обработано doc_00920 ошибка Логика простая: любая точка входа заявок с портала должна иметь буфер и лог. Иначе одна ночь падения сервиса — и вы теряете клиентов, даже не зная, сколько именно. ИИ-связка: конвейер анализа документов и промпт Конвейер, который реально работает в разобранных кейсах, выглядит так: Клиент загружает документ в портал → OCR распознаёт текст → дешёвая модель определяет тип документа → к типу применяется своя спецификация → при необходимости включается более мощная модель для сложного случая → результат уходит менеджеру на проверку → подтверждённые данные попадают в CRM как обучающий пример. Два момента здесь стоили нам нескольких недель работы. Первый: распознавание внутри самого сервиса модели работало отлично, а при запуске через API повёрнутые документы переставали распознаваться корректно. Решение — не гнать всю базу разом. Собрали компактную выборку типовых примеров, обучили стажёра проверять результат вручную и написали отдельные спецификации под каждый тип документа: как модель путает имена и фамилии, пропускает отчества, сбивается на вертикально загруженных сканах. Второй момент: OCR внутри системы и OCR при передаче документов по API давали разное качество — потребовался отдельный протокол выбора модели под тип документа и почерк. Ниже — рабочий промпт для этапа «определение типа документа + первичная оценка кейса». Это дешёвая модель (например, класс Haiku/GPT-4o-mini) — задача простая, классификационная, дорогая модель здесь избыточна и увеличивает счёт без пользы. Пример ответа модели на такой запрос: Если need_strong_model = true — документ уходит на второй проход к более мощной модели с расширенным промптом, который уже включает спецификацию под конкретный тип и просит выделить уязвимости кейса (недостающие поля, нечитаемые фрагменты, признаки старого шаблона документа). Это тот самый многоступенчатый анализ: дешёвая модель фильтрует основной поток, дорогая разбирает только спорные 20–30% случаев. Инженерная обвязка. Всё крутится вокруг трёх узлов: облачное хранилище документов (единая точка вместо трёх), прокси-сервис, который логирует каждый вызов модели в таблицу (успех / ошибка / нет ответа), и вебхук в CRM, который обновляет карточку клиента только после подтверждения менеджером. Один рабочий MCP-server поверх базы CRM даёт ИИ-инструментам прямой доступ к данным компании без ручного экспорта — по нашему опыту это снижает расход токенов на 30–40% и уменьшает долю галлюцинаций модели, потому что она не пытается угадывать контекст, а получает его напрямую. Перезапуск — по крону раз в час: проверяются документы со статусом «в очереди» дольше часа, они переотправляются автоматически. Об ошибке система сообщает записью в лог-таблицу с кодом ошибки и document_id, а не молчанием — это правило родилось из той самой истории с потерянным балансом, о которой я писал выше. MVP вместо релиза Ваш первый портал должен закрывать один вопрос клиента, а не тридцать. Дальше вы будете достраивать по обратной связи, а не по фантазии. Соблазн — запустить портал сразу целиком, с красивым дизайном и всеми функциями. Одна команда так и сделала со страницами сайта: собрали больше десятка типов страниц одним скриптом, который должен был соблюдать брендбук. Результат не соответствовал ни стилю, ни гайдлайнам. Руководитель не стал доводить каждую страницу до идеала — взял утверждённый прототип главной как эталон и пересобрал все типы заново с участием команды, через полноценный аудит. В итоге ушло больше времени, чем если бы сразу заложили ревью на старте вместо попытки автоматизировать всё скриптом. Другой случай — тот же урок, но с чужим конструктором распознавания документов: разработчик собрал систему на основе крупного массива вопросов из публичного источника, а при передаче техническому лиду она не собралась. «Получается красивый дом, но дверей нету, как зайти — непонятно». Это ровно тот риск, который снимает поэтапный пилот вместо разового релиза. Этап Что делали Зачем 1. Пилот на живых кейсах Несколько десятков реальных случаев прогнали через алгоритм, отдали менеджерам на проверку Проверить корректность без риска на всей базе 2. Тест на сегменте 20% клиентской базы, оценка отклика рынка Понять, нужен ли портал клиентам вообще, до вложений в MVP 3. Сбор данных полгода Накопление массива для обучения модели Без объёма данных нейросеть в портале не заработает 4. MVP к концу года Запуск ограниченной версии Только после проверки качества на двух предыдущих этапах На диаграмме ниже — примерная длительность каждого этапа: от короткого пилота до MVP в конце года. Пилот: живые кейсы ~2 недели Тест: сегмент клиентов ~2 месяца Сбор данных до объёма ~6 месяцев MVP запуск конец года Та же логика повторилась и с документами — той самой компактной выборкой и стажёром, о которых я писал выше: сначала маленькая выборка с ручной проверкой, потом спецификации под каждый тип. Дешевле, чем гнать автоматизацию сразу на всей базе данных и потом переделывать модель с нуля. Про то, как ИИ-система теряет точность на нестандартных документах и что с этим делать пошагово, — в статье про рост распознавания с 59% до 85% . Экономика: что портал стоит и что даёт Считаю раздельно три эффекта — их нельзя складывать в одну цифру, потому что это разные инициативы с разной механикой. Возьмём для примера условную компанию: производство на заказ, отдел из 15 менеджеров, оборот ~18 млн ₽/мес, средний чек около 120 000 ₽ — то есть примерно 150 сделок в месяц на весь отдел. Формула для каждого эффекта — часы × поток клиентов × доля повторяющихся вопросов, чтобы вы могли подставить свои цифры вместо примерных. Эффект статусов (снятые вопросы «на каком я этапе»). Оценка: отдел из 15 менеджеров, у каждого в работе около 12 клиентов на этапе ожидания документов. По грубой оценке 30% из них раз в день пишут с вопросом статуса (около 4 вопросов), на ответ уходит примерно 5 минут. Это около 20 минут в день на менеджера, или около 6 часов в месяц (оценка, 22 рабочих дня). На весь отдел — около 88 часов рабочего времени в месяц (оценка). Это эффект именно личного кабинета со статусами, отдельно от MVP с нейросетью — статусы можно и нужно внедрить до всякого ИИ. Эффект буферизации заявок. Отдельная мера, отдельный эффект. Если форма без буфера падает в сумме на условные 2 часа в месяц (оценка) при потоке около 30 заявок в день, то за это время теряется молча несколько заявок. При исторической конверсии обращения в сделку ≈20% (оценка) это означает риск потери около одной оплаченной сделки в месяц — то есть каждая пятая из молча потерянных заявок могла бы стать клиентом. При среднем чеке 120 000 ₽ это риск около 120 000 ₽/мес (оценка). Это тот риск, который снимает не портал целиком, а конкретно буфер и лог на приёмнике формы — недорогая доработка с ощутимой отдачей. Стоимость пилота с нейросетью. Проверка живых кейсов менеджерами — оценочно 15 минут на кейс, итого около 10 часов работы менеджеров на первый круг проверки. При ставке ~1 000 ₽/час (оценка) это около 10 000 ₽ разовых затрат — на порядок дешевле, чем сразу запускать MVP на всей базе клиентов и потом переделывать модель, которую обучили на «галочках без файлов». Эффект Оценка Что конкретно даёт Статусы в личном кабинете ~88 ч/мес (оценка) Снимает вопросы «на каком я этапе» с отдела менеджеров Буферизация заявок ~1 сделка/мес риска, ~120 000 ₽/мес (оценка) Не теряет молча несколько заявок при сбое формы Пилот ИИ-анализа (разово) ~10 ч, ~10 000 ₽ (оценка) Проверка живых кейсов менеджерами перед тестом на сегменте Итог: личный кабинет со статусами и буферизация заявок окупаются почти сразу и не требуют нейросети вообще. ИИ-часть портала (анализ документов) — самая дорогая и самая долгая по времени составляющая, её эффект проявится не раньше, чем накопится обучающий массив, то есть не раньше MVP к концу года. Чтобы прикинуть свой случай: возьмите число менеджеров, среднее число активных клиентов на менеджера, долю вопросов о статусе в день и свою историческую конверсию — и посчитайте по той же формуле. Когда клиентский портал для бизнеса не нужен вообще Если у вас пять пересекающихся процессов внутри одного проекта — сбор документов, исследование, редактура, вёрстка, производство — и вы ещё не свели их в одну воронку внутри CRM, портал только добавит путаницы. В одном таком проекте решили не делать пять отдельных воронок, а собрать одну главную с проект-менеджером как фасадом и вложенными смарт-процессами внутри, чтобы руководитель видел итоговый процент готовности без погружения в десятки деталей. Это заняло меньше ресурсов, чем разработка внешнего портала, и решило ту же задачу — прозрачность для того, кто принимает решения. Проверка занимает пять минут: четыре признака, каждый из которых означает «портал вам пока не нужен». Хватает одного совпадения, чтобы отложить разработку и заняться тем, что под ней. Признак 1. Документы клиентов лежат больше чем в одном месте. Личные компьютеры, пара облаков и CRM — портал покажет клиенту не всю картину, а ту часть, которая случайно попала в систему. Сначала одно хранилище, потом витрина над ним. Признак 2. Однотипные вопросы отнимают у менеджеров меньше рабочего дня в неделю. Экономить нечего: отвечать руками дешевле, чем строить и потом поддерживать интерфейс. Признак 3. Статус клиента нельзя показать без пояснения менеджера. Пока нет фиксированного списка причин и следующего шага, слово «отказано» в кабинете читается как приговор — телефон зазвонит чаще, а не реже. Признак 4. После запуска портал некому вести. Нет владельца и нет записанной инструкции по интеграции — через полгода никто не вспомнит, какие поля куда уходят, и любая правка встанет. Обратите внимание: три признака из четырёх — про данные и процесс, и ни один не про дизайн. Портал не чинит то, что сломано под ним. Где ломается признак 4 Портал легко превращается в проект без документации. У нас были случаи, когда знания о настройке интеграции передавались только устно, «под диктофон», а таблиц и регламентов не оставалось вообще. Если человек, который настраивал вебхук между порталом и CRM, уходит — новый сотрудник тратит дни на то, чтобы понять идентификаторы полей, которые нигде не записаны. Пишите инструкцию сразу, а не «когда будет время». Если хотя бы один признак про вас — сначала чинить его, а потом думать про интерфейс. Иначе получится история про «красивый дом без дверей»: интерфейс готов, а зайти в него системно нельзя, потому что данные под капотом рассинхронизированы. Чек-лист: с чего начать в понедельник Проверьте, где физически хранятся документы клиентов сейчас — сколько источников (личные компьютеры, облака, CRM) участвуют в одном процессе. Посчитайте, сколько раз в день менеджеры отвечают на вопрос «на каком я этапе» — это и есть будущая экономия от статусов, а не от всего портала целиком. Добавьте буфер и лог на любую точку приёма заявок с сайта или портала — это дешевле и быстрее, чем весь остальной проект. Заведите фиксированный список причин отказа/статусов вместо свободного текста — без этого показывать статус клиенту нечестно. Если планируете ИИ-анализ документов — начните с небольшой выборки живых кейсов и ручной проверки, а не с запуска на всей базе. Запишите инструкцию по интеграции (вебхук, идентификаторы полей) в документ, а не оставляйте знание в голове одного разработчика. Если у вас автоматизация уже работает, но требует, чтобы кто-то за ней постоянно следил — это отдельная и очень частая проблема, разобрана в статье про автоматизацию, которая становится второй работой . Проверьте себя тремя вопросами: сколько однотипных запросов приходит вашим менеджерам за неделю, сколько времени уходит на ответы и жалуются ли клиенты на непрозрачность. Если по всем трём цифры высокие — портал вам нужен. Если нет — займитесь тем, что болит. Как считать окупаемость таких проектов — в бесплатном курсе . Как решать вам Мой критерий после нескольких таких проектов: портал оправдан, когда однотипные вопросы клиентов съедают у ваших людей больше рабочего дня в неделю. Меньше — дешевле отвечать руками и вложиться во что-то другое. И не стройте сразу большой: наш первый рабочий вариант закрывал ровно один вопрос — «на каком этапе мой заказ». Этого хватило, чтобы снять половину звонков. И то, что я вынес из этих проектов главным. Умение посмотреть на свой процесс и сказать «вот здесь машина справится, а вот здесь под ней нет данных» — это отдельный управленческий навык, и его придётся освоить. Раньше руководителя мерили тем, как он раздаёт задачи людям. Сегодня дороже стоит тот, кто умеет масштабировать процесс через машину и до старта видит, где витрину ставить не на чем. Портал этот навык проверяет быстро и без пощады: либо вы посчитали часы и источники данных заранее, либо оплатили красивый фасад. Посчитайте свои однотипные вопросы за неделю — эта цифра и ответит вам, нужен ли портал сейчас или ещё рано. ## Контроль сроков выполнения заказов: как перестать узнавать о срыве от клиента URL: https://davidgerstein.pro/blog/sroki-vypolneniya-zakazov/ Дата: 2026-08-10 Направление: Производственный цикл Цифры: 8 из 75 сделок зависает на одном этапе (~10%) · около 20 случаев в месяц требуют ручного разбора причины · 3 неответа клиента = отказ по договору Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы не можете прямо сейчас, за минуту, назвать три заказа, которые стоят дольше норматива, — у вас нет контроля сроков. У вас есть система оповещения через скандал: вы узнаёте о срыве от клиента, а не до него. И узнаёте последним — раньше вас об этом знали менеджер, клиент и, скорее всего, ваш конкурент, которому клиент уже позвонил. Разбираю, как мы это чинили: без новых систем и без найма, одной перестройкой того, что уже было. Что такое контроль сроков выполнения Контроль сроков выполнения — это когда норматив на каждый этап заказа зафиксирован как обязательство, система сама считает дни в статусе и при превышении норматива пишет ответственному, а не ждёт, пока кто-то откроет отчёт. Он держится на трёх опорах: срок прописан в договоре, статус фиксируется автоматически без участия менеджера, причина просрочки — обязательное поле со списком значений, а не свободный текст. Без этих трёх опор в отделе из 8 менеджеров при 75 сделках в работе зависает до 8 сделок на одном этапе — около 10% активного портфеля, — и руководитель узнаёт о срыве последним, от самого клиента. В отделе из 8 менеджеров при обороте около 9 млн ₽/мес и среднем чеке 180 тыс. ₽ одновременно в работе держится порядка 75 сделок — так диктует цикл сделки около 6 недель. В какой-то момент 8 из этих 75, то есть каждая девятая, зависли на этапе «документы запрошены». Не на день, не на неделю — достаточно долго, чтобы это стало заметно в отчёте. Разбор показал причину: продавцы на этапе продажи говорили клиентам «спешить не нужно, можно начать когда угодно». Клиент расслаблялся. Документы не присылал. Формально сделка жила, фактически — стояла. Контроль сроков выполнения заказов в этой компании до того момента держался на памяти менеджера и на том, вспомнит ли он позвонить клиенту через месяц. Похожая история, только с другим механизмом сбоя. В феврале из-за несинхронизированного изменения требований к пакету документов зависло 9 сделок, в апреле — всего 1, а за первую неделю мая снова 6. Требования изменились, а процесс не подхватил изменение вовремя. И есть отдельный риск: если ошибка повторится с крупным клиентом, под удар попадёт не только конкретная сделка, но и репутация компании при следующем тендере. Оба случая — не про недобросовестных сотрудников. Про то, что срок выполнения заказа нигде не был зафиксирован как обязательство, а отклонение от него нигде не всплывало само. Если у вас в CRM статус сделки — это то, что менеджер поменял вручную, когда вспомнил, — вы уже в этой ситуации, просто ещё не увидели цифру. Почему вы узнаёте о срыве от клиента У нас так было полгода: я узнавал о просрочках из претензий, а мои руководители — от меня. И первое, что я сделал, было ошибкой: я собрал людей и потребовал «внимательнее вести CRM». Полтора месяца стало чуть лучше, потом всё вернулось. Это моя недоработка, не их: я требовал дисциплины там, где не было ни зафиксированного срока, ни сигнала о его нарушении. Если вы сейчас на этой стадии — это нормально, здесь спотыкаются все, включая меня. Три причины, и ни одна не про безответственность ваших людей. Классическая цепочка: клиент звонит недовольный, менеджер оправдывается, директор лезет в CRM и видит, что сделка «висит» уже два месяца без движения. При этом статус в системе формально корректный — просто никто не смотрел, сколько дней он не менялся. Дело не в CRM. Статус там — это то, что менеджер отметил в последний раз, а не сигнал о том, что дело зависло. Разбор с этапом внешней проверки показал то же самое: система вообще не фиксировала случаи неуспешного прохождения. Менеджер вручную откатывал сделку назад и должен был удалить дату проверки — и часто забывал это делать. Тогда в отчётах числилась проверка, которой не было, а реальный срок молчаливо съезжал. Где теряется история Ручной откат сделки назад — это точка, где теряется вся история просрочки. Если человек вручную возвращает статус, он с высокой вероятностью забудет зафиксировать причину. Автоматизировать нужно не «красивый дашборд», а именно момент отката. Что добавили под этап проверки Решение получилось не про интерфейс, а про обязательные поля и таймер: отдельное поле даты неуспешной проверки — не путается с датой планируемой; обязательная причина отказа с выбором из списка (документы, оплата, согласование, другое) — без свободного текста, который никто потом не читает; автоматическая задача менеджеру ровно в день проверки с двумя вариантами ответа: пройдена / не пройдена; уведомление контролю качества, если сделка не перемещена на новый этап в установленный срок. Последний пункт — самый важный. Не начальнику менеджера, а именно контролю качества, отдельному от продаж человеку. Это разрывает зависимость контроля от того, кто заинтересован в красивой отчётности. Статусы для клиентов: снимок, а не текущее значение Если статусы вы планируете показывать клиенту сами — смотрите разбор про клиентский портал : что выводить, а что оставить внутри. Тонкость, которая спасёт вас от споров: клиент должен видеть, что было обещано изначально, а не только то, что стало после сдвигов. Отдельная ловушка — когда статус в CRM это один и тот же столбец, который менеджер просто меняет по ходу дела. Тогда невозможно понять, сколько дней клиент провёл на каждом этапе и когда именно случился затор. Рабочее решение — двухуровневая фиксация. Раз в неделю, в фиксированный день (в разобранном случае — среда вечером), система автоматически записывает актуальный статус каждого клиента в отдельный столбец. Новый столбец добавляется слева от предыдущих — так руководитель видит последние изменения без прокрутки таблицы вправо. Если статус не поменялся, ставится прочерк — это тоже сигнал, причём часто более тревожный, чем смена статуса. CRM · Срез статусов · среда, 18:00 8 из 75 сделок на этапе «документы запрошены» Клиент 29.05 22.05 15.05 Иванов А. — Документы запрошены Документы запрошены Петрова М. Проверка назначена Документы запрошены — Сидоров К. — — Документы запрошены По такому снимку видно не только «где клиент сейчас», но и «сколько недель он там стоит» — это и есть данные для поиска системных заторов вроде описанной выше группы из 8 сделок на «документах запрошены». Февраль 9 сделок Апрель 1 случай Май, 1-я неделя 6 сделок На диаграмме — сделки, зависшие из-за устаревшего шаблона документов, по месяцам. Провал в апреле — не решение проблемы, а просто меньше сделок в этом месяце в целом: сама причина (несинхронизированное изменение требований) устранена не была, поэтому в мае объём снова вырос. Про то, как CRM вообще может искажать даты и вводить в заблуждение при построении отчётов, у меня был отдельный разбор — CRM врёт. Как я поймал Битрикс24 на сдвиге дат . Если статусы «сами меняются» без видимой причины, начинать нужно оттуда. Автоматические алерты: что это и как их ставить Автоматический алерт — это сообщение, которое система отправляет сама при нарушении срока, без участия менеджера. Разница с отчётом принципиальная: отчёт надо открыть и прочитать, алерт приходит к тому, кто должен действовать, в момент, когда действовать ещё не поздно. Рабочая настройка выглядит так. У каждого этапа есть норматив в днях. Система считает дни в статусе и при превышении отправляет сообщение ответственному — в мессенджер, а не в журнал. Если через сутки статус не изменился, второе сообщение уходит его руководителю. Ключевое, что делает алерты рабочими, а не фоновым шумом: сообщение должно требовать действия, а не сообщать факт . «Заказ №142 стоит в сборке 6 дней при нормативе 3 — что делаем?» работает. «Просрочено заказов: 7» не работает, потому что непонятно, чьё это и что с этим делать. Договор: первая линия контроля сроков выполнения Посмотрите свой типовой договор: там вообще указан срок и что происходит при его сдвиге? У половины компаний это формулировка ни о чём. Самая дешёвая мера сработала лучше остальных. В договорах с клиентами не был прописан срок действия контракта. Для аналитики это было критично: без даты «когда услуга должна быть выполнена» нельзя посчитать просрочку в принципе — не с чем сравнивать. Решение простое на бумаге: внести в регламент требование прописывать сроки для стандартных работ. Для специальных, нетиповых видов работ срок сознательно опускается — не нужно натягивать обязательство там, где реальная зависимость от третьей стороны (например, ожидание документа от внешнего ведомства или партнёра — до пяти месяцев) делает жёсткий срок бессмысленным и даже опасным для компании. Второй пункт в договор — условие про отказ клиента от контакта. Если клиент не отвечает три зафиксированных раза, это считается отказом от услуги. Формулировка защищает компанию от ситуации, когда сделка формально «активна», а по факту клиент пропал на полгода, и именно на это время растягивается статистика просрочек, за которую отвечает менеджер. Правило Если срок не зафиксирован в договоре, любая система статусов будет показывать красиво оформленную неопределённость. Автоматизация фиксации не заменяет обязательство — она делает видимым его отсутствие. Что происходит, когда данные живут в головах Ваш риск здесь не в потере файлов, а в том, что статус заказа знает только один человек — и он в отпуске. Ещё один источник просрочек — не процесс, а место, где хранятся данные. В одном случае новый сотрудник вообще не работал в CRM: все документы клиентов лежали на личном компьютере. Проанализировать кейсы или передать дела другому менеджеру было физически невозможно — данные просто не существовали для системы. При уходе менеджера в отпуск в другой компании нашли рабочий обходной путь: документооборот вели через общую таблицу со всеми контрактами. Назначенный сотрудник сверял поступление документов по фамилиям и отмечал в таблице, руководитель подтверждал и уведомлял клиентов. Это не идеальное решение — но оно централизованное, и любой человек может подхватить процесс без раскопок в личных папках. Похожая картина была с сотрудником, который собирал документы по клиентам для дальнейшей передачи подрядчикам: у него не было доступа в CRM, вся координация шла через переписки и локальные папки. При передаче проекта выяснилось, что клиентская информация рассредоточена и недоступна команде — историю работы пришлось восстанавливать заново, потому что фиксировалось всё «под запись, под диктофон» — ни таблиц, ни регламентов. Про то, почему менеджеры вообще избегают вносить данные в общую систему, я разбирал отдельно в статье Менеджеры не вносят данные в CRM — это не про лень, а часто про неудобный интерфейс и отсутствие обратной связи от системы. ИИ-связка: классификация причин просрочки Мы завели её после того, как я устал слышать «так вышло»: машина раскладывает причины по типам, и становится видно, что половина срывов — не вина исполнителей. Здесь вы получаете не факт «сорвали», а причину — и по ней уже видно, чинить процесс или разговаривать с конкретным исполнителем. Обязательное поле «причина отказа» решает проблему только наполовину: менеджер может выбрать «другое» и написать в комментарии два слова. Дальше это невозможно агрегировать — приходится читать вручную десятки карточек. Здесь и появляется задача для модели: не принимать решение вместо менеджера, а привести его текст к структуре, по которой уже можно строить отчёт. Конвейер выглядит так: Bitrix24: смена стадии сделки → вебхук уходит во внешний обработчик. Облачная функция передаёт комментарий менеджера в дешёвую модель для классификации. Модель возвращает категорию и дату повтора — функция записывает их обратно через REST API. Каждый шаг логируется; при сбое — алерт в Google Sheets и чат контроля качества. Шаг 1: в Bitrix24 настраивается автоматизация — при переводе сделки на стадию «проверка не пройдена» вебхук отправляет во внешний обработчик JSON с данными сделки и комментарием менеджера. Пример того, что летит на вход: Шаг 2: этот JSON вместе с промптом уходит в дешёвую модель (обобщённо — модель класса GPT-4o-mini или Claude Haiku: задача простая, классификация короткого текста по фиксированному списку, дорогая модель здесь избыточна и просто дороже на объёме в пару десятков кейсов в месяц). Промпт: Пример ответа модели на вход выше: Шаг 3: облачная функция берёт этот JSON и через метод crm.deal.update REST API Bitrix24 записывает категорию в обязательное поле причины отказа, а дату повторной попытки — в отдельное поле для следующей автозадачи менеджеру. Если confidence ниже 0.6 — категория не проставляется автоматически, а карточка помечается флагом «проверить вручную»: дешёвая модель не должна тихо ошибаться там, где сомневается сама. Инженерная обвязка Логика крутится не «где-то в облаке абстрактно», а на конкретном стеке: вебхук Bitrix24 → серверлес-функция (можно на n8n или Google Cloud Functions) → вызов API модели → запись обратно через REST API CRM. Всё, что происходит на каждом шаге, дублируется строкой в общую Google-таблицу: время вызова, deal_id, что отправили, что получили, статус (успех/ошибка/низкая уверенность). Это тот же принцип, что уже отрабатывали на похожей задаче с обработкой заявок через API — тогда сотрудник не видел баланс учётной записи модели и не мог поймать ошибку, пока не появился общий лог всех вызовов. Здесь ошибка та же по природе: без построчного лога руководитель не узнает, что классификатор неделю падал по таймауту, пока кто-то не заметит пустые поля причины отказа у десятка карточек. Перезапуск — простой ретрай с экспоненциальной задержкой на 2-3 попытки; если все три упали — в чат контролю качества уходит уведомление с deal_id и текстом ошибки, карточка помечается на ручную обработку. Никакой сделки, которая должна получить статус, нельзя оставлять «зависшей» без сигнала о том, что автоматика не сработала — иначе получаем ту же тишину, из-за которой директор узнаёт о срыве от клиента. Где ломается автоматика Модель на входе видит только комментарий менеджера — если он пишет «клиент не смог» без деталей, категория уйдёт в «другое» с низким confidence, и карточку всё равно придётся разбирать вручную. Классификатор снимает рутину с однозначных случаев, но не заменяет обязанность менеджера писать по существу. Экономика: сколько стоит и когда окупается Считайте от ваших потерь: сорванный срок — это не только штраф, но и клиент, который в следующий раз пойдёт к другому. Настройка обязательных полей, автозадачи и вебхука с классификатором занимает около 18-25 часов работы специалиста (18 000-25 000 ₽ по ставке ~1 000 ₽/час), а снимает с менеджеров и контроля качества около 5 часов ручного разбора в месяц (≈5 000 ₽/мес) — при этом остаётся частью защиты от риска потери сделок, который оценивается в 360 000 ₽/мес (оценка, верхняя граница). Разложим на цифрах. Отдел из 8 менеджеров держит одновременно около 75 сделок в работе (чек 180 тыс. ₽, цикл 6 недель). Без автоматической фиксации на одном этапе без движения зависает около 10% портфеля — это 8 сделок. Не каждая зависшая сделка теряется: часть просто задерживается. Но по опыту похожих ситуаций около четверти из зависших (2 сделки из 8, консервативно) реально уходит в отказ или требует полного пересбора документов. При чеке 180 тыс. ₽ это риск на уровне 360 000 ₽/мес (оценка, верхняя граница — реальные потери могут быть ниже, если часть дел просто задерживается, а не теряется безвозвратно). Теперь стоимость ручной альтернативы. Через стадию «проверка/согласование не пройдено» в месяц проходит порядка 20 сделок (около 40% от 50 закрываемых в месяц — нормальная доля для услуг с проверками на входе). Если на разбор причины и уточнение статуса у каждой уходит около 15 минут (оценка), это 5 часов в месяц, или 5 000 ₽ по ставке 1 000 ₽/час менеджера. Именно эти 5 часов автоматика снимает напрямую — это единственный по-настоящему денежный поток-эффект классификатора. При затратах на внедрение 18 000-25 000 ₽ и экономии 5 000 ₽/мес окупаемость по времени разбора — 4-5 месяцев. Это честная цифра для отдела такого масштаба, а не мгновенная отбивка. Риск в 360 000 ₽/мес снижает не классификатор сам по себе, а вся связка целиком — договор со сроком, обязательное поле, автозадача и контроль качества; вклад именно ИИ-классификатора в этом риске отдельно от прочих мер выделить нельзя. Что не считаем эффектом: если высвобожденные 5 часов менеджера и контроля качества не сокращают штат и не увеличивают продажи, а просто перетекают на другую рутину — это не денежный эффект, а перераспределение нагрузки на бумаге. Эксплуатация классификатора на объём около 20 вызовов в месяц с короткими текстами (комментарий менеджера на 1-2 предложения плюс промпт на пару абзацев — порядка 200-300 токенов на вызов) при тарифах дешёвых моделей обходится в 100-300 ₽/мес — счёт идёт на рубли, а не на тысячи, если не гонять через неё документы целиком. Показатель Значение (оценка на условном примере) Активных сделок в работе одновременно 75 (отдел из 8 менеджеров) Зависших дел без движения в месяц 8 (~10% портфеля) Риск срыва/потери дела в месяц 2 сделки × 180 тыс. ₽ = 360 000 ₽ Ручной разбор без автоматизации ~5 часов/мес (≈5 000 ₽) Разовое внедрение (поля + автозадача + классификатор) 18-25 часов специалиста (18 000-25 000 ₽) Окупаемость по экономии времени 4-5 месяцев Эксплуатация классификатора в месяц 100-300 ₽ Так эти цифры будут выглядеть на экране отчёта, который стоит собрать перед внедрением: Отчёт: экономика контроля сроков 8/75 сделок зависло без движения 360 000 ₽ риск потерь в месяц 18-25 ч разовое внедрение 4-5 мес окупаемость по времени Чтобы прикинуть свой случай: возьмите число активных сделок в работе, оцените долю зависших без движения по своему отчёту (не по этой статье), умножьте на средний чек и на реальную долю срывов из своей практики — цифры в этом разделе служат ориентиром для расчёта, а не готовым ответом. Чек-лист: с чего начать в понедельник Выгрузить из CRM все сделки, которые не меняли статус дольше двух недель, и посчитать долю от общего активного портфеля — это ваша реальная цифра вместо оценки из этой статьи. Проверить 10 случайных договоров за последний месяц на предмет прописанного срока выполнения для стандартных работ. Если срока нет — это первая правка в регламент, дешевле любой автоматизации. Сделать причину отказа/просрочки обязательным полем с фиксированным списком значений вместо свободного текста — хотя бы вручную, без интеграции с моделью. Настроить один автоматический снимок статуса раз в неделю в отдельный столбец (можно начать с Google Sheets и ручного экспорта, не обязательно сразу вебхук). Назначить, кто получает уведомление о просрочке этапа — не непосредственный руководитель менеджера, а независимый контроль качества. Если решите автоматизировать классификацию причин — начните с 10-15 реальных кейсов и дешёвой модели, проверяя результат вручную, прежде чем доверять полю в CRM. Похожий принцип — не чинить симптом, а искать место, где система молчит вместо того чтобы сигналить, — разбирал и в материале про автоматизацию, которая требует надзора . Контроль сроков без такого надзора рано или поздно превращается в ещё одну красивую таблицу, за которой всё равно нужно ходить и проверять руками. Начните с замера на этой неделе: возьмите десять последних заказов и посмотрите, сколько из них сдано в обещанный срок. Цифра обычно ниже, чем ощущение, — и именно она даёт основание что-то менять. Как поставить контроль сроков, который предупреждает заранее, — механика в бесплатном курсе для руководителей . Что я понял про сроки Мы годами считали срывы виной исполнителей и разбирали каждый случай отдельно. Когда собрали статистику причин, картина изменилась: больше половины просрочек начиналось не у исполнителя, а на входе — заказ приняли без реального срока, согласовали устно, никто не зафиксировал. И ещё одно, чего я не понимал раньше. Умение построить так, чтобы о просрочке мне сообщала машина, а не клиент, — это не «настройка CRM». Это отдельный управленческий навык, и его придётся освоить так же, как когда-то осваивали бюджетирование. Руководитель, который держит сроки системой, стоит дороже руководителя, который держит их своей памятью и обзвоном по пятницам. Память кончается на тридцатой сделке. Система — нет. Ваш вывод из этого простой: прежде чем спрашивать с людей, проверьте, есть ли у них шанс уложиться. Часто выясняется, что срок им никто и не называл. ## Отчёты Битрикс24 врут: как я поймал CRM на сдвиге дат задним числом URL: https://davidgerstein.pro/blog/crm-vret-dannye-bitrix24/ Дата: 2026-08-08 Направление: Продажи Цифры: 12,9% лидов со сдвигом дат · сверка по ID · сторож-снимок Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваши отчёты Битрикс24 не сходятся между собой — не спешите винить систему, подрядчика или собственные фильтры выгрузки. В моём случае причина оказалась куда неприятнее: данные менялись задним числом, и об этом никто не знал. Если две выгрузки из CRM за один и тот же период дают разные числа — это не вы что-то не так фильтруете. Возможно, ваши данные меняются под вами. У меня это выглядело так: 12,9% лидов за месяц изменили дату создания задним числом . Отчёты, планёрки, мотивация менеджеров — всё считалось на цифрах, которые тихо ползли. Эта статья — как обнаружить такое у себя, как доказать (себе и коллегам, которые скажут «ты просто неправильно выгрузил») и как построить сторожа, чтобы это не повторялось. Считаю на условной сервисной компании: 8 менеджеров, оборот ~9 млн ₽/мес, средний чек ~180 тыс. ₽, около 50 сделок в месяц. Почему отчёты Битрикс24 не сходятся между собой? Отчёты Битрикс24 расходятся не из-за фильтров выгрузки и не из-за того, что отчёт «неправильно настроен», — чаще всего данные под отчётом меняются задним числом. У меня за один месяц 12,9% лидов изменили дату создания уже после того, как попали в отчёты: сегодняшняя выгрузка за прошлый период отличается от вчерашней — и обе выглядят правильными. Проверяется это за вечер: сверить дату создания с соседями по ID и снять два снимка базы с разницей в сутки. Единичный сдвиг — скорее ручная правка. Тревога начинается, когда сдвиги кратны фиксированному интервалу (у меня — 18 и 36 часов) и накапливаются месяц к месяцу. Как выглядит, когда отчёты Битрикс24 не сходятся между собой Симптом первичен, диагноз — вторичен: если отчёт за прошлый месяц, снятый сегодня, отличается от того же отчёта неделю назад — данные меняются задним числом, а не отчёт «неправильно посчитан». У меня набор симптомов был такой, каждый по отдельности легко списать на случайность: отчёт за прошлый месяц, снятый сегодня, отличается от того же отчёта, снятого неделю назад; сумма лидов по дням не сходится с итогом за месяц; менеджер уверяет, что лид пришёл в пятницу, а в CRM он «создан» в среду; конверсия периода меняется без единой новой сделки. Обычная реакция — перепроверить фильтры и успокоиться. Я перепроверял фильтры три раза, прежде чем допустить мысль, что проблема в данных. Это нормально: гипотеза «система врёт» психологически дороже гипотезы «я ошибся». Но проверяется она за вечер, а не за квартал. Ещё один маркер, который я сначала пропустил: расхождение всегда росло к концу месяца, когда отчёты смотрели чаще — это подсказка, что источник сдвига связан не со случайным сбоем, а с регулярным процессом, который срабатывает по расписанию. Как доказать: сверка с соседями по ID Правило простое: в большинстве CRM (в Битрикс24 точно) идентификаторы записей растут монотонно, и это независимый свидетель против самой CRM. Если у лида с ID 10500 дата создания раньше , чем у лида с ID 10450, — одна из дат изменена. Сами номера подделать при обычной работе нельзя, а даты — можно. Методика в четыре шага: Выгрузите лиды за период с полями ID и «дата создания». Отсортируйте по ID. Дата создания обязана расти вместе с ним (с точностью до секунд одномоментных загрузок). Каждое место, где дата «проваливается назад» относительно соседей, — кандидат в сдвинутые. Снимите ту же выгрузку через сутки и сравните: записи, у которых дата изменилась между двумя снимками, — доказанные, а не гипотетические. У меня в один месяц таких оказалось 12,9%. Сдвиги были кратны восемнадцати часам и накапливались — то есть это был системный процесс, а не разовая правка руками. При отделе из 8 менеджеров и оценке потока лидов около 320 в месяц (по 10 лидов на менеджера в неделю, оценка) это дало примерно 41 сдвинутую запись. Источник в итоге нашёлся на стороне интеграций, но статья не о нём: в вашей CRM источник будет свой. Статья о том, что без ежедневного снимка данных вы этого не увидите никогда — сегодняшняя выгрузка всегда выглядит цельной, враньё видно только в сравнении со вчерашней. Разбивка сдвинутых записей по величине сдвига в моём случае выглядела так — я привожу её, чтобы показать: сдвиги не случайны, они группируются вокруг фиксированных интервалов, а это уже подпись конкретного процесса, а не шума. Величина сдвига Лидов (оценка) Доля от сдвинутых 18 часов 19 46% 36 часов 14 34% 54 часа и более 8 20% Итого сдвинутых 41 100% 18 часов — 19 лидов (46%) 36 часов — 14 лидов (34%) 54+ часов — 8 лидов (20%) Когда сверка по ID не сработает Метод с монотонными ID работает только там, где идентификатор — честный автоинкремент базы без переиспользования; в CRM с несколькими независимыми источниками ID (например, после миграции из старой системы) он даёт ложные срабатывания, и тогда нужен второй, внешний якорь. В Битрикс24 ID сделки или лида — автоинкремент на стороне базы, и в моём случае этого хватило. Но если у вас часть записей попала в CRM пачкой при переносе из другой системы, у них ID выданы задним числом одной партией — сверка по соседям покажет «провал» там, где на самом деле никакого воровства времени нет, это миграция. Отличить миграцию от систематической подмены несложно: у мигрированных записей сдвиг привязан к одной календарной дате у множества записей сразу — это ровно причина «migration» в промпте классификатора выше, а не «integration». Второй якорь, который я в итоге завёл параллельно с ID, — время прихода вебхука от формы на сайте. Оно логируется на стороне сайта, до Битрикс24, и задним числом его переписать некому. Сравнение «дата создания в CRM» против «время вебхука» ловит те случаи, где ID почему-то не монотонен или счётчик был сброшен. Если в вашей CRM нет ни надёжного автоинкремента, ни внешнего лога прихода лида — доказать прошлые сдвиги задним числом не получится вообще: остаётся только начать копить ежедневные снимки с сегодняшнего дня и ждать первого расхождения. ИИ-связка: классификация причины сдвига Как только сторож находит расхождение, второй вопрос — почему оно возникло: техническая интеграция, ручная правка менеджером или миграция данных. LLM здесь не заменяет разбирательство, а сортирует находки по вероятной причине, чтобы не тратить время инженера на каждую запись вручную. Схема простая: ежедневный diff двух снимков (получен через Битрикс24 REST API, метод crm.lead.list с полями ID и DATE_CREATE ) отдаётся модели пачкой, модель размечает вероятную причину и уверенность. Дальше инженер смотрит только записи с низкой уверенностью или с новой, ранее не встречавшейся причиной. Пример ответа модели на этот вход: Уверенность ниже 0,7 — сигнал руками проверить запись, а не доверять разметке. За месяц у меня таких пограничных случаев было около 15% от всех сдвинутых — терпимо для одного просмотра раз в неделю. Сторож: ежедневный снимок и сравнение Решение скучное и работает: раз в сутки автоматически снимается срез базы (ID, дата создания, стадия, ответственный, источник) и сравнивается с предыдущим снимком. Любое изменение задним числом попадает в отчёт: какая запись, что было, что стало. Инженерная обвязка минимальна: Забор данных: Битрикс24 REST API, вебхук на crm.lead.list с полями ID, DATE_CREATE, STAGE_ID, ASSIGNED_BY_ID, SOURCE_ID , постранично, раз в сутки по cron. Хранение: отдельная таблица (Google Sheets на старте, потом можно в PostgreSQL) — одна строка снимка на лид на дату среза. Сравнение: скрипт сопоставляет вчерашний и сегодняшний снимок по ID, находит расхождения в DATE_CREATE , формирует список. Сигнал: расхождения — в чат руководителю (Telegram-бот или системное сообщение в Битрикс24), не в лог-файл, который никто не открывает. Важно, куда идёт сигнал. Отчёт сторожа должен приходить туда, где его увидят, а не лежать в папке. Автоматизация, за которой надо ходить самому, не работает — сторож без громкого сигнала превращается в ещё один непрочитанный лог. Экономика: во что это выливается в деньгах Настройка сторожа заняла у меня около 6 часов (вебхук, скрипт снимка, сравнение, алерт), эксплуатация — около 300 ₽/мес (хранение снимков и вызовы API), эффект — около 31 000 ₽/мес (оценка). Расчёт по частям, чтобы не путать поток с запасом. Без сторожа РОП и финансист тратят на ручную сверку нестыкующихся отчётов около 4 часов в неделю на двоих — это 16 часов в месяц. При ставке около 1 000 ₽/час (оценка) это 16 000 ₽/мес чистого потока, который сторож экономит, потому что расхождение видно сразу, а не находится на планёрке методом «пересчитай ещё раз». Второй кусок эффекта — точность бонусов. При отделе из 8 менеджеров и 50 сделках в месяц по 180 тыс. ₽, если 12,9% лидов имеют недостоверную дату, это касается примерно 6 сделок в месяц (50 × 0,129 ≈ 6,45, округляю вниз), у которых стадия или срок в отчёте может быть посчитан неверно. На практике это выливается примерно в один неверно рассчитанный бонус в месяц — переплата или недоплата менеджеру около 15 000 ₽. Это не разовая находка, а повторяющаяся ошибка, которую сторож устраняет каждый месяц, поэтому её тоже можно складывать в поток: 16 000 + 15 000 = 31 000 ₽/мес. Что мы не считаем эффектом: сами 6 сделок на 1 080 000 ₽ оборота (6 × 180 000) — это не найденные и не потерянные деньги, а объём выручки, отчётность по которому раньше была в «серой зоне» неопределённости. Сторож не увеличивает выручку и не находит пропавшие сделки — он снимает неопределённость в её учёте. Складывать эту сумму с 31 000 ₽/мес было бы смешиванием запаса с потоком. Отдельно: точность бонусов — заслуга не только сторожа, а связки «сторож + пересмотр методики расчёта премии на снимке, а не на live-базе». Вклад одного сторожа в эти 15 000 ₽ отдельно не выделить, честнее говорить о комплексе мер. Что это меняет в отчётности Главное следствие: метрики периода нужно считать по снимку на дату закрытия периода, а не по живой базе — иначе прошлое продолжит меняться у вас под ногами. Правило Дашборд на непроверенных данных опаснее отсутствия дашборда. Красивая цифра придаёт уверенность — в том числе неверную. Аудит достоверности — обязательный первый этап любого проекта отчётности, и за годы работы с CRM я не видел ни одного аудита, который не нашёл бы расхождений. Практические следствия для отдела на 8 менеджеров и 40 человек в компании: метрики периода считать по снимку на дату закрытия периода, а не по живой базе; в отчёте показывать расхождения как расхождения, а не выбирать «правильную» цифру молча; любую интеграцию, у которой есть право писать в CRM, считать подозреваемой по умолчанию и логировать её правки; премии и KPI менеджеров пересчитывать по зафиксированному снимку, а не по текущему состоянию базы на момент выплаты. Отдельный разговор — как это преподнести команде, которая привыкла доверять цифре на экране. Я не пытался доказывать правоту на планёрке словами: показал два скриншота одного и того же отчёта за один период, снятых с разницей в неделю, и разницу в конверсии на них. После этого вопросов «а точно ли это баг» не осталось — расхождение видно глазами без единого слова про API и снимки. И общее: прежде чем строить на данных CRM что-либо умное — ИИ-отчёты, прогнозы, мотивацию — потратьте вечер на проверку монотонности дат. Это самый дешёвый аудит из всех возможных, и он регулярно окупает себя одним найденным сдвигом. Чек-лист понедельника Всё внедряется за один рабочий день, без дополнительного бюджета на инструменты — только время инженера или аналитика. Выгрузить лиды за последний месяц с полями ID и «дата создания», отсортировать по ID. Найти места, где дата «проваливается назад» относительно соседей по ID, — это кандидаты. Снять повторную выгрузку через сутки и сравнить с первой — подтвердить реальные сдвиги. Настроить ежедневный снимок через Битрикс24 REST API (метод crm.lead.list ) и cron-задачу. Написать скрипт сравнения снимков и алерт в мессенджер при найденном расхождении. Договориться с РОПом и финансистом, что метрики периода считаются по зафиксированному снимку на дату закрытия, а не по live-базе. Проверить, какие интеграции имеют право писать в CRM, и включить логирование их правок. Если после этого списка сторож за неделю не нашёл ни одного сдвига — тоже результат: у вас чистые данные, и это стоило проверить, а не считать само собой разумеющимся. И назову вещь своим именем. Сомневаться в собственных данных — это управленческий навык, такой же обязательный, как умение читать отчёт о прибылях и убытках. Руководитель, который перед решением спрашивает «откуда эта цифра и менялась ли она с прошлой недели», стоит дороже руководителя, который принимает экран за истину. Осваивается навык за один вечер сверки — а работает потом годами. Ваша проверка: снимите один и тот же отчёт дважды с разницей в две недели и сравните построчно. Если цифры разошлись — вы нашли то же, что нашёл я, и дальше вопрос только в масштабе. Как поставить контроль достоверности данных — в бесплатном курсе . ## Рентабельность направления: посчитать, пока оно не съело прибыль URL: https://davidgerstein.pro/blog/unit-ekonomika-napravleniya/ Дата: 2026-08-08 Направление: Стратегия Цифры: внедрение 14–22 часа · экономия 7–8 часов в месяц · окупаемость 2–3 месяца Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы можете назвать маржу компании, но не можете назвать рентабельность каждого направления отдельно — вы прямо сейчас кормите одно направление из прибыли другого и не знаете, какое именно. Проверьте себя за минуту: сколько вы зарабатываете на одном клиенте в каждом направлении? Не в среднем по компании — по направлениям, по отдельности. Средняя цифра по компании — самая опасная в управлении: она прячет направления, которые вы кормите из прибыли других. Я сам кормил одно почти год и был уверен, что оно «в целом нормально работает». Моя ошибка была не в арифметике — я ни разу не разнёс расходы по направлениям и считал общую маржу достаточным основанием для решений. Собственник компании на встрече с руководителем говорит прямо: «Ты должна знать юнит-экономику каждого направления как свои пять пальцев. Сколько зарабатываем, какая маржа, какие точки бизнеса. Это база, база, база. Любой финансовый директор знает всю эту юнит-экономику. Все». Через несколько недель у другой компании из той же группы другая картина: 30 прилётов в месяц, просадка по закрытию счетов, денег нет ни на рост продаж, ни на удержание уровня прошлого месяца. Зарплату платят с налогового резерва. Это две стороны одной проблемы, и обе стоят денег прямо сейчас. Если руководитель не знает маржу направления, он либо хвалит канал, который уже съедает прибыль, либо режет тот, что кормит остальных — вслепую, без цифр. Возьмём условный, но типичный случай для иллюстрации: производство на заказ, отдел из 6 менеджеров, средний чек 200 000 ₽, оборот направления около 4 млн ₽ в месяц — то есть примерно 20 сделок. Из них 10% зависает на неизвестной стадии — просто потому что никто не считает по направлению и не видит, где они застревают. Формула для прикидки своего случая: количество сделок в работе × средний чек × доля зависших без объяснения = ежемесячные потери от непрозрачности воронки. В нашем примере это 20 сделок × 200 000 ₽ × 10% = 400 000 ₽ в месяц — около 10% оборота направления (оценка, консервативно, без учёта возможного повторного возврата части сделок). Юнит-экономика бизнеса — не отчёт для инвестора раз в квартал, а ответ на вопрос «мы зарабатываем или проедаем» по каждому направлению отдельно, а не в среднем по компании. Как посчитать рентабельность направления Разнести по направлению его прямые и постоянные расходы, посчитать маржу с одной сделки и вывести точку безубыточности: постоянные расходы направления ÷ маржа с единицы. На направлении с постоянными расходами 800 000 ₽ и маржой 80 000 ₽ со сделки это 800 000 ₽ ÷ 80 000 ₽ = 10 сделок в месяц: девятая ещё не окупает направление, десятая выводит в ноль, и только с одиннадцатой направление зарабатывает. Главная ловушка — считать по сумме подписанных договоров вместо фактических поступлений: расхождение доходит до 60%, и рентабельность направления получается нарисованной. Почему рентабельность направления не видна в средней цифре по компании Разберём на примере, который повторяется почти везде: два направления с разной экономикой, усреднённые в один показатель. Скорее всего, вы узнаете в нём свою компанию. Общая выручка группы компаний может расти, а конкретное направление — тянуть всё вниз. Руководитель крупнейшего подразделения с внушительным штатом пришла с претензией: она отвечает за производство, логистику, апсейлы, нагрузка растёт, план выполняется — а процент от прибыли у неё самый маленький в компании. Собственник возразил: процент зависит не от выручки, а от затрат на управление подразделением. Спор остался открытым, потому что ни у одной из сторон не было цифр по юнит-экономике именно этого направления — только общие ощущения «я много делаю» и «у тебя больше расходов». Это типичная точка разрыва. Пока нет расчёта по направлению — маржа, постоянные расходы, точка безубыточности отдельно от остальной компании — спор о справедливости превращается в спор о характере. С цифрами он превращается в переговоры об изменении условий. Где путаются цифры чаще всего В одной из компаний план стратегии предполагал выручку в год, а в реальный план заложили сумму почти в два с половиной раза меньше. Разница возникла и причина не в ошибке расчётов: просто не договорились о терминах. Речь шла о сумме подписанных договоров или о фактических авансовых платежах, которые составляют 37–40% от суммы договора. Это не мелочь. Это разные деньги, разные кассовые разрывы и разная реальная маржа направления. Где ломается расчёт Юнит-экономика считается неправильно не потому, что кто-то плохо считает, а потому что термины не выровнены между отделами. «Выручка» у маркетинга, «выручка» у финансиста и «выручка» у собственника — три разных числа, если заранее не договориться, что именно считается: договор, аванс или фактическое поступление. Точка безубыточности: считайте до того, как радоваться росту Рост убыточного направления делает вам хуже, а выглядит как успех. Проверьте, нет ли у вас такого. В одной из компаний группы обсуждали точку безубыточности — чтобы её пройти, не хватало ещё 350 000 ₽. При этом на счетах на момент встречи было собрано более 1,2 млн ₽. На первый взгляд цифры не бьются: почему тогда вообще речь о нехватке денег? Разгадка в том, что это разные метрики — порог по конкретному расходному циклу или проекту против совокупных поступлений за более длинный период или по другой статье. Без единой методологии их нельзя класть рядом, а на встречах их кладут именно так: «у нас же собрано гораздо больше, при чём тут этот порог». Это ровно та ловушка, о которой шла речь выше: пока не зафиксировано, что именно стоит за каждым числом — период, статья, направление — сравнивать их бессмысленно, даже если оба числа верны каждое по отдельности. Точка безубыточности направления считается просто: постоянные расходы направления делятся на маржу с единицы. Пример на условных цифрах (для иллюстрации формулы, не из кейса): если постоянные расходы направления — 800 000 ₽ в месяц, а маржа с одной сделки составляет десятую её часть — 80 000 ₽, точка безубыточности — 10 сделок в месяц. Девятая сделка ещё не окупает направление, десятая — только выводит в ноль, и лишь начиная с одиннадцатой направление зарабатывает. Сложность не в формуле, а в том, чтобы честно разнести расходы. Если аренда, зарплата бэк-офиса и часть маркетинга не распределены по направлениям, а висят «на компании в целом», точка безубыточности каждого направления будет занижена — и решение о его судьбе примут на основе неверных цифр. Схема мотивации руководителя направления Диапазон дохода в месяц Что показывает Процент от прибыли направления от низкого до среднего уровня, разброс почти в пять раз Реальную волатильность юнит-экономики: выручка компании колеблется в разы от месяца к месяцу Фиксированный оклад стабильный уровень выше среднего, узкий коридор Стабильность для сотрудника, но отрывает мотивацию от фактической рентабельности направления На диаграмме — та же вилка дохода наглядно: как процент от прибыли сильно колеблется, а фиксированный оклад держится в узком коридоре. Мин. доход, % от прибыли низкий уровень Макс. доход, % от прибыли почти в пять раз выше Фикс. оклад, низ вилки выше среднего Фикс. оклад, верх вилки чуть выше низа вилки Разброс почти в пять раз у одного и того же руководителя производственного отдела — это не каприз системы мотивации, это честное отражение того, что юнит-экономика направления нестабильна. Собственник обсуждал переход на фиксированный оклад именно потому, что предсказуемость дохода важнее для человека, чем точное соответствие вкладу. Но фиксированный оклад снимает главный смысл расчёта юнит-экономики — если руководитель получает одно и то же независимо от маржи направления, у него нет стимула её считать и оптимизировать. Механика расчёта: что → чем → куда Разложите свои направления по этой схеме — вам понадобится выгрузка по выручке и понимание, какие расходы вы относите к прямым. Расчёт юнит-экономики направления — это не разовая аналитическая сессия, а еженедельный цикл. Вот как он выглядит по шагам, чтобы его можно было повторить с любой командой: Что. Каждую сделку и каждый расход помечают направлением (продукт, рынок, канал) — не «на компанию», а конкретно. Источник данных — CRM (Bitrix24 или amoCRM) плюс таблица расходов, которая обычно ведётся отдельно от CRM. Чем. Раз в неделю, в фиксированный день, данные выгружаются в единую таблицу — вручную или через вебхук. В одной из компаний выбрали четверг: результаты недели копятся к этому дню и сводятся в отчёт по трём блокам — маркетинг, продажи, авансы. Куда. Свод попадает в Google Таблицу с формулами точки безубыточности по каждому направлению: постоянные расходы направления ÷ маржа с единицы. Формула, а не фиксированное число — чтобы не пересчитывать вручную каждый раз, когда меняются вводные. Кто смотрит. Руководитель направления — каждый четверг, до общей планёрки. Собственник или финдиректор — раз в месяц, сравнивая тренд, а не разовое значение. Без честного разнесения расходов по направлениям весь расчёт превращается в фикцию. Показательный случай: в одной из компаний SEO-специалист не смог назвать источники лидов из органического поиска — а значит, аналитика не связывает запросы, страницы и продажи, и юнит-экономику канала посчитать просто не из чего. Похожая проблема разбирается в статье про разрыв между маркетингом и продажами . ИИ-связка: сбор и первичный анализ Когда вы посчитали руками один раз и поняли структуру, сборку стоит отдать машине: ваша ценность в выводах, а не в складывании столбцов. Ручной свод раз в неделю занимает у аналитика или ассистента руководителя 2–3 часа: выгрузить сделки из CRM, сверить с таблицей расходов, найти нестыковки терминов («договор» вместо «аванс»), пересчитать маржу по направлениям. Это рутина, которую можно передать модели — но не для принятия решений, а для подготовки черновика отчёта, который потом проверяет человек. Схема конвейера: CRM (Bitrix24/amoCRM) → еженедельный вебхук выгружает сделки за неделю в JSON → скрипт на Google Apps Script объединяет их с таблицей расходов по направлениям → дешёвая модель (уровня GPT-4o-mini) классифицирует записи и считает точку безубыточности по формуле → черновик отчёта падает в Google Sheets и дублируется в Telegram-канал руководителя → человек проверяет цифры перед четверговой встречей. Дешёвая модель здесь оправдана: задача — классификация и арифметика по заданной формуле, а не творческий анализ. Гонять через дорогую модель тысячи строк сделок ради пересчёта маржи — переплата без выигрыша в качестве. Дорогую модель имеет смысл подключать только на втором шаге — когда нужно объяснить руководителю аномалию человеческим языком, а не выдать сырые цифры. Пример входных данных, которые скрипт формирует из CRM-выгрузки и таблицы расходов (упрощённая структура для одного направления за неделю): Пример ответа модели, который ложится в таблицу без ручной доработки: Здесь видно, как работает формула на реальных числах: постоянные расходы направления делятся на маржу с единицы — получается 1,6. То есть направлению нужно закрыть меньше двух сделок в неделю, чтобы выйти в ноль по фиксированным расходам этой недели; всё сверху — вклад в прибыль. И сразу видно, почему нельзя было взять contract_sum вместо actual_payment: сумма по сделке 1042 почти вдвое больше фактического поступления — если бы модель считала по договору, точка безубыточности выглядела бы пройденной, хотя деньги ещё не пришли. Вот как этот черновик выглядит уже собранным — в виде отчёта в Google Таблице или Telegram-боте, который руководитель открывает в четверг утром: Отчёт: Направление B, неделя 2026-W32 100% факт. поступления за неделю (база расчёта) 50% маржа с одной сделки от поступлений 1,6 сделки до точки безубыточности Сделка Договор Факт. оплата Статус 1042 100% 40% расхождение 60% 1043 100% 100% закрыта Инженерная обвязка простая и без экзотики: вебхук из Bitrix24 настроен на событие «изменение стадии сделки», данные копятся в промежуточном листе Google Sheets, скрипт запускается по расписанию (Apps Script trigger, каждый четверг утром). Если вебхук не отработал или модель вернула невалидный JSON — бот в Telegram присылает сообщение «отчёт за неделю не собран, проверь вручную» вместо того, чтобы молча подставить пустые значения. Это критично: расчёт юнит-экономики, который тихо сломался и продолжает показывать старые цифры, опаснее, чем его отсутствие — про похожий сценарий тихой поломки я писал в статье про то, как CRM сдвигает даты незаметно для пользователя . Где ломается автоматизация расчёта Модель хорошо считает по формуле и плохо — угадывает, что имел в виду человек, если поля в CRM называются неоднозначно («сумма» без уточнения — договор или оплата). В одной из компаний ИИ-инструмент для стратегического планирования выдал убедительный прогноз, который не учитывал бонусы продаж и содержал необоснованные предположения о марже направления — их никто не сверил с фактическими данными из CRM, пока прогноз не разошёлся с реальностью на треть. Что даёт автоматизация, а что — сам факт расчёта Важное разделение для вас: большую часть эффекта даёт не автоматизация, а то, что вы вообще посчитали. Автоматизация лишь удерживает вас от того, чтобы бросить. Здесь важно не смешивать два разных эффекта. Первый — экономия времени от автоматизации сбора данных. Второй — деньги, которые видны только после того, как компания вообще начала считать юнит-экономику по направлениям отдельно. Это разные инициативы, и вклад каждой нужно оценивать по отдельности. Эффект автоматизации отчёта. Внедрение конвейера (вебхук + скрипт Apps Script + промпт для модели) занимает 14–22 часа работы аналитика или разработчика (оценка). При ставке около 1 000 ₽/час это 14 000–22 000 ₽ разовых затрат. Дальше еженедельный свод, который раньше занимал 2–3 часа вручную, сводится к проверке готового черновика — экономия 7–8 часов в месяц (оценка). При той же ставке это 7 000–8 000 ₽/мес. Окупаемость по этой оценке — 2–3 месяца, если считать только экономию времени на сборе и своде данных, без учёта эффекта от самих решений, принятых на основе отчёта. Эффект от разделения расчёта по направлениям. Это отдельная инициатива — не заслуга автоматизации, а заслуга самого решения считать раздельно. Пример с начала статьи: отдел из 6 менеджеров, средний чек 200 000 ₽, около 20 сделок в работе в месяц, 10% зависает без объяснения на неизвестной стадии — это 400 000 ₽ риска в месяц (оценка, консервативно). Автоматизация не устраняет этот риск сама по себе — она делает его видимым каждую неделю, а не раз в квартал на разборе полётов. Устранять зависшие сделки всё равно должен человек: разобраться со стадией, поднять причину, вернуть сделку в работу или списать её честно. Статья Оценка Что это даёт Внедрение конвейера 14–22 часа × ~1 000 ₽/час = 14 000–22 000 ₽ Разовые затраты на настройку вебхука, скрипта и промпта Экономия на своде 7–8 часов/мес × ~1 000 ₽/час = 7 000–8 000 ₽/мес Освобождённое время аналитика, окупаемость 2–3 месяца Риск от непрозрачной воронки ≈ 400 000 ₽/мес (оценка) Не эффект автоматизации — эффект самого разделения расчёта по направлениям Ваш чек-лист на понедельник Шесть шагов, каждый на один подход. Ни один не требует от вас нового инструмента. Выписать все направления, продукты или рынки компании и проверить: есть ли по каждому отдельный расчёт маржи, а не общая цифра по компании. Договориться с финансистом и маркетингом о едином определении «выручка»: договор, аванс или фактическое поступление — и зафиксировать это письменно, а не на словах. Посчитать точку безубыточности хотя бы для одного направления по формуле: постоянные расходы ÷ маржа с единицы. Проверить, размечены ли сделки и расходы в CRM по направлениям — без этого ни ручной, ни автоматический расчёт не будет верным. Назначить фиксированный день еженедельной сверки (как четверг в примере) — до общей планёрки, чтобы цифры были готовы к обсуждению, а не собирались на ходу. Если решите автоматизировать сбор — начать с промпта и ручной проверки на одном направлении, а не сразу на всей компании. И ещё одно, ради чего всё это. Умение за час разложить бизнес на направления и сказать, какое кормит, а какое ест, — это отдельный управленческий навык, и его придётся освоить. Руководитель, который приходит к собственнику с рентабельностью по каждому направлению, стоит дороже руководителя, который приносит общую выручку и просит верить на слово. Навык осваивается один раз и работает потом всю карьеру. Сделайте на этой неделе: возьмите два своих направления и посчитайте по каждому доход и прямые расходы на одного клиента. Одна таблица, час. Результат обычно неприятный и всегда полезный. Как собрать этот расчёт так, чтобы он обновлялся сам, — в бесплатном курсе . Мой опыт с этим расчётом был отрезвляющим: одно направление, которое я считал перспективным, при честном подсчёте оказалось убыточным на каждом клиенте. Мы его закрыли — и высвободившиеся руки дали рост там, где экономика сходилась. Решение было очевидным ровно в тот момент, когда появились цифры, и невозможным до этого. ## Контроль дебиторской задолженности: три метрики вместо памяти двух человек URL: https://davidgerstein.pro/blog/debitorka-pod-kontrolem/ Дата: 2026-08-07 Направление: Финансы Цифры: лимит на порядок меньше нужного · долг перед поставщиком ~1,1 млн ₽ · дефицит кассы ~900 тыс ₽/мес Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Назовите три числа: сколько вам должны, сколько из этого просрочено и у кого самый большой долг. Не можете — значит, дебиторкой в вашей компании не управляет никто, и это не фигура речи. Если вы держите эти три числа в голове, а не в отчёте, — у вас не контроль, у вас память двух-трёх человек. Она работает ровно до отпуска, увольнения или просто загруженной недели. Дальше вы узнаёте о своих деньгах от того, кому не заплатили. Ниже — три метрики, которые закрывают этот вопрос, и способ собирать их без ручного свода каждую неделю. Что такое контроль дебиторской задолженности на практике Контроль дебиторской задолженности — это три числа, которые видны в системе каждый день и которые не нужно ни у кого запрашивать: общий объём долга клиентов, его распределение по срокам просрочки и распределение по пакетам услуг. Отчёт раз в месяц контролем не является: к моменту его выхода решение уже принято или упущено. Собирается это так: выгрузка сделок из CRM раз в сутки — дешёвая модель раскладывает долг по возрастным корзинам (0–30, 31–60, 61–90, 90+ дней) и по пакетам — сводка уходит в таблицу и в мессенджер ответственному. Ручной сбор тех же трёх метрик занимает у финансиста 1–1,5 часа в день, то есть 20–30 часов в месяц; конвейер оставляет 5–6 часов в месяц на сверку и разбор аномалий. Клиент внёс предоплату в криптовалюте, компания получила сумму с небольшой наценкой сверху. Через пару недель клиент потребовал вернуть всё в течение дня, сославшись на обещание менеджера. Руководитель вернул большую часть, удержав расходы и бонус — чтобы не судиться. Контроль дебиторской задолженности в этой истории свёлся к ручному разбору задним числом: никто заранее не зафиксировал условия возврата, и решение принималось в режиме тушения пожара, а не по правилу. Похожая история с реферальной программой: партнёры узнавали о своих вознаграждениях только тогда, когда клиент сам просил вернуть деньги. Информация задерживалась, потому что никто не был обязан передавать её вовремя. Оба случая не про мошенничество и не про злой умысел. Просто дебиторка живёт в головах у людей, а не в системе — и всплывает, только когда кто-то начинает нервничать. Цена такой памяти реальна: пока финансист вручную собирает данные о долгах по полтора часа в день, компания фактически держит под это отдельную скрытую штатную единицу — цифры в разделе «Экономика» ниже. Три метрики, которые закрывают вопрос Мы пришли к ним не сразу: сначала я пытался смотреть общую сумму долга — и это оказалось бесполезно, потому что сумма ничего не говорит о сроках и о том, где рвётся. Скажу как есть: я не понимал этого почти год. У меня была общая цифра, и мне казалось, что раз цифра есть — дебиторка под контролем. Это моя ошибка, и вылезла она ровно там, где было больнее всего, — на апрельском разборе с поставщиком. Так что если вы сейчас смотрите на одну сумму и считаете это контролем — здесь ошибаются почти все, просто не все потом об этом рассказывают. Заведите их у себя в таком виде — и вы будете знать о проблеме за две недели до того, как она станет проблемой. После разбора подобных случаев в задачи руководителя отдела добавили обязанность ежедневно отслеживать три показателя: общий объём дебиторской задолженности, её распределение по срокам возникновения и распределение по пакетам услуг. Не отчёт раз в месяц, а цифры, которые видны в системе постоянно. Смысл не в самих цифрах, а в том, что их не нужно запрашивать. Раньше вопрос «сколько нам должны и с какого числа» требовал звонка финансисту и получаса ожидания. Теперь это строка в отчётности. Разница кажется мелкой, пока не наступает момент, когда решение нужно принять за полчаса, а не за день — как в истории с платежом подрядчику, который просили провести «прям буквально за полчаса». Метрика Зачем нужна Что показывает Объём дебиторки общий риск кассового разрыва сколько денег «зависло» у клиентов прямо сейчас Распределение по срокам приоритет для взыскания какая часть долга уже критична, а какая в пределах нормы Распределение по пакетам услуг связь долга с продуктом какие услуги систематически не оплачиваются вовремя Третья метрика часто недооценена. Если долг концентрируется вокруг одного пакета услуг, проблема не в клиентах, а в условиях продажи этого пакета: слишком длинная отсрочка, неудобная схема оплаты или обещания на этапе продажи, которые потом не выполняются менеджером, а расхлёбывает финансовый отдел. Клиенты не платят вовремя — или вы сами создаёте разрыв Неприятная часть: половина просрочек в компаниях, которые я разбирал, создавалась внутри — счёт выставили поздно, акт не подписали, реквизиты сменились. Проверьте свою сторону, прежде чем звонить клиентам. Компания продавала проектную услугу с маржинальностью 25–30%, но с циклом в три месяца до получения платежа от клиента. Расходы на выполнение работы приходилось авансировать заранее, а резервов под этот цикл не откладывали. В апреле это вылилось в конкретную ситуацию: лимит расходов оказался на порядок меньше фактической потребности. Итог — долг перед поставщиком услуг на ~1,1 млн ₽. Показательна и попытка обосновать увеличение лимита: сотрудник, который просил поднять фонд примерно в полтора раза, не смог ответить ни на один вопрос о юнит-экономике — сколько компания заработает на эти деньги. Руководитель отказал в согласовании и потребовал прийти с расчётом, а не с фразой «мы тратим больше, нам не хватает». Это тот же принцип, что и три метрики выше: без цифры, которую видно постоянно, любое решение о деньгах превращается в спор на веру. После разбора договорились откладывать 30% от прибыли на резервы. Формально проблема решена, но по факту это отложенное решение: пока резерв не накопится, разрыв между расходом и платежом клиента остаётся дырой в кассе, которую латает кто-то другой — либо личными деньгами, либо кредитом. Похожая логика в другой истории: финансовый директор распределил около 35% месячной прибыли между сотрудниками, но в тот же период не хватило денег на оплату рекламы. Коллеге пришлось вносить личные средства. Разбор показал: кассовый разрыв был виден за месяц-два до проблемы, но никто не смотрел на цикл поступлений системно — резерв на маркетинг не формировался никогда. факт. лимит нужный объём На диаграмме — разрыв между фактическим лимитом фонда в апреле и реальной потребностью по объёму работ, из которого вырос долг перед поставщиком. Правило Прибыль, которую можно распределить, и деньги, которые физически лежат на счёте, — разные вещи. Если резерв под цикл поступлений не выделен заранее, распределение прибыли на бумаге создаёт кассовый разрыв на практике. Это управленческая мера, и никакая автоматизация отчётности её не заменяет. Предоплаты и рассрочки: где чаще всего рвётся у вас Три места, в которых теряются деньги даже у аккуратных компаний. Проверьте каждое. История с возвратом криптовалютной предоплаты показала слабое место: возвраты вообще никак не фиксировались. Формулировка, прозвучавшая при разборе, была прямой: «Возвраты абсолютно никак не фиксируются, никто никак не ведёт, никто не отвечает. Нужен инструмент, нужен регламент». Это не редкость — предоплаты и рассрочки часто учитываются в момент получения денег, но не в момент их возможного возврата. Рассрочки и предоплаты учёт требуют минимум трёх вещей, зафиксированных письменно ещё до конфликта: сумма, курс или условия на момент получения — особенно если оплата в нестандартной форме условия возврата: полная сумма, за вычетом расходов, в какой валюте и в какой срок кто отвечает за фиксацию возврата и куда он записывается Без этого регламента каждый возврат превращается в отдельные переговоры, где условия придумываются на ходу — как в случае с криптовалютой, где решение принималось «чтобы избежать судебного разбирательства», а не по заранее известному правилу. Когда начислять бонус — за договор или за платёж Смежная тема — мотивация продавцов. Возник конфликт: один участник хотел начислять бонус в момент заключения договора, не дожидаясь платежа. Другой указывал, что есть второй финансист, который отслеживает расхождения и докладывает руководству. Решение приняли простое: бонус — по факту получения платежа, а не по факту подписания договора. Это прямо связано с дебиторкой. Если платить за договор, у продавцов пропадает стимул следить за тем, оплатил клиент вовремя или нет — сделка для них уже закрыта. Если платить за платёж, интерес совпадает с интересом компании: чем быстрее клиент заплатит, тем быстрее продавец получит бонус. Платёжная дисциплина — не только про клиентов Ваша собственная дисциплина работает так же: если вы платите поставщикам как получится, вы учите рынок, что с вами можно так же. Дебиторка обычно ассоциируется с должниками-клиентами. Но платёжная дисциплина ломается и внутри компании, причём с похожими последствиями. В мае финансирование части рекламных кампаний задержали. Площадки, которые работают по предоплате, начали хуже отрабатывать бюджет — это классический эффект дисциплины наоборот: не клиент не заплатил компании, а компания не заплатила вовремя партнёру, и это тоже ударило по деньгам. Ещё пример — перенесённые платежи, которые требовали повторного ручного инициирования вместо автоматической обработки. Платёж, согласованный на понедельник, не прошёл, и компания оказалась в риске остановки рекламной кампании из-за нехватки средств на счёте. Причина не в отсутствии денег, а в том, что перенос платежа выпал из процесса — его никто не проконтролировал повторно. Похожая проблема с искажением данных встречается и в CRM: в одной из компаний даты создания лидов самопроизвольно менялись при синхронизации, сдвиг доходил до 36 часов. Разбор этого случая — в статье о том, как CRM врёт данными и как сверять их по ID . Принцип тот же, что и с дебиторкой: если данные не сверяются регулярно и автоматически, ошибка накапливается тихо, пока не превращается в кассовый разрыв или сорванную сделку. ИИ-связка: сбор метрик без ручного свода Когда вы поймёте, на что смотрите каждую неделю, отдайте сбор машине: ваша задача — решения, а не выгрузки. Три метрики из первого раздела можно собирать вручную — и почти все компании так и делают, пока не набьют шишку. Но задача рутинная, объём данных большой (сотни строк в день), а логика простая: разложить сделки по срокам и пакетам, найти аномалии. Это ровно тот случай, где дорогая модель не нужна — нужен дешёвый конвейер, который не забывает. Схема конвейера: Bitrix24 (источник сделок) → вебхук выгружает JSON раз в сутки → дешёвая модель агрегирует и ищет аномалии → результат пишется в Google Sheets и дублируется в Telegram ответственному → раз в неделю финансист смотрит сводку на планёрке. Один нюанс, который часто ловят на практике: брать дату не из поля, которое может «сдвигаться» при синхронизации CRM (см. историю с датами лидов), а из версионной истории сделки — иначе распределение по срокам будет врать так же, как врали даты создания лидов. Пример ответа модели: Сводка по дебиторке — Google Sheets 100% общий долг в рублях (база) ~1% долг в евро от рублёвого эквивалента 5% просрочка 90+ дней от общего долга 34% доля просрочки в Пакете B Пакет Доля долга Статус Пакет A 38% норма Пакет B 62% аномалия 90+ На мокапе — та же сводка, что модель отдаёт в JSON выше, но так, как она ляжет в лист Google Sheets и попадёт в Telegram ответственному. Модель здесь — дешёвая (класса mini): задача не творческая, а структурная агрегация с фиксированной схемой JSON, дорогая модель тут даёт тот же результат за большую цену. Дорогую модель имеет смысл подключать отдельным шагом — раз в неделю, чтобы она писала текстовое резюме для планёрки поверх готовых цифр, а не пересчитывала сама агрегацию. Инженерная обвязка: вебхук Bitrix24 запускает выгрузку по расписанию (Google Apps Script или n8n), передаёт JSON в модель по API, результат пишется в Google Sheets отдельным листом с датой запуска. Если ответ модели не парсится как JSON или вебхук не получил данные — скрипт не падает молча, а шлёт сообщение в Telegram-бот ответственному финансисту с текстом ошибки и временем сбоя. Повторный запуск — через час, автоматически, без ручного перезапуска. Механика целиком — в разборе автоматизация финансовой модели . Отдельный вопрос — что именно улетает в модель. Суммы долга и связку с пакетом услуг обычно можно передавать без персональных данных клиента, если убрать имя, телефон и e-mail до отправки. Что можно, а что нельзя отправлять во внешний ИИ-сервис — разбирали отдельно в статье про персональные данные и нейросети . Где ломается Автоматическая выгрузка не заменяет присмотр. Если поле даты в CRM «плывёт» при синхронизации, конвейер честно посчитает неверные корзины по срокам — и выдаст красивый, но лживый отчёт. Обязательна еженедельная сверка агрегата с сырыми данными вручную, хотя бы выборочно. Экономика: сколько стоит контроль дебиторской задолженности Ваши затраты — час в неделю на разбор списка. Отдача — деньги, которые приходят вовремя, и разговоры с клиентами, которые ведутся до просрочки, а не после. Настройка конвейера — 8–16 часов работы разработчика (12 000–24 000 ₽ разовых при ставке ~1 500 ₽/час), эксплуатация — около 3 000 ₽/мес на дешёвую модель, эффект — экономия примерно 15 000–20 000 ₽/мес на времени финансиста (оценка). Дальше — как получена эта цифра и что в неё не входит. Финансист тратит на ручной сбор трёх метрик 1–1,5 часа в день — это 20–30 часов в месяц при обычных 20–22 рабочих днях. При ставке ~1 000 ₽/час с учётом налогов это 20 000–30 000 ₽ скрытых трудозатрат в месяц. Автоматизация выгрузки и агрегации снимает большую часть рутины — реалистично освобождается 70–80% этого времени, то есть остаётся 5–6 часов в месяц на еженедельную сверку и разбор аномалий, это 5 000–6 000 ₽ по той же ставке. Чистая экономия — 15 000–20 000 ₽ в месяц. При разовых затратах на внедрение в 12 000–24 000 ₽ конвейер окупается за первый-второй месяц эксплуатации — это консервативная прикидка, а не гарантия. Для сравнения масштаба: похожая по трудозатратам, но точечная задача — уведомление партнёра о закрытии проекта через бота — заняла всего 20 минут (подробности в разделе «Что реально сработало» ниже). Это разные по масштабу вещи: 20 минут закрыли одну дыру, а не выстроили систему контроля дебиторки целиком. Подробный разбор реальных счетов за похожие сценарии с дешёвыми моделями — в статье сколько на самом деле стоит ИИ в месяц . Показатель Вручную С автоматизацией Время на сбор метрик, в день 1–1,5 часа 15–20 минут на сверку сводки Время в месяц 20–30 часов 5–6 часов Стоимость при ставке ~1 000 ₽/час 20 000–30 000 ₽ 5 000–6 000 ₽ Абонентка на модель — ~3 000 ₽/мес Итоговая экономия 15 000–20 000 ₽/мес Формула для своего случая словами: возьмите часы ручного сбора метрик в день, умножьте на число рабочих дней в месяце (обычно 20–22), умножьте на часовую ставку сотрудника с учётом налогов — получите скрытые трудозатраты в месяц. Из этой суммы вычтите оставшееся время на еженедельную сверку (1–2 часа в неделю) и абонентку на модель (~3 000 ₽/мес) — получите чистую экономию. Ставка «типового» сотрудника у всех разная: например, в одной из компаний реальная стоимость часа сотрудника с учётом налогов доходила лишь до 40% от грубой отраслевой оценки для роли финансиста. Подставляйте свою ставку, а не чужую — иначе экономия в расчёте окажется мнимой. Я в своё время подставил отраслевую и получил красивую экономию, которой в кассе не было. Что не считаем эффектом: ускорение получения денег от клиента (когда компания раньше видит проблему и раньше требует оплату) — это разовый запас, ускорение оборотного капитала в конкретном месяце, а не повторяющийся ежемесячный поток. Его нельзя складывать с экономией часов финансиста и нельзя умножать на число месяцев — это разные по природе величины. Отдельно от экономии часов стоит риск, который автоматизация не снимает — только делает видимым раньше: в кейсе с проектной услугой дельта между лимитом и потребностью составила почти весь объём нужных средств, а результатом стал долг перед поставщиком на ~1,1 млн ₽. Важно не смешивать два эффекта в одной сумме: экономия времени финансиста — это эффект автоматизации отчётности, а избежание долга — это эффект управленческого решения о резервировании 30% прибыли. Первое можно посчитать в часах за месяц, второе закрывается только резервом, а не отчётностью — конвейер лишь показывает проблему за недели, а не в момент, когда поставщик уже требует деньги. Кейс В чём разрыв Цена вопроса Проектная услуга цикл 3 месяца, резерв не формировался долг перед поставщиком ~1,1 млн ₽ Маркетинговый бюджет прибыль распределили раньше, чем закрыли резерв коллеге пришлось вносить личные деньги Средний месяц компании расходы заметно превышали выручку дефицит кассы ~900 тыс ₽/мес Реферальная программа партнёр узнавал о вознаграждении по запросу клиента риск конфликта и репутации, устранён за ~20 мин работы Долг перед поставщиком ~1,1 млн ₽ Дефицит кассы за месяц ~900 тыс ₽ Дельта лимита (проектная услуга) почти весь нужный объём На диаграмме — три ключевых разрыва из кейсов статьи: они разного происхождения, но одинаково следуют из отсутствия резерва под цикл поступлений. Что реально сработало у нас Из всего списка мер вам стоит начать с одной — той, что дала больше половины эффекта. Одно решение с реферальной программой оказалось дешёвым и быстрым: настроить в боте автоматизацию уведомлений о закрытии проектов рефералов, чтобы вознаграждение выплачивалось сразу, а не после того, как клиент сам напомнит о деньгах. На это ушло около 20 минут работы. Это не решает всю проблему дебиторки, но убирает конкретную точку, где задержка возникала регулярно и предсказуемо — и её эффект нужно оценивать именно так, отдельно от резервной политики компании. Второе рабочее решение — перенос времени финансового планирования с утра на 13:00 четверга, чтобы к моменту принятия решений данные успевали собраться и проанализироваться полностью. Звучит как мелочь, но именно из-за нехватки полных данных утром принимались решения по неполной картине — а дебиторка и кассовые разрывы почти всегда обнаруживаются постфактум именно из-за такого разрыва во времени между сбором данных и решением. Здесь важна честность: я сам сначала полез строить конвейер и только потом увидел, что больше половины эффекта дали перенос совещания и один регламент на страницу. Оба решения — организационные, не про автоматизацию. ИИ-конвейер из предыдущего раздела ускоряет сбор цифр, но не заменяет управленческое решение перенести совещание или настроить регламент возврата. Автоматизация без присмотра часто превращается во вторую работу — про эту ловушку подробнее в статье про автоматизацию, которая требует надзора . Ограничение Три метрики и конвейер работают только если источник данных (CRM) сам по себе не врёт. Если в CRM гуляют даты или сделки задваиваются, любая автоматическая сводка по срокам просрочки будет красивой, но неверной — сначала чините источник, потом ставьте отчётность поверх него. Чек-лист: с чего начать в понедельник Выгрузить текущий список сделок с непогашенной оплатой из CRM и вручную посчитать общий объём дебиторки — это база для сравнения с автоматическим отчётом. Завести три поля в CRM или таблице: сумма к оплате, дата по договору, пакет услуг — если их ещё нет как обязательных. Написать регламент возврата предоплат на одну страницу: сумма/курс на момент получения, условия возврата, кто отвечает за фиксацию. Проверить, привязан ли бонус продавца к платежу или к договору — если к договору, обсудить смену логики с отделом продаж. Настроить хотя бы одно автоматическое уведомление о просрочке (даже без ИИ) — например, письмо ответственному, если платёж не пришёл через 3 дня после срока. Назначить день и час недели, когда финансовые данные точно собраны, и планировать разбор дебиторки именно на это время, а не на утро по неполным цифрам. Что сделать в понедельник: соберите три метрики из этой статьи руками — один раз, на бумаге. Час работы даст вам картину, которой у вас, скорее всего, никогда не было. Автоматизацию поставите потом, когда поймёте, на что смотреть каждую неделю. Механика — в бесплатном курсе . И правило, которое я вывел для себя: разговор о деньгах с клиентом всегда легче до просрочки, чем после. До — вы уточняете сроки. После — вы требуете. Разница в тоне огромная, а определяется она одним: знаете ли вы о приближении срока заранее. Как это выглядело у нас Мы начинали с того, что дебиторку никто не смотрел системно: помнили пару крупных должников, остальное всплывало случайно. Первый же собранный список показал, что мелких просрочек больше, чем крупных, и в сумме они дают больше денег — просто их не видно поодиночке. Дальше мы сделали скучную вещь: назначили день недели, в который список смотрится, и человека, который его приносит. Никакой автоматизации на старте не было — обычная выгрузка и полчаса времени. Эффект пришёл в первый же месяц, и только потом мы отдали сбор машине. И назову вслух то, что обычно остаётся за скобками. Держать деньги под контролем через машину — это отдельный управленческий навык, и осваивать его придётся лично вам, а не вашему финансисту. Руководитель, который умеет собрать конвейер и читать его сводку за пять минут, стоит дороже руководителя, который умеет только спросить «сколько нам должны» и ждать полдня ответа. Ещё пару лет назад это было приятным дополнением к профессии. Сейчас это входной билет. Мой вывод: контроль дебиторки — это привычка, а не система. Систему можно купить, привычку придётся завести самому. Заведите эту привычку на этой неделе: назначьте день, назначьте человека, посмотрите первый список. Как автоматизировать сбор потом — в бесплатном курсе . ## Контроль работы менеджера в CRM — дашборд вместо штрафов и пустых карточек URL: https://davidgerstein.pro/blog/menedzhery-ne-vedut-crm/ Дата: 2026-08-05 Направление: Продажи Цифры: факт разошёлся с планом на пятую часть недельной выручки · конверсия 14% вместо 23% · +1 п.п. конверсии в месяц после контроля Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваши менеджеры не ведут CRM — не спешите вводить штрафы. Сначала ответьте себе на неудобный вопрос: а что менеджер получает от того, что заполнил карточку? Обычно ответ — ничего. Он тратит время, чтобы вам было удобно смотреть отчёты. С его стороны это чистые издержки, и любой нормальный человек будет их сокращать. За одну неделю условный отдел производственной компании недосчитался 200 000 ₽ выручки — план по деньгам выполнили лишь на четыре пятых. При плановой недельной выручке в 1 000 000 ₽ факт составил 800 000 ₽. Закрыли 7 сделок из 16 запланированных. Причина не в том, что менеджеры плохо разговаривали — во встречу конвертировалось 55% лидов (49 встреч), это нормальный показатель. Провал случился на следующем шаге: из встречи в договор дошло только 22% — притом что для выхода на плановую конверсию лид → продажа в 23% нужна была совсем другая цифра на этом шаге. При этом средний чек по факту оказался выше плана — 13,5% против плановых 10% — то есть часть провала по количеству сделок частично компенсировалась более крупными контрактами, но разрыв в выручке это не закрыло. Корень проблемы окажется банальным: менеджеры не вносят данные в CRM вовремя, и часть воронки просто исчезает из поля зрения. 10% 13,5% И когда руководитель полез разбираться, что происходит на шаге «встреча → договор», выяснилось: часть сделок просто зависла в статусе «переговоры» без даты следующего контакта, без комментария, без признаков жизни. Отдельно нашёлся клиент, который висел в воронке полтора года — без единого движения. Когда команда считала средний срок цикла сделки, эта одна карточка портила всю статистику: казалось, что цикл огромный, хотя на деле клиента просто забыли. Решение руководителя было быстрым — вынести его в отдельную воронку, чтобы не портил цифры. Это не решило проблему зависшего клиента. Это решило только проблему кривого отчёта. Этому посвящён отдельный материал: зависшие сделки в воронке . Оба случая — про одно и то же: менеджеры не вносят данные в CRM не из лени и не из саботажа. Систему никто не заставляет отвечать за пустую карточку — ни поощрением, ни последствием, ни даже понятным правилом, за что вообще отчитываться. Что делать, если менеджеры не вносят данные в CRM Начинать не со штрафов, а с двух колонок в отчёте — «дней в текущей стадии» и «дата последнего контакта» — плюс светофор по нормативному сроку каждой стадии. В разобранной неделе именно невидимые зависшие сделки стоили отделу 200 000 ₽: план по деньгам выполнили на 80%, закрыли 7 сделок из 16. Штраф за пустую карточку меняет поведение на день. Дашборд, который сам показывает застрявшую сделку, убирает саму возможность спрятать проблему. До включения любого контроля менеджерам нужно письменно объяснить, по каким критериям их оценивают, — иначе вы получите сопротивление, а не данные. Почему менеджеры не вносят данные в CRM Три причины, и ни одна из них не про лень ваших людей. В одной компании при разборе вторичных звонков нашли причину пассивности менеджеров: систему настроили оценивать разговоры по конкретным критериям, но самим менеджерам эти критерии никто не сообщил. Люди звонили, как звонили всегда, а система штрафовала их за несоответствие правилам, о которых они не подозревали. Со стороны это выглядит как саботаж: люди делают не то, что нужно. По факту — управленческая ошибка. Правила ввели, а отделу их не объявили. Решение оказалось контринтуитивным: сначала наладить сравнение оценок между собой, разобраться, что вообще система считает хорошим звонком, и только потом объявлять правила игры команде. Внедрять контроль раньше, чем менеджеры поймут, за что их оценивают, — гарантированный способ получить сопротивление, замаскированное под забывчивость и «не успел внести». Похожая логика в материале о том, как я строил контроль качества звонков без ОКК : там оценка без прозрачных критериев тоже сначала вызывала не улучшение, а глухое раздражение отдела. Где ломается Внедрять контроль или автоматическую оценку раньше, чем объявить менеджерам правила. Если человек не знает, за что его меряют, любая система контроля читается как придирка — и незаполненные карточки CRM становятся формой тихого протеста, а не следствием лени. Зависшие сделки: где в мёртвых карточках ваши деньги Посмотрите свои карточки без движения за месяц — обычно там лежит выручка размером с неплохую неделю. Долгоживущий клиент без движения — частный случай общей болезни: пайплайн копит сделки, которые формально «в работе», а по факту — цифровой мусор. Он занижает конверсию, завышает средний цикл сделки и прячет реальные проблемы отдела за красивой строчкой «в процессе». В другой компании отдельно выявили пайплайн клиентов, поставленных на паузу — они просто оставались без внимания и не возобновляли сотрудничество. Решили не смешивать их с активной базой, а протестировать реактивацию именно на «паузниках»: ИИ-бот анализировал историю переписки, определял вероятную причину паузы и подбирал тон обращения, прежде чем аккуратно напомнить о себе. Логика простая — тестировать риск там, где терять почти нечего, и только потом масштабировать подход на активных клиентов. Ещё нагляднее — история с реанимацией старых отказников. Компания подняла базу клиентов, отказавших менеджерам семь лет назад: не готовы платить, не готовы разговаривать, заявку так и не оставили. Все они когда-то брали трубку — просто работали с менеджерами низкой квалификации. В марте эти же люди вернулись и купили на 500 000 ₽ — это ощутимая часть месячного оборота условного отдела в 4 000 000 ₽. Зависшая сделка — не всегда мёртвый груз. Иногда это отложенные деньги, которые CRM не помогает найти, потому что никто не открывает старые статусы. Прежде чем гоняться за виновными в незаполненной CRM, стоит проверить саму систему на честность: я разбирал отдельно, как Битрикс24 может физически сдвигать даты и путать статусы . Метод сверки по ID оттуда применим и здесь — часть «зависших» сделок при ближайшем разборе оказывается ошибкой синхронизации, а не бездействием менеджера. Контроль работы менеджера: что реально показывает ваша воронка Отличайте две вещи: воронка показывает движение сделок, а не старание людей. Если вы будете судить по ней о человеке напрямую, получите красивые карточки и те же продажи. Возвращаясь к неделе с провалом плана на 200 000 ₽: цифры сами показали, где именно течёт воронка. Дело не в команде в целом — дело в одном конкретном шаге: встречи назначаются нормально (55%), но до договора доходит только 22%. На диаграмме — конверсия по каждому шагу воронки в сравнении с плановой конверсией лид → продажа. Руководитель отдела не скрывал тревоги: «конверсия очень низкая в продажу... мне становится страшно, я начинаю переживать конкретно». Честная реакция на цифры полезнее общих слов про эффективность. Показатель План Факт Продажи за неделю 100% 80% от плана Закрытые сделки 16 7 Конверсия лид → продажа 23% 14% Конверсия лид → встреча — 55% Конверсия встреча → договор — 22% Лид → встреча 55% Встреча → договор 22% Лид → продажа (факт) 14% Лид → продажа (план) 23% Есть и обратный пример, где контроль реально сработал. При меньшем составе отдела продажи стабильно держались выше, чем после расширения штата более чем в два раза. Причина проста — избыток лидов на менеджера просто снизил качество работы с каждым клиентом. После внедрения контроля конверсия начала расти на 1 процентный пункт в месяц. Медленно, но это заслуга управления. Наём новых людей сам по себе конверсию не поднял — эти два эффекта здесь стоит разводить сознательно. Дашборд вместо репрессий Ваша цель — сделать так, чтобы менеджеру было выгодно вести карточку, а не страшно её не вести. Разница в результате огромная. Штраф за пустую карточку меняет поведение на день. Дашборд, который сам показывает застрявшие сделки, меняет поведение системно — потому что убирает саму возможность спрятать проблему. В нескольких компаниях, где я наблюдал эту задачу, решение выглядело похоже. Один дашборд отслеживал pipeline по каждому менеджеру, конверсию договоров в оплату, дату последнего контакта с клиентом и источник сделки — с детализацией по месяцам, чтобы видеть заброшенные сделки без единого касания. Второй пошёл дальше: динамический отчёт по воронке, обновляемый ежечасно, с индикатором-светофором на каждой сделке — зелёный, жёлтый, красный — на основе нормативных сроков по стадиям. Не «сколько дней клиент висит вообще», а «сколько дней он висит сверх нормы для этой стадии конкретно». Воронка сделок — светофор по срокам стадий 80% факт продаж за неделю от плана 14% конверсия лид → продажа (план 23%) 47 дн. сделка #48213 в стадии «Переговоры» (норма 10 дн.) 2026-03-02 дата последнего контакта Сделка Стадия Дней сверх нормы Статус #48213 Переговоры 37 ждёт решения #48097 Договор 0 в норме #48150 Встреча 12 менеджер не дожал Третий вариант — дашборд по договорам: менеджер, клиент, сумма, дата выставления счёта, была ли встреча. Смысл — увидеть закономерность: закрываются ли сделки после встреч или без них, и дожимать точечно конкретных клиентов, а не отдел целиком. Блок воронки Что отслеживаем Признак затора Вход в работу Дата первого контакта, статус документов Нет движения дольше нормы стадии Активная работа с документами Комплектность, дата последнего запроса Комплект не собран, клиент молчит Подготовка к проверке Дата подачи, статус ответа Ответ просрочен, нет комментария Финал / закрытие Дата оплаты или отказа Статус завис без даты закрытия Логика всех решений одна, и один из руководителей сформулировал её коротко: «чем мне создавать два отчёта? Мне проще создать один». Разрозненные таблицы плодят пустые поля в CRM, потому что менеджеру физически неудобно вносить одно и то же в три места. Единый портал с данными по источникам, пайплайну и оплатам снимает барьер механически — не мотивацией, а конструкцией системы. Правило Дашборд без нормативных сроков по стадиям — просто красивая таблица. Светофор работает только тогда, когда для каждой стадии воронки прописано, сколько дней в ней нормально находиться. Без этого «застрявшая» сделка ничем не отличается от «нормальной» — обе просто висят одинаково зелёным. ИИ-связка: подсветка причины зависания Здесь вы получаете то, чего не даст ни один отчёт: не факт «сделка стоит», а причину — что было последним касанием, чего ждёт клиент, писал ли ему кто-нибудь вообще. Ручной светофор по срокам решает половину задачи — он показывает, ЧТО зависло. Не показывает, ПОЧЕМУ. На потоке в несколько сотен активных сделок в месяц у РОПа физически нет времени открывать каждую просроченную карточку и читать историю переписки. Здесь встраивается модель — не вместо человека, а как первый фильтр, который сортирует зависшие сделки по вероятной причине, прежде чем к ним прикоснётся менеджер. Схема конвейера: Bitrix24 (событие ONCRMDEALUPDATE при смене стадии) → облачная функция вычисляет «дней в стадии» и сверяет с нормативом из таблицы Google Sheets → если превышение — тело сделки уходит в дешёвую модель на классификацию → ответ модели записывается обратно в кастомные поля сделки через REST API → РОП видит готовую метку в дашборде, а не сырую историю переписки. Модель здесь нужна дешёвая (уровня GPT-4o-mini или аналог), не топовая: задача — классификация по короткому списку причин плюс черновик из 2–3 предложений, объём — сотни сделок в месяц. Дорогая модель на этом шаге — переплата без прироста качества: разница в точности классификации причины паузы для топовой и лёгкой модели на таком объёме текста практически не ощущается. Пример входных данных, которые уходят в модель (структура из Bitrix24-вебхука): Пример ответа модели: Инженерная обвязка: функция крутится на облачном сервере по расписанию раз в час плюс по вебхуку при смене стадии. Нормативы сроков хранятся в отдельной Google-таблице — их правит РОП без доступа к коду. Ошибки вызова API (таймаут, лимит) логируются в отдельный лист «Ошибки интеграции» и дублируются алертом в Telegram-канал отдела. Что при масштабировании на несколько воронок. Одна плоская Google-таблица с нормативами держится, пока в компании одна воронка и один РОП, который её правит. Как только воронок несколько — например, отдельно продажи и отдельно сопровождение — или отделов больше одного, плоский лист начинает путать нормативы: правки одного РОПа перезаписывают правки другого, а функция иногда читает таблицу в момент редактирования и забирает неполные данные. На этом объёме лист лучше разбивать по вкладкам с явным pipeline_id и department_id в каждой строке, а функцию — переводить с чтения «всего листа» на чтение конкретной вкладки по идентификатору сделки. Если воронок больше 3–5 и правки в норматив вносят разные люди одновременно, конструкция на Google Sheets исчерпывает себя — дальше нормативы стоит держать в отдельной таблице базы данных (хотя бы Airtable), а не в Google-листе. Отдельно — что делать, если ответ модели не лезет в схему: JSON без одного из полей, лишний текст перед скобкой, причина не из разрешённого списка. Приёмный код валидирует ответ по JSON-схеме до записи в CRM. Если валидация не прошла — автоматический retry с тем же промптом и явной пометкой «предыдущий ответ не соответствовал схеме, верни строго валидный JSON». Если после второй попытки схема снова не сходится — сделка не остаётся без метки: ей присваивается служебный статус «требует ручного разбора», и она попадает в отдельный фильтр дашборда, а не теряется молча, как это было бы с пустой карточкой без всякого ИИ. Здесь важна деталь, которую легко упустить: сам факт двойного сбоя должен куда-то эскалироваться, а не просто оседать строчкой в листе «Ошибки интеграции». Лог, который никто не читает, — это та же зависшая карточка, только на уровне инфраструктуры. Правило простое: если по одной и той же сделке подряд две неудачных попытки, или если за час накопилось больше пяти сбоев по разным сделкам, — в Telegram-канал уходит отдельный алерт с пометкой «требует внимания интегратора», а не рядовая запись в общий лог. Порог в «пять сбоев за час» — ориентир для старта; для конкретного объёма сделок в компании его стоит откалибровать на первой неделе работы. Без этого правила автоматизация превращается в ту же самую проблему, которую она должна была решить: где-то в системе тихо копится факт, что что-то не работает, и никто об этом не знает. Раз в неделю 10% автоматических классификаций проверяются вручную — сверяются с тем, что реально происходило со сделкой, чтобы не пропустить дрейф качества модели. Это тоже время, а не бесплатная строчка в регламенте — см. блок про экономику ниже. Экономика: сколько это стоит и что даёт Настройка дашборда со светофором и вебхука на ИИ-классификацию занимает ~15–25 часов работы интегратора, эксплуатация — ~3 000–6 000 ₽ в месяц на поддержку и вызовы модели, эффект от точечного спасения зависших сделок — ≈16 000–21 000 ₽ в месяц (оценка) на примере условного отдела. Дальше — не отчёт по деньгам разобранной компании, а рабочий шаблон расчёта на условном отделе из 10 менеджеров производственной компании с оборотом ~4 000 000 ₽ в месяц и средним чеком 60 000 ₽; ни одна цифра здесь не измерена по факту в компании из кейса — это метод, куда подставляют свои значения вместо примерных. Шаг 1. Сколько денег под риском. Консервативное допущение: без движения сверх нормативного срока может стоять до 10% активных сделок. При ~80 сделках в работе (по 8 на менеджера) зависших сверх нормы окажется около 8. 8 сделок × 60 000 ₽ чек ≈ 480 000 ₽ пайплайна под риском в месяц. Это не факт продаж — сумма, которая либо закроется с опозданием, либо сорвётся вовсе. Если в вашей CRM доля другая — подставьте свою цифру после выгрузки по чек-листу ниже, формула не меняется. Шаг 2. Сколько спасает подсветка. Консервативно: своевременная подсветка и дожим спасают 15–20% этой суммы. 480 000 ₽ × 15–20% ≈ 72 000–96 000 ₽ пайплайна, который реально можно спасти в месяц. Но пайплайн — ещё не деньги на счету. Шаг 3. Сколько реально попадёт в кассу. Чтобы получить реалистичную оценку выручки, пайплайн домножается на собственную конверсию встреча → договор — в нашем кейсе 22%. 72 000–96 000 ₽ × 22% ≈ 16 000–21 000 ₽ реалистичной выручки в месяц. Условие: «спасённая» сделка проходит тот же путь, что и остальные. Именно эту цифру сравниваем со стоимостью внедрения — не сырую оценку спасённого пайплайна. Шаг 4. Сколько экономит время РОПа. Без дашборда ручной разбор воронки — кто завис, кто не звонил, у кого просрочен статус — занимает 3–5 часов в неделю. При ставке ~1 000 ₽/час это 12 000–20 000 ₽ его рабочего времени в месяц. Автоматический светофор забирает эту работу почти целиком. Формула для своего случая: (число зависших сделок сверх нормы) × (средний чек) × (% спасения, консервативно 15–20%) × (конверсия встреча → договор) = реалистичная оценка эффекта в выручке в месяц. Стоимость внедрения. Дашборд с датой контакта, светофором по нормативам и вебхуком для ИИ-классификации — по практике 15–25 часов работы аналитика/интегратора, при ставке ~1 000 ₽/час это 15 000–25 000 ₽ разовых затрат — стоимость одной-двух недель работы штатного аналитика. Стоимость владения — то, что легко забыть вычесть. Разовым внедрением дело не заканчивается. Пересмотр нормативов сроков по стадиям (сезонность, новые услуги) — ~1 час РОПа в месяц, около 1 000 ₽. Еженедельная проверка 10% классификаций: при потоке в несколько сотен сделок в месяц это несколько десятков карточек в неделю, по 2–3 минуты на карточку — итого 2–5 часов в месяц, около 2 000–5 000 ₽. Итоговая постоянная стоимость поддержки — около 3 000–6 000 ₽ в месяц, то есть в 3–5 раз меньше разовых затрат на внедрение. Итог. Реализованная выручка (≈16 000–21 000 ₽/мес) перекрывает стоимость поддержки (≈3 000–6 000 ₽/мес) в разы. Плюс сэкономленное время РОПа — ещё 12 000–20 000 ₽/мес в пересчёте на ставку. Минус стоимость поддержки — величина на порядок меньше эффекта. Чистый эффект всё равно кратно превышает разовые затраты на внедрение (15 000–25 000 ₽). Окупаемость укладывается в первый-второй месяц эксплуатации. Отдельно — эксплуатация самой модели: при потоке в несколько сотен сделок в месяц и коротких промптах счёт за вызовы дешёвой модели обычно укладывается в 1 000–3 000 ₽ в месяц — это цена одного-трёх часов работы менеджера, не больше. Все цифры этого раздела — рабочий шаблон расчёта, а не измеренный факт: реальные значения зависят от вашей воронки и вашей базы клиентов. Важная оговорка. Рост конверсии на 1 п.п. в месяц из истории с расширением отдела дал не дашборд сам по себе, а весь комплекс контроля — включая ограничение числа лидов на менеджера. Вклад именно дашборда отдельный и более скромный: он ускоряет обнаружение проблемы для РОПа — недели ручного разбора воронки превращаются в минуты просмотра дашборда. Саму конверсию поднимает то, что происходит после обнаружения: звонок, дожим, решение. Автоматизация без надзора — та же проблема, вид сбоку Предупреждаю вас заранее: если вы решите проблему техникой, не решив её управленчески, вы получите те же пустые карточки, только заполненные машиной. Соблазн после всего этого — автоматизировать заполнение CRM целиком: пусть бот сам подтягивает статусы и закрывает неквалифицированные лиды. Отчасти это работает: при закрытии неквалифицированного лида менеджер проговаривает альтернативу по звонку, а SMS с дальнейшей ссылкой уходит автоматически — вручную это делали реже и хуже. Но полная автоматизация без контроля создаёт новую проблему вместо старой. Я подробно разбирал это на других кейсах в статье про автоматизацию, которая требует надзора : система, которую поставили и забыли, начинает врать так же, как забытая вручную CRM — просто по другим причинам. Применительно к нашей задаче: автоматическая классификация причины зависания снимает часть ручной работы с РОПа, но кто-то обязан раз в неделю проверять, что модель классифицирует верно. Иначе зависшая сделка получит автоматическую метку «ждёт решения» вместо реального «менеджер забыл позвонить» — и станет ещё незаметнее, чем была без всякой автоматизации. И вот что здесь стоит назвать вслух. Умение построить контур, в котором данные появляются сами — норматив по стадии, светофор, пятнадцатиминутный разбор только красных сделок, — это отдельный управленческий навык, а не работа айтишника. Руководитель, который умеет собрать такой контур, стоит дороже руководителя, который умеет только требовать заполнять карточки. Я сам шёл к этому годами: сначала делал красивые отчёты, которые никто не открывал, и злился на людей вместо того, чтобы чинить конструкцию. Чек-лист: с чего начать в понедельник Если на всё остальное нет времени — сделайте сегодня три вещи: Выгрузить из CRM список сделок без движения дольше 14 дней без комментария — это временный норматив, пока нет своего. Разослать менеджерам письменный список критериев, по которым оцениваются их звонки и сделки, — до включения любого автоматического контроля. Договориться с РОПом о еженедельном 15-минутном разборе только красных (просроченных) сделок — не всей воронки целиком. Остальное — по мере появления времени в течение недели: Добавить в таблицу или дашборд две колонки: «дней в текущей стадии» и «дата последнего контакта» — это можно сделать за один день в Google Таблице, не дожидаясь интеграции. Вручную проверить 5–10 «зависших» сделок: клиент правда неактивен или это ошибка внесения данных, как в разборе про CRM, которая врёт. Если планируете тестировать ИИ-классификацию причин, начните с сегмента «холодных» или паузных сделок, где риск минимален, прежде чем выкатывать на всю базу. Считать порог для вызова интегратора по конкретным цифрам, а не «на глазок»: если зависших сделок сверх нормы больше 10% пайплайна, если ручной разбор воронки у РОПа занимает больше 5 часов в неделю, или если поток сделок превышает 100 в месяц — это тот объём, где Google-таблица с ручным обновлением перестаёт справляться и нужен вебхук. Если своими силами за 2–3 недели не удалось: настроить вебхук на смену стадии в CRM, договориться с РОПом о нормативах по каждой стадии воронки, или найти в CRM поле, где физически хранится дата последнего контакта, — это сигнал звать интегратора или вендора CRM. Самодельная Google-таблица с ручным обновлением решает диагностику, но не автоматизацию; для конвейера с вебхуком и записью результата обратно в кастомные поля сделки нужен человек, который хотя бы раз настраивал такую интеграцию. Найти его дешевле, чем полгода терпеть пустые карточки CRM и объяснять на планёрках, куда делась выручка. Что сделать вам на этой неделе: спросите двух менеджеров, что им даёт заполненная карточка. Ответ определит, с чего начинать — с правил, с обучения или с того, чтобы убрать из CRM половину полей, которые никому не нужны. Как выстроить это так, чтобы данные появлялись сами, а не «по требованию», — в бесплатном курсе . ## KPI менеджера по продажам: что мерить, чтобы увидеть провал в среду URL: https://davidgerstein.pro/blog/kpi-menedzherov-prodazh/ Дата: 2026-08-03 Направление: Продажи Цифры: выполнение плана по выручке 80% · конверсия в продажу 14% при плане 23% · рост конверсии на 1 п.п./мес после внедрения контроля Спросите своего менеджера, что он должен сделать на этой неделе, чтобы выполнить план. Если в ответ услышите «продавать больше» — у вас нет KPI, у вас есть план по выручке и надежда. И если вы узнали здесь свой отдел — вы управляете продажами вслепую: провал вы увидите двадцать восьмого числа, когда чинить уже нечего. Разница принципиальная: план — это результат, на который менеджер влияет косвенно. KPI — это то, что он контролирует сам и что вы можете проверить в среду, а не двадцать восьмого числа, когда исправить уже нечего. Неделя: план по выручке выполнен на 80%. Закрыли 7 сделок из 16 запланированных. Конверсия в продажу — 14% при плановых 23%. Средний чек, кстати, выше плана: 13,5% против 10%. Во встречу конвертировали хорошо — 55%, встреч провели 49. А вот из встречи в договор — только 22%. Руководитель отдела в этот момент говорит буквально: «мне становится страшно, я начинаю переживать конкретно». Вот с этой раскладки и стоит начинать разговор про KPI менеджера по продажам. Не с одной цифры «выполнил план — не выполнил», а с воронки, где видно, на каком именно шаге теряются деньги. В этом примере деньги теряются не на входе (лидов и встреч достаточно) и не на сумме сделки (чек выше плана). Они теряются между встречей и договором. Это совсем другая проблема, чем если бы проседала конверсия во встречу — и лечится она по-другому. Какие KPI менеджера действительно работают KPI менеджера — это не план по выручке: план он получает как результат, влияет на него косвенно и узнаёт о провале в конце месяца. Рабочие показатели те, что человек контролирует сам и вы проверяете в среду: число сделок в движении, доля сделок без касания дольше семи дней, конверсия в следующий этап. Эти три показателя остались после месяца, в котором выручки не было, а объяснить причину никто не мог. Проверка на практике: у сильного и слабого менеджера сравнивайте не выручку, а эти три числа — разница в действиях объясняет разницу в деньгах. Почему план по выручке — это не KPI, а диагноз задним числом Мы у себя долго путали эти две вещи и потеряли на этом не один квартал. Я сам годами смотрел на одну строчку «план — факт» и был уверен, что этого достаточно. План не выполнялся, и я честно не понимал, за что хвататься: менять людей, менять цену, добавлять рекламы. Здесь ошибаются почти все, кто вырос из продавца в руководителя, — я в том числе. План по выручке говорит только одно: получилось или нет. Он не говорит, почему. Отдел из 6–7 менеджеров в одной компании стабильно продавал хуже, чем тот же отдел в составе 3 человек — руководителя, его напарника и ещё одного. Причина не в квалификации новых людей. Причина в том, что лидов на всех не хватило, и качество работы с каждым лидом упало. По плану выручки это не видно сразу — видно только через несколько месяцев, когда цифры уже просели. После того как ввели контроль на уровне воронки — не «сколько продали», а «сколько лидов, сколько встреч, сколько дней сделка стоит без движения» — конверсия начала расти на процентный пункт в месяц. Не потому что наняли новых людей или увеличили бюджет на лиды. Потому что стало видно, где именно теряются клиенты у конкретных менеджеров. Воронка вместо итоговой цифры Рабочий набор метрик для отдела продаж выглядит примерно так — и это то, что легло в основу дашборда, о котором дальше. В последнем столбце — фактические значения по той самой неделе с планом, выполненным на 80%, там, где данные вообще фиксировались: Метрика Что показывает Где искать проблему Значение за неделю (пример) Конверсия в продажу Итоговая эффективность менеджера Слишком общая, сама по себе бесполезна 14% факт / 23% план Конверсия лид → встреча Качество квалификации и первого контакта Скрипт, скорость реакции на заявку 55% (49 встреч) Конверсия встреча → договор Аргументация и умение закрывать сделку Навык менеджера, ценностное предложение 22% Средний чек Умение продавать пакеты выше базового Работа с апсейлом, знание услуг 13,5% / 10% план Дни в текущем статусе Скорость движения сделки по воронке Застрявшие клиенты, забытые лиды не фиксировалось до дашборда Дата последнего контакта Есть ли вообще внимание к клиенту Пайплайн без касаний не фиксировалось до дашборда Доля клиентов на одном менеджере Риск непрерывности при увольнении Нет передачи знаний внутри команды не фиксировалось до дашборда Три последние строки не зря помечены «не фиксировалось» — это честная часть картины: до внедрения дашборда эти данные просто не собирались, и именно их отсутствие не позволяло увидеть риски заранее. Вот как выглядит эта воронка на примере той самой недели — по стадиям, а не одной итоговой цифрой: Лид → встреча 55% Встреча → договор 22% Лид → продажа (факт) 14% Лид → продажа (план) 23% Из этой картинки понятно, что чинить нужно не скрипты первого звонка (со встречами всё нормально) и не квалификацию лидов на входе. Проблема — в переходе от встречи к договору. Это либо аргументация, либо цена, либо то, что клиенту не закрыли реальное возражение на встрече. Без разбивки по стадиям это выглядело бы просто как «конверсия ниже плана» — и время ушло бы на исправление не той части воронки. Правило KPI, который меряет только результат, а не процесс, всегда приходит с опозданием. Пока вы видите просевший план — деньги уже потеряны за 2–3 месяца до этого. Метрики процесса (дни в статусе, дата контакта, конверсия по стадиям) дают шанс вмешаться раньше. Мёртвые лиды и мёртвые сделки — считать отдельно Проверьте у себя: сколько сделок в вашей воронке не двигались две недели? Обычно это от четверти до половины, и в отчёте по выручке они не видны никак — а деньги там есть. В одной воронке нашёлся клиент без движения полтора года — из отдельной категории контрактов, которая по своей природе двигается медленнее остальных. Он искажал всю статистику: по нему считались сроки, средние показатели, конверсии — и всё это было неправдой, потому что клиент фактически не двигался. Решение простое: вынести такие случаи в отдельную воронку по типу работ, чтобы не путать «спящих» клиентов с активной работой. Похожая логика применима и на входе воронки: если в отдел приходит 200+ потенциальных обращений в месяц, а конверсия держится около 25%, недостаточно смотреть на итоговый процент — нужно понимать, сколько из этого пула вообще пригодно для апсейла прямо сейчас, а сколько застряло на этапе сбора документов и физически не может продвинуться дальше, сколько бы касаний ни делал менеджер. Другой пример — с базой отказников. Компания подняла лиды семилетней давности, которые когда-то отказали: не готовы платить, не готовы разговаривать, не оставили заявку. В марте часть из них вернулась и купила на сумму, заметную для месячного оборота компании. Важная деталь: все они раньше брали трубку и общались — просто им в своё время достался менеджер низкой квалификации. Это фиксация системной ошибки: слабый менеджер = потерянные деньги, которые можно вернуть, просто пересадив клиента на другого человека. Стоит сразу оговориться: этот результат дал не один инструмент, а комплекс мер — сегментация базы, ручной отбор «тёплых» отказников и пересадка на менеджера с другой квалификацией. Отдельно оценить вклад одной лишь автоматизации выборки в эту сумму по имеющимся данным нельзя, и приписывать её целиком скорингу было бы нечестно. Компания сейчас готовит автоматический инструмент, чтобы повторить этот результат уже не разово, а на потоке — но пока это план, а не факт, который можно было бы зашить в KPI. Для KPI менеджера это означает: нужна метрика не только по новым лидам, но и по работе с базой. Один менеджер в мае сделал только 15 звонков новым контактам вместо плановых 60+, зато повторное касание по 19 тёплым лидам дало 4 рекомендации. Вывод прямой: одного звонка недостаточно, нужна регулярная работа с базой как отдельный измеримый процесс, а не разовая акция. Больше про то, куда утекают лиды между маркетингом и продажами — в статье «Лиды есть, а продаж нет» . ИИ-связка: контроль без ручной прослушки Здесь машина закрывает вашу главную проблему с KPI: вы наконец видите не только результат, но и то, как работает ваш менеджер, — по всем разговорам, а не по трём, которые вы успели послушать. Отдельная история — про то, как ИИ начал оценивать вторичные звонки менеджеров по критериям, которые сами менеджеры никогда не видели. Требования к таким звонкам были прописаны в системе для настройки алгоритма, но до отдела продаж их никто не донёс. В итоге менеджеры звонили, как звонили всегда, а система штрафовала их за несоответствие правилам, о которых они не подозревали. Это типичная ошибка при внедрении любого автоматизированного KPI: сначала нужно проверить, что оценки ИИ и оценки живого проверяющего совпадают в целом, и только потом объявлять отделу правила игры. Рабочая схема конвейера, которая закрывает эту проблему, выглядит так: Что. Звонок менеджера завершается в телефонии, подключённой к CRM (например amoCRM или Bitrix24). Чем. Вебхук на событие «звонок завершён» отправляет запись во внешний сервис транскрибации, затем текст и метаданные (id менеджера, id сделки, длительность) — в дешёвую модель для первичного скоринга по критериям. Куда. Результат (баллы по критериям, итоговый скор, флаг эскалации) пишется обратно в карточку сделки CRM через API и параллельно — в общий дашборд. Кто и когда. Пограничные звонки (скор 40–60 из 100) автоматически уходят на повторную оценку дорогой моделью и попадают в очередь ручной проверки РОПа. Остальные просто накапливаются в статистике по менеджеру. Дешёвая модель здесь оправдана: объём звонков большой, а задача первого прохода простая — сверить факты по чек-листу, не рассуждая. Дорогая модель включается только на спорных случаях, где нужна интерпретация тона и контекста. Это тот же принцип, что и в контроле качества без штатного ОКК — подробнее про экономику такой связки в статье про контроль качества звонков без ОКК . Пример ответа модели на такой запрос: Инженерная обвязка Пайплайн крутится не «где-то в облаке», а на понятном сервисе-посреднике: небольшой скрипт или сценарий в n8n на отдельном сервере (или облачной функции), который слушает вебхук из CRM, дергает API транскрибации и API модели, пишет результат обратно через API CRM. Если модель вернула невалидный JSON или не ответила — до трёх повторов с задержкой, затем звонок автоматически падает в ручную очередь, а не теряется молча. Если пайплайн не отвечает вообще (сбой сервиса, кончилась квота API) — отдельное сообщение уходит в канал ответственного за инфраструктуру, а не в общий чат отдела продаж, чтобы не путать техническую ошибку с реальной проблемой у менеджера. Здесь же стоит держать в голове ограничение по личным данным: транскрипты звонков могут содержать чувствительную информацию о клиенте, и то, что можно отправлять во внешнюю модель, а что нельзя, — вопрос отдельный и заслуживает самостоятельного разбора. Где ломается KPI, о котором менеджер узнаёт постфактум по результату оценки, а не заранее в виде понятного правила, — это не мотивация, а рулетка. Она демотивирует быстрее, чем полное отсутствие KPI. Прежде чем включать автоматическую оценку в мотивацию, минимум месяц гоняйте её параллельно с ручной проверкой и сверяйте расхождения. Мотивация: процент с продаж — не единственный рычаг Здесь вам придётся принять решение, которое не понравится части команды. Но если вы платите только процент, вы платите за удачу так же, как за работу. С мотивацией менеджеров сложнее, чем кажется на старте. В одной компании руководителя отдела перевели на схему «1% с личных продаж + 1% с продаж команды» — чтобы стимулировать развитие отдела, а не только личный результат. Но внедрение отложили на месяц: испугались, что менеджер с недостаточным личным доходом потеряет мотивацию, пока привык мыслить горизонтом в один месяц, а не в перспективе роста команды. В другом случае руководитель отдела получал двойную комиссию — и как менеджер, и как руководитель, — что снижало его интерес развивать команду вместо личных продаж. Решение — временно сохранить двойную схему на два месяца, а затем перейти только на командную комиссию, привязав переход к конкретному критерию: укомплектованный состав из нескольких менеджеров. Есть и обратная сторона — конфликт ожиданий. Менеджеру когда-то обещали процент от прибыли, но когда рост замедлился, собственник эту долю забрал, списав всё на «неправильное управление». Формально это решение собственника. По факту — подрыв доверия к любой будущей схеме мотивации в этой команде. KPI и бонусы, которые можно отменить задним числом, работают только один раз — после этого людям нужны письменные договорённости, а не устные обещания. Похожая тонкость — с расчётом бонуса: менеджеру предложили не засчитывать доход от клиента, который должен был оплатить в следующем месяце, хотя раньше компания обещала учитывать такие переходящие платежи. Менеджер согласился в обмен на повышение бонуса — но осадок от смены правил остаётся, даже если формально стороны договорились. Не всякий провал по конверсии решается деньгами. Когда конверсия отдела держится на уровне 25–28% третий месяц подряд, руководитель формулирует это без обиняков: «конверсия 25-28% третий месяц подряд — это позор. Если такая конверсия, то я меняю сразу структуру мотивации и все рекомендации отдаю в отдел продаж, у которого конверсия 80%». Это тоже KPI-решение, просто не про размер процента, а про то, что низкая конверсия делает сам факт получения лидов от компании привилегией, которую можно потерять. Похожий случай — с менеджерами, которые теряют энтузиазм на холодных лидах из низкоконверсионного канала: здесь сработало не повышение комиссии (это подтвердило бы, что канал действительно «плохой»), а объяснение, что работа со сложными холодными сделками — часть роста квалификации, а не наказание. KPI, которые считают не только продажи Один из собственников предложил другой взгляд на цель. Вместо роста продаж в абсолютных цифрах (это дало бы сравнительно скромный прирост прибыли) — смотреть на сокращение цикла обслуживания клиента на 30% и снижение операционных расходов на 20–30%. Логика в том, что эти метрики сильнее влияют на чистую прибыль через ускорение оборота денег и снижение затрат, чем прямой рост выручки. Для менеджеров это тоже применимо: скорость закрытия сделки и снижение доли «зависших» клиентов иногда даёт бизнесу больше денег, чем ещё один процент к конверсии. И ещё один KPI — который вообще не сводится к числу. Менеджер провёл лид-менеджера через постепенное вовлечение: сначала наблюдение за встречами, потом ведение первых 7 минут, затем расширение роли, пока не сказал «иди и закрывай сама» — и она закрыла сделку. Ни один дашборд не покажет момент готовности человека к самостоятельной работе. Это тот случай, когда KPI по количеству проведённых встреч стажёром маскирует главное: готов он или нет. Дашборд вместо отчётов вручную Правило для вас: если руководителю отдела нужно больше двух минут, чтобы понять, кто из его людей отстаёт и почему, — дашборд не работает. Ваша цель не красота, а скорость реакции. Практический вывод из всей этой фактуры такой: KPI менеджера по продажам работает, только если он живёт в системе, а не в голове руководителя и не в еженедельном отчёте, который менеджер сам себе пишет. В нескольких компаниях в итоге пришли к одному и тому же решению — единый интерактивный отчёт вместо разрозненных документов: договоры по источникам, пайплайн по месяцам, оплаты и выставленные счета по каждому сотруднику. Логика простая: «зачем мне два отчёта, если можно один интерактивный, который обновляется сам, чем пять таблиц, которые нужно сверять руками». Технически это тот же дашборд, что и в связке со скорингом звонков, только источник данных — не транскрипты, а карточки сделок CRM. Ключевой элемент — светофор по срокам стадий: если сделка стоит в статусе «встреча назначена» дольше норматива (например, 3 рабочих дня без движения), карточка красится в жёлтый, а после недели — в красный. Руководителю не нужно спрашивать у менеджера «как там клиент» — достаточно открыть дашборд и увидеть все красные строки за секунду. Менеджеру не нужно писать отдельный отчёт «что происходило на неделе» — эта же таблица и есть отчёт, просто без ручного труда по её составлению. Именно это и убирает микроменеджмент из уравнения: контроль идёт не через вопросы «почему не позвонил», а через видимость процесса. Менеджер видит те же цифры, что и руководитель, — значит, разговор идёт про конкретную сделку и конкретный срок, а не про общее недовольство результатом. Экономика: во что обходится KPI менеджера без воронки Прикиньте свою цифру: сколько сделок в вашей воронке зависло и какой у вас средний чек. Это не потерянные деньги, но это деньги, которые лежат без движения, пока вы меряете только выручку. Давайте посчитаем не абстрактно, а на условном примере, чтобы цифры были осязаемы. Возьмём отдел из 8 менеджеров, где на каждого приходится примерно 20 лидов в месяц — итого около 160 лидов на отдел. Просадка конверсии на 9 процентных пунктов (именно такой разрыв был в разобранном примере: план 23%, факт 14%) на этой базе — это примерно 14 несостоявшихся сделок в месяц (160 × 9% ≈ 14, оценка). При условном среднем чеке в 150 тыс. рублей (цифра для примера, не из фактуры компании) это риск на уровне 2,1 млн рублей недополученной выручки в месяц — оценка, которая будет меняться в зависимости от реального чека и объёма лидов у конкретного отдела. Отдельно стоит посчитать цену ручных отчётов, которые дашборд убирает. Если РОП тратит на сведение недельных отчётов по менеджерам условные 3 часа в неделю, а каждый из 8 менеджеров тратит на подготовку своего отчёта ещё по 30–40 минут — это дополнительно 4–5 часов в неделю на отдел. При ставке около 1000 ₽/час (оценка) это порядка 16–20 тыс. рублей в месяц условной стоимости времени, которое уходит не на продажи, а на составление таблиц вручную. Дашборд не увеличивает выручку сам по себе — он лишь освобождает эти часы и делает видимой проблему на встрече-к-договору за недели, а не месяцы. Сам рост конверсии на процентный пункт в месяц, о котором шла речь в начале статьи, — результат того, что руководитель начал видеть проблему раньше и разбирать её точечно с конкретными менеджерами, а не разовый эффект одного лишь дашборда без последующей ручной работы с людьми. Осторожно с цифрами Приведённые расчёты — иллюстрация логики «конверсия × база лидов × чек», а не прогноз для вашей компании. Подставляйте свои значения: базу лидов, реальный средний чек, фактический разрыв план/факт по конверсии — и оценка станет пригодной для решения, стоит ли вкладываться в дашборд именно сейчас. Чек-лист на понедельник Выгрузить из CRM воронку по стадиям за последний месяц отдельно от итоговой конверсии: лид → встреча, встреча → договор, договор → оплата. Найти стадию с самым большим провалом относительно нормы — именно туда, а не в скрипты первого звонка, направить внимание на этой неделе. Проверить долю сделок без движения дольше норматива (3–7 рабочих дней в зависимости от цикла) — если такой метрики ещё нет, завести её первой, раньше любых KPI по звонкам. Вынести в отдельную воронку контракты с заведомо более долгим циклом, чтобы они не искажали средние сроки и конверсии по основному потоку. Если планируете автоматическую оценку звонков — сначала прогнать её месяц параллельно с ручной проверкой РОПа и свериться в расхождениях, и только потом объявлять правила отделу. Перед изменением схемы мотивации — зафиксировать её письменно и не менять задним числом: разовое нарушение обещания стоит доверия ко всем будущим KPI. Посчитать для своего отдела оценку риска по формуле «база лидов × разрыв конверсии план/факт × средний чек» — и сравнить с ценой внедрения дашборда или скоринга, прежде чем в них вкладываться. Начните с малого на этой неделе: возьмите двух менеджеров — сильного и слабого — и сравните не выручку, а действия. Сколько звонков, сколько дошло до встречи, сколько сделок висит без движения. Разница в действиях объяснит вам разницу в выручке лучше любого разговора о мотивации. Как поставить на это машину, чтобы видеть картину по всем менеджерам, а не по двум, — механика в бесплатном курсе для руководителей . Как мы к этому пришли Мы жили на плане по выручке несколько лет и считали, что это нормально. Перелом случился, когда я попробовал разобрать неудачный месяц: выручки нет, а объяснить почему никто не может. Менеджеры говорят «рынок», руководитель отдела разводит руками, и спорить не с чем — цифр под этими объяснениями нет. Мы тогда добавили три показателя, которые менеджер контролирует сам: сколько сделок он двигает, сколько висит без касания, какая доля доходит до встречи. Дальше стало неинтересно спорить: у одного все три показателя в норме и провал по выручке — значит, вопрос к продукту или цене. У другого половина сделок неделю без движения — вопрос к нему. Никакой магии тут нет, и вам не нужны ни системы, ни бюджет. Нужна готовность смотреть не только на результат, но и на работу, которая к нему ведёт. Скажу прямо: читать воронку по стадиям — такой же базовый навык руководителя, как читать отчёт о движении денег. Раньше директор мог этого не уметь и оставаться сильным директором. Сейчас не может. Тот, кто видит, на каком шаге встала сделка, управляет отделом. Тот, кто видит только итог месяца, управляет своей надеждой. Я на этот навык потратил не один квартал — и это была самая окупаемая учёба за всё время. Начните на этой неделе с одного: посчитайте, сколько сделок у каждого менеджера стоит без касания дольше семи дней. Эта цифра скажет вам о работе отдела больше, чем месячный отчёт по выручке. Как поставить такой контроль на автомат — в бесплатном курсе для руководителей . ## Контроль задач сотрудников: делегирование, которое не возвращает работу вам URL: https://davidgerstein.pro/blog/delegirovanie-bez-poteri-kontrolya/ Дата: 2026-08-01 Направление: Операционное управление Цифры: 11 000 ₽/мес возврата времени на отчёте · 9 000 ₽/мес переплата за 12 лишних каналов связи · 540 000 ₽/мес риск от зависших сделок (оценка) Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Вы делегируете, а потом всё равно проверяете каждый шаг? Значит, вы не делегировали — вы просто добавили себе ещё одну задачу: контроль. Проблема почти всегда в одном: задача передана, а критерий приёмки — нет. Человек не знает, каким должен быть результат, вы не знаете, когда можно отпустить, и оба страдают. Финансовый сотрудник жаловался, что коллеги дёргают его весь день с просьбами об оплатах. Основную работу не успевал, начал сомневаться в своей компетентности. Разбор показал: проблема не в человеке. В расписании не было слота под платежи. Как только появилось окно с 10 до 11 — именно на обработку операций, — перебивания не исчезли полностью, но перестали быть системой. Это и есть делегирование задач руководителем в чистом виде: не «возьми на себя», а «вот структура, в которой твоя ответственность работает». Большинство проблем с делегированием — это не проблема доверия. Это отсутствие структуры, в которую можно делегировать. Я сам года два считал, что дело в людях: не тянут, не хотят, надо искать других. Дело было в том, что я не давал им структуры, — и это моя недоработка, а не их. Ниже — с чем я сталкивался, сколько это стоило в деньгах и что чинил. Как контролировать задачи сотрудников без микроменеджмента Не проверять каждый шаг, а закрыть три опоры: фиксированный слот в расписании под конкретный тип задач, один источник данных вместо трёх разных выгрузок и инструкция, закреплённая после третьей итерации. Дальше руководитель смотрит не на задачи, а на отклонения — сводка приходит в 9:00 сама, без вопроса «как дела». Цена отсутствия такого контроля считается в деньгах: 11 часов в месяц (≈ 11 000 ₽) на ручной отчёт, ≈ 9 000 ₽/мес переплаты за 12 лишних каналов связи и до 540 000 ₽/мес риска по зависшим сделкам без владельца (оценки). Делегирование задач руководителем — это не «отдать руки», а построить систему Показательный разговор: менеджер ведёт три проекта, в каждом по пять треков. Просит помощника. Ему дают одного человека — «ещё одну пару рук». Не помогает. Потому что задача не в нехватке рук, а в отсутствии структуры распределения: нужны не руки, а три отдельных зоны ответственности, каждая со своим человеком и своими границами. Если этого нет — любой помощник превращается в ещё один канал, который надо контролировать вручную. Скажу прямо: собрать контроль задач сотрудников так, чтобы он держался без вас, — это отдельный управленческий навык, и осваивать его придётся так же, как когда-то осваивали бюджетирование. Руководитель, который умеет построить структуру, где работа идёт без его личного присутствия, стоит дороже руководителя, который умеет только раздавать поручения и потом их выбивать. Я этот навык добирал на ходу и с потерями. Корень проблемы обычно один: у руководителя нет навыка постановки задачи. Не в смысле «не может объяснить», а в смысле — не разбивает работу на единицы, которые можно передать целиком, с понятной границей и результатом. Пока задача не разбита, делегирование выглядит как «на, разберись», а это не делегирование, это перекладывание неопределённости. Контроль задач сотрудников: почему таблицы и память подводят Проверьте себя: сколько задач вы держите в голове прямо сейчас и сколько из них вы вспомните завтра без напоминания? Классический симптом — данные, которые врут в зависимости от того, кто и как их выгрузил. У нас была ситуация: список клиентов из воронки одного региона выгружали трижды, получили три разных числа. Это не ошибка одного сотрудника. Это децентрализованное хранение: у каждого свой фильтр, своя версия правды, и руководитель тратит время не на управление, а на поиск, какая цифра настоящая. Отдельно я разбирал похожий случай с датами, которые сдвигались в самом Битрикс24 — там источник ошибки был не в человеке, а в системе, но принцип диагностики тот же: сначала найти, где именно врёт цифра, потом чинить. Контроль исполнения задач нельзя строить на том, что кто-то посмотрит таблицу и скажет «всё ок». Мы заменили ручную проверку ботом: он ежедневно присылает, сколько звонков было вчера, сколько добавлено сегодня, на сколько отстают от плана. Менеджеры складывают записи в структурированную папку под своей учёткой, система агрегирует сама. Руководителю не нужно спрашивать «как дела» — у него есть цифра без интерпретаций. Отдельно — дашборд для руководителей подразделений: маркетинг, продажи, платёжный календарь, персональное обслуживание в одном месте вместо блуждания по CRM и таблицам. Добавили вкладку «ВИП-контроль» для клиентов с чеком, кратно превышающим средний по базе, — ежедневная проверка статусов с быстрым переходом в CRM, если нужно копнуть глубже. Смысл не в том, чтобы видеть всё. Смысл в том, чтобы видеть отклонение и разбираться только с ним. Дашборд руководителя подразделения 52 подключённых канала за месяц 78% план по звонкам, Смирнова А. Топ-15% порог для ВИП-контроля по чеку Раздел Статус Маркетинг норма Продажи внимание Платёжный календарь норма ВИП-контроль (чек в разы выше среднего) проверить Было Стало Руководитель спрашивает в чате «как продвигается» Бот присылает статус автоматически по расписанию Три разные выгрузки — три разных числа Один источник данных, агрегация по пользователю Отчёт готовится вручную перед планёркой Сводка собирается сама к началу дня Контроль = проверка вручную каждой задачи Контроль = реакция на отклонение от плана Похожая логика — в подходе к заполнению CRM менеджерами : пока внесение данных держится на памяти и добросовестности человека, оно будет проседать. Система должна делать это за него или ловить момент, когда он этого не сделал. ИИ-связка: как собрать сводку без ручного сведения Дашборды и боты выше — это уже готовые продукты. Но конвейер, который их кормит, можно собрать за один день на связке «Bitrix24-вебхук → таблица → модель → Telegram», без разработки с нуля. Вот как это выглядит по шагам: Bitrix24-вебхук раз в сутки, в 8:00, выгружает задачи и сделки, изменённые за последние 24 часа, плюс текст голосовых сообщений сотрудников (уже расшифрованный отдельным сервисом). Данные складываются в Google Sheets построчно — по одному сотруднику на строку, с полями: должность, план по звонкам, факт, просроченные задачи. Скрипт (Google Apps Script или сценарий в Make/n8n) собирает JSON по каждому сотруднику и отправляет его в языковую модель с промптом на структурирование и приоритизацию. Модель возвращает строгий JSON: приоритет, отклонение, ключевое событие дня. Telegram-бот в 9:00 публикует сводку руководителю и, при необходимости, самому сотруднику — до начала рабочего дня, а не по запросу. Модель на этом шаге — дешёвая, а не топовая. Мы уже проверяли на другой задаче: разработчик гонял промпт через дорогую модель (Opus), хотя более дешёвая версия (Sonnet) на том же входе давала идентичный результат. Здесь задача та же по природе — структурирование и классификация по понятным правилам, а не творческая генерация. Переплата за флагманскую модель тут не окупается ничем, кроме иллюзии надёжности. А где разница между дешёвой и дорогой моделью действительно видна — в разборе того, что машина вытягивает на текстах, документах и таблицах . Пример ответа модели на реальном по структуре входе: Что делать, если дешёвая модель на этой конкретной задаче начинает систематически путать приоритеты — например, ставит «норма» при явной просрочке в 3 дня. Опыт с Opus/Sonnet выше был про другую задачу, здесь порог принятия решения свой, и его надо проверять отдельно. Порядок действий такой: сначала ужесточить промпт числовыми порогами (это уже сделано выше — «> 2 дней», «70–90%»), затем добавить 3–5 few-shot примеров именно тех кейсов, где модель ошибалась, и только если после этого доля ошибок в приоритете выше приемлемой (условно — чаще одной ошибки на 20 сводок), переходить на модель среднего уровня. Смена модели — последний шаг в этой цепочке, не первый; в девяти случаях из десяти проблема лечится промптом, а не ценой токена. Инженерная обвязка простая и без иллюзий: сценарий крутится в Make (или n8n на своём сервере), лог всех входов и ответов пишется в отдельный лист Google Sheets — это и есть журнал для разбора, если что-то пошло не так. Если API модели вернул ошибку или таймаут — три автоматических повтора с интервалом 5 минут, при третьей неудаче алерт уходит в отдельный технический чат «бот молчит», а не теряется молча. Если ответ модели не парсится как валидный JSON — строка помечается флагом и уходит человеку на ручную проверку вместо того, чтобы тихо выпасть из сводки. Прозрачность без ежедневных пересказов Ваша цель — видеть статус, не спрашивая. Если для понимания картины нужна планёрка, вы платите за неё временем всей команды. У руководителя, который держит в голове десятки процессов, обычно нет времени вникать в каждую задачу отдельно. Решение, которое сработало у нас: все встречи, записи и задачи агрегируются в одну сводку, которая приходит утром с приоритизацией по должностям и автоматическим распределением новых задач. Это не отчёт для галочки — это способ не упустить важное, не читая десять источников. То же с постингом в соцсети: менеджеры записывают голосовое сообщение по итогам дня, оно попадает в единый агрегат, транскрибируется и упаковывается в контент. Единственная сложность — заставить людей делать эту рефлексию ежедневно, потому что живой контент требует живого источника. Автоматизация решает упаковку, но не решает дисциплину на входе. Это ограничение я обхожу молча реже, чем стоило бы. В статье о планёрках, которые документируют себя сами , — тот же принцип: прозрачность задач сотрудников держится не на том, что все стали ответственнее, а на том, что фиксация перестала зависеть от человека, который вечно спешит. Где ломается Делегирование без структуры превращается в перебивания и хаос — сотрудник получает задачу, но не получает границ, времени и точки, куда обращаться с вопросами. Результат: он либо тонет, либо возвращает задачу руководителю в виде постоянных уточнений. То же с автоматической сводкой: если голосовые сообщения или данные из CRM перестают приходить регулярно (человек забыл, канал отвалился), сводка молчит или показывает пустые поля — и это выглядит как «всё в порядке», хотя на деле источник просто не сработал. Прежде чем делегировать или автоматизировать контроль, нужно ответить на вопрос: в какое время, в каком канале и с каким результатом это должно происходить. Если ответа нет — делегировать пока нечего. Инструкция вместо повторного объяснения Работающая практика: каждое новое действие сотрудника либо документируется в виде инструкции, либо записывается на диктофон для расшифровки. Логика простая — три итерации: неправильно, неправильно, правильно. После третьей, рабочей версии действие закрепляется инструкцией, и к вопросу больше не возвращаются. Это медленнее в моменте и быстрее на дистанции: рутина превращается в процесс, который можно передать новому человеку без повторного объяснения с нуля. Без этого шага делегирование упирается в стену: каждый новый сотрудник задаёт те же вопросы, что и предыдущий, а руководитель отвечает на них лично — то есть фактически не делегировал, а нанял себе ещё одного человека, требующего внимания. Разделение ролей — тоже форма делегирования Не всегда проблема в задачах. Иногда — в том, что одна роль требует двух разных типов внимания одновременно. У нас менеджер не мог одновременно обучать новичков и вести опытных продавцов — это разные режимы работы, и попытка совмещать их в одном человеке приводила к тому, что страдали обе группы. Решение — разделить: один занимается только стажёрами, другой — действующими менеджерами. Ещё пример: сильный сотрудник без свободного времени в дне, с карьерными амбициями, упёрся в потолок. Вместо увольнения или игнорирования ей предложили возглавить проект автоматизации — это одновременно решило её потолок и операционную проблему компании. Делегирование здесь шире, чем «дать задачу»: это распределение ответственности так, чтобы она соответствовала возможностям и мотивации человека, а не только штатному расписанию. Обратный пример упущения — руководитель отдела разработки долго не был подключён к планёркам по автоматизации, хотя все обсуждаемые задачи были техническими и касались его напрямую. Это не делегирование, это исключение из контура человека, который должен был быть его частью с самого начала. Это моя ошибка: я не позвал его вовремя. Вскрылось не сразу — и стоило времени на пересборку процессов задним числом. Сколько стоит несистемное делегирование — и что даёт система Три расчёта ниже, каждый со своей ценой и эффектом: ручной отчёт — это 11 часов в месяц (≈ 11 000 ₽, оценка по ставке); лишние каналы связи — 12 линий и ≈ 9 000 ₽/мес переплаты (оценка); зависшие сделки без владельца — риск ≈ 540 000 ₽/мес (оценка). Это три разные задачи с разными исправлениями, не одна и та же экономия, посчитанная трижды. Ручной отчёт. Формула: (минуты в день ÷ 60) × рабочие дни в месяце × ставка сотрудника в час = потери времени в деньгах. Аналитик тратил около 30 минут в день на ручное заполнение ежедневного отчёта (показатель, средний чек, конверсия) — это факт, не оценка. Подставляем: 0,5 часа × 22 рабочих дня = 11 часов в месяц. По ставке около 1 000 ₽/час (оценка, ориентир для сотрудника аналитического уровня) это 11 часов × 1 000 ₽ ≈ 11 000 ₽/мес чистого времени, которое можно вернуть аналитику на аналитику, а не на копирование цифр. Возьмите свои минуты и свою ставку — формула та же. Разрастание каналов связи без контроля. Формула: количество лишних подключённых линий × стоимость одной линии в месяц = переплата. В компании ~40 человек за несколько месяцев число оплаченных коммуникационных линий выросло до 27, хотя реально с внешними клиентами работают около 15 человек (8 менеджеров продаж и часть поддержки). Разница — 12 лишних линий: WhatsApp и Telegram подключены по отдельности почти у каждого, хотя нужен один канал. Одна линия стоит ~750 ₽/мес. 12 × 750 ₽ ≈ 9 000 ₽/мес переплаты (оценка) — деньги, которые уходили не за связь с клиентами, а за то, что право подключать канал делегировали, а точку контроля над этим правом — нет. Аудит и отключение дублей — это не разработка, это полчаса работы с биллингом провайдера, но без выделенной ответственности за него никто не потратил эти полчаса три месяца подряд. Зависшие сделки без владельца. Формула: поток сделок в месяц × доля зависших без контроля × доля тех, что в итоге срываются × средний чек = риск в деньгах. При обороте отдела продаж ~9 млн ₽/мес и среднем чеке ~180 тыс. ₽ поток — около 50 сделок в месяц. Если из-за отсутствия контроля исполнения около 10% сделок зависают без явного владельца (никто не назначен ответственным за следующий шаг) — это 5 сделок в месяц. Из них 2 всё же закрываются, просто позже, а 3 — по консервативной оценке — срываются: клиент не получил ответа вовремя и ушёл к конкуренту или остыл. Риск: 3 сделки × 180 000 ₽ ≈ 540 000 ₽/мес (оценка). Это не фактическая потеря, а верхняя граница риска при текущей доле зависания — но именно она обосновывает, почему владелец у каждой сделки должен быть назначен явно, а не подразумеваться. Идут по плану — 45 сделок (90%) Зависли, но закрылись — 2 сделки (4%) Зависли и сорвались — 3 сделки (6%) Важная оговорка по всем трём цифрам: они не складываются в единый эффект одного и того же внедрения. Ручной отчёт чинится интеграцией CRM с таблицей — это отдельная задача. Каналы связи чинятся аудитом биллинга — вторая задача. Зависшие сделки чинятся точкой контроля (бот, дашборд, явный владелец на каждом этапе) — третья. Если вы одновременно наводите порядок во всех трёх, экономия суммируется; но приписывать все три результата, скажем, одному только Telegram-боту со сводкой — было бы натяжкой: сдвиг дают разные меры, вклад каждой по отдельности можно посчитать только там, где мы это явно сделали выше. Отдельно: что мы не считаем эффектом. 11 000 ₽/мес по отчёту — это высвобожденное время аналитика, а не сокращение фонда оплаты труда: человек остаётся в найме, время просто уходит на более сложную аналитику. Деньгами это становится только тогда, когда высвобожденные часы дают измеримый результат — больше отчётов без найма нового человека, меньше переработок. Пока это не так — это поток свободного времени, а не поток денег. Чек-лист на понедельник Выписать 3 задачи, которые вы делегировали за последний месяц, но которые всё равно возвращаются к вам вопросами. Для каждой — определить: не хватает границы, времени в расписании или инструкции. Проверить, есть ли у каждой сделки в работе явный владелец следующего шага. Если ответственность подразумевается, а не назначена — риск зависания есть уже сейчас. Сверить число подключённых коммуникационных каналов (WhatsApp, Telegram, другие линии) со списком сотрудников, которым они реально нужны. Разница — это переплата, которую можно отключить сегодня же. Для одного повторяющегося ручного отчёта посчитать: минуты в день × рабочие дни × ставка сотрудника. Если сумма заметна — это кандидат на автоматизацию через выгрузку из CRM, а не на «доделаем как-нибудь». Для одного нового действия, которое сотрудник выполняет впервые, — решить заранее: документируем сразу как инструкцию или записываем на диктофон для расшифровки после третьей итерации. Ни один из этих пунктов не требует бюджета на разработку. Все они требуют одного — назначить, кто и когда на это смотрит. Контроль задач сотрудников в итоге сводится именно к этому: не к тому, что вы отдали работу, а к тому, что вы построили структуру, в которой эта работа не возвращается к вам сама. Сделайте на этой неделе эксперимент: передавая следующую задачу, потратьте две минуты на формулировку «по какому признаку я приму результат». Не «сделай хорошо», а конкретно. Это единственное изменение, которое снимает половину вашего контроля. Я бы начал ровно с него — оно ничего не стоит и работает уже завтра. Как выстроить это системно — и почему то же правило работает с машинными исполнителями, — в бесплатном курсе . Контроль держится на цифрах, которым можно верить. Как их получить — там, где разбирается источник, хозяин и срок обновления каждой цифры . ## Сколько стоит ИИ на самом деле: мои счета, минус $40 за ночь и шлюз учёта URL: https://davidgerstein.pro/blog/skolko-stoit-ii-realnye-rashody/ Дата: 2026-08-01 Направление: Финансы Цифры: −$40 за ночь · ~$300/мес за 100% звонков · 11 сервисов на шлюзе Цифры компании и отдела продаж в этом тексте — обобщённый профиль сервисного бизнеса: 8 менеджеров, оборот ~9 млн ₽/мес, средний чек ~180 тыс. ₽, цикл сделки ~6 недель, всего в компании ~40 человек. Технические расходы на ИИ — реальные, с моего продакшена. Назовите цифру: сколько ваша компания потратила на нейросети в прошлом месяце? Не порядок, не «немного» — цифру. Если вы не можете назвать её прямо сейчас, вы платите вслепую — и это ровно та ситуация, в которой я однажды потерял сорок долларов за одну ночь и узнал об этом утром. Сорок долларов — не деньги. Деньги — это то, что я не знал о них до утра. Значит, с тем же успехом там могло быть четыреста, и я бы тоже узнал постфактум. Когда спрашивают «сколько стоит внедрение ИИ», обычно имеют в виду прайс подрядчика. Я отвечу с другой стороны — со стороны собственных счетов: сколько стоит эксплуатация ИИ в месяц на реальных задачах среднего бизнеса, как эти расходы выходят из-под контроля и как выглядит учёт, который я в итоге построил. Сразу про границы. Я говорю про рабочие процессы компании: оценку звонков, разбор документов, ежедневные сводки. Подписка на сервис, который делает ролики и картинки, устроена по-другому — там платят за штуку контента, и переносить её тариф на рабочий контур бессмысленно. Сколько стоит ИИ: короткий ответ в цифрах Эксплуатация — сотни долларов в месяц , а не миллионы в год: оценка 100% телефонных разговоров обходится нам примерно в $300 в месяц на весь поток, пилот через API — в десятки долларов. Дорого стоит другое: внедрение и время людей на приёмку. И отдельная статья расходов, о которой узнают поздно, — сбой без ограничителя: одна ночь без стоп-крана стоила −$40 . Ночь за сорок долларов Один зациклившийся процесс может сжечь больше, чем весь месячный бюджет на профильную задачу, и вы узнаете об этом случайно, а не по сигналу системы — так у меня появился первый повод считать расходы на ИИ отдельной строкой. Начну с истории, с которой начался мой учёт. Одна строчка кода. Процесс зациклился вечером и до утра гонял запросы к модели. Ничего не упало, никаких ошибок — просто утром баланс оказался на сорок долларов легче. Молча. Без предупреждений. Сорок долларов — не деньги для бизнеса. Проблема в другом: я узнал об этом утром, случайно, посмотрев баланс. Тот же цикл мог крутиться неделю. А через месяц у меня уже одиннадцать сервисов ходили в модели, каждый со своим ключом, и расход был виден одной строкой в конце месяца — без ответа на вопрос, кто именно тратит. Сколько стоит ИИ на практике: порядок цифр по задачам Порядок цифр такой: от нескольких долларов в месяц за лёгкую задачу до примерно 300 $/мес за тяжёлый поток вроде 100% проверки звонков — то есть на два порядка меньше, чем директора обычно ожидают, услышав слово «нейросеть». Цифры мои, с продакшена, округлены. Ваши будут отличаться, но порядок величин — нет. Задача Объём Расход/мес Оценка качества звонков по чек-листу ~177 разговоров в день, 100% потока ~$300 Распознавание и разбор документов поток клиентских комплектов, 79 типов десятки–сотни $, зависит от потока Ежедневная отчётность и аналитика сводки, проверки данных, дайджесты единицы–десятки $ Главный вывод из таблицы: эксплуатация ИИ для среднего бизнеса стоит сотни долларов в месяц, а не миллионы рублей в год. Дорогим бывает внедрение — люди, процесс, калибровка. Сама работа моделей дешева, и дешевеет дальше. На диаграмме — те же три задачи в долларах в месяц, по фактическому расходу. Оценка звонков $300 Разбор документов $150 Отчётность $20 Как это работает по шагам: путь одного звонка до строки расхода От записи разговора до строки в отчёте о расходе — четыре шага и меньше минуты автоматической обработки; каждый шаг оставляет свою запись в логе, поэтому расход виден не только в конце месяца, а на любом отрезке дня. Звонок записывается и сразу уходит в очередь на распознавание речи — без ручной выгрузки. Транскрипт разбирается моделью по чек-листу: скрипт, возражения, запрещённые фразы — по всем ~177 разговорам в день, а не по выборке. Оценка и метаданные (сервис, токены, стоимость запроса) пишутся в шлюз учёта одной транзакцией. Раз в сутки агрегатор считает расход по каждому сервису и сравнивает с лимитом; при превышении — оповещение в мессенджер. Три правила, которые дались деньгами Заберите их себе — вам они достанутся бесплатно, мне обошлись дороже. Три правила ниже стоили мне реальных денег и часов перепроверенной работы: дорогая модель — на исключения, дешёвая — на поток; не экономить на входных данных; и учёт — до первого запуска, а не после первого счёта. 1. Дорогая модель — на исключения, дешёвая — на поток Самая частая ошибка — гонять флагманскую модель на всём подряд. Мы посчитали по фактическим данным, где дешёвая модель справляется не хуже: печатный текст с высоким согласием двух моделей — дешёвая; рукописный или спорный — дорогая; критичные поля — дорогая с проверкой человеком. Решение принимается расчётом на своих данных, а не вкусом. Экономия — в разы при том же качестве на выходе. 2. Не экономить на входных данных Обратная сторона. Я пробовал сжимать аудио и сканы перед обработкой — расход падает, а вместе с ним падает качество расшифровки и распознавания. Дальше эту разницу доплачивают люди: перепроверкой, спорами с несправедливыми оценками, ручным разбором. Экономия на входных данных — самая дорогая экономия из возможных. 3. Учёт ставится до первого запуска, а не после первого счёта После ночи за $40 я перевёл все сервисы на единый шлюз: каждый запрос к моделям идёт через одну точку, расход считается по каждому сервису отдельно, на всплеск приходит оповещение в мессенджер, у сервисов есть лимиты. Одиннадцать сервисов переехали без переписывания их логики. шлюз учёта — расход за сутки 11 сервисов на шлюзе $300 оценка звонков, факт/мес 80% мягкий лимит бюджета −$40 инцидент, одна ночь сервис модель расход, $ статус call-scoring cheap 9.80 doc-parser cheap 22.10 daily-digest cheap 0.60 Где риск Шлюз — единая точка отказа: если он лежит, лежат все сервисы сразу. Ему нужны автоперезапуск и запасной маршрут. И да, это снова правило про автоматизацию, которая обязана следить за собой сама . Скрытые расходы: когда сотрудники платят за ИИ из своего кармана Если сотрудник тратит личные деньги на токены и серверы, чтобы не ждать согласования, — это не инициативность, а сигнал: в компании нет быстрого и понятного пути одобрить небольшой расход на ИИ, и человек решает проблему в обход процесса. У нас так и получилось. Один из разработчиков потратил около 60 тысяч рублей собственных денег на токены и серверы для системы — просто чтобы не останавливать работу в ожидании подписи. Когда это вскрылось, встал вопрос о лимите: ставить максимальный тариф в 10 тысяч рублей в месяц «с запасом на будущее» или смотреть на факт. Факт составил 500 рублей. Установка тарифа «на всякий случай» в двадцать раз выше факта — тот же самый порок, что и полное отсутствие лимита: решение принимается не по данным, а по страху. Вывод простой: лимит и порог согласования должны считаться от фактического расхода за последние недели, а не от абстрактного «пусть будет с запасом». Для мелких сумм — условно, до нескольких тысяч рублей в месяц на сервис — быстрее и дешевле дать сотруднику право тратить без согласования, чем терять время на подпись. Но именно поэтому шлюз учёта обязателен: право тратить без подписи не должно означать «тратить без записи в логе». Быстрые победы: не всё требует расчёта ROI Если настройка автоматизации занимает 20 минут, а устраняет систематическую задержку выплат партнёрам или клиентам, считать окупаемость не нужно — нужно просто сделать это в начале недели, до планёрки. Пример из практики, не про модели напрямую, но из той же категории «автоматизация вместо расчётов»: в реферальной программе партнёры узнавали о положенном вознаграждении с опозданием — только когда клиент сам просил вернуть деньги, ссылаясь на обещание менеджера. Решение заняло около 20 минут работы: бот стал сразу уведомлять партнёра о закрытии проекта его реферала, без ручного контроля со стороны бухгалтерии. Не каждая автоматизация требует таблицы с формулой — иногда достаточно спросить «сколько минут займёт исправить», и если ответ меньше часа, просто сделать это. То же правило применимо к учёту расходов на ИИ: прежде чем заказывать дашборд на неделю разработки, проверьте, нельзя ли закрыть 80% боли одним оповещением в мессенджер за 20 минут — как в примере со шлюзом выше. ИИ-связка: промпт для разбора аномалий расходов Модель, которая раз в сутки читает лог трат по всем сервисам и находит аномалии — скачок токенов, новый сервис без лимита, всплеск у конкретного ключа — экономит ровно то время, которое раньше уходило на ручное сравнение таблиц: обычно 20–30 минут в день у одного человека. У меня это Google Таблица: скрипт раз в сутки выгружает туда лог из шлюза (сервис, дата, токены, стоимость, модель), а отдельная ячейка с промптом отправляет срез за последние 7 дней в модель и получает разбор. Структура входных данных простая — построчный JSON без предварительной агрегации, модель сама считает средние и отклонения. Пример ответа на боевых данных: Дальше — дело техники: если anomalies не пустой, скрипт шлёт это же сообщение в мессенджер. Отдельно эту связку я не считаю новой экономией: она снимает те же 20–30 минут ручной сверки, что и обычный дашборд, просто делает это без участия человека каждый день. Инженерная обвязка: шлюз, лимиты, алерты Обвязка — это единая точка входа для всех вызовов модели, лимиты на уровне сервиса и оповещение при приближении к порогу; без этих трёх элементов учёт превращается в наблюдение за уже случившимся фактом. Шлюз у меня — тонкая прокси-прослойка: каждый из 11 сервисов стучится не напрямую к провайдеру модели, а на внутренний адрес со своим service_id в заголовке. Прокси логирует запрос и потом сама идёт к провайдеру. Если провайдер недоступен — до трёх повторов с задержкой, дальше сервис получает понятную ошибку вместо зависания. Поле лога Пример значения service_id call-scoring timestamp 2026-07-24T03:12:00Z model cheap / expensive tokens_in / tokens_out 4200 / 850 cost_usd 0.031 Лимит настроен на два уровня: мягкий (80% от месячного бюджета сервиса) — только сообщение, жёсткий (100%) — сервис переходит на дешёвую модель или останавливается, в зависимости от критичности задачи. Когда бот находит баг дороже своей собственной стоимости Иногда главная выгода от простого бота — не экономия на людях, а находка технической проблемы, которая иначе всплыла бы через месяцы в виде испорченной отчётности; сам бот при этом стоит единицы долларов в месяц, а цена необнаруженной проблемы не поддаётся быстрой оценке. У нас так вскрылась проблема с CRM: даты создания лидов самопроизвольно менялись при синхронизации. Разработчик настроил бота на ежечасную выгрузку данных и сравнение снимков — и обнаружил, что сделки «мигрируют» в другие дни, сдвиг варьируется от 18 до 36 часов. В интерфейсе CRM версия показывала корректные даты, но через несколько часов цифры расходились сами по себе, без вмешательства человека. Стоимость такого бота попадает в ту же категорию, что и ежедневная отчётность из таблицы выше — единицы-десятки долларов в месяц. Но если бы этот сдвиг не поймали, отчёты о скорости обработки лидов были бы систематически искажены — а решения на основе таких отчётов стоят дороже любого счёта за API. Экономика: что стоит система учёта и что она окупает Настройка шлюза учёта заняла ~8 часов работы разработчика, эксплуатация системы оценки звонков — ~300 $/мес (около 27 000 ₽ по курсу 90), а эффект — высвобождение времени менеджеров, эквивалентное ≈ 240 000 ₽/мес фонда оплаты труда (оценка). Считаю так: менеджер обходится компании примерно в 100 тыс. ₽/мес (оклад, налоги, переменная часть). Для отдела из 8 менеджеров это 800 000 ₽/мес фонда. Если автоматическая проверка 100% звонков снимает 30% рутины по прослушиванию и ручной оценке — той самой, которую раньше делал старший менеджер или сам руководитель отдела, — высвобождается ресурс на 240 000 ₽/мес. Это эффект только автоматической оценки звонков: скрипты продаж, обучение и прочие изменения в отделе в этот расчёт не входят. Масштаб риска, который система должна ловить раньше человека Для масштаба: отдел из 8 менеджеров при обороте ~9 млн ₽/мес и среднем чеке ~180 тыс. ₽ закрывает около 50 сделок в месяц. Если 10% из них зависает — 5 сделок, — риск составляет ≈ 900 000 ₽/мес (оценка). Именно такие зависшие сделки должна ловить проверка 100% потока звонков, а не выборочная: пропущенное в 1 звонке из 10 возражение клиента в выборочном контроле не всплывёт вообще. посчитайте на своих цифрах сделок в месяц средний чек, ₽ % зависших сделок риск ≈ {X} ₽ в месяц формула: сделки в месяц × средний чек × доля зависших; оценка сверху, не догма Что мы не считаем эффектом: если высвобожденные 30% времени менеджеры тратят на то же количество звонков без роста конверсии, или если это время просто перераспределилось на другую рутину без роста продаж и без сокращения часов — это не эффект в деньгах, а перераспределение нагрузки, которое стоит доказывать отдельным замером конверсии до/после. Где это ломается на практике Три ситуации, в которых вы почти наверняка окажетесь, если начнёте считать всерьёз. Каждая из них у меня была. Система учёта и оценки звонков ломается не там, где ждут, — не на самой модели, а на трёх местах: единая точка отказа, ложные срабатывания оценки и цена, зависящая от чужого прайса. Где риск Модель, оценивающая звонки по чек-листу, может системно занижать оценку за нестандартную, но правильную реплику менеджера — и тогда «объективная» оценка становится источником конфликтов внутри отдела продаж, а не инструментом контроля. Нужна калибровка на споре: раз в месяц брать 20 несогласий менеджера с оценкой и разбирать вручную. Второй риск — зависимость от чужого прайса: провайдер модели меняет тарифы, и то, что стоило 300 $/мес, может стать 450 $/мес без предупреждения. Лимиты и оповещения не защищают от роста цены, только от неконтролируемого роста объёма — это разные риски, и закрывать их нужно разными способами: фиксировать тариф в договоре там, где это возможно, и держать план Б на дешёвую модель. Как посчитать бюджет для своей задачи Теперь про ваши цифры. Считать надо не «сколько стоит нейросеть», а сколько стоит одна ваша операция — оценка звонка, разбор документа, сборка отчёта. Дальше умножаете на объём потока и сравниваете с тем, во что эта работа обходится сейчас руками. Бюджет считается не из прайса подрядчика, а из объёма собственного потока: объём в сутки × цена запроса дешёвой и дорогой модели на вашей выборке — и через 15 минут у вас есть цифра, а не ожидание. Возьмите один процесс и посчитайте объём: сколько звонков, документов, писем в день. Прогоните неделю реального потока на дешёвой и на дорогой модели параллельно. Это стоит единицы долларов и даёт вам собственную, а не вымышленную цену качества. Умножьте на месяц и добавьте 30% на рост и повторные прогоны. Поставьте лимит на уровне двух ожидаемых месячных расходов и оповещение на уровне одного. Если подрядчик называет вам стоимость эксплуатации, не спросив объём потока, — он называет случайное число. А если внедрение окупается только при «миллионах операций в будущем» — это не окупаемость, это пилот, который выдают за продакшен . Чек-лист на понедельник Пять действий, которые можно сделать до обеда понедельника, без бюджета на подрядчика и без ожидания «большого внедрения». Прогнать один реальный поток (звонки, документы, письма) через дешёвую и дорогую модель параллельно на 50–100 примерах и сравнить качество. Завести единую точку входа для вызовов модели, даже если сервисов пока два. Поставить лимит расходов на уровне двух ожидаемых месячных сумм и оповещение — на уровне одного. Логировать каждый вызов (сервис, дата, токены, стоимость, модель) в таблицу, а не смотреть общий баланс раз в месяц. Отделить эффект в деньгах от эффекта в часах: если часы фактически не высвободились, эта цифра не идёт в отчёт руководству. Резюме короткое. Видеть, сколько стоит ИИ в вашей собственной операции, — управленческий навык, а не бухгалтерия: пока вы не знаете себестоимость одного звонка или одного документа, вы не можете сказать, окупается ли работа, и любые разговоры о пользе остаются разговорами. Навык ставится один раз и дальше работает на каждой следующей задаче. Сделайте на этой неделе одно: найдите, сколько именно ушло за прошлый месяц и на какие задачи. Даже если это будет неточная прикидка по трём счетам — вы удивитесь, сколько решений станет очевидными сразу после появления этой цифры. У меня стало очевидным, что половину задач надо гонять через модель попроще, — и счёт упал вдвое без потери качества. Как поставить учёт нормально, с разбивкой по сервисам и стоп-краном на превышение, — разбираю по шагам в бесплатном курсе . ## Контроль отдела продаж: как ввести прослушку звонков и не потерять команду URL: https://davidgerstein.pro/blog/kontrol-zvonkov-bez-sabotazha/ Дата: 2026-07-30 Направление: Контроль качества Цифры: цена ошибки сопоставима с годовым бюджетом отдела · 10%→100% охват звонков · 66 звонков на калибровке Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Любой контроль сотрудники встречают одинаково: соглашаются вслух и обходят на практике. Если вы слушаете десятую часть звонков и по ней судите обо всём отделе продаж — у вас нет контроля качества. У вас есть выборка, которая вас успокаивает. Разбираю, как выстроить контроль отдела продаж так, чтобы это не превратилось в тихую войну. Стоимость одной ошибки в контроле качества может достигать величины, сопоставимой с крупным годовым бюджетом компании — на одном клиенте. При этом отдел контроля в лучшем случае охватывает 25% работы бизнеса — не потому что люди плохо работают, а потому что человек физически не прослушает весь поток звонков. Отсюда соблазн отдать контроль отдела продаж нейросети — и слушать не выборку, а весь поток. И отсюда же начинается сопротивление: менеджеры не хотят, чтобы их оценивал алгоритм, логику которого им никто не объяснил. Я видел, как это внедрение проваливается, и видел, как оно получается. Разница не в модели и не в бюджете на API. Разница в том, дали ли менеджерам увидеть, как система принимает решения, до того как решения системы стали влиять на их зарплату. Я сам в первый раз полез сначала в технику — конвейер, промпты, выгрузки — и только потом пошёл разговаривать с людьми. Порядок был неверный, и месяц ушёл на то, чтобы отыграть назад. Так что дальше я пишу не с позиции «делайте правильно», а с позиции человека, который это уже переставлял местами. Как ввести контроль отдела продаж без саботажа Контроль отдела продаж вводят в три такта и строго в этом порядке: сначала разговор с командой, потом письменные правила оценки, и только потом техника. Объявите, что именно меряется, зачем и что будет с результатами — пятнадцать минут честного объяснения экономят месяцы тихого саботажа. Ключевой приём — прозрачность оценки: показывайте цитату из разговора рядом с каждым баллом. Когда человек видит, за какую фразу снижен балл, спорить не с чем: можно только согласиться или объяснить контекст. Ориентир по срокам: калибровочная сессия с каждым менеджером до запуска, выборка от 50–70 звонков на сверку оценки ИИ с ручной и три месяца, когда оба контура работают параллельно, — до этого решения о премиях по автоматической оценке не принимают. Контроль отдела продаж — не слежка за сотрудниками Разница не в жёсткости, а в предмете замера. Слежка меряет человека: скриншоты экрана, трекеры активности, счётчики нажатий клавиш — то есть присутствие. Контроль отдела продаж меряет работу: как прошёл разговор с клиентом, отработано ли возражение, соблюдён ли регламент. Первое ваш сотрудник улучшить не может — он может только имитировать занятость. Второе может, и в этом весь смысл: у оценки есть чек-лист, который менеджер видит и вправе оспорить. Если ваша система не даёт человеку посмотреть, за что ему поставили балл, вы построили слежку и получите ровно то сопротивление, о котором ниже. Почему ваши менеджеры сопротивляются Три причины, и ни одна из них не «им есть что скрывать». Первая причина — оценка нейросети не всегда стабильна. Это не жалоба менеджера, это признание руководителя отдела, который сам внедряет систему: «Оценка, она не всегда адекватна». Один и тот же звонок при повторной обработке может получить разный результат. Если система колеблется сама с собой, доверять ей вслепую — значит плодить конфликты, а не снимать их. Вторая причина — менеджер не понимает, что именно оценивают и по каким данным. Показательный случай из смежной аналитики переговоров: менеджер по продажам не мог разобраться, у кого сколько договоров выставлено и откуда пришли клиенты. Его фраза точно описывает состояние человека перед внедрением любого контроля: «Я не могу с этим работать, я не понимаю, у кого сколько договоров выставлено, что это за клиенты». Когда человек не видит собственных данных в понятном виде, он не поверит и оценке своей работы — даже честной. Третья причина — необъяснённые сбои в системе учёта, которые совпадают по времени с внедрением контроля. В одном случае клиенты видели в списке посещений свои фамилии рядом с именем чужого менеджера. Причину так и не нашли. Это не про чью-то вину — это про то, что необъяснённая несостыковка разрушает доверие к любой автоматике быстрее, чем самая жёсткая, но понятная оценка. Правило Система, которая не может объяснить свою логику менеджеру, не получит от него сотрудничества. Она получит либо саботаж, либо формальное подчинение без реальной помощи в донастройке чек-листов. Как внедрить контроль отдела продаж: механика по шагам Ваш первый шаг вообще не про систему: это встреча с командой, на которой вы объясняете, что и зачем будете мерить. Порядок для вас: сначала разговор, потом правила, и только потом техника. Любая перестановка даёт саботаж. Ниже — последовательность, которую можно повторить с любой командой продаж, не привязываясь к конкретной CRM. Меняется инструмент, логика — нет. Источник данных. Звонки и записи встреч выгружаются из CRM (в фактуре — Bitrix24) в единое хранилище: Google Drive или отдельный бакет. Триггер выгрузки — заполнение обязательного поля с аудиозаписью на этапе сделки «встреча проведена». Без этого триггера система либо ловит холостые звонки, либо пропускает нужные. Транскрибация. Аудио прогоняется через сервис распознавания речи, текст сохраняется отдельно от таблицы с оценками — полный текст в Drive, в таблице только ссылка. Это защита от обрезания транскрипта лимитом ячейки, о которой ниже. Классификация звонка. Дешёвая модель определяет тип разговора: первичный звонок лида, звонок продаж, вторичный контакт и так далее — всего в практике встречается до 10 сценариев, под каждый свой чек-лист. Оценка по чек-листу. Дорогая модель получает транскрипт, тип звонка и релевантный чек-лист, выставляет оценку по каждому пункту, определяет менеджера по имени в записи. Свод результатов. Оценки собираются в личный кабинет руководителя продаж — сводная таблица по менеджерам, дельта отклонений от ручной проверки, алерты о нарушениях регламента (например, превышение времени молчания). Разбор. Руководитель раз в неделю смотрит проблемные зоны по чек-листу, раз в месяц — калибрует систему на конкретных звонках с менеджерами. Всё в этой цепочке держится на шаге 1. Если триггер выгрузки зависит от того, переведёт ли менеджер сделку на нужный этап вовремя, система будет захватывать не все звонки. Заставлять менеджеров быть дисциплинированнее — плохое решение. Правильное — сделать поле с аудиозаписью обязательным для перехода на следующий этап сделки, тогда дисциплина встроена в саму CRM, а не держится на памяти человека. Похожая логика разбиралась в материале о том, как менеджеры не вносят данные в CRM без репрессий. ИИ-связка: конвейер, промпт и обвязка Технику показываю коротко: в вашем случае она вторична, главное — то, как вы её объявите команде. Кому инженерная часть нужна подробно — устройство контура целиком: выгрузка, расшифровка, чек-листы, экономика . Схема конвейера в текстовом виде: CRM (Bitrix24) — выгрузка звонка по триггеру Хранилище (Drive) — аудио + полный транскрипт Дешёвая модель — классификация типа звонка Дорогая модель — оценка по чек-листу Таблица + кабинет — свод, дельта, алерты На шаге классификации ставится дешёвая модель — задача простая (определить один из 10 типов звонка по первым репликам), переплачивать за неё дорогой моделью бессмысленно. На шаге финальной оценки по чек-листу — дорогая модель: там нужно удерживать контекст всего разговора, включая предыдущие звонки с этим же клиентом, и не терять нюансы тона и возражений. Пример промпта для второго шага — оценки встречи по чек-листу. Платформа — Google Apps Script, который вызывает API модели и пишет результат обратно в Google Таблицу, откуда его забирает личный кабинет руководителя. Пример ответа модели: Инженерная обвязка. Скрипт крутится по расписанию (триггер Apps Script раз в час), забирает список звонков из Bitrix24 REST API за период, где заполнено поле аудиозаписи и ещё нет оценки. При ошибке вызова API (лимит, таймаут, пустой транскрипт) скрипт не падает молча — пишет статус в отдельную колонку и шлёт алерт в тот же Telegram-бот, который уже используется для оповещений о задержках ответов менеджеров. Повторный запуск — по следующему тику расписания, без ручного вмешательства. Отдельно логируется стоимость каждого вызова API — это тот же контур, что описан в материале о том, сколько реально стоит ИИ в месяц , включая ночь с циклическим запросом на заметную для месячного бюджета сумму из-за бага в коде — ошибка, которая случилась именно на этапе отладки такого пайплайна. Калибровочная сессия: снимаем сопротивление заранее Час вашего времени, который экономит месяцы. Сажаете команду и вместе оцениваете три записи по чек-листу — расхождения обсуждаете сразу. Работающий приём — калибровочная сессия с каждым менеджером до массового запуска. Руководитель разбирает одну конкретную встречу: показывает автоматическую оценку, показывает чек-лист, по которому она выставлена, и вместе с менеджером обсуждает, где они согласны, а где нет. Это не оправдание системы перед сотрудником — это способ получить от менеджера расхождения, которые лягут в донастройку промпта и чек-листа. Менеджер видит: его не наказывают анонимным алгоритмом, а спрашивают его мнение как эксперта. Из объекта контроля он становится соавтором чек-листа — и это ровно та грань, которая отделяет внедрение с поддержкой команды от внедрения, которое тихо саботируют. Стандарты обслуживания нужны раньше алгоритма Калибровка не работает, если стандарты обслуживания не сформулированы заранее. Нельзя оценивать звонок по критериям, которые никто не проговорил вслух. В одном случае отделу продаж и сопровождения поручили совместное совещание, чтобы выработать единую коммуникационную стратегию — как одинаково информировать клиентов о задержках, чтобы не получился «сломанный телефон» между отделами. Пока стандарт живёт в голове каждого менеджера по-своему, любая автоматическая оценка воспринимается как произвол. Проверка методологии: 66 звонков Ваш ориентир по объёму выборки: несколько десятков звонков достаточно, чтобы увидеть системные расхождения. Отдельная категория проблем — не человеческая, а методологическая. Прежде чем масштабировать оценку на всех менеджеров, по каждому звонку фиксируется, как его оценила нейросеть и как оценил человек из отдела контроля качества, и считается дельта отклонения. За месяц набралось 66 звонков с ручной оценкой параллельно с автоматической. Это не недоверие к ИИ ради недоверия — это способ понять, где система систематически ошибается, до того как её результат станет основанием для решений о зарплате или увольнении. Так выглядит фрагмент кабинета руководителя, куда стекаются результаты конвейера — с реальным примером звонка из промпта выше: Кабинет руководителя отдела продаж 66 звонков в выборке дельты 3 мес двойного контроля 10 чек-листов по типам звонков Звонок Менеджер Оценка ИИ Нарушение Статус CR-10452 Иванов И.И. 62 молчание 41 сек … … … без нарушений Руководитель, который отвечает за стратегию автоматизации, формулирует условие жёстко: «Я не готов автоматизировать контроль качества, потому что я не понимаю, работает ли методология, и я не понимаю, сколько это будет стоить. Пока нет цифр, пока нет доказанной эффективности, я не готов». Это здоровая позиция, а не перестраховка. Подробный разбор того, что стоит проверять до полного доверия автоматической оценке звонков, я делал отдельно — 7139 оценок и $300 в месяц: честный отзыв о системе . Три месяца двойной работы — это не потеря, а страховка Практика, которая повторяется в разных внедрениях: систему запускают не менее чем на три месяца параллельно с ручным контролем. Это значит двойной расход бюджета на этот период — платите и за ИИ-оценку, и за штат контроля качества одновременно. Неприятно, но альтернатива хуже: отключить ручной контроль раньше и начать принимать решения по людям на основе методологии, которая ещё не проверена. Этап внедрения Что происходит Риск, если пропустить Калибровочная сессия Разбор одной встречи с менеджером, сверка оценки ИИ и мнения человека Менеджеры саботируют систему как «чёрный ящик» Параллельная оценка (66+ звонков) Сравнение оценки ИИ и ручной, расчёт дельты Решения о людях принимаются на непроверенной методологии 3 месяца двойного контроля Оба контура работают одновременно, бюджет на период удваивается Раннее отключение ручного контроля скрывает системные ошибки ИИ Полное развёртывание 100% охват звонков, сокращение штата контроля качества Без предыдущих этапов — повтор истории про потерю крупной суммы на одной ошибке На диаграмме — рост охвата контроля после внедрения речевой аналитики: было 10% вручную (нижняя граница диапазона 10–25%, в который упирается ручной контроль), план — 100%. 10% было 100% план Выборочные 10% звонков вручную — против 100% охвата с речевой аналитикой на нейросетях (данные из практики внедрения). Ловушки, похожие на саботаж Прежде чем обвинять людей, проверьте технику: у нас часть «нарушений» оказалась сбоями записи. Часть сопротивления менеджеров на самом деле вызвана не недоверием к идее, а конкретными техническими сбоями, которые система выдаёт за «объективную оценку». Транскрибация обрезалась из-за лимита символов в ячейке Google-таблицы. ИИ оценивал неполный текст звонка и выносил вердикт по обрубленной версии разговора. Решение простое: в таблицу кладут короткий фрагмент и ссылку на полный текст, который открывается отдельно. Система не всегда понимает, какой именно звонок нужно оценивать в цепочке взаимодействий с клиентом: «Проблема любой АИ, которая связана с любой CRM, заключается в том, что как система должна понять, что это именно тот звонок, который нужно оценить». Первый звонок может быть холостым, следующий — система не захватывает, менеджер не всегда переводит сделку на нужный этап. Решение оказалось не в дисциплине менеджеров, а в инженерии: автоматическая выгрузка всех звонков из CRM с уникальными ID — сущность, менеджер, время. Триггером для выгрузки встречи служит заполнение обязательного поля с аудиозаписью на этапе «встреча проведена». Систему заставили анализировать контекст предыдущих звонков с тем же клиентом, а не оценивать разговор в вакууме. Ещё один нюанс: готовых коробочных решений, которые сами сегментируют тип звонка и подключают к каждому типу отдельный промпт, на рынке нет. В разбираемой практике используется 10 разных чек-листов под разные сценарии — первичный звонок лида, звонок продаж, вторичный контакт. Это не разовая настройка, а живой процесс: внедрение шло уже четвёртый месяц и требовало постоянных доработок. Похожая история — про автоматизацию, которая требует постоянного надзора: контроль качества звонков из той же породы решений. Где ломается Любая автоматическая оценка звонков спотыкается на стыке с CRM: система не знает, какой звонок оценивать, если менеджер не переводит сделку по этапам вовремя, и не знает, что оценивает обрезанный текст, если транскрипт превышает лимит ячейки таблицы. Чинить это дисциплиной менеджеров бесполезно — чинить нужно инженерией: уникальные ID звонков, обязательные поля-триггеры, вынос полного текста за пределы таблицы. Экономика: что это стоит и что даёт вам Считайте не только деньги: главные ваши затраты здесь — время на разговоры с командой, и они окупаются лучше всего. Возьмём условную компанию из легенды этого разбора: отдел из 15 менеджеров, оборот ~18 млн ₽/мес, средний чек ~90 000 ₽. Это не цифры реального клиента из фактуры, а модельный расчёт для формулы — подставьте свои значения и получите свою оценку. Формула 1. Сколько стоил бы ручной контроль при 100% охвате. (число звонков в месяц) × (минут на разбор одного звонка) ÷ 60 × (ставка контролёра в час) = стоимость полного ручного контроля в месяц. Подставляем: 15 менеджеров × 20 звонков/день × 22 рабочих дня ≈ 6 600 звонков в месяц. Разбор одного звонка с занесением в чек-лист занимает у контролёра в среднем 10–15 минут — возьмём середину, 12,5 минуты. Итого: 6 600 × 12,5 ÷ 60 ≈ 1 375 часов в месяц. При типовой ставке контролёра качества ~1 000 ₽/час (оценка) это выливается в сумму около 1 375 000 ₽ в месяц — эквивалент почти девяти штатных контролёров, работающих полный день, только на то, чтобы прослушать входящий поток. Именно поэтому на практике отдел контроля физически ограничивается 10–25% потока — не от лени, а потому что 100%-й ручной охват для такого объёма экономически нерентабелен без кратного расширения штата. Формула 2. Цена пропущенной ошибки. (поток контактов в месяц) × (доля, конвертирующаяся в сделку) × (доля сделок, которые портит необнаруженная ошибка в скрипте) × (средний чек) = упущенная выручка в месяц. Подставляем консервативно: 6 600 контактов × 3% конверсии в сделку (оценка, отраслевая усреднённая, в вашем случае может быть выше или ниже) ≈ 198 потенциальных сделок в месяц — это близко к фактическому объёму сделок легендированной компании: заявленный оборот ~18 млн ₽/мес при среднем чеке ~90 000 ₽ даёт те же ~200 сделок. Если необнаруженная вовремя ошибка в скрипте (пропущенное возражение, нарушенный регламент) портит всего 2% из них — это 4 сделки на средний чек 90 000 ₽, то есть около 360 000 ₽ упущенной выручки в месяц (оценка, зависит от реальной конверсии и цикла сделки). Это тот порядок величины, который стоит за фразой «сотни тысяч рублей риска» — не абстракция, а расчёт с консервативными допущениями. Формула 3. Экономия на ФОТ после автоматизации. (число высвобождаемых ставок) × (часы полной занятости в месяц) × (ставка в час) = экономия ФОТ в месяц. В разбираемой практике после настройки автоматической оценки планируют отказаться минимум от двух штатных единиц отдела контроля качества. Подставляем: 2 ставки × ~160 часов/мес × 1 000 ₽/час ≈ 320 000 ₽ экономии ФОТ в месяц (оценка). Это то, что раньше уходило на ручное прослушивание выборки в 10–25% звонков; конкретная сумма экономии компании из фактуры напрямую не раскрывается, это расчётная величина при указанных допущениях. Формула 4. Что съедает экономию — стоимость самого ИИ-контура. Эксплуатация ИИ-контура не бесплатна. В похожем по объёму проекте (7139 оценок в месяц) она составляла порядка $300/мес на инфраструктуру и вызовы моделей — цифра из другого кейса, не из текущего расчёта напрямую, но как ориентир масштаба полезна. В рублях (~27 000 ₽/мес по курсу ~90 ₽/$) это около 2% от стоимости полного ручного контроля (1 375 000 ₽) и заметно меньше экономии ФОТ по формуле 3. Даже если удвоить эту сумму на риск нештатных расходов, она остаётся на порядок меньше высвобождаемого ФОТ — окупаемость по грубой прикидке достигается в первый же месяц эксплуатации, если методология уже прошла проверку дельтой. Отдельно стоит закладывать риск разовых инцидентов: у меня циклический запрос из-за бага в коде за одну ночь обошёлся в сумму порядка нескольких тысяч рублей. Это моя недоработка: я не поставил потолок расходов на контур, прежде чем оставить его работать без присмотра. Сумма небольшая — примерно как один рабочий день контролёра качества, — но именно она заставила пересмотреть готовность системы к продакшену без мониторинга расходов. На диаграмме ниже — сопоставление денежных порядков этих четырёх формул: во сколько раз риск ошибки и экономия ФОТ меньше стоимости полного ручного контроля, и насколько дёшева на этом фоне сама эксплуатация ИИ-контура. Ручной контроль 100% потока 1 375 000 ₽ — базовый уровень Риск пропущенной ошибки ~360 000 ₽ (~26% от базового) Экономия ФОТ после ИИ ~320 000 ₽ (~23% от базового) Эксплуатация ИИ-контура ~27 000 ₽ (~2% от базового) Оценка для типового отдела из 15 менеджеров по формулам выше — не факт из отчётности конкретного клиента. Показатель Значение (оценка) Как считали Поток контактов на 15 менеджеров ≈ 6 600 звонков/мес 15 × 20 звонков/день × 22 раб. дня Ручной разбор 100% потока ≈ 1 375 часов/мес 6 600 × 12,5 мин ÷ 60 Текущий ручной охват на практике 10–25% физический предел человеко-часов ОКК Стоимость полного ручного контроля ≈ 1 375 000 ₽/мес 1 375 ч × 1 000 ₽/час Риск пропущенной ошибки в скрипте ≈ 360 000 ₽/мес 6 600 × 3% конверсии × 2% сорванных сделок × 90 000 ₽ Экономия ФОТ после автоматизации ≈ 320 000 ₽/мес 2 ставки × 160 часов × 1 000 ₽/час Эксплуатация ИИ-контура ≈ 27 000 ₽/мес ориентир $300/мес из другого проекта аналогичного объёма Риск нештатных расходов от нескольких тысяч рублей за инцидент кейс: циклический запрос из-за бага за одну ночь Период двойного бюджета 3 месяца параллельная работа ИИ и ручного контроля до валидации методологии Важная оговорка про смешение эффектов: за пару месяцев из реанимации невключившихся клиентов удалось вытащить сумму, заметную на фоне месячного оборота отдела — это результат отдельной инициативы по повторному контакту с базой, а не самого контроля качества звонков. Смешивать эти два эффекта нельзя: контроль качества снижает риск потери сделок из-за плохого разговора (формула 2 выше), а реанимация — отдельный процесс дожима уже потерянных лидов, у него свой бюджет и своя команда. Вклад именно контроля качества в выручку в фактуре напрямую не измерен и требует отдельного A/B-сравнения после трёх месяцев параллельной работы — до этого момента любые цифры выше остаются оценкой с консервативными допущениями, а не фактом из отчётности. Ваш чек-лист на понедельник Первые два пункта — разговоры, не техника. Сформулировать стандарт обслуживания письменно — на одном совещании отделов продаж и сопровождения, а не по памяти каждого менеджера. Сделать поле с аудиозаписью обязательным для перехода сделки на этап «встреча проведена» — это единственный надёжный триггер выгрузки звонков. Выбрать 2–3 типа звонков для старта (не все 10 сразу) и написать под них чек-листы вместе с руководителем продаж. Запустить параллельный контур: ИИ-оценка + ручная оценка тех же звонков, минимум 50–70 штук для первой выборки дельты. Провести калибровочную сессию с каждым менеджером до того, как оценки начнут влиять на премию. Посчитать свою версию формул выше — с вашим потоком звонков, вашей ставкой контролёра и вашим средним чеком — и зафиксировать бюджет на 3 месяца двойной работы с датой решения: масштабировать, донастраивать или остановить. Контроль отдела продаж — не про то, чтобы поймать менеджера на ошибке. Это про то, чтобы увидеть отдел продаж целиком, а не выборочную четверть. Но когда система в первый раз ошибётся — а она ошибётся, — её будет некому защищать. Разве что тем, кто с самого начала понимал, почему она посчитала именно так. О более широкой картине того, почему технически готовые внедрения буксуют на людях, я писал в материале почему внедрение ИИ не работает — хотя технически всё запустилось . И назову вещь своим именем. Умение объяснить машине, что в вашей компании считается хорошим разговором с клиентом, — это новый управленческий навык, и осваивать его придётся вам, а не подрядчику. Промпт напишут за деньги. Навык руководителя — другое: сформулировать стандарт так, чтобы его одинаково поняли и человек, и модель, а потом выдержать три месяца двойного бюджета, пока дельта на выборке в 66 звонков не станет предсказуемой. Руководитель, который это умеет, видит весь отдел продаж целиком. Руководитель, который не умеет, видит десять процентов звонков и называет это контролем. Разница в цене такого руководителя будет расти каждый год. Ваше первое действие — не настройка системы, а разговор с командой: что меряем, зачем, что будет с результатами. Пятнадцать минут честного объяснения экономят месяцы сопротивления. Как выстроить контроль, который принимают, — в бесплатном курсе для руководителей . И последнее, что стоит вам запомнить: сопротивление снимается не жёсткостью, а прозрачностью. Покажите людям, за что именно им ставят балл, — и спор о справедливости прекращается сам. ## Протокол планёрки, который пишется сам URL: https://davidgerstein.pro/blog/protokoly-planerok-avtomatom/ Дата: 2026-07-27 Направление: Операционное управление Цифры: ~70 часов в месяц экономии для отдела из 15 менеджеров (оценка) · время на переспрашивание сокращается в разы с автопротоколом · окупаемость около 1–2 месяцев Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Половина решений с ваших планёрок теряется в течение недели. Не потому что люди безответственные — потому что никто их не записал, а память у всех своя. Если вы через три дня после планёрки переспрашиваете собственных сотрудников, о чём же вы там договорились, — у вас нет протокола. У вас есть коллективное воспоминание, и оно расходится с реальностью тем быстрее, чем больше людей сидело в переговорке. Плохо не то, что вы что-то забыли. Плохо, что вы не можете проверить, кто прав. У меня есть цитата от финансового сотрудника, которую я храню как напоминание себе: «Я бы хотел погруженно работать — взял задачу, погрузился, час ей занимался. А в большинстве случаев, если мне 15 минут удалось что-то поделать без перерыва — это невероятная удача». Дело не в перегрузке. Дело в том, что человека дёргают вопросами, ответы на которые уже прозвучали на планёрке пять минут назад — просто их никто не записал. Автоматический протокол планёрки — не бюрократическая прихоть для галочки, а способ вернуть людям эти самые 15 минут концентрации. Обратный пример из той же компании: руководителя отдела разработки просто не звали на технические планёрки по внедрению ботов и автоматизации — хотя эти задачи напрямую касались его работы. Собственник узнал об этом случайно и назвал упущением. Причина проста: не было единого места, куда стекались бы решения со всех встреч. Кого не позвали — тот не в курсе, а переспрашивать неудобно. Протокол, который расходится сам, без участия человека на этапе набора текста, закрывает и эту проблему тоже — не только проблему забытых задач. Как автоматически составить протокол планёрки Протокол планёрки — рабочая запись встречи из трёх списков: решения, задачи с ответственным и сроком, вопросы без ответа. Собрать его автоматически можно так: запись встречи → расшифровка речи → постановка задачи машине «сделай протокол из этих трёх списков». Обязательная строка в постановке — «если срок или ответственный не назван, пометь и не придумывай». Экономия на отделе из 15 человек — порядка 70 часов в месяц (оценка), и не на письме протокола, а на том, что решения перестают переспрашивать заново. Зачем вам протокол планёрки Не для отчётности. Для того, чтобы через неделю вы могли проверить, сделал ли ваш человек то, о чём договорились, — не по памяти, а по записи. Без протокола планёрка живёт ровно до момента, пока участники не разошлись по делам. Дальше начинается пересказ по памяти, и каждый помнит немного своё. Я видел, к чему это приводит на уровне данных: при попытке выгрузить список клиентов одного региона из воронки CRM получили несколько разных чисел, заметно расходящихся между собой. Причина — децентрализованное хранение информации, никто не сверялся с единым источником. С задачами из планёрок работает тот же механизм: если протокол не зафиксирован автоматически сразу после встречи, каждый участник уносит свою версию договорённостей, и через неделю выяснить, кто прав, уже нельзя. Похожий конвейер в компании уже отработан для другой задачи — автопостинга в соцсеть. Менеджеры записывают голосовое сообщение по итогам дня, оно попадает на единый агрегат, транскрибируется, упаковывается в пост и публикуется без участия человека. Единственная сложность там — заставить людей ежедневно наговаривать рефлексию, техническая часть работает стабильно. Протокол планёрки строится по той же логике: запись → расшифровка → структура → распределение. Меняется только то, что упаковывается на выходе: не пост для соцсети, а список задач со сроками и ответственными. Шаблон протокола планёрки: что должно быть в каждом Протокол работает, если в нём всегда одни и те же поля — тогда его можно и собирать машиной, и читать по диагонали. Наш набор такой: Дата, участники, кто вёл — чтобы через месяц было понятно, с кого спрашивать. Повестка — пункты, которые собирались обсудить. Расхождение повестки и обсуждённого — сам по себе диагноз. Решения — что постановили, отдельно от обсуждения. Формулировка в прошедшем времени: «решили», а не «обсудили возможность». Задачи: что, кто, к какой дате — три поля обязательны. Задача без имени и даты через неделю не существует. Вопросы без решения — то, что не закрыли. Этот блок переносится в повестку следующей встречи автоматически. Машина собирает такой протокол из расшифровки за минуты. Но заполнить поле «кто и к какой дате» она может только тем, что прозвучало вслух: если на встрече не назвали имя и срок, в протоколе будет пусто — и это тоже полезный сигнал. Механика по шагам Соберёте за день. Вам понадобится запись встречи и одна постановка задачи для машины — ни того, ни другого покупать не нужно. Раскладываю конвейер на шаги, которые можно повторить на своей команде без отдельного штата разработчиков. Протокол — удачный первый кандидат: процесс частый, ошибка в нём стоит дёшево, а результат виден всему отделу, то есть ровно те признаки, по которым выбирают процесс и доводят его до эксплуатации . Запись. Планёрка идёт в Zoom, Google Meet или просто на диктофон в переговорке. Источник аудио не принципиален — важно, чтобы запись велась постоянно, а не «когда вспомнили». Расшифровка. Аудио уходит в сервис распознавания речи. Для старта не нужно ничего разрабатывать: Яндекс SpeechKit и Salute Speech от Sber дают разметку по спикерам из коробки через обычный API-запрос, платите за минуты записи — удобно, если планёрок немного. Если записей много и хочется считать не в минутах, а в разовой настройке, — Whisper (открытая модель, можно развернуть на своём сервере) обходится дешевле в пересчёте на час при большом потоке, но требует один раз настроить инфраструктуру. На выходе в любом случае — транскрипт с таймкодами и, желательно, разметкой по спикерам. Структурирование. Транскрипт подаётся в языковую модель с промптом, который вытаскивает поручения: что сделать, кто отвечает, к какому сроку, на какой минуте это прозвучало. Передача в систему. Результат — не текст в чате, а структурированные записи, которые скрипт кладёт в CRM или таск-трекер через вебхук: задача, ответственный, дедлайн, ссылка на исходный фрагмент записи. Просмотр человеком. Руководитель или проект-менеджер один раз в день получает сводку: что добавилось, что просрочено, что требует подтверждения — и подтверждает или правит вручную. Последний шаг — не формальность. Без него автоматизация превращается в чёрный ящик, который никто не контролирует — с похожими последствиями я уже сталкивался на другой автоматизации в этой же компании, речь о ней ниже, в разделе про надзор. ИИ-связка: промпт, модель, обвязка Возьмите эту постановку как основу и подставьте свои разделы протокола: у вас может быть другой набор, важен принцип. Расшифровка сама по себе — самая дешёвая часть цепочки, около 2 000 ₽ в месяц при ежедневной получасовой планёрке. Дороже интеграция: связать запись с CRM, таск-трекером, распределить задачи по людям. И вот здесь легко переплатить, даже не заметив этого. В одной команде разработчик гонял тяжёлую модель (Opus) на задачах, которые дешёвая версия (Sonnet) решала одинаково хорошо. Проверили на одном и том же промпте — результат оказался идентичным. Для выделения задач из транскрипта планёрки это прямое указание: не нужна самая дорогая модель, чтобы превратить текст в список поручений. Дорогая модель имеет смысл там, где есть более глубокая смысловая нагрузка — например, оценка качества переговоров с клиентом, а не структурирование внутренней планёрки. Вот рабочий промпт для этапа «выделение задач из транскрипта». На входе — транскрипт с таймкодами и именами спикеров, полученный от сервиса распознавания речи. Модель — Sonnet или её аналог: задача чисто структурная, переплачивать за более тяжёлую модель здесь бессмысленно. Пример ответа модели на реальный кусок транскрипта планёрки, где обсуждали расхождения в выгрузке клиентов по региону: Смотрите: по первой задаче модель честно написала «уточнить» вместо того, чтобы придумать ответственного, — имя на записи просто не прозвучало. Такое поведение нужно закладывать в промпт явно, иначе модель начнёт галлюцинировать исполнителей. Вот как эти две задачи выглядят уже после того, как скрипт разложил их по CRM — так руководитель видит их в системе, а не в чате: Задачи из планёрки · CRM 2 задачи из транскрипта 1 ответственный не назван 1 срок подтверждён Задача Ответственный Срок Статус Свести три выгрузки клиентов по региону в один отчёт уточнить не назван Проверить настройки фильтра воронки в CRM Ирина 2026-07-29 Формат вебхука и структура очереди — для тех, кто будет собирать это руками JSON от модели не летит в CRM напрямую — между ними должна быть буферная очередь, иначе одна кривая расшифровка положит задачи с ошибками без возможности откатить. Практическая схема, которую я видел рабочей: Скрипт получает JSON-массив от модели и построчно пишет его в промежуточную таблицу (можно на первое время в Google Sheets, дальше — в БД): столбцы id, task_text, owner_raw, deadline_raw, timecode, confidence, status . Статус по умолчанию — pending . Отдельный воркер раз в 5–10 минут разбирает записи со статусом pending . Если confidence = low или owner_raw = «уточнить» — запись уходит в manual_review , задача не создаётся автоматически, а в Telegram руководителю приходит карточка с кнопками «создать» / «отклонить». Если confidence = high и имя из owner_raw находится в справочнике сотрудников (простой маппинг «имя → ID ответственного в CRM»), воркер отправляет задачу через API и меняет статус на sent , сохраняя ID созданной задачи для сверки при аудите. Пример запроса на создание задачи через REST-вебхук Bitrix24 (метод tasks.task.add ) для второй строки из примера выше: Для amoCRM логика та же, меняется только эндпоинт и поля: задача создаётся через API amoCRM в сущность «задачи» с привязкой к сделке по ID, а не через отдельный сервис задач, как в Bitrix24. Выбор платформы не принципиален — принципиально то, что между JSON от модели и записью в системе стоит очередь с проверкой уверенности, а не прямой пайп «расшифровал → создал». Если JSON невалиден или больше половины пунктов получили confidence «low» — система не создаёт задачи молча, а шлёт алерт в Telegram ответственному за автоматизацию: транскрипт кривой, нужно посмотреть руками. Перезапуск — по той же записи повторным вызовом, без пересборки всей цепочки. Где ломается Модель на слух путает похожие фамилии и созвучные цифры — особенно если участники говорят одновременно или запись сделана через плохой микрофон. Это не баг конкретного промпта, а ограничение распознавания речи в принципе. Решение то же, что для любой автоматизации: выборочная проверка, а не слепое доверие результату. Как задачи из совещания перестают теряться Ваше правило: задача без имени и срока в протоколе помечается как непоставленная. Это дисциплинирует участников быстрее любых напоминаний. В одной компании я видел рабочую конструкцию для этого — ежедневную сводку. Все встречи, записи и задачи агрегируются в одно резюме, которое приходит в Telegram со scoring по должностям и автоматическим распределением новых задач. Руководитель не читает протокол планёрки целиком — он получает уже отфильтрованный список: что касается лично его, что нужно передать дальше, что закрыто. Отдельно там же работает принцип для рутинных действий: каждое выполняемое задание либо документируется в виде инструкции, либо записывается на диктофон для последующей расшифровки. После трёх итераций — неправильно, неправильно, правильно — действие закрепляется инструкцией, и к вопросу больше не возвращаются. Тот же принцип применим к планёркам: не полагаться на память человека, фиксировать один раз и переиспользовать. Что именно должно попадать в протокол Формулировка задачи — не «обсудили», а «сделать X»; Ответственный — конкретное имя, не отдел целиком; Срок — дата, а не «в ближайшее время»; Ссылка на источник — таймкод записи, чтобы можно было проверить контекст. Без последнего пункта протокол превращается в пересказ, который через неделю нельзя проверить — а это именно то, что происходило с несколькими разными выгрузками по одному и тому же региону: никто не мог сказать, какая цифра верна и откуда она взялась. Задача конвейера Что нужно Где обычно переплачивают Расшифровка голоса в текст Яндекс SpeechKit / Salute Speech / Whisper на своём сервере Тяжёлая модель без необходимости Выделение задач из текста Дешёвая языковая модель (Sonnet и аналоги) + чёткий промпт Ручной перебор текста человеком Распределение задач по людям Интеграция с Bitrix24 / amoCRM через вебхук Копирование вручную в разные чаты Контроль исполнения Точки контроля и чеклисты Повторные напоминания в личке Вот как обычно распределяются трудозатраты на внедрение такого конвейера с нуля — по опыту, не точные часы: Настройка расшифровки ~10% Промпт для выделения задач ~20% Интеграция с CRM/трекером ~50% Обучение команды пользоваться ~20% На диаграмме — доля трудозатрат по каждому этапу настройки конвейера: больше всего времени уходит не на расшифровку и не на промпт, а на интеграцию с CRM или таск-трекером. Больше про экономию на моделях и реальные счета за токены я разбирал в статье о реальных расходах на ИИ — там же пример, когда правильная настройка лимитов сэкономила около 50 000 ₽ за одну ночь просто на выборе модели. Экономика: что это стоит и что даёт Настройка конвейера «запись → расшифровка → задачи в CRM» — это около 40 часов интеграции при ставке подрядчика ~2 000 ₽/час (≈80 000 ₽ разово), эксплуатация — около 2 000 ₽/мес на транскрибацию, эффект — примерно 70 000 ₽/мес высвобожденного времени менеджеров (оценка). Формула для прикидки своего случая словами: (число участников планёрки) × (минуты, которые в среднем уходят у каждого на переспрашивание задач в день) × (рабочих дней в месяц) / 60 = часы потерь в месяц; умножьте результат на свою почасовую ставку — получите сумму, которую сейчас незаметно съедает отсутствие протокола. Возьмём условный отдел из 15 менеджеров сервисной компании с оборотом около 12 млн ₽/мес и ежедневной 30-минутной планёркой. Без протокола каждый в среднем тратит около 15 минут в день на то, чтобы переспросить у коллеги или руководителя, что именно решили и кто за что отвечает — это ровно та ситуация, которую описывал финансовый сотрудник в начале статьи. Подставляем в формулу: 15 менеджеров × 15 минут × 22 рабочих дня / 60 ≈ 82 часа в месяц, потерянных на одном отделе. При ставке рабочего часа ~1 000 ₽/час это около 82 000 ₽ в месяц — только на переспрашивание, без учёта цены забытых договорённостей, если из-за них зависла сделка или не выставлен вовремя счёт. ~15 мин/день без протокола ~2 мин/день с автопротоколом Прикидка по времени на уточнение задач после планёрки, не абсолютные внутренние данные компании. Похожий паттерн уже встречался в той же компании в другой роли: аналитик отдела тратила около 30 минут в день на ручное заполнение ежедневного отчёта — основной показатель, средний чек, конверсия, — пока не подключили автоматическую выгрузку этих цифр из CRM. Масштаб другой, и вклад этой отдельной меры в общий результат компании отдельно не выделялся — но механизм тот же: ручной перенос данных из одного места в другое крадёт время, которое конвейер с ИИ возвращает на содержательную работу — будь то анализ отчёта или содержание самой планёрки. Стоимость эксплуатации не в расшифровке — она обходится примерно в 2 000 ₽ в месяц при разумном выборе модели, о чём и говорит история с Opus и Sonnet, давшими идентичный результат на одном промпте. Основные деньги уходят один раз: на интеграцию с CRM или таск-трекером и на настройку промпта под структуру конкретных планёрок компании. Откуда берётся раскладка трудозатрат на весь конвейер — не с потолка, а прямая раскладка по этапам с диаграммы выше, для интеграции среднего уровня сложности (одна CRM, один таск-трекер, без кастомных полей и без переписывания структуры данных): настройка и тест расшифровки — меньшая часть общего объёма (10%), доводка промпта на 10–15 реальных записях планёрок — заметно больше (20%), интеграция с CRM через вебхук — аутентификация, маппинг сотрудников на ID ответственных, обработка ошибок, буферная очередь, тестирование на боевых данных — основная часть работы (50%), обучение команды пользоваться и первые недели поддержки — ещё одна пятая часть (20%). Если CRM кастомная, полей для задач нет вообще или нужна интеграция сразу с двумя системами — время на интеграцию вырастет в полтора-два раза, и окупаемость ниже сдвинется соответственно. Дальше это около 70 часов высвобожденного времени в месяц на отдел из 15 менеджеров (82 часа минус 11 часов, которые остаются на уточнение и после автопротокола), которые больше никому не нужно объяснять заново — задача уже лежит в системе со сроком и ответственным. Что не считаем эффектом: если высвобожденные часы менеджеров просто перераспределяются на другую работу без роста числа закрытых сделок — это не доход, а перераспределение времени. В деньги эффект превращается только там, где время реально высвобождается, а не тратится на замену той же самой работы. Окупаемость по грубой прикидке: при ставке подрядчика на интеграцию около 2 000 ₽/час и объёме работ порядка 40 часов разовые вложения в проект составляют около 80 000 ₽. Экономия по времени в пересчёте на стоимость рабочего часа — около 70 000 ₽/мес — отбивает эти вложения примерно за один-два месяца. Дальше это уже чистое высвобождение времени, а не разовая экономия. Показатель Без протокола С автопротоколом Время на уточнение задач, час/мес на отдел из 15 менеджеров ~82 часа ~11 часов Стоимость этого времени при ставке ~1 000 ₽/час ~82 000 ₽/мес ~11 000 ₽/мес Источник истины по договорённостям Память участников Транскрипт с таймкодом Цифры в таблице — грубая прикидка по формуле «часы × ставка», не факт из системы учёта. Надзор всё равно нужен Соблазн включить систему и забыть о ней — самый частый способ сломать автоматизацию протоколов; проверять выборочно нужно каждые две-три недели, а не полагаться на то, что скрипт работает вечно без присмотра. Я видел похожую историю с коммуникационными каналами в этой же компании: в одном месяце было оплачено на порядок меньше линий, чем в следующем, — переплата шла за WhatsApp и Telegram на сотрудников, которых физически не было в таком количестве. Никто не следил, что система разрастается сама. Признаю: следить там должен был я, и не следил — это моя недоработка, а не сбой системы. Включённая автоматизация выглядит работающей ровно до первой выборочной проверки, и здесь ошибаются все, я в том числе. Так что если вы сейчас подумали «ну я-то проверю» — я тоже так думал. С автопротоколами планёрок риск тот же: если не проверять выборочно, что задачи реально долетают до исполнителя и срок в CRM совпадает со сроком на записи, система тихо начнёт врать — так же, как врёт CRM при рассинхроне дат, о чём я писал в статье про сдвиг дат в Битрикс24 . Про то, что любая автоматизация без периодической проверки превращается во вторую работу, а не в экономию времени, я подробно писал в статье про надзор за автоматизацией . Протокол планёрки — не исключение: раз в две-три недели стоит выборочно сверить три-четыре записи с тем, что реально попало в задачи. Это 15-20 минут проверки против часов ручного набора текста, которые экономятся каждую неделю. Возвращаясь к финансовому сотруднику с его 15 минутами концентрации: его проблема решилась не автоматизацией, а структурой дня — конкретным часом на обработку платежей. Протокол планёрки решает соседнюю проблему: он убирает необходимость держать в голове десяток устных договорённостей и пересказывать их по три раза за день. Это не заменяет управленческое решение о структуре дня, но освобождает время, чтобы его вообще успеть принять. Чек-лист: с чего начать в понедельник Выберите одну регулярную планёрку — не самую важную, а самую частую — и начните записывать её постоянно, без исключений. Подключите сервис расшифровки речи с таймкодами и разметкой по спикерам: для старта проще всего облачный API (Яндекс SpeechKit или Salute Speech), при большом потоке записей выгоднее Whisper на своём сервере. Возьмите промпт из этой статьи, прогоните на одной реальной записи и сверьте результат вручную — сколько задач модель нашла верно, сколько пропустила, где ошиблась с ответственным. Настройте передачу результата в CRM или таск-трекер через вебхук с промежуточной очередью и статусами pending/manual_review/sent — не в чат, чат не считается системой хранения задач. Назначьте человека, который раз в две-три недели выборочно сверяет 3-4 протокола с записью — это тот самый надзор, без которого автоматизация врёт молча. Через месяц посчитайте разницу: сколько времени раньше уходило на переспрашивание задач и сколько уходит сейчас на проверку протокола. Начните со следующей планёрки: включите запись и попросите машину сделать протокол. Сравните с тем, что запомнили участники, — разница обычно отрезвляет. Как поставить это на поток, чтобы протокол собирался сам, — в бесплатном курсе для руководителей . Как это меняет ваши планёрки У вас изменится не только документооборот. Когда участники знают, что решения записываются с именами и сроками, они формулируют их точнее — и половина расплывчатых договорённостей исчезает сама. Ваш побочный выигрыш: вы перестаёте быть единственным человеком, который помнит, о чём договорились. Это освобождает вам голову лучше любого тайм-менеджмента. И назову вещь, которой не было в списке требований к руководителю ещё пять лет назад. Умение поставить машине задачу так, чтобы протокол собрался без вас, — это управленческий навык, ровно такой же, как умение провести саму планёрку. Руководитель, который держит договорённости в системе, стоит дороже руководителя, который держит их в голове: первого можно поставить на три отдела, второй упирается в объём собственной памяти. Осваивается это за один вечер на одной записи. Но пока вы его не освоили, вы конкурируете с теми, кто уже освоил. Попробуйте на ближайшей встрече — вам понадобится только запись и десять минут на проверку результата. Ваш первый протокол машина соберёт уже завтра — попробуйте. ## «Если бы я не пришёл, ничего бы не произошло»: внедрение автоматизации процессов без надзора URL: https://davidgerstein.pro/blog/avtomatizatsiya-kotoraya-trebuet-nadzora/ Дата: 2026-07-25 Направление: Операционное управление Цифры: 39 000 ₽/мес скрытого надзора, 10 автоматизированных процессов, 3 обязательных свойства Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. У меня есть личный тест на настоящую автоматизацию, и я собираюсь им поделиться, потому что он экономит деньги ещё на этапе постановки задачи. Тест звучит так: что произойдёт, если про этот процесс все забудут на две недели? Если ответ «будет работать, а при сбое сам перезапустится или громко позовёт» — это автоматизация. Если ответ «надо будет поглядывать» — это не автоматизация. Это вторая работа, которую вы добавили к первой. Если вы узнаёте здесь свой вечер пятницы — «дай гляну, всё ли вышло», — дальше цифры, во что вам это обходится и что нужно требовать при внедрении. Внедрение автоматизации процессов: что заложить, чтобы не следить Если при внедрении автоматизации процессов не заложить три свойства — самоперезапуск, громкий сигнал о сбое и ответ на вопрос «жив?» за 10 секунд, — процесс придётся сопровождать руками до конца его жизни. На наборе из 10 автоматизированных процессов скрытый надзор — «глянуть, всё ли вышло», разобрать сбой, вспомнить проверить — обходится примерно в 39 000 ₽ в месяц (оценка) рабочего времени. Эти часы не попадают в расчёт окупаемости и съедают эффект. Процесс, который можно оставить без присмотра, обязан иметь три свойства: сам перезапускается, громко сообщает о сбое и отвечает на вопрос «жив?» за 10 секунд. Как я к этому пришёл История, после которой тест появился. Автоматическая публикация контента: процесс собирает материалы, готовит посты, выкладывает по расписанию. Работал прекрасно — пока однажды не упёрся в ошибку и молча не встал. Утром выясняется: ничего не вышло. Запускаю руками, чиню. Через неделю — то же самое, по другой причине. Фраза, которую я тогда сказал вслух: «Если бы я не пришёл и не проверил, ничего бы не произошло». В этой фразе — вся суть. Процесс формально автоматический, фактически — на ручном приводе, просто привод дёргается не каждый раз, а при сбоях. Но чтобы узнать о сбое, надо проверять. А чтобы проверять, надо помнить. А значит, задача не ушла из головы — она в ней поселилась в худшей форме: «не забыть проверить робота». Самое неприятное — что я узнавал о сбоях не по сигналу, а по отсутствию результата. Я заходил в канал по привычке, видел, что вчерашнего поста нет, и только тогда понимал: что-то сломалось ещё вчера, а значит, весь день процесс молчал впустую. Это и натолкнуло на формулировку теста: если единственный способ узнать о поломке — заметить пустоту там, где должен быть результат, надзор уже идёт, просто он не назван вслух. Арифметика, которую никто не считает Допустим, ручная задача занимала час в день. Автоматизация сократила его до нуля — но добавила: пять минут в день «глянуть, всё ли вышло», полчаса раз в неделю на разбор сбоя, и главное — фоновую ответственность, которая не делегируется. Если процессов таких не один, а десять (а их быстро становится десять), у вас появляется новая должность: смотритель зоопарка роботов. Обычно эта должность достаётся самому дорогому человеку в компании — тому, кто автоматизацию и заказывал. Именно поэтому «мы автоматизировали двадцать процессов» так часто соседствует с «почему-то никто не почувствовал облегчения»: автоматизируют то, что проще поддаётся, а не то, что держит поток. Отсюда и порядок действий — сначала описать процесс, найти узкое место и назначить владельца , и только потом отдавать шаг машине. Дальше — конкретные цифры на нашем наборе из 10 процессов, чтобы это перестало быть фигурой речи. Три свойства процесса, который можно оставить одного 1. Сам перезапускается Большинство сбоев — временные: сеть моргнула, сервис не ответил, файл пришёл битый. Процесс обязан уметь повторить попытку сам — с паузой, несколько раз, по одному конкретному упавшему элементу, а не всей пачке. Это решается при постановке задачи одной фразой в ТЗ и почти ничего не стоит. Добавленное потом — стоит дорого. 2. Громко зовёт, когда не справился Если перезапуск не помог — процесс сообщает туда, где сообщение увидят: в мессенджер ответственному, а не в лог-файл. Тишина должна означать «всё хорошо», и это соглашение важно держать честным: процесс, который молчит и когда работает, и когда умер, хуже процесса, которого нет, — он создаёт ложную уверенность. 3. Отвечает на вопрос «ты живой?» В любой момент за десять секунд можно узнать: когда процесс отработал в последний раз, что сделал, что в очереди. Не залезая в код и не спрашивая того, кто его писал. У меня это сводка одной командой или строка в ежедневном отчёте. Отдельный коварный случай — процесс, который «работает», но делает не то: у меня жил сборщик данных, который месяцами писал записи, при этом полезная часть молча не работала. Поэтому «живой» — это не «процесс запущен», а «результат сегодня существует и выглядит осмысленно». Правило Три свойства — перезапуск, громкий сбой, проверяемость — включаются в задачу на автоматизацию с первого дня. Автоматизация без них не принимается как готовая, сколько бы красиво она ни работала на демонстрации. Стоимость этих трёх свойств — процентов десять от проекта; стоимость их отсутствия — весь эффект проекта. Отличать автоматизацию от второй работы под тем же названием — управленческий навык, и нужен он вам до подписания задачи, а не после первого молчаливого сбоя. Три ошибки, которые сводят надзор на нет Даже когда за автоматизацию берутся всерьёз, надзор возвращается через одну из трёх типовых дыр: сигнал приходит не тому человеку, сигнал приходит слишком часто, или перезапуск маскирует проблему вместо того, чтобы её решать. Сигнал не тому человеку. Уведомление о сбое падает в общий чат отдела, где его читают все и не читает никто. Ответственность размывается: каждый думает, что отреагирует другой. Правильно — один конкретный получатель на процесс, даже если это неудобно признавать вслух: «за это отвечает N, и сообщение идёт лично N». Сигнал слишком частый. Если процесс присылает предупреждение при каждой мелочи — задержке на пять секунд, единичном таймауте, который перезапуск и так исправил, — люди быстро научаются игнорировать канал целиком. Через месяц там будет пятьдесят непрочитанных сообщений, и настоящий сбой утонет среди них. Сигнализировать нужно только о том, что требует действия человека, а не о любом отклонении от идеала. Перезапуск маскирует проблему. Процесс, который тихо перезапускается пять раз подряд и в итоге срабатывает, формально «жив» — но если он делает это каждый день, значит, где-то есть системная причина, которую никто не видит, потому что до открытого сбоя не доходит. У меня был именно такой случай с внешним сервисом, который отвечал через раз: процесс справлялся сам, отчёт был зелёный, а нагрузка на инфраструктуру росла месяцами, пока не вылилась в более дорогой сбой. Поэтому даже «успешные после перезапуска» случаи стоит один раз в неделю просматривать отдельно, а не считать полностью закрытым вопросом. Экономика надзора: во что обходится «просто поглядывать» В компании из 40 человек у нас 10 автоматизированных процессов; доработка недостающих свойств у 6 из них заняла ≈18 часов разовой работы, эксплуатация не добавила затрат — используются существующие каналы уведомлений, а эффект — снижение скрытого надзора с ≈39 000 ₽/мес до ≈2 000 ₽/мес, то есть чистая экономия ≈37 000 ₽/мес (оценка при ставке ~1 000 ₽/час). Один из этих 10 процессов — ежедневный отчёт для 8 менеджеров отдела продаж, которые в сумме закрывают около 50 сделок в месяц при обороте 9 млн ₽ и среднем чеке 180 тыс. ₽. Формально отчёт автоматический: цифры сами приходят в чат каждое утро. Фактически раз в одну-две недели он расходится с CRM на несколько сделок — обычно из-за тех, что двигают статус в выходные, — и тогда менеджеры по неделе работают по неверным цифрам, пока кто-то не заметит нестыковку и не поднимет её вручную. Это ровно третий тип из таблицы ниже: процесс работает, но требует регулярной проверки, потому что сам не умеет сказать «я соврал». Вторая категория из таблицы — процессы, которые уже умеют сигнализировать о явном сбое, но не умеют перезапускаться сами. У нас таких три, и по ним надзор — это не проверка «всё ли верно», а ручной перезапуск по сигналу: получил сообщение, зашёл, нажал кнопку. На каждый такой случай уходит 10–15 минут, но случаются они непредсказуемо, и именно эта непредсказуемость съедает управленческое внимание сильнее, чем сами минуты — переключение контекста стоит дороже, чем показывает секундомер. Категория процесса Кол-во из 10 Надзор, ч/мес Надзор, ₽/мес (оценка) Есть все 3 свойства — полностью автономные 4 0 0 Есть только громкий сигнал о сбое 3 12 12 000 Нет ни одного свойства — нужна ручная проверка 3 27 27 000 Итого 10 39 39 000 Полностью автономные — 40% Только сигнализируют — 30% Нужен ручной надзор — 30% Что мы не считаем эффектом: если сотрудник раньше тратил час в день на ручной шаг, а теперь тратит те же 39 часов в месяц на присмотр за автоматикой — это не экономия, а другая работа под старым названием. Экономией мы называем только то, что освобождается сверх текущего надзора после доработки — то есть разницу между 39 000 ₽/мес и 2 000 ₽/мес, а не разово выигранное время на старте проекта. Как я проверяю процессы: промпт для дежурного по автоматизациям Ежедневная ручная проверка 10 процессов занимает 15–20 минут в день; промпт ниже сводит это к чтению одной сводки, которую модель собирает из логов и вебхука Bitrix24 за 10–15 секунд, а не к обходу каждого процесса по отдельности. На входе — JSON со статусами процессов за сутки: часть данных приходит из вебхука Bitrix24 (например, статус фоновой синхронизации сделок), часть — из логов сервера, где крутятся публикация и отчёты. Модель должна не пересказать логи, а решить за меня один вопрос: нужно ли сегодня вмешаться руками. Пример ответа модели на этот вход: Ключевая деталь — поле action_needed . Пока оно есть и по нему честно можно ориентироваться, сводку можно читать по диагонали за 10 секунд, как и требует третье свойство. В день, когда сводка начинает врать («ok», хотя процесс не запускался неделю), доверие к ней рушится быстрее, чем строится, поэтому сам дежурный-промпт тоже раз в месяц стоит сверять руками с реальными логами — иначе он превращается в ещё один процесс, требующий надзора. Куда это масштабируется С ростом числа автоматических процессов появляется следующий уровень той же задачи: сторож сторожей — один ежедневный отчёт, который сводит состояние всех процессов в одну картину. У меня он приходит вечером в мессенджер и построен на том же принципе, что промпт выше: не «всё ли запущено», а «что реально требует моих рук сегодня». Это снимает последнюю форму надзора — необходимость помнить, за чем следить. На практике сторож сторожей — это тот же промпт, только на входе у него не три процесса, а десять, а на выходе — не построчный список, а один агрегированный вывод: сколько процессов зелёные, сколько требуют внимания, и есть ли среди них повторяющаяся причина сбоя за последние семь дней. Повторяющаяся причина — отдельный сигнал: если один и тот же процесс перезапускается по одной и той же ошибке третий день подряд, это уже не сбой, а системная проблема, которую перезапуск временно прячет, — ровно тот случай из раздела про типичные ошибки. Без сводного отчёта такую закономерность видно только задним числом, когда проблема успела вырасти. Тот же принцип «система должна следить за собой» относится и к данным, на которых всё построено, — про это отдельный разбор: как CRM тихо меняла данные задним числом , и почему без ежедневного снимка этого не видно. А про то, во что автоматизация обходится в деньгах в принципе, — разбор реальных расходов на ИИ . Чек-лист на понедельник Выпишите все автоматизированные процессы компании — обычно их оказывается больше, чем помнят вслух. Для каждого проверьте три свойства: сам перезапускается, сам сообщает о сбое, отвечает на «жив?» за 10 секунд. Посчитайте, сколько из них требуют регулярной ручной проверки (третья категория из таблицы) — это ваш реальный, а не декларируемый, объём надзора в часах. Переведите часы в деньги по ставке ~1 000 ₽/час и сравните с тем, сколько будет стоить доработка (в разборе — ≈18 часов разово на 6 процессов). Начните с процесса, чья цена ошибки выше всего — как отчёт для отдела продаж, который расходится с CRM молча. Ваш способ проверить, не попали ли вы в эту ловушку: посчитайте, сколько времени в неделю у вас уходит на присмотр за автоматикой. Если больше, чем экономит, — вы построили себе вторую работу. Посчитайте ваш надзор в часах за месяц и сравните с тем, что автоматика экономит. Если разница не в вашу пользу — либо доводите контур до конца, либо честно возвращайтесь к ручной работе: промежуточное состояние обходится дороже обоих вариантов. ## Регламент работы с договорами: как сделать шаблон, который не подведёт в суде URL: https://davidgerstein.pro/blog/dogovory-shablony-i-riski/ Дата: 2026-07-25 Направление: Право и риски Цифры: иск в разы превысил фактическую оплату · 60–70% условий закрыто актами до старта · 5 чарджбеков за полтора года Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Сколько версий вашего типового договора ходит сейчас по компании? Если вы уверены, что одна, — проверьте: я почти уверен, что их три. И одна из них — та, куда менеджер когда-то внёс правку клиента и забыл откатить. Если у вас нет одного места, откуда шаблон берут все, и одного человека, который отвечает за его версию, — регламента работы с договорами у вас нет. Есть привычка, которая держится ровно до первого спора. Разбираю, как навести здесь порядок и что из этого можно отдать машине. У компании, которая снимает семейные фильмы на заказ, были старые договоры с первыми клиентами и новые — с последними. В старых не было ни слова про итоговый фильм, сопровождение и визуальные ожидания. В новых — было. Разница появилась не потому, что кто-то сел и продумал риски заранее. Она появилась после конфликтов. Шаблоны договоров с клиентами в этой компании росли как заплатки поверх дыр, а не как система. Я видел это в нескольких компаниях: юрист есть, договор подписывается, но каждый новый конфликт обнажает формулировку, которую никто не проверял. Садятся переписывать один пункт вместо того, чтобы посмотреть на весь шаблон целиком. Пока идёт эта переписка — юрист тратит часы на ручную проверку каждого нового договора, потому что не доверяет старому шаблону. Если в отделе несколько менеджеров и каждый ведёт по 4 сделки в месяц с договором, это несколько десятков документов, из которых юрист вручную читает каждый — при 20–30 минутах на документ это десяток с лишним часов в месяц только на то, чтобы убедиться, что в тексте нет старой дыры. Что должно быть в регламенте работы с договорами Регламент работы с договорами — это не папка с бланками, а четыре правила: одно место, откуда шаблон берут все; реестр версий с причиной каждой правки; пять блоков, которые юрист закрывает один раз (гарантии, возвраты, этапы с актами, данные, запрет боковых договоров сотрудников); и порог, после которого зовут юриста. В разобранном кейсе 60–70% условий закрывается актами ещё до старта производства — именно этой фиксации не хватило в споре, где клиент требовал 772 тыс. ₽ при фактической оплате 262 тыс. ₽ , а подтвердить удалось только 150 тыс. ₽ . Первичную проверку договора на эти пять рисков вы можете отдать дешёвой модели: на потоке в 32 договора в месяц время юриста сокращается с 13 часов до 4 (оценка), а сам скрининг стоит десятки-сотни рублей в месяц. Договоры с клиентами: шаблоны, которые растут заплатками — это риск Разработчику курса дали задачу — он использовал личную учётку вместо служебной. Никто не заметил, потому что всё работало. Проблема всплыла, когда понадобилось выдать доступ новым сотрудникам, а прогресс прохождения курса оказалось невозможно отследить. С договорами то же самое: пока нет конфликта, дырявая формулировка не мешает. Мешает она в момент, когда клиент требует деньги назад, а вы читаете пункт и понимаете — там нет однозначного ответа. В компании, которая сопровождает клиентов в длительных разрешительных процедурах через внешние инстанции, был пункт 6.8: возврат денег полагался «при соблюдении рекомендаций компании о продолжении работы». Клиент получил два отказа от внешнего ведомства, отказался от дальнейшего обжалования и потребовал полный возврат. Компания потратила 70 тыс. ₽ на сбор документов и бонусы менеджерам, но вернула клиенту оплаченные 420 тыс. ₽ — потому что формулировка не выдерживала спора. Слово «отказ» звучало как финальная точка, хотя по факту первый отказ ведомства не был последней инстанцией. Решение — не карательное, а редакторское: заменить «отказ» на «уведомительное письмо от ведомства» и прямо прописать, что это не финальная инстанция. Полный возврат — только после исчерпания всех возможностей, включая обращение в вышестоящие органы. Один термин меняет всю логику ответственности. Правило Проверяйте каждую формулировку в договоре вопросом: «а что если клиент прочитает это буквально и максимально в свою пользу?» Если ответ неочевиден — переписывайте, не дожидаясь суда. Регламент работы с договорами: какие версии хранить и когда их менять У кинокомпании было решение сделать дополнительное соглашение — срочно, к пятнице. В нём: количество часов съёмки, определение качества видео, число локаций, обязательства клиента по предоставлению информации и участию семьи, границы ответственности компании при отказе клиента участвовать. Это типичный список того, что должно быть в шаблоне с самого начала, а не появляться после первого скандального проекта. Второе решение той же компании — разбить договор по этапам работ с согласованием выполненного перед переходом к следующему. До выхода на производство должно быть закрыто 60–70% условий, с актами выполненной работы. Это защищает обе стороны: клиент видит, за что платит на каждом шаге, компания фиксирует, что этап принят, и не отвечает потом за то, что происходило до подписания акта. Версия шаблона Чего не было Что добавили Первые клиенты Описание фильма, сопровождения, итоговых визуальных ожиданий Отдельный раздел с ожиданиями и определением качества Дополнительное соглашение (срочное) Часы съёмки, локации, обязательства клиента Конкретные цифры и границы ответственности при отказе участвовать Этапная версия Разбивки по этапам, актов 60–70% условий закрыто до старта производства, акты на каждый этап Гарантийная версия (п. 6.8) Точное определение «отказа» «Уведомительное письмо», явное указание — не финальная инстанция Если у вас нет истории конфликтов, по которой можно построить такую таблицу — начните собирать её сейчас. Каждый спор, дошедший до претензии, это готовая строка для будущей версии шаблона. Держите таблицу версий в отдельном реестре — Google Sheets или лист в CRM, — а не в переписке между менеджером и юристом, иначе через год никто не вспомнит, почему пункт звучит именно так. Гарантии: разделить то, что вы контролируете, и то, что нет Клиент требовал гарантировать итоговый результат в срок 6–12 месяцев с полным возвратом за 10 рабочих дней при неудаче. Компания не может контролировать проверки внешних инстанций, форс-мажоры и действия самого клиента. Но по договору обязана отвечать за результат целиком — это ловушка, в которую легко попасть, если гарантия написана одной строкой без разбивки. Решение, которое предложило руководство: перейти от гарантий по итоговому результату к гарантиям только по тем этапам, которые компания реально контролирует — сроки записи, этапы подготовки документов. По рискам, на которые компания не влияет, отдельно обсуждать с клиентом, какой конкретно риск он хочет застраховать. Это честнее, чем обещать всё и разбираться с последствиями постфактум. Похожая логика применима к деньгам. У компании было 5 чарджбеков за полтора года: клиент получает услугу, общается с менеджером, а потом оспаривает платёж через банк. Договор с чёткой фиксацией этапов и подписанными актами — лучшая защита от такого спора, потому что банк видит документальный след, а не голословное «услугу не оказали». Другой пример — слишком маленький минимальный аванс создавал риск неплатежей и требовал отдельного сотрудника только для сбора задолженности. Это тоже договорная проблема: если условия оплаты прописаны слабо, вы нанимаете человека разгребать то, что должен был закрыть текст на бумаге. Подробнее про то, как контроль дебиторки снимает эту нагрузку — в статье «Дебиторка растёт: контроль, который не зависит от памяти людей» . Типовые договоры: риски, которые не в тексте, а в людях Шаблон может быть идеальным, но его нарушает конкретный человек. Руководитель отдела заключил договор на консультационные услуги на 350 тыс. ₽ с клиентом, которому компания такие услуги не оказывает. Деньги получены, чек не выписан, договор подписан на ИП сотрудника — вопреки прямому запрету руководства. Это классический прецедент бокового заработка, и, что хуже, не первый: политика против таких договоров уже озвучивалась на совещаниях. Клиенты потом звонили собственнику с претензией, думая, что покупали услугу у компании, а получили её по отдельному договору мимо кассы. Здесь шаблон бессилен — нужен контроль исполнения. Я долго считал такие истории проблемой найма: не тех взяли. Оказалось, дело в другом — в компании не было ни одной бумаги, где сотруднику прямо запрещалось бы это делать. Но кое-что шаблон всё же может: явный пункт о запрете параллельных договоров с клиентами компании, подписанный каждым сотрудником с доступом к клиентской базе. Это не остановит недобросовестного человека, но даёт основание для иска и увольнения без долгих споров о трудовом праве. Второй похожий кейс — клиент оплатил 262 тысячи, а через суд потребовал 772 тысячи. Компания смогла задокументировать только 150 тысяч как не оказанные услуги и вернула именно эту сумму. Разница между тем, что требовал клиент, и тем, что удалось доказать, — это разница между компанией с актами на каждый этап и компанией без них. Похожая история — спор, где клиент требовал вернуть большую часть предоплаты, заявив, что не получил обещанную стратегию. Компания предложила стратегию постфактум, но было поздно: договор не фиксировал, что именно и когда должно быть предоставлено. Требование клиента 772 тыс. ₽ Реально оплачено 262 тыс. ₽ Задокументировано как неоказанное 150 тыс. ₽ Разрыв между верхним и нижним баром — это цена договора без промежуточных актов. Каждый из трёх кейсов в этом разделе решался бы иначе, если бы этап был закрыт документом до того, как начался следующий. Где ломается Договор без промежуточной фиксации результата — это договор, который в суде читается в пользу клиента. Акт на каждом этапе стоит дешевле, чем спор о том, что вообще было сделано. Данные клиентов в договоре: не только про деньги Отдельная категория рисков — то, что вы обязаны прописать про данные клиента, а не только про услугу. Юрист проверил, что все юрлица группы зарегистрированы как операторы персональных данных, но выявил пробел: в договорах с клиентами не было явного согласия на трансграничную передачу данных, хотя документы обрабатывались на зарубежных серверах. Это отдельный пункт, который легко забыть, если шаблон писался до того, как в процессе появилась внешняя обработка данных. Подробнее о том, что можно и что нельзя передавать через ИИ-сервисы — в статье «Персональные данные и нейросети: что можно отправлять в ИИ, а что нельзя» . Договор — это только половина защиты данных. Вторая половина — то, где вы физически храните файлы и таблицы, на которые в договоре ссылаетесь. При аудите одной из систем нашли конфиденциальную информацию — кошельки, данные менеджеров, сведения о компаниях — открыто лежащей в JS-файле на публичном сервере; её проиндексировали поисковики. В другой раз выяснилось, что таблицы с финансовой информацией и данными клиентов доступны всем, у кого есть ссылка. Формально в договоре может быть безупречный пункт про согласие на обработку данных — но если реестр рисков или база договоров лежит открытой по ссылке, этот пункт существует только на бумаге. Ещё один пробел того же типа — ответственность за иностранное контрактное право. Юрист составляет и проверяет договоры, но не имеет права общаться с клиентом напрямую. Ответ на это — не переписывание договора, а назначение отдельного специалиста, который отвечает за юридическую поддержку и может привлекать консультантов при необходимости. Иногда риск не в тексте документа, а в том, что некому объяснить клиенту, что там написано. ИИ-связка: автоматическая проверка договора перед юристом Юрист не должен читать каждый договор целиком, если 80% текста — типовые блоки, уже проверенные раньше. Его время нужно тратить на нестандартные условия. Чтобы это работало, между менеджером и юристом ставится дешёвая модель — она не подписывает и не советует, она находит расхождения с эталонным шаблоном и помечает риск. Схема конвейера — как это выглядит в виде реестра шагов и статусов: Конвейер проверки договора Шаг Инструмент Статус 1. Сборка договора из блоков Google Docs 2. Выгрузка текста по кнопке Apps Script 3. Скрининг риска Дешёвая модель (API) 4. Запись вердикта в реестр Google Sheets 5. Уведомление при high-риске Вебхук в Bitrix24 Дорогую модель я сюда сначала и ставил — и зря платил за то, что делает дешёвая. Модель здесь нужна дешёвая (класса mini, тип GPT-4o-mini или аналог) — задача не творческая, а классификационная: сверить пункт с пятью известными типами дыр и вернуть структурированный вердикт. По публичным ценникам таких моделей стоимость входных и выходных токенов минимальна — доли рубля за тысячу токенов (курс и точная цифра зависят от провайдера и меняются). Дорогую модель звать незачем, она нужна только если позже понадобится сгенерировать саму формулировку правки, а не найти проблему. Пример ответа модели на договор с пунктом про возврат без уточнения инстанции: Инженерная обвязка простая и без иллюзий: скрипт крутится в Google Apps Script, привязанном к служебному аккаунту, а не к личному — ровно тот урок, который компания усвоила на истории с курсом, где доступ был завязан на личную учётку разработчика и стал недоступен при масштабировании. Промпт и API-ключ хранятся в коде скрипта, а не в текстовом файле на диске — тот же принцип, что и с токенами доступа к порталу: «единственный способ сохранить работу при блокировке — чтобы все файлы были у тебя, а не зависели от чужой учётной записи». Шаг 5 в таблице конвейера — вебхук в CRM при high-риске — помечен предупреждением не случайно. При аудите безопасности в одной из систем выяснилось, что вебхуки лежат без защиты и через них можно достучаться до данных клиентов на внешнем портале. Ошибки в самом коде проверки риска оказались там мельче проблемы: настоящей дырой была архитектура доступа, а не логика скрипта. Прежде чем подключать вебхук уведомлений к боевой CRM, закройте его токеном и ограничьте IP отправителя — иначе вы чините одну дыру и открываете другую. При сбое API — три автоматических повтора с паузой, затем письмо ответственному юристу с пометкой «скрининг не сработал, проверьте вручную». Реестр рисков в Google Sheets открыт по принципу «один человек — одна таблица»: юрист правит статусы, менеджер только читает, чтобы автоматическая запись не конфликтовала с ручной правкой. Реальная стоимость токенов на поток в несколько десятков договоров в месяц оказалась ниже, чем я закладывал в план: по прикидке выше это десятки-сотни рублей в месяц даже с запасом на повторные прогоны. Основные деньги в этой схеме экономятся не на API, а на часах юриста — это разбираем в разделе экономики. Ограничение модели Скрининг ловит только известные пять типов риска — то, что уже случалось. Новый тип дыры, которого не было в истории компании, модель не увидит. Реестр нужно пополнять после каждого нового конфликта, иначе список рисков замораживается на дне выпуска промпта. Согласование без юриста на каждый пункт: пять блоков, которые закрывают всё заранее Самый частый вопрос, который я слышу: «Можно ли согласовывать договоры быстрее, не гоняя каждый вариант через юриста?» Можно, если заранее закрыть типовые риски библиотекой формулировок: Гарантийные пункты — по этапам, которые компания контролирует, а не по итоговому результату. Возвраты — с чёткой развилкой «что считается отказом» и «что не является финальной инстанцией». Этапы и акты — минимум для 60–70% объёма работ до основной фазы проекта. Данные — согласие на трансграничную передачу, если данные уходят на внешние серверы. Ограничения для сотрудников — прямой запрет параллельных договоров с клиентами компании. Когда эти пять пунктов закрыты один раз юристом, дальше менеджер собирает договор из проверенных блоков без согласования каждой версии заново. Юрист подключается только когда клиент просит нестандартное условие — гарантию срока, особый порядок оплаты, изменение ответственности. Это резко сокращает время согласования, потому что большая часть текста уже проверена, а спорным остаётся один-два пункта. Работает это только если версии шаблона хранятся централизованно, а не расползаются по личным папкам менеджеров — иначе вы снова получите ситуацию с первыми и последними договорами, которые отличаются друг от друга без всякой логики. Автоматизация без владельца процесса создаёт похожий хаос и в других системах компании: без человека, который следит за версией, документы расползаются так же, как когда-то расползались вкладки в CRM без ответственного. Экономика: что стоит библиотека шаблонов и что она даёт Настройка ИИ-скрининга — около 6 часов на скрипт и промпт, эксплуатация — десятки-сотни рублей в месяц на токены, эффект — около 13 500 ₽ экономии на времени юриста в месяц (оценка). Возьмём отдел из 8 менеджеров со средним чеком 180 тыс. ₽. Каждый ведёт по 4 сделки в месяц с договором — 32 договора в месяц. Ниже — грубая оценка, не факт компании, а типовой расчёт «часы × ставка», который можно приложить к своим цифрам. Показатель Без библиотеки шаблонов С библиотекой + ИИ-скрининг Договоров в месяц 32 32 Время юриста на документ 20–30 минут (читает всё) 3–5 минут на «чистые», 20–30 минут на нестандартные (≈20% потока) Часы юриста в месяц (оценка) ~13 часов ~4 часа Стоимость по условной ставке (оценка) ~19 500 ₽/мес ~6 000 ₽/мес Стоимость ИИ-скрининга — единицы-десятки рублей/мес Разница — около 13 500 ₽ экономии на времени юриста в месяц: ставка юриста ~1 500 ₽/час, у вас юрист может стоить дороже или дешевле. Разовые затраты на создание самой библиотеки — юрист один раз сводит существующие формулировки, переписывает пять проблемных блоков и утверждает эталонный шаблон: около 40 часов по той же ставке — разово около 60 000 ₽. При экономии ~13 500 ₽/мес окупаемость составляет примерно 4–5 месяцев (оценка, без учёта того, что часть этих часов юрист и так тратил бы на разбор конкретных конфликтов). Это только эффект от сокращения ручного чтения — не смешивайте его с эффектом от кейса 772/262/150 тысяч. Там сработал не ИИ-скрининг, а факт наличия поэтапных актов в договоре: это отдельная инициатива (перестройка структуры договора), и её вклад нельзя списывать на автоматизацию проверки. Что не считаем эффектом ИИ-скрининга: снижение суммы иска в конкретном споре, ускорение получения оплаты и любые изменения, которые дали акты и этапная разбивка договора, — это отдельные рычаги со своей отдельной экономикой. Не путать эффекты ИИ-скрининг экономит часы юриста на чтении типовых блоков — это около 162 000 ₽ в год. Поэтапные акты снижают сумму, которую можно отсудить постфактум, — это может быть на порядок больше в конкретном споре (см. разницу 772/262/150 тысяч выше). Считайте окупаемость каждого рычага отдельно, иначе завышенная общая цифра развалится при первой проверке цифр советом директоров. Чек-лист: с чего начать в понедельник Внедрение библиотеки шаблонов и ИИ-скрининга — не проект на квартал, а неделя сфокусированной работы, если у вас уже есть история конфликтов. Понедельник. Собрать все действующие версии договорных шаблонов в один реестр (Google Sheets или лист CRM). Выписать все претензии и споры за последние 12 месяцев — каждая станет строкой будущей таблицы версий. Вторник. Свести найденные проблемы в пять категорий: гарантии, возвраты, этапы/акты, данные, боковые договоры сотрудников. Отдать список юристу на разовую вычитку — не всего шаблона, а именно этих пяти блоков. Среда. Юрист переписывает проблемные формулировки один раз и утверждает эталонный шаблон. Параллельно — проверить права доступа к реестру и таблицам с договорами: не лежат ли они открытыми по ссылке. Четверг. Настроить скрипт скрининга: Apps Script на служебном аккаунте, промпт из этой статьи, запись вердиктов в Google Sheets. Прогнать на 5–10 старых договорах, чтобы откалибровать severity и убедиться, что модель не путает риски. Пятница. Подключить уведомление в CRM при high-риске через защищённый вебхук (токен + ограничение по отправителю). Провести короткую летучку с менеджерами: как собирать договор из готовых блоков и когда обязательно звать юриста. Через месяц. Пересчитать часы, которые юрист реально тратит на договоры, и сверить с оценкой из раздела экономики — если цифры разошлись сильно, дело либо в ставке, либо в доле нестандартных условий выше ожидаемых 20%. Отдельно — про людей, а не про текст. Библиотека шаблонов и ИИ-скрининг не остановят сотрудника, который решит заключить параллельный договор в обход компании, как это уже случалось. Здесь помогает только явный пункт о запрете и регулярный аудит закрытых сделок — если политика озвучена один раз на совещании, это не значит, что прецедент не повторится. Если проблема шире, чем формулировки в договоре — например, менеджеры вообще не фиксируют этапы работы в CRM, и акты подписывать не с чем, — начинать нужно не с шаблона, а с дисциплины внесения данных. Об этом — в статье «Менеджеры не вносят данные в CRM: что делать без репрессий» . Ни один шаблон не заменит договора, прочитанного человеком. Но если типовые риски закрыты один раз, юрист тратит время именно на то, на что тратить его должен, — а не на пятый одинаковый абзац про гарантии. И ещё одно, чему мне пришлось учиться самому: читать собственный договор глазами клиента, который завтра захочет вернуть деньги. Это управленческий навык, а не юридический. Юрист сверит текст с законом, но только вы знаете, что менеджер пообещал клиенту голосом и чего клиент ждёт по факту. Руководитель, который умеет заранее назвать пять мест, где его же договор прочитают против него, стоит компании дешевле любого разбирательства. Ваша проверка на эту неделю: соберите у трёх менеджеров файл «типового договора», который они отправляют клиентам, и сравните между собой. Если найдёте расхождения — вы нашли свой риск, и он дороже любой автоматизации. Как поставить проверку версий и первичный разбор входящих договоров машиной — в бесплатном курсе для руководителей . И последнее: договорите с вашим юристом одну вещь — кто и как часто проверяет актуальность шаблонов. Без этого правила ваш идеальный договор устареет вместе с законодательством, и узнаете вы об этом в суде. Как это было у нас Мы обнаружили три разные версии типового договора случайно, и я до сих пор считаю это везением — когда клиент прислал наш же документ с пунктом, который мы год назад убрали. Оказалось, у одного менеджера сохранилась старая версия, и он отправлял именно её. Я тогда не стал разбираться, кто виноват: система позволяла хранить договоры где угодно, и рано или поздно это должно было случиться. Мы завели единое место, откуда берётся шаблон, и правило, что личные копии не используются. Сверьте свои шаблоны на этой неделе — и заведите одно место, откуда их берут все. Как поставить проверку версий машиной, разбираю в бесплатном курсе . ## Адаптация новых сотрудников: стажёр не выходит на план, а наставник не клонируется URL: https://davidgerstein.pro/blog/onbording-kotoryj-rabotaet/ Дата: 2026-07-24 Направление: Люди Цифры: 5 дней курса · 3-й месяц — первый кризис менеджера · до 18 ч наставника на одного новичка (оценка) Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас новый сотрудник выходит на первый самостоятельный результат дольше месяца — вы платите зарплату за ожидание. И виноват тут обычно не человек. Виновато то, что адаптации новых сотрудников у вас нет как процесса: есть наставник, у которого на этой неделе нашлось время. Новый менеджер получает клиента и не может ответить на простой вопрос: «За что я платил?» Не потому что забыл скрипт. Потому что сам не понимает ценности того, что продаёт компания. Итог — конфликт при первом же контакте, иногда расторжение договора в первую неделю. Это не проблема мотивации. Это дыра в адаптации новых сотрудников: человека выпустили в поле без базы. Посчитаем грубо, консервативно и с прицелом на то, чтобы вы могли подставить свои числа. Условная компания: отдел из 12 менеджеров, оборот ~6 млн ₽/мес, средний чек сделки — 150 000 ₽. Формула такая: число новых менеджеров в квартал × доля тех, кто срывает контракт из-за непонимания ценности услуги × средний чек сделки = сумма прямого риска, который никто не считает отдельной строкой в отчёте. В нашем случае: 5 новичков в квартал, из них хотя бы один срывает контракт в первую неделю (оценка на основе разобранного кейса, консервативно — каждый пятый). При среднем чеке 150 000 ₽ получается 150 000 ₽ в квартал прямого риска, который никто не считает отдельной строкой в отчёте, — и это без учёта репутационных потерь: клиент, которому не смогли объяснить, за что он платит, расскажет об этом знакомым. Я разбирал этот кейс вместе с руководителем отдела продаж и командой найма. Оказалось, что до этого адаптация держалась на одном человеке — опытном коллеге, который выделял несколько дней на индивидуальное обучение по видеозвонку. Работало, пока не начали расти объёмы найма. Наставник физически не мог клонироваться. Как собрать само обучение — курс, аттестацию и проверку — в отдельном разборе . Как организовать адаптацию новых сотрудников Не через живого наставника, а через структуру: 5 рабочих дней курса на корпоративном портале — компания, клиентский путь, типы клиентов, услуги и скрипты, реальные кейсы, — с тестом в конце каждого дня и личной папкой документов, которая собирается сама по мере прохождения. Наставника это не отменяет, а сдвигает: с пересказа базовых фактов — на разбор исключений. В разобранном кейсе его время на одного новичка сократилось, по оценке, с 18 часов до 2. Текстовые ответы пятого дня проверяет дешёвая модель — 1–2 $ в месяц на поток из пяти новичков. Почему наставник-энтузиаст — это не система Проверьте у себя: если ваш лучший наставник уйдёт в отпуск, как выйдет новый сотрудник? Если ответ «подождёт» — системы нет. Схема «опытный коллега учит новичка вживую» кажется тёплой и человечной. На деле это скрытая стоимость: пока наставник объясняет пятому стажёру одно и то же, он не работает с клиентами. Компания платит дважды — за обучение и за упущенные продажи наставника. Второй эффект — качество плывёт. Один наставник объяснит подробно, другой — на бегу, между звонками. Новичок из второй группы выходит на линию с дырами в знаниях, которые вскрываются на реальном клиенте. Тогда и звучит то самое «за что я платил» — а отвечать некому, потому что менеджер сам не разобрался. Решение, которое сработало: убрать живого наставника из первого касания и заменить его готовым инструментом, который новичок проходит самостоятельно. Опытный сотрудник подключается позже — на разборе сложных случаев, а не на пересказе базовых фактов о компании. Пять шагов адаптации, которые вы соберёте сами Ни один из них не требует бюджета — только вашего решения и пары часов на описание. Ниже — последовательность, которую можно повторить с своей командой без больших вложений. Это не теория, а порядок, в котором собирали курс в разобранном кейсе. Шаг 1. Собрать контент, который сейчас в головах наставников. Что → знания о компании, партнёрах, клиентском пути, типах клиентов, скриптах. Чем → интервью с двумя-тремя лучшими продавцами (по 1–2 часа записи на диктофон). Куда → расшифровка ложится в структуру по дням, а не единым полотном текста. Шаг 2. Разбить на дневные блоки с тестом в конце каждого. Что → пять логических блоков: компания, клиентский путь, типы клиентов, услуги и скрипты, реальные кейсы. Чем → любой конструктор курсов на корпоративном портале или даже Google Forms на первом этапе. Куда → личный кабинет новичка, доступный без записи на созвон. Шаг 3. Привязать документы к этапам, а не отправлять архивом. Что → шаблоны, регламенты, скрипты. Чем → скачивание конкретного файла разблокируется после прохождения блока. Куда → личная папка новичка формируется автоматически к концу пятого дня. Шаг 4. Подключить отслеживание прогресса. Что → кто прошёл тест, кто застрял, у кого низкий балл. Чем → Telegram-бот, читающий статус из таблицы или базы курса. Куда → руководитель получает уведомление, а не должен заходить и проверять вручную. Шаг 5. Отдать сложные случаи живому человеку. Что → разбор нестандартных возражений, реальных звонков, кейсов, которые не влезли в тест. Чем → короткая очная сессия с наставником, но уже не по базовым фактам, а по конкретным пробелам, выявленным тестами. Куда → отдельный чек-лист на неделю вперёд, а не бесконечный созвон. Наставник тут никуда не девается — просто смещается с рутины на разбор исключений. То же смещение компания планирует и для отдела контроля качества: с ручной проверки каждого звонка — на управление системой и разбор сложных случаев. Подробный разбор — как построить систему контроля качества звонков . Курс, который заменил наставника Команда сделала 5-дневный онлайн-курс для новых сотрудников отдела продаж. Он размещён на корпоративном портале, у каждого менеджера — личный кабинет. Прогресс отслеживает Telegram-бот. День Содержание 1 Компания и партнёры 2 Клиентский путь и точки касания 3 Типы клиентов и коммуникация 4 Услуги компании и скрипты 5 Реальные кейсы Каждый день заканчивается тестом. Тесты вынесены на отдельный экран — исключает соблазн подсмотреть ответ во время прохождения материала. Мелочь, но именно на таких мелочах курс либо становится проверкой знаний, либо превращается в формальность для галочки. Отдельно решили проблему с документами. Раньше новичок либо игнорировал файлы, которые ему присылали одним архивом, либо получал устаревшую версию. Теперь на каждом этапе курса он скачивает нужный документ сам. К концу обучения у него собрана личная папка со всеми актуальными материалами для работы — не потому что кто-то заставил, а потому что иначе курс не пройти. В план на дальнейшее расширение вошли: шаблоны документов с конкретными примерами, пояснение ценности каждого действия для клиента, видеоинструкции по оформлению документов, расширенный раздел по скриптам, чек-лист в конце обучения и видеозадания — новичок сам записывает короткое видео по определённой стадии работы. Срок этого расширения — конец июня. Это уже не про факты, а про навык: умеет ли человек говорить с клиентом, а не только знать теорию. Как бюрократия крадёт первый день Посчитайте, сколько времени ваш новый сотрудник тратит в первый день на документы и доступы. Обычно это весь день — и он же самый мотивированный за весь период. Курс бесполезен, если новичок физически не может выйти на работу в назначенный день. В одной компании ввод сотрудника требовал письменного распоряжения руководителя на каждого человека — даже если заявка уже пришла от отдела кадров. Формулировка руководителя была прямой: «Получается бред полный — у нас есть HR, которые знают процесс, но меня дёргают на каждого человека отдельно». Параллельно тормозило оснащение техникой: специалист задерживал координацию по ноутбукам и телефонам, и без дополнительной бумаги от руководителя человека не включали в систему. В итоге адаптация начиналась не с курса, а с ожидания подписи и ноутбука. Новичок терял мотивацию раньше, чем открывал первый урок. Где ломается Онбординг спроектирован идеально на бумаге, но упирается в согласования, которые никто не убрал из процесса. Прежде чем строить курс, проверьте, сколько подписей нужно, чтобы новичок получил доступ и технику. Если больше одной — это узкое место, а не курс. Похожая логика описана в материале про автоматизацию, которая требует надзора : любую систему, даже готовую, нужно кому-то поддерживать вручную первое время, иначе она превращается во вторую работу вместо облегчения первой. ИИ-связка: проверка тестов и профиль стажёра, а не просто «прошёл — не прошёл» Тест с вариантами ответов ловит только фактические ошибки: не знает партнёров, путает типы клиентов. Он не ловит главное — понимает ли новичок ценность продукта настолько, чтобы объяснить её клиенту своими словами. Для этого в курс добавили текстовые вопросы пятого дня, а проверку их передали модели, а не только руководителю. Схема конвейера простая: Проверка тестов — Google Sheets + Telegram-бот 5 новичков в потоке за месяц 25 ответов проверено ИИ за месяц 1–2 $ стоимость проверки в месяц Стажёр Вопрос Балл Статус Стажёр А Ценность услуги 2/5 разобрать на созвоне Стажёр Б Ценность услуги 5/5 понимает Данные из LMS падают в Google Sheets по вебхуку: вопрос, эталонный ответ, ответ стажёра. Дальше построчно уходят в модель. Для этого шага не нужна дорогая модель — задача не творческая, а классификационная с элементами анализа текста, поэтому используется дешёвая модель уровня GPT-4o-mini или её аналог: она справляется с оценкой формулировки за секунды и обходится в доли цента за один запрос — при потоке в десятки ответов в день итоговый счёт укладывается в 1–2 $ в месяц (расчёт — ниже). Прикинем стоимость: на одного новичка — 5 текстовых вопросов (день 5). При потоке 5 новичков в месяц это 25 запросов к модели в месяц. Дешёвая модель обходится в доли цента за короткий запрос такого типа, поэтому итоговый счёт — около 1–2 $ в месяц (оценка, консервативно завышена). Дороже стоит не модель, а инженерная обвязка вокруг неё, и то — разово. Пример ответа модели на реальный по структуре вход: Инженерная обвязка простая и дешёвая: Google Apps Script по триггеру на новую строку в таблице вызывает API модели, пишет результат в соседние столбцы. Если запрос падает — скрипт помечает строку статусом «ошибка» и присылает уведомление в тот же Telegram-канал, где обычно идут отчёты по вакансиям. Перезапуск — вручную по кнопке в таблице, отдельного сервера не нужно. Ответственный смотрит канал раз в день, а не сидит и обновляет вкладку. Похожий принцип уже отработан на другом процессе — при найме: агент подключался через API к порталу вакансий, вытягивал отклики и заполнял таблицу метриками и скоринговой оценкой кандидата по критериям — просмотры, клики, отказы, процент релевантных резюме на одном листе, реестр откликов с баллами на другом. Пример ответа: Здесь тоже сработала синхронизация как узкое место: по данным портала было заметно больше откликов, чем зафиксировано в таблице системы. Решением стали два уровня контроля — таймстамп последнего обновления таблицы и Telegram-бот с push-уведомлением о новом отклике с высокой оценкой. Внедрение этих двух улучшений заняло 2 дня. Тот же принцип двойного контроля стоит закладывать и в проверку тестов курса: не доверяйте одной таблице, пока не увидели, что она обновляется вовремя. Третий месяц — точка, которую нужно планировать заранее Курс закрывает первую неделю. Дальше начинается адаптация в реальной работе, и здесь есть закономерность, которую сформулировал один из руководителей: «Первый кризис менеджера всегда случается на третий месяц. Потом либо на шестой, либо на девятый месяц. Это математика, это физика, это закон жизни». Месяц Что происходит Действие руководителя 3-й Первый кризис: усталость, сомнение в себе, спад результатов Не увольнять и не заваливать поддержкой — короткая сессия + чек-лист на неделю 6-й Повторный спад, если первый не был проработан Контролируемая пауза: отпуск на пике, а не в момент обвала 9-й Финальная точка нестабильности перед выходом на плато Профиль сотрудника: сильные/слабые стороны, специализация по клиентам Это не разовый провал конкретного человека, а предсказуемая точка выгорания. Если её не ждать, руководитель реагирует на кризис как на ЧП — увольняет или срочно перегружает поддержкой. Если её ждать, можно управлять падением заранее: на пике производительности отправить менеджера в отпуск, чтобы не допустить раскачки маятника до полного обвала. Задача руководителя в этот момент — не удержать человека на максимуме любой ценой, а организовать контролируемое снижение нагрузки и вывести его на плато. Где ломается Профиль сотрудника и график нагрузки бесполезны, если руководитель узнаёт о кризисе постфактум — по падению цифр в CRM за прошлый месяц. Нужен опережающий сигнал: анализ звонков или чек-ин раз в две недели, а не квартальный отчёт. Без этого точка «3-й месяц» остаётся красивой теорией на бумаге. В разобранном кейсе аналогичный принцип применили к анализу звонков: систему профилирования сотрудника строили на основе расшифровок разговоров — например, задача была собрать заметный объём расшифровок голосовых звонков за неделю и зафиксировать клиентские слова о страхах и проблемах, — чтобы заметить, если менеджер пришёл расстроенный, до того как это отразится на конверсии. Подробнее о том, как считать качество звонков без раздутого отдела контроля, — в материале про контроль качества звонков без ОКК . Экономика адаптации новых сотрудников: что стоит и что даёт Формула для своего случая словами: (часы наставника на одного новичка «было» минус часы «стало») × число новичков в квартал × часовая ставка наставника = экономия в квартал. Дальше — сверх этого — идёт снижение риска сорванных контрактов, посчитанное отдельно во вступлении. Подставим цифры разобранного кейса. Отдел продаж, 5 новичков в квартал. Раньше на каждого уходило до 3 рабочих дней живого времени опытного наставника — по 6 часов чистого общения (оценка, по факту зависело от человека). Это 18 часов на одного новичка, то есть на поток из 5 новичков за квартал — 90 часов, больше двух рабочих недель одного человека, потраченных не на продажи, а на повтор одного и того же материала. При ставке наставника ~1 000 ₽/час (оценка) это 90 000 ₽ скрытых издержек за квартал — не считая упущенных продаж, которые он мог бы закрыть за эти же часы. После перехода на курс живое участие наставника на первом этапе сведено к нулю: он подключается только на разборе исключений — оценочно 2 часа на человека вместо 18. На поток из 5 новичков это 10 часов вместо 90, то есть 10 000 ₽ вместо 90 000 ₽ по той же ставке (оценка) — экономия 80 000 ₽ в квартал только на времени наставника. На диаграмме — часы наставника на одного новичка до и после перехода на курс. 18 ч было 2 ч стало Оценка по кейсу: 18 часов живого общения наставника на одного новичка (3 дня по 6 часов) против 2 часов на разбор исключений после запуска курса. Показатель Значение Часы наставника на 1 новичка, было 18 ч (оценка) Часы наставника на 1 новичка, стало 2 ч (оценка) Экономия часов на поток из 5 новичков в квартал 80 ч (оценка) Экономия в деньгах при ставке ~1 000 ₽/час (оценка) ≈ 80 000 ₽ в квартал Разовые затраты на сборку курса (оценка) ≈ 40 часов методиста и специалиста портала Разовые затраты в деньгах при той же ставке (оценка) ≈ 40 000 ₽ Окупаемость В пределах первого квартала эксплуатации То есть даже консервативно (нижняя граница экономии, верхняя граница затрат на разработку) курс окупает себя за один квартал только на экономии времени наставника — без учёта снижения риска сорванных контрактов (150 000 ₽ в квартал) из вступления. Это вклад именно курса и автоматизации проверки тестов; эффект от программы удержания на третьем месяце в этот расчёт не входит — она считается отдельной инициативой и даёт эффект в горизонте месяцев, а не недель, поэтому смешивать их в одну цифру некорректно. Почему третий месяц — переломный и что за ним стоит, разобрал в материале про текучесть кадров . ИИ-проверка текстовых ответов на дешёвой модели при потоке в 5 новичков в месяц стоит на уровне 1–2 $ в месяц (оценка, см. расчёт выше) — сопоставимо с расходами, разобранными в материале про реальные счета за ИИ . Telegram-бот с уведомлениями — разовая настройка плюс минимальная поддержка хостинга. Что автоматизировать, а что оставить человеку Курс, документы и Telegram-бот с прогрессом — это то, что стоит автоматизировать сразу: рутина, которая раньше отнимала время у опытного сотрудника. Но есть решения, которые автоматизировать рано. В найме сработал тот же принцип, что описан выше: агент собирал данные и выставлял оценки, но окончательное решение по каждому кандидату оставалось за рекрутером — модель училась на его правках, а не подменяла его выбор. В адаптации логика та же: система выдаёт материалы, оценивает текстовые ответы и фиксирует, кто прошёл тест, а кто нет. Решение — верить результату теста или проверить человека на реальном звонке — остаётся за руководителем. Ошибка, которую стоит избежать: автоматизировать сразу весь путь новичка, включая финальное решение о готовности к работе с клиентом. Это тот же класс проблем, что описан в материале про ошибки внедрения ИИ — система без контроля человека на старте выдаёт ложное чувство завершённости процесса, хотя по факту никто не проверил, усвоил ли новичок материал или просто прокликал тест. И вот что я хочу назвать вслух. Умение спроектировать вход человека в работу — так, чтобы он не зависел от того, у кого сегодня нашлось время, — это отдельный управленческий навык. Не эйчаровский, а именно руководителя: он же решает, что отдать машине, а что оставить себе. Раньше без него можно было обойтись — пока новичок один в квартал, его реально вести за руку. Сейчас руководитель, который умеет собрать вход как систему, стоит дороже того, кто умеет только раздавать задачи людям. Мне это далось не сразу: я года полтора считал, что дело в людях, а не в отсутствии описанного процесса. Чек-лист: с чего начать в понедельник Посчитайте, сколько часов в месяц ваши опытные сотрудники сейчас тратят на индивидуальное обучение новичков — это ваша база для сравнения «до/после». Проверьте цепочку доступа: сколько подписей и согласований нужно, чтобы новичок получил логин и технику в первый день. Уберите лишние. Разбейте существующие материалы по обучению на 4–5 логических блоков и добавьте тест в конец каждого — без нового контента, только структура. Настройте одну простую автоматизацию: уведомление руководителю или наставнику, когда новичок не завершил блок в срок. Отметьте в вашем календаре у каждого новичка дату «третий месяц» — заранее, а не когда цифры уже просели. Если решите подключать ИИ-проверку текстовых ответов — начните с одной дешёвой модели и одного вопроса курса, а не со всей программы сразу. Онбординг, который держится на энтузиазме одного наставника, ломается при первом же росте штата. Онбординг, который держится на курсе, документах и понимании, что кризис на третьем месяце — это норма, а не авария, выдерживает масштаб. Разница не в бюджете на автоматизацию. Разница в том, спроектирован процесс заранее или собирается на коленке каждый раз, когда приходит новый человек. Начните с малого: опишите первую неделю нового сотрудника по дням. Что он делает в понедельник, с кем говорит во вторник, что должен уметь к пятнице. Один документ снимает половину вопросов и ускоряет выход на результат. Как собрать адаптацию, которая работает без наставника-героя, — в бесплатном курсе . Что вы получите на выходе Ваш новый сотрудник выходит на результат в два раза быстрее, а вы перестаёте зависеть от того, есть ли у наставника время и настроение. Плюс появляется побочный эффект: описанная адаптация показывает вам, насколько ваши процессы вообще понятны со стороны. Возьмите дату выхода вашего следующего новичка и отсчитайте от неё три месяца — поставьте эту точку в ваш календарь сегодня, пока она не превратилась в срочное увольнение. Как это было у нас Мы держали адаптацию на энтузиазме одного человека — и когда он ушёл в отпуск, два новичка просто просидели неделю. Тогда я и понял, что у нас не система, а везение. Мы описали первую неделю по дням: что делает новичок, с кем встречается, что должен уметь к пятнице. Заняло у меня три часа. Следующий сотрудник вышел на результат вдвое быстрее предыдущего — при том, что наставника у него не было вообще. ## Квалификация лидов: куда утекают деньги между маркетингом и продажами URL: https://davidgerstein.pro/blog/lidy-est-prodazh-net/ Дата: 2026-07-22 Направление: Маркетинг Цифры: 44 лида → 1-2 продажи · конверсия упала с 33% до 6% · брак лидов втрое выше плановых 20% Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Лиды идут, отчёты зелёные, а продаж нет. Если вы сейчас смотрите в отчёт, где заявок больше, чем месяц назад, а денег столько же или меньше, — диагноз простой: вы платите за трафик, который до кассы не доходит, и не знаете, на каком метре он останавливается. Первое желание — обвинить маркетинг в качестве трафика или продажников в лени. Обычно виноваты не они, а стык между ними, за который не отвечает никто. Несколько десятков качественных лидов из социальной сети за месяц. Отдел продаж закрыл 1-2. Руководитель смотрит на отчёт и не понимает: трафик есть, лиды помечены как качественные, а денег нет. Это не редкий случай — это самая частая точка разрыва между маркетингом и продажами, которую я вижу в компаниях. Разбор показал: эти лиды были первым касанием. Человек увидел пост, оставил заявку — и всё, для него это начало пути, а не готовность купить. А отдел продаж работал с ними так же, как с лидами из контекстной рекламы, где человек уже искал услугу и морально готов купить. Разные источники требуют разного цикла продажи, а система работала одним шаблоном на все. Пока это не поправили, каждый месяц компания платила за трафик, который физически не мог конвертироваться в срок одного звонка. Здесь честно скажу: я сам разбирался в этом не сразу. Я долго считал, что если лид помечен как качественный, то дальше дело за продажами, — и месяцами смотрел не туда. Понял только тогда, когда сел и вручную проследил путь двадцати заявок от заявки до первого звонка. Так что если вы сейчас в этой точке — вы не в отстающих. Вы просто ещё не делали этот замер. Почему лиды есть, а продаж нет? Потому что деньги теряются не в трафике, а на стыке маркетинга и продаж: в одном месяце 44 лида дали 1-2 продажи, хотя все были помечены как качественные. Три типовые причины — с лидом первого касания работают по сценарию для горячего, CRM плодит дубли и не атрибутирует 10-15% заявок, а оффер бьёт не в тот сегмент: после смены текста объявления конверсия упала с 33% до 6%. Проверять надо в этом порядке: сначала подсчёт (дубли, атрибуция, метод фиксации продажи), потом соответствие стратегии продаж источнику лида, и только потом качество самого трафика. Брак лидов в этом канале оказался втрое выше плановых 20% — значит, реальная цена годного лида была вдвое выше расчётной, при том же бюджете на канал. Квалификация лидов: четыре места, где деньги теряются Четыре точки разрыва. Пройдите по ним и найдите свою — обычно она одна, и она же объясняет всю картину. Прежде чем менять маркетинг, я всегда проверяю три вещи по порядку: правильно ли считаются лиды, правильно ли они атрибутируются, и правильно ли с ними работает продажа. В моей практике в 80% случаев (оценка, по частоте разборов) проблема находится в первых двух пунктах, а не в третьем — но именно продажи обычно обвиняют первыми. Дубли, которые красят картину в чёрный цвет В одной системе аналитики одна входящая точка создавала два-три дубликата лида. Показатели конверсии падали день ото дня — хотя реальная ситуация была другой. Руководитель обнаружил это случайно, читая утренний отчёт и заметив, что цифры не бьются с ощущением от работы отдела продаж. Похожая история с расхождением в отчётах по продажам: у разных менеджеров цифры в отчётах заметно не совпадали. При проверке через CRM выяснилось: потеряна одна сделка, потому что её посчитали рекомендацией, а не лидом. А при фильтрации по месяцу оплаты вместо месяца создания договора разница выросла ещё сильнее. Дело не в человеке — так работает система: без единого метода подсчёта данные теряются сами, стоит только считать их вручную или разными способами в разных отчётах. Подробнее про то, как CRM искажает цифры из-за сдвига дат и метода подсчёта, я разбирал в отдельной статье про сверку данных по ID . Атрибуция, которая тает на глазах 10-15% лидов невозможно атрибутировать к каналу — пользователи блокируют куки, чистят историю, ставят блокировщики рекламы. В декабре эта доля подскочила до 30%. Если не выделять эту категорию отдельно, отчёт по каналам врёт: кажется, что один источник не работает, хотя на деле часть его лидов просто не засчиталась. Правило Прежде чем менять стратегию канала из-за низкой конверсии, проверь три вещи: нет ли дублей, сколько лидов не атрибутировано, и одинаковым ли методом считаются продажи в разных отчётах. Часто «проблема с лидами» — это проблема с подсчётом лидов. Что делать вам, если качество лидов упало Сначала проверьте свою сторону: скорость ответа, форму, первый вопрос менеджера. Половина «некачественных» лидов становится такими уже после попадания к вам. Компания провела эксперимент — изменила текст объявления по совету экономиста. Результат: конверсия упала с 33% до 6%, в 5,5 раза. При этом объём лидов вырос на 25%. Больше заявок, но качество село — лиды пошли из другого сегмента — с меньшим бюджетом и более длинным решением. Классическая ловушка: смотреть на количество лидов и не смотреть на их структуру. На диаграмме ниже — конверсия лидов в продажу до и после смены текста. 33% было 6% стало Конверсия лидов в продажу до и после смены текста объявления по совету экономиста. Объём лидов при этом вырос на 25%, но за счёт возрастной и иногородней аудитории, не готовой к покупке. Команда разошлась во мнениях: один настаивал продолжить тест, второй видел проблему и требовал остановки. Решение отложили до анализа региональной структуры. Это правильный шаг — но его нужно было делать до запуска на весь бюджет, а не после падения в 5,5 раза. Тестировать формулировку оффера стоит на 10-15% бюджета и сразу смотреть не только количество лидов, но и структуру: возраст, регион, источник. Сегментация вместо стрельбы по площадям Маркетолог честно признал: раньше продавали услугу, описывая процедуру оформления документов, которая клиенту неинтересна. За неделю с аналитиком собрали три типовых портрета покупателя — часто это люди старшего возраста, одинокие или с выросшими детьми, ищущие общие интересы. После этого стали работать с болью клиента, а не с процедурой. Конверсия пошла вверх без увеличения бюджета — это заслуга именно сегментации, отдельно от других изменений в кампании, которые шли параллельно. Похожая логика — с крупной базой контактов с вероятностью целевого признака выше 25%. Пробная рассылка на небольшую выборку дала открываемость 50%, но конверсию в лиды — 0%. Вывод команды: «не понимая сегментацию клиента, бить в лоб бесполезно, это стрелять из пушки по воробьям». Решили заменить одно прямое предложение серией из 3-4 писем с конкретными преимуществами — здоровье, поиск родственников, путешествия — и только потом анонсировать событие. Как считать цену лида, который дошёл до сделки Из полученных лидов лишь около 40% оказались качественными по контролю качества. Планировали отвал не более 20%, получили 60%. Бюджет на канал не менялся, а годных лидов на выходе стало в полтора-два раза меньше — значит и цена каждого годного лида выросла ровно во столько же раз (оценка по пропорции план/факт). Наглядно, на условных числах: если качественные лиды — это 40% от общего пула, то при плановом отвале 20% тот же пул лидов дал бы вдвое больше качественных — при том же бюджете на канал. Факт оказался ровно в два раза меньше плана. Бюджет не менялся, а делится он теперь на вдвое меньшее число годных лидов — значит цена одного качественного лида для этого канала не «немного выросла», а буквально удвоилась. Формула для своего случая: возьмите долю годных лидов по плану (100% минус плановый отвал) и разделите на фактическую долю годных — получите, во сколько раз реальная цена лида выше расчётной. Показатель План Факт Отвал лидов до 20% 60% Лиды в мае / июне (план) рост на треть — Качественные лиды в день 15 16-17 (без выходных) Валовые лиды в день (все источники) — ~50 Неатрибутируемые лиды — 10-15%, в декабре до 30% На диаграмме — соотношение валовых и качественных лидов в день, план и факт. Валовые лиды/день 50 Качественные (факт) 16-17 Качественные (план) 15 50 валовых лидов в день превращаются в 16-17 качественных. Канал тут ни при чём — так устроена воронка, если знать это заранее и планировать бюджет от неё, а не от валового числа. Компания, которая планирует заметный рост лидов на следующий месяц, должна понимать: из них может оказаться качественными меньше половины, если канал новый или сегментация не отработана. Отдельная история — синхронизация оплаты и поставки лидов. Чтобы получить лиды в начале месяца, нужно оплатить их ещё 28-го числа предыдущего. Если половина счетов не оплачивается вовремя — а именно так и было — весь цикл привлечения сдвигается, и «недобор лидов» на самом деле означает «недоплата в срок». Это тот случай, когда причина проблемы с продажами лежит не в маркетинге и не в отделе продаж, а в бухгалтерии. ИИ-связка: автоматический поиск разрыва Здесь машина показывает вам, где именно и на сколько застревают ваши лиды, — без ручного разбора каждой карточки. Ручная сверка отчётов — то, чем вручную занимался руководитель, когда случайно заметил дубли, — не масштабируется. При потоке 50 лидов в день невозможно каждый день вручную сверять источник, дедупликацию и приоритет для менеджера. Здесь и встраивается ИИ-скоринг: не вместо контроля качества, а как первый фильтр, который сразу подсвечивает, с кем работать в первую очередь и почему. Схема конвейера простая и без лишних сервисов: лид падает в CRM (amoCRM или Bitrix24) → вебхук пишет строку в Google Sheets → скрипт по таймеру раз в 15 минут проверяет новые строки без оценки → вызывает дешёвую модель с промптом ниже → записывает score и рекомендацию обратно в таблицу и в карточку CRM → при score выше порога уходит уведомление менеджеру в Telegram. Модель здесь нужна дешёвая: задача — не творческий текст, а структурированная оценка по понятным критериям, с этим справляется лёгкая модель уровня GPT-4o-mini или аналог, дорогая модель тут не нужна и не окупается на потоке 50 лидов в день. Пример ответа модели на такой запрос: Инженерная обвязка Всё крутится на связке CRM-вебхук + Google Apps Script + Google Sheets — без отдельного сервера. Вебхук из CRM пишет сырые данные лида построчно. Скрипт по таймеру раз в 15 минут ищет строки без заполненной колонки score, отправляет их в API модели, пишет ответ обратно. Если API недоступен или вернул не-JSON — скрипт помечает строку статусом «ERROR», логирует причину в отдельный лист ошибок и повторяет попытку через час, не блокируя обработку остальных строк. Раз в день отдельный отчёт в тот же Telegram-канал: сколько лидов обработано, сколько ушло в ошибку — это тот минимальный алерт, которого не хватило в истории с ботом, о которой ниже. Зачем сводить рекламу и продажи, если лиды и так идут Как собрать такую связку с нуля — как её собрать . «Отсутствие информации — это отсутствие рычагов давления. И это меня прям очень сильно бесит» — так один руководитель описал ситуацию, когда невозможно разделить конверсию по источникам трафика, потому что интеграция между рекламными кабинетами и CRM не позволяет этого сделать. Без сквозной аналитики компания видит только суммарную цифру и не может сказать, какой канал реально приносит продажи, а какой — только формальные конверсии в CRM. Пример: SEO-специалист внедрил реал-тайм дашборд по лидам и конверсиям за один уикенд вместо обещанных суток. Дальше выяснилось: трафик растёт, а продажи в мае упали. Без дашборда это выглядело бы как «маркетинг работает». С дашбордом стало ясно — работает трафик, не работает что-то дальше по воронке. Похожая логика в тесте по позициям в топ-3 Яндекса до середины июня: цель — понять, коррелирует ли рост трафика с продажами, прежде чем масштабировать бюджет на продвижение. Дашборд: лиды и конверсия 50 валовых лидов/день 16-17 качественных лидов/день 60% факт. отвал лидов <10% конверсия органики, апрель Месяц Конверсия органики Статус Январь 17% Март ~15% Апрель <10% Ещё один сигнал того же порядка: конверсия органического трафика упала ниже 10% в апреле, хотя в январе была 17%, в марте — почти 15%. Такое снижение три месяца подряд — уже не шум, а тренд, и виден он только тогда, когда смотришь данные по месяцам, а не по последней неделе. Дашборд полезен только тогда, когда данные в нём читаемы, а не спрятаны в методичке. В одном случае анализ крупного массива отклонённых лидов выдали в виде Excel с формулами, которые нужно было вручную разбирать, вместо наглядного дашборда — это тот же провал сквозной аналитики, только с другой стороны: данные вроде бы есть, а рычага для решений из них не получить, пока кто-то не потратит часы на ручной разбор таблиц. Когда автоматизация теряет данные молча У одного клиента неделю не работал автоматизированный бот для сбора лидов, но команда не спешила это чинить — общий бизнес приносил деньги, и отдельная проблема модуля не казалась критичной. Итог — потеря данных о потенциальных клиентах за длительный период, которую никто не заметил вовремя, потому что не было алерта на остановку модуля. Про то, что автоматизация без постоянного присмотра превращается во вторую работу, я писал в статье про автоматизацию, которая требует надзора . Где ломается Сквозная аналитика не спасает, если данные в неё попадают с дублями, без атрибуции и с ручными правками задним числом. Сначала чистые данные — потом дашборды и выводы по каналам. И второе ограничение: ИИ-скоринг из раздела выше не заменяет контроль качества — модель оценивает вероятность по косвенным признакам, а не проверяет реальность документов или намерений, это разные задачи с разной ценой ошибки. Экономика внедрения: сколько стоит настройка ИИ-скоринга и что она экономит Внедрение связки «вебхук → Google Sheets → скоринг → Telegram-уведомление» — это, по моей оценке, 6-8 часов работы разработчика или аналитика на настройку скрипта и обкатку промпта, плюс 1-2 часа юриста на проверку передаваемых данных; эксплуатация — порядка 1500 запросов в месяц к дешёвой модели, единицы долларов, не заметная статья расходов. Тему, какие данные лида можно передавать во внешний API, я разбирал отдельно в статье про персональные данные и нейросети . При типовой почасовой ставке фриланс-разработчика настройка обойдётся в сумму, сопоставимую с одним рабочим днём специалиста (оценка). Эффект считаю отдельно от эффекта самой сегментации и от эффекта чистки дублей — это разные инициативы, и мешать их вклад в одну цифру нечестно. Вклад именно скоринга и дашборда — это высвобожденное время на ручную приоритизацию заявок. Если РОП или менеджер тратит около часа в день на то, чтобы вручную решить, кому звонить в первую очередь среди полусотни новых заявок, это несколько десятков рабочих часов в месяц. Формула для своего случая: часы ручной работы в день × рабочие дни в месяц × ставка часа сотрудника (~1000 ₽/час) = скрытые расходы на ручную приоритизацию в месяц. При такой ставке это даёт сумму, сопоставимую со стоимостью настройки скоринга за месяц, которую снимает автоматизация — то есть окупаемость укладывается в первый месяц эксплуатации, дальше это чистая экономия времени. Что мы не считаем эффектом: если освободившийся час РОП тратит на другие задачи, а не на звонки клиентам, прямого прироста выручки это не даёт — только перераспределение рабочего времени. Отдельно — иллюстративный расчёт цены самой проблемы «разные источники требуют разной стратегии», на профиле условной компании из плашки выше: отдел продаж 8 менеджеров, у каждого в активной работе 5 сделок в месяц — итого 40 сделок, средний чек 180 тыс. ₽. Если 10% сделок зависает именно на стыке маркетинга и продаж — потому что с холодным первым касанием работают по сценарию для горячего лида, — это 4 сделки в месяц, риск ≈ 720 000 ₽ выручки в месяц (оценка). Даже если на практике зависает не 10%, а 3-5% (1-2 сделки, риск ≈ 180 000-360 000 ₽), порядок цифр показывает: разница в стратегии продажи по источникам стоит дороже, чем настройка скоринга и дашборда вместе взятых. Порядок действий: с чего начинать разбор Порядок действий, который у меня сработал: сначала проверить подсчёт (дубли, атрибуция, метод фиксации продажи), потом проверить соответствие стратегии продаж источнику лида (первое касание — это не готовая сделка), и только потом разбираться с качеством самого трафика через сегментацию аудитории. Тестировать изменения в оффере нужно на небольшой доле бюджета и сразу смотреть структуру лидов, а не только их количество — иначе можно повторить историю с падением конверсии в 5,5 раза. Отдельно стоит следить за скоростью реакции на аномалии. Замороженные вебинары без единого мероприятия за месяц, неработающий бот, который никто не чинит неделю, — такие вещи находят случайно, если не выстроен регулярный контроль. Похожий принцип регулярного контроля я описывал применительно к оценке звонков менеджеров — там тоже без системного просмотра проблемы копятся незаметно, разбор в статье про контроль качества звонков показывает, как это выглядит на практике. Чек-лист на понедельник Выгрузить из CRM все лиды за последний месяц и вручную проверить 20-30 карточек на дубли по телефону/email — если находишь больше 2-3%, чинить дедупликацию раньше, чем менять стратегию канала. Посчитать долю неатрибутируемых лидов за последние 3 месяца отдельной строкой в отчёте — не смешивать её с «плохим каналом». Сверить метод подсчёта продаж в разных отчётах: по дате создания сделки или по дате оплаты — разница может быть в десятки процентов. Выписать реальный % брака по каждому источнику лидов за месяц и сравнить с плановым — если факт вдвое выше плана, стоимость лида тоже примерно вдвое выше расчётной. Проверить, есть ли алерт на остановку каждого источника лидов (бот, форма, вебинар) — если алерта нет, поставить хотя бы ежедневную сверку количества по часам. Собрать 2-3 портрета покупателя с отделом продаж за одну встречу — не с нуля, а спросить менеджеров, кто чаще всего реально покупает и почему. И назову вещь своим именем. Умение читать стык маркетинга и продаж по цифрам — это новый управленческий навык, а не работа аналитика, которую можно кому-то отдать. Руководитель, который за пятнадцать минут отвечает, сколько лидов пришло, сколько из них дубли, сколько не атрибутировано и через сколько минут с ними связались, стоит дороже руководителя, который управляет по ощущению отдела продаж. Навык осваивается на одном месяце данных — но осваивать его придётся вам лично: делегировать его некому, потому что делегируется задача, а не понимание. Проверьте свой стык на этой неделе: возьмите двадцать последних лидов и проследите путь каждого до первого контакта. Сколько времени прошло, кто взял, что сказал. Обычно после такой проверки вопрос «почему нет продаж» отпадает сам. Как выстроить передачу лида без потерь — в бесплатном курсе для руководителей . И главное, что стоит проверить именно вам: кто в вашей компании отвечает за лид в момент, когда маркетинг его передал, а продажи ещё не взяли. Если ответа нет — вот вам и причина. Ваши деньги теряются в этой паузе, и ни один отчёт вам её не покажет. Ваш план на неделю Сделайте три вещи. Первое: возьмите двадцать своих последних лидов и проверьте, через сколько минут с ними связались. Второе: посмотрите, у скольких из них вообще есть ответственный менеджер в вашей CRM. Третье: спросите ваших продавцов, что они думают о качестве лидов, и сравните их ответ с цифрами из первых двух пунктов. Обычно после этого упражнения вы понимаете, что ваша проблема не в маркетинге и не в продажах, а в стыке между ними — и чинить надо именно его. И проверьте вашу собственную реакцию на эти цифры: если вы сейчас подумали «у нас точно не так» — тем более сделайте замер. Мы тоже были уверены, что у нас с этим порядок, пока не посмотрели на двадцать конкретных лидов и не увидели, что половина ждала ответа больше суток. Ваш вывод из этого разбора должен быть простым: прежде чем покупать больше лидов, посмотрите, что происходит с теми, что у вас уже есть. Мы у себя закрыли этот разрыв простым правилом: у лида есть ответственный с первой секунды. Ни техники, ни бюджета — и потери сократились в разы. ## Управленческий учёт: три отчёта, без которых собственник слеп URL: https://davidgerstein.pro/blog/upravlencheskij-uchet-s-nulya/ Дата: 2026-07-21 Направление: Финансы Цифры: дефицит 1,8 млн ₽/мес · резерв 30% от прибыли (165 тыс ₽/мес) · долг перед поставщиком 700 тыс ₽ Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Простой вопрос: вы можете прямо сейчас, не открывая ничего, назвать, сколько денег придёт на счёт на следующей неделе и сколько уйдёт? Если нет — вы не управляете компанией, вы её сопровождаете. Извините за прямоту, но по-другому это не назвать. Я сам жил в этой позиции дольше, чем готов признать: прибыль вроде есть, отчёты кто-то делает, а к двадцатому числу выясняется, что платить нечем. Причём каждый раз это «неожиданно» — хотя цифры лежали на виду за месяц. Ниже — три отчёта, с которых начинается зрячее управление, и разбор конкретного месяца, где дефицит в 1,8 млн ₽ был виден заранее, но его никто не увидел. Расходы компании составили 13,8 млн ₽ при выручке 12 млн ₽ за месяц — превышение на 15%. Дефицит кэша по итогам месяца — 1,8 млн ₽, и этой суммы не хватило даже на зарплаты. Формула здесь простая, и её стоит держать в голове дальше: дефицит месяца = расходы за месяц минус фактические поступления за тот же месяц. В нашем случае 13,8 млн минус 12 млн — те самые 1,8 млн ₽ дефицита, ни рублём меньше. Это не разовая авария, а результат того, что месяцами никто не сверял «прибыль есть» с «деньги есть». Вопрос «управленческий учёт — с чего начать» обычно всплывает, когда разрыв уже случился. Правильнее задавать его раньше. Расходы 13,8 млн ₽ Выручка 12 млн ₽ На диаграмме — расходы против выручки за месяц: разница между линиями и есть тот самый дефицит в 1,8 млн ₽, о котором идёт речь. Дальше — не теория, а три отчёта, которые я видел в работе живых компаний: где они спасали, а где их отсутствие стоило денег, доверия и долгов перед поставщиками. Что такое управленческий учёт и с чего его начать Управленческий учёт — это учёт для собственника, а не для налоговой: он отвечает не на вопрос «как отчитаться», а на вопрос «чем платить и на чём мы зарабатываем». Начинается он с трёх отчётов, а не с покупки системы. ДДС — движение денег на четыре недели вперёд, показывает кассовые разрывы заранее. П&У — прибыль без иллюзий, с учётом обязательств. Резервы и дебиторка — сколько вам должны и когда заплатят. Первый отчёт собирается за час в обычной таблице. Если он поймает хотя бы один забытый платёж, час окупился — а дальше станет понятно, что именно автоматизировать. Три отчёта вместо одной большой таблицы в Excel Смотрите, что обычно происходит у вас. Есть таблица, которую ведёт бухгалтер или помощник, в неё сваливается всё подряд, и раз в месяц вы туда заглядываете. Проблема не в таблице — проблема в том, что она отвечает на вопрос «что было», а вам нужны ответы на три разных вопроса, и один отчёт их не даёт. Собственники часто просят «финансовую отчётность» — и получают один разросшийся файл, где вперемешку прибыль, остатки на счетах и планы. Это не работает: вопросы у отчётов разные, и смешивать их — значит не отвечать ни на один точно. Разделить отчёты по вопросам — половина дела; вторая половина в том, чтобы у каждой цифры был назначен хозяин и срок обновления . Отчёт Что показывает На какой вопрос отвечает Как часто смотреть ДДС Реальное движение денег по датам платежей Хватит ли денег на зарплаты и обязательства через 2 недели Еженедельно, в кризис — ежедневно П&У Доходы и расходы периода, включая то, что ещё не оплачено Заработали ли мы на самом деле Помесячно Резервы и дебиторка Что нам должны и что мы отложили на риск Есть ли подушка на случай задержки платежей клиентов Ежедневно Три отчёта закрывают три разных провала. Без ДДС компания узнаёт о кассовом разрыве, когда платить уже нечем. Без П&У раздают бонусы из прибыли, которой на деле не было. А без контроля дебиторки и резервов живут по кругу: получили деньги — потратили — через три месяца клиент требует возврат, а денег уже нет. ДДС: отчёт, который должен был предупредить за месяц Финансовый директор рассчитал прибыль за период — 900 000 ₽ — и распределил её между сотрудниками. Тут же выяснилось: денег на оплату рекламы нет, коллеге пришлось вносить личные средства. Разбор показал — кассовый разрыв был виден за месяц-два до того, как случился. Резервный фонд под него никто не создавал. Похожая история — с финансовым менеджером, который брал деньги под зарплаты и дивиденды, не зная о критических периодах цикла поступлений (четыре недели). Ошибка должна была быть видна уже 15 мая. Резерв на маркетинг не формировался никогда. ДДС — единственный отчёт, который отвечает на вопрос «хватит ли денег через две недели». Не «сколько мы заработали», а именно «сколько реально на счетах и что должно списаться раньше, чем придёт следующий платёж». Когда его нет, руководство узнаёт о проблеме в моменте: «мне очень нужно, чтобы платёж подрядчику был оплачен, он до сих пор не оплачен, нужно буквально за полчаса» — так формулируется кризис, который ДДС показал бы за неделю до того, как он стал кризисом. Показательный побочный эффект того же отсутствия ДДС — задержка в мае финансирования части рекламных кампаний. Площадки, работающие по предоплате, начали хуже отрабатывать бюджет сразу после задержки: это не абстрактный «риск», а конкретная механика, по которой кассовый разрыв бьёт по будущей выручке, а не только по текущим платежам. Правило ДДС строится по датам реальных платежей, а не по датам договоров и не по датам согласования. Если в отчёте фигурируют «планируемые к оплате» суммы вперемешку с уже прошедшими — это не ДДС, а желаемое, выданное за факт. П&У: почему нельзя делить прибыль, которой ещё нет «Мы не можем распределить всю премию, давайте подождём» — эта фраза прозвучала после того, как компания уже успела распределить прибыль, которой фактически не было, вместо того чтобы формировать резервы на маркетинг. Похожая логика привела к тому, что оставшийся кэш решили вложить в маркетинг в начале месяца вместо зарплат — сознательно рискуя тем, что к 15-му числу понадобится финансовая помощь, и заранее готовя документы на кредит. Другая история — мотивация, завязанная не на тот момент. В одной компании спорили: начислять бонус в момент подписания договора с клиентом или дожидаться платежа. Решили — только по факту получения денег. Тот же принцип держит и весь П&У: доход признаётся, когда он реально случился, а не когда кто-то пообещал, что случится. Отдельно в П&У ломаются необъяснимые скачки статей. Собственник потребовал к утру следующего дня детализацию расходов за два месяца — фонд заработной платы вырос с 950 000 ₽ до 1 850 000 ₽ (плюс 94,7% к плану), без единого нового сотрудника на восьмидневке. Без П&У с разбивкой по статьям такой скачок замечают, когда деньги уже потрачены — не раньше. П&У по одному усреднённому числу за квартал или за год маскирует ровно такие скачки. У руководителя производства средняя зарплата с января держалась на стабильном уровне, но в один из месяцев упала в несколько раз ниже среднего — почти в 4,7 раза, тогда как у другого руководителя в тот же месяц разрыв со средним составил около 1,9 раза. Если смотреть только на средний показатель, такую просадку не видно вообще; она всплывает лишь тогда, когда П&У строится помесячно, а не «в целом за период». Третий случай — крупные маркетинговые вложения. Компания потратила 480 000 ₽ резервных средств на рекламные кампании, и встал вопрос: это текущий расход или инвестиция? Решили привязать к результату — если кампании окупились продажами, расход показывается в полном объёме вместе с доходом; если ушли в убыток, списывается на резервы, без искажения месячных показателей. Это и есть управленческий учёт в действии: не формальная бухгалтерская проводка, а решение, которое честно показывает, что произошло с деньгами и почему. Резервы и дебиторка: цифры, которые должны быть на экране каждый день Компания продавала услугу с маржинальностью 25–30% при выручке услуги около 2 000 000 ₽ в месяц, но цикл работы занимал три месяца до получения платежа, а расходы приходилось авансировать. Резервов не откладывали. В апреле лимит фонда составил 360 000 ₽ — на порядок меньше реальной потребности в 3 600 000 ₽. Договорились откладывать 30% от прибыли на резервы — но это решение пришло уже после того, как накопился долг перед поставщиком услуг в 700 000 ₽ — 35% от месячной выручки этой услуги. Если прикинуть этот резерв в абсолютных цифрах (оценка, консервативно): прибыль в месяц при выручке услуги 2 000 000 ₽ и марже 25–30% — примерно 550 000 ₽. 30% от этой прибыли — около 165 000 ₽ в месяц. Разрыв между этим темпом накопления (165 000 ₽/мес) и разовой потребностью в 3 600 000 ₽ виден сразу: Показатель Без резерва С резервом 30% от прибыли Выручка услуги в месяц 2 000 000 ₽ Маржинальность 25–30% Прибыль в месяц (оценка) ≈550 000 ₽ Откладывается в резерв (оценка) 0 ≈165 000 ₽/мес Лимит фонда в апреле (факт) 360 000 ₽ — Реальная потребность на кейс 3 600 000 ₽ 3 600 000 ₽ Итог Долг перед поставщиком — 700 000 ₽ При темпе 165 000 ₽/мес нужно почти два года, чтобы накопить 3,6 млн ₽ — резерва в 30% от прибыли одной этой услуги недостаточно, нужен либо более высокий процент, либо другой источник финансирования цикла Это ключевой вывод для любого расчёта резерва: сама формула «откладывать N% от прибыли» не работает без проверки, догоняет ли она реальный цикл платежей. Если цикл — три месяца, а резерв копится медленнее, чем растёт потребность, разрыв просто переносится вперёд, а не закрывается. Если экстраполировать ту же логику на типичный отдел продаж: 8 менеджеров, средний чек 250 000 ₽, оборот около 12 000 000 ₽ в месяц — это примерно 48 сделок. Если 10% из них регулярно зависает в дебиторке дольше срока оплаты по договору, под риском оказывается около 1 200 000 ₽ в месяц (оценка, консервативно). Именно эту цифру должен видеть на экране финансист каждый день, а не раз в квартал в сводном отчёте. Похожая логика — в истории с клиентом, который внёс предоплату криптовалютой, а компания из-за курсовой разницы зачислила себе на счёт сумму примерно на 10% больше номинала. Клиент позже потребовал полный возврат в тот же день. Без готового резерва такой возврат — это всегда чей-то кассовый разрыв прямо сейчас. Решение вернуть около 82% от зачисленной суммы, удержав расходы и часть бонуса, — это конкретный пример того, как отсутствие заранее просчитанной политики возвратов конвертируется в потерю около 18% от суммы просто на урегулирование, вместо того чтобы урегулирование было прописано в регламенте заранее. Ещё один пример того же порядка — распределение одного платежа между тремя счетами (два расчётных и налоговый) при острой нехватке ликвидности. В таких условиях задача финансиста — не решать самостоятельно, что важнее, а оперативно доносить до руководства реальную картину дефицита и сроков обязательств. Без ежедневного среза по дебиторке и резервам это решение принимается на ощупь, а не на цифрах. После этого в задачи руководителя добавили ежедневное отслеживание трёх метрик: объём дебиторской задолженности, её распределение по срокам возникновения и по пакетам услуг. Цифры должны быть видны в системе отчётности постоянно, а не всплывать раз в месяц на планёрке. Подробнее про то, как выстроить контроль дебиторки так, чтобы он не зависел от памяти конкретного человека — в отдельном разборе про контроль дебиторки . И отдельно — вопрос доверия к самим данным, из которых строится отчётность. В одной компании обнаружили: даты создания лидов в CRM самопроизвольно сдвигаются при синхронизации — от 18 до 36 часов. Попади такие искажения в ДДС или в расчёт выручки по периодам — отчёт врёт красиво и уверенно. Прежде чем строить управленческий учёт поверх CRM, стоит убедиться, что она сама не путает даты — я разбирал это отдельно, в кейсе про как CRM врёт с датами . Где ломается Резервы формируются, только когда их формально включают в план — «отложить 30% от прибыли» должно быть строкой в бюджете, а не намерением. Иначе при первой нехватке денег резерв тратится первым, а долг перед поставщиком остаётся вторым. С чего начать: четыре шага вместо интуиции Дальше — то, что вы можете сделать сами, без финдиректора и без внедрения систем. Начинать надо не с покупки программы, а с этих четырёх шагов: они дадут вам понимание, которое потом определит, какая программа вам вообще нужна. Когда компания запрашивала увеличение лимита расходов на проектную услугу, обоснование звучало так: «мы тратим больше, нам не хватает, поэтому давайте его увеличим». Это классика неначатого управленческого учёта: аргумент есть, цифр под ним нет. Руководитель потребовал пересчитать лимит в привязке к росту выручки и провести анализ по двум периодам — базовому (июнь–сентябрь) и текущему (октябрь и далее). Решение свелось к четырём шагам, которые подходят как шаблон для запуска учёта с нуля: выгрузить закрытые документы за базовый период с расчётом себестоимости — это фундамент для П&У; выгрузить созданные сделки за текущий период — основа для ДДС и прогноза притока денег; сравнить помесячный прирост количества и стоимости, отдельно по регионам — здесь видно, где рост реальный, а где — статистическая случайность; выявить аномалии в удорожании отдельных статей — то, что в П&У выглядит как необъяснимый скачок вроде резкого роста ФОТ. Похожий принцип сработал и с финансовым сотрудником, который просил увеличить ежемесячный лимит фонда в полтора раза, но не смог ответить ни на один вопрос о юнит-экономике и связи расхода с заработком. Выяснилось попутно, что лимит апреля уже был превышен — то есть оплатить апрельские расходы из апрельского же бюджета всё равно было бы нечем, даже без увеличения лимита. Ответ был простой: приходи с расчётом, сколько мы заработаем на эти деньги, иначе согласования не будет. Это правило стоит закрепить с самого начала выстраивания учёта: любой запрос на увеличение бюджета сопровождается расчётом отдачи, а не ощущением «нам не хватает». С этого же принципа стоит начинать сверку расходов, которые никто не может обосновать числом. Когда руководитель запросил 30 видео по 15 000 ₽ за штуку (в сумме 450 000 ₽ — около 4% месячного оборота), никто не смог назвать конкретную цифру объёма — расход отклонили до уточнения. Так же обнаружились и регулярные небольшие выплаты дворнику наличными из офисного фонда — при том, что сам фонд был выдан под устное указание вести реестр, а трат из него никто формально не согласовывал. Управленческий учёт с нуля — это в первую очередь такая ревизия: пройтись по каждой регулярной статье и спросить, откуда взялась цифра и кто может её подтвердить. Начинать без месяца подготовки можно с малого: выгрузить ДДС за последние два-три месяца по факту оплат, сложить рядом П&У за тот же период по факту начислений, и отдельно вывести список дебиторки с датами возникновения. Это займёт день, а не квартал — и первую же неделю покажет, где деньги реально теряются, а не где кажется, что теряются. ИИ в связке: как собирать три отчёта, а не сводить их руками Руководитель маркетинга однажды за неделю решил задачу, которую два года не могли решить вручную: сопоставить сотни тысяч строк лидов с позициями в поиске и ключевыми словами. Excel такой объём не тянул, а модель справилась за неделю лучше, чем прежний ручной процесс за два года. Тот же принцип работает и в управленческом учёте: три отчёта — это не про креативность, а про объём строк, которые нужно сверить с планом и друг с другом. Это задача, которую не обязательно делать руками каждую неделю. Не всякая автоматизация требует связки из скрипта и двух моделей. Когда выяснилось, что партнёры по реферальной программе задерживают информацию о вознаграждениях до момента, когда клиент сам попросит возврат, решение заняло около 20 минут: настроить автоматическое уведомление в боте о закрытии проекта реферала. Это тот случай, когда проблема — не в объёме данных, а в отсутствии одного триггера; конвейер ниже нужен там, где строк действительно много и руками их не пересмотреть. Механика конвейера простая, без экзотики: Источник данных. Ежедневная выгрузка сделок, платежей и закрытых документов через Bitrix24 REST API (или amoCRM API) в Google Sheets, вкладка «raw_dds» — суммы, даты, статьи, счета. Первичная проверка. Google Apps Script по расписанию отправляет строки за сутки в дешёвую модель — она считает отклонение факта от плана по каждой статье и помечает подозрительные строки. Углублённый разбор. Строки с отклонением выше порога уходят в дорогую модель — она формулирует гипотезу причины на основе доступных данных, без домыслов, и просит уточнения там, где данных не хватает. Результат. Помеченные аномалии падают во вкладку «anomalies» и дублируются уведомлением в Telegram-бот финансисту и собственнику. Кто смотрит. Дебиторку и ДДС — финансист ежедневно, сводку по П&У и аномалиям — собственник раз в неделю, в фиксированное время, а не «когда будет минутка». Промпт для первого шага — намеренно скучный и жёсткий, потому что задача не творческая, а счётная. На вход — JSON-массив строк расходов за период, на выходе — тот же массив с расчётом отклонения и пометкой аномалии: Модель на этом шаге — дешёвая (уровня GPT-4o-mini или аналогичного класса): задача построчная, без творчества, и счёт может идти на сотни строк в месяц. Дорогая модель подключается только к строкам с anomaly: true — обычно это 5–10% от общего потока, и именно там нужна более развёрнутая формулировка причины для отчёта собственнику, а не для очередной таблицы. Пример входных данных (три строки из типичного месячного среза, суммы условные — для иллюстрации логики): Пример ответа модели: Именно эти помеченные строки и попадают на экран, который видит финансист каждое утро, — примерно так выглядит вкладка «anomalies» после прогона того же примера (цифры условные): Google Sheets — вкладка anomalies 2 аномалии за день 94,7% макс. отклонение Статья План Факт Откл. Статус ФОТ 950 000 1 850 000 +94,7% Реклама 501 000 501 000 0% Проектная услуга 86 000 100 000 +16,3% Инженерная обвязка — без сервера и без отдельной команды разработки. Всё крутится на связке Google Apps Script (триггер по расписанию, ежедневно в 7 утра) плюс Google Sheets как хранилище и Bitrix24 REST API как источник. Ошибки — в отдельную вкладку «errors» с меткой времени и текстом ответа API; при неудачном запросе или таймауте модели скрипт делает до трёх повторов с паузой, а после третьего провала шлёт сообщение в тот же Telegram-бот, что и уведомления об аномалиях, — чтобы сбой конвейера не остался незамеченным неделю. Ограничение Модель не заменяет решение — она снижает объём ручной сверки. Если исходные данные из CRM врут (даты создания лидов сдвигались на 18–36 часов при синхронизации — см. отдельный разбор), модель добросовестно найдёт аномалию там, где её нет, и не найдёт там, где она реально есть. Сначала — чистые исходные данные, потом — автоматизация поверх них. Экономика: что это стоит и что даёт Считайте на своих цифрах, а не на моих. Вопрос, который стоит себе задать: во сколько вам обошёлся последний кассовый разрыв — со всеми срочными займами, испорченными отношениями с поставщиками и вашими нервами? Обычно эта сумма кратно больше, чем стоит нормально поставленный учёт. Формула для своего случая простая: возьмите количество часов, которое сейчас уходит на ручную сверку отчётов в месяц, умножьте на часовую ставку финансиста — это ваши текущие издержки на сведение цифр. После автоматизации той же выгрузки и первичной фильтрации посчитайте, сколько часов останется на реальную проверку уже помеченных аномалий, и умножьте на ту же ставку. Разница между двумя суммами — и есть ежемесячный эффект. Разово: настройка выгрузки из CRM, скрипта и промпта — 6–8 часов работы (силами штатного разработчика или самого финансиста, если он умеет в Apps Script). При ставке ~1 000 ₽/час это 6 000–8 000 ₽ разово (оценка), без внешнего подрядчика. Для сравнения: не всякая автоматизация требует такого объёма — точечный триггер вроде уведомления о закрытии проекта реферала занимает около 20 минут и решает свою узкую задачу без отдельного конвейера. Ежемесячно: обработка сотен строк дешёвой моделью плюс десятки строк дорогой моделью на аномалии — по опыту эксплуатации подобных связок это укладывается в 3 000–5 000 ₽ в месяц на API (оценка, подробный разбор счетов — в статье сколько реально стоит ИИ в месяц ). Экономится время, которое сейчас уходит на ручную сверку. Оценка: сбор трёх отчётов вручную (выгрузка, сведение, поиск расхождений) — около 24 часов в месяц для одного финансиста. Автоматическая выгрузка и первичная фильтрация аномалий забирают у него рутинную часть, оставляя проверку уже помеченных строк — около 10 часов в месяц. 24 ч/мес вручную 10 ч/мес авто На диаграмме — время финансиста на сверку трёх отчётов: 24 часа в месяц вручную против 10 часов, когда выгрузка и первичная фильтрация аномалий автоматизированы. Разница — 14 часов в месяц, то есть около 58% времени, которое раньше уходило на ручную сверку (оценка). При ставке ~1 000 ₽/час это высвобождение на 14 000 ₽/мес в денежном выражении (оценка) — не считая главного эффекта, который так прямолинейно в деньгах не измеряется: аномалия вроде резкого роста ФОТ или лимита фонда, упёршегося в потолок при реальной потребности в разы больше, видна не в конце месяца, а на следующий день после появления в данных. Это снятый риск того же порядка, что дефицит месячного бюджета или долг перед поставщиком из кейсов выше. Оцениваю вклад именно автоматизации сборки отчётов отдельно от прочих мер (пересмотра лимитов, регламента резервов) — это разные инициативы, и смешивать их эффект было бы нечестно. Чек-лист: что сделать в понедельник Выгрузить ДДС по факту оплат (не по датам договоров) за последние 2–3 месяца. Собрать П&У по факту начислений за тот же период, отдельно пометив крупные разовые статьи вроде маркетинговых вложений. Составить список дебиторки с датами возникновения и суммами, отсортировать по сроку просрочки. Прописать резерв отдельной строкой бюджета (например, 30% от прибыли) — и сразу прикинуть, догоняет ли этот темп реальный цикл платежей, а не оставлять цифру «на глаз». Настроить хотя бы одну автоматическую выгрузку данных (CRM → таблица) вместо ручного сведения каждую неделю. Установить порог отклонения (например, 15% от плана) и получать уведомление об аномалии, а не искать её вручную раз в месяц. Стоит обсудить с командой и регламент самих встреч, на которых эти отчёты разбираются — если планёрка не документирует решения и цифры, к следующей неделе половина выводов забудется. Как сделать так, чтобы протокол собирался сам, без отдельного человека с блокнотом, я разбирал в статье про планёрки, которые документируют себя сами . И главное, ради чего всё это. Управленческий учёт — не бухгалтерия и не отчётность для банка. Это ваши глаза: без них вы принимаете решения на ощупь и списываете последствия на рынок, сотрудников или сезон. Читать три своих отчёта — такой же базовый навык руководителя, как считать маржу: вы не делегируете его финдиректору целиком, ровно как не делегируете умение говорить с клиентом. Начните с одного отчёта — ДДС на четыре недели вперёд. Час работы, обычная таблица. Если через неделю вы поймаете хотя бы один платёж, о котором забыли, — считайте, что час окупился. У меня он окупился в первый же раз, и с тех пор я не понимаю, как жил иначе. Если хочется не собирать это по кусочкам, а поставить сразу правильно — с автоматической сборкой и уведомлениями об аномалиях, — механику я разбираю в бесплатном курсе для руководителей : финансовый контур там отдельным блоком, с шаблонами и практикой на ваших цифрах. Начните с одного отчёта на этой неделе — и посмотрите, сколько ваших решений изменится, когда вы увидите деньги на четыре недели вперёд. ## Распознавание первичных документов и своего потока: точность с 59% до 85% без смены модели URL: https://davidgerstein.pro/blog/raspoznavanie-dokumentov-59-85/ Дата: 2026-07-18 Направление: Производственный цикл Цифры: 79 типов · точность 59% → 85% · полтора часа на комплект → минуты Суммы и объёмы в разборе пересчитаны на условную компанию — механика и выводы реальные. Если вы пробовали распознавание первичных документов — счетов, актов, накладных, а следом и собственного потока справок и договоров — и бросили, почти наверняка вы остановились на 59%. Не буквально на этой цифре, но в этом районе: система вроде работает, но перепроверять приходится всё, менеджеры плюются, и через месяц все возвращаются к ручному вводу с чувством «ну я же говорил». Мы стояли ровно там же. Разница только в том, что не бросили — и выяснили вещь, которая переворачивает подход: эти 59% не имеют отношения к качеству модели. Мы подняли точность до 85%, не обучая и не меняя модель вообще. Всё, что дало прирост, — организация вокруг неё. Ниже — что именно делать, по слоям, с честными цифрами и с местом, где ломаются почти все готовые решения. Распознавание первичных документов: почему первый прогон даёт около 59% Речь о рабочем потоке компании — счета, акты, накладные, справки, договоры с приложениями, а не о том, как вытащить текст из одной фотографии. Первый прогон проваливается потому, что модель работает без эталонного набора и без правил разбора спорных случаев. 59% — типовой результат первого прогона, и на нём большинство закрывает тему, решив, что технология не тянет. Ту же связку удалось довести до 85% на 79 типах документов , не меняя модель: собрали эталоны, описали правила для спорных полей, прогнали циклы сверки. Время на комплект упало с полутора часов до минут. Откуда берутся 59% Сначала про цифру, потому что её обычно считают нечестно. Стартовую точность мы считали по ключевым полям — фамилии, имена, даты, номера, то, из-за чего документ вообще обрабатывают. На реальном потоке, сверкой с человеком. Не «доля распознанных документов», а доля полей, которые можно не перепроверять . Разница принципиальная: вендор покажет вам первое, работать вы будете со вторым. И ещё одно, из-за чего цифры вендоров и ваши никогда не сойдутся: они считают на своей тестовой выборке, вы живёте на своём потоке. Пока не прогнали свои документы — любая обещанная точность к вам отношения не имеет. 59% — это типичный результат схемы «модель как есть плюс универсальный промпт». И вот где на самом деле лежат потери: система не знает, что за документ перед ней; не знает, какие поля в нём критичны; и пытается обрабатывать всё одним способом. Три дыры, и ни одна не чинится сменой модели. Хоть флагманскую поставьте. Модель «как есть» + общий промпт 59% После трёх слоёв организации 85% Слой 1: спецификация на каждый тип документа Вместо универсальной инструкции — библиотека: на каждый из 79 типов своя спецификация. Что это за документ, какие поля извлекать, какие из них критичны, какие типичные ловушки — где путается серия с номером, как выглядят старые бланки. Выглядит спецификация буднично — вот сокращённый пример того, что мы пишем на каждый тип: Обратите внимание на последнюю строку. «Пустое поле лучше выдуманного» — правило, которое я бы вешал на стену: без него машина заполнит пропуск правдоподобной ерундой, и вы найдёте её через месяц в договоре. Звучит трудоёмко. Это и есть трудоёмко: неделя работы человека, который знает эти документы. Но именно здесь основной прирост точности, и работа делается один раз, а окупается на каждом документе потока. Если вам не хочется её делать — это честный сигнал, что внедрение вы не потянете: дальше будет не легче. Слой 2: режимы доверия вместо «всё автоматом» Второй слой — признать, что стопроцентная автоматизация не нужна и вредна. Поток делится на три режима, и решение принимается расчётом по фактическим признакам (тип шрифта, согласие двух моделей между собой, число критичных полей), а не на глаз. Режим Что попадает Роль человека Авто Печатный текст, высокое согласие моделей, мало критичных полей Не участвует Авто с проверкой Средние случаи Видит поля рядом с документом и подтверждает Только руками Рукопись, плохой скан, высокая цена ошибки Делает целиком Почему это главное решение Первая же ошибка автоматики на важном документе убивает доверие ко всей системе. Люди начинают перепроверять всё подряд — и эффект обнуляется, при том что деньги за обработку продолжают тратиться. Честное «этот тип мы пока проверяем руками» сохраняет доверие к тем девяноста процентам потока, где автоматика реально работает. Система с режимами доверия живёт. Система «всё автоматом» умирает от первого скандала — и забирает с собой вашу репутацию внутри компании. Слой 3: дорогая модель — только там, где нужна Третий слой — экономика, и здесь директору стоит вмешаться лично. Флагманская модель на каждом документе — это дорого и бессмысленно: на печатном тексте дешёвая даёт то же качество. Дорогая работает на сложных случаях и критичных полях. Это не экономия ради экономии. Разница в счёте между «гоняем всё через флагман» и «маршрутизируем по сложности» — кратная, и она решает, доживёт ли проект до второго квартала. Подробнее про эту арифметику — в разборе реальных расходов на ИИ . Сколько это стоит и когда окупается Считаем на условной компании: поток 400 комплектов в месяц, разбор одного руками — полтора часа, ставка менеджера 700 ₽/час. Это порядка 420 тысяч рублей в месяц управляемой работы (оценка) — при том, что менеджер нанимался не за этим. Стоимость машинной обработки складывается из трёх частей: сами вызовы модели (центы за документ при разумной маршрутизации), недели работы на спецификации — разовые, и время человека на приёмку в режимах «с проверкой» и «руками». Последняя часть не исчезает никогда, и её надо честно закладывать: у нас это порядка четверти прежнего времени. посчитайте свою ручную обработку комплектов документов в месяц часов на один комплект ставка сотрудника, ₽/час ручной разбор ≈ {X} ₽ в месяц формула: комплекты × часы × ставка. Сравнивайте не с нулём, а с четвертью этой суммы — столько останется на приёмку Если ваша цифра в калькуляторе меньше сотни тысяч в месяц — честно скажу: не начинайте, вам это пока не окупится, займитесь чем-то более денежным. Если больше — вы каждый месяц платите эту сумму за работу, которую половина рынка уже не делает руками. Случай, о котором молчат вендоры Теперь то, ради чего стоит дочитать до конца, если вы выбираете готовое решение. В реальном хранилище документы не лежат «один файл — один документ». Справка приходит тремя фотографиями. Договор — сканом по страницам. А иногда в одном PDF лежат два разных документа, потому что менеджер отсканировал стопку не глядя. Требование «склейте всё в один файл» не работает. Так документы физически не приходят, и заставлять клиентов и сотрудников пересобирать файлы — значит убить внедрение об удобство. Нам пришлось учить систему собирать документ из нескольких файлов и резать файл на несколько документов. Если вы выбираете подрядчика или коробку — тестируйте именно на этом. Не на чистом скане паспорта, который вам покажут на демо. Дайте три фотографии одной справки под углом и PDF с двумя документами внутри. Здесь ломаются почти все, и лучше узнать об этом до оплаты, а не после. Чего я не понимал в начале Признаюсь в двух вещах, на которых потерял время. Первое: я месяц искал «модель получше». Сравнивал, читал бенчмарки, гонял тесты. Прирост от смены модели оказался в пределах статистической погрешности — а прирост от описания типов документов дал двадцать шесть процентных пунктов. Я искал не там, где потерял, а там, где светлее. Второе: мы сначала строили «всё автоматом», потому что режимы доверия казались признанием поражения. Это была ошибка ровно наоборот: система без режимов доверия проработала до первой громкой ошибки, после которой ей перестали верить целиком. Пришлось откатываться и вводить их задним числом — вместе с потерянным доверием команды, которое восстанавливается дольше, чем настраивается любая техника. Распознавание первичных документов в 1С: где проходит граница Раз уж речь зашла о выборе, разведу два вопроса, которые постоянно смешивают: распознавание первичных документов и распознавание вашего потока — это не одно и то же, и решаются они разными инструментами. Первичка — счета, акты, накладные, УПД. Структура устойчивая, поля стоят на своих местах, форма предсказуема. Здесь встроенные средства учётной системы справляются, и городить рядом свой контур незачем: цены подписочные, результат сразу в проводке. Ваш собственный поток — всё остальное. Клиентские справки, договоры с приложениями, рукописные формы, сканы под углом. Именно на этом наборе первый прогон и даёт те самые 59% , потому что каждый тип требует своей спецификации, а «одна модель на всё» разваливается. Первый заход на другом наборе — 92 эталонных документа, ошибки с 20% до 7% — описан здесь . Практический вывод: если у вас болит первичка — начинайте с возможностей учётной системы, это дешевле и быстрее. Свой контур нужен там, где документы нестандартные, а объём такой, что ручной ввод стал отдельной работой. У нас именно этот путь и довёл точность до 85% на 79 типах , а время на комплект — с полутора часов до минут. Как выбирать между коробкой, подрядчиком и своими руками Раз уж вы дочитали до сюда, вам скоро придётся принимать это решение. Коротко, как я его вижу. И сразу отвечу на вопрос, который задают чаще всего: «а в 1С же есть распознавание документов, зачем что-то ещё?» Есть, и для бухгалтерии оно работает: 1С и подобные программы отлично забирают счета и накладные в учёт, цены там понятные и подписочные. Но их распознавание заточено под бухгалтерский первичный документ — стандартную форму с предсказуемой структурой. Как только поток становится вашим — клиентские справки, договоры с приложениями, сканы под углом, редкие типы, — оптическое распознавание по шаблону упирается в потолок, и начинается ровно то, о чём эта статья. Готовая коробка хороша, если ваши документы — стандартные и массовые: счета, накладные, паспорта. Дёшево, быстро, но спецификации под ваши редкие типы вы туда не занесёте, и на «трёх фотографиях справки» она, скорее всего, споткнётся. Тест перед покупкой описан выше — не поленитесь. Подрядчик нужен, когда типов много и они ваши. Но требуйте, чтобы спецификации писались вместе с вашим человеком, который эти документы знает, — и чтобы они остались у вас в читаемом виде. Спецификации, а не код, — главный актив этого проекта. Если подрядчик уходит, а описания типов остались у вас, вы восстановите систему за недели. Если наоборот — начнёте с нуля. Своими руками реально, если в компании есть человек, готовый разбираться. Инструменты доступны, вход — десятки долларов, механика описана в разборе про агентов . Именно так это начиналось у нас, и оглядываясь — это был правильный выбор: мы поняли свои документы лучше, чем понял бы любой внешний исполнитель. Что это дало людям До: менеджер разбирает комплект документов клиента полтора часа. Скачивает, переименовывает, раскладывает по разделам, вносит данные в карточку. После: загружает всё одним окном, система определяет типы, раскладывает и извлекает данные, менеджер проверяет результат. Полтора часа превратились в минуты — и я специально не пишу «в ноль», потому что проверка осталась. Но выигрыш даже не в этом. Исчезла зависимость от того, «как привык раскладывать конкретный человек» — а значит, ушёл целый класс проблем: потерянные комплекты, разный порядок папок у разных менеджеров, невозможность быстро передать клиента другому сотруднику. Где остановиться 85% — не потолок и не магия. Это уровень, на котором система стала выгоднее ручного труда с запасом, а дальнейший прирост стоит дороже, чем проверка оставшихся случаев человеком. Практический признак, что пора остановиться: вы неделю бьётесь за пару процентных пунктов, а очередь на приёмке от этого не уменьшается. Значит, оставшиеся случаи по своей природе требуют человека, и правильное решение — не улучшать модель, а нормально организовать проверку. Знать, где остановиться, — управленческий навык, и в распознавании документов он экономит больше денег, чем любая смена модели. Ему нигде не учат, и именно на нём чаще всего сыплются внедрения. Гонка за сотней процентов съедает бюджеты, которые нужно было потратить на второй процесс. О том, где такие проекты ломаются целиком, — разбор ошибок внедрения . С чего начать вам Не с выбора подрядчика и не с изучения рынка программ. С трёх действий, на которые уйдёт неделя и ни рубля. Первое. Посчитайте, сколько времени ваши люди тратят на разбор документов. Не «примерно», а замером: попросите двух менеджеров неделю фиксировать. Цифра вас удивит — она всегда больше ожидаемой. Второе. Выпишите типы документов, которые к вам приходят. Не все 79 — топ-10 по частоте. Это и будет черновик первых спецификаций. Третье. Возьмите десять реальных комплектов — грязных, с фотографиями и перевёрнутыми сканами — и прогоните через любой доступный инструмент. Получите свои 59% и увидите, где именно теряется точность. Это ваша стартовая точка, и она всегда честнее презентации вендора. Дальше — три слоя из этой статьи. А если хотите пройти путь по порядку, с практикой на своих документах, — у меня есть бесплатный курс для руководителей : работа с документами там разобрана отдельно, вместе с экономикой и режимами доверия. И последнее. Разница между компаниями, у которых это работает, и теми, у кого «не пошло», — почти никогда не в бюджете и не в подрядчике. Она в том, нашёлся ли человек, готовый неделю описывать типы документов вместо того, чтобы ждать волшебную коробку. Волшебных коробок не будет ни в этом году, ни в следующем — будут инструменты, которые окупаются в руках того, кто разобрался. ## Внутреннее обучение сотрудников без наставника: курс, аттестация и автоматизация URL: https://davidgerstein.pro/blog/vnutrennee-obuchenie-sotrudnikov/ Дата: 2026-07-17 Направление: Люди Цифры: 5 дней курса · несколько десятков расшифровок звонков за неделю · кризис на 3-м месяце Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Обучение в большинстве компаний выглядит так: опытный сотрудник пересказывает новичку то, что помнит. Через месяц новичок пересказывает это следующему — с потерями. Если вы не можете за минуту сказать, кто и по какому материалу учил вашего последнего новичка, — у вас нет обучения. У вас есть надежда, что опытный сотрудник найдёт время и вспомнит нужное. Стоит эта надежда дороже, чем кажется: платит за неё тот, кто в это время не продаёт. Разбираю, как превратить пересказы в курс, которым действительно пользуются, без учебного центра и бюджета. Так раньше выглядело внутреннее обучение сотрудников в отделе продаж: опытный менеджер тратил несколько дней на то, чтобы обучить новичка вживую — по видеозвонку, пересказывая одно и то же в десятый раз. Всё это время он не занимался клиентами. Если считать грубо: три дня по три-четыре часа в день на одного новичка — это 9–12 часов работы, вычтенных из продаж наставника (оценка). При двух новых менеджерах в месяц — обычный темп найма для отдела из 8 человек — это около 20 часов наставника ежемесячно, компания оплатила их дважды: за обучение и за упущенную выручку того, кто учил. Компания заменила это пятидневным онлайн-курсом с личным кабинетом для каждого новичка — внутреннее обучение перестало держаться на щедрости одного человека, который согласен отвлекаться от продаж ради обучения соседа. Ниже — как это устроено по шагам, с каким промптом работает автоматизация вокруг обучения, что это стоит и где ломается, если сделать поверхностно. Внутреннее обучение сотрудников: что это и с чего начать Если вы не можете за минуту назвать материал, по которому учился ваш последний новичок, — внутреннего обучения у вас нет, есть надежда на щедрость опытного коллеги. Внутреннее обучение сотрудников — это когда знание компании записано один раз и передаётся всем одинаково, а не пересказывается из головы в голову с потерями на каждом звене. Рабочий минимум состоит из трёх частей: пятидневный онлайн-курс с тестом в конце каждого дня и личным кабинетом новичка; персональная папка документов вместо разрозненных ссылок; аттестация не по одному входному тесту, а по профилю сотрудника, собранному из расшифровок его звонков. Наставник при этом не исчезает — он включается на разборе кейсов, а не тратит 9–12 часов на десятый пересказ одного и того же (оценка). Что не так с пересказом от коллеги к коллеге Ваша проблема здесь не в качестве пересказа, а в потерях: каждая передача теряет часть смысла, и через три звена новичок работает не так, как вы задумывали. У формата «сядь рядом с опытным и слушай» есть три системных проблемы, и все они бьют по деньгам. Первая — время того, кто учит. Опытный сотрудник — это тот, кто и так закрывает план. Каждый час, потраченный на объяснение новичку, вычитается из его продаж напрямую. Вторая — качество передачи. Каждый рассказывает по-своему, расставляет свои акценты, что-то забывает. Один новичок узнаёт про скрипты, другой — только про клиентский путь, потому что наставнику в тот день было некогда рассказать остальное. Третья, и самая дорогая — новичок не верит в ценность продукта, потому что никто толком не объяснил, за что клиент платит. Конкретный случай: новый менеджер получает клиента, не понимая реальной ценности услуги. Клиент спрашивает «за что я платил» — и менеджер не может ответить убедительно, потому что сам не понимает. Это заканчивается конфликтами и расторжением договоров, иногда при первом же контакте. Здесь ошибаются все, и я дольше многих. Я не понимал, почему новички после одного и того же «обучения» отвечают клиенту по-разному, и списывал это на характер. Потом сел и сравнил, что именно каждому из них успели рассказать. Разница была не в людях. Ни один наставник не был обязан рассказать всё — просто потому, что нигде не записано, что такое «всё». Моя недоработка: я требовал от обучения результата, а самого обучения в письменном виде не существовало. Где ломается Обучение через устный пересказ работает только до тех пор, пока в компании один-два новых сотрудника в квартал. При росте найма формат ломается — наставники выгорают, новички получают разный уровень подготовки, а руководитель узнаёт о пробелах только когда клиент уже расторг договор. Как устроить внутреннее обучение сотрудников без наставника-героя Ваша цель — чтобы знание жило в компании, а не в конкретном человеке, который может уволиться. Компания разработала пятидневный онлайн-курс для новых сотрудников отдела продаж. Структура простая и последовательная: День Содержание 1 Информация о компании и партнёрах 2 Клиентский путь и точки касания 3 Типы клиентов, коммуникация 4 Услуги компании, скрипты 5 Реальные кейсы, итоговый тест Каждый день заканчивается тестом. Тесты вынесены на отдельный экран — специально, чтобы исключить возможность подсмотреть ответы во время прохождения материала. Мелочь, но именно она отличает контроль знаний от формальности «прочитал, поставил галочку». Курс размещён на корпоративном портале, у каждого менеджера — свой личный кабинет. Прогресс отслеживает Telegram-бот: не руководитель каждый день заходит проверять, кто где застрял, а бот сам показывает, кто прошёл, а кто завис на третьем дне уже неделю. Документы не теряются — их скачивают по ходу курса С документами разобрались похожим образом. Раньше стандартные файлы и шаблоны рассылались списком, и часть из них терялась или игнорировалась. Теперь обучающийся скачивает нужный документ на каждом этапе курса — к концу обучения у него формируется персональная папка со всеми материалами для работы. Документы актуальны на момент прохождения курса, а не на момент, когда их последний раз обновляли. Курс планируется расширять: шаблоны документов с конкретными примерами заполнения, видеоинструкции по оформлению документов, расширенный раздел по скриптам, чек-лист в конце обучения для напоминания в работе и видеозадания — короткие ролики, которые новичок записывает сам по определённым стадиям работы с клиентом. Это уже не просто курс, а тренажёр с обратной связью. Насколько меняется нагрузка на наставника — на диаграмме ниже часы на одного новичка до и после курса, грубая прикидка на потоке из нескольких новичков в месяц: 12ч наставник 1,5ч курс+бот Часы на одного новичка при потоке в несколько новичков в месяц — живое обучение наставником против курса с разбором кейсов ботом-трекером (обе цифры — оценка). Как построить систему, которая не требует постоянного ручного контроля от руководителя, — в статье про онбординг как систему, а не наставника-энтузиаста . ИИ-связка: как обучение соединяется с автоматизацией найма Внутреннее обучение — это не только курс о продукте. Есть и другой пласт: обучение работе с новыми инструментами, включая автоматизацию собственной рутины сотрудника. Разберём конкретный конвейер: он не про продажи, а про найм, но логика обучения та же — сначала человек учится проверять машину, потом снижает частоту проверок. Менеджер по найму ежедневно вручную фильтровал резюме и отслеживал отклики на портале вакансий. Решение — не дать готовый инструмент сразу, а сначала обучить менеджера работе с API и таблицей, потом пошагово нарастить автоматизацию: Подробный разбор — скрининг резюме нейросетью . Таблица мониторинга вакансий — метрики: просмотры, клики, отказы Подключение по API-ключам — доступ к базе портала Агент опроса портала — раз в день тянет новые отклики Скоринг резюме — оценка по критериям вакансии На старте все решения по кандидатам остаются ручными — менеджер проверяет каждую оценку агента и даёт обратную связь. Это и есть обучение: не «доверяй машине сразу», а «проверяй, пока не набралась статистика ошибок». Промпт для скоринга резюме — Google Sheets + Apps Script Таблица мониторинга живёт в Google Sheets. Агент на Google Apps Script раз в день дёргает API портала, дописывает новые строки в лист «Отклики» и для каждой строки вызывает дешёвую модель (GPT-4o-mini или аналог) — задача массовая и шаблонная, платить за дорогую модель на потоке в десятки резюме в день смысла нет. Например, при потоке в несколько десятков резюме в день дешёвая модель обходится в районе одного-двух долларов в сутки (оценка на типовых расценках токенов) — заметно дешевле часа работы менеджера, который раньше тратился на ручной просмотр того же объёма откликов. Пример ответа модели на реальном резюме из потока: Поле flag_review — это и есть та самая ручная проверка на старте: менеджер в первую очередь смотрит кандидатов с флагом, а не доверяет итоговому баллу вслепую. Инженерная обвязка Всё крутится в связке Google Sheets + Apps Script триггер (time-driven, раз в сутки) + API портала + Telegram Bot API. Апскрипт пишет в два листа: «Отчётность по вакансиям» (дата, просмотры, клики, отказы, процент релевантных резюме) и «Реестр откликов» (кандидат, критерии, итоговый балл). Перезапуск — вручную из меню таблицы, кнопка «Обновить сейчас», плюс лист «Errors» с временными метками сбоев API. Обнаружилась рассинхронизация: по данным портала было заметно больше откликов, чем зафиксировано в таблице системы. Решили две вещи. Первое — показатель времени последнего успешного обновления в самой таблице, чтобы визуально видеть, когда данные устарели. Второе — Telegram-бот с push-уведомлениями: раз в час короткая сводка новых откликов и отдельное уведомление, когда появляется кандидат с высокой оценкой. Прямо из чата бота можно открыть резюме, перейти на портал, пригласить на собеседование или отклонить. Срок внедрения этой доработки — 2 дня. Так теперь выглядит фрагмент этой таблицы — с меткой времени обновления и флагом на кандидата, которого нужно проверить вручную: Google Sheets — Реестр откликов неск. десятков откликов по данным портала 09:14 время последнего обновления Кандидат Балл Статус R-1042 7/10 на проверку R-1039 9/10 ок Показательная фраза из этого же проекта: «Пока ты не понимаешь, что можешь доверять системе, и смотришь и там, и там, это для тебя не рабочий инструмент, это просто ещё одна табличка, куда надо смотреть». Обучение без стадии проверки превращается в имитацию автоматизации — два источника правды вместо одного, и менеджер тратит время на оба. Ещё один кейс — зависимость команды от одного человека. Руководитель IT-отдела столкнулся с тем, что компания держится на единственном специалисте: если он в отпуске, встают все проекты. Решение — за два-три месяца обучить остальных гибридным инструментам разработки, не чистому коду, а профессиональным низкокодовым платформам, чтобы задачи можно было передавать при перегрузке или отсутствии основного исполнителя. Это тоже внутреннее обучение, только его цель — не адаптация новичка, а снижение риска на ключевую роль. О том, что бывает, когда автоматизация внедрена, но никто не научен ей пользоваться и она требует постоянного ручного надзора, — в статье почему внедрение ИИ не работает, хотя технически всё запустилось . Аттестация: тест — не единственный инструмент Проверяйте не память, а действие: пусть ваш сотрудник сделает реальную задачу, а не ответит на двадцать вопросов. Курс с тестами показывает, что сотрудник прочитал материал. Он не показывает, применяет ли сотрудник знания в работе. Для этого нужна аттестация, построенная на других данных — на реальных звонках, а не на опроснике. Промпт для профиля сотрудника по расшифровкам звонков Здесь модель работает не с потоком в десятки резюме в день, а с несколькими десятками расшифровок в неделю — задача тоньше, нужен анализ формулировок и эмоционального фона, а не бинарная классификация. Здесь оправдана более дорогая модель уровня GPT-4o или Claude Sonnet. Пример ответа модели: Именно так и вскрылась реальная проблема одной сотрудницы: она мерила свой успех процессом («сделано ли правильно»), а не результатом для клиента. Тест по скриптам этого никогда бы не показал — она отлично прошла бы любой опросник. Задача, которую поставили дальше, — собрать несколько десятков таких расшифровок за неделю, зафиксировав клиентские слова о страхах и проблемах, и уже на этом материале разбирать формулировки, а не факт звонка. Второй слой аттестации — анонимная обратная связь от коллег, метрика в компании называется ЕМПС. На её основе рассчитываются бонусы. Это защищает от субъективных претензий руководителя и показывает сотруднику, на какие конкретные критерии влияет размер доплаты — не «начальник так решил», а измеримый показатель. Третий слой — профиль сотрудника целиком: сильные и слабые стороны, специализация по клиентам, успехи и неудачи. Такие профили запрашивались у руководителей направлений именно для того, чтобы точнее распределять задачи и обучение, а не назначать людей на роли наугад, когда человек занимается не своим делом и не может передать навык коллегам. Кризис на третьем месяце — тоже часть системы обучения Есть закономерность, которую полезно закладывать в программу адаптации заранее: «первый кризис менеджера всегда случается на третий месяц. Потом либо на шестой, либо на девятый. Это математика, это физика, это закон жизни». Курс и тесты закрывают знания на старте, но не защищают от выгорания через три месяца после выхода на самостоятельную работу. Управленческое решение здесь — не игнорировать спад, а организовать «контролируемое падение»: выровнять сотрудника на плато вместо раскачивания маятника, вплоть до планового отпуска на пике нагрузки, чтобы не допустить окончательного срыва. Правило Курс закрывает знание продукта и процессов. Он не закрывает применение этих знаний в реальной работе и не защищает от кризиса адаптации на третий месяц. Нужен второй слой контроля — по звонкам, обратной связи коллег или прогрессу в системе, — иначе тест становится формальностью, а не аттестацией. Похожий принцип объективной оценки без ручного прослушивания — в статье про контроль качества звонков без ОКК : там тоже речь о том, как заменить субъективное впечатление руководителя измеримыми данными. Экономика: что это стоит и что даёт вам Считайте от срока выхода на результат: на сколько дней быстрее ваш новичок начнёт приносить деньги. Разделим два эффекта — их нельзя смешивать, они дают разные деньги на разных участках. Эффект курса вместо наставника. Формула для собственного расчёта: (часы наставника на одного новичка при живом обучении − часы на курс и разбор кейсов) × ставка часа наставника × число новичков в месяц = высвобожденная стоимость в месяц. Подставим цифры для отдела из 8 менеджеров: наставник тратил 9–12 часов на одного новичка при живом обучении, курс с ботом-трекером снижает эту нагрузку до 1–2 часов на разбор реальных кейсов — экономия 7–11 часов на новичка, то есть снижение нагрузки на наставника примерно на 85–90%. При двух новичках в месяц это около 21 часа наставника — почти три рабочих дня, которые высвобождаются для его собственных клиентов вместо пересказа материала. При ставке около 1 000 ₽/час (оценка) это порядка 18 000–21 000 ₽ в месяц отвоёванной выручки наставника. Это не прямая экономия бюджета, а высвобожденная мощность продавца. Показатель Наставничество (было) Курс + бот (стало) Эффект Часы на 1 новичка 9–12 ч 1–2 ч −7–11 ч Часы в месяц (2 новичка) ~21 ч ~3 ч −18 ч Снижение нагрузки на наставника 100% (весь объём вручную) ~10–15% от прежнего экономия ~85–90% Эффект от понимания ценности продукта. Дальше считаем риск расторжений из-за «за что я платил». Формула: число новых менеджеров в месяц × клиентов на менеджера в первый месяц × доля потерянных из-за непонятой ценности × средний чек = риск расторжений в месяц. Пример для отдела из 8 менеджеров со средним чеком 180 000 ₽: при найме двух новичков в месяц каждый в первый месяц ведёт около десяти клиентов — 20 клиентов на двоих. Если каждый пятый из них уходит после первого разговора из-за непонятой ценности, это 4 расторжения в месяц и около 720 000 ₽ риска (оценка) — примерно 8% месячного оборота компании (9 млн ₽), заметная утечка, а не мелочь на общем фоне. Курс с блоком «клиентский путь и ценность услуги» не гарантирует ноль расторжений, но снимает главную причину — менеджер, который сам не понимает продукт. Что не считаем эффектом. Экономия часов наставника — это поток: она повторяется каждый месяц, пока идёт найм, и её можно сразу переводить в деньги через ставку. Риск расторжений — это предотвращённая потеря, а не гарантированный ежемесячный доход: она не суммируется с часами наставника, а считается отдельной строкой, потому что зависит от того, сколько новичков реально усвоили ценность продукта после курса, а не только прошли тест. Стоимость внедрения. Разовая разработка курса — контент, тесты, структура личных кабинетов — это часы методиста и руководителя направления, ориентировочно 40–60 часов на пятидневную программу, то есть примерно одна-полторы рабочие недели одного специалиста при полной занятости. Эксплуатация — хостинг портала и Telegram-бот-трекер, минимальные регулярные расходы, сопоставимые со стоимостью пары часов работы методиста в месяц, без учёта уже существующей CRM-инфраструктуры. Чек-лист: с чего начать в понедельник Выбрать одну роль с самым частым потоком новичков — там наставничество съедает больше всего часов. Разбить материал на 5 дней по структуре: компания и партнёры → клиентский путь → типы клиентов → продукт и скрипты → кейсы и тест. Тест — на отдельном экране, не рядом с материалом, иначе это профанация контроля. Настроить один документ-трекер прогресса (таблица или бот) — без него курс превращается в файл, который никто не проверяет. Для автоматизации рутины — выбрать один процесс (например, фильтрацию резюме), обучить ответственного работе с API и таблицей, прежде чем строить конвейер. Добавить второй слой аттестации — хотя бы несколько десятков расшифровок звонков в месяц на анализ формулировок, а не только тест по знаниям. Курс с документами, тестами и ботом-трекером снимает обучение с плеч одного наставника. Аттестация поверх него показывает, что знания не просто прочитаны, а работают в звонках. Слабое место остаётся общим для обоих слоёв: если пропустить стадию ручной проверки — что в курсе, что в скоринге резюме, что в анализе звонков — вся автоматизация превращается в ещё одну табличку, куда всё равно приходится смотреть глазами, а не в систему, которой доверяют. И назову вещь, которую обычно не называют вслух. Умение разложить свою работу на шаги и оставить их материалом, которым воспользуется другой человек, — это отдельный управленческий навык, такой же рабочий, как умение считать маржу. Руководитель, чья команда учится без него, стоит дороже руководителя, который умеет только показывать лично: первый растёт вместе с наймом, второй упирается в собственный календарь. Навык осваивается, но сам не появляется. Начните с одного: запишите на видео, как ваш лучший сотрудник делает самую частую операцию. Двадцать минут — и у вас есть первый учебный материал, который точнее любого пересказа. Как собрать из таких кусков систему обучения — в бесплатном курсе . Проверьте своё обучение одним способом: спросите сотрудника, который вышел месяц назад, где он ищет ответы на рабочие вопросы. Если ответ «спрашиваю коллег» — ваша система обучения существует только на бумаге, а знания живут в головах и уходят вместе с людьми. С чего начать вам Возьмите вашу самую частую операцию — ту, которую новичок делает в первую неделю. Попросите вашего лучшего сотрудника записать её на видео или расписать по шагам. Двадцать минут его времени — и у вас появился первый материал, который не зависит от чьей-то памяти. Дальше добавляйте по одному материалу в неделю. Через квартал у вас будет ядро курса, собранное из ваших реальных процессов, а не из общих слов про клиентоориентированность. Мой опыт Мы потеряли на этом полгода: я был уверен, что обучение — задача HR, и ждал от них курс. Курса не было, потому что HR не знает содержания работы, а те, кто знает, были заняты работой. Сдвинулось, когда я перестал ждать и завёл правило: каждый разбор реальной ситуации записывается и попадает в общую папку. Через два месяца из этих записей собрался нормальный вводный курс — без единого специального часа на его создание. Мой личный итог: я перестал ждать, когда у нас появится «нормальное обучение», и начал собирать его из того, что мы и так делаем. Оказалось, что материала у нас было достаточно — не хватало только привычки его сохранять. ## Контроль заявок на стыке отделов: где конверсия падает с 55% до 22% URL: https://davidgerstein.pro/blog/poteryannye-zayavki/ Дата: 2026-07-15 Направление: Продажи Цифры: разрыв конверсии встреча→договор 55%→22% · шестизначная сумма в евро с реанимации 7-летней базы лидов · 1,5 года без движения по одной сделке Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Самая обидная потеря в бизнесе — не проигранный конкурс и не ушедший к конкуренту клиент. Это заявка, на которую просто никто не ответил. Проверьте себя сразу, до всякой теории. Если вы не можете за минуту назвать, сколько заявок за прошлую неделю остались без единого касания и кто по каждой отвечает поимённо, — у вас эти заявки есть. Не «может быть, есть», а есть. Вы их просто не видите: в отчёте они лежат в одной куче с живыми. Вы за неё заплатили: реклама, сайт, работа маркетолога. Человек поднял руку и сказал «мне интересно». А дальше цепочка порвалась — и вы об этом даже не узнали, потому что в отчёте эта заявка есть, а в продажах её нет. В CRM одной компании нашёлся клиент без единого движения полтора года. Не отказ с причиной, не пауза по документам — просто карточка, которая зависла и годами тихо портила статистику отдела. Руководитель наткнулся на неё случайно, когда разбирал воронку по срокам жизни сделок. Это и есть потерянная заявка в продажах в чистом виде: она не удалена, не закрыта, у неё просто нет хозяина. Я третий год ставлю ИИ и системы отчётности в отделы продаж среднего бизнеса и вижу одну и ту же картину раз за разом. Заявки почти никогда не теряются в момент создания — лид попал в CRM, кто-то ему позвонил. Они теряются на стыках: когда лид переходит от маркетинга к продажам, от одного менеджера к другому, когда сделка меняет статус в воронке. В эти секунды никто конкретно не отвечает за клиента — и он проваливается в щель между процессами. По одной компании на неделе, где я разбирал воронку, факт не дотянул до плана продаж на пятую часть — как раз из-за таких проваленных передач, а не из-за того, что менеджеры вдруг разучились продавать. Где рвётся контроль заявок и как это проверить за пятнадцать минут Четыре типовых разрыва: заявка попадает в общий пул без ответственного, ответ приходит позже суток, статус меняется вручную и по памяти, повторные обращения не связываются с исходным. Работают обычно минимум два. Проверка занимает пятнадцать минут: возьмите заявки за неделю и найдите те, где нет ни одного касания клиента. Каждая такая строка — оплаченный рекламой и выброшенный шанс. Где именно рвётся ваша цепочка Четыре типовых разрыва. Пройдите по ним и отметьте, какие есть у вас, — обычно работают минимум два. Три точки разрыва встречаются в разных отделах продаж почти одинаково. Первая — смена статуса без владельца. Сделка перешла с этапа переговоров на этап «ожидание документов», и в этот момент менеджер решил, что мяч на стороне клиента. Клиент решил ровно то же самое про менеджера. Оба ждут. Через полтора года получаем зависшую карточку, которую случайно находят при аудите воронки. Вторая — увольнение или ротация менеджера. В одной из компаний, где я работал, ключевой менеджер ушёл, и стало неясно, кто обслуживает его клиентов. Несколько из них общались только с ним лично — без параллельного контакта, без дублирующей записи в CRM о договорённостях, что перекликается с типичной проблемой, когда менеджеры не вносят данные в CRM вовремя. Один клиент был привлечён буквально накануне увольнения, с ним ещё никто не успел даже созвониться повторно. Передачи не было — было исчезновение. Третья — межотдельная передача лидов , тот самый разрыв между маркетингом и продажами , где лиды есть, а сделок нет. Маркетинг сдал лид в продажи, продажи — в операционный отдел на исполнение. На каждом шаге теряется контекст: чего хотел клиент, что ему обещали, в какое время удобно звонить. В одной компании менеджеры передавали клиента операционному отделу устно или короткой строкой в задаче. Отдел начинал звонить наугад, клиенты не брали трубку — просто потому что не понимали, кто и зачем им звонит. Позже формат передачи изменили: менеджер стал давать детальный портрет клиента и его ожидания, операционный отдел получил доступ к календарю менеджера и назначал звонок на согласованное время. Клиенты стали отвечать заметно охотнее — но это отдельное решение, не автоматизация, и его эффект я здесь не смешиваю с ИИ-инструментами ниже. Правило Если у заявки в момент передачи нет конкретного человека с именем и сроком реакции — она не передана, она потеряна. «Отдел разберётся» ответственностью не считается, это способ спрятать разрыв до следующего аудита воронки. Заявки без ответственного: что покажут ваши цифры Возьмите свою выгрузку за неделю и посмотрите три вещи: сколько заявок без ответственного, сколько без единого касания и сколько получили ответ позже суток. Три числа, которые дадут вам полную картину. Проверьте прямо сейчас, не откладывая: сколько заявок за прошлую неделю не имеют ответственного или не получили ни одного касания. Эта цифра обычно отрезвляет сильнее любой статьи. Недельная динамика одного отдела продаж хорошо показывает, как выглядит разрыв в цифрах, а не в ощущениях. Факт продаж за неделю — 80% от плана. Закрыто 7 сделок из 16 запланированных. Конверсия в продажу — 14% при плане 23%. При этом конверсия во встречу держалась на уровне 55% — 49 встреч фактически состоялось, то есть люди доходили до разговора, и до этого момента процесс работал нормально. Показатель План Факт Сумма продаж за неделю 100% 80% от плана Закрытых сделок 16 7 Конверсия в продажу 23% 14% Средний чек (отклонение от базового) 10% 13,5% Конверсия во встречу — 55% (49 встреч) Конверсия встреча → договор — 22% Разрыв между 55% и 22% — это ровно то место, где заявка формально ещё жива (встреча состоялась), но реально уже потеряна. Клиент дошёл до разговора и не дошёл до договора, а в большинстве отчётов, которые я видел до внедрения детализации, воронка вообще не разбивается на такие подэтапы — есть только «было» и «не было». На диаграмме — обе конверсии рядом: видно, где именно происходит основной провал. Лид → встреча 55% Встреча → договор 22% Конверсия в продажу, план 23% Конверсия в продажу, факт 14% Похожая история про май того же отдела: команда отвлеклась на апсейл действующей базе (на кону было направление с потенциалом около 500 000 ₽ в месяц) и перестала системно звонить новым контактам. План на месяц — 60+ звонков, сделали 15. При этом повторное касание по 19 тёплым лидам, оставшимся с апреля, дало 4 рекомендации. Ресурс, который просто лежал без внимания, оказался продуктивнее нового потока — потому что до него наконец дошли руки. Это тоже потерянная заявка, только растянутая на месяц: не пропала, а простояла без движения ровно до момента, пока кто-то не вспомнил о её существовании. Механика по шагам: как найти и закрыть ваш разрыв Пройдите этот путь на своих данных: сначала находите, где рвётся, потом ставите ответственного, потом закрываете техникой. В обратном порядке не работает — автоматизация поверх бардака делает бардак быстрее. Порядок для вас — от простого к сложному. Первый шаг даст результат в тот же день, остальные потребуют недели. Порядок, который реально работает — без сложной автоматизации на старте. Шаг 1. Откуда данные. Выгружаете из CRM (Bitrix24, amoCRM или любая другая) все сделки с датой последнего изменения статуса, датой создания, текущим этапом и ответственным менеджером. Это стандартный экспорт, доступен в любой системе без доработок. Здесь важна оговорка: дата в поле CRM не всегда равна дате реального последнего касания — иногда система показывает дату технического сдвига, а не звонка. Прежде чем строить на этих данных отчёт, стоит свериться с логами звонков хотя бы выборочно, я подробно разбирал этот случай отдельно, когда Bitrix24 сдвигал даты сам . Шаг 2. Что считать разрывом. Для каждого этапа воронки задаёте нормативный срок — сколько дней сделка может провести на этом статусе, прежде чем это станет проблемой. Норматив берётся не из головы, а из истории: смотрите медианное время на этапе у сделок, которые в итоге дошли до продажи, и берёте его как ориентир с запасом. Шаг 3. Кто и что делает с превышением. Сделки, превысившие норматив, помечаются как зависшие. Дальше — развилка: часть из них реально мёртвая (клиент год не отвечает, есть смысл вынести в отдельную воронку реактивации, чтобы не портить статистику активных сделок), часть — живая, но без ответственного (тут нужен именно контакт, а не архивация). Именно так поступили с клиентом, зависшим на полтора года: его не удалили и не форсировали звонком «на всякий случай», а перенесли в отдельную воронку, чтобы он перестал искажать конверсию остальных сделок. Шаг 4. Куда попадает результат. Не в отдельный файл, который никто не открывает, а в дашборд, доступный руководителю отдела и самим менеджерам, с прямым переходом в карточку сделки — чтобы разбор занимал секунды, а не поиск по CRM. Рабочий вариант такого отчёта: по каждому менеджеру клиент, статус, дата создания сделки, количество дней в текущем статусе и светофор — зелёный, жёлтый, красный — по нормативному сроку стадии. Обновление раз в час достаточно для отдела продаж, ежесекундная точность тут не нужна. Шаг 5. Кто и когда смотрит. Руководитель отдела — ежедневно, по красным меткам. Собственник или коммерческий директор — раз в неделю, по агрегированной динамике: растёт ли доля зависших сделок или падает. ИИ-связка: реактивация ваших зависших сделок Если разрыв у вас на входе, а не в старой базе, начните с другого конца: как устроена автоматизация обработки заявок — от письма до задачи с ответственным. Прежде чем покупать новые лиды, посмотрите на старые: у вас в базе почти наверняка лежат сотни контактов, до которых не дошли руки. Ваши старые заявки — это не мусор, а оплаченная база, до которой не дошли руки. Машина разбирает её и приносит вам список тех, кому есть смысл написать сегодня. Ручной разбор зависших сделок работает, пока их немного. Когда база вырастает до сотен клиентов на паузе, нужна первая линия автоматической сортировки — не для того, чтобы заменить менеджера, а чтобы не звонить всем подряд одинаковым текстом. Конвейер выглядит так: CRM (amoCRM или Bitrix24) → вебхук при переходе сделки в статус «пауза» дольше нормативного срока → запрос к модели с историей переписки и звонков → результат (причина паузы, тон, черновик сообщения) пишется в кастомное поле сделки и создаёт задачу менеджеру на согласование → менеджер утверждает или правит текст → отправка. Автоматика не отправляет сообщение сама — она готовит черновик, решение остаётся за человеком. Это осознанное ограничение: компания, с которой я работал, сначала тестировала реактивацию именно на «паузниках» — клиентах, которые и так не двигались, — чтобы не рисковать активной базой, если модель ошибётся с тоном. Модель здесь — дешёвая (уровня gpt-4o-mini или аналогичной по цене): задача классификационная и генерирует короткий текст, ей не нужна глубокая аналитика или длинный контекст. Дорогую модель имеет смысл подключать только на этапе разбора сложных возражений в живом диалоге, а не на массовой сортировке базы. Пример ответа модели: Второй, более простой сценарий — для компаний, у которых пока нет ресурсов на вебхуки в CRM. Выгрузка зависших сделок в Google Sheets, скрипт на Apps Script раз в сутки отправляет строки в модель для быстрой сегментации: «мёртвая» или «живая без ответственного». Пример ответа модели: Инженерная обвязка здесь простая, но обязательная: лимит на количество запросов в минуту (чтобы не упереться в rate limit при массовой выгрузке в сотни строк), лог каждого ответа модели с deal_id — иначе при сбое непонятно, какие сделки уже обработаны, и fallback-правило «если API недоступен или confidence ниже 0,4 — сделка уходит в очередь на ручной разбор, а не отправляется автоматом». Без этого правила один сбойный ответ модели может улететь клиенту как есть. Скрытые критерии убивают доверие к системе Если вы одновременно вводите скоринг звонков или сортировку сделок и не объясняете менеджерам, по каким именно критериям их теперь оценивают, — получаете не улучшение процесса, а сопротивление. В одной компании система оценивала вторичные звонки по требованиям, о которых сами менеджеры не знали: они продолжали звонить «как звонили всегда», а отчёт показывал провал. Правильный порядок обратный: сначала показать менеджерам, как оценки модели соотносятся с реальными звонками, добиться согласия, что критерии справедливы, и только потом вводить их как норму. Здесь я обязан сказать про себя, а не про абстрактную компанию. Тот случай со скрытыми критериями — моя ошибка. Систему ставил я, критерии держал в голове я, а до менеджеров их не донёс: решил, что цифры в отчёте объяснят себя сами. Не объяснили — получил месяц глухого сопротивления и отчёт, которому в отделе никто не верил. Так что если ваша первая попытка навести порядок в заявках упрётся в «да мы и так всё делаем» — это нормальный этап, я сам через него прошёл. Это не признак того, что команда плохая. Экономика: цена одного процента конверсии Посчитайте на своих цифрах — умножьте свой средний чек на количество заявок за месяц и на один процент. Обычно получается сумма, ради которой стоит потратить неделю на наведение порядка. Отдельно стоит разобрать шестизначную сумму в евро, которая обычно всплывает как аргумент «просто дожмите старую базу». В одной компании подняли базу лидов, которые отказали менеджерам семь лет назад — по трём причинам: не готовы платить, не готовы разговаривать, заявку в итоге не оставили. В марте те же контакты вернулись и купили на шестизначную сумму в евро. Важная деталь: все они когда-то реально брали трубку и общались — просто тогда с ними работали менеджеры низкой квалификации, и заявка терялась не из-за плохого лида, а из-за плохой обработки. Это чистый результат ручной реактивации: обзвон, повторный контакт, живой разговор. Автоматический ИИ-инструмент, о котором шла речь выше, на момент этой реактивации ещё не применялся — компания только готовит его, чтобы повторить эффект без ручного перебора каждой карточки. Вклад ИИ в этот результат — нулевой, и приписывать ему чужой результат было бы нечестно. Его роль — не заменить то, что сделали руками, а масштабировать сортировку, когда база вырастет с десятков до сотен карточек и руками её уже не разобрать. Чтобы прикинуть свой риск, а не чужой, считайте по формуле: количество сделок в активной воронке × доля зависших дольше норматива × консервативная доля тех, что без вмешательства так и не закроются × средний чек. Все три доли — это оценка, а не факт, поэтому берите её с запасом в свою пользу, а не в пользу красивой цифры. Параметр Значение Менеджеров в отделе 6 Сделок в активной воронке на менеджера (оценка) ~15 Всего сделок в работе 90 Доля зависших дольше норматива 10% Зависших сделок 9 Доля теряемых без вмешательства (консервативная оценка) 50% Теряемых сделок (округлено, оценка) ≈4 Средний чек 250 000 ₽ Риск в месяц (оценка) ≈ 1 000 000 ₽ То есть отдел из 6 менеджеров при обороте около 6 млн ₽ в месяц и всего 10% зависших сделок рискует терять около 1 млн ₽ выручки в месяц просто потому, что часть заявок никто не подхватил вовремя (оценка, не факт — но повод посчитать свою воронку по той же схеме, прежде чем списывать провал плана на «слабый месяц»). Второй слой затрат — не выручка, а время руководителя на ручной разбор. Если РОП тратит на каждую зависшую сделку в среднем 15 минут — найти карточку, вспомнить историю, решить, что делать — 9 сделок в неделю дают около 2,25 часа, то есть порядка 9 часов в месяц. При ставке руководителя примерно 1 500 ₽/час это около 13 500 ₽ в месяц только на ручную разборку (оценка) — статья расходов, которая исчезает, если дашборд с датой последнего касания и цветовой меткой уже показывает, где смотреть, а не заставляет искать вручную. Что делать вам в первую очередь Порядок действий на вашу неделю — каждый пункт можно закрыть за один подход, и первые два не требуют ни техники, ни бюджета. Если внедрять всё сразу — не начнёте ничего. Порядок действий на ближайшую неделю такой: Выгрузить из CRM все сделки без движения дольше нормативного срока по своей же стадии — это делается за один экспорт, без интеграций. Разделить список на две группы: «мёртвые» (нет ответа больше 2-3 месяцев, нет смысла держать в активной статистике) и «живые без ответственного» (клиент отвечал, но никто не назначен вести дальше). По каждой «живой» сделке назначить конкретного человека с именем и сроком следующего касания — не отделу, а сотруднику. «Мёртвые» сделки вынести в отдельную воронку реактивации, чтобы они перестали искажать общую конверсию отдела. Проверить риск на увольнение и ротацию: у каждого активного клиента должен быть второй контакт, зафиксированный в CRM, а не только в голове одного менеджера. Если база зависших сделок исчисляется сотнями — протестировать автоматическую сортировку промптом выше только на «паузниках», не на активных сделках, и только после того, как критерии оценки объяснены команде. Ничего из этого не требует бюджета на разработку. Первые четыре пункта — это час работы с выгрузкой CRM и здравым смыслом. Автоматизация подключается позже, когда ручной разбор перестаёт помещаться в рабочий день руководителя, а не раньше. Правило простое: сначала находите разрыв руками на одной неделе данных, и только когда он подтверждается системно — из недели в неделю, из месяца в месяц — переводите его в дашборд и промпт, а не наоборот. И назовём вещи именем. Умение удержать заявку на стыке — это управленческий навык, а не черта характера дружной команды. Руководитель, который открывает воронку и за минуту говорит, какие сделки стоят дольше норматива и кто по каждой отвечает, стоит дороже руководителя, который умеет только спросить на планёрке «ну как там продажи». Этому нигде не учили. Осваивать придётся на своей же выгрузке, и лучше сейчас, пока это стоит 9 сделок в месяц, а не годовой воронки. Сделайте это на этой неделе: возьмите все заявки за последние семь дней и найдите те, где нет ни одного контакта с клиентом. Каждая такая строка — оплаченный вами и выброшенный шанс. Как закрыть разрыв так, чтобы он не открывался снова, и поставить автоматический контроль без напоминалок, — механика в бесплатном курсе . Что я понял на своей истории Мы нашли у себя заявки, которые лежали без ответа по три дня, — и это при том, что у нас был регламент «отвечать в течение часа». Регламент был, ответственность размазана: заявка падала в общий пул, каждый думал, что её взял кто-то другой. Починилось не ужесточением, а простой вещью: у каждой заявки с первой секунды есть имя ответственного. Не отдел, не «менеджеры», а конкретный человек, который видит её в своём списке. После этого потери упали до единиц, и никого не пришлось наказывать. Если у вас заявки падают в общий котёл — начните с этого, до всякой автоматизации. Вам это не будет стоить ничего, кроме одного решения. ## Узкое место в процессе: как найти то, что тормозит всю компанию URL: https://davidgerstein.pro/blog/uzkie-mesta-v-processah/ Дата: 2026-07-12 Направление: Операционное управление Цифры: разные выгрузки одного показателя расходятся почти в 5 раз · 7 → 52 канала связи за месяц · сотрудников больше, чем рабочих мест Как найти узкое место в процессе Не искать виноватого, а задать процессу три вопроса: где расходятся цифры из разных источников, куда уходят деньги без привязки к результату и какое звено физически не тянет больший объём. В компании на 40 человек ответ нашёлся за вечер: 45 из 52 оплачиваемых каналов связи — почти 90% — не использовал никто, потому что за отключение лишнего не отвечал ни один человек. Проверка занимает неделю и не требует софта. Самый быстрый признак того, что узкое место в процессе у вас есть: одна и та же цифра из разных выгрузок не сходится — в одном офисе расхождение доходило почти до 5 раз . Участок, у которого нет своей цифры, и есть кандидат номер один. Если вы до сих пор ищете, кто именно тормозит работу, — вы ищете не то. Узкое место в процессе почти никогда не совпадает с участком, на который жалуются: жалуется тот, кому больно, а рвётся там, куда никто не смотрит. Разбираю метод, который находит его за вечер, вместо месяцев интуитивных догадок. Полный маршрут — от описания процесса до автоматизации — в руководстве «Как управлять бизнес-процессами» . В апреле компания платила за несколько каналов связи. В мае — уже в разы больше при том же штате. На каждого сотрудника подключены и WhatsApp, и Telegram, хотя фактически столько каналов на человека не нужно. Руководитель посмотрела на список и сказала прямо: столько сотрудников, чтобы это использовать, в компании нет. Если считать грубо: 45 из 52 каналов — «лишние», то есть почти 90% всех подключений компания оплачивала просто так (оценка, точное число нужных каналов не считали). Формула для своего случая простая: (число оплачиваемых каналов на сотрудника минус фактически нужное) × стоимость одного канала = переплата в процентах от бюджета на связь. Никто не отключал ненужное, потому что за это не отвечал ни один конкретный человек. Это и есть узкое место в бизнесе: расход, за который никто не отвечает, пока кто-то не задаст правильный вопрос. Это типичная картина узкого места: деньги или время утекают не там, где на это жалуются. Финансовый сотрудник месяцами жаловался, что его дёргают по любому платежу — срочно, сейчас, пожалуйста. Он не успевал с основной работой и начал сомневаться в своей компетентности. Руководитель разбирался неделю и нашёл проблему не в человеке, а в расписании: в его дне не было выделенного часа для платежей. Ввели правило — обработка оплат с 10 до 11 — и перебивания прекратились сами. Вот так обычно и выглядит поиск узкого места: то, на что жалуются, почти никогда не является причиной. Три вопроса, которые находят узкое место в процессе Задайте их себе по любому своему процессу — и вы сузите поиск с «где-то в компании» до конкретного участка за час. Гадать бесполезно. Работают три конкретных вопроса, которые я задаю по очереди на каждом уровне — от отдела до конкретного сотрудника. Где расходятся цифры из разных источников — если два человека называют разные числа по одному и тому же показателю, там дыра. Куда уходят деньги без привязки к результату — подписки, инструменты, часы, которые никто не пересчитывал последние полгода. Какое звено физически не может принять больше объёма — не потому что люди плохие, а потому что пропускная способность исчерпана. Дальше по каждому из трёх пунктов — реальные кейсы, а после них — механика, которую можно повторить у себя за неделю. Узкое место в процессе — это структура, а не человек Если ваш ответ на вопрос «где тормозит» звучит как имя сотрудника — проверьте ещё раз. Обычно человек стоит в точке, куда сходятся три процесса, и справился бы кто угодно так же. История с финансистом — частный случай общей ошибки: искать виноватого там, где на самом деле не хватает организации дня. Похожая история была с руководителем маркетинга — он тратил колоссальное время на ручное заполнение отчётов, счетов и таблиц в разных местах. Даже отправку счёта приходилось перепроверять через почту — точно ли ушло. Его слова: «Я бы хотел погружённо работать — взял задачу, погрузился, час ей занимался. А в большинстве случаев если удалось поделать 15 минут — это уже невероятная удача». 15 минут концентрации — вот реальная метрика узкого места. Не «сотрудник не справляется», а «структура дня физически не даёт сосредоточиться». Назову вещь своим именем: читать процесс по цифрам, а не по жалобам — это отдельный управленческий навык, и его придётся освоить. Навык руководителя сегодня не в том, чтобы раздать задачи и спросить результат, а в том, чтобы увидеть за жалобой конструкцию: где сходятся потоки, где нет ответственного, где звено упёрлось в потолок пропускной способности. Я сам полгода искал виноватых вместо того, чтобы мерить, — и это самая дорогая моя ошибка в операционке. Руководитель, который умеет разбирать процесс на звенья, стоит дороже того, кто умеет только требовать. Делегирование — это не «дать ещё рук» Отдельная категория узких мест — там, где руководитель путает делегирование с ручным трудом. Пример: менеджер ведёт несколько проектов, в каждом по несколько треков. Ему не нужна ещё одна пара рук — ему нужен помощник на каждый проект. Проблема тут не в возможности масштабирования, а в отсутствии у самого менеджера навыка ставить задачи. Дать ему одного помощника — не решить узкое место, а размазать его на двоих. Правило Если жалоба звучит «не успеваю» — сначала проверь структуру дня и распределение ролей, и только потом нанимай людей. Лишний человек в неправильной структуре создаёт второе узкое место вместо решения первого. Деньги утекают там, где вы не считаете Простое правило: если у участка нет цифры, он и есть ваш главный кандидат в узкие места. Второй вопрос метода — куда уходят деньги без привязки к результату. История с каналами связи выше — не разовая ошибка бухгалтерии, а симптом отсутствия аудита подписок. Инструменты подключаются по запросу «нужно срочно», а отключаются никогда, потому что за это не отвечает ни один конкретный человек. С деньгами работает тот же принцип, что и с расписанием, — только вместо часа в дне тут лишняя строчка в счёте. Разработчик использовал дорогую модель (уровня Opus) для задач, которые дешёвая версия (уровня Sonnet) решала с идентичным результатом. Проверили на одном и том же промпте — разницы в качестве не нашли, а разница в цене за токен была ощутимой: по открытым прайсам топовые модели обычно в 5-10 раз дороже «мини»-версий на сопоставимых задачах извлечения и структурирования текста (оценка по публичным тарифам, не внутренние цифры компании). Инструмент подключили «на всякий случай» и забыли проверить, нужен ли он в такой конфигурации — почти дословно та же история, что и с каналами связи. Данные, которые говорят на разных языках Проверьте у себя: одинаково ли называются одни и те же вещи в вашей CRM, учёте и отчётах руководителей. Третий диагностический вопрос — попробовать выгрузить одну и ту же цифру из разных мест. В одном региональном офисе попытались выгрузить список клиентов из воронки — получили три разных результата, расходящиеся почти в пять раз. Это не ошибка одного отчёта, это следствие децентрализованного хранения данных: у каждого своя версия правды, и никто не может сказать, какая верная. Именно с этого симптома обычно и начинается разговор о том, что CRM врёт — я подробно писал, как поймать систему на сдвиге дат и что делать, если данным нельзя доверять, в статье про Битрикс24 . Симптом Что на самом деле сломано Сотрудника постоянно перебивают Нет структуры рабочего дня Один человек «не тянет» несколько проектов Отсутствует навык постановки задач, а не рук не хватает Счёт «в разработке», а по факту потерян Нет единой точки истины по статусам Разные выгрузки дают разные цифры Децентрализованное хранение данных Растущий счёт за подписки без роста штата Нет ответственного за аудит инструментов Когда процесс упирается в стены Бывает и так, что ваше узкое место — не в данных, а в реальном мире: помещение, оборудование, физическая пропускная способность. Иногда узкое место — не про людей и не про цифры, а буквально про метры. В компании сотрудников по списку заметно больше, чем реальных рабочих мест в офисе: большая часть в основном помещении, остальные распределены по паре отделов, плюс ресепшен. При планируемом росте штата — запуск нового рынка, новый отдел — офис физически не вмещает коллектив. Никакая CRM и никакой ИИ это не решит, пока не пересчитаны квадратные метры. Мест в офисе сейчас меньше нужного Сотрудников по списку больше мест После найма (план) разрыв растёт На диаграмме — разрыв между доступными местами и сотрудниками по списку, который после планового найма ещё увеличится. В другом случае ту же проблему решили без стройки: переставили столы напротив друг друга, оптимизировали проходы — и разместили заметно больше людей на меньшей площади, чем изначально планировалось. Иногда узкое место снимается не бюджетом, а перекладкой мебели. Для контраста: в этой же компании параллельно обсуждался капитальный ремонт другого помещения — смета вышла на сумму, сопоставимую с несколькими месячными бюджетами компании, при сроке в полгода и отдельной ежемесячной компенсацией подрядчику за координацию. Это не альтернатива перестановке столов — это совсем другой класс решения для совсем другого масштаба задачи, и путать их — типовая ошибка: сначала стоит проверить дешёвый вариант (мебель, перепланировка проходов), и только если он физически не закрывает потребность — переходить к капитальным затратам. Та же нехватка пропускной способности — только в отделе документооборота. За один день менеджеры провели несколько встреч и получили много лидов, но сами договоры не готовят — это делают два специалиста, которые уже работают на износ, включая выходные. Проблема не в том, что менеджеры плохо продают. Проблема в том, что звено дальше по цепочке физически не успевает за новым потоком. Пока это не решено, увеличивать продажи бессмысленно — деньги всё равно упрутся в очередь на оформление. Оценить масштаб риска можно той же формулой, что и для воронки ниже: количество договоров в очереди × средний чек = сумма, которая физически не может быть закрыта в срок. Подробнее о том, как теряются деньги между маркетингом и продажами, я разбирал в материале про лиды без продаж . Механика: как провести диагностику за неделю Три вопроса выше — это направление поиска. Ниже — последовательность действий, которую можно повторить с любой командой без специального софта в первую неделю. День 1-2. Сбор жалоб. Что → фразы сотрудников на планёрках и в личных разговорах («не успеваю», «опять переделывать», «где взять цифру»). Чем → простой список без анализа. Куда → одна таблица на всех, колонки «кто сказал», «про что», «дата». День 2-3. Кросс-выгрузка данных. Что → один и тот же показатель (число клиентов в воронке, сумма дебиторки, конверсия) выгружается из CRM, из отчёта аналитика и из ручной таблицы менеджера. Чем → штатные фильтры системы, без доработок. Куда → сравнительная таблица с тремя колонками и расхождением в процентах. День 3-4. Аудит расходов на инструменты. Что → счета за подписки и коммуникационные каналы за последние 2 месяца. Чем → выгрузка из платёжной системы или бухгалтерии. Куда → список «инструмент — стоимость — кто реально пользуется» с пометкой «оставить/отключить». День 4-5. Замер пропускной способности узких звеньев. Что → количество задач на входе и на выходе у звена, на которое жалуются чаще всего (документооборот, согласование, поддержка). Чем → ручной подсчёт за 2-3 дня или счётчик в боте. Куда → таблица «поступило / обработано / в очереди». День 5. Синтез. Кто → руководитель направления вместе с тем, кто вёл таблицы. Что делает → сопоставляет три вопроса метода с собранными данными и выбирает 1-2 узких места с наибольшим денежным весом. Куда → короткая дорожная карта на ближайший месяц, а не список из двадцати пунктов. Пример того, как выглядит выбор на шаге «Синтез» в реальности. По итогам недели на столе оказалось два кандидата: сильное расхождение выгрузок по числу клиентов в одном офисе и очередь на оформление договоров у двух специалистов, работающих по выходным. Формально оба «узкие места». Но у расхождения данных цена ошибки — потерянное время на споры, чья цифра верна, это часы аналитика в неделю. У очереди на договоры цена ошибки — упущенные сделки, которые физически не закрываются в срок, то есть выручка. Руководитель в этом случае выбрал вторым приоритетом именно очередь на оформление: она напрямую сокращает деньги, а не только время. Расхождение выгрузок ушло в план на следующий месяц с более простым решением — одна точка истины по статусу клиента вместо трёх таблиц. Правило простое: при прочих равных сначала закрывается узкое место, которое режет выручку, а не то, которое просто раздражает. ИИ-связка: как автоматизировать сбор сигналов об узких местах Ручной сбор жалоб и дорожных карт хорошо работает один раз, но быстро выдыхается, если делать это каждый квартал заново. Рабочий вариант — превратить голосовую рефлексию менеджера в структурированные данные автоматически. Это тот же принцип, что применили в компании для дорожной карты изменений: менеджер за полчаса голосом описывает по каждой стадии воронки, что есть сейчас, что работает, что нужно чинить — и это уходит техническому специалисту на расписание автоматизаций. Конвейер: голосовое сообщение в Telegram-бот → транскрибация → структурирование моделью по шаблону → запись в Google Sheets → уведомление руководителю с приоритетами. Модель на шаге структурирования — дешёвая (уровня Sonnet или аналогичного класса «мини»), а не топовая. Задача здесь — не творческая генерация, а извлечение сущностей по жёсткому шаблону: разработчик в этой же компании проверял ровно это на одном промпте с дорогой и с дешёвой моделью — результат был идентичным, а счёт за токены — разным. Пример ответа модели на реальный кусок расшифровки про подготовку договоров: Инженерная обвязка. Хранилище — лист Google Sheets «Дорожная карта», каждая строка — один ответ по одному этапу. Триггер — Telegram-бот принимает голосовое, отправляет на транскрибацию, скрипт (Google Apps Script или n8n) формирует JSON из шаблона выше и вызывает API модели. Результат пишется обратно в таблицу и дублируется в Telegram-чат руководителя со scoring по приоритету — тот же принцип, что применили для ежедневной сводки по задачам и встречам. Стоимость вызовов модели логируется отдельным столбцом — чтобы не повторить историю с дорогой моделью там, где хватает дешёвой. Если транскрипция пустая или модель вернула невалидный JSON — строка помечается статусом «ошибка», и в отдельный технический чат уходит алерт с минимумом контекста, достаточным, чтобы разработчик не открывал таблицу вручную: Ответственный получает этот алерт в личном или групповом техническом чате, нажимает кнопку в боте — и скрипт заново прогоняет ту же расшифровку через модель без ручного копирования текста. Без такого алерта ошибки обработки просто накапливаются в таблице незамеченными, и через месяц половина дорожной карты оказывается пустой — это тот же тип узкого места, что и с каналами связи: расход или сбой, за который никто не отвечает. Google Sheets — Дорожная карта 20-30 голосовых в день ≈1000 токенов за вызов 5 приоритет: критично Этап Что автоматизировать Приоритет Статус Оформление договора Автозаполнение полей из CRM, уведомление о просрочке 5 критично Прикинуть стоимость эксплуатации можно так: один голосовой отчёт менеджера — это примерно 300-500 слов расшифровки, то есть около 700-900 токенов на вход плюс промпт, и ещё около 150-200 токенов на ответ модели — итого порядка 1000 токенов за вызов (оценка). При потоке в 20-30 сообщений в день это 20 000-30 000 токенов в день, или 600 000-900 000 токенов в месяц. На дешёвой модели это укладывается в единицы долларов в месяц (оценка по порядку публичных тарифов), плюс сопоставимые копейки за транскрибацию голоса. Формула для своего случая: количество сообщений в день × токены на вызов × цена за токен × дни в месяце = месячный счёт за модель. Экономика: что стоит найти узкое место и что это даёт Диагностика по трём вопросам почти ничего не стоит — это часы руководителя и аналитика на сбор данных. Стоит автоматизация конвейера вокруг неё. Ниже — расчёт по фрагментам, которые я намеренно не смешиваю в один общий эффект: это разные узкие места, с разной механикой экономии, и складывать их в одну итоговую сумму было бы натяжкой. Статья Часы / объём Оценка масштаба Настройка бота и скрипта для дорожной карты (разово) 8-12 часов работы разработчика меньше двух рабочих дней одного специалиста — разовые трудозатраты Эксплуатация: транскрибация + вызовы дешёвой модели 20-30 сообщений в день, ≈1000 токенов на вызов на порядок дешевле часа работы специалиста в месяц (единицы долларов, оценка по публичным тарифам) Высвобождение времени аналитика на ручном отчёте ≈30 минут в день → 10,5 часа в месяц (факт из практики) ≈1,5 рабочего дня в месяц на одного сотрудника — время, освобождённое для другой работы Переплата за незакрытые каналы связи (факт: 7→52 канала) 45 «лишних» каналов из 52 переплата, в 45 раз превышающая стоимость одного подключения — почти 90% всех оплаченных каналов Формула для строки с аналитиком, если хотите прикинуть свой случай: минуты экономии в день × 30 дней ÷ 60 = часы экономии в месяц. Здесь 30 минут × 30 ÷ 60 = 10,5 часа — это чуть больше рабочего дня, который каждый месяц высвобождается на одного сотрудника для другой работы. При типичной ставке менеджера это условная стоимость освобождённого времени, сопоставимая с четвертью недельного дохода на одного сотрудника — не «живые» деньги в кассе, а часы, которые можно направить на аналитику вместо копирования цифр. Отдельно — иллюстративный пример того, во сколько обходится расхождение данных, если его не замечать. Отдел из нескольких менеджеров, каждый ведёт около 10 сделок в месяц со средним чеком, сопоставимым с несколькими месячными окладами специалиста — в сумме десятки сделок в воронке. Если из-за нестыковки данных между источниками (как в примере с расходящимися выгрузками по числу клиентов) около 10% сделок «зависает» и выпадает из поля зрения — это несколько сделок, которые никто не сопровождает вовремя, потому что в отчётах их как будто нет. При типичном среднем чеке это риск, сопоставимый с месячным фондом оплаты труда небольшого отдела, которые компания не обязательно теряет физически, но которыми не управляет — сделки просто зависают между версиями правды, пока кто-то вручную не сверит три таблицы (оценка, консервативный расчёт по условному отделу, не факт из практики конкретной компании). Это не сумма, которую можно сложить с переплатой за каналы связи или с высвобожденным временем аналитика — три разных узких места, три разных источника риска, и путать их в один «эффект от ИИ» было бы нечестно перед читателем. Чек-лист на понедельник Если начинать прямо сейчас, без предварительной подготовки — вот пять действий, которые можно закрыть за один рабочий день. Выпишите три фразы-жалобы, которые слышали от разных людей за последний месяц, и отметьте, совпадают ли они по сути. Запросите один и тот же показатель (число клиентов, сумма к оплате, конверсия) из двух-трёх источников и сравните цифры. Поднимите счета за инструменты и подписки за последние два месяца — отметьте те, что выросли без роста штата. Найдите звено, на которое чаще всего жалуются менеджеры или клиенты, и посчитайте вручную его вход и выход за два дня. Выберите одно узкое место с наибольшим денежным весом и назначьте по нему одного ответственного, а не рабочую группу. Метод не требует новых людей и дорогого софта — требует готовности задать три вопроса вместо того, чтобы искать виноватого. Дальше, когда узкое место найдено, автоматизация вроде конвейера из голосового сообщения в структурированную дорожную карту убирает рутину вокруг диагностики — но не заменяет саму диагностику. Про то, как автоматизация без надзора превращается в новую проблему, я писал отдельно в материале про автоматизацию, требующую контроля . Как автоматизировать поиск и следить за узкими местами постоянно — в бесплатном курсе для руководителей . Ваш замер на эту неделю: один процесс, время каждого шага по факту. Узкое место обнаружится само, и почти наверняка это будет не тот участок, на который жалуются ваши люди. Именно поэтому мерить нужно, а не спрашивать. Как это применить у себя Ваш порядок действий такой. Возьмите процесс, на который у вас больше всего жалоб. Разложите его на шаги — не по регламенту, а как есть на самом деле. По каждому шагу узнайте у ваших людей, сколько времени он занимает и чего они ждут дольше всего. Дальше вы увидите картину: у вас будет один шаг, где очередь, и несколько, где вам казалось, что проблема. Разница между вашими ощущениями и замером обычно и есть самое ценное в этом упражнении. И не пытайтесь чинить всё сразу: расшив одно узкое место, вы получите новое в другом месте — это нормально, и это ваша следующая задача. Начните этот замер на своём процессе на этой неделе — как соединить его с постоянным мониторингом, разбираю в бесплатном курсе для руководителей . У нас первый такой замер показал, что мы полгода чинили не то: жаловались на отдел продаж, а очередь стояла на согласовании договоров. Я тогда извинился перед руководителем продаж — и с тех пор мы не обсуждаем узкие места без цифр. ## Как считать стоимость лида, чтобы не платить за брак URL: https://davidgerstein.pro/blog/stoimost-kachestvennogo-lida/ Дата: 2026-07-09 Направление: Маркетинг Цифры: конверсия 33%→6% после смены текста объявления · доля качественных лидов 40% вместо плановых 80% · одна точка входа даёт до 3 дублей на лид Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Ваш маркетолог отчитывается стоимостью лида. Цифра красивая, динамика хорошая, а продажи не растут. Знакомо? Дело в том, что вы платите не за лиды. Вы платите за клиентов — и между этими двумя вещами лежит пропасть, которую в отчётах обычно не показывают, потому что её неудобно измерять. Ниже — как считать стоимость качественного лида, а не просто заявки, и почему дешёвые заявки часто обходятся дороже. Как это устроено, разобрал отдельно: почему часть лидов теряет UTM-метку . Экономист посоветовал поменять текст рекламного объявления. Конверсия в заявку была 33%. После правки — 6%. В пять с половиной раз ниже. Зато лидов стало на 25% больше. Часть команды обрадовалась: больше заявок, дешевле каждая. Часть потребовала остановить тест. Стоимость качественного лида в этой истории никто не считал — считали только цену клика. Что происходит, когда лиды дешёвые, а денег нет, — разбор до денег . Разобрали региональную структуру новых заявок. Люди стали старше, из других регионов, часть — вообще из-за рубежа. Трафик подешевел, объём вырос, а годных клиентов для конкретной услуги в этой массе почти не осталось. Маркетинг отчитывается по цене лида, а не по цене продажи — и эти две цифры расходятся тем сильнее, чем агрессивнее реклама оптимизируется под дешёвый клик. Как рассчитать стоимость лида? Делите бюджет канала не на все заявки, а только на те, что прошли квалификацию. В одном из месяцев качественными оказались 40% лидов при плане 80% — значит, реальная стоимость лида была вдвое выше отчётной, хотя бюджет и цена клика не менялись ни на копейку. Вторая цифра, без которой первая ничего не значит, — бюджет канала, делённый на число оплативших клиентов. Канал, который по цене заявки выглядит вчетверо дешевле, по цене продажи оказывается в 4-8 раз дороже. Две разные цифры, которые вы считаете одной Разберём на вашем примере. Возьмите стоимость лида из отчёта и умножьте на количество заявок — получите бюджет. А теперь разделите тот же бюджет на число клиентов, которые реально заплатили. Вторая цифра и есть та, которой вы управляете; первую вам просто показывают. В одном месяце компания получила несколько десятков лидов из нового канала — соцсети. По качеству — нормальные, прошли фильтр. Но закрылось лишь несколько продаж. Не потому, что лиды плохие. Потому что это было первое касание: человек увидел рекламу, оставил заявку, но ещё не готов покупать. Другой источник трафика — уже тёплые, с прогревом, — конвертируется иначе и требует другого цикла продажи, часто многоэтапного. Если считать стоимость лида просто как бюджет, делённый на число заявок, оба источника выглядят одинаково хорошо. Если считать стоимость лида, доведённого до продажи, — картина другая. Формула словами: стоимость продажи = бюджет канала ÷ число закрытых сделок. Подставим для примера одинаковый бюджет на оба канала (оценка, только чтобы показать разницу в механике счёта): Показатель Канал А (соцсети) Канал Б (тёплый трафик) Бюджет на канал одинаковый (база 100%) одинаковый (база 100%) Лидов получено в два раза больше база Стоимость одного лида (отн. канала Б) ≈0,45× 1× (база) Продаж закрыто единицы заметно больше Стоимость одной продажи (отн. канала Б) ≈4-8× 1× (база) По цене лида канал А выглядит вчетверо выгоднее. По цене продажи — в 4-8 раз дороже. Именно эта подмена и происходит в отчётах, где считают заявки, а не сделки. Делите бюджет на квалифицированных, а не на всех Считать нужно так: бюджет на канал — не на общее число заявок, а на число лидов, прошедших контроль качества. Формула словами: стоимость качественного лида = бюджет канала ÷ число лидов, прошедших контроль качества. В одном отчёте из общего потока квалифицировали лишь 40% заявок, хотя планировали отбраковку не выше 20% (то есть рассчитывали получить в разы больше качественных лидов). Пример на условных числах: если бюджет на канал принять за постоянную величину, то по плану стоимость качественного лида — бюджет, делённый на плановое число лидов. По факту — тот же бюджет, делённый вдвое меньшее число лидов, то есть ровно вдвое дороже, хотя бюджет и цена клика не изменились ни на копейку. Показатель План Факт Доля качественных лидов 80% 40% Отбраковка до 20% 60% Конверсия в заявку (тест объявления) 33% (было) 6% (стало) Объём лидов после смены текста — +25% На диаграмме ниже — та же смена текста объявления, но крупно: как обвалилась конверсия при росте объёма заявок. 33% до 6% после Лидов после правки пришло на 25% больше, но доля тех, кто вообще оставляет заявку, упала в 5,5 раза — трафик стал массовым, а не целевым. Если посмотреть на путь одного лида от клика до продажи как на воронку с потерями на каждом шаге, на диаграмме ниже видно, где теряется объём — разрыв между «лид пришёл» и «лид можно продавать» нагляднее, чем в любой таблице: Валовые лиды (все источники) 100% Атрибутируемые (минус 10-15%, в декабре минус 30%) 85% Прошли контроль качества 40% Дошли до продажи (десятки лидов → единицы сделок) ~4-5% Если бюджет на рекламу не менялся, а доля качественных лидов упала вдвое, реальная цена лида выросла вдвое. Эту математику редко считают на уровне отчёта «сколько лидов пришло» — считают только на уровне «сколько заплатили за продажу», и то не всегда вовремя. Почему лид приходит некачественным У нас это выяснилось некрасиво: мы месяцами ругали подрядчика за качество, а потом посмотрели на свою сторону. Оказалось, форма на сайте собирала телефон без проверки, менеджеры перезванивали через три часа, а половина «мусорных» заявок была от людей, которым просто никто не ответил вовремя. Я тогда извинился перед подрядчиком. Скажу честно: я сам годами смотрел на цену заявки из рекламного кабинета и считал, что это и есть стоимость лида. Я не понимал, что цифра, которой меня отчитывают, и цифра, которой я управляю, — разные. Это моя ошибка: пока я сверял среднее по кабинету, два канала спокойно жгли бюджет и не приносили денег. Если вы сейчас в этой точке — это нормально, здесь ошибаются почти все, кто впервые садится сводить маркетинг с кассой. Прежде чем требовать качество с маркетолога, посмотрите на свою сторону: скорость ответа, форму, скрипт первого касания. Часть причин почти всегда лежит у вас в процессе, а не в его настройках. Причины, которые видел на практике, почти всегда одни и те же. Несоответствие оффера аудитории. Маркетолог продавал услугу, описывая процедуру оформления документов — то, что клиенту неинтересно. С аналитиком собрали три типовых портрета покупателя: часто это люди старшего возраста, одинокие или с выросшими детьми, ищущие общие интересы. Как только начали говорить о болях, а не о процедуре, отклик изменился. До этого лиды формально были — просто не те. Отсутствие сегментации базы. Рассылка по базе из 15 000 контактов дала открываемость 50% — отличный результат по меркам email-маркетинга. Конверсия в лид — 0%. Прямое предложение консультации без прогрева не сработало вообще. «Стрелять из пушки по воробьям, не понимая сегментацию» — точное описание того, что произошло. Решение — серия из 3-4 писем с конкретными выгодами вместо одного прямого оффера. Неготовность локального рынка. При выходе на новый языковой рынок с целевой аудиторией в сотни тысяч человек в одном городе, за всё время работы локальной версии сайта получили лишь пару покупателей — и оба оформили сделку на английском. Проблема не в объёме аудитории, а в непонимании локальных болей и слабой проработке трафика на этом языке. Подробнее о том, где именно трафик превращается в разрыв между «лиды есть» и «продаж нет», разбирал в статье Квалификация лидов: почему лиды есть, а продаж нет . Что искажает саму стоимость лида в ваших отчётах Проверьте каждый пункт у себя — обычно работают минимум два, и вместе они дают расхождение в разы. Прежде чем считать стоимость качественного лида, стоит убедиться, что число лидов в отчёте вообще реально. Обнаружили: одна входящая точка создавала два-три дубликата лида в системе. Конверсия «падала» день ото дня в отчётах, хотя реальная ситуация была стабильной. Нашли это случайно, просматривая утренние цифры. Если дубли не чистить, стоимость лида занижается искусственно — делишь бюджет на раздутое число заявок и получаешь красивую, но неверную цифру. Стоимость лида нужно смотреть в динамике, а не разово: разовый отчёт за один месяц маскирует тренд. Конверсия органического трафика сайта в лид составляла 17% в январе, снизилась до почти 15% в марте и упала ниже 10% в апреле — устойчивое падение качества канала, которое видно только при сравнении месяцев подряд, а не по одной цифре за отчётный период. Отдельная категория — неатрибутируемые лиды. Пользователи блокируют куки, чистят историю, используют блокировщики рекламы. В среднем такие лиды — 10-15% потока. В декабре доля выросла до 30%. Их нельзя честно приписать ни одному каналу, но и выбрасывать из общей картины нельзя — иначе стоимость привлечения по атрибутированным каналам искусственно завышается. Ещё один источник путаницы — расхождение отчётов по датам и статьям учёта. В одном случае разница между отчётами двух менеджеров составила около 11% от общей суммы: сделку не засчитали как лид, потому что формально это была рекомендация, а не заявка. В другом случае фильтрация по месяцу оплаты вместо месяца создания договора дала расхождение почти в 1,7 раза между двумя версиями одного и того же отчёта. Такие расхождения делают любой расчёт стоимости лида условным, пока данные не сверены на уровне CRM, а не на уровне памяти сотрудников. Похожая история с искажением дат подробно разобрана в статье CRM врёт: как я поймал Битрикс24 на сдвиге дат . Правило Пока в CRM есть дубли, неразмеченные неатрибутируемые лиды и расхождение по датам оплаты и создания сделки, любая цифра стоимости лида — это оценка, а не факт. Сначала чистка данных, потом расчёт стоимости. Скоринг лидов до того, как их увидит менеджер Смысл для вас простой: ваши менеджеры перестают тратить утро на заявки, из которых ничего не выйдет, и занимаются теми, где есть деньги. Отдельно от чистки данных — задача сортировки уже пришедших лидов по вероятности сделки. Идея простая: не тратить одинаковое время менеджера на лида с высокой вероятностью и на лида, у которого шансов почти нет. Внедряется модель, которая оценивает поведение на сайте (время на странице, посещённые разделы), сверяет с данными о сегменте и типе услуг и выдаёт приоритет ещё до звонка. Схема конвейера: лид попадает в CRM → вебхук отправляет карточку лида в модель → модель возвращает приоритет и обоснование → поле в CRM обновляется автоматически → менеджеру приходит уведомление только по высокоприоритетным лидам. Задача чисто классификационная — оценить вероятность по структурированным признакам, а не сочинить текст. Дорогая модель уровня топового GPT или Claude тут ни к чему: дешёвая модель с коротким контекстом справляется не хуже при потоке в десятки и сотни лидов в день, а разница в цене — в разы. Пример ответа модели на этот запрос: Вот как это выглядит уже в CRM, после того как вебхук отработал и записал ответ модели в карточку сделки: amoCRM · сделка #48213 42% вероятность сделки medium приоритет 340 сек время на сайте facebook_ads источник Поле Значение Статус Регион не определён Страницы pricing, cases, faq Рекомендация прогревающее письмо, без звонка Инженерная обвязка: вебхук amoCRM при переходе сделки в статус «новый лид» дёргает облачную функцию. Функция формирует JSON, отправляет запрос модели и пишет ответ в кастомное поле сделки. Если модель не отвечает за 10 секунд или возвращает невалидный JSON, сделка получает статус «требует ручной оценки». Ошибка уходит в отдельный лист Google Sheets, менеджер по данным разбирает такие случаи раз в день. Без этой страховки система молча теряет часть лидов, а никто не замечает. Где ломается обвязка У партнёра неделю не работал похожий бот для сбора лидов — команда клиента не спешила чинить, потому что общий бизнес и так приносил деньги, а сбой в одном модуле не выглядел критичным. За неделю потеряли данные обо всех лидах, прошедших через этот канал. Автоматизация без обязательного алерта об ошибке — это не автоматизация, а тихая дыра в воронке. Подробнее о том, как надзор за автоматикой не даёт ей развалиться незаметно, — в статье «Если бы я не пришёл, ничего бы не произошло» . Квалификация как отдельный этап Здесь вам придётся принять управленческое решение, а не техническое: кто в вашей компании отвечает за квалификацию и по каким критериям. Без этого любой скоринг останется цифрой, которой никто не пользуется. Скоринг ускоряет квалификацию, но не заменяет её. Отдельная практика — осознанный отказ от продажи там, где нет оснований. Компания сознательно отказывает лидам, если уверена, что предпосылок для сделки нет: продажа такому клиенту — репутационный риск. Вместо продажи — предварительный сервис партнёра для проверки оснований, с передачей результата обратно в CRM триггером. Это дороже на этапе обработки одного лида, но дешевле на дистанции — меньше возвратов и жалоб. Синхронизация оплаты и потока лидов Отдельная проблема, которая напрямую влияет на стоимость лида, — не маркетинговая, а операционная. Чтобы получить лиды в начале месяца, счёт за рекламу нужно оплатить в конце предыдущего — например, 28-го числа ради лидов 3-го числа следующего месяца. Половина счетов оплачивается не вовремя. Разрыв в оплате разрывает весь цикл привлечения: рекламный кабинет снижает показ, лиды идут неравномерно, а стоимость каждого лида в такие дни растёт — просто потому что бюджет распределяется не по плану, а по факту оплаты. Где ломается расчёт Планирование бюджета на маркетинг без синхронизации с датой оплаты счетов приводит к тому, что даже правильно посчитанная стоимость лида не выполняется на практике — просто потому что реклама не откручивается вовремя. Как это выглядит в вашем плане, а не в отчёте задним числом Разница принципиальная: отчёт объясняет, почему не получилось, план говорит, сколько качественных лидов вам нужно в неделю, чтобы получилось. Планировали рост доли качественных лидов до плановых 80% в мае с ускорением в июне, с детализацией по неделям и дням — чтобы видеть отставание раньше, чем закроется месяц. При стабильном ежедневном потоке валовых лидов со всех источников, из которых качественных набиралось около 40% за прошлую неделю вместо плановых 80%, компания сразу видела отставание от графика, а не через месяц по итоговому отчёту, когда бюджет уже потрачен. Отдельно учли сезонность: для декабря как месяца низкого спроса ввели коэффициент 0,8 — на 20% ниже обычного плана, с перераспределением недостающего объёма на остальные месяцы. Без такого коэффициента декабрьский провал выглядел бы как проблема с качеством лидов, хотя на деле это сезонное падение спроса, которое повторяется из года в год. Экономика: что стоит скоринг и что он даёт Посчитайте на своих цифрах: сколько времени ваши менеджеры тратят на обработку заявок, из которых ничего не выйдет. Обычно это несколько ставок в год, спрятанных внутри рабочего дня. Внедрение вебхука и обвязки на amoCRM API с дешёвой моделью — это разработка на несколько дней силами одного специалиста, плюс тестовый прогон на паре сотен лидов. Эксплуатация — счёт за токены модели, который при потоке в десятки лидов в день остаётся на уровне обычного облачного сервиса, а не отдельной статьи расходов. Подробный разбор того, сколько реально стоит ИИ в эксплуатации, — в статье Сколько на самом деле стоит ИИ в месяц . Эффект считаю отдельно от остальных мер — от смены оффера, от сегментации базы, от чистки дублей. Сам по себе скоринг не увеличивает долю качественных лидов, он экономит время менеджера на этапе первичной обработки: не нужно вручную выяснять по каждому лиду, стоит ли звонить сейчас или лучше сначала прогреть. Формула для риска сорванных сделок словами: доля сделок, потерянных из-за неправильной приоритизации, × число сделок в месяц × средний чек = сумма риска в месяц. Возьмём условную компанию из легенды: сервисная компания, отдел продаж из 8 менеджеров, оборот около 9 млн ₽ в месяц при среднем чеке сделки 180 000 ₽ — это около 50 сделок в месяц. Если доля сделок, которые зависают или срываются из-за того, что менеджер потратил время на заведомо слабый лид вместо приоритетного, — около 10% от месячного объёма (оценка), то при 50 сделках это 5 сделок, а риск ≈ 5 × 180 000 ₽ = 900 000 ₽ в месяц (оценка). Скоринг не гарантирует спасение всех этих сделок, но снижает вероятность, что приоритетный лид будет обработан на день позже конкурента. Отдельно — прямая экономия часов. Формула словами: (число отбракованных лидов в день × минуты на первичный контакт) ÷ 60 = часы, потраченные впустую; часы × ставка менеджера в час = потери в день; потери в день × число рабочих дней = потери в месяц. Пример на подставленных числах для той же условной компании: при потоке 25 лидов в день на отдел из 8 менеджеров и фактической отбраковке 60% (как в разобранном случае) отсеивается 15 лидов в день; на первичный контакт с одним лидом уходит в среднем 12 минут (оценка) — суммарно 180 минут, то есть 3 часа впустую. При ставке около 1 000 ₽/час менеджера это 3 000 ₽ в день, а за 22 рабочих дня — около 66 000 ₽ в месяц (оценка), что сопоставимо с большей частью оклада одного менеджера в этой легенде. Это не потерянные деньги, а время, которое можно вернуть приоритизацией, а не расширением штата. Что не считаем эффектом: если время, освободившееся у менеджера, ушло не на новые продажи, а на другую текучку, — это перераспределение часов, а не деньги в кассе. Чек-лист: с чего начать в понедельник Выгрузить лиды за прошлый месяц и вручную проверить дубли по телефону и email — без этого шага любая цифра стоимости лида условна. Заведите в CRM отдельное поле «неатрибутируемый» и считать долю таких лидов отдельно от общей воронки, не смешивая с браком. Сверить график оплаты рекламных счетов с датой ожидаемых лидов — счёт должен уходить минимум за 3-5 дней до нужного окна показов. Прогнать последние партии лидов через контроль качества и сравнить фактическую отбраковку с плановой — если план был 20%, а факт 50-60%, это сигнал к пересмотру оффера, а не канала. Запустить простую приоритизацию по баллам без модели — и только после того, как логика проверена руками, переносить её в промпт и вебхук. Пересчитать стоимость каждого канала не по количеству заявок, а по количеству лидов, дошедших до квалификации — сравнить каналы заново, цифры почти всегда меняют местами лидеров. Стоимость качественного лида — это не цифра из рекламного кабинета. Это результат вычитания: из всех заявок вычесть дубли, вычесть неатрибутируемые, вычесть тех, кто пришёл с первым касанием и ещё не готов покупать, вычесть тех, кто не проходит критерии квалификации. То, что осталось, и есть настоящий лид — и его цена почти всегда выше, чем средняя цена заявки по кабинету. Начните с простого: попросите посчитать конверсию в оплату по каждому источнику. Не в сделку, а в деньги. Через неделю у вас будет другой разговор с маркетингом — предметный. Как поставить скоринг лидов до того, как их увидит менеджер, — механика в бесплатном курсе . Как я теперь смотрю на этот показатель Мы у себя перестали обсуждать стоимость лида на планёрках вообще. Осталось два числа: сколько стоит клиент, который заплатил, и сколько заявок пришлось обработать, чтобы его получить. Всё остальное — рабочие метрики маркетолога, и в мой отчёт они не попадают. И ради этого стоило заводить весь разговор. Умение отличать метрику, которой вас отчитывают, от метрики, которой вы управляете, — это управленческий навык, а не бухгалтерия. Руководитель, который умеет задать системе один точный вопрос и получить на него честную цифру, стоит дороже руководителя, который принимает готовый отчёт как данность. Этому навыку нигде не учат — его придётся поставить себе самому, и начинать проще всего со стоимости лида. Эффект оказался неожиданным: разговоры стали короче, а решения — точнее. Мы закрыли два канала, которые давали дешёвые заявки и ноль денег, и вложили их бюджет в тот, что казался дорогим. Выручка выросла, при том что «стоимость лида» в отчёте ухудшилась — и это было правильное ухудшение. ## План-факт без вранья: как смотреть на расхождения и не искать виноватых URL: https://davidgerstein.pro/blog/plan-fakt-bez-vranya/ Дата: 2026-07-06 Направление: Стратегия Цифры: план разошёлся с фактом больше чем в два раза · +40% к плану без права на похвалу · несколько десятков прилётов в месяц Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваш план-факт всегда сходится — вас обманывают. Или вы обманываете себя: план подгоняют под факт, факт трактуют под план, и разбор превращается в ритуал. Честный план-факт неприятен по определению: он показывает, где вы ошиблись в прогнозе. Именно поэтому он и полезен. Собственнику принесли годовой план выручки. В документе, который реально согласовали руководители, стояла сумма в разы меньше. Разница не в ошибке округления — в двух разных сущностях. Кто-то считал сумму договоров, кто-то — авансовые платежи, которые составляют примерно 37–40% от той же выручки. Арифметика это подтверждает: согласованная цифра — это как раз около 40% от исходного плана, то есть похоже, что один документ считал полную сумму сделок, а другой — только авансовую часть от неё. Формально оба правы. По факту план-факт анализ в таком виде бессмысленен: сравнивать нечего, потому что никто не договорился, что такое «факт», а разница выглядит как катастрофа только до тех пор, пока не найдена эта развилка. план факт На диаграмме — два документа с разными критериями факта: факт составил около 40% от плана, то есть похоже на авансовую часть от полной суммы сделок, а не ошибку расчёта. Здесь я обязан сказать про себя. Я сам долго не проверял, из чего складывается «факт» в сводном отчёте: в одной таблице фактом были деньги на счёте, в соседней — сумма подписанных договоров, и я месяцами сравнивал одно с другим, не замечая подмены. Ощущение контроля при этом было полное. Так что если вы сейчас узнали свою компанию — это нормально: определение факта не проговаривают вслух ровно потому, что каждому по отдельности оно кажется очевидным. Я видел эту историю в разных декорациях десятки раз. Компания вроде бы считает цифры, строит таблицы, проводит планёрки — а решения принимаются на глазах у всех неправильно, потому что план и факт измеряют разные вещи. Дальше — как выглядит рабочий план-факт анализ, если убрать из него вранье, поиск виноватых и посчитать, во сколько часов и денег обходится его отсутствие. Как считать отклонение факта от плана Формула отклонения факта от плана Как считать Отклонение = (факт − план) ÷ план × 100 %. Положительное — перевыполнение, отрицательное — недобор. Формула тривиальна; врёт обычно не она, а определение факта: что именно считается фактом и на какую дату он зафиксирован. Отклонение = (факт − план) ÷ план × 100%. Формула тривиальна, ошибка живёт в другом месте: в определении факта. Спросите своего финансиста и коммерческого по отдельности, что считается фактом выручки — деньги на счёте или подписанный акт. Ответы обычно расходятся, и любой ваш план-факт бессмыслен, пока это не зафиксировано письменно. Во что обходится одна неверная цифра в презентации — случай, который чуть не увёл стратегию . Второе правило: перевыполнение вдвое разбирается так же, как провал. И то и другое означает, что вы неверно спланировали. Когда +40% к плану — не повод хвалить Проверьте у себя: перевыполнение вдвое означает не героизм команды, а то, что вы неверно спланировали. И то и другое стоит разобрать. Отдел показал результат на 40% выше запланированного. Обычная реакция — премия, благодарность на планёрке. Собственник в этой истории похвалить не смог. Потому что сама стратегия, из которой родился план, устарела через несколько месяцев работы: изменилась геополитическая обстановка, законодательство, новостная повестка — спрос сдвинулся, а цифры в документе остались прежними. Отдел не стал работать в четыре раза лучше. План был занижен из-за внешних факторов, которые никто не пересчитал. И вот тут главная ловушка план-факт анализа: отклонение в плюс воспринимается как достижение автоматически, а на самом деле это тот же сигнал, что и отклонение в минус — модель сравнения сломана. Правило Отклонение — это не оценка человека, это оценка модели. Прежде чем хвалить или наказывать за план-факт, проверь: план вообще был живым на момент сравнения, или он написан три месяца назад и с тех пор не пересчитывался? Решение, которое приняли в этой истории — перейти от фиксированных цифр к формулам. Если темп роста составляет плюс 5% в месяц, формула пересчитывает плановые показатели автоматически при загрузке фактических данных за период. Например: план на месяц был условной единицей, за предыдущий месяц факт вырос на те же +5% — формула на следующий месяц ставит план не «из старой презентации», а с учётом этого роста, и +40% к устаревшей цифре превращаются в честные проценты к живой базе. План перестаёт быть документом, который переписывают раз в квартал под недовольство руководителей, и становится рабочим инструментом, который живёт вместе с бизнесом. Подробнее о том, как стратегия превращается из презентации в рабочий процесс, — в отдельном материале про стратегию как рабочий инструмент . Всё начинается с определения факта Спросите двух своих руководителей, что считается фактом выручки — деньги на счёте или подписанный акт. Если ответы разошлись, ваш план-факт бессмыслен, пока вы это не зафиксируете. История с расхождением плана и факта больше чем в два раза — не про арифметику, а про дисциплину. Прежде чем сравнивать план с фактом, нужно письменно зафиксировать: факт — это что? Подписанный договор? Аванс на счёте? Деньги, прошедшие полный цикл оплаты? В одной из компаний это довели до предельной ясности: «Действуем по факту. Если в течение двух дней деньги заходят, я решу этот вопрос» — продажа признаётся не в момент устной договорённости и не в момент подписания, а в момент поступления денег в оговорённый срок, минуя лишние согласования с бухгалтерией. Жёстко, но честно: план-факт отклонения считаются от одной точки отсчёта, а не от трёх разных в зависимости от того, кто отчитывается. Похожая проблема всплыла с аналитикой каналов продаж. Руководитель спросил SEO-специалиста, откуда конкретно приходят лиды из органического поиска . Специалист не смог назвать источники — аналитика не была настроена на связку «поисковый запрос → страница → продажа». Формально отчёты существовали. По факту план-факт анализ по каналу был фикцией: цифры были, а понимания, откуда они взялись, не было. Руководитель после этого потребовал перестроить отчётность так, чтобы каждый исполнитель стратегии понимал, за какие конкретные результаты он отвечает — иначе план-факт по каналу так и остаётся красивой таблицей без содержания. Если данные в CRM или аналитике сами по себе искажены или неполны, весь план-факт анализ строится на песке — похожий случай я разбирал в материале про то, как CRM врёт с датами . Юнит-экономика как база для сравнения Без понимания экономики по каждому направлению план-факт анализ превращается в сравнение двух случайных чисел. «Ты должна знать юнит-экономику каждого направления как свои пять пальцев. На гражданской — сколько зарабатываем, какая маржа, какие точки бизнеса. Это база, база, база. Любой финансовый директор знает всю эту юнит-экономику. Всё» — фраза руководителя финансовому директору звучит жёстко, но по делу. Если нет базовой единицы экономики, отклонение факта от плана нельзя интерпретировать: непонятно, хорошо это или плохо, дорого или дёшево. Механика по шагам Соберёте за вечер: план, факт, отклонение, причина. Четыре колонки, из которых сложнее всего заполняется последняя — и именно ради неё всё затевается. Ниже — последовательность, которую можно повторить с любой командой за одну-две недели, без закупки новых систем. Зафиксировать факт письменно. Один документ, один критерий: деньги на счёте, а не обещание менеджера. Ответственный — финансовый директор или собственник, не отдел продаж (у него конфликт интересов). Выбрать источники данных. Сделки и стадии — CRM (в наших примерах Bitrix24), поступления денег — банк/бухгалтерия, лиды по каналам — рекламные кабинеты и аналитика сайта. Три источника, а не один общий Excel «на глаз». Свести данные в один регистр. Google Таблица или BI-лист, куда раз в сутки выгружается срез: план по неделе, факт по неделе, статус сделки, ответственный менеджер. Назначить ритм сверки. Фиксированный день недели, один и тот же блок вопросов: маркетинг, продажи, авансы. Не «как получится», а каждую неделю в один день. Разметить отклонения по статусам. Зелёный/жёлтый/красный — не проценты в вакууме, а понятные пороги, одинаковые для всех менеджеров. Разобрать красные позиции на планёрке. Не весь список, а только критические — иначе совещание превращается в перечитывание таблицы вслух. ИИ-связка: автоматическая еженедельная сверка Здесь машина берёт на себя сбор и первичный разбор: вам приходит список отклонений с гипотезами, а не пустая таблица, которую надо заполнять. Ручная сборка план-факт отчёта — это тот момент, где дешёвая модель окупает себя быстрее всего. Задача не творческая: разложить сделки по статусам, посчитать агрегаты, выделить, что горит. Для этого не нужна дорогая модель — нужна дисциплинированная дешёвая, которая не выдумывает цифры, а классифицирует то, что ей дали. Схема конвейера: Bitrix24 (сделки, стадии, суммы, даты) → вебхук выгружает срез в Google Sheets раз в сутки → по четвергам скрипт Apps Script собирает недельный срез, обогащает его прошлой неделей и отправляет в LLM → модель возвращает JSON со статусами и приоритетами → результат записывается обратно в лист «Итоги недели» и дублируется сообщением в Telegram-чат руководителей. Модель здесь — дешёвая, уровня GPT-4o-mini или аналогичного класса: задача классификаторская, а не творческая, и переплачивать за «умную» модель нет смысла — она с той же вероятностью либо верно посчитает проценты, либо ошибётся, но стоит в разы дороже. Так этот же результат выглядит для руководителя не в JSON, а в листе «Итоги недели», куда скрипт кладёт агрегаты и список красных клиентов: Итоги недели — план-факт по сделкам 21 сделок зелёных 6 сделок жёлтых 4 сделок красных Клиент Менеджер Доля риска Просрочка Статус C-1042 Игнатова 18% 6 дней C-1090 Седов 27% 9 дней Инженерная обвязка. Скрипт крутится в Google Apps Script по триггеру времени (четверг, утро). Вебхук Bitrix24 настроен на выгрузку изменений по сделкам раз в сутки в промежуточный лист. Если LLM не отвечает или возвращает невалидный JSON — скрипт не затирает предыдущий отчёт, а шлёт сообщение об ошибке в тот же Telegram-чат: «план-факт отчёт за неделю не собран, проверь вебхук и лог». Ручной перезапуск — одна кнопка в меню таблицы, доступна ответственному, а не только тому, кто писал скрипт. Где ломается Красиво оформленный план-факт отчёт — не гарантия того, что цифры в нём верны. Команда собрала похожую ИИ-модель для стратегического прогноза по региональному филиалу: прогноз звучал убедительно, но при проверке выяснилось — не учтены бонусы продаж, целевые показатели ничем не обоснованы, а прогноз объёма на будущий год — по сути домысел, оформленный уверенным текстом. Команда вернулась к ручному построчному пересчёту плана против фактических бонусов и только потом стала подключать автоматизацию заново, поэтапно: сначала классификация отклонений, потом прогнозирование, и то под контролем человека на каждом шаге. Если отчёт готовит ИИ или один человек без перепроверки, хотя бы раз в квартал прогоняй конкретные цифры руками — премии, налоги, комиссии выпадают из автоматических расчётов первыми. Ритм: план-факт отклонения нужно видеть еженедельно В одной из компаний с проблемами по продажам ввели фиксированный еженедельный коммерческий отчёт: маркетинг, продажи, авансы — три блока, один день недели, четверг. Результаты накапливаются за неделю и сводятся в единую таблицу. Смысл не в самой таблице, а в скорости обнаружения проблемы: если конверсия просела, за неделю видно, это глобальная проблема или дело в конкретном менеджере, который заболел или уволился. Компания, о которой шла речь, находилась не в теоретической ситуации. Выпало два источника дохода — один на два месяца, другой на больший срок, — новых сделок осталось лишь несколько десятков в месяц, денег не хватало ни на увеличение продаж, ни на поддержание уровня прошлого месяца, зарплата выплачивалась с резервного налогового счёта. «Мы все прекрасно понимаем, что по закрытиям счетов у нас просадка... прилетов у нас немного, точка. Глобально у нас есть проблемы... у нас нет денег на то, чтобы вложиться в увеличение продаж» — в такой момент план-факт анализ раз в квартал — роскошь, которую компания не может себе позволить. При таком скромном потоке даже несколько сделок в статусе «красный» — это уже 10–15% всего месячного объёма (оценка), и заметить их нужно за неделю, а не постфактум в конце месяца. Еженедельный ритм — единственный способ поймать проблему до того, как она станет фатальной. Блок отчёта Что фиксируется Зачем Маркетинг Лиды по каналам, стоимость, конверсия в квалификацию Понять, откуда реально приходят деньги, а не откуда «должны» Продажи Сделки по стадиям, суммы, отклонение от плана недели Увидеть проблему на уровне менеджера или воронки, а не всего отдела Авансы Поступившие платежи, просрочки, дебиторка Отделить «продал» от «получил деньги» Похожий принцип — не полагаться на память людей, а строить контроль на данных — я описывал применительно к дебиторской задолженности в статье про контроль долгов . Логика та же: план-факт анализ без систематического сбора данных быстро превращается в разговоры на память. Три цвета вместо одной цифры На уровне отдельной сделки план-факт отклонения удобно смотреть не в процентах, а в статусах. Одна из компаний внедрила трёхуровневую систему контроля клиентов: таблица каждого клиента со сроками и цветовым статусом; сводная таблица по стадиям воронки с количеством и суммой; отдельный список красных клиентов для приоритетной работы. Статус Критерий Действие Зелёный Отклонение по срокам/сумме ≤ 5% Штатный мониторинг, разбор не нужен Жёлтый Отклонение 5–15% или просрочка 1–3 дня Отметить менеджеру, проверить на следующей неделе Красный Отклонение >15% или просрочка >3 дней В отдельный список, разбор на планёрке в приоритете Смысл системы не в красоте, а в том, что она убирает субъективность из разговора «как дела с клиентом». Либо клиент зелёный, либо нет — критерий один и тот же для всех менеджеров. План-факт анализ на уровне отдельной сделки перестаёт зависеть от того, кто и как красиво отчитывается на планёрке. Похожий принцип виден и на уровне каналов продаж за годы. Когда собственник потребовал переделать презентацию стратегии маркетинга — цифры по выручке (годовые) не совпадали с бюджетом (месячным), информация была неупорядочена, отсутствовали временные маркеры реализации, — новая структура зафиксировала прогресс по годам явно: в 2025-м доля SEO-лидов была 5%, в 2026-м — 35%. Не абстрактный «рост», а конкретная точка до и точка после. 5% в 2025 35% в 2026 На диаграмме — доля SEO-лидов в общем потоке до и после пересборки маркетинговой стратегии: с 5% в 2025 году до 35% в 2026-м. Такой формат «до/после» по каждому каналу отдельно — SEO, Telegram, реферальные источники — заставляет план-факт отчёт отвечать не только «сколько», но и «за счёт чего»: «Я не говорю, за счёт чего он даст больше лидов. Я хочу понимать: за счёт SEO или за счёт SMM?» — это требование к плану, а не к красивой презентации. Решения на данных, а не на убедительном тексте Вам будут приносить объяснения. Ваша задача — требовать под каждое объяснение цифру, иначе разбор превращается в конкурс красноречия. Тот случай с региональным филиалом, о котором шла речь выше, — не исключение, а типичный сценарий: правдоподобный текст от ИИ легко принять за расчёт. Модель не врёт специально — она просто не знает, что бонусы продаж не учтены, а целевые показатели никто не обосновал. Она честно оформляет то, что ей дали, в уверенный абзац. Управленческие решения на данных требуют, чтобы кто-то проверил цифры руками, а не просто прочитал складный текст. Команда сначала вернулась к ручному пересчёту — построчно сверила план с фактическими бонусами и обоснованием целевых цифр — и только после этого стала подключать автоматизацию, но поэтапно: сначала классификация отклонений, потом прогнозирование, и то под контролем человека на каждом шаге. Обещание — не факт Самая частая подмена в отчётах, которые вам показывают. Проверьте, не считаете ли вы фактом то, что ещё не случилось. Отдельно стоит история про юристов и бонусы за выигранное дело. Решили платить бонус тому, кто официально закреплён ответственным за кейс, а остальным — отдельно, за помощь, вне привязки к конкретному результату. Правило на будущее простое: один человек отвечает за результат, остальные помогают без ревности к похвале. Это тоже часть план-факт дисциплины — если неясно, кто отвечает за цифру, то и отклонение некому предъявить, кроме абстрактной «команды». С этим же связана фраза, которая объясняет половину проблем с планом в продажах: «Проблема не в том, что ты продал. Проблема, что пообещал». Расхождение план-факт часто рождается не в момент подведения итогов, а в момент, когда менеджер обещает клиенту то, что компания не может обеспечить. К моменту сверки цифр это уже не отклонение — это долг, который придётся закрывать за чужой счёт. Экономика: что стоит и что даёт вам Час вашего времени в неделю против решений, принятых с опозданием на месяц. Ваши затраты — час в неделю. Отдача — решения, принятые на неделю раньше, чем раньше. Настройка ручной дисциплины плана-факта занимает около 8–12 часов работы руководителя и аналитика (оценка), автоматизация сборки данных экономит порядка 72 часов в месяц ручного труда менеджеров (оценка), а еженедельная сверка помогает раньше увидеть риск на сумму около 1 800 000 ₽ оборота под угрозой (оценка) — три разных числа, которые нельзя складывать в один эффект. Формула для собственной прикидки простая: количество сделок в месяц × доля «зависших» (не отменённых явно, а просто не дошедших до оплаты в срок) × средний чек = оборот под риском. Дальше отдельно: часы ручной сверки × ставка сотрудника = стоимость рутины, которую можно снять автоматизацией. Ниже — расчёт на условной компании с отделом из 12 менеджеров и оборотом ~18 млн ₽/мес, чтобы формулу было видно в цифрах. При среднем чеке 300 000 ₽ отдел закрывает около 60 сделок в месяц. Если 10% сделок «зависает» — это 6 сделок в месяц, риск ≈ 1 800 000 ₽ месячного оборота (оценка). Это не потерянные деньги — это деньги, судьба которых неизвестна до тех пор, пока нет чёткого критерия факта и еженедельной сверки. Стоимость внедрения ручной части — не про деньги, а про часы: договориться о критерии факта, развести таблицу по трём блокам, обучить менеджеров вносить статус — это разовые 8–12 часов работы руководителя и аналитика. При ставке ~1 000 ₽/час это около 10 000 ₽ разово — меньше одного дня простоя одного менеджера. Автоматизация сборки данных (вебхук Bitrix24 → Google Sheets → LLM-классификация) экономит не стратегию и не продажи — только рутину сведения отчёта. Если раньше каждый из 12 менеджеров тратил около 1,5 часа в неделю на ручное заполнение и сверку своих сделок для еженедельного отчёта, это 18 часов в неделю на отдел, то есть около 72 часов в месяц. При ставке ~1 000 ₽/час это около 72 000 ₽ в месяц рабочего времени, которое уходит на копирование цифр в таблицу вместо продаж. Что мы не считаем эффектом: высвобожденные 72 часа менеджеров — это поток времени, а не автоматическая прибавка к выручке. Если менеджер потратит освободившиеся часы не на звонки клиентам, а на другую рутину, денежного эффекта не будет вообще. И риск оборота 1 800 000 ₽, и экономия часов — это два разных числа: одно про то, что дисциплина помогает раньше увидеть проблему (но не гарантированно её решает — часть зависших сделок всё равно не закроется), другое — про экономию рутины. Складывать их в один «результат внедрения» нельзя. Эксплуатация модели-классификатора: при недельном прогоне среза на 60 сделок объём текста на вход и выход укладывается в несколько тысяч токенов за прогон. Четыре прогона в месяц (по четвергам) при тарифах дешёвых моделей уровня GPT-4o-mini — это меньше 100 ₽ в месяц суммарно, то есть дешевле одной чашки кофе на всю автоматизацию, при условии что через модель гоняется только еженедельный агрегированный срез, а не весь массив сделок построчно. С чего начать в понедельник Зафиксировать письменно, что именно считается фактом: деньги на счёте, договор или аванс — один критерий, один документ. Назначить фиксированный день недели для сверки и одного ответственного, кто сводит данные (не тот, кто отчитывается по продажам). Разметить сделки по трём статусам — зелёный/жёлтый/красный — с одинаковыми порогами для всех менеджеров. Проверить, актуален ли план: если условия рынка изменились, не сравнивать факт с устаревшими цифрами — пересчитать план формулой. Настроить минимальную автоматическую выгрузку данных (CRM → таблица) прежде чем звать ИИ считать отклонения. Раз в квартал прогонять конкретные цифры отчёта руками — премии, комиссии и бонусы первыми выпадают из автоматики. План-факт анализ, который не ищет виноватых, — это не про мягкость к людям. Это про то, что сначала нужно договориться о единице измерения, потом — о ритме сверки, и только потом разбирать, почему цифры разошлись. Без первых двух пунктов третий превращается в театр. И ещё одно, про вас лично. Держать план-факт живым — это отдельный управленческий навык, а не бухгалтерская функция, которую спускают вниз вместе с таблицей. Руководитель, который за минуту отвечает, что в его компании считается фактом, на какую дату он зафиксирован и кто его сводит, управляет бизнесом. Тот, кто не может, управляет пересказом отчётов. Этому навыку не учат — его добирают сами, обычно после первой цифры, которая развалилась на совете. Начните с определений на этой неделе: зафиксируйте письменно, что считается фактом и в какой момент. Дальше любой ваш разбор станет предметным, а половина споров исчезнет сама. Как автоматизировать еженедельную сверку и получать отклонения списком — в бесплатном курсе . План-факт — часть общей конструкции отчётности: у каждого показателя должен быть источник правды, хозяин и срок обновления. Разбор целиком — в руководстве по управленческой отчётности . ## Электронный архив документов, который не разваливается, когда сотрудник уходит URL: https://davidgerstein.pro/blog/elektronnyj-arhiv-dokumentov/ Дата: 2026-07-02 Направление: Производственный цикл Цифры: несколько мест хранения документов одновременно у одной компании · пара десятков клиентов зависли на этапе «документы запрошены» · более сотни клиентов пострадали из-за устаревшего шаблона за один сезон Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Проверьте себя: сколько времени у вас займёт найти договор с клиентом трёхлетней давности? Если вы честно отвечаете «спрошу у Марины» — у вас нет архива, у вас есть Марина. И когда она уйдёт в отпуск или уволится, вы это почувствуете очень остро. Архив кажется скучной темой ровно до первого раза, когда документ нужен срочно — юристу, налоговой, клиенту с претензией. Тогда выясняется, что папки на диске раскладывал каждый по-своему, а половина файлов называется «скан_итог_финал_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/dostupy-sotrudnikov-audit/ Дата: 2026-06-28 Направление: Право и риски Цифры: 5 сотрудников без доступа к курсу · 500 000 ₽ мимо кассы за одну сделку · 30 ₽ за одноразовый SMS-номер Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Смотрите. Если вы прямо сейчас не назовёте поимённо, кто из бывших сотрудников ещё может зайти в ваши системы, — открытые доступы у вас уже есть. Не «возможно есть», а есть. Я говорю это не для страху: у себя я нашёл их ровно так — не искал, а наткнулся. Это не вопрос доверия к людям, это вопрос гигиены, и он всплывает в самый неподходящий момент. Разработчик делал обучающий курс для сотрудников. Настроил его под свою личную учётную запись — так было быстрее, не пришлось заводить служебную. Курс работал, люди учились. Проблему заметили только через несколько месяцев, когда понадобилось дать доступ пятерым новым сотрудникам. Оказалось, что весь курс висит на личном аккаунте одного человека, отследить прохождение невозможно, а выдать права кому-то ещё — тоже. Права доступа сотрудников в этой компании до того дня не сверяли ни разу: всё работало, значит, всё в порядке. Это типичная логика среднего бизнеса. Доступы раздают по мере необходимости, никто не ведёт реестр, а вопрос «кто и куда может зайти» всплывает либо при увольнении, либо после утечки. Если для компании из нескольких десятков человек и полутора десятков сервисов такой сверки не делали ни разу — это не гипотетический риск, это уже накопленный долг, который однажды предъявят к оплате. Разберу, где обычно ломается, как это автоматизировать и что реально стоит проверить, если аудит доступов вы ещё не делали. Как проверить права доступа сотрудников Права доступа сотрудников проверяют так: выгрузите список всех учётных записей во всех системах и сверьте его с актуальным штатным расписанием. Час работы. Дальше по каждой строке решение: оставить, сузить права, отозвать. Что находят чаще всего: активные доступы уволенных, права «на всякий случай» шире задачи, общие учётки без владельца и доступ через личные аккаунты в облаках. Регулярность важнее глубины — раз в квартал, с именем ответственного в чек-листе увольнения. Аудит начинается не с паролей, а с денег Считайте не риски в абстракции, а конкретно: что произойдёт с вашим бизнесом, если завтра эти данные окажутся у конкурента. Первая ошибка — считать, что аудит доступов это ИТ-задача. Я сам так считал несколько лет: есть системный администратор, значит, доступы — его зона ответственности. На практике это в первую очередь вопрос контроля над деньгами и обязательствами компании. А значит, это не задача админа, а задача того, кто отвечает за деньги. Руководитель отдела, доверенное лицо, заключил договор на консультационные услуги с клиентом компании на 500 000 ₽ — около 6% месячного оборота условной компании (9 млн ₽/мес при отделе из 8 менеджеров). Клиенту такие услуги компания не оказывает — их не должно было существовать. Деньги получены, чек не выписан, договор подписан на ИП сотрудника. Руководство прямо запрещало такую деятельность на совещаниях. Прецедент всё равно случился. В другой истории похожая схема: сотрудник продавал услуги мимо компании, клиенты звонили собственнику с претензией, думая, что покупали у него, а на деле получили услугу по отдельному договору. Политика против боковых заработков была объявлена заранее — это не остановило. Оба случая — не про пароли. Но именно доступ к клиентской базе, к контактам, к переписке с клиентом делает такую схему возможной. Аудит доступов отвечает на вопрос: кто физически может дотянуться до клиента и данных, минуя систему учёта. Если ответ — «почти любой сотрудник, у кого есть логин», проблема уже создана, осталось дождаться, когда ей воспользуются. Правило Доверие к сотруднику — не повод не проверять его доступы. Именно доверенные сотрудники наносят самый дорогой ущерб — у них больше прав и меньше контроля. Где чаще всего находятся дыры Идите по списку и отмечайте. Три места, где дыры находятся почти всегда. Я ни разу не видел компанию, где не сработало бы хотя бы одно, — и ваша вряд ли исключение. Личные аккаунты вместо служебных История с курсом на личном аккаунте — не редкость. То же самое встречается с ботами, интеграциями, автоматизацией отчётов: человек настраивает сервис под себя, потому что так проще завести доступ прямо сейчас. Через полгода он увольняется или уходит в отпуск, и никто не может зайти в систему, которая держит на себе часть операционки. Таблицы и документы с доступом «по ссылке» В одной компании обнаружили: множество таблиц с финансовой информацией и данными клиентов открыты для всех, у кого есть ссылка. Не для конкретных людей — для любого, кто ссылку получил. Собственница запросила аудит всех таблиц и удаление посторонних адресов из совместных документов. В другом случае конфиденциальная информация — кошельки, данные менеджеров, сведения о компаниях — оказалась в открытом JavaScript-файле на публичном сервере. Файл индексировали поисковики. То есть данные не украли — их выложили сами, по невнимательности при настройке. Доступ третьих лиц через внешний портал При аудите безопасности одной системы выяснилось: веб-хуки лежат без защиты, а внешний портал имеет доступ к данным клиентов. Архитектурная проблема доступа третьих лиц оказалась серьёзнее обычных ошибок в коде — приоритет работ пересмотрели, сначала закрывали дыры в доступе, потом занимались остальным. Что проверять Типичная ошибка Что сделать Учётные записи в сервисах Настроено на личный аккаунт сотрудника Перевести на служебную учётную запись компании Таблицы и документы Доступ «по ссылке» для всех Именной доступ, регулярная ревизия списка API-токены и ключи Хранятся в переписке, передаются во внешние каналы Хранить в коде, минимально необходимые права Доступ уволенных Закрывают по памяти, когда вспомнят Регламент: чек-лист отзыва прав в день увольнения Внешние порталы и веб-хуки Без защиты, доступ к данным клиентов Аудит перед любой доработкой продукта Права доступа сотрудников: по минимуму, а не «на всякий случай» Правило, которое сэкономит вам нервы: если сотрудник просит доступ «чтобы посмотреть» — дайте выгрузку, а не доступ. Ваше правило: доступ выдаётся под задачу и на срок задачи. Расширить проще, чем потом разбираться. При настройке интеграции через API-токены в одной из систем применили простое правило: чувствительные ссылки доступа хранятся только в коде, локальные файлы не передаются во внешние каналы, права выдаются минимально необходимые. Не «дам доступ ко всему, вдруг понадобится», а ровно к тому, что нужно для задачи. Похожий принцип сформулировали для совместных документов: «один человек — одна таблица». Это разграничение прав, которое предотвращает конфликт между автоматическим обновлением и ручным редактированием — и заодно снимает вопрос, кто именно испортил данные, если что-то пошло не так. Когда за таблицу отвечает один человек, аудит доступов превращается в простую сверку: у кого есть права редактирования, должно совпадать со списком тех, кто реально должен туда писать. С массовой выдачей доступов та же логика. При регистрации сотрудников в облачных системах внедрили процесс автоматизации получения смс-кодов через третий сервис — по 30 ₽ за код — и регламент учёта: каждый номер одноразовый, использование фиксируется. Это мелочь, но она превращает хаотичную раздачу доступов в процесс, который можно проверить постфактум, а не гадать, кто и когда что регистрировал. Закрытие доступов — не разовая акция Проверьте свой процесс увольнения: есть ли в нём пункт про отзыв доступов, и кто за него отвечает поимённо. Проблема с личной учёткой разработчика показала главное: доступы, привязанные к человеку, а не к роли, невозможно закрыть чисто. Когда сотрудник увольняется, компания либо теряет доступ к системе, либо вынуждена держать его учётку живой неопределённо долго — потому что переносить настройки некому и некогда. Отсюда правило, которое стоит закрепить регламентом, а не держать в голове у одного администратора: любой сервис, влияющий на операционку, настраивается на служебный аккаунт компании. Личный аккаунт — только временное решение с датой, когда его заменят на служебный. Вторая часть регламента — чек-лист на день увольнения. Не «через неделю кто-нибудь вспомнит», а список: какие сервисы, какие таблицы, какие мессенджеры, какие общие ящики. Без такого списка отзыв доступа держится на памяти руководителя, а память подводит именно в конфликтных увольнениях — когда цена ошибки выше всего. Отдельно стоит вопрос блокировки самой платформы, а не человека. При внедрении бота в мессенджер обнаружили: платформа может заблокировать номер при нестандартном использовании. Решение — завести отдельный тестовый номер для проверки, прежде чем выводить бота на рабочий канал. Логику продолжает подход, который использовали в другой команде: «мы работаем в коде, потому что единственный способ устоять при блокировке — это чтобы все файлы были у тебя, и ты не зависела от доступа к учётной записи». Аудит доступов должен отвечать и на этот вопрос: что случится с операционкой, если один сервис исчезнет или заблокирует конкретный аккаунт. ИИ-связка: автоматическая сверка доступов Ваша цель — чтобы список расхождений приходил сам, а не собирался руками раз в год под аудит. Ручная сверка «кто уволен — у кого остались права» работает, пока в компании небольшая команда и несколько сервисов. На полусотне людей и полутора десятках систем (CRM, облачные таблицы, боты, порталы) это уже задача для регулярного скрипта, а не для памяти HR-менеджера. Собирать всё вручную каждый квартал — дорого по времени и ненадёжно: список из полутора десятков вкладок никто не сверяет построчно два раза подряд. Конвейер простой: раз в неделю скрипт выгружает список активных сотрудников (из HR-таблицы или через API CRM — например, список пользователей amoCRM) и список выданных доступов (ведётся отделом в отдельном листе Google Sheets), сводит их в один JSON и отправляет дешёвой модели на классификацию расхождений. Результат падает в лист «Аномалии», критичные случаи — сразу уведомлением ответственному. Схема: HR-таблица + список доступов → Google Apps Script собирает JSON → запрос к LLM API → ответ пишется в лист «Аномалии» → high-risk строки триггерят уведомление в Telegram. Модель нужна дешёвая — задача не творческая, а классификационная: сопоставить статус сотрудника с датой последнего доступа и вернуть структурированный список. Гонять её на дорогой модели — переплата без пользы. Пример ответа модели: Так это выглядит уже не в JSON, а в самом рабочем листе, куда падает результат: Google Sheets — лист «Аномалии» Email Сервис Проблема Риск ivanov@gmail.com Telegram-бот CRM уволен 3 мес назад, доступ активен высокий petrova@company.ru Google Sheets: Финансы Q2 доступ по ссылке, не именной средний sidorov@company.ru Портал клиентов дубль прав с уволенным низкий Инженерная обвязка: скрипт крутится на Google Apps Script с триггером по расписанию раз в неделю, читает два листа (сотрудники, доступы), формирует JSON и обращается к LLM через HTTP-запрос. Результат пишется в третий лист «Аномалии» с меткой времени. Если сервис недоступен — три повторные попытки с паузой, при неудаче запись падает в лист «Ошибки» и уходит уведомление ответственному за доступы, а не молча теряется. Ключ к LLM API и токены к CRM хранятся в свойствах скрипта, а не в самом коде таблицы — тот же принцип «минимально необходимые права», что и в истории с API-токенами выше. Если данные о пользователях идут из Bitrix24 через вебхук, тот же принцип разбирал я в статье про то, как CRM врёт с датами — прежде чем строить на вебхуке аудит доступов, стоит убедиться, что сами даты и статусы в CRM не съезжают. Разница в трудозатратах между ручным и автоматическим вариантом наглядно видна на диаграмме ниже. Ручная сверка всех сервисов (раз в квартал) 10 ч Поддержка двух листов для скрипта ~20 мин / неделя Проверка листа «Аномалии» человеком ~15 мин / неделя Автоматический прогон скрипта ~5 мин / неделя Цифры в диаграмме — оценка по типовым трудозатратам, не хронометраж. Во сколько раз автоматическая сверка выгоднее Прикиньте на своей численности: сколько человеко-часов уходит у вас на одну ручную сверку и сколько раз в год вы её делаете. Настройка автоматической сверки — около 8–10 часов, эксплуатация — около 300 ₽/мес на токены модели плюс около 35 минут в неделю ответственного, а эффект — окно, в котором доступ уволенного сотрудника или таблица «по ссылке» остаются незамеченными, сокращается с трёх месяцев при квартальной ручной сверке до одной недели (оценка). Формула для ручной сверки простая: число сервисов × среднее время проверки одного сервиса = трудозатраты одного цикла. На сбор списка активных сотрудников, проход по сервису и сверку прав обычно уходит 30–40 минут на сервис. Для 15 сервисов это 15 × 40 минут ≈ 10 часов — та же цифра, что на графике выше. Один квартальный проход стоит компании как 10 часов работы ответственного, а за год из четырёх проходов — около 40 часов той же работы. Если у вас 5 сервисов и меньше сотрудников, время пропорционально меньше — например, около 3 часов на проход: подставьте своё число сервисов в ту же формулу. Автоматическая сверка требует разовой настройки скрипта, промпта и тестового прогона на реальных данных — это те самые 8–10 часов из оценки выше, сопоставимые с одним ручным квартальным проходом. Дальше скрипт бегает сам раз в неделю, но кто-то должен поддерживать актуальность двух исходных листов (около 20 минут в неделю) и просматривать лист «Аномалии» (около 15 минут в неделю) — вместе это около 30 часов в год, заметно меньше 40 часов на четыре ручных прохода. При ставке около 1000 ₽/час эта разница — порядка 10 000 ₽/год, то есть по чистой экономии часов автоматизация окупается небыстро: настоящая выгода не в этих деньгах, а в частоте проверки. Показатель Ручная сверка (раз в квартал) Автоматическая сверка (раз в неделю) Частота проверки 4 раза в год 52 раза в год Трудозатраты в год ≈ 40 ч ≈ 30 ч + разово 8–10 ч на внедрение Затраты первого года относительно ручной сверки база для сравнения сопоставимы или чуть выше из-за внедрения; со второго года — заметно ниже Сколько доступ может «висеть» незамеченным до 3 месяцев до 1 недели По трудозатратам автоматизация в первый год почти не выигрывает у ручной сверки — экономия становится заметной со второго года, когда разовые часы на внедрение уже не в счёте. Настоящий эффект не в часах, а в частоте: тот же объём усилий покупает проверку раз в неделю вместо раза в квартал, а значит, доступ уволенного сотрудника или таблица «по ссылке» не успевают провисеть месяцами до следующей ревизии. На диаграмме — как меняется сама частота проверки. 4 раза до 52 раза после Было — ручная сверка раз в квартал, 4 прохода в год. Стало — автоматический прогон раз в неделю, 52 прохода в год. Что мы не считаем эффектом: сами ~10 000 ₽/год экономии на трудозатратах — не главная выгода автоматизации, это фон. Мы также не считаем эффектом аудита сам разовый случай на 500 000 ₽, разобранный ниже, — это иллюстрация масштаба риска, а не гарантированная ежемесячная экономия. Эффект самого аудита считать напрямую в деньгах сложнее — он не приносит выручку, он снимает риск. Но масштаб риска можно проиллюстрировать конкретным случаем: доверенный сотрудник заключил договор в обход компании на 500 000 ₽ — около 6% месячного оборота условной компании, пользуясь тем, что имел прямой доступ к клиенту без промежуточного контроля. Аудит доступов сам по себе не остановил бы умышленное мошенничество — это отдельный вопрос доверия и внутреннего контроля, и сдвиг здесь дала бы связка регламента доступа и общего контроля, а не один только аудит. Но регулярная сверка убирает техническую возможность делать это месяцами незаметно: если доступ к клиентской базе логируется и проверяется хотя бы раз в неделю, а не раз в квартал или никогда, аномальная активность видна раньше, а не тогда, когда клиент уже позвонил с претензией. Где ломается Регламент по доступам работает, только если его проверяют регулярно, а не пишут один раз после инцидента. Автоматическая сверка снимает часть нагрузки, но не заменяет человека, который читает лист «Аномалии» и реально закрывает найденные доступы — если этот шаг выпадает, скрипт превращается в красивый отчёт, который никто не открывает. Куда уходят ваши данные Три канала, о которых обычно не думают: облачные диски, личные аккаунты сотрудников и нейросети. Отдельный слой риска — данные, которые уходят за пределы компании: в облачные таблицы с доступом по ссылке, во внешние порталы, в ИИ-сервисы. Требования к персональным данным в целом ужесточаются не только в России: в разных юрисдикциях обсуждают более жёсткие правила работы с персональными данными через ИИ-сервисы и отдельно — с чувствительными категориями данных вроде расовой или этнической принадлежности. Формулировки и статус таких инициатив стоит уточнять по конкретной стране перед принятием решений, но общий вектор понятен уже сейчас: вопрос «кто и куда отправляет данные клиента» — не только вопрос внутреннего контроля, но и растущий юридический риск. Прежде чем встраивать ИИ в работу с клиентскими данными, стоит понять, что вообще можно отправлять во внешние модели, а что нет — это отдельная тема, я разбирал её в статье про персональные данные и нейросети . Если в компании уже есть автоматизация, которая работает без постоянного присмотра, риски доступов там множатся быстрее обычного — см. текст про автоматизацию, которая требует контроля . С чего начать вам в понедельник Один час, один список, одно решение по каждой строке. Выгрузить список всех сервисов, где хранятся данные клиентов, финансов или переписка с клиентом. По каждому сервису проверить: аккаунт служебный или личный. Личные — в план перевода на служебные, с датой. Пройтись по облачным таблицам и документам, найти доступ «по ссылке» вместо именного и закрыть. Составить чек-лист отзыва доступов на день увольнения: сервисы, таблицы, мессенджеры, общие ящики — списком, а не по памяти. Назначить одного ответственного за квартальную ревизию доступов — с датой в календаре, а не «когда-нибудь». Если сервисов больше десяти — запланировать автоматическую сверку по модели из этой статьи вместо ручной раз в квартал. Ревизия прав доступа сотрудников не заканчивается один раз. Она превращается в привычку: раз в квартал пройтись по списку сервисов, сверить, кто там реально должен быть, и закрыть то, что осталось от прошлых сотрудников, прошлых экспериментов и прошлой спешки. И вот что здесь важнее любого чек-листа. Держать в голове карту «кто куда может дотянуться» — это управленческий навык, такой же базовый, как чтение отчёта о деньгах. Руководитель, который за минуту скажет, кто имеет доступ к клиентской базе и к платежам, управляет бизнесом. Тот, кто не скажет, управляет ощущением контроля. Разница проявляется не каждый день, а один раз — и сразу дорого. Если вы за минуту такую карту по своей компании не соберёте — навыка пока нет. Сделайте на этой неделе: выгрузите список всех, у кого есть доступ к вашим системам, и сверьте с актуальным штатным расписанием. Час работы, и результат обычно неприятно удивляет. Как поставить регулярный аудит доступов без ручной сверки — в бесплатном курсе . Проверьте свою ситуацию прямо на этой неделе — и если найдёте активные доступы у бывших сотрудников, не устраивайте разбор полётов. Просто закройте и заведите регулярную сверку: это системная дыра, а не чья-то халатность. И ещё одно: заведите отдельную строку в вашем процессе увольнения — «доступы отозваны, проверил такой-то». Одна строка, а закрывает целый класс рисков. Как это было у нас Мы делали первую сверку доступов через полтора года после запуска — и нашли активные учётки людей, которые не работали у нас по восемь месяцев. Никакого злого умысла: просто увольнение шло через кадры, а доступы жили у нас в ИТ, и никто не соединил эти два процесса. Я тогда не стал искать виноватого — сама схема была дырявой. Мне было неприятно другое: полтора года я подписывал документы об увольнении и ни разу не спросил, закрыты ли доступы. Моя недоработка, не кадровиков. Мы связали два процесса одной строкой в чек-листе увольнения и завели ежеквартальную сверку. С тех пор находки единичные и закрываются в тот же день. Сделайте сверку на этой неделе — и заведите следующую на квартал вперёд прямо в календаре. Как автоматизировать — в бесплатном курсе . Мы нашли у себя доступы людей, которые не работали восемь месяцев, — и после этого сверка стала ежеквартальной. Ваша первая сверка, скорее всего, покажет то же самое. ## Прогноз продаж, которому можно верить: воронка вместо ощущений URL: https://davidgerstein.pro/blog/prognoz-prodazh-po-voronke/ Дата: 2026-06-25 Направление: Продажи Цифры: план выполнен на 80% · конверсия 14% против плана 23% · встреча→договор 22% Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Как считать прогноз продаж по воронке Прогноз продаж по воронке — это произведение: число лидов × конверсия лид→встреча × конверсия встреча→договор × конверсия договор→оплата × средний чек. Не сумма ожиданий менеджеров, а арифметика по этапам, которую вы можете проверить строку за строкой. Если у вас прогноз собирается из ответов на вопрос «сколько закроешь в этом месяце», отклонение вы увидите на тридцатый день. Расчёт по этапам показывает его на пятый: в одной такой неделе план по деньгам выполнен на 80%, потому что конверсия просела до 14% против плановых 23% — и просела ровно на одном переходе, встреча→договор. Как вы сейчас отвечаете на вопрос «сколько закроем в этом месяце»? Если ответ собирается из ощущений менеджеров — вы не прогнозируете, вы гадаете и потом объясняете, почему не сбылось. Нормальный прогноз собирается из воронки: сколько сделок на каждом этапе, какая конверсия дальше, сколько времени занимает переход. Это арифметика, которую вы можете проверить, а не вера в оптимизм отдела. Неделя 14–20 мая. План по деньгам выполнен на 80%. Закрыли 7 сделок из 16 запланированных. Конверсия в продажу — 14% при плане 23%. Конверсия во встречу нормальная, 55%, а вот из встречи в договор — только 22%. Руководитель отдела продаж прямым текстом: «Тут уже мне становится страшно, я начинаю переживать конкретно». За недостающими 20% плана стоят не абстрактные проценты, а конкретные девять сделок, которые должны были закрыться и не закрылись. Это и есть прогноз продаж по воронке в чистом виде. Не «в этом месяце должны сделать миллион, потому что обычно делаем», а разложенная по этапам математика: сколько лидов, какая конверсия на каждом шаге, сколько денег получится на выходе. Когда цифры разложены так, страх появляется на пятый день недели, а не на тридцатый день месяца — когда уже поздно что-то менять. Дальше в статье — как считать этот прогноз руками, какой промпт можно скопировать для еженедельной диагностики узкого места, во сколько обходится зависшая сделка и где эта система обычно ломается. Прогноз продаж по воронке против прогноза «на глазок» Сравните два подхода на своём примере — вы наверняка узнаете первый. Классический прогноз продаж строится так: руководитель спрашивает у менеджеров, сколько они закроют в этом месяце, складывает ответы и докладывает наверх. Это работает, пока воронка стабильна. Как только что-то меняется — состав отдела, источник лидов, сезон — прогноз «на глазок» начинает врать, и врёт он всегда в оптимистичную сторону, потому что менеджер отвечает на вопрос «сколько ты хочешь закрыть», а не «сколько у тебя реально в пайплайне со сроком». В одной компании отдел из нескольких человек — руководитель, его напарник и ещё один менеджер — стабильно давал продажи выше, чем тот же отдел после расширения примерно вдвое. Причина не в квалификации новых людей. Причина в том, что лидов на каждого стало больше, а внимания к каждому лиду — меньше. Конверсия просела именно потому, что никто не считал её по этапам в моменте: рост штата выглядел как рост мощности, а на деле размывал воронку. После внедрения контроля по этапам конверсия начала расти на процентный пункт в месяц — не рывком, а постепенно, потому что причину нашли не на глаз, а по разбивке. Оговорюсь сразу: этот рост дал комплекс мер — контроль конверсии, разбор застрявших сделок, дисциплина по звонкам — а не один только факт появления таблицы. Ниже, в разделе про экономику, я оцениваю вклад именно инструмента прогноза отдельно от остальных мер. Правило Прогноз, который не разложен на этапы воронки, — это не прогноз, а надежда. Надежда не масштабируется вместе с отделом. Конверсия по этапам: где именно теряются ваши деньги Посчитайте свою конверсию по каждому переходу. Почти наверняка вы найдёте один этап, где теряется больше половины, — и почти наверняка это будет не тот этап, на который вы грешили. Отдельная цифра «конверсия 25%» ничего не говорит о том, что делать. Разбивка по этапам — говорит. В майском примере разница между планом и фактом была не в количестве лидов и не во встречах — там всё было в норме. Проблема сидела на переходе от встречи к договору: 55% встреч состоялось, но только 22% из них закрылись договором. Значит причину нужно искать не в лидогенерации и не в графике встреч, а в том, что происходит на самой встрече и сразу после неё. На диаграмме ниже — конверсия по каждому этапу воронки за неделю 14–20 мая в сравнении с плановой конверсией лид→продажа. Этап воронки План Факт (неделя 14–20 мая) Лид → встреча — 55% (49 встреч) Встреча → договор 23% 22% Лид → продажа 23% 14% Средний чек 10% 13,5% Закрыто сделок 16 7 Лид → встреча 55% Встреча → договор 22% Лид → продажа, факт 14% Лид → продажа, план 23% Подставим формулу из начала статьи в цифры недели 14–20 мая, где в источнике зафиксирован не весь набор величин: 49 встреч при конверсии лид→встреча 55% означают около 89 лидов в работе (49 ÷ 0,55 — оценка, точное число лидов не зафиксировано). Из 49 встреч конверсия 22% даёт около 11 договоров (49 × 0,22). Но оплатой закрыли только 7 сделок — то есть ещё 4 договора из 11 за неделю не дошли до денег: они либо повиснут на следующей неделе, либо уйдут в отказ. Без разбивки по этапам эта картина не видна вообще — на выходе была бы одна цифра «7 из 16» без понимания, где именно теряются четыре уже подписанных договора. Любопытная деталь: средний чек выше плана. Это значит, менеджеры не проседают в презентации ценности дорогих пакетов — они проседают именно на переходе к подписанию. По другому кейсу той же компании: конверсия 25–28% держалась три месяца подряд, и руководитель прямо сказал — если так продолжится, меняю структуру мотивации и все рекомендации отдаю отделу с конверсией 80%. Жёстко, но честно: он смотрел не на факт продаж, а на то, где именно теряется процент. Ещё пример того, как этап-специфичная причина маскируется под «плохой месяц»: отдел отвлёкся на апсейл по одному направлению и почти забросил холодные звонки. Вместо плановых 60+ звонков новым контактам сделали в разы меньше. При этом повторное касание по нескольким десяткам тёплых лидов месячной давности дало несколько рекомендаций. Вывод руководителя: одного звонка недостаточно, нужна регулярная работа с базой. Без разбивки по этапам этот вывод было бы невозможно сделать — просто увидели бы «продажи ниже плана» и не поняли почему. Отдельно стоит случай, когда конверсия отдела внезапно упала до 30% при ожидаемых 50%. Разбор занял не неделю, а около пяти минут — но не потому, что кто-то угадал причину, а потому, что дашборд уже был разбит не только по этапам, но и по источникам сделок. Первая же строка среза по источникам показала: просадка сосредоточена в одном канале холодных лидов, где менеджеры физически перестали успевать доводить контакт до встречи — остальные источники держали плановую конверсию. Без такой разбивки эту же причину пришлось бы искать вручную, поднимая карточки по каждому менеджеру — отсюда и оценка «неделя ручного разбора» в таблице ниже. О том, как теряются деньги между маркетингом и продажами на более раннем этапе — в статье «Лиды есть, а продаж нет» . Дашборд вместо памяти: механика по шагам Соберёте это за вечер, если у вас есть выгрузка из CRM. Никакой BI-системы покупать не нужно — начните с таблицы, а инструмент выберете, когда поймёте, что именно смотрите каждую неделю. Прогноз по воронке требует данных, которые не устаревают за неделю. Разовый отчёт для планёрки — это фотография прошлого. Нужен инструмент, который обновляется постоянно и показывает не только «сколько продали», а «что застряло и почему». Механика такая: Что → сырые данные о сделках (этап, дата создания, дата последнего движения, менеджер, сумма, источник) забираются из CRM. Чем → Google Apps Script или прямой вебхук CRM по расписанию складывает срез в таблицу, где считаются конверсии по этапам, разбивка по источникам и дни без движения. Куда → результат попадает на дашборд с интеграцией «клик по строке → карточка сделки», чтобы не искать её отдельно. Кто и когда смотрит → руководитель — ежедневно по светофору, собственник — на еженедельном разборе плана/факта. В одной компании собрали именно такой дашборд: pipeline по каждому менеджеру, конверсия из договора в оплату, дата последнего контакта, источник сделки. Детализация по месяцам показывает заброшенные сделки без касаний ещё до того, как они превратятся в потерянный доход. Потом руководитель заказал динамический отчёт по воронке с обновлением каждый час. Для каждого менеджера он показывает клиента, текущий статус, дату создания сделки, число дней в статусе и светофор — зелёный, жёлтый, красный — на основе нормативных сроков по стадиям. Идея простая: если сделка на этапе «договор» висит дольше нормы, система красит её красным раньше, чем это заметит человек на планёрке. Вот как такой отчёт выглядит на практике для недели 14–20 мая: Воронка · неделя 14–20 мая 80% выполнение плана 14% лид→продажа (план 23%) 7 / 16 закрыто сделок Менеджер Этап Дней в статусе Статус Иванов Договор 12 просрочено Петров Встреча 2 норма Сидорова Оплата 1 норма Похожая логика — в отдельном дашборде по договорам: имя менеджера, имя клиента, сумма, дата выставления счёта, была ли встреча. Это позволяет видеть закономерность — сделки после встречи закрываются иначе, чем без неё — и дожимать конкретные неоплаченные договоры адресно, а не общим напоминанием «оплатите, пожалуйста». Про системный контроль оплат — в статье «Дебиторка растёт: контроль, который не зависит от памяти людей» . В итоге вместо двух-трёх разрозненных отчётов получился один интерактивный портал: все договоры по источникам, пайплайн по месяцам, оплаты и выставленные счета по каждому сотруднику. Логика владельца была простой: «Чем мне создавать два отчёта? Мне проще создать один» — и именно на этом портале был найден за пять минут кейс с падением конверсии до 30%, описанный выше. Показатель До дашборда С дашбордом Время поиска причины отклонения конверсии до недели ручного разбора карточек (оценка автора кейса, по трудозатратам на выгрузку и сверку вручную) ≈ 5 минут — зафиксировано в кейсе с падением конверсии до 30% при плане 50%, когда причина была видна в первой строке среза по источникам Время руководителя на сведение отчётов в неделю несколько часов (оценка автора кейса: выгрузка из CRM + сверка в трёх таблицах + формулы вручную) ≈ 0 — автосбор по расписанию, ручная работа только на чтение готового среза Момент обнаружения зависшей сделки на планёрке или после потери клиента в день превышения нормативного срока по стадии (светофор) Обе оценки в левой колонке — не измерения секундомером, а прикидка руководителя по памяти о том, сколько времени уходило раньше. Это честная оценка, а не точный хронометраж, и в статье она помечена как оценка намеренно — чтобы не выдавать прикидку за измеренный факт. ИИ-связка: диагностика узкого места Дальше — постановка, которую вы можете взять как есть и подставить свою выгрузку. Машина найдёт этап, где стоит очередь, и покажет, на чём именно вы теряете. Дашборд показывает цифры. Но кто-то ещё должен каждую неделю посмотреть на все строки по всем менеджерам и сформулировать словами, где именно проблема. Это ручная работа, и её можно передать дешёвой модели — задача чисто структурная: сравнить план и факт по этапам, найти максимальное отклонение и сформулировать причину без домыслов. Творческая модель здесь не нужна и дорогая тоже не нужна — нужна дисциплинированная, которая не выдумывает лишнего. Схема конвейера: CRM (amoCRM API или Bitrix24-вебхук) → почасовой снимок сделок в Google Sheets → раз в неделю сборка JSON по каждому менеджеру → запрос к дешёвой модели (класс gpt-4o-mini или аналог) → ответ пишется обратно в таблицу и дублируется в чат руководителя. Входные данные на менеджера выглядят так — это не гипотетический пример, а структура, которую реально собирает Google Apps Script по расписанию раз в неделю: Пример ответа модели на входные данные выше: Обратите внимание: модель не сказала «менеджер плохо работает» — она указала конкретную сделку и конкретное отклонение. Это и есть разница между диагностикой и оценочным суждением. Дальше решение принимает человек: разговор с менеджером, звонок клиенту, пересмотр скрипта — но повестку для этого разговора формирует не память руководителя, а цифра. Инженерная обвязка, без которой промпт ломается на третьей неделе: Расписание запуска — раз в неделю, в фиксированный день и час (например, понедельник 8:00), до планёрки, а не после. Если в срезе за неделю у менеджера меньше 5 сделок на этапе — модель должна писать «недостаточно данных», а не достраивать вывод по единичному случаю. Это правило зашито в промпт отдельным пунктом, а не оставлено на усмотрение модели. Сырой ответ модели логируется отдельной строкой рядом с итоговым JSON — если через месяц вывод покажется странным, можно проверить, на каких именно цифрах он основан. Числовые поля в ответе (deviation_pp, stuck_deals_count) валидируются скриптом перед записью в таблицу: если модель вернула не число или пустое поле — строка помечается для ручной проверки, а не публикуется как есть. Стоимость такого прогона на класс моделей gpt-4o-mini при отделе из нескольких менеджеров и одном запуске в неделю — предмет отдельного разговора: подробный разбор счетов за ИИ в инфраструктуре продаж — в статье про контроль качества звонков без ОКК , там похожая экономика на других объёмах. Экономика: во сколько обходится ваша зависшая сделка Возьмите свой средний чек и умножьте на число сделок, которые стоят без движения дольше двух недель. Это ваш замороженный оборот — деньги, которые уже почти ваши. Возьмём легендированный пример на профиле условной компании из этого разбора: сервисная компания, отдел из 12 менеджеров, оборот ~6 млн ₽ в месяц, средний чек — 500 тыс. ₽. При таких вводных отдел закрывает около 12 договоров в месяц (6 000 000 ₽ ÷ 500 000 ₽ — оценка). Возьмём консервативную долю зависающих на этапе «договор→оплата» сделок — 10% от закрытых договоров. В разобранном выше примере недели эта доля была выше — 4 зависших договора из 11, то есть 36% — так что 10% в этом расчёте заниженная, а не завышенная оценка. 10% от 12 договоров в месяц — это около 1 зависшей сделки (оценка). При среднем чеке 500 тыс. ₽ риск не дойти до оплаты по этой сделке — около 500 тыс. ₽ в месяц (оценка, верхняя граница: она справедлива, если сделка теряется полностью, а не переезжает на следующий месяц — на практике часть таких сделок всё же закрывается позже, так что реальный риск обычно ниже этой цифры). Отдельно — время руководителя. Ручной поиск причины по каждой зависшей сделке (поднять карточку, посмотреть переписку, позвонить менеджеру) занимает примерно час (оценка). На одну зависшую сделку в месяц это около 1 000 ₽ по ставке ~1 000 ₽/час (оценка) — сумма, которая не идёт ни в какое сравнение с риском 500 тыс. ₽ по недополученной выручке. Именно это время дашборд с автоматическим светофором и еженедельной ИИ-диагностикой освобождает почти полностью — вместо часа на сделку остаётся 5–10 минут на проверку уже готового вывода модели. Важная оговорка: рост конверсии на процентный пункт в месяц, о котором шла речь в начале статьи, — результат комплекса мер (контроль, разбор сделок, дисциплина по звонкам), а не одного только дашборда. Вклад именно инструмента прогноза в этом комплексе — сокращение времени на обнаружение проблемы с недели до минут, что и переводится в риск около 500 тыс. ₽ в месяц (оценка на легендированном профиле), выявленный на пятый день, а не в конце месяца, когда план уже сорван и деньги не вернуть. Где это ломается Три места, в которых ваш прогноз перестанет работать. Первые два вы почините за день, третье потребует разговора с командой. Ловушка данных Дашборд честен ровно настолько, насколько честна CRM. Если менеджеры двигают сделки по этапам с задержкой в 2–3 дня «для порядка», конверсия по этапам будет искажена системно, а не случайно — и разбор по источникам покажет ложную причину. Перед тем как доверять прогнозу по воронке, стоит проверить, не врут ли сами даты в CRM: разбор похожих искажений — в статье про сдвиг дат в Битрикс24 . Риск ИИ-диагностики Модель без жёстких правил в промпте начинает достраивать причины там, где их нет в данных — особенно если у менеджера на этапе меньше 5 сделок за неделю. Решение не в более умной модели, а в явном запрете достраивать вывод при нехватке данных прямо в тексте промпта, как это сделано в примере выше. Ловушка долгоживущих сделок Если в воронке есть клиенты, которые стоят без движения полтора года (специфический тип контрактов, разовые долгие случаи), они искажают среднюю конверсию и нормативные сроки по стадиям. Их нужно выносить в отдельную воронку до расчёта прогноза, а не усреднять вместе с обычным циклом сделки. Чек-лист понедельника Разложить план недели на этапы воронки: лид→встреча, встреча→договор, договор→оплата — а не одну цифру «план по деньгам». Свериться с фактом за прошлую неделю по каждому этапу отдельно, а не только по итоговой сумме продаж. Проверить разбивку по источникам сделок — просадка в одном канале маскируется нормальной средней конверсией по отделу. Выгрузить список сделок, которые дольше нормы висят на своём этапе (светофор красный/жёлтый), и разобрать топ-3 из них до планёрки. Если используется ИИ-диагностика — проверить, не помечены ли строки «недостаточно данных»: это сигнал, что в CRM просела дисциплина внесения данных, а не что всё в порядке. Отдельно вынести долгоживущие нетипичные сделки в отдельную воронку, чтобы они не искажали средние показатели. Прогноз по воронке не избавляет от плохих недель. Он избавляет от неожиданных плохих недель. Разница между «мы недобрали план и уже знаем почему» и «мы недобрали план и понятия не имеем почему» — это разница между управляемым отделом продаж и отделом, который живёт от отчёта к отчёту. Цифры за 14–20 мая некрасивые. Но они были видны на пятый день, а не на тридцатый — и это единственное, что даёт шанс что-то успеть исправить в текущем месяце, а не только сделать выводы для следующего. И ещё одно, без чего таблица не приживётся. Разложить план на этапы и раз в неделю сверять с фактом — это управленческий навык, такой же, как чтение отчёта о прибылях или разбор рекламации. Он ставится теми же понедельниками, что и любой другой: первые три раза уходит час, дальше двадцать минут, а через месяц вы начинаете замечать провал раньше, чем его замечает сам отдел продаж. Что сделать в понедельник: выгрузите сделки за квартал и посчитайте конверсию каждого перехода. Одна таблица, час работы. После неё разговор с отделом продаж перестанет быть спором мнений — вы будете обсуждать конкретный этап, где стоит очередь. Как собрать прогноз, который пересчитывается сам и предупреждает о провале заранее, — в бесплатном курсе . Мой опыт: где я обжёгся Первый наш прогноз по воронке был красивым и неверным. Я взял среднюю конверсию по всем сделкам сразу — и получил цифру, которая не сбывалась ни разу. Оказалось, что конверсия у разных источников отличается в три раза, и усреднять их было ошибкой: половина прогноза строилась на лидах, которые не конвертировались почти никогда. Мы разделили воронку по источникам, и прогноз начал попадать. Заодно выяснилось, что один канал стабильно даёт мусор, — его закрыли, и это решение окупило всю затею с прогнозированием. Так что если ваш прогноз не сбывается — прежде чем винить менеджеров, проверьте, не усредняете ли вы то, что усреднять нельзя. ## Регламент работы отдела: от полки к инструменту URL: https://davidgerstein.pro/blog/reglamenty-kotorye-rabotayut/ Дата: 2026-06-21 Направление: Операционное управление Цифры: потери без регламента различаются в разных сценариях на порядок Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Сколько регламентов написано в вашей компании и сколько из них выполняется? Разница между этими числами — цена вашей работы по наведению порядка, которая ушла в стол. Регламент не работает не потому, что люди плохие. Он не работает, потому что написан для проверяющего, а не для исполнителя: длинный, общий и не отвечающий на вопрос «что делать в четверг в три часа». Финансовый сотрудник компании жаловался, что не успевает с основной работой. Коллеги дёргали его весь день — срочные оплаты, вопросы по счетам, «а вы уже перевели?». Он начал сомневаться в собственной компетентности. Руководитель разбирался не с человеком, а с расписанием: в рабочем дне не было выделенного окна на платежи. Ввели правило: обработка оплат — с 10 до 11, всё остальное время закрыто для таких вопросов. Проблема исчезла не потому, что сотрудник стал работать быстрее, а потому что в компании наконец появился регламент, которого раньше не существовало вообще — только ощущение, что «все всё знают». Цену такого отсутствия регламента посчитать просто: часы отвлечения в день × ставка за час × число рабочих дней в месяце = потери в месяц. Если сотрудник тратит условно час в день на реакцию на чужие срочные вопросы вместо плановой работы, при ставке ~1000 ₽/час (оценка) и 22 рабочих днях в месяце это даёт около 22 000 ₽ потерь рабочего времени одного человека в месяц (оценка). При этом закрыть проблему часто можно не наймом второго специалиста, а одним правилом в календаре. Как составить регламент работы отдела, который будут соблюдать Регламент работы отдела соблюдают, когда он привязан к конкретному времени или точке в процессе и описывает одно повторяющееся действие, а не обязанность вообще. Закрепляется он не с первого раза: рабочая формула — три итерации, «неправильно — неправильно — правильно», и только после третьей удачной попытки действие фиксируют инструкцией. Пока правила нет, компания платит за него временем и выручкой. Час отвлечений в день на одном сотруднике при ставке ~1000 ₽/час и 22 рабочих днях — около 22 000 ₽ в месяц (оценка). В документообороте счёт другой: 10% сделок, зависших из-за отсутствия правила очерёдности, в отделе с оборотом 9 млн ₽ дают риск ≈900 000 ₽ в месяц (оценка). Почему документ не работает без расписания Мы написали десятки регламентов, прежде чем я понял простую вещь: документ без встроенной проверки — это пожелание. Никто не саботирует, просто у всех есть работа поважнее, чем помнить, что там написано. Кейс с финансистом — частный случай общей проблемы: у большинства перегруженных сотрудников нет не задач, а структуры дня. Задачи прилетают асинхронно, каждый коллега считает свой запрос срочным, и человек весь день переключается между чужими приоритетами вместо своих. Формально должностная инструкция у него есть. Реально — нет ни одного протокола, который бы говорил: «в это время — вот это, в остальное — недоступен». То же самое звучит в жалобе руководителя маркетинга, который тратит колоссальное время на ручное заполнение отчётов и таблиц в разных местах и не может выделить час на аналитику без переключений: «Я бы хотел погружённо работать: взял задачу, погрузился, час ей занимался. А в большинстве случаев, если 15 минут удалось поработать — это невероятная удача». Проблема здесь не в мотивации и не в компетенциях. Проблема в отсутствии регламента, который бы защищал время на глубокую работу так же, как защищает окно 10–11 у финансиста. Правило Регламент, который не привязан к конкретному времени и не защищает конкретный блок в календаре, остаётся декларацией. Работает только то расписание, которое коллеги физически не могут нарушить, потому что окно закрыто в системе или объявлено вслух при всех. Механика: от сбоя до инструкции Ваш ориентир: новый человек должен сделать правильно, не спрашивая никого. Если для выполнения нужны устные пояснения — регламент не готов. В одной из компаний разложили появление регламента на понятную последовательность действий. Дальше — шесть шагов, которые можно повторить с любой командой. Фиксация сбоя. Руководитель или сам сотрудник замечает повторяющуюся проблему — перебивания, разные цифры в отчётах, зависшую задачу. Источник — жалоба, наблюдение на планёрке, разбор конкретного провала. Первая попытка действия без инструкции. Сотрудник выполняет задачу как умеет. Результат почти всегда неидеальный — это ожидаемо, а не повод для штрафа. Фиксация действия. Каждое новое действие либо документируется текстом, либо записывается на диктофон для расшифровки. Формат неважен — важно, что попытка не исчезает бесследно. Повторение и разбор ошибок. Формула трёх итераций: неправильно — неправильно — правильно. После третьего раза, когда результат устраивает, действие проверяют ещё раз на воспроизводимость. Закрепление инструкцией. Если третья попытка сработала — действие фиксируют как регламент и не проверяют его вручную каждый раз заново. Дальше его соблюдение можно передать на автоматическую проверку. Точка контроля. Кто-то — руководитель, проект-менеджер, бот — периодически сверяет, что регламент всё ещё выполняется так, как закреплён, а не «как удобнее сегодня». Формула трёх итераций работает, потому что она не пытается угадать идеальный процесс заранее. Она фиксирует то, что реально произошло, и делает это правилом. Заранее написанная инструкция почти всегда описывает идеальный процесс, которого не существует. Когда данные и роли расходятся У нас был случай, когда регламент требовал заполнять поле, которого в системе уже не существовало. Полгода люди честно пытались его найти и тихо считали документ бредом — и были правы. Самая наглядная иллюстрация отсутствия стандартизации — попытка выгрузить список клиентов одного региона из системы и получить три разных числа. Общий фильтр по региону 80 Фильтр менеджера А 22 Фильтр менеджера Б 17 На диаграмме — три результата одной и той же выгрузки клиентов одного региона: они расходятся почти в четыре раза. Это не ошибка одного сотрудника — это следствие того, что данные хранятся вразнобой: разные фильтры, разные представления воронки, разные привычки у разных менеджеров. Регламента «как считать клиентов» просто не существовало, поэтому каждый посчитал по-своему, и все три ответа были по-своему правильными для того, кто их получил. О том, как система хранения данных сама по себе может искажать цифры ещё до того, как их кто-то посчитал вручную, я разбирал в статье про сдвиг дат в Битрикс24 . Похожая история — с производственным циклом в консультационном бизнесе. Компания разделила процесс на два блока: «Производство» (интервью, сбор документов, структура) и «Упаковка» (редактура, вёрстка, согласование, финальный выпуск). За оба блока отвечает один проект-менеджер, но подрядчики и сроки — разные. Персональный менеджер работает лицом к клиенту, проект-менеджер отвечает за качество продукта. Это и есть стандартизация: не единая инструкция «на всё», а чёткая граница между двумя ролями с разной ответственностью. Без регламента С регламентом Финансист прерывается весь день, не успевает с основной работой Окно 10–11 закрыто для платежей, остальное время — на основные задачи Три выгрузки клиентов дают три разных числа Единый источник данных и единый способ подсчёта Действие делают заново каждый раз с нуля После трёх итераций действие закреплено инструкцией и не пересматривается вручную Один человек одновременно обучает новичков и ведёт опытных продавцов Роли разделены: один занимается только стажёрами, другой — менеджерами Разделение ролей встречается и в отделе продаж: попытка масштабировать команду через групповой набор стажёров провалилась, потому что менеджер не мог одновременно обучать новичков и управлять опытными продавцами. Решение оказалось не в найме ещё одного менеджера «вообще», а в разделении зон ответственности: обучение — отдельная роль, управление опытной командой — отдельная. Это тоже регламент, просто выраженный не текстом, а структурой должностей. Где регламент подменяют профилем личности Обратный пример — компания долго не могла сформулировать требования к новой ключевой роли, продакшн-менеджеру для запуска проекта. Обсуждение шло больше часа: разбирали личные качества кандидатов, но так и не сформулировали, что конкретно человек будет делать на этой должности. Если обсуждение вакансии сводится к «нам нужен инициативный, ответственный человек», а не к перечню операций и точек контроля, регламента для этой роли не появится вообще — ни на бумаге, ни в реальности. Ошибка воспроизводится потом на каждом собеседовании и каждой аттестации, потому что сравнивать не с чем. ИИ-связка: проверка соблюдения без ручного контроля Здесь вы получаете то, ради чего всё затевалось: регламент начинает проверяться сам, а вам приходит список отклонений, а не ощущение, что «кажется, не соблюдают». Ручная проверка регламентов — та же проблема, что и ручное заполнение отчётов: она съедает время того, кто мог бы заниматься содержательной работой. В одной из команд её решили так же, как проверку контента: автор загружает документ на Google Диск, триггер запускает скрипт, отчёт о соответствии приходит в Telegram. Теперь не нужно вручную перечитывать многостраничные документы ради формальных пунктов. Логика переносится на регламенты почти без изменений. Схема конвейера: Google Диск (папка «Регламенты на проверку») → триггер Apps Script → запрос к модели с текстом документа и чек-листом → результат в Google Таблицу и Telegram-чат ответственного → раз в неделю руководитель просматривает сводку отклонений. Для этой задачи не нужна дорогая модель. В одной из команд заметили, что дорогая модель (Opus) и более дешёвая (Sonnet) дали идентичный результат на одном и том же промпте — разница была только в цене токенов. Проверка регламента по чек-листу — задача классификации, а не творческого рассуждения, поэтому дешёвая модель здесь справляется так же надёжно. Прикинуть свою экономию можно так: число проверяемых документов в месяц × разница в цене токенов между моделями на один прогон = экономия в месяц. Если прогонять несколько десятков регламентов в месяц, а разница в цене между дорогой и дешёвой моделью на один прогон невелика (оценка, зависит от длины документа), суммарная экономия на токенах будет скромной. Основной эффект здесь не в деньгах на токены, а в том, что дешёвую модель не жалко гонять чаще и по большему числу документов. На практике здесь достаточно модели уровня Sonnet или GPT-4o-mini — при регулярных проверках экономия на токенах ощутима именно за счёт объёма, а качество результата не проседает. Пример ответа модели на реальный документ с пропущенной точкой контроля: Инженерная обвязка. Скрипт крутится на Google Apps Script, привязан к папке на Google Диске, срабатывает по событию добавления или изменения файла. Результат пишется в Google Таблицу (журнал проверок по датам) и дублируется сообщением в Telegram-чат ответственного за регламент. Если вызов модели падает — таймаут или лимит квоты — файл помечается тегом «ошибка проверки», в Telegram уходит текст ошибки, повторный запуск можно поставить по расписанию раз в час или запускать вручную кнопкой в таблице. Никакой самостоятельной эскалации бот не делает — решение о доработке документа всегда принимает человек. Telegram · Журнал проверки регламентов неск. десятков документов в месяц Документ Статус Замечание Регламент оплаты счетов не пройдено нет точки контроля Регламент выгрузки клиентов пройдено — Регламент подбора менеджеров пройдено — Ограничение ИИ-проверки Модель хорошо ловит формальные пропуски — нет срока, нет ответственного, нет измеримого результата. Она плохо оценивает, решает ли регламент реальную проблему клиента или сотрудника. Итоговую приёмку регламента должен делать человек, знающий контекст процесса, а не только чек-лист. Где регламент работы отдела ломается на стыке Главный разрыв — между тем, кто пишет документ, и тем, кто по нему работает. Проверьте у себя: писал ли ваш регламент человек, который сам делает эту работу? Показательный провал — разработка портала на базе большого массива вопросов (несколько сотен тысяч). Один специалист собрал контент и дизайн, передал техлидеру — и тот неделю не мог собрать систему нормально. Результат описали так: «красивый дом, но дверей нету, как зайти непонятно». Причина не в квалификации техлидера, а в отсутствии чёткого технического задания — регламента передачи задачи между контентной и технической частью команды. Каждый сделал свою часть хорошо, но регламента стыковки не было, поэтому проект не собрался. Такой же разрыв, только на уровне управления, — ситуация, когда руководителя разработки не подключали к планёркам по внедрению ботов и автоматизации, хотя эти решения напрямую касались его работы. Собственник признал это управленческой ошибкой и вернул руководителя в контур обсуждений. Регламент коммуникации между отделами — кто на каких встречах обязан присутствовать — такая же часть стандартизации процессов, как инструкция для рядового сотрудника. Где ломается Регламент, написанный одним отделом для другого без участия исполнителя, почти всегда упирается в разрыв на стыке. Дизайн и контент можно сделать отдельно, но правило передачи между этапами нужно писать вместе с тем, кто будет собирать финальный результат. О том, как автоматизация превращает часть подобных регламентов в фоновый процесс без ручного контроля, я писал в статье про протоколы планёрок, которые документируют себя сами . А про то, как выстраивается многоуровневая структура ответственности — от стратегии компании до задач конкретного сотрудника, — в материале про стратегию как рабочий инструмент . Экономика: что вам это стоит и что даёт Ваши затраты — часы на описание. Отдача — время, которое вы перестаёте тратить на объяснения одного и того же новым людям. Стоимость внедрения одного формального регламента невысокая: 1–2 часа на разбор сбоя и формулировку правила, ещё 1–2 часа на настройку автоматической проверки, если она нужна. Основные затраты — не деньги, а дисциплина: кто-то должен зафиксировать первую попытку, разобрать три итерации и довести дело до закреплённой инструкции. Отдельно считается цена отсутствия регламента — там, где есть конкретные цифры из практики. Общая логика одна: время потерь в день × ставка часа × число рабочих дней в месяце = потери в месяц (оценка); ставку и часы потерь стоит подставлять свои, взяв консервативную оценку. Ситуация Потери без регламента (оценка) Эффект после внедрения Ручной ежедневный отчёт (30 мин/день на сотруднике) ≈11 000 ₽ в месяц на одного сотрудника (0,5 ч × 22 дня × 1000 ₽/час) Данные тянутся из CRM автоматически, время идёт на анализ Поиск «правильной» цифры из трёх версий выгрузки ≈22 000 ₽ в месяц на одного сотрудника (1 ч в день × 22 дня × 1000 ₽/час) Единый регламент подсчёта, сверка не нужна Несогласованные подключения мессенджеров на сотрудника рост затрат на связь ≈30 000 ₽ в месяц (оценка, расчёт ниже) Аудит и лимит на подключение новых каналов каналы в апреле каналы в мае На диаграмме — рост числа оплаченных коммуникационных каналов на команду в несколько раз за месяц, при почти неизменном числе реальных пользователей. Последняя строка таблицы — отдельный сюжет: за месяц число оплаченных коммуникационных каналов на условной команде выросло с 10 до 30, хотя число сотрудников, которые реально ими пользовались, за это время почти не изменилось. При типичной цене подписки на канал (WhatsApp или Telegram-номер с интеграцией в CRM) ~1500 ₽/мес формула простая: число каналов × цена канала = месячные затраты на связь. Было 10 × 1500 = 15 000 ₽, стало 30 × 1500 = 45 000 ₽, прирост — 30 000 ₽ в месяц (оценка). Это треть условного оклада линейного сотрудника поддержки в этой компании (90 000 ₽), при том что реальных пользователей почти не прибавилось. Причина — не злой умысел, а отсутствие регламента: подключение нового канала не требовало согласования, поэтому каждый добавлял себе WhatsApp и Telegram по мере желания. Такой риск не виден в моменте — он всплывает только на аудите. Более крупный пример — из документооборота. Два специалиста, готовящие договоры, работают на износ, включая выходные, потому что менеджеры сами не готовят документы, а поток лидов растёт. Формула для своего случая: число менеджеров × доля зависших из-за документов сделок × средний чек = потери выручки в месяц. Если взять условный отдел из 6 менеджеров с оборотом ~9 млн ₽/мес и средним чеком 150 000 ₽ (это около 60 сделок в месяц), и предположить, что 10% сделок зависает именно из-за задержки в подготовке документов — не из-за клиента, а из-за отсутствия регламента приоритизации в документообороте, — набегает риск незакрытой или отложенной выручки ≈900 000 ₽ в месяц (оценка: 6 сделок × 150 000 ₽). Это сопоставимо с фондом оплаты труда всего отдела за месяц — при ставке ~120 000 ₽ на менеджера ФОТ отдела составляет ≈720 000 ₽. Регламент здесь не отменяет нехватку рук, но переводит вопрос из «все горят» в конкретное решение: выделенный сотрудник с оплатой за задачу-результат либо распределение между свободными людьми по чёткому правилу очерёдности. Важно не путать вклад разных инструментов в итоговый эффект. Автоматическая проверка регламентов через ИИ экономит время на контроле формальных пунктов — это отдельный, небольшой вклад, измеряемый часами проверяющего и токенами модели. Экономия на зависших сделках или на лишних каналах связи из примеров выше — это эффект самого регламента и аудита как управленческого решения, а не ИИ-инструмента, который лишь ускоряет проверку уже написанного правила. Складывать эти цифры в одну «экономию от автоматизации» некорректно — это разные по природе источники экономии. Правило, которое не пишут в должностной инструкции Оно вам понадобится, когда регламент столкнётся с реальностью: что делать сотруднику, если инструкция противоречит здравому смыслу. Есть ещё один тип регламента, который редко формулируют письменно, но который держит всю систему. Собственник одной компании сформулировал его так: «Вы должны развиваться с бизнесом. В тот момент, когда бизнес вас обогнал — всё. В тот момент, когда вы не соответствуете бизнесу — всё». Это не про должностные обязанности, а про условие, при котором вся остальная стандартизация имеет смысл: сотрудник, который перестал расти вместе с процессами, рано или поздно станет узким местом, сколько бы инструкций для его роли ни было написано. Практическое применение этого правила видно на примере с высокоэффективным менеджером, у которой не осталось свободного времени в течение дня и которая упёрлась в карьерный потолок. Вместо увольнения ей предложили возглавить проект автоматизации — регламент роста для сотрудника оказался частью регламента развития всей компании, а не отдельным ритуалом отдела кадров. Из всего этого складывается не универсальная методичка, а рабочий признак: регламент рождается из конкретного сбоя, а не пишется заранее «про запас». Он привязан ко времени или чёткой точке в процессе — а не к общей формулировке обязанности. Закрепляется после нескольких попыток, а не с первого раза на бумаге. И пересматривается, когда меняются роли, — как в случае с разделением обучения новичков и управления опытной командой. Сам по себе документ при этом верхний слой, а не замена процессу: как процесс описывают, меряют и доводят до владельца — отдельный разговор. Чек-лист: с чего начать в понедельник Выберите один повторяющийся сбой за последнюю неделю — перебивания, нестыковку цифр в двух отчётах, задачу без ответственного — и опишите его в одном предложении. Спросите у трёх человек, вовлечённых в процесс, как они выполняют это действие сейчас. Если ответы разные — регламента нет, есть только ощущение, что «все всё знают». Назначьте конкретное время или точку в процессе для этого действия — не «по мере необходимости», а «с 10 до 11» или «после подписания договора, до передачи в производство». Зафиксируйте первую попытку выполнения по новому правилу текстом или диктофоном. Не редактируйте задним числом — фиксируйте то, что реально произошло. Пройдите цикл из трёх итераций и закрепите правило инструкцией только после того, как третий раз получилось без ручного контроля. Если проверка регламента формальная — есть срок, есть ответственный, есть точка контроля, — соберите её в чек-лист и попробуйте автоматизировать проверку промптом, прежде чем поручать это человеку каждый раз заново. Регламенты, которые читают, — не те, что написаны красивее. Это те, что описывают уже произошедший сбой и закрывают ему дорогу назад. Остальное — красивый дом без дверей. Возьмите на этой неделе один свой регламент и проверьте его на исполнителе: дайте прочитать и попросите пересказать, что он будет делать. Если пересказ не совпал с вашим замыслом — виноват документ, а не человек. Как превратить регламенты в то, что машина сможет проверять автоматически, — в бесплатном курсе . Что я понял про регламенты за эти годы Мой главный вывод неприятный для любителей порядка: регламент нельзя написать один раз. Мы пробовали — получили красивую папку, которую никто не открывал. Работать начало, когда я принял, что каждый документ живёт, пока его проверяют, и умирает в тот день, когда проверка прекращается. Второй вывод: писать должен тот, кто делает. Мои регламенты, написанные из кабинета, разваливались о реальность на первой же неделе — я не знал деталей, которые для исполнителя очевидны. Сейчас я формулирую задачу и критерий приёмки, а текст пишет человек, который эту работу выполняет. И третий: если для соблюдения нужна ваша воля — регламента нет. Есть ваше личное присутствие, которое нельзя масштабировать. Если называть вещи своими именами, это отдельный управленческий навык: превратить разовый сбой в правило, которое держится без вас. Руководитель, который умеет это делать, стоит дороже руководителя, который каждый раз объясняет одно и то же заново, — и осваивать этот навык придётся, потому что на объяснениях вручную компания дальше десяти человек не растёт. Что сделать на этой неделе: возьмите один процесс, который у вас регулярно ломается, и опишите его в пять шагов — с человеком, который эту работу делает. Проверьте на нём же. Дальше решите, нужен ли вам следующий. Как поставить автоматическую проверку соблюдения — в бесплатном курсе для руководителей . ## Отбор резюме нейросетью: 400 откликов за вечер без потери адекватных URL: https://davidgerstein.pro/blog/skrining-rezyume-ii/ Дата: 2026-06-19 Направление: Люди Цифры: несколько десятков откликов на портале · 2 дня на доработку бота · ~3 ч/день ручного просмотра (оценка) Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Отбор резюме: что делает машина, а что человек Отбор резюме на потоке собирается из четырёх блоков: таблица мониторинга вакансии , подключение к порталу откликов по API , агент, который ежедневно забирает новые резюме и оценка каждого резюме по критериям вакансии . Машина читает и ранжирует. Приглашает и отклоняет человек. Если у вас на вакансию приходит несколько сотен откликов, счёт выходит такой: ежедневный разбор одной вакансии сжимается с ~3 часов до ~40 минут, то есть более чем вчетверо (оценка). Ломается связка не там, где её ждут: не на качестве оценки резюме, а на рассинхроне между порталом и таблицей — часть откликов до оценки просто не доезжает. Четыреста откликов на вакансию — это не удача, это проблема. Потому что разобрать их некому: у вашего HR есть ещё десять задач, и он честно посмотрит первые тридцать, а дальше начнётся лотерея. Если вы честно смотрите первые тридцать откликов, а остальные закрываете статусом «не рассмотрено», — у вас не кадровый голод, у вас утечка. Вы платите за поток, до которого не доходят руки, и человек, который вам нужен, вполне может лежать на трёхсотой строке. Вы его не отклонили. Вы его не открывали. Я прошёл через это и знаю, чем заканчивается: нанимают не лучшего кандидата, а того, кто удачно оказался в верху списка. Ниже — как мы отдали первичный разбор машине и что из этого вышло, включая место, где всё сломалось в первый раз и где я потерял больше всего времени. Менеджер по подбору персонала свёл статистику на конец дня: портал показывает несколько десятков откликов на вакансию, в таблице автоматизированной системы — заметно меньше. Не два-три резюме потерялось, а ощутимый кусок потока. Первая мысль — агент занижает оценки, и часть кандидатов не проходит порог. Вторая, более неприятная — агент вообще не забирает эти резюме с портала, до всякой оценки. Разница принципиальная: одно чинится правкой критериев, второе — это дыра, через которую утекают кандидаты, которых никто даже не увидел. До автоматизации менеджер вручную открывал портал, листал отклики, сверял с описанием вакансии, копировал подходящих в отдельный файл. При потоке в несколько сотен откликов на вакансию это часы каждый день — оценочно около 3 часов на вакансию при работе с массовым потоком, то есть больше трети восьмичасового рабочего дня только на просмотр резюме, без единого звонка кандидату. И это в лучшем случае: часть откликов при ручном разборе просто не открывают — до них не доходят руки, и адекватный кандидат уходит со статусом «не рассмотрено» без единого взгляда на резюме. Зачем мы за это взялись У нас была вакансия, на которую пришло больше четырёхсот откликов за неделю. Я посмотрел, как это разбирается, и понял, что мы физически не сможем прочитать всех: HR честно разбирал первые полсотни, дальше начинался случайный отбор. Мы нанимали не лучшего кандидата, а того, кто удачно попал наверх списка. Меня это разозлило: мы платим за размещение, тратим время команды на собеседования — и при этом главную часть работы, отбор, делаем наугад. Отсюда и появился этот контур. Я не искал «внедрить ИИ», я искал способ не выбрасывать людей, за показ которых уже заплачено. Ручной скрининг не масштабируется линейно. Если на вакансию приходит 400 откликов за вечер — обычное дело для массового найма, — просмотреть каждое резюме за разумное время физически нельзя. Начинается выборочная проверка: смотрят первые пятьдесят, остальное закрывают статусом «отклонено» без просмотра. Часть адекватных кандидатов теряется и вовсе не из-за того, что они не подходят: до них просто не дошла очередь. Задача автоматизации здесь конкретная — не заменить решение человека, а гарантировать, что каждый отклик хотя бы попал в поле зрения с предварительной оценкой. Дальше менеджер смотрит не 400 резюме подряд, а список, отсортированный по баллам, и тратит время на тех, у кого оценка высокая или пограничная. Как устроен отбор резюме: API, таблица, агент Дальше — сборка, которую вы можете повторить у себя. Если у вас есть площадка с откликами и таблица, вам понадобится вечер. Никакого специального софта покупать не нужно, и это тот случай, когда ваш HR справится без ИТ-отдела. Внедрение строилось в четыре шага, и порядок был важен именно такой — попытка начать сразу с автоматических приглашений здесь провалилась бы гарантированно. Структурированная таблица мониторинга вакансий. Поля под просмотры, клики, отказы, статус резюме по критериям — до всякого API. Без таблицы некуда складывать данные, которые потом принесёт агент. Подключение через API-ключи к базе данных портала. Без него всё осталось бы ручным копированием — механика та же, только медленнее. Агент, который ежедневно обращается к порталу и вытягивает новые отклики. Работает по расписанию, не по запросу человека. Автоматическое заполнение таблицы резюме с оценкой по заданным критериям. Тут в дело вступает модель — она читает текст резюме и критерии вакансии, а не просто копирует поля. На начальном этапе все решения по кандидатам остаются за менеджером. Агент не приглашает и не отклоняет — он готовит материал для решения. Это не временная перестраховка, а рабочая логика: система должна накопить обратную связь от человека, прежде чем ей можно доверить действие, а не только оценку. ИИ-связка целиком: промпт, модель, обвязка Мы собирали это неделю и переделывали дважды; я покажу сразу рабочую версию, чтобы вы не повторяли наш путь. Обратите внимание на структуру постановки: она пишется под ваши требования к вакансии, а не под «хорошего кандидата вообще». Чем точнее вы опишете, кого ищете и что для вас стоп-фактор, тем меньше вам придётся перепроверять руками. Конвейер выглядит так: портал вакансий → агент по расписанию (cron) → API портала отдаёт новые отклики → текст резюме и критерии вакансии уходят в модель на скоринг → результат пишется в Google Sheets → менеджер видит отсортированный список → решение по кандидату вручную → обратная связь возвращается в систему для донастройки критериев. Для скоринга резюме взяли дешёвую модель уровня GPT-4o-mini. Дешевле здесь не означает хуже: задача формальная: сверить текст с чётким списком критериев, не рассуждать, не сочинять. Дорогая модель с расширенным рассуждением здесь просто сжигает бюджет без прироста качества — разница в точности на этом шаге не окупает разницу в цене токена. Структура входных данных, которую агент собирает по API портала и передаёт в модель: Пример ответа модели на реальный вызов: Второй промпт — для короткого уведомления в Telegram, когда балл кандидата высокий. Тут тоже дешёвая модель: задача — переформулировать структурированные данные в две строки человеческого текста, а не анализировать. Инженерная обвязка. Агент крутится по расписанию (cron-задача, вызов раз в час), пишет результат в Google Sheets через API — таблица одновременно и хранилище, и интерфейс для менеджера. Telegram-бот подписан на изменения таблицы и присылает сводку и точечные уведомления по высоким баллам. Отдельный лист в таблице фиксирует время последнего успешного прогона агента — если метка не обновлялась дольше цикла (больше часа), это видно сразу, без сверки вручную. При сбое запроса к API портала агент делает до трёх повторных попыток с задержкой, а после третьей неудачи отправляет отдельное сообщение в служебный Telegram-канал: «синхронизация не удалась, данные могли устареть». Что видно в таблице и в боте Обратите внимание, что попадает вам на глаза, а что — вашему HR. Руководителю не нужен весь список: вам нужны отобранные кандидаты и причина отбора, чтобы вы могли спорить с логикой, а не пересматривать четыреста откликов. Два листа таблицы решают разные задачи: один показывает здоровье вакансии в целом, второй — конкретных кандидатов. Лист таблицы Что фиксирует Кто смотрит и когда Отчётность по вакансиям Дата, просмотры, клики, отказы, процент релевантных резюме, время последнего обновления Менеджер — раз в день, при подозрении на сбой — сразу Реестр откликов Критерии оценки кандидата и итоговый балл по каждому резюме Менеджер — по мере поступления уведомлений от бота Так выглядит лист «Отчётность по вакансиям» на практике — с теми же цифрами, что и в примере выше: несколько десятков откликов на портале, из них большая часть уже попала в таблицу агента, и метка синхронизации, по которой сразу видно, отстали данные или нет. Google Sheets — Отчётность по вакансии 38 откликов на портале 34 в таблице агента 92/100 лучший балл дня 14:05 время последней синхронизации Кандидат Балл Статус resp-58902 92 смотреть в приоритете resp-58831 3 смотреть в очереди Разница по времени до и после внедрения — оценка на основе описанного процесса, а не точный хронометраж. Но порядок величины отражает реальность потока в несколько сотен откликов в день. На диаграмме ниже — сравнение времени ручного просмотра всех откликов и проверки уже отобранных агентом кандидатов. 180 мин было 40 мин стало 180 минут (~3 часа) — оценочное время ручного просмотра всех откликов на активную вакансию в день; 40 минут — время на проверку уже отобранных агентом кандидатов. Обе цифры — оценка, основанная на потоке в несколько сотен откликов на вакансию. Экономия по времени не означает, что кандидатов начали смотреть меньше — их смотрят все, просто в отсортированном порядке с готовой предварительной оценкой, а не листая ленту откликов подряд. Где автоматизация сломалась в первый раз Читайте внимательно, если будете повторять: именно здесь вы потеряете время, если пойдёте нашим путём без этой поправки. И здесь я обязан сказать про свою ошибку. Когда менеджер принёс расхождение, я искал причину в оценках: правил критерии, перечитывал постановку, спорил про пороги. А ломалось не там. Часть откликов просто не доезжала с портала в таблицу, и оценивать было нечего — модель к этим людям даже не прикасалась. Я не понимал простой вещи: связку двух систем проверяют не по качеству результата, а по факту доставки данных. Если вы сейчас стоите на этом же месте — это не ваша глупость, на этом спотыкается каждый, кто первый раз сшивает своё с чужим. Расхождение между числом откликов на портале и меньшим числом в таблице — не единичный сбой, а системный риск любой интеграции через API. Портал обновляется в своём темпе, агент забирает данные в своём, и если между ними разрыв, менеджер об этом не узнаёт, пока не сверит вручную. А сверка вручную — это ровно та рутина, от которой хотели уйти. Решение — не «почини баг один раз», а встроить показатель, который сразу говорит: данные свежие или устарели. Добавили метку времени последнего обновления таблицы. Если метка отстаёт от текущего момента больше, чем на один цикл работы агента, значит синхронизация сбилась, и таблице пока верить нельзя. Где ломается Скрининг резюме ИИ не ломается на оценке кандидатов — там алгоритм чаще всего работает предсказуемо, если критерии сформулированы чётко. Он ломается на стыке систем: там, где данные с портала должны попасть в таблицу, а по факту иногда не попадают из-за разницы в темпе обновления. Любое внедрение такого рода требует отдельного контроля не качества оценки, а факта доставки данных. Второй уровень контроля: Telegram вместо второй таблицы Когда появилась метка синхронизации, вскрылась вторая проблема — поведенческая, не техническая. Менеджер не доверял таблице до конца и продолжал параллельно заглядывать на портал. Логика простая: пока нет уверенности, что системе можно доверять, приходится смотреть и там, и там — а это уже не рабочий инструмент, а ещё одна табличка, куда надо смотреть. Инструмент, который требует постоянной сверки с другим источником, не экономит время — он его удваивает. Дело было не в том, чтобы уговорить менеджера довериться таблице, а в том, чтобы вынести уведомления туда, где человек и так проверяет входящее — в мессенджер. Спроектировали Telegram-бота: раз в час — сводка по новым откликам, отдельное уведомление — каждый раз, когда появляется кандидат с высокой оценкой. Из чата можно сразу посмотреть резюме, перейти на портал, пригласить на собеседование или отклонить. Так выглядит лента уведомлений в реальном чате бота: Telegram — уведомления бота Время Сообщение 14:00 Новый кандидат 92/100 по вакансии «Менеджер по продажам». Есть опыт в отрасли и английский B2. 13:20 Синхронизация не удалась, данные могли устареть Срок на доработку — два дня, потому что база (API, таблица, агент) уже была готова, добавлялся только слой уведомлений. Здесь важна оговорка про смешение эффектов: экономию времени (3 ч → 40 мин) даёт связка API + таблица + скоринг — она сокращает сам просмотр резюме. Telegram-бот отдельно не сокращает время просмотра, он убирает необходимость параллельной сверки с порталом «на всякий случай». Этот эффект в часах отдельно не измерялся, но именно он превращает таблицу из «ещё одной таблички» в рабочий инструмент — без него часть сэкономленного времени менеджер тратил бы обратно на ручную проверку. Где ещё ломается Модель для скоринга спотыкается на нестандартных резюме: PDF, где текст на самом деле картинка, файлы без структуры, резюме на смеси языков. Без предварительного распознавания текста агент в таких случаях либо занижает балл, либо помечает резюме флагом «не удалось оценить» — и это тоже нормальный сценарий, если он попадает в поле зрения человека, а не тихо тонет в общем потоке. Отбор резюме: что остаётся за человеком и что забрать себе Отбор резюме в этой схеме не заканчивается решением: машина готовит материал, решение принимает человек. Агент обучается на обратной связи: если менеджер регулярно отклоняет кандидатов с высоким баллом по одному критерию и принимает с низким по другому, это сигнал, что критерии оценки настроены неточно. Без ручной проверки этот сигнал никто бы не увидел, и система продолжала бы штамповать оценки, не совпадающие с реальными решениями по найму. Полная автоматизация приглашений на собеседование — следующий этап, и переходить к нему стоит только после того, как накопится достаточно решений менеджера для сверки с оценками агента. Тут же встаёт вопрос данных: резюме — это персональные данные кандидатов, и что из них можно передавать в сторонние ИИ-инструменты, а что нет, разобрано отдельно в статье про персональные данные и нейросети . Экономика: что это стоит и что даёт Разработка базовой связки — таблица, API-подключение, агент со скорингом — заняла порядок нескольких дней работы одного человека, обучающегося работе с API и серверными инструментами по ходу. Доработка с Telegram-ботом добавила ещё два дня — примерно треть от времени на саму базовую связку. В пересчёте на трудозатраты разработчика весь проект укладывается в объём одной рабочей недели. Эксплуатация — вызовы дешёвой модели на скоринг и уведомления — при потоке в несколько сотен резюме в день обходится на порядок дешевле одного рабочего дня менеджера в месяц, без учёта стоимости самого API портала, если он платный. Эффект считаем отдельно от прочих инициатив по найму — это вклад именно скрининга, без учёта, например, параллельного обновления курса адаптации новых сотрудников. Формула для своего случая считается так: (часы ручного просмотра в день минус часы проверки после автоматизации) × ставка часа менеджера × число одновременно открытых вакансий × число рабочих дней в месяце = месячный эффект в деньгах. Подставим пример: отдел закрывает 3 вакансии в месяц с потоком по 300–400 откликов на вакансию. Ручной просмотр — оценочно 3 часа в день на активную вакансию, автоматизация сокращает это время до 40 минут проверки отобранных кандидатов. Разница — около 2 часов 20 минут в день на вакансию, то есть время сокращается более чем в 4 раза. При трёх параллельных вакансиях в активной фазе это суммарно около 7 часов высвобожденного рабочего времени в день — больше, чем целый рабочий день одного менеджера, — а за 20 рабочих дней набегает объём, сопоставимый примерно с тремя-четырьмя дополнительными рабочими неделями менеджера в месяц (оценка, при условии, что вакансии действительно идут параллельно и поток стабилен). Показатель До После Эффект Время на просмотр откликов, 1 вакансия/день ~3 ч (оценка) ~40 мин (оценка) сокращение более чем в 4 раза Доля восьмичасового рабочего дня, 1 вакансия ~37% дня ~8% дня высвобождается ~29% дня При 3 параллельных вакансиях — — ~7 ч/день, за месяц — 3–4 доп. рабочие недели менеджера (оценка) Разовые затраты на внедрение (разработка + бот) — сопоставимы с одной рабочей неделей разработчика (оценка) Срок окупаемости разовых затрат — меньше 2 недель при потоке из примера (оценка) Окупаемость считается прямым делением: разовые затраты на внедрение делим на дневную экономию рабочего времени, пересчитанную в деньги по ставке менеджера. В примере верхняя, консервативная граница затрат делится на консервативную дневную экономию — получаем около 10–11 рабочих дней. Даже с консервативными допущениями по обе стороны формулы срок окупаемости укладывается в пару недель, а не месяцы. Это не чистая экономия бюджета — высвобожденное время менеджер тратит на звонки и интервью, то есть эффект выражается не в снижении расходов на зарплату, а в ускорении цикла закрытия вакансии и в том, что меньше адекватных кандидатов теряется из-за физической нехватки времени на просмотр. Похожая логика перевода часов в деньги разобрана в статье про реальные расходы на ИИ в месяц — стоит свериться, прежде чем закладывать бюджет на подписки моделей под несколько процессов сразу. С чего начать в понедельник Проверьте, есть ли у портала вакансий открытый API или хотя бы экспорт откликов — без этого шаг с агентом невозможен, и придётся начинать с ручного экспорта. Соберите таблицу мониторинга с двумя листами — отчётность по вакансии и реестр откликов с критериями — до подключения любого агента. Сформулировать критерии оценки резюме в виде короткого списка, а не общих формулировок вроде «опытный специалист» — модель оценивает буквально то, что написано. Добавьте в таблицу отдельную ячейку с меткой времени последнего обновления — это дешевле, чем разбирать расхождения в данных постфактум. Запустить агента в режиме «только предлагает», без права приглашать или отклонять, минимум на несколько недель, чтобы накопить обратную связь менеджера. Настройте хотя бы одно уведомление вне таблицы — почта или мессенджер, — чтобы не создавать вторую систему, которую придётся проверять параллельно с первой. Что из этого переносится на другие процессы найма Автоматизация подбора персонала здесь строилась не как единая «умная система», а как последовательность простых блоков: сбор данных, структурирование, контроль синхронизации, уведомления. Каждый блок можно проверить отдельно и обкатать до того, как строить следующий. Похожая логика описана в статье о том, почему внедрение ИИ не работает, хотя технически всё запустилось : система, которую не с чем сверить и некому проверить, быстро превращается в фон, на который никто не смотрит. Из этого кейса при переносе на другой найм стоит забрать не саму технологию, а три привычки, на которых она держится. API и таблица дают скорость, но не гарантируют полноту данных — за это отвечает отдельная метка синхронизации, а не надежда на то, что интеграция «просто работает». Критерии оценки не калибруются сами по себе — их донастраивает человек, регулярно сверяя баллы агента с реальными решениями по найму, и без этой сверки скоринг рано или поздно начинает расходиться с практикой. И финальное решение по конкретному кандидату не стоит целиком передавать модели — и дело не в том, что она обязательно ошибётся: цена ошибки в найме выше, чем цена сорока минут ручной проверки. Конкретный портал, конкретная модель для скоринга, формат таблицы — всё это меняется под инструменты, которые уже есть в компании. Не меняется последовательность: сначала данные и их проверка, потом оценка, и только в самом конце — автоматическое действие, да и то не сразу, а после того как система докажет, что её оценкам можно доверять. И честная граница: машина отбирает и ранжирует, решение о встрече принимаете вы. Не потому что технология слабая, а потому что ответственность за найм нельзя делегировать никому — ни машине, ни рекрутеру. Теперь главное, ради чего я вообще это описал. Умение поставить машину на входе в свой процесс — это управленческий навык, такой же обязательный, как умение читать отчёт о деньгах. Я вижу это по себе: раньше у меня было два хода — догрузить человека задачами или нанять ещё одного. Теперь есть третий: описать критерии так точно, чтобы поток разбирался без моего участия. Руководитель, который умеет масштабировать работу через машину, стоит дороже руководителя, который умеет только раздавать поручения людям. Учиться этому придётся, и лучше сейчас, пока это ещё преимущество, а не минимальное требование к должности. Первое движение — на этой неделе, оно занимает полчаса: откройте последнюю закрытую вакансию и посчитайте, сколько откликов реально открыли глазами. Я в свой раз считал с очень неприятным чувством. Эта цифра и есть размер вашей утечки, и пока вы её не назвали, чинить нечего. Если у вас поток откликов и вы хотите собрать такой отбор у себя, механика — в бесплатном курсе : там же готовые постановки для первичного разбора. ## Сквозная аналитика своими руками: аудит данных вместо покупки BI-сервиса URL: https://davidgerstein.pro/blog/skvoznaya-analitika-s-chego-nachat/ Дата: 2026-06-18 Направление: Маркетинг Цифры: 10–15% лидов не атрибутируется (в декабре — 30%) · дубли давали 2-3 копии на лид · конверсия органики упала с 17% до 10% за 4 месяца Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Сквозная аналитика: с чего начать, пока сервис не куплен Если у вас конверсия в отчёте падает третью неделю подряд, а отдел продаж говорит, что звонков столько же, — скорее всего, вы смотрите не на рынок, а на дубли в собственной базе. Сквозная аналитика начинается не с выбора платформы, а с трёх вопросов к каждой цифре: откуда она берётся, по какой дате считается и не задваивается ли по пути. Первую рабочую версию вы соберёте за неделю на том, что уже есть: выгрузка из CRM, Google Sheets, час внимания. На этом шаге в компании на 40 человек нашлись дубли, дававшие 2-3 копии на один лид, и 10-15% лидов, которые не привязать к каналу вообще (в декабре — до 30%). Пока эти дыры открыты, любой купленный дашборд будет аккуратно показывать ваши же кривые данные. Сквозная аналитика звучит как проект на полгода и бюджет с шестью нулями. На практике первую рабочую версию вы соберёте за неделю — и она ответит на главный вопрос: какие каналы дают деньги, а какие только заявки. Разбирал этот случай подробно — куда пропадают заявки с сайта на пути к оплате . Руководитель компании открыл с утра отчёт по лидам — конверсия падала третий день подряд. Полез разбираться: одна входящая точка создавала два-три дубликата на каждый лид. Реальная картина была другой — просто одного человека в базе считали за троих. Нашёл случайно: цифры совсем не бились с ощущением от звонков отдела продаж, вот и пересмотрел отчёт не по привычке. Не открой он его в то утро — решения принимались бы ещё неделю на кривых цифрах, а бюджет канала тем временем продолжал списываться в прежнем темпе. Вот и весь секрет: сквозную аналитику начинают не с покупки сервиса, а с проверки, не врут ли данные, которые уже есть. Час на аудит одного источника обычно дешевле недели решений, принятых по кривой картине. Сквозная аналитика: сначала ревизия данных, а не дашборд У меня было ощущение, что сквозная аналитика — это дашборд с графиками и деньги на дорогую платформу. На деле первые месяцы ушли не на визуализацию, а на поиск дыр в данных, которые уже были. Дыры оказались простыми и дорогими. Я и сам сначала искал, какой сервис купить, а не что проверить, — на этот поиск ушло больше времени, чем потом на весь аудит. Пример: у двух менеджеров разошлись цифры по продажам за месяц — расхождение почти на 10%. Проверили через CRM: потеряли одну сделку — её посчитали рекомендацией, а не лидом, и не включили в расчёт. Дальше нашлась вторая проблема: при фильтрации по месяцу оплаты вместо месяца создания договора разница выросла почти до 40% от суммы. Это не ошибка человека — это ошибка настройки фильтра, которую никто не проверял месяцами. Прежде чем считать что-то сквозным, ответьте на три вопроса про имеющиеся данные: откуда берётся цифра, по какой дате она считается и не задваивается ли она где-то по пути. Пока эти вопросы не закрыты, любой красивый дашборд врёт красиво — и чем он красивее, тем сложнее заподозрить подвох. Спрашивать «откуда эта цифра» раньше, чем принимать по ней решение, — это отдельный навык руководителя, и он даёт больше любой новой платформы: вы перестаёте покупать инструмент под проблему, которой у вас нет. Разбирал этот случай подробно — как считать стоимость лида, чтобы не платить за брак . Правило Не строй сквозную аналитику поверх данных, которые никто не проверял на дубли и сдвиги дат. Час на аудит источника экономит месяц неверных решений. Дубли лидов — самая частая дыра Одна входящая точка — например, форма на сайте — может плодить несколько карточек в CRM: то двойной клик, то вебхук, продублированный интеграцией. Конверсия при этом падает не потому, что стало хуже, а потому что в знаменателе теперь в два-три раза больше лидов, чем было на самом деле. Проверяется просто: сравнить число уникальных телефонов и почт с числом карточек в CRM за один день. Не совпадает — у вас дыра, а не тренд. Похожая история с датами разобрана в статье о том, как CRM врёт данные и сдвигает даты — там же способ поймать искажение до того, как оно попадёт в отчёт для руководителя. Где нашли ошибку Расхождение Эффект, если не поймать Отчёт двух менеджеров за месяц Расхождение почти на 10% — из-за сделки, посчитанной как рекомендация, а не лид Решения по итогам месяца принимаются на заниженной выручке Фильтр по дате оплаты вместо даты договора Разница выросла почти до 40% от суммы в зависимости от способа фильтрации Прогноз кассы искажается на треть без единой ошибки человека Дубли на входящей точке (форма на сайте) валовых лидов заметно больше уникальных контактов — на треть за день Конверсия выглядит упавшей в полтора раза, хотя реальный трафик не изменился Атрибуция: 10-15% лидов вы всё равно не отследите В любой кампании часть лидов не привязать к каналу — кто-то блокирует куки, кто-то чистит историю браузера. У нас эта доля держалась на 10-15%, а в декабре подскочила до 30%: праздничный трафик идёт с других устройств и по другим сценариям. Сначала я сам пробовал силой раскидать эти лиды по каналам, чтобы отчёт выглядел полным — не помогает, только добавляет шум. Правильнее выделить их отдельной строкой с пояснением причины. Тогда видно: доля растёт — значит, что-то поменялось в трафике или на сайте, и это повод разбираться, а не подгонять цифры. Отдельная и более неприятная версия той же проблемы — когда система технически не даёт разделить конверсию даже по видимым источникам. У нас Google и Яндекс какое-то время сливались в один поток из-за ограничений интеграции. Без разделения непонятно, какой канал реально работает — это уже не аналитическая, а управленческая проблема: нет данных — нет рычага давления ни на подрядчика, ни на бюджет. Если ваш подрядчик показывает вам два источника одной строкой, это не отчёт, а его удобство — просите разделить до того, как обсуждать результат. Цена канала: считать по качественным лидам, а не по валовым заявкам Цена канала — это не бюджет, поделённый на валовое число заявок, а бюджет, поделённый на число лидов, дошедших до контроля качества, за тот же период. Разница огромная. Сам расчёт разбираю по шагам отдельно: как считать стоимость лида, чтобы не платить за брак . Пример на условных цифрах, чтобы формулу можно было приложить к своему каналу: бюджет канала, поделённый на число качественных лидов (наш реальный случай по каналу в соцсети), даёт цену за качественный лид почти втрое выше, чем тот же бюджет, делённый на валовые заявки. На бумаге валовая цифра выглядит втрое дешевле и втрое обманчивее на практике, потому что ничего не говорит о том, сколько из этих заявок дойдёт до сделки. 100 — грубо 296 — точно На диаграмме — один и тот же бюджет канала: делённый на валовые заявки он даёт индекс 100, делённый на качественные лиды — индекс 296, почти втрое выше. Первая цифра выглядит красивее, вторая — честнее говорит о деньгах. Канал в соцсети дал за месяц лишь считанные единицы продаж на десятки качественных лидов — на первый взгляд провал. При разборе выяснилось: это первое касание клиента, а не готовый к покупке лид, цикл сделки здесь длиннее, чем у остальных источников. Считать стоимость лида так же, как по контекстной рекламе, — методологическая ошибка. Прими решение по валовой цифре — закрыли бы канал и потеряли источник, которому просто нужна другая воронка. Ещё случай: после смены текста объявления по чужой рекомендации конверсия упала с 33% до 6% — в 5,5 раза, а объём лидов вырос на четверть. Формально «лидов стало больше», по факту стоимость качественного лида выросла в разы: новый трафик оказался возрастным, иногородним, из-за рубежа. Без разбивки по качеству это выглядело бы успехом ещё две недели — пока отдел продаж не начал жаловаться на пустые звонки. Что мерить Частая ошибка Что делать вместо Стоимость лида Бюджет / валовые лиды Бюджет / лиды, прошедшие контроль качества Конверсия канала Сравнивать все каналы одной меркой Учитывать длину цикла сделки для каждого источника Атрибуция Насильно распределять неотслеживаемые лиды Выделять отдельной категорией с причиной План по лидам Смотреть только на итог месяца Сверять план по дням и неделям О том, как разрыв между количеством лидов и реальными продажами прячется в отчётах, я подробнее писал в статье «Лиды есть, а продаж нет» — там разобрано, где именно теряются деньги между маркетингом и отделом продаж. Контрольные точки: план по дням, а не по месяцу Когда месячный план по лидам стоит одной цифрой без разбивки по неделям и дням, он бесполезен для управления: об отставании узнаёшь только в последнюю неделю месяца, когда исправлять уже почти нечего. У нас выходило заметное число валовых лидов в день со всех источников, из них меньше половины — качественные в рабочий день; дневной план по качественным лидам был реальной контрольной точкой, а не цифрой для галочки. За месяц качественными оказались только 40% лидов при плановом отвале не больше 20%. Эту разницу видно, только если считать конверсию в качество каждую неделю, а не подводить итог постфактум. То же с сезонностью: декабрь у нас идёт с коэффициентом 0,8 к плану — заранее известно, что лидов будет на 20% меньше, и это не повод паниковать, а повод не сравнивать декабрь с октябрём напрямую. Технически такой дашборд не требует дорогого сервиса — у нас его за выходные собрал специалист по SEO, с отслеживанием лидов и конверсий по страницам в реальном времени. Дальше пошла ручная работа: сверять рост трафика с падением продаж и искать, на каком этапе разрыв. Например, конверсия органического трафика падала четыре месяца подряд — с 17% в январе до 10% в апреле, при этом трафик рос. Без разбивки по неделям это выглядело бы как «сайт работает», а по факту качество лидов с этого канала всё время снижалось. Мне понадобилось четыре месяца, чтобы это заметить, — ровно потому, что я смотрел на итог месяца, а не на неделю. Январь 17% Март 15% Апрель 10% На диаграмме — конверсия органического трафика сайта в лиды, % от посетителей. Трафик за этот же период рос — падала именно конверсия, что видно только при разбивке по месяцам, а не по итогу квартала. ИИ-связка: ежедневная проверка отчёта на аномалии вместо ручной сверки Ручную сверку каждое утро делал аналитик: сравнивал лиды в CRM с уникальными контактами, смотрел долю неатрибутируемых, прикидывал отставание от плана по дням. Задача рутинная и формализуемая, но требует внимания каждый день — то есть годится для дешёвого классификатора, а не для дорогой топовой модели: здесь не нужно творчество, нужна аккуратная сверка чисел по жёсткой инструкции. Конвейер выглядит так: 1. Вебхук из Bitrix24 (или amoCRM API) раз в сутки выгружает новые сделки и лиды в Google Sheets: дата, канал, статус, телефон/email, отметка о прохождении контроля качества. 2. Google Apps Script по расписанию (триггер time-driven, ежедневно в 7:00) сворачивает сырые строки в JSON-сводку за последние 7 дней по каналам. 3. Скрипт отправляет JSON в LLM API с промптом ниже. 4. Ответ модели (тоже JSON) пишется в отдельный лист «Аномалии» и дублируется уведомлением в Telegram-бот ответственному аналитику. 5. Аналитик утром открывает лист, а не весь отчёт целиком — смотрит только то, что модель пометила как high или medium. Пример ответа модели: Google Sheets — лист «Аномалии» +34% лидов gross сверх нормы за день ~⅓ разрыв с уникальными контактами high подозрение на дубли Дата Канал Тип аномалии Важность 2026-06-10 site_form duplicate_suspect high Так выглядит лист «Аномалии», в который модель пишет результат прогона: аналитик открывает только его, а не весь отчёт целиком. Инженерная обвязка простая, без энтерпрайза: Google Apps Script пишет логи прогонов в отдельный лист, каждая ошибка API — таймаут, лимит токенов, пустой ответ — попадает туда же с меткой времени и дублируется в Telegram сообщением «прогон не выполнен». Перезапуск — вручную, кнопкой в меню таблицы, без доступа к серверу аналитик делает это сам за минуту. Тот же принцип я описывал в статье про реальные счета за ИИ — дешёвая модель на рутинной сверке обходится в доллары в месяц, а не в тысячи. Где ломается модель Дешёвая модель хорошо ловит явные расхождения чисел, но иногда путает причину: помечает сезонное падение — тот же декабрь с коэффициентом 0,8 — как аномалию. Порог severity нужно калибровать вручную первые 2-3 недели, иначе аналитик начнёт игнорировать уведомления, и тогда автоматизация окажется хуже, чем её отсутствие. Экономика: что стоит и что даёт Настройка ~14-26 часов разово (аудит источников + связка вебхук → Sheets → LLM), эксплуатация — несколько долларов в месяц на токены, эффект — экономия около 20 часов ручной сверки в месяц (оценка). Внедрение. Аудит источников данных — дублей, дат, атрибуции — разовая работа аналитика или толкового менеджера, оценочно 8-16 часов в зависимости от числа источников. Настройка связки вебхук → Google Sheets → LLM API — ещё 6-10 часов работы того, кто умеет писать Apps Script; часто это тот же человек, что уже собирал дашборд за выходные, а не отдельный дорогой подрядчик. Эксплуатация. Дешёвая модель на ежедневном прогоне сводки по 5-10 каналам обходится в несколько долларов в месяц, не в десятки. Основная статья расходов — не токены, а время человека, который читает и разбирает флаги. Эффект. Ручная сверка отчётов продаж и маркетинга занимала у аналитика около часа в день — это около 20 часов чистого рабочего времени в месяц только на то, чтобы свести две таблицы руками, не считая ошибок, которые всё равно проскакивают, потому что на 22-й день подряд быть внимательным устаёшь. Что мы не считаем эффектом: время аналитика не сокращается до нуля — оно перераспределяется на разбор флагов, помеченных моделью, а не на саму сверку; в деньгах это экономия часов на рутине, а не сокращение штата. Окупаемость на этих же оценках: разовая настройка — 14-26 часов работы. Экономия ручного времени — около 20 часов в месяц, что при ставке ~1 000 ₽/час даёт около 20 000 ₽/мес (оценка). Даже по верхней границе разовых работ окупаемость наступает меньше чем за полтора месяца, а дальше это чистая экономия минус несколько долларов на токены. Отдельно — риск от решения на грязных данных, и это не эффект автоматизации, а иллюстрация цены задержки. При обороте отдела ~9 млн ₽/мес и среднем чеке ~180 тыс. ₽ это около 50 сделок в месяц; дневной бюджет канала, крутящийся на искажённой картине неделю, — это риск потратить бюджет вслепую на канал, который на самом деле работает иначе, чем показывает отчёт. Похожая история — с конверсией 33%→6%: две недели трафика «по инерции» на неверной гипотезе съели заметную часть месячного бюджета канала на лидов, которых потом пришлось признать нецелевыми. Причины и следствия тут лучше не путать: сама сверка данных не увеличивает число лидов и не чинит воронку — она только показывает, где решения принимались вслепую. Рост качества лидов из истории с аватарами покупателя или снижение оттока — отдельные инициативы, их вклад в деньги считается отдельно, а не приписывается автоматической проверке отчётов. Я это развожу жёстко: сверка данных отвечает за качество решений, а не за рост выручки. Чек-лист: с чего начать в понедельник Сравнить количество лидов в CRM с количеством уникальных телефонов/email за последнюю неделю — найти дубли на входящих точках. Выделить неатрибутируемые лиды отдельной категорией в отчёте и посчитать их долю за последний месяц. Разбить месячный план по лидам на недели и дни, отметить контрольные точки для отставания. Пересчитать стоимость лида по каждому каналу через число лидов, прошедших контроль качества, а не валовое. Проверить, можно ли технически разделить источники трафика (например, Google и Яндекс) — если нет, завести задачу на доработку интеграции отдельно от отчётности. Настроить простую ежедневную сверку через вебхук из CRM и дешёвую модель вместо часа ручной работы аналитика в день. Ни один из этих шести пунктов не требует покупки BI-платформы. Все они требуют часа-двух внимания к данным, которые уже есть в системе — и, судя по практике, именно там прячется больше денег, чем в новом канале трафика. Начните на этой неделе с малого: свяжите источник лида с фактом оплаты хотя бы вручную, по последним пятидесяти сделкам. Уже эта таблица покажет вам, где вы переплачиваете. Полная механика — в бесплатном курсе . Ваша первая версия должна ответить на один вопрос: какие ваши каналы приносят деньги, а какие только заявки. Не стройте систему — соберите ответ. Всё остальное вы достроите потом, когда поймёте, чего вам не хватает. Не ждите идеальных данных: ваша первая версия будет неточной, и это нормально. Она нужна не для отчётности, а чтобы вы увидели порядок величин и поняли, какие ваши каналы вообще стоит разбирать подробнее. ## Платёжный календарь: как собрать и вести, чтобы дефицит был виден заранее URL: https://davidgerstein.pro/blog/platezhnyj-kalendar/ Дата: 2026-06-16 Направление: Финансы Цифры: дефицит кассы ≈1,2 млн ₽/мес (≈10% выручки) · долг поставщику ≈800 000 ₽ · резерв 0 ₽ Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Что такое платёжный календарь и как он устроен Платёжный календарь — это таблица обязательств и ожидаемых поступлений, разложенная по датам на 4-8 недель вперёд. Не отчёт о том, что вы потратили в прошлом месяце, а прогноз того, что случится с деньгами на вашем счёте в конкретный день. Собирается он из двух списков: счета к оплате, зарплата, аренда, налоги — против сделок с датой оплаты по договору и вероятностью, что деньги придут вовремя. Отвечает он на один вопрос: хватит ли вам денег в день, когда надо платить. В компании на 40 человек расходы месяц за месяцем превышали выручку, дефицит кассы доходил до 1,2 млн ₽ — около десятой части месячной выручки, — и виден он был за месяц до дня зарплаты. Первую версию календаря вы соберёте за час в обычной таблице; автоматическая сводка через вебхук CRM и дешёвую модель — это 8-12 часов настройки и единицы долларов в месяц на вызовы. Если вы узнаёте о нехватке денег в день зарплаты — дело не в том, что деньги кончились внезапно. Дефицит не случается внезапно, он виден за месяц. Просто всё это время вы смотрите не туда: на остаток на счёте сегодня вместо графика обязательств на четыре недели вперёд. Я долго считал, что чувствую деньги компании и без таблицы: обороты в голове, платежи в памяти. Это работало ровно до месяца, когда финансовый директор рассчитал прибыль за период и распределил её между сотрудниками — а через две недели выяснилось, что денег на рекламу нет, и коллеге пришлось вносить личные средства, чтобы кампании не остановились. Дефицит был предсказуем ещё пятнадцатого числа. Никто не смотрел, включая меня. Резервного фонда не было вообще. Это не единичный случай, а системная ошибка. Другой финансовый менеджер брал деньги под зарплаты и дивиденды, не зная о критических периодах цикла поступлений — четырёх неделях, когда деньги уходят раньше, чем приходят. Проблема должна была стать видна ещё 15 мая. Стала видна в момент, когда платить было нечем. Платёжный календарь нужен именно на этот зазор — между «есть прибыль на бумаге» и «есть деньги на счёте в нужный день». Смотреть на деньги вперёд, а не назад — это управленческий навык, такой же осваиваемый, как чтение отчёта о прибыли. Им не рождаются: я освоил его позже, чем следовало, и заплатил за это несколькими нервными месяцами. Календарь — просто инструмент, который этот навык поддерживает. Не отчёт для красоты, а способ не оказаться в положении, когда вы узнаёте о проблеме в день выплат. Чем платёжный календарь отличается от отчёта о расходах Отчёт о расходах отвечает на вопрос «куда ушли деньги», платёжный календарь — на вопрос «хватит ли их через три недели». Это разные жанры: первый вы читаете после того, как всё случилось, второй — до. Ошибка, из-за которой у многих календарь не приживается, ровно в этом: его пытаются собрать из прошлых трат, а он строится из будущих обязательств и договорных дат оплаты. Разница видна на первом же решении. В одной компании плановые закрывающие платежи на июнь оказались заметно ниже плана. Чтобы компенсировать падение выручки, требовалось кратно нарастить продажи — задача, которую отделы могли не потянуть физически. Директор предложил осознанно входить в месяц с реальными цифрами вместо того, чтобы потом объяснять недовыполнение. Это и есть работа календаря: не подгонять факты под план задним числом, а увидеть проблему в начале месяца, когда ещё можно что-то сделать. В другой компании — производстве на заказ с отделом из 8 менеджеров и оборотом около 12 млн ₽/мес — средние ежемесячные расходы превышали выручку. Дефицит кассы по итогам месяца — около 1,2 млн ₽, то есть порядка десятой части месячной выручки. Этого не хватало даже на зарплаты. Цифра считается заранее, простым вычитанием обязательств из ожидаемых поступлений. Без календаря её видят в день, когда нужно платить. Выручка 12 млн ₽ Расходы выше выручки Дефицит ≈1,2 млн ₽ (~10%) На диаграмме — соотношение выручки, расходов и дефицита кассы за месяц (легендированные суммы). Механика: что → чем → куда за 4 шага Дальше — как это собирается у вас. Ничего сложного тут нет, и первую версию вы сделаете за час в обычной таблице. Я специально описываю руками, а не через сервис: пока вы не сведёте это сами хотя бы раз, вы не поймёте, что именно потом автоматизировать. Повторить эту схему может любая команда с CRM и таблицей. Она не требует смены системы учёта — только дисциплины и одного скрипта-связки. Что берём. Два списка: обязательства (счета к оплате, зарплата, аренда, налоги — с датой и суммой) и ожидаемые поступления (сделки с датой оплаты по договору и вероятностью, что деньги придут вовремя). Источник — CRM (Bitrix24, amoCRM) и банковская выписка. Чем считаем. Скрипт или модель раз в сутки сводит оба списка по неделям и считает разрыв: поступления минус обязательства. Для чистой агрегации без интерпретации хватает дешёвой модели — это не аналитика, а арифметика по структурированным данным. Куда попадает результат. В таблицу (Google Sheets) с условной раскраской: неделя в минусе — красная. Копия результата — в Telegram-чат финансиста и собственника, без дополнительных кликов. Кто и когда смотрит. Фиксированное время раз в неделю, не по требованию. В одной компании время финансового планирования специально перенесли с утра на 13:00 четверга — чтобы данные успевали собраться полностью до разговора, а не в процессе него. ИИ-связка: прогноз разрыва без ручного сведения таблиц Собирать вручную два списка и сверять их по неделям — рутина, на которой чаще всего врут глазами, а не деньгами: пропускают платёж, дублируют строку, забывают про вероятность оплаты. Модель хороша именно тут — и вовсе не потому, что «умная»: она просто не устаёт сводить одинаковые столбцы. Схема конвейера: Bitrix24-вебхук выгружает сделки со статусом оплаты и датой → Google Apps Script раз в сутки в 07:00 кладёт их в лист «receipts», а счета к оплате — в лист «obligations» → скрипт вызывает API дешёвой модели с промптом ниже → ответ пишется в лист «calendar» → строки с риском подсвечиваются условным форматированием → копия сводки уходит в Telegram-бота ответственному. Модель — дешёвая (класса gpt-4o-mini или аналог). Задача не требует рассуждений — это агрегация чисел по датам и сравнение с порогом. Дорогая модель здесь не даёт точности выше, только увеличивает счёт. Пример ответа модели на модельных (иллюстративных) данных: Так это выглядит в самом листе «calendar», куда скрипт кладёт ответ модели: Google Sheets — лист «calendar» -17% дефицит недели 01.06 к обязательствам 4 недели горизонт прогноза Неделя Обязательства Поступления Разрыв Статус 01.06 420 000 350 000 -70 000 риск 08.06 310 000 355 000 +45 000 норма Второй шаг конвейера — короткое уведомление человеку, а не сырой JSON. Для этого второй, тоже дешёвый, вызов модели превращает результат в текст для Telegram: Пример ответа: «Неделя с 01.06: дефицит ≈17% от суммы обязательств. Проверьте перенос платежей или поступление по сделке №118.» Инженерная обвязка. Всё крутится на бесплатном тарифе Google Apps Script (триггер по расписанию) плюс API дешёвой модели. Если вебхук Bitrix24 не ответил или структура данных не совпала с ожидаемой — скрипт не падает молча, а пишет строку ошибки в отдельную ячейку листа «log» и дублирует её в тот же Telegram-чат. Перезапуск ручной: кнопка в кастомном меню Sheets «Пересчитать календарь» вызывает тот же скрипт вне расписания. Никакого отдельного сервера не требуется — это тот же принцип, что описан в разборе про сдвиг дат в Битрикс24 : если источник данных врёт (сделки «мигрируют» на 18-36 часов при синхронизации), календарь унаследует эту ошибку, поэтому сверка версий обязательна на входе, а не после. Похожая дыра — не техническая, а процессная. В одной компании перенесённый платёж требовал повторного ручного инициирования заявки вместо автоматической обработки: платёж, согласованный на понедельник, просто завис, а рекламная кампания оказалась под угрозой остановки из-за нехватки денег на счёте. Календарь сам по себе такую дыру не закрывает — он показывает, что платёж должен уйти в конкретный день, но перенос даты обязан попадать в новую строку календаря автоматически, а не теряться между заявкой и исполнением. Где ломается Платёжный календарь не работает, если решения по нему принимает тот, кто не видит полной картины. Финансист, который распределяет деньги между несколькими счетами при остром дефиците ликвидности, обязан информировать руководство о разрыве и сроках — но не принимать самостоятельные решения по продажам или приоритетам. Смешение этих ролей превращает календарь в инструмент оправдания задним числом, а не прогноза. Учёт платежей: обоснование суммы важнее самой суммы Учёт платежей в календаре — это не список статей расходов, а привязка каждой суммы к дате и обоснованию. Показательный случай: компания запросила бюджет на видеомонтаж исходя из цены за штуку, но месячный итог получался значительным. Никто не смог назвать конкретное количество видео. Расход отклонили до уточнения объёма. Это базовое правило учёта: сумма без единицы измерения — не расход, а предположение. Ещё пример — увеличение лимита на проектную услугу. Обоснование звучало как «мы тратим больше, нам не хватает, поэтому давайте увеличим». Руководитель потребовал пересчитать лимит в привязке к росту выручки: выгрузить закрытые документы за базовый период, сравнить с текущим, проверить помесячный прирост количества и стоимости отдельно по регионам, найти аномалии в удорожании. Тот же паттерн — с фондом на регулярные расходы: сотрудник просил увеличение лимита в полтора раза, но не смог ответить ни на один вопрос о доходности этих денег. Решения не было, пока не появился расчёт «сколько заработаем на эти деньги». В платёжном календаре у каждой крупной статьи должно быть основание — количество единиц, привязка к выручке, а не факт прошлых трат. Без этого календарь превращается в дорогую таблицу с красивыми цифрами. Статья месяца Сумма / доля от бюджета Комментарий Продвижение сайта 300 000 ₽ (33%) Согласованный счёт Рекламные интеграции 300 000 ₽ (33%, два отдельных счёта) Суммарно сопоставимо с продвижением Резерв на маркетинг 300 000 ₽ (33%) Около трети всех расходов, не тратится без основания Итого согласуемых расходов 900 000 ₽ (100%) Полная сумма на месяц Остаток после авансов 225 000 ₽ (25%) Что реально останется в кассе Строка «остаток после авансов» — самая важная в вашей таблице. Именно её обычно и не считают, пока не наступает день зарплаты. Длинный цикл: почему календарь нужен тем более, чем дольше ждать оплаты Чем длиннее зазор между вашим расходом и поступлением денег, тем раньше нужен прогноз, а не факт. В одной услуге норматив прохождения от первого обращения до результата — около 5 месяцев (10 дней на подготовку, 10 рабочих дней на сбор данных от клиента, неделя на отправку подрядчику, 5 рабочих дней на финальный этап, плюс очередь у внешнего исполнителя — от 1 до 2 месяцев). Всё это время компания несёт расходы, а платёж приходит в конце. Тип цикла Срок до оплаты Что это значит для календаря Проектная услуга ~3 месяца Расходы авансируются, резерв обязателен Полный цикл с внешним подрядчиком ~5 месяцев Прогноз нужен минимум на квартал вперёд Рекламные площадки (директ) предоплата Задержка платежа сразу снижает отработку бюджета Последняя строка — не абстракция. В мае одной компании не хватило времени вовремя провести часть финансирования рекламных кампаний в директе. Из-за задержки площадки начали хуже отрабатывать бюджет — они изначально работают на предоплате, и просадка по деньгам сразу превращается в просадку по показам и кликам, которую потом не наверстать доплатой postfactum. Именно на длинном цикле резерв не создавали — и в апреле упёрлись в лимит, оказавшийся на порядок меньше нужного. После этого договорились откладывать 30% от прибыли на резервы. Решение правильное, но с опозданием: оно принято уже после того, как образовался долг перед поставщиком услуг на 800 000 ₽ — около 7% месячного оборота, — а не до. Резервы: прибыль на бумаге не равна деньгам в кассе Здесь я скажу вещь, которая вам не понравится. Если у вас нет резерва, ваш платёжный календарь — это график, по которому вы едете без тормозов: видно хорошо, остановиться нечем. Резерв — не про осторожность, а про право принимать решения спокойно, а не под давлением ближайшего платежа. «Мы не можем распределить всю премию, давайте подождём» — фраза, которая должна звучать до распределения, а не после того, как выяснится нехватка на маркетинг. В одном случае компания потратила из резерва 900 000 ₽ — около четверти годового резерва в 3,6 млн ₽ — на маркетинговую кампанию, и встал вопрос учёта: считать это текущими затратами или инвестицией. Ответ зависит от результата: окупилось продажами — показываем расход с доходом; убыток — списываем на резервы, не включая в месячные показатели. Это разграничение имеет смысл только тогда, когда резерв вообще существует. Есть и обратная крайность — экономия там, где она не нужна для расчёта разрыва, но нужна для порядка в мелких статьях. «Я не готова платить за хранение ёлки и новогодних игрушек» — фраза не про хранение, а про то, что мелкие нецелевые расходы съедают резерв незаметно, пока не заходит речь о крупных платежах. Другой случай — фонд на офисные расходы: выдали сумму с устным указанием вести реестр, а по факту из этих денег регулярно небольшими суммами платили дворнику кешем без единого согласования. Без реестра фонд превращается в чёрную кассу, и его нельзя учитывать в платёжном календаре, потому что его состояние никто не может подтвердить. Дебиторка и возвраты как часть календаря Платёжный календарь считает не только исходящие платежи. Входящие деньги — тоже прогноз, а не факт. Пример: клиент внёс предоплату криптовалютой, компания получила сумму примерно на 10% больше из-за курсовой разницы. Позже клиент потребовал полный возврат в течение суток. Решение — вернуть большую часть полученной суммы, удержав расходы и бонус, чтобы не доводить до суда. Такие возвраты, если их не фиксировать системно, искажают прогноз поступлений на следующий месяц. «Возвраты абсолютно никак не фиксируются, никто не ведёт, никто не отвечает. Нужен инструмент, нужен регламент» — эта фраза точно описывает дыру, из-за которой платёжный календарь становится неточным даже при аккуратном учёте расходов. Дебиторская задолженность требует того же подхода: ежедневный трекинг объёма, распределения по срокам возникновения и по типам услуг. Без этого руководитель видит остаток на счёте сегодня, но не видит, сколько денег реально придёт в ближайшие недели. Подробнее о системе без ручной сверки — в отдельном разборе про дебиторку и контроль без памяти людей . Такая же дыра — с реферальными вознаграждениями: партнёры задерживали информацию о выплатах до момента, когда клиент сам просил возврат денег. Решение заняло около 20 минут работы — настроить автоматическое уведомление в боте о закрытии проекта реферала, чтобы вознаграждение выплачивалось вовремя, а не по напоминанию. Маленькая правка того же типа, что и вебхук выше: не новая система, а закрытие дыры в существующей. Кто должен видеть календарь Вопрос, на котором спотыкаются чаще всего: показывать ли календарь команде. Мой ответ — да, в той части, которая касается их работы. Руководитель, который знает про узкую неделю, сам придержит закупку. Руководитель, который не знает, придёт к вам за деньгами именно в эту неделю — и будет прав, потому что откуда ему знать. Календарь бесполезен, если он лежит в одном файле у финансиста и никто, включая вас, в него не смотрит регулярно. Лечится это не призывом к дисциплине, а конструкцией отчётности: у показателя должен быть назначенный хозяин и известный срок обновления . В одном случае зарплата руководителя производства с января в среднем была значительно выше типичного уровня, но в худшем месяце упала в несколько раз ниже среднего. У другого руководителя в том же месяце разрыв был заметно меньше. Такая разница видна заранее, если данные о выручке и обязательствах открыты, а не всплывают в момент расчёта зарплаты. Та же логика — в контроле начислений. В одной компании возник спор: начислять бонус в момент подписания договора с клиентом или дожидаться платежа. Решили платить по факту получения денег, а не по факту обещания. Это тоже часть платёжного календаря — он должен быть завязан на реальное движение денег, а не на промежуточные события в CRM, которые могут не подтвердиться. Правило Платёжный календарь считается раз в неделю, в фиксированное время, с полными данными — а не по требованию собственника в момент, когда платёж горит. «Мне очень нужно, чтобы платёж подрядчику был оплачен, буквально за полчаса» — если такие сообщения регулярны, это не календарь, а тушение пожара с таблицей вместо ведра. Экономика: что это стоит и что даёт Внедрение считается в часах, не в новой системе. Настройка связки «вебхук CRM → Google Sheets → API модели → Telegram» занимает у толкового исполнителя 8-12 часов (оценка): подключить выгрузку, написать два промпта, настроить условное форматирование и уведомление об ошибке. Дороже всего — не код, а согласование, откуда именно брать «обязательства» и «поступления», чтобы обе стороны совпадали по смыслу. Эксплуатация обойдётся вам не в месячную лицензию, а в стоимость вызовов дешёвой модели. При ежедневном пересчёте и коротком JSON на входе счёт укладывается в единицы долларов в месяц: подробный разбор похожих счетов есть в материале сколько на самом деле стоит ИИ в месяц . Экономия тут не в цене токенов, а в часах, которые раньше уходили на ручное сведение таблиц. Формула для своего случая: часы ручной сверки в неделю × ставка часа × число недель в месяце = стоимость ручного труда в месяц. Оценка эффекта именно этого шага — без смешения с организационными решениями вроде «откладывать 30% в резерв» (это отдельная мера, её эффект в статье не считаем): если финансист тратит на ручной сбор и сверку данных для календаря около 6 часов в неделю (оценка), при 4 неделях в месяце это ≈24 часа трудозатрат в месяц — при ставке ~1 000 ₽/час это ≈24 000 ₽/мес ручного труда (оценка). Автоматическая выгрузка и агрегация снимает большую часть рутины — вручную остаётся только проверка аномалий, оценочно 30% времени, то есть ≈1,8 часа в неделю вместо 6. Экономия — около 70% времени на этой позиции, то есть ≈16 800 ₽/мес (оценка), не считая эффекта от более раннего обнаружения разрыва. Окупаемость: настройка в 8-12 часов при той же ставке ~1 000 ₽/час — это разовое вложение около 8 000-12 000 ₽ (оценка), которое окупается сэкономленным временем меньше чем за месяц (оценка). Дальше это уже чистая экономия времени, а не разовый эффект. 6ч/нед вручную 1,8ч/нед авто На диаграмме — часы ручной сверки данных в неделю до и после автоматизации (оценка). Отдельно — цена самого разрыва, если его не увидеть заранее. При расходах, превышающих выручку, ежемесячный дефицит около 1,2 млн ₽ (≈10% выручки) — это не разовая, а системная проблема. Без прогноза она решается экстренными кредитами «на всякий случай» каждый месяц, а не одним резервом, рассчитанным за 4 недели вперёд. С чего начать в понедельник Выгрузить из CRM и банка все обязательства на 4 недели вперёд — с точной датой и суммой, без усреднения по статьям. Собрать ожидаемые поступления с вероятностью оплаты, а не просто сумму сделки из карточки. Свести оба списка в одну таблицу по неделям и посчитать разрыв вручную хотя бы один раз, прежде чем автоматизировать. Назначить фиксированное время пересчёта раз в неделю — и не пересчитывать календарь по требованию «нужно оплатить за полчаса». Завести резерв отдельной строкой, которую нельзя тронуть без обоснования суммой и датой. Настроить хотя бы одно автоматическое уведомление о риске — бот, скрипт, письмо — чтобы разрыв не узнавали в день зарплаты. Скажу прямо: если у вас нет платёжного календаря, вы играете в рулетку с зарплатой своих людей. Не потому что вы плохой руководитель, а потому что человеческая память не умеет держать тридцать платежей с датами — она для этого не приспособлена. Сделайте первую версию на этой неделе. Обычная таблица, четыре недели вперёд, два столбца: приход и расход. На это уйдёт час, и уже он покажет вам недели, где вы ходите по краю. Автоматизация — потом, когда станет понятно, что именно автоматизировать. А если хотите сразу собрать это в рабочий контур — с автоматическим сведением и уведомлением о риске за две недели — механика разобрана в бесплатном курсе , вместе с остальным финансовым блоком. Мой личный опыт, для честности: календарь на четыре недели вперёд снял у меня ощущение постоянной тревоги за деньги. Не потому что денег стало больше — потому что исчезли сюрпризы. Мы у себя ведём календарь четвёртый месяц, и главное изменение не в деньгах, а в том, что я перестал узнавать о разрывах в день зарплаты. Этого одного хватило, чтобы привычка прижилась. ## Критерий оценки качества работы в звонке: пять вместо пятидесяти URL: https://davidgerstein.pro/blog/chek-list-ocenki-zvonka/ Дата: 2026-06-14 Направление: Контроль качества Цифры: 66 звонков ручной сверки · цена одной ошибки — до 2,4 млн ₽ (оценка) · 25% охват контролем вручную Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас есть чек-лист оценки звонков на пятьдесят пунктов — у вас нет чек-листа оценки звонков. У вас есть документ, который никто не заполняет честно, потому что заполнить его честно физически невозможно. Я через это прошёл. Мы начинали с длинного списка «всё, что важно», и получили ровно то, что получают все: контролёр ставит галочки не глядя, менеджеры считают оценку лотереей, руководитель не может объяснить, почему у одного 7, а у другого 8. Работать начало, когда осталось пять пунктов. Ниже — какие именно и почему. Критерий оценки качества работы: короткий ответ Рабочий критерий оценки качества работы менеджера в звонке — это пять проверяемых пунктов вместо пятидесяти: тип звонка определён верно, соблюдён регламент по срокам, соблюдён скрипт своего этапа сделки, отмечен тон коммуникации и зафиксирован результат в CRM. Каждый из пяти подтверждается цитатой из разговора — поэтому оценка не «гуляет» между прогонами. Пятьдесят пунктов добросовестно не проверяет ни человек, ни машина. Руками контроль закрывает около 25% разговоров, автоматическая оценка по короткому списку — 100% того же потока. Прежде чем убирать людей из контроля, сверьте машину с человеком на выборке в 66 звонков и посчитайте дельту отклонения. Отдел настраивал систему оценки звонков четвёртый месяц. Десять вариантов чек-листов под разные сценарии — первичный звонок, звонок продаж, вторичный контакт, встреча. Каждый месяц — доработки. Не потому что систему делали плохо. Потому что критерий оценки качества работы в звонке — это не строка в документе, а живая настройка, которая ломается на реальных звонках чаще, чем кажется на этапе презентации. Параллельно в другой компании посчитали цену вопроса иначе: стоимость одной пропущенной ошибки в контроле качества может достигать 2,4 млн ₽ на одном клиенте — это примерно 65% его годового контракта на услуги компании (оценка). При этом отдел контроля в лучшем случае прослушивает 25% звонков — не потому что работает плохо, а потому что физически не успевает больше. Это не абстрактный риск. Это разрыв между тем, сколько звонков реально требует проверки, и тем, сколько человек способен проверить руками за смену. Почему ваши пятьдесят пунктов не работают Посмотрите на свой чек-лист и честно ответьте: сколько времени займёт заполнить его добросовестно по одному разговору? Если больше пяти минут — его никто не заполняет добросовестно, включая вашего лучшего сотрудника. Классический чек-лист контроля качества звонков — это лист на пятьдесят строк: поздоровался, представился, уточнил имя, задал открытый вопрос, отработал возражение, предложил альтернативу, поблагодарил, попрощался. Каждый пункт логичен сам по себе. Проблема — в сумме. Человек физически не может держать в голове пятьдесят критериев, слушая живой разговор. Он либо сваливается в формальную галочку («вроде было»), либо тратит на один звонок пятнадцать минут вместо пяти. А 25% охвата вручную — это уже потолок ресурса, а не вопрос качества работы контролёров. В отделах с большей нагрузкой на менеджера этот потолок проседает и до 10% — предел зависит от общего потока звонков и штата контроля, а не от желания людей проверять больше. ИИ формально может оценить все пятьдесят пунктов за секунды. Но это не решает проблему — оно её маскирует. Если критерии размыты, модель по-разному оценивает один и тот же звонок при повторной обработке. «Оценка, она не всегда адекватна» — это не претензия к технологии, это диагноз чек-листу. Пятьдесят нечётких формулировок дают пятьдесят источников погрешности, которые складываются друг с другом. Правило Если чек-лист даёт разные результаты при повторной оценке одного и того же звонка — проблема не в модели, а в формулировках критериев. Сначала переписать чек-лист, потом доверять автоматике. Пять пунктов: рабочий критерий оценки качества работы Сверьте со своим списком. Если у вас нет хотя бы трёх из этих пяти — вы меряете не то, что влияет на деньги. На разных внедрениях всплывает один и тот же короткий список. Не потому что кто-то сознательно урезал критерии до пяти, — потому что именно эти пять реально влияют на деньги и повторяются в каждой рабочей системе контроля. № Критерий Что проверяет 1 Тип звонка определён верно Первичный лид, продажа, вторичный контакт, встреча — от этого зависит, какой чек-лист вообще применять 2 Регламент по срокам Сроки молчания, скорость первого ответа, отсутствие «зависших» диалогов дольше установленного норматива 3 Скрипт по этапу сделки Соблюдение обязательных блоков разговора для конкретного этапа, а не абстрактной «вежливости» 4 Тон и эмпатия Отдельный ежемесячный отчёт по недостаткам деловой коммуникации — не по каждому звонку, а по накопленной картине 5 Фиксация результата Итог звонка записан в CRM: следующий шаг, договорённость, дата повторного контакта Здесь нет пункта «улыбался ли голосом». Есть проверяемые вещи. Тип звонка либо определён, либо нет. Срок молчания либо нарушен, либо нет. Скрипт для этапа либо соблюдён, либо нет. Это бинарные или почти бинарные критерии — именно поэтому ИИ на них не «гуляет» между прогонами. Тон и эмпатия — единственный субъективный пункт, и его сознательно вынесли из потокового контроля в отдельный ежемесячный отчёт, который становится основой для обучения, а не для дисциплинарных решений по каждому звонку. То, что оценивается автоматически и в реальном времени, должно быть проверяемым фактом. То, что требует нюанса, — идёт в накопительную аналитику. Инженерная связка: как машина понимает, какой звонок оценивать Эта часть нужна вам, если вы будете ставить оценку на поток. Если пока оцениваете руками — пропустите, вернётесь позже: сначала должен заработать сам чек-лист, а уже потом его стоит отдавать машине. Как он встраивается в остальной контур, показано в разборе всей системы оценки разговоров целиком — от выгрузки записи до калибровки и отчёта. Прежде чем спорить о критериях, нужно решить более простой вопрос: система вообще должна понять, какой звонок из CRM брать в оценку. Первый звонок клиенту может быть холостым — не дозвонились. Следующий звонок система может не захватить, если менеджер не перевёл сделку на нужный этап. А заставлять менеджеров вручную двигать статусы ради того, чтобы система «увидела» звонок, — путь в саботаж. Рабочая схема конвейера выглядит так (на диаграмме — пять шагов, от вебхука Bitrix24 до финальной оценки чек-листа): 1. Bitrix24-вебхук на смену этапа шаг 1 2. Выгрузка аудио и ID шаг 2 3. ASR-транскрибация шаг 3 4. Дешёвая модель: тип звонка шаг 4 5. Дорогая модель: оценка шаг 5 Для встреч триггером служит заполнение обязательного поля с аудиозаписью на этапе «встреча проведена» — а не ручная отметка «оцени меня». Перед оценкой самого звонка система подтягивает контекст предыдущих контактов с этим же клиентом: иначе оценка вырывает разговор из истории и делает неверные выводы. Похожая проблема с кривыми входными данными разбиралась в статье о том, как CRM врёт с датами — если данные на входе нечестные, никакой чек-лист на выходе не спасёт оценку. Промпт: разделение на дешёвую и дорогую модель Классификация типа звонка — задача с 3–4 вариантами ответа, глубокий контекст не нужен. Для неё хватает дешёвого классификатора — он быстрый и почти не влияет на счёт за месяц даже при полном охвате звонков. Финальная оценка по чек-листу требует понимания контекста разговора, нюансов возражений и связи с предыдущими звонками — здесь оправдана более мощная модель с расширенным окном контекста. Структура входных данных для второго шага (передаётся из Google Sheets, куда предварительно попадают ID звонка, менеджер, тип и ссылка на транскрипт): Пример ответа модели: Так выглядит итоговый отчёт руководителя после полного охвата — не выборка, а поток всех звонков за день: Отчёт: оценка звонков — сегодня 140 звонков за день 100% охват оценкой ID звонка Менеджер Тип Срок Скрипт CRM d-88213 M-07 продажа d-88214 M-03 первичный Инженерная обвязка держится не на скрипте-энтузиасте, а на трёх правилах. Где крутится: серверная часть — Google Apps Script или облачная функция, дёргающая Bitrix24 REST API по расписанию раз в сутки; результаты падают в Google Sheets, из которого руководитель забирает выгрузку в личный кабинет. Как перезапускается: при обрыве на шаге транскрибации задание уходит в очередь повторных попыток с экспоненциальной задержкой, а не падает молча. Как сообщает об ошибке: в Telegram-канал руководителя автоматизации уходит алерт с ID звонка и кодом ошибки — тем же ботом, что шлёт алерты о задержках ответов менеджеров. Технический капкан, который стоил месяца доверия Транскрибация звонков обрезалась из-за лимита символов в ячейке таблицы. Модель получала неполный текст и делала вывод по обрубленному разговору — формально применяя правильный чек-лист к неправильным данным. Решение оказалось не в увеличении лимита, а в архитектуре: в таблицу сохраняется краткий фрагмент и ссылка на полный текст, который открывается отдельно. Мелочь, которая стоила месяца доверия к оценкам — и напоминание, что ошибка в инженерной обвязке иногда дороже ошибки в промпте. Про то, как разово недосмотренная строка кода обходится в деньги, — отдельный разбор в статье сколько на самом деле стоит ИИ в месяц . Калибровка: без разговора с менеджером чек-лист мёртв Это тот этап, который вы захотите пропустить. Не пропускайте: чек-лист, который менеджеры не приняли, они будут обходить, а не выполнять — и вы получите красивые цифры при неизменных продажах. Даже идеально составленный чек-лист не заработает, если менеджеры считают его произвольным. Рабочий формат — калибровочная сессия: руководитель разбирает с менеджером одну его встречу, показывает автоматическую оценку по чек-листу, и вместе обсуждают точки согласия и расхождения. Смысл не в том, чтобы менеджер «принял» оценку. Смысл в том, чтобы он помог её донастроить — указал, где чек-лист не учитывает специфику разговора, где критерий сформулирован криво. Без этого шага внедрение оценки звонков превращается в конфликт, а не в инструмент. Подробнее о том, как избежать сопротивления при запуске контроля звонков, — в статье про менеджеров против прослушки . Экономика: сколько стоит проверка и что она даёт Посчитайте свою цифру: сколько у вас звонков в месяц, сколько стоит час контролёра и какую долю потока он реально успевает. Разница между этой долей и сотней процентов — ваша зона неизвестности, и именно в ней происходит всё, о чём вы потом узнаёте от клиентов. Считайте на своём потоке: сколько звонков в месяц у вашего отдела и какую долю из них слышит хоть кто-то. Разница между этой долей и сотней процентов — это и есть зона, где ваши обещания клиентам живут без всякого контроля. Возьмём условный отдел из 8 менеджеров продаж, каждый закрывает в среднем 15–20 звонков в день — то есть от 120 до 160 звонков по отделу; для расчёта возьмём середину диапазона, 140 звонков в день. Ручная проверка одного звонка по расширенному чек-листу занимает 10–15 минут — усреднённая цифра из практики контроля качества, для расчёта возьмём середину, 12 минут (оценка). Формула для ручного 100% охвата словами: звонков в день × минут на проверку одного звонка ÷ 60 = часы, которые нужно закрыть контролёрам . На наших числах: 140 × 12 / 60 = 28 часов в день. При восьмичасовой смене это 28 / 8 = 3,5 ставки контролёра — с запасом на отчётность округляем до 4. Текущий охват в 25% (35 звонков в день из потока 140) укладывается ровно в одну смену: 35 × 12 / 60 = 7 часов — это и есть тот самый контролёр, который «физически не успевает больше». Чтобы закрыть оставшиеся 75% потока руками, нужны ещё 3 ставки. При условной ставке специалиста контроля качества (ориентировочная рыночная ставка для такой позиции) это 8 часов × 3 ставки × 22 рабочих дня — то есть дополнительно три полных ставки в месяц только на то, чтобы прослушивать, без учёта написания отчётов и обучения; в пересчёте на эксплуатацию модели это кратно больше стоимости обработки того же потока звонков автоматикой. Показатель Вручную (25% охват) С речевой аналитикой Звонков в обработке из потока 140/день 35 140 Часы контролёра в день 7 (в рамках смены) не требуется — обработка автоматическая Доп. ставки контролёров для 100% охвата нужно ещё 3 0 Доп. ФОТ в месяц на закрытие разрыва (оценка) ≈3 полных ставки — кратно дороже эксплуатации модели эксплуатационные расходы модели + риск инженерных ошибок (пример — до 35 000 ₽ за одну ночь из-за циклического запроса, оценка) Читателю, который хочет прикинуть свой случай: формула та же — поток звонков в день × минуты на ручную проверку ÷ 60 = часы; часы ÷ длительность смены = недостающие ставки; ставки × часы смены × своя ставка в час × число рабочих дней = ежемесячная стоимость закрытия разрыва руками . Подставьте свои цифры вместо 140 и 12 — порядок величины будет тем же. Если система хотя бы раз за период предотвращает ошибку катастрофического масштаба (по одной из практик — сумму порядка 2,4 млн ₽, около 65% годового бюджета клиента, оценка), это перекрывает многолетние издержки на разработку и эксплуатацию сразу. Но это редкий, единичный кейс, и его нельзя закладывать в среднюю экономику как регулярный эффект — поэтому основной расчёт выше идёт через операционные часы, а не через гипотетическую катастрофу. Речевая аналитика с автоматической классификацией и оценкой снимает потолок ручного охвата: 100% вместо выборочных 25% (в некоторых отделах — вместо 10%), без роста штата контроля. Экономический эффект здесь не в замене одного контролёра ИИ — это отдельный организационный шаг, который в разных компаниях планируют делать поэтапно и после проверки методологии, минимум за 3 месяца параллельной работы. В одной из практик по итогам такого перехода планируют отказаться минимум от двух штатных единиц контроля качества — но это управленческое решение после проверки методологии, а не автоматический результат внедрения чек-листа. Вклад именно чек-листа и оценки — в том, что охват растёт без пропорционального роста затрат на контроль, а не в том, что штат сокращается автоматически в день внедрения. На диаграмме — до и после внедрения речевой аналитики: 25% вручную 100% авто Охват контроля вырос с 25% звонков (35 из 140 в день, проверяемых вручную) до 100% при автоматической оценке — без увеличения штата контролёров. Обратная сторона — эксплуатационные расходы и риск инженерных ошибок. Один из внедрений столкнулся с циклическим запросом из-за ошибки в коде: за одну ночь это обошлось примерно в 35 000 ₽ (оценка). Сумма для месячного бюджета компании небольшая, но именно она стала поводом пересмотреть готовность системы к масштабированию — раз ошибка стоит денег на этапе теста, на проде она стоит больше. Детальный разбор счетов за подобный инструмент — в статье про контроль качества звонков без ОКК . Смешивать эффект этого инструмента с другими мерами — например, с параллельным пересмотром скриптов продаж — не стоит: вклад считается отдельно, иначе экономика получается дутой. Что я понял про сопротивление Когда мы вводили оценку, я ждал спора о критериях. Спора не было — было тихое сопротивление: менеджеры соглашались на планёрке и продолжали работать как раньше. Я разбирался месяц и понял простую вещь: они не верили, что оценка справедлива, и не могли это сказать вслух. Помогла не жёсткость, а прозрачность: мы стали показывать цитату из разговора рядом с каждым баллом. Когда человек видит, за какую именно фразу ему снизили балл, спорить становится не с кем — можно только согласиться или объяснить контекст, и оба варианта нам подходят. Тогда же я понял, чем это на самом деле является. Свести оценку к пяти пунктам, каждый из которых подтверждается цитатой, — это управленческий навык, а не работа контролёра. Руководитель либо умеет назвать пять вещей, за которые он отвечает деньгами, либо прячется за пятьюдесятью и называет это требовательностью. Если вы будете вводить это у себя — заложите на разговоры с командой столько же времени, сколько на настройку. У меня ушло примерно поровну, и я считаю это нормальной пропорцией. Стандарты обслуживания по телефону: что стоит за цифрами Сроки — часть любого чек-листа, но их легко занизить или завысить без реальных данных. В одной компании средний ответ на сообщение клиента — 8 часов, включая нерабочее время и сон, что требует отдельной проверки на честность метрики: если считать только рабочие часы, реальная скорость реакции может выглядеть иначе. Максимальный допустимый срок тишины — две недели, но ответ внутри рабочего дня требуется всегда. Это конкретные, измеримые нормативы — не «отвечать быстро», а число, которое можно проверить автоматически через тот же вебхук, что выгружает звонки. Отдельное правило для повторных касаний: если клиент молчит больше 24 часов после первого контакта — повторное сообщение через 4 часа, а если ответа нет и после этого — прописан следующий шаг сценария (вторая попытка, эскалация), а не открытый разбор без решения. Это тоже часть чек-листа, только не по звонку, а по цепочке коммуникации целиком. Перед тем как убирать людей из контроля, проверьте у себя адекватность самой автоматической оценки. В одном из внедрений за месяц прогнали 66 звонков параллельно через ИИ и через ручную оценку контролёра, посчитали дельту отклонения — и только после этого решали, готова ли методология к полному развёртыванию. Где ломается Внедрение оценки звонков без параллельного периода — минимум три месяца с двойной нагрузкой на бюджет — почти всегда даёт ложное чувство готовности. Система показывает цифры раньше, чем доказывает свою методологическую состоятельность. «Я не готов автоматизировать контроль качества, пока нет цифр и доказанной эффективности» — это не осторожность ради осторожности, это единственно рабочая позиция перед заменой людей автоматикой. Чек-лист на понедельник Выписать 2–3 реальных типа звонков в своей воронке — не десять, а именно те, что реально повторяются. Возьмите пять критериев из таблицы выше и адаптировать формулировки под свой скрипт продаж. Настройте выгрузку звонков из CRM по уникальным ID (сущность, менеджер, время), а не полагаться на ручные отметки этапов. Прогнать выборку в 50–70 звонков через ИИ и через ручную оценку, посчитать дельту отклонения. Проведите калибровочную сессию хотя бы с одним менеджером на каждый тип звонка. Только после совпадения оценок в 80–90% случаев — расширять охват и снижать долю ручного контроля. Это медленнее, чем «внедрить ИИ за неделю». Зато к моменту, когда систему используют для решений о премиях или увольнениях, она уже проверена, а не работает на веру. Что сделать на этой неделе: возьмите свой чек-лист (или составьте первый) и вычеркните всё, кроме пяти пунктов, каждый из которых можно подтвердить цитатой из разговора. Если пункт нельзя подтвердить цитатой — это не критерий, а мнение, и в оценке ему не место. Дальше — калибровка с менеджерами, иначе любой чек-лист мёртв. А как поставить на это машину, чтобы оценивались все звонки, а не выборка, — механика в бесплатном курсе . Сократите свой чек-лист до пяти пунктов на этой неделе и посмотрите, как изменится качество заполнения. ## Цели компании на год: от годовой цифры до задачи менеджера на неделю URL: https://davidgerstein.pro/blog/dekompoziciya-celej/ Дата: 2026-06-12 Направление: Стратегия Цифры: план года разошёлся с фактом больше чем в два раза · авансы 37-40% от выручки Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Цели компании на год: как поставить их так, чтобы они выполнялись Цели компании на год — это не одна цифра выручки в презентации, а цепочка: годовая сумма → каналы и их конверсии → месяцы → недели → задача конкретного менеджера, причём у каждого узла цепочки есть один ответственный. Без цепочки годовая цифра не управляет ничем: сделать «годовой план» в понедельник нельзя, можно сделать пять звонков и отправить два коммерческих предложения. Если у вас план на месяц получается делением годовой цифры на двенадцать — цепочки нет. Проверяется это за минуту, и проверять стоит: в компании на 40 человек годовая цель по стратегии и сумма в рабочем плане разошлись почти в два с половиной раза только потому, что никто не уточнил, о чём цифра — о выручке, об авансах (37–40% от суммы) или о сумме договоров. Знакомо: цели компании на год у вас есть — красивая цифра в презентации. Дальше её делят на двенадцать, спускают в отделы, и через квартал выясняется, что план не выполняется, а виноватых нет: каждый делал что мог. Почему модель перестаёт работать в первый же месяц — типичные ошибки построения . Деление на двенадцать — это не декомпозиция. Это способ переложить ответственность за недостижимую цифру на людей, у которых нет рычагов на неё повлиять. Нормальная декомпозиция отвечает на другой вопрос: что конкретно должен сделать менеджер в понедельник, чтобы годовая цифра стала реальной. Ниже — как её собрать. На встрече всплыла цифра: по стратегии компания должна дать определённую выручку за год. В плане, который лежал перед собственником, была заложена сумма меньше почти в два с половиной раза — и никто в комнате не мог сразу сказать, откуда она взялась. Потом выяснилось: непонятно, о чём вообще цифра — о сумме договоров или об авансовых платежах, которые составляют 37–40% от выручки. Если руководители называют один и тот же показатель разными числами, любое совещание по стратегии превращается в полтора часа спора вместо работы. Формула простая: часы спора × число участников × частота встреч в месяц = потерянное рабочее время. Возьмём консервативно: 1,5 часа × 5 участников × 4 встречи в месяц = 30 часов рабочего времени руководящего состава ежемесячно (оценка) уходит на споры про единицу измерения цифры, а не на решения. При ставке ~1 000 ₽/час это около 30 000 ₽ управленческого времени в месяц (оценка) — и это только цена одного повторяющегося недопонимания. Цели компании на год начинаются не с красивой дорожной карты, а с того, чтобы два человека в одной компании говорили об одном и том же, когда называют число. Дальше — механика: как годовую цифру довести до задачи конкретного менеджера на конкретной неделе так, чтобы он мог её выполнить, а не просто прочитать. Цели компании на год: зачем годовую цифру вообще разбирать на части Годовая цифра сама по себе не инструмент управления. Она — лозунг. Менеджер не может утром прийти на работу и сделать «годовой план» — он может сделать пять звонков, закрыть три сделки, отправить два коммерческих предложения. Между лозунгом и действием нужна цепочка промежуточных цифр. Эта цепочка и есть декомпозиция. Обычно она рвётся в двух местах. Первое — на стыке «выручка / авансы / договоры»: финансисты и продажники считают по-разному, и никто не сверяет, что цифры в презентации собственника и в отчёте бухгалтерии — про одно и то же. Второе — на стыке «стратегия / канал»: план говорит «нужно больше лидов», но не говорит, за счёт какого канала. Собственник в одном из разговоров сформулировал это прямо: «Я не говорю, за счёт чего. Я не говорю, пиши тексты или не тексты. Конечно, я хочу понимать, за счёт чего он даст больше лидов. За счёт SEO или за счёт SMM?» Вот и вся разница между целью и декомпозицией цели: одна называет число, другая — механику, как это число получить. Годовая цифра выручки: считать по каналам, а не делением на 12 Вот здесь у вас, скорее всего, и ломается. Проверьте: ваш план на месяц получен делением годовой цифры — или собран снизу, из каналов и их реальной пропускной способности? Первое — арифметика, второе — управление. Самая частая ошибка — взять годовую цифру и поделить на двенадцать месяцев. Получается ровная линия, которая не имеет отношения к реальности: сезонность, запуск новых каналов, выход менеджера на план — всё это она игнорирует. Работающая структура выглядит иначе. Сначала — совокупная картина на год: какой процент лидов даёт каждый канал (SEO, Telegram, платный трафик) и какая у каждого канала конверсия. После этого — детализация по годам с фиксацией прогресса. И только потом — тактические детали по месяцам и неделям. Собственник в одной из компаний потребовал именно такой пересборки, когда увидел презентацию, где годовые цифры выручки не совпадали с месячным бюджетом, а хронология источников вообще отсутствовала. Второй уровень декомпозиции — по рынкам. Если компания работает на нескольких географиях, агрегированная цифра «плюс 20% лидов» ничего не говорит: на одном рынке рост тянет SEO, на другом — партнёрские каналы, а SMM может не работать нигде из них. Собственник в такой ситуации настоял на том, чтобы план был детализирован по каждому рынку отдельно — с указанием, за счёт каких конкретных каналов ожидается прирост. Похожая логика — про то, как теряются деньги между маркетингом и продажами, — разобрана в статье «Лиды есть, продаж нет» : цифра сверху ничего не стоит, пока не разложена на конкретные точки провала. Кто за что отвечает после разбивки Декомпозиция без закрепления ответственности превращается в красивую таблицу без последствий. Когда руководитель обнаружил, что SEO-специалист не может назвать конкретные источники лидов из органического поиска — аналитика просто не была настроена на связку «запрос → страница → продажа», — он потребовал перестроить отчётность так, чтобы каждый исполнитель понимал, за какие именно результаты отвечает лично он. Тот же принцип сработал в истории с бонусами юристам за выигранное дело. Вместо того чтобы делить премию поровну между всеми, кто помогал, решение было простым: бонус за результат получает тот, кто официально отвечает за кейс, — это определяется явно и заранее. Остальные могут получить отдельное поощрение за помощь, но вне привязки к конкретному делу. Правило масштабируется на любую декомпозицию: один человек отвечает за узел, остальные помогают без ревности к похвале. Без явного ответственного любая ветка плана становится общей, а значит — ничьей. OKR в среднем бизнесе: где эта модель ломается Если вам продавали OKR как универсальное решение — читайте внимательно. В компании вашего размера эта рамка работает частично, и знать, где именно она развалится, дешевле, чем узнать это через квартал. OKR — цели и ключевые результаты — в среднем бизнесе работают ровно до момента, пока их не отдали на откуп инструменту, который умеет красиво писать текст, но не умеет считать. В одной ситуации команда сделала ИИ-модель для стратегического планирования по региональному филиалу. Прогноз выглядел убедительно: структурированный, с цифрами, с логикой роста. При проверке оказалось — не учтены бонусы продавцов, а прогноз объёма на следующий год ничем не обоснован. Собственник сформулировал проблему точно: «Стратегия выглядит убедительно, но содержит объективно бредовые вещи». ИИ-инструмент генерирует текст, который звучит правдоподобно, — это не то же самое, что текст, который считает правильно. Команда вернулась к ручному пересчёту для верификации и только потом стала внедрять автоматизацию поэтапно. Это правильный порядок: сначала проверка гипотезы на контролируемом сегменте, потом масштабирование. Та же логика применялась при обучении нейросети на реальных кейсах — сначала небольшая выборка кейсов с валидацией людьми, потом тест на ограниченной выборке, и только затем — полный запуск. Где ломается OKR и любая декомпозиция превращаются в фикцию, если цели формулирует инструмент без проверки человеком, который знает реальные ограничения бизнеса: премии, сезонность, ограничения по деньгам. Модель умеет писать убедительно, но не умеет знать то, чего нет в данных, которые ей дали. Для среднего бизнеса лучше работает трёхмесячная стратегия, а не годовой OKR-документ на полке. Собственник в одной компании требовал от новых руководителей именно так: определить критерии успеха заранее с вышестоящим руководством, разбить план по неделям и дням, согласовать показатели до начала периода, чтобы не было претензий по факту. Про то, почему стратегия должна быть рабочим документом, а не презентацией для отчёта, разобрано в статье «Стратегия как рабочий инструмент» . ИИ-связка: пересчёт по неделям без ручного сведения Скажу, как у нас: первые месяцы я сводил это руками по воскресеньям — час-полтора, и каждый раз с мыслью «надо автоматизировать». Автоматизировали, когда стало ясно, что мой час стоит дороже, чем вся эта сборка. Ручная сборка понедельного плана из данных по каналам — рутина, которая крадёт время у руководителя именно там, где он должен думать, а не сводить таблицы. Задача решается конвейером из двух моделей: дешёвая делает арифметику каждую неделю, дорогая раз в месяц проверяет логику на предмет тех самых «объективно бредовых вещей». Шаг 1. Источник данных — лист Google Sheets «Факт_каналы»: там еженедельно накапливаются лиды и конверсии по каждому каналу (SEO, Telegram, платный трафик) из CRM-выгрузки. Шаг 2. По четвергам, к моменту коммерческой встречи, скрипт собирает данные за неделю и отправляет их в дешёвую модель (например, недорогой классификатор из линейки GPT или Claude — задача чисто арифметическая, дорогая модель тут не нужна) с формулой темпа роста. Шаг 3. Результат — понедельный план по каждому каналу — падает в лист «План_декомпозиция», который видит руководитель на встрече. Шаг 4. Раз в месяц тот же массив данных плюс сама сгенерированная стратегия уходят в более дорогую флагманскую модель с задачей проверить допущения: учтены ли бонусы, обоснован ли прогноз, не завышена ли конверсия относительно факта прошлых месяцев. Пример ответа модели: Так этот прогноз выглядит на экране, который руководитель открывает по четвергам перед коммерческой встречей — лист «План_декомпозиция» с уже посчитанными цифрами и подсвеченным отклонением: Google Sheets — План_декомпозиция 4,19 сделок прогноз на неделю 55 лидов по трём каналам 1 канал в красной зоне Канал Лиды (прогноз) Сделки (прогноз) Статус SEO 20 1,6 норма Telegram 12 1,44 норма Paid 23 1,15 откл. 24% Инженерная обвязка простая и без лишних сущностей: Google Apps Script по триггеру каждый четверг в 9:00 забирает данные из листа, вызывает API дешёвой модели, пишет результат во второй лист и отправляет уведомление в Telegram-канал руководителя. Если API не ответил или JSON не парсится — бот присылает сообщение «декомпозиция не обновилась, проверь вручную» вместо того, чтобы падать молча. Раз в месяц отдельный скрипт собирает те же данные плюс текст стратегии и уходит в дорогую модель на ревью — это тот самый шаг, который спас команду от «объективно бредовых» цифр в кейсе с региональным филиалом. Обратная связь от руководителя, если план разошёлся с реальностью, фиксируется голосовым сообщением в тот же Телеграм-чат и используется как корректировка на следующую неделю — без этого механизм превращается в генератор красивых, но не проверенных цифр. Почему я перешёл на недели Мы долго жили месяцами: план на месяц, разбор в конце месяца. Проблема в том, что месяц — это слишком поздно. К моменту, когда вы видите провал, у вас остаётся ноль времени на исправление, и вы можете только объяснить его постфактум. Когда мы перешли на недельный ритм, изменилось не качество планирования, а скорость реакции: провал видно на седьмой день, а не на тридцатый, и у вас есть три недели, чтобы что-то сделать. Ваши менеджеры при этом начинают понимать связь между своей неделей и годовой цифрой — а без этого понимания любая декомпозиция остаётся вашей личной таблицей. Я долго считал это работой планового отдела, а не своей. Ошибался: разложить цели компании на год до недельной задачи — управленческий навык ровно того же порядка, что умение читать отчёт о прибылях. Ему нигде не учат, его набирают руками, и первые две-три попытки у вас выйдут кривыми — у меня вышли. Неделя как единица измерения: ритм, который держит декомпозицию живой Годовая и квартальная цифры не защищают от того, что реальность меняется быстрее, чем документ. Собственник одной компании обнаружил: отдел показал результат на 40% выше плана, но похвалить менеджеров нельзя — сама стратегия оказалась некорректной ещё на старте, потому что внешние факторы (новости, законодательство) поменяли спрос быстрее, чем план успели пересчитать. Решение — не переписывать стратегию каждые три недели вручную, а заложить в неё формулу вместо фиксированной цифры. Например: темп роста +5% ежемесячно — и при загрузке новых данных план пересчитывается автоматически. Так статичный документ становится динамическим и не устаревает сам по себе. На уровне недели декомпозиция держится на регулярном ритме отчётности. В одной компании ввели структурированный коммерческий отчёт по блокам — маркетинг, продажи, авансы — с фиксированным днём встречи, каждый четверг. Результаты накапливаются к концу недели и сводятся в одну таблицу. Это позволяет отличить системную проблему конверсии от локальной — например, от отсутствия конкретного менеджера в моменте. Трёхуровневый контроль клиентов Для декомпозиции цели по выручке в отделе продаж полезна не только табличная разбивка по каналам, но и контроль движения каждого клиента по воронке. Рабочая модель — три слоя: Уровень Что отслеживает Кто смотрит Карточка клиента Сроки, отклонения, статус (зелёный/жёлтый/красный) Менеджер Сводная таблица Количество и сумма по стадиям воронки Руководитель отдела Список красных клиентов Приоритетная работа с проблемными сделками Руководитель + менеджер Сводная таблица показывает, где узкое место — на входе лидов, на конверсии или на просроченных сделках. Похожий подход к тому, чтобы отчётность не зависела от памяти и добросовестности людей, разобран в статье про контроль дебиторки : система должна показывать проблему раньше, чем она станет критичной. Ваш горизонт: год → квартал → месяц → неделя Разложите свою цифру по этой лестнице и посмотрите, на каком уровне у вас обрывается связь с конкретными действиями. Обычно она обрывается на месяце — и именно поэтому ваши люди не понимают, что делать в понедельник. Собранная воедино модель декомпозиции выглядит как последовательность уровней, где каждый следующий проверяет предыдущий: Горизонт Что фиксируется Кто отвечает 5 лет Макростратегия, ожидаемые показатели по направлениям Собственник 3 месяца Мини-стратегия руководителя: критерии успеха, разбивка по неделям Руководитель направления Месяц Каналы, конверсии, план по авансам и договорам Руководитель отдела Неделя Коммерческий отчёт: маркетинг, продажи, авансы Менеджеры + руководитель заложено в план цель года На диаграмме — сумма, заложенная в рабочий план, и годовая цифра из стратегии: план оказался меньше почти в два с половиной раза. Пока непонятно, о чём именно цифра — о выручке, авансах или сумме договоров, — этот разрыв будет воспроизводиться на каждой сверке. Разрыв между строкой «стратегия» и строкой «рабочий план» — это и есть та самая нестыковка, из-за которой руководители на встрече не могли сойтись на едином числе. Пока разница не объяснена (валюта, авансы или договоры), любые понедельные цифры внизу цепочки будут собирать несопоставимые данные под одним названием. Дорожная карта на уровне команды работает по той же логике. В одной компании на завтра было намечено ровно три приоритета: профили сотрудников, структура отчётности, детализация этапов работы — не десять пунктов «на будущее», а три конкретных, которые можно закрыть за день. Похожая логика масштабирования по времени применялась и при найме: отдел продаж расширяли в два раза не одним набором, а небольшими партиями каждый понедельник, из которых оставалась часть; за несколько недель численность выходила на целевую. Экономика: что стоит собрать декомпозицию Ваши затраты здесь — время, а не деньги: два-три вечера на первую версию и час в неделю на поддержание. Ваша цена бездействия считается просто: возьмите разницу между планом и фактом за прошлый год. Часть этой разницы — не рынок и не лень команды, а то, что люди не понимали, какое их действие на неё влияет. Стоимость внедрения такого конвейера — не про закупку системы, а про время. Настройка листа Google Sheets, скрипта на Apps Script и промпта для дешёвой модели занимает у толкового аналитика примерно 6–10 часов разово (оценка) — меньше одного рабочего дня. Эксплуатация: вызовы дешёвой модели раз в неделю обходятся на порядки дешевле одного часа работы аналитика — счёт идёт на копейки при трёх каналах данных. Ежемесячная проверка дорогой моделью добавляет к этому долю процента от той же часовой ставки — расход, которым можно пренебречь на фоне остального бюджета. Итого поддержка конвейера обходится в разы дешевле, чем цена одного совещания, где руководители спорят, о какой цифре идёт речь: разовая настройка укладывается в рабочий день, ежемесячная поддержка — в минуты, против 30 часов (≈30 000 ₽, оценка) управленческого времени, которую компания теряет каждый месяц на пустые споры про единицу измерения цифры, с которых начался этот текст. Дальше эта разница окупает саму систему в первый же месяц эксплуатации. Чек-лист понедельника: с чего начать разбор годовой цифры Сверьтесь с финансистом: годовая цифра в стратегии — это выручка, авансы (37–40% от суммы) или сумма договоров? Зафиксировать письменно. Разбейте годовой план по каналам — сколько лидов и какая конверсия ожидается от каждого источника, а не «плюс 20% лидов» одной строкой. Назначьте одного ответственного за каждый узел декомпозиции: канал, рынок, неделю. Без ревности к похвале, но с ясной точкой спроса. Заведите лист «Факт_каналы» в Google Sheets и настроить еженедельную выгрузку из CRM — без этого нечего будет считать автоматически. Заложите в план формулу роста (например, +5% в месяц) вместо фиксированной цифры — чтобы план пересчитывался при новых данных, а не устаревал за квартал. Поставьте ежемесячную проверку сгенерированного плана дорогой моделью или человеком — на предмет бонусов, сезонности и ограничений по деньгам, которых нет в сырых данных. Проверьте себя одним вопросом: может ли ваш рядовой менеджер объяснить, как его недельная работа связана с годовой целью компании? Если нет — декомпозиции у вас нет, есть спущенный план. Разница видна в момент, когда что-то идёт не так: при декомпозиции понятно, где именно провалилось, при спущенном плане — только то, что «не выполнили». Соберите первую версию на этой неделе: годовая цифра → каналы → недельные показатели → действия конкретных людей. Это два часа работы, которые снимут половину вопросов на планёрках. Как автоматизировать пересчёт и не сводить это руками каждую неделю — в бесплатном курсе . Мы у себя проверяем связь так: любой сотрудник должен за минуту объяснить, как его неделя влияет на годовую цифру. Если объяснить не может — это наша недоработка, а не его. ## Цикл сделки в CRM: почему средняя цифра врёт и как найти сделки без движения URL: https://davidgerstein.pro/blog/zavisshie-sdelki-v-voronke/ Дата: 2026-06-10 Направление: Продажи Цифры: 1,5 года без движения · встреча 55% → договор 22% · факт продажи заметно ниже плана (неделя) Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Что такое цикл сделки и почему средняя цифра врёт Если вы не можете назвать за минуту, сколько сделок в вашей CRM не двигались дольше месяца, — средний цикл сделки в вашем отчёте посчитан вместе с ними и не значит ничего. Цикл сделки — это срок от первого контакта до оплаты, и мерить его надо не в среднем по воронке, а по нормативу каждой стадии: у квалификации свой срок, у стадии «ждём документы от клиента» — свой. В разобранном случае один клиент простоял в статусе «переговоры» полтора года, а доля таких сделок в пайплайне — около 10%. Пока они лежат в общей воронке, цикл сделки завышен, прогноз по срокам сыпется, а деньги, за которые уже заплачено рекламой и временем менеджера, числятся «в работе». Видно это становится после трёх полей в карточке: дней в статусе, дата последнего контакта, норматив срока стадии. Деньги, о которых все забыли, лежат не в новых заявках — они в вашей воронке. Не потенциальные — почти ваши: клиенты, которые интересовались, обсуждали условия и просто перестали отвечать. Вы за них уже заплатили — за рекламу, за звонки, за время менеджера на встрече. Пока они висят в статусе, выручки они не приносят, зато исправно тянут вверх цифру, по которой вы планируете месяц. Как это устроено, разобрал отдельно: процент от прибыли, который перестали платить . У одной компании клиент завис в CRM в статусе «переговоры» на полтора года. Не отказ, не пауза с пометкой — просто висел. Каждый месяц эта зависшая сделка попадала в отчёт по срокам работы с клиентами и портила среднюю температуру по больнице: аналитик считал средний цикл сделки, а полтора года без движения тянули цифру вверх так, что реальная картина исчезала. Руководитель предложил простое решение — вынести такие сделки в отдельную воронку. Не удалить, не забыть, а перестать мешать ими считать остальных. Отдельный разбор на эту тему: потерянные заявки . Проблема — не один забытый клиент. Это про то, что база растёт, а вы теряете зрение: не видите, где деньги застряли, а где их уже нет. И чем больше отдел, тем быстрее зрение садится. Отдел из пятнадцати менеджеров при обороте около 9 млн ₽/мес и среднем чеке порядка 60 тыс. ₽ — это несколько сотен позиций в воронке. Если хотя бы десятая часть из них зависла (оценка доли, на практике часто выше), это несколько десятков сделок, которые числятся «в работе», а по факту не существуют — и никто не считал, сколько денег в них заморожено. Если вы прямо сейчас не можете назвать эту сумму по своей воронке — она уже работает против вас: вы платите за новых клиентов, стоя на старых. Зависшая сделка — это не отказ и не потеря Разница простая. Отказ — клиент сказал «нет», сделку можно закрывать. Потеря — вы прозевали момент, и клиент ушёл к другому. Зависшая сделка — это состояние неопределённости: никто не сказал «нет», но и движения нет. Она живёт в статусе месяцами, потому что менеджеру неудобно её закрыть (жалко бросать) и неудобно её толкать (непонятно, чем). Проблема не в том, что такие сделки существуют — они будут всегда. Проблема в том, что они искажают всё остальное: среднюю длину цикла сделки — если считать её вместе с «висяками», прогноз по срокам закрытия сыпется; конверсию по стадиям — сделка числится «в работе», хотя фактически из воронки выпала; загрузку менеджера — в отчёте у него много активных клиентов, а реально с половиной он не общался месяцами. Один такой клиент в отчёте почти не заметен. Пара десятков таких клиентов на отдел из пятнадцати человек — это около 1,2 млн ₽ подвисшего пайплайна (около 20 сделок × средний чек 60 тыс. ₽, оценка), который не существует, но занимает место в статистике и в голове менеджера, когда он планирует свою неделю. Как считать цикл сделки по стадиям: дашборд и светофор В одной компании руководитель поставил задачу построить отчёт по воронке, обновляемый ежечасно. Логика: для каждого менеджера видно клиента, текущий статус, дату создания сделки, количество дней в этом статусе — и индикатор-светофор на основе нормативных сроков по стадиям. Зелёный — в пределах нормы, жёлтый — превышение, красный — сделка мертва по всем признакам, кроме статуса в CRM. Соль тут в слове «нормативных». Норматив свой для каждой стадии и своей воронки. Для звонка-квалификации это может быть два дня, для стадии «ждём документы от клиента» — две недели, для крупной сделки с согласованием — месяц. Если применить один универсальный порог ко всей воронке, светофор либо будет всегда красным, либо никогда — оба варианта бесполезны. Цвет Что значит Что делать Зелёный Сделка движется в пределах нормы для стадии Ничего, оставить менеджеру Жёлтый Срок стадии превышен, но контакт был недавно Напоминание менеджеру, разбор на планёрке Красный Срок сильно превышен, контакта не было давно Разбор причины паузы: реанимация, перенос в отдельную воронку или закрытие Так этот отчёт выглядит на экране РОПа — не таблица цифр, а живой список сделок с цветным статусом на каждой строке: Воронка · светофор по стадиям 240 сделок в пайплайне 24 зависших (10%) 540 макс. дней без движения Клиент Стадия Дней в статусе Статус ООО «Вектор» Переговоры 18 Иванов А. Ждём документы 21 ИП Соколова После встречи 47 ООО «Гранд» Переговоры 540 Отдельно нужен дашборд по договорам: менеджер, клиент, сумма, дата выставления счёта, была ли встреча. Это отвечает на вопрос, который иначе тонет в общих цифрах: сделки закрываются после встречи или без неё, и на каком именно клиенте застрял конкретный договор. В одной компании такой отчёт собрали в единый портал вместо разрозненных таблиц — просто потому, что вести два отчёта дороже, чем один с фильтрами. Про то, что CRM сама по себе может показывать неверные даты — отдельная тема, я разбирал её в статье про сдвиг дат в Битрикс24 . Если светофор строится на датах, а даты сдвигаются, светофор врёт вместе с ними — это стоит проверить до того, как строить отчёт, иначе вся механика ниже работает на кривых входных данных. Почему сделки зависают: не всегда виноват менеджер За неделю в одной компании факт продажи заметно отстал от плана. Закрыта примерно половина запланированных сделок, конверсия продажи заметно ниже плановой. При этом конверсия во встречу — 55% (несколько десятков встреч проведено), а из встречи в договор — только 22%. Люди доходят до встречи нормально. Проблема — на стадии между встречей и договором. Именно там сделки чаще всего зависают: клиент выслушал, кивнул, взял паузу «подумать» — и дальше тишина. На диаграмме видна именно эта просадка — конверсия рушится не на входе в воронку, а на переходе от встречи к договору. Конверсия во встречу 55% Встреча → договор 22% Конверсия продажи, план план выше факта Конверсия продажи, факт факт ниже плана Причины паузы разные, и лечатся они по-разному: клиент хочет посоветоваться — нужен не звонок с напоминанием, а материал, который он покажет второй стороне; клиент не готов платить сейчас — реактивация должна прийти не сразу, а через месяц-два, когда ситуация изменится; клиент разочаровался в качестве общения с конкретным менеджером — тут реанимация должна идти от другого человека, иначе сделка просто зависнет второй раз. В одной сделке клиент дал согласие на комплексную услугу с заметным чеком, оба супруга оставили повторные заявки, перезвонили руководителю продаж с благодарностью — а в понедельник объявили паузу для «стратегического решения» и попросили не давить. Это не отказ и не зависшая в классическом смысле сделка, но именно из таких пауз чаще всего вырастают полугодовые «висяки»: клиент реально заинтересован, но никто не поставил ему напоминание через месяц, и сделка тихо ушла в тень. Здесь ошибаются все, включая меня. Я сам годами читал воронку по количеству сделок, а не по времени: вижу «переговоры» — значит, менеджер работает. Не работал. Мне было проще верить статусу в карточке, чем спросить, когда с этим клиентом последний раз реально разговаривали, — и потом я же считал средний цикл сделки по цифрам, в которых сидел полуторагодовалый «Гранд». Это не халатность и не лень. Это нормальная слепота руководителя, у которого нет под рукой одного столбца — «дней в статусе». Лечится он не выговором менеджеру, а этим самым столбцом. Правило Зависшая сделка старше полугода не должна учитываться в той же воронке, что живые сделки. Она либо переносится в отдельную воронку для длинных случаев, либо закрывается с явной причиной. Смешивать её с текущим пайплайном — значит врать самому себе о скорости продаж и о реальной длине цикла сделки. Реанимация: тест на «паузниках» перед атакой на активную базу Одна компания сделала ИИ-бота для реактивации: он анализирует историю переписки с клиентом, определяет вероятную причину паузы и выбирает тон сообщения — не одинаковый шаблон всем, а разный подход под ситуацию. Дальше бот контролируемо пингует клиентов из зависших сделок целевыми сообщениями. Логика запуска мне понравилась: тестировать сначала на «паузниках», а не на активной базе. Если бот сформулирует неудачное сообщение, риск — потерять клиента, который и так стоит без движения, а не испортить отношения с тем, кто ещё активно ведёт переговоры. Похожий подход, только вручную, я видел в другой компании: неготовые лиды не закрывают сразу, а переводят в резерв на два-три месяца, и потом их берёт в работу другой, более опытный менеджер. За два года практики там сложилась чёткая картина: клиенты «подостывают», но новый голос и новый контакт снова включает интерес. Это работает именно потому, что реактивация не давит — она приходит через паузу, достаточную, чтобы обстоятельства клиента могли измениться. Кейс с 7-летней базой Самый показательный пример — компания подняла базу лидов, которые отказали ещё семь лет назад: не готовы платить, не готовы разговаривать, заявку не оставили. В марте эти же клиенты вернулись и купили на сумму, заметную для месячного оборота отдела — по грубой прикидке, сопоставимую с ≈1–1,5 млн ₽ (оценка). Общий признак у всех: раньше они брали трубку и общались, просто попали к менеджерам низкой квалификации. То есть отказ был не в продукте и не в клиенте — он был в качестве разговора. Компания теперь готовит отдельное предложение с автоматическим инструментом реактивации именно под этот сегмент — тех, кто когда-то отвечал на звонки, но не дошёл до сделки. Как шёл этот подъём по дням и что он принёс — дневник реанимации базы . Вывод из этого кейса простой: реанимация клиентской базы работает не потому, что вы напомнили о себе, а потому что вы исправили то, что сломалось в первом контакте. Если причина отказа была в слабом менеджере — второй заход с сильным менеджером даёт результат. Если причина была в продукте или цене — тот же заход с тем же предложением просто повторит отказ. Результат в этом кейсе дала связка «новый менеджер + давность контакта + сам факт повторного касания» — три фактора смешаны, и без А/Б-разбивки по сегментам нельзя сказать, какой из них внёс больший вклад. Это стоит учитывать при оценке, что именно сработает на вашей базе: инструмент реактивации без замены менеджера может дать заметно меньший эффект, чем в этом кейсе. ИИ-связка целиком: конвейер реактивации без спама Схема, которую можно повторить на своей CRM, выглядит так: CRM (у меня — Bitrix24) по правилу автоматизации триггерит вебхук, когда сделка не менялась дольше нормативного срока стадии; внешний сценарий (n8n, Make или свой сервер) забирает через REST API историю переписки и метаданные сделки; эти данные уходят в LLM с промптом на определение причины паузы, тона и черновика сообщения; ответ модели записывается в поле сделки и превращается в задачу менеджеру на подтверждение — сообщение не уходит клиенту само, менеджер видит черновик и одобряет или правит; каждый вызов логируется в отдельную таблицу мониторинга, чтобы было видно, сколько сделок обработано и сколько реактиваций подтверждено. Модель на этом шаге — дешёвая (класса GPT-4o-mini или аналог). Задача классификационная и шаблонная: определить одну из нескольких типовых причин паузы и подобрать один из нескольких тонов. Дорогая модель здесь не даёт прироста качества, зато на заметном месячном объёме сделок ощутимо увеличивает счёт. Разбор того, сколько вообще стоят разные модели в проде, я делал отдельно — это тема для другого материала, здесь важно только само правило: чем более рутинная классификация, тем дешевле должна быть модель под неё. Пример ответа модели на такой запрос: Инженерная обвязка простая и без магии. Триггер на «нет изменений N дней» — бизнес-процесс в CRM, вызывающий вебхук раз в сутки батчем, а не в реальном времени: это дешевле и не создаёт гонки при массовом обновлении сделок. Сценарий забирает историю через методы вроде crm.timeline.comment.list и crm.deal.get , отправляет промпт в LLM API, результат пишет обратно в пользовательское поле сделки через crm.deal.update и создаёт задачу менеджеру. Если вызов API упал по таймауту — три повтора с задержкой, и если не помогло — сообщение об ошибке с deal_id в рабочий чат, а не молчание. Сценарий идемпотентен: при следующем суточном триггере он повторно берёт сделки с флагом «не обработано», так что пропущенный день не теряет данные, а просто обрабатывается позже. Экономика: что это стоит и что даёт Настройка дашборда со светофором — оценочно 8–15 часов, конвейер реактивации поверх CRM — ещё 10–20 часов, эксплуатация на дешёвой модели держится в пределах 300–600 ₽ в месяц (оценка), а потенциальный эффект реанимации одной партии зависших сделок — ≈317 000 ₽ (оценка, верхняя консервативная граница). Разберём по шагам. Стоимость внедрения — это в первую очередь часы, а не деньги на подписки. Настройка дашборда со светофором по стадиям — оценочно 8–15 часов работы аналитика или интегратора CRM, в зависимости от того, сколько воронок и нормативов нужно завести. Настройка конвейера реактивации поверх готовой CRM — ещё 10–20 часов на вебхук, промпт и логирование, плюс тестовый прогон на «паузниках» перед масштабированием. Эксплуатация на дешёвой модели недорогая. Если в месяц через конвейер проходит несколько сотен зависших сделок, а на каждую уходит порядка 1500 входных токенов (история переписки плюс промпт) и 300 выходных, суммарный расход выходит на уровне нескольких сотен тысяч токенов в месяц. При тарифе дешёвой модели, который на порядок ниже, чем у топовых моделей того же класса, это выходит в пределах 300–600 ₽ в месяц по прямой стоимости токенов с учётом курсовой наценки и накладных расходов провайдера — не отдельная статья бюджета, а строка внутри существующих расходов на LLM-инструменты. Формула для своей оценки: (число зависших сделок в месяц) × (токены на сделку) × (цена за токен у вашего провайдера) — подставьте свои цифры и посчитайте порядок суммы до внедрения, а не после. Теперь про эффект в деньгах, отдельно от затрат на внедрение. Возьмём цифры из начала статьи: отдел из пятнадцати менеджеров, оборот ~9 млн ₽/мес, средний чек ~60 тыс. ₽, недельный план продаж отдела — около 2,25 млн ₽ (оценка на базе оборота). При десятой части пайплайна, зависшей на практике часто больше, и при допущении, что конверсия из зависшей сделки в оплату после реактивации не выше конверсии «встреча → договор» из фактуры (22%), расчёт по формуле (число зависших сделок) × (средний чек) × (22%) при 24 зависших сделках даёт: 24 × 60 000 ₽ × 0,22 ≈ 317 000 ₽ потенциального эффекта реанимации этой партии (оценка, консервативный сценарий, верхняя граница). Важная оговорка: эта величина — эффект всего контура «дашборд нашёл + бот классифицировал причину + менеджер довёл до сделки» целиком, а не одного инструмента. Дашборд без реактивации даст только видимость проблемы, реактивация без дашборда будет бить по случайным сделкам вместо реально застрявших — 22% конверсии реалистичны только при обеих частях контура вместе, и то как верхняя, не гарантированная граница. 0 без системы ≈317 000 ₽ потенциал Без дашборда и реактивации зависшие сделки просто лежат в воронке. С полным контуром — потенциальный эффект реанимации этой партии, ≈317 000 ₽ (24 сделки × 60 000 ₽ × 22%), консервативная верхняя оценка. Формула для своего случая словами: (число зависших сделок) × (средний чек) × (ожидаемая конверсия реактивации, консервативно — не выше вашей конверсии «встреча → договор») = потенциальный эффект партии. Число зависших сделок берётся не «на глаз», а по факту после первой выгрузки фильтром по дате последнего изменения — иначе вся формула строится на предположении, а не на данных. Отдельно — стоимость ручного поиска зависших сделок без дашборда. Если РОП тратит на просмотр воронки и выписывание «висяков» вручную 3 часа в неделю при ставке ~1000 ₽/час, это около 12 часов и ~12 000 ₽ в месяц просто на то, чтобы найти проблему, — до того, как её начали решать. Дашборд со светофором сокращает это время до 10–15 минут просмотра готового отчёта, то есть экономит РОПу практически весь этот ресурс времени каждый месяц, не считая эффекта от найденных сделок. Что мы не считаем эффектом: часы, которые менеджер тратил на «висяк», после внедрения дашборда просто перераспределяются на другие сделки — это не прямая экономия в деньгах, а освобождённый ресурс времени, который ещё нужно конвертировать в новые продажи. Показатель Без дашборда и реактивации С дашбордом и контролируемой реактивацией Время РОПа на поиск «висяков» в месяц ~12 часов / ~12 000 ₽ ~1 час / ~1 000 ₽ на просмотр готового отчёта Зависшие сделки в пайплайне 15 менеджеров около десятой части, не выделены и не видны та же доля, выделена светофором и распределена по причинам Потенциальный эффект реактивации этой партии 0 (сделки просто лежат) ≈317 000 ₽ (верхняя консервативная граница) Затраты на внедрение — ~18–35 часов разово + 300–600 ₽/мес на токены LLM Как не наплодить новых зависших сделок Есть соблазн решить проблему массовым пингом всей базы разом — благо технически это дёшево. В одной компании была история: в мае отдел отвлёкся на апсейл и почти не звонил новым контактам — звонков сделали в разы меньше плана. Зато повторное касание по тёплым лидам из апреля дало несколько рекомендаций. Вывод руководителя: одного касания недостаточно, нужна регулярная, а не разовая работа с базой. Разовая массовая реактивация без системы просто создаёт новую партию зависших сделок — теперь уже «зависших после реактивации», и с клиентом, у которого накопилось раздражение от двух неудачных контактов вместо одного. Чтобы это не повторялось, нужны три вещи одновременно: регулярный, а не разовый цикл касаний по резервной базе — с интервалом, а не единым днём рассылки; привязка реактивации к нормативному сроку стадии, а не к «когда вспомнили»; фиксация причины паузы в CRM, чтобы второй заход не повторял ошибку первого. Ещё одна вещь, которую легко упустить: если реактивацией занимается тот же менеджер, что довёл сделку до зависания, шанс повторить сценарий выше, чем если подключить другого человека — живого или бота. Про то, почему менеджеры вообще перестают доводить сделки до конца и как это чинить без репрессий, я писал отдельно — см. про менеджеров, которые не ведут CRM . А если проблема шире — лиды идут, а до продажи не доходят системно — стоит смотреть не только на зависшие сделки, но и на всю воронку целиком, этому посвящена статья про лиды есть, продаж нет . Где ломается Автоматическая реактивация без сегментации по причине паузы превращается в спам с человеческим лицом. Клиент, который замолчал из-за цены, и клиент, который замолчал из-за плохого менеджера, не должны получать одинаковое сообщение — иначе вы просто ускорите второй отказ. Второй частый сбой — светофор строится на «дате последнего изменения» в CRM, а поле обновляется автоматически при любом техническом действии, включая смену ответственного. Тогда красная сделка внезапно становится зелёной без единого реального контакта с клиентом, и всё построение теряет смысл. Чек-лист: с чего начать в понедельник Выгрузить из CRM все сделки, которые не менялись дольше двух нормативных сроков стадии — без ИИ, просто фильтр по дате последнего изменения. Разбить список на три корзины: старые (более полугода), тёплые с понятной причиной паузы, тёплые без понятной причины. Старые вынести в отдельную воронку тем же днём, чтобы аналитика по срокам цикла перестала врать. По тёплым сделкам выписать причину паузы — спросить у менеджера, если она неочевидна из переписки, — прежде чем писать хоть одно реактивационное сообщение. Задать нормативный срок по каждой стадии воронки хотя бы вручную в таблице: без него светофор строить не на чем. Запустить реактивацию сначала на десятке-двух самых старых «паузников», а не на всей базе — оценить долю ответивших, прежде чем масштабировать конвейер дальше. Выгрузите свои сделки без движения дольше двух недель и посчитайте их сумму. Обычно эта цифра сопоставима с месячным планом — и работа с ней стоит вам ноль рублей на привлечение. Смотреть на воронку по времени, а не по числу карточек, — такой же базовый навык руководителя, как читать остаток на расчётном счёте. Спросить машину «покажи всё, что стоит дольше нормы для своей стадии» и получить список за секунду — это уже не про CRM и не про ИИ, это про то, сколько вы стоите как управленец. Тот, кто держит эти 24 сделки перед глазами каждую неделю, дороже того, кто узнаёт про 540 дней простоя из чужого отчёта раз в квартал. Я считаю, разрыв между этими двумя руководителями будет расти быстрее, чем разрыв в знании инструментов. Как поставить реанимацию на поток и не терять сделки заново — в бесплатном курсе для руководителей . Ваш регулярный ритуал после первой чистки: раз в неделю смотреть список сделок без движения дольше двух недель. Пять минут вашего времени — и ни одна сделка больше не зависает на месяцы. Заведите этот список у себя на этой неделе — и посмотрите, сколько ваших денег в нём лежит. Мы у себя нашли в таком списке сумму, сопоставимую с месячным планом, — и половину из неё удалось вернуть в работу за две недели. ## Автоматизация заявок: от письма до задачи с ответственным URL: https://davidgerstein.pro/blog/avtomatizatsiya-obrabotki-zayavok/ Дата: 2026-06-08 Направление: Производственный цикл Цифры: 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 — это отдельная тема, она разобрана в материале Контроль работы менеджера: дашборд вместо штрафов . А о том, как ведёт себя автоматизация вообще без присмотра человека, я писал в статье «Если бы я не пришёл, ничего бы не произошло» . Пять слоёв из этой статьи — приём, определение типа, маршрутизация, срок, контроль — работают только вместе. Уберите любой, и очередь заявок найдёт новое место, чтобы зависнуть. Но ни один из них не ставится один раз и не забывается: приёмщик через полгода ловит новый тип сбоя, шаблон документа устаревает после смены закона, а менеджер находит способ обойти обязательное поле, если систему оставить без присмотра. Автоматизация заявок держится не на коде, а на том, кто раз в квартал проверяет, что все пять слоёв ещё работают так, как задумано. И ещё одно, ради чего всё это. Умение провести заявку глазами по всему пути — от письма до задачи с фамилией и сроком — такой же базовый навык руководителя, как умение читать отчёт о прибыли. Раньше с директора спрашивали, как он раздаёт задачи людям. Теперь спрашивают, как у него устроен маршрут, по которому задача возникает сама и сразу с хозяином. Я считаю, в этом сегодня и разница в цене между двумя руководителями: один держит поток в голове и в переписке, второй — в системе, которая работает и без него. Начните с замера: сколько заявок за прошлую неделю получили ответ позже двух часов. Эта цифра — ваш потенциал, и он обычно больше, чем прирост от увеличения рекламного бюджета. Как собрать обработку заявок так, чтобы ни одна не терялась, — механика в бесплатном курсе . Что дало больше всего эффекта Из всей автоматизации главный результат дала не техника, а одно правило: у каждой заявки с первой секунды есть ответственный человек. До этого мы честно настраивали маршруты и статусы — и всё равно теряли обращения, потому что заявка попадала «в отдел», а отдел не отвечает, отвечают люди. Если у вас сейчас так же — начните с этого правила, оно бесплатное. Автоматизацию поставите поверх. ## Почему реклама не окупается: окупаемость рекламы считают от кассы, а не от кликов URL: https://davidgerstein.pro/blog/pochemu-reklama-ne-okupaetsya/ Дата: 2026-06-06 Направление: Маркетинг Цифры: 350 000 ₽ на инфлюенсеров · 0 договоров · конверсия 33%→6% Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Окупаемость рекламы: короткий ответ Реклама не окупается чаще всего не из-за площадки и не из-за подрядчика, а из-за точки отсчёта: отчёт считает клики и заявки, касса считает оплаченные договоры. Если у вас лидов стало больше, а денег столько же — вы смотрите не на ту цифру. Чтобы посчитать окупаемость рекламы честно, нужны три вещи: считать от даты оплаты договора, а не от даты заявки; держать неатрибутируемые лиды (10–15% в обычный месяц, до 30% в декабре) отдельной строкой, а не размазывать их по каналам; и отдельно смотреть процент брака среди лидов. В компании на 40 человек по этой причине 350 000 ₽ ушли на инфлюенсеров при нуле договоров за месяц, а конверсия упала с 33% до 6%. Вам показывают отчёт: лидов столько-то, стоимость лида такая-то, всё в норме. А деньги в кассе не сходятся с этой красотой. Знакомо? Проблема почти никогда не в подрядчике и не в площадке. Проблема в том, что отчёт по рекламе меряет клики и заявки, а вы управляете деньгами — и между этими двумя мирами есть разрыв, в который проваливается ваш бюджет. Ниже — где именно он проваливается, с разбором до денег, а не до кликов. Я собрал сюда места, в которых сам терял бюджет и потом искал причину задним числом. Месяц, 350 000 ₽ на инфлюенсеров. Ноль договоров. Параллельно директ третий месяц подряд в минусе по ROI, плюс был только один месяц из четырёх. Это не гипотеза — это цифры одной компании за один отчётный период. И вопрос «почему реклама не окупается» в этот момент звучит уже не как теория, а как разговор с финансовым директором, который считает деньги, а не охваты. Проблема в том, что реклама почти всегда «работает» — если мерить кликами, лидами, охватами. Она перестаёт работать, если мерить деньгами. Между этими двумя точками измерения обычно и прячется слив бюджета: отчёт по лидам растёт, касса — нет. Дальше — разбор мест, где именно ломается эта связка, и что с этим можно сделать руками, без веры в «просто лучше настроить таргетинг». Как это устроено, разобрал отдельно: сквозная аналитика своими руками . Почему цифры в вашем отчёте врут Начнём с того, что вы видите каждый месяц, и разберём, где именно эта картинка расходится с вашей кассой. Я сам два года смотрел на такой дашборд и ни разу не спросил у него, откуда берётся знаменатель. Руководитель одной компании случайно, просматривая утренние отчёты, обнаружил: одна входящая точка создавала два-три дубликата лида. Конверсия падала день ото дня — а реальная ситуация была другой. Никто не искал проблему специально, потому что дашборд выглядел правдоподобно: цифры росли, потом снижались, всё как обычно бывает в рекламе. Если точка входа плодит два-три дубля на один реальный лид, отчётная конверсия считается не от реального числа обращений, а от в два-три раза большего количества «лидов» — то есть искусственно занижается в 2–3 раза без единого изменения в реальном спросе (оценка на основе того же кейса: реальный поток не менялся, менялся только знаменатель формулы). Другой день, другой пример — расхождение в отчётах по продажам. У одного менеджера в отчёте сумма, у другого — заметно меньше. При проверке через CRM оказалось: потеряна сделка (она шла как рекомендация, а не как лид, и выпала из расчёта) на 280 000 ₽ — это почти средний чек компании (300 000 ₽). А при фильтрации по месяцу оплаты вместо месяца создания договора разница выросла ещё сильнее. Это не ошибка одного человека — это способ, которым разные фильтры дают разную «правду» из одних и тех же данных. Третья беда — атрибуция. При планировании кампании выяснилось, что 10–15% лидов невозможно привязать к источнику: люди блокируют куки, чистят историю, ставят блокировщики рекламы. В декабре доля неатрибутируемых лидов подскочила до 30%. Если эту треть просто раскидать по каналам «на глаз», отчёт по ROI рекламы превращается в художественную литературу — с тем же успехом можно гадать на кофейной гуще. Правило Пока не выделена отдельная строка «неатрибутируемые лиды» с причиной, любой отчёт по каналам — это оценка, а не факт. Не принимайте решение «отключить канал» на основе цифры, в которую спрятана треть непонятного трафика. Подробнее о том, как CRM искажает даты и цифры без злого умысла, — в разборе CRM врёт. Как я поймал Битрикс24 на сдвиге дат . Лиды есть, продаж нет Если это про вас — а это про большинство — то дальше самая важная часть. Считать окупаемость по заявкам бессмысленно: заявка не деньги. Деньги появляются, когда заявка доходит до оплаты, и вот на этом пути ваш маркетинг обычно слеп. Компания получила несколько десятков качественных лидов из соцсети за месяц. Закрыла 1–2 продажи. На бумаге — провал канала. При разборе выяснилось: эти лиды — первое касание. В отличие от других источников, где человек уже прогрет и готов к разговору, здесь нужен многоэтапный цикл — и «слив» на самом деле означал не плохой канал, а неправильную скорость продажи, применённую к чужому типу трафика. С французским рынком та же болезнь, только в других цифрах: в Париже сотни тысяч человек целевой аудитории, а за всё время с французской версии сайта — два покупателя, оба говорили по-английски. Причина не в объёме аудитории, а в том, что локальные боли не были поняты, и с французским трафиком просто не умели работать: сайт был, а перевод боли клиента на язык этой боли — нет. Третий случай — про маркетолога, который годами продавал «процедуру оформления документов», то есть то, что клиенту неинтересно. За неделю с аналитиком собрали три аватара покупателя: часто это люди старшего возраста, одинокие или с выросшими детьми, ищущие общие интересы. После того как начали говорить не про процедуру, а про боль, конверсия пошла вверх. Дело было не в рекламном бюджете вообще, а в том, что реклама везла трафик к офферу, который не отвечал на вопрос клиента. Разрыв между «лиды есть» и «продаж нет» — тема отдельного разбора: Квалификация лидов: почему лиды есть, а продаж нет . Когда «оптимизация» рекламы убивает окупаемость Этот раздел стоит прочитать, если вам когда-нибудь предлагали «снизить стоимость лида». Ваш подрядчик почти наверняка сможет её снизить — вопрос в том, что вы получите взамен. Самый наглядный случай — смена текста объявления по совету экономиста. Конверсия упала в 5,5 раза: было 33%, стало 6%. При этом количество лидов выросло на 25%. По количеству лидов кампания выглядела лучше. По составу — хуже: пришли заявки из другого сегмента, то есть люди с меньшим бюджетом и худшей конвертацией в сделку. На диаграмме ниже — конверсия до и после смены текста объявления. 33% было 6% стало Рост числа лидов на 25% совпал с падением конверсии с 33% до 6% — по количеству кампания выглядела лучше, по качеству трафика была хуже. Команда после этого разделилась: один хотел продолжать тестирование, второй видел проблему и требовал вывода. Решение отложили ради дополнительного анализа региональной структуры лидов. Это нормальная развилка — но именно она и решает, окупится реклама или нет: если мерить только объём лидов, кампания выглядит рабочей ещё месяц-два, пока не долистаешь до продаж. Такая же история с органическим трафиком: конверсия сайта упала ниже 10% в апреле — в марте было почти 15%, в январе 17%. Устойчивое снижение месяц за месяцем, и вопрос не «работает ли SEO», а «какого качества трафик оно приносит сейчас, а не полгода назад». Канал Что видно по объёму Что скрывает объём Реклама с новым текстом Лидов +25% Конверсия упала с 33% до 6%, качество лидов ниже Инфлюенсеры Охват, узнаваемость 350 000 ₽, 0 договоров за месяц Директ Клики и лиды идут Отрицательный ROI 3 месяца из 4 Органика Трафик растёт или стабилен Конверсия упала с 17% до 10% за 4 месяца Холодная рассылка (крупная база контактов) Открываемость 50% Конверсия в лиды — 0% На диаграмме — конверсия в лид по каналам, от полного провала рассылки до лучших месяцев органики. Соцсеть, первое касание 2–4% Холодная рассылка (крупная база) 0% Реклама после смены текста 6% Органика, апрель 10% Органика, январь 17% Деньги, которые утекают без обратной связи И самое дорогое место. Пока ваш маркетолог не знает, какие лиды дошли до денег, он оптимизирует вслепую — а вы платите за эту слепоту каждый месяц. У условной компании — оптового поставщика с оборотом около 12 млн ₽/мес и отделом из 8 менеджеров — 350 000 ₽ на инфлюенсеров и ноль договоров за месяц — это не случайность конкретного отчёта, а симптом отсутствия обратной связи между тратой и результатом. Параллельно в директе три месяца из четырёх — минус по ROI, и только один месяц — в плюс, при этом на инфлюенсеров продолжали тратить около 300 000 ₽ ежемесячно вместо специализированных каналов. Когда канал не даёт обратной связи «деньги → договор» быстрее, чем цикл принятия решения о бюджете, компания просто продолжает тратить по инерции. Решение отключить или сократить канал принимается не потому, что кто-то один раз посчитал, а потому что накопилось три месяца подряд одинаковой картины. Это дорогая инерция: три месяца — это три бюджетных цикла, потраченных на подтверждение того, что уже было понятно после первого. Деньги утекают и через рассинхрон оплаты. Чтобы получить лиды в начале месяца, счёт нужно оплатить в конце предыдущего — например, 28-го числа для лидов 3-го. При этом половина счетов оплачивается не вовремя. При среднем потоке около 50 валовых лидов в день даже три дня простоя из-за просроченного счёта — это около 150 недополученных валовых лидов, и при конверсии в качественные на уровне 33% — около 50 качественных лидов, которых просто не будет в отчёте того месяца (оценка). Дело не в качестве рекламы вообще, а в том, что даже хороший канал не окупится, если платить за него с опозданием и терять первые дни месяца простоя, которые потом никто не компенсирует. Та же болезнь — в истории с крупной базой контактов с вероятностью целевого признака выше 25%. Прямое предложение консультации или вебинара не сработало вообще — открываемость 50%, конверсия в лиды 0%. Причина в формулировке одной команды: «не понимая сегментацию клиента, бить в лоб бесполезно — это стрельба из пушки по воробьям». Заменили на серию из 3–4 писем с конкретными преимуществами и только потом анонс события. Деньги на рассылку были потрачены один раз — вопрос был не в бюджете, а в последовательности касаний. ИИ-связка: проверка лида до того, как он попал в отчёт по ROI Вот здесь машина закрывает вашу главную дыру: она смотрит каждый лид до того, как он испортит вам статистику, и отделяет мусор от реальных обращений. Большая часть разобранных выше искажений — дубли, неатрибутируемые лиды, задержка с пометкой «неверный источник» — это работа, которую руками делать долго и лень, поэтому её не делают вообще. Отчёт собирают из сырых данных CRM, и все дубли с мусором едут прямо в расчёт ROI. Это чинится не заменой CRM, а простым конвейером-фильтром перед тем, как лид попадает в отчёт. Схема конвейера: 1) Лид создаётся в CRM (Bitrix24) через форму сайта или рекламный кабинет → 2) вебхук CRM при создании нового лида дёргает облачную функцию → 3) функция подтягивает через Bitrix24 REST API последние лиды за 48 часов (crm.lead.list) и формирует запрос к модели → 4) модель возвращает JSON с флагом дубля и статусом атрибуции → 5) функция записывает результат обратно в кастомные поля лида (crm.lead.update) → 6) маркетолог и РОП видят уже очищенные цифры в еженедельном отчёте. Еженедельный отчёт по лидам ~50 валовых лидов/день ~1/3 качественных лидов/день 10–15% неатрибутируемых, типично план май / план июнь рост от месяца к месяцу Лид Дубль Атрибуция 88213 нет unattributed 88214 да, 88190 instagram_ads Модель на этом шаге — дешёвая (класса GPT-4o-mini или аналог): задача чисто классификационная, вызовов много (на каждый новый лид), платить за дорогую модель здесь нет смысла — точность сопоставления по телефону/email и utm-меткам не требует «рассуждений», только сверки шаблонов. Пример ответа модели: Инженерная обвязка: облачная функция крутится на serverless-платформе (например, Yandex Cloud Functions или аналог), триггерится вебхуком Bitrix24 на событие создания лида. Результат пишется в кастомные поля UF_DUPLICATE и UF_ATTRIBUTION_STATUS через crm.lead.update. Если Bitrix24 API не ответил или модель вернула невалидный JSON — запись падает в отдельный лист Google Sheets «ошибки предобработки», а в рабочий чат маркетолога уходит уведомление. Раз в час отдельное расписание догоняет необработанные лиды (там, где кастомное поле осталось пустым) — это защита от разовых сбоев вебхука. Этот инструмент не стоит путать с решением проблемы качества трафика. Скоринг и дедупликация чистят отчёт — они не чинят оффер, не переводят рекламу на нужный аватар клиента и не ускоряют оплату счетов. Это отдельная задача, разобранная в предыдущих разделах, и её эффект нельзя приписывать одной автоматизации. Как считать окупаемость, чтобы не обманывать себя Рабочая точка отсчёта — не лид и не клик, а оплаченный договор, привязанный к дате оплаты, а не к дате создания заявки. В примере с расхождением сумм по разным менеджерам именно смена фильтра «месяц оплаты» вместо «месяц создания» дала честную картину. Дальше — план не месяцем, а неделями и днями. У компании план по качественным лидам заметно вырос от мая к июню — но контроль шёл по неделям: несколько десятков валовых лидов в день, около трети из них качественные, накопленным итогом за месяц набиралось нужное число. Такая детализация позволяет увидеть отставание на третьей неделе, а не в последний день месяца, когда исправлять уже поздно. Неделя Плановый темп Контрольная точка Неделя 1 Около четверти месячного плана качественных лидов Сверка по факту среды и пятницы Неделя 2 Ещё столько же, накопленным итогом около половины плана Если отстаём — корректировка бюджета до конца недели Неделя 3 Накопленным итогом около трёх четвертей плана Последняя точка для догона плана без аврала Неделя 4 + остаток Добор до полного месячного плана Разбор причин отставания, а не только цифры Отдельно — коэффициент сезонности. Для декабря как месяца низкого спроса ввели коэффициент 0,8 — на 20% ниже обычного плана, с перераспределением объёмов на другие месяцы. Без этого декабрьский провал каждый год выглядел бы как авария, а не как предсказуемая сезонность, и решения принимались бы панически, а не по графику. И наконец — контроль качества самих лидов, а не только их числа. Из общего объёма качественными по факту проверки оказались только около 40%, при том что рассчитывали на отвал не больше 20%. Если не считать процент отбраковки отдельно, реклама может «работать» по количеству и одновременно проваливаться по деньгам. Где ломается Расчёт окупаемости ломается там, где отчёт строится по дате создания лида, а не по дате оплаты, и там, где нет отдельной цифры по браку. Обе ошибки дают красивый отчёт и пустую кассу — причём чем позже это вскрывается, тем дороже разворот бюджета. Экономика: что стоит фильтр лидов и что он даёт Считаем честно, без смешивания с другими инициативами из этой статьи (сменой оффера, сегментацией базы, ускорением оплаты счетов — это отдельные решения со своим эффектом). Стоимость внедрения конвейера дедупликации и атрибуции: разработка вебхука и функции — это разовая работа на 1–2 дня специалиста уровня «настроить интеграцию», плюс настройка кастомных полей в CRM. По времени это 12–16 часов работы — то есть разовые вложения, сопоставимые примерно с двумя рабочими днями одного специалиста (оценка). Эксплуатация: вызовы дешёвой модели на классификацию лида стоят копейки за штуку — при типовом для этой воронки потоке валовых лидов в день это заведомо ниже стоимости одного часа работы аналитика в месяц, даже с запасом на повторные догоны по расписанию (оценка на основе публичных цен на модели класса mini). Эффект нужно считать не как «сколько денег принёс инструмент», а как «сколько времени и риска он снимает». Пример на условных, но реалистичных числах: если аналитик тратит 3 часа в неделю на ручную сверку дублей и разметку неатрибутируемых лидов при типовом потоке лидов — это около 12 часов в месяц ручного труда, которые автоматизация снимает почти полностью, то есть высвобождается объём времени, сопоставимый примерно с полутора рабочими днями специалиста ежемесячно (оценка). Формула для своего случая: (часы ручной сверки лидов в месяц) × (ставка специалиста в час) = ежемесячные потери на ручной труд, который заменяет фильтр. Если это число больше стоимости разового внедрения — инструмент окупается быстро. В нашем примере разовые затраты на внедрение (12–16 часов работы) окупаются примерно за 1–1,5 месяца снятого ручного труда — и это без учёта второго, более весомого эффекта, который считается отдельно. Второй, более весомый эффект — не экономия часов, а снятый риск ошибочного решения. Пример: доля неатрибутируемых лидов — 20–30% в обычный месяц (по декабрю — все 30%) от бюджета канала. Это значит, что решение «отключить канал» или «удвоить бюджет» в такой месяц принимается вслепую по 20–30% объёма трафика канала, происхождение которого никто не подтвердил. Эти два эффекта — экономия часов и снятый риск ошибочного решения — не складываются механически в одну сумму: часы считаются в трудозатратах текущего месяца, а риск — это вероятность более дорогой ошибки в будущем. Держите их раздельно, если считаете окупаемость для своего случая, иначе легко приписать инструменту чужой эффект. Отдельно — про инфлюенсеров: 350 000 ₽ и ноль договоров за месяц — это цифра одного канала, не результат фильтра лидов и не заслуга или вина автоматизации. Её нельзя чинить дедупликацией — здесь нужен другой разговор: о критериях выбора площадки и контрольной точке отсечения бюджета до третьего месяца, а не после. Подробнее о том, как считать реальную стоимость ИИ-инструментов в подобных конвейерах, — в разборе сколько на самом деле стоит ИИ в месяц . Чек-лист: с чего начать в понедельник Выгрузить лиды за последний месяц и посчитать долю без utm-меток или с пустым источником — если больше 15%, завести отдельную строку «неатрибутируемые» в отчёте. Проверьте отчёт по продажам по двум фильтрам — «дата создания заявки» и «дата оплаты договора» — и сравнить итоговые суммы. Расхождение больше 5% значит, что текущий отчёт врёт. Найдите хотя бы один канал, где ROI отрицательный два месяца подряд, и явно решить: третий месяц наблюдения или остановка — без «ещё чуть-чуть посмотрим». Разбейте месячный план по лидам на недели с контрольными точками — не ждать конца месяца, чтобы узнать об отставании. Проверьте процент отбраковки лидов за контроль качества отдельно от процента конверсии в продажу — если отбрак выше плана в 2–3 раза, проблема в качестве трафика, а не в отделе продаж. Если поток лидов заметный (десятки в день) — оценить, сколько часов в неделю уходит на ручную сверку дублей (например, 3 часа в неделю ≈ 12 часов в месяц), и сравнить с разовой стоимостью внедрения фильтра (по нашей оценке — порядка 12–16 часов работы специалиста); если ручной труд стоит дороже за 1–2 месяца — фильтр окупается быстро. Что сделать на этой неделе: возьмите последний отчёт по рекламе и рядом положите фактические поступления за тот же период. Не выручку по CRM, а деньги. Если цифры не сходятся — вы нашли, где искать, и это уже половина решения. Механику сквозного счёта — от клика до платежа, с проверкой качества лида до попадания в отчёт — разбираю в бесплатном курсе для руководителей . Мой опыт: где я ошибался сам Я долго смотрел на стоимость лида как на главную цифру. Мы её снижали, гордились результатом — и не понимали, почему касса не растёт. Ошибка была в том, что я мерил вход в воронку, а деньги живут на выходе. Перелом случился, когда мы связали рекламу с фактическими оплатами. Выяснилось, что самый «дорогой» канал давал клиентов с чеком вдвое выше и почти без отказов, а «дешёвый» — вал заявок, из которых до денег доходили единицы. Мы полгода вкладывали в худший канал, потому что он лучше выглядел в отчёте. Тогда я и назвал для себя тот навык, которого мне не хватало. Навык руководителя здесь не в том, чтобы разбираться в настройках рекламного кабинета, — а в том, чтобы к любой красивой цифре в отчёте задавать два вопроса: в каких деньгах она выражается и на какую дату посчитана. Два вопроса, тридцать секунд. Их не задают годами. Если у вас маркетолог отчитывается стоимостью лида и вы этим довольны — вы, скорее всего, повторяете мою ошибку прямо сейчас. Попросите его показать выручку по каналам, а не заявки. Разговор изменится в тот же день. Сделайте на этой неделе один запрос: выручка по каналам за квартал, не заявки. Если таких данных нет — вот вам первая задача, и она важнее любой оптимизации ставок. Как связать рекламу с деньгами и проверять качество лида до отчёта — механика в бесплатном курсе для руководителей . ## База знаний компании: почему вики умирают и что работает вместо них URL: https://davidgerstein.pro/blog/baza-znanij-kotoroj-polzuyutsya/ Дата: 2026-06-04 Направление: Операционное управление Цифры: 80 / 22 / 17 — три ответа на один запрос · 40→7 минут на инструкцию · 3 попытки до рабочей инструкции Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. У вас есть база знаний? А ей кто-нибудь пользуется? Если у вас, как у большинства, разговор глохнет на втором вопросе — диагноз простой: база есть почти у всех, пользуются единицы. Продолжение тоже знакомо: люди всё равно идут спрашивать в чат, потому что так быстрее. Я собрал за карьеру три таких кладбища. Ниже — что делает базу живой, и это не про инструмент: с любым инструментом можно сделать и работающую вещь, и мёртвый архив. Руководитель попросил выгрузить список клиентов одного региона из воронки. Получил три числа: 80, 22, 17. Три человека, три фильтра, три версии правды. Никто не соврал — каждый смотрел в свой кусок системы. Это и есть цена отсутствия единого источника данных: не хакерская атака и не саботаж, а обычный рабочий день, где база знаний компании существует в головах, а не в системе. На выяснение, какое из трёх чисел верное, ушла встреча с тремя участниками — по грубой прикидке это час-полтора рабочего времени трёх сотрудников, то есть 3–4 часа × 1000 ₽ ≈ 3–4 тыс. ₽ за один эпизод (оценка). А таких эпизодов в месяц — не один. Дальше — не про то, как красиво оформить вики. Про то, почему такие порталы умирают через полгода после запуска, и что вместо них реально работает в операционке: механика по шагам, конкретный промпт для превращения голосового сообщения в инструкцию и честная экономика — сколько это стоит и что снимает. Почему база знаний не работает и что с этим делать База умирает по одной причине: спросить коллегу быстрее, чем найти ответ. Пока это так, вы проигрываете чату — независимо от того, какой инструмент купили. Три правила живой базы: она пополняется автоматически из разборов и планёрок, а не подвигом энтузиаста; у каждой статьи есть срок годности, после которого она уходит на проверку; и поиск в ней работает быстрее, чем вопрос в чате. Проверка простая — дайте новому сотруднику найти ответ на реальный рабочий вопрос и засеките время. Три ответа на один вопрос — это диагноз Задайте своей команде один рабочий вопрос в общем чате и посмотрите, сколько разных ответов вы получите. Если больше одного — у вас нет базы знаний, у вас есть коллективная память, и она у каждого своя. История с 80/22/17 показательна тем, что проблема не в CRM и не в квалификации людей. Проблема в децентрализованном хранении данных: у каждого свой фильтр, своя выгрузка, своё понимание, что считать «активным клиентом». База знаний компании — это в первую очередь не документ с инструкциями, а согласованный источник правды: где лежит актуальная цифра, кто её обновляет, как её проверить. Если у отдела нет единого места, где хранится актуальное состояние процесса — количество клиентов, статус договора, версия регламента, — люди начинают спрашивать друг друга. Спрашивают и дело не в лени: спросить быстрее, чем искать в трёх системах одновременно. Красивый дом без дверей Так выглядит большинство баз, которые я видел, включая мои первые: содержание есть, входа нет. Проверьте свою — сможете ли вы за минуту найти в ней ответ на вопрос, который вам задали вчера? Одна команда собрала базу на огромное число вопросов. Разработчик подготовил контент и дизайн, передал технической команде — и там всё встало. Несколько операций подряд, неделя работы — а войти в систему нормально не получалось. По итогу — «красивый дом, но дверей нету, как зайти непонятно». Разрыв случился не из-за нехватки данных. Данных было в избытке. Разрыв — между контентом и разработкой: никто заранее не сформулировал техническое задание на то, как человек должен искать ответ, сколько кликов ему на это нужно, что происходит, если он не знает точного термина. Где ломается Большая база знаний без продуманного входа хуже маленькой без базы вообще. Люди не будут листать сотни тысяч записей в поисках одной. Они пойдут в чат и спросят коллегу — а коллега оторвётся от своей работы, и цикл повторится. Тот же принцип разделения контента и упаковки работает и в производстве документов: в одной компании производственный цикл разбит на два блока — «производство» (сбор материала, интервью, структура) и «упаковка» (редактура, вёрстка, финальный вид). За оба блока отвечает один проект-менеджер, но исполнители разные. С базой знаний то же самое: тот, кто пишет контент, и тот, кто делает его доступным, — разные компетенции. Если это не разделить осознанно, получится дом без дверей. Почему ваши сотрудники всё равно спрашивают в чате Ответ неприятный: потому что спросить быстрее, чем искать. Пока это так, ваша база проигрывает чату по единственному критерию, который важен исполнителю. Финансовый сотрудник жаловался, что коллеги постоянно перебивают его просьбами об оплатах и срочных операциях. Он не успевал с основной работой и начал сомневаться в собственной компетентности. Руководитель разобрался — и корень оказался не в характере коллег и не в квалификации финансиста. Корень — в отсутствии структуры: не было выделенного времени в расписании, когда платежи обрабатываются, и все знали бы, что до 10 и после 11 дёргать бесполезно. Это тот же класс проблемы, что и с базой знаний. Люди спрашивают не потому что не хотят искать сами, а потому что не знают, где и когда искать, и им проще получить ответ живьём. Руководитель маркетинга описывал это так: «Я бы хотел погруженно работать, ну, взял задачу, в неё погрузился и час ей занимался. А в большинстве случаев, если мне 15 минут удалось что-то поделать, это прям невероятная удача». Постоянные прерывания — это не только про отсутствие документации. Это про отсутствие правил, к кому и когда обращаться. База знаний без регламента «в какое время это решается» ломается так же, как регламент без базы знаний, куда за ответом идти. Механика: как база собирается по шагам Мы шли этим путём дважды: первый раз с конца — выбрали красивый инструмент и начали в него переносить, и умерли на третьей неделе. Второй раз с начала — с правила, откуда берутся статьи. Второй заход дожил до сегодня. Порядок для вас: сначала правило пополнения, потом структура, и только потом инструмент. Обратный порядок — с выбора платформы — и есть главная причина мёртвых баз. Рабочая версия строится не сверху вниз (сначала портал, потом контент), а снизу вверх — из повторяющихся действий, которые уже происходят. В одной компании ввели простое правило: каждое выполняемое сотрудником действие либо документируется как инструкция, либо записывается на диктофон для последующей расшифровки. Схема такая: Три попытки. Сотрудник берётся за задачу: первый раз — не вышло, второй — снова мимо, но уже по-другому, третий — получилось. Вот на этом моменте включается фиксация. Чем фиксируется. Сотрудник не пишет текст — надиктовывает на диктофон или в голосовое сообщение, что он сделал, шаг за шагом. Куда попадает. Запись автоматически транскрибируется и упаковывается моделью в структурированную инструкцию (шаги, формат, условия применения). Кто и когда смотрит. Черновик инструкции уходит на проверку владельцу процесса (не автору, а ответственному за раздел базы), тот подтверждает или правит формулировки — без ручного набора текста с нуля. Что дальше. После публикации к вопросу больше не возвращаются — при повторном возникновении такой же ситуации сотрудник получает ссылку на инструкцию, а не устный ответ. Смысл в том, что база знаний не пишется отдельным проектом «в свободное время», которого ни у кого нет. Она собирается как побочный продукт обычной работы. Похожий принцип уже применяется для автопостинга: менеджеры записывают голосовое по итогам дня, данные транскрибируются и упаковываются в готовый текст — подробнее об этой механике в статье о том, как планёрка документирует себя сама . Это снимает главный вопрос, который убивает попытки завести базу знаний: «кто будет её вести». Никто отдельно — она собирается из того, что люди и так делают, если процесс правильно настроен. ИИ-связка: от голосового до инструкции Конвейер простой и его можно повторить на любом стеке, где есть Telegram-бот и вебхук: голосовое сообщение → транскрибация → структурирование моделью → черновик в таблице → проверка человеком → публикация. Шаг транскрибации — это распознавание речи (модель уровня Whisper или встроенный STT платформы), он не требует рассуждений, только точность звука в текст. Шаг упаковки в инструкцию — это уже работа с текстом: выделить шаги, убрать оговорки, не потерять смысл. Здесь достаточно дешёвой модели: команда уже проверяла на своём проекте — дорогая модель и модель подешевле дали идентичный результат на одном и том же промпте структурирования текста. Переплата за токены на такой задаче — чистые потери. Упаковка расшифровки в инструкцию — далеко не единственное, что машина делает с текстом: есть шесть ступеней — от писем и документов до таблиц и подключения к вашим системам . Промпт для шага «упаковка» (вебхук из Telegram-бота или Make/n8n-сценария, вход — JSON с транскриптом): Пример ответа модели: Инженерная обвязка: Telegram-бот принимает голосовое сообщение → вебхук в n8n (или Make) передаёт файл в API транскрибации → текст уходит в модель по промпту выше → результат складывается черновиком в Google Sheets (колонки: employee_id, title, steps, unclear, status) → ответственному за раздел базы приходит уведомление в Telegram с ссылкой на черновик. Если транскрибация вернула пустой текст или файл повреждён — бот отвечает сотруднику «не расслышал, запишите ещё раз», а ошибка логируется в отдельный технический чат, чтобы не потерять сигнал молча. Перезапуск ручной: по task_id можно повторно дёрнуть вебхук без пересборки всей цепочки. Так выглядит сам черновик в таблице, прежде чем владелец раздела его подтвердит: Черновики базы знаний — Google Sheets 10–20 новых инструкций в месяц employee_id title status manager_14 Оформление договора с ускоренным тарифом на проверке manager_09 Возврат по договору опубликовано Второй полезный промпт — не для создания инструкций, а для их прополки. База без аудита ведёт себя так же, как неконтролируемые подписки на сервисы: в одной компании обнаружили, что за месяц число оплаченных коммуникационных каналов выросло в несколько раз — просто потому что никто не проверял, действительно ли они используются. С базой знаний тот же риск: статьи копятся, дублируются, устаревают, и никто это не считает, пока объём не станет неуправляемым. Модель здесь та же дешёвая: задача — сравнение текстов и дат, не творческая генерация. Запускать такой аудит достаточно раз в месяц вручную по кнопке или по расписанию в том же n8n. Что видно на цифрах: где теряется время без базы знаний Ситуация Что происходит Оценка потерь Три версии выгрузки клиентов (80/22/17) Сотрудники сверяют вручную, кто прав ~3–4 часа на эпизод (оценка) Финансиста прерывают вопросами об оплатах Нет расписанного окна приёма запросов рабочий день дробится на отрезки по 15 минут Портал с огромным числом вопросов без точки входа Пользователи не находят нужное база не используется, возврат к вопросам в чате Ручное заполнение ежедневного отчёта Данные собираются вручную, а не тянутся из CRM ~30 минут в день, ~10 часов в месяц (оценка) На диаграмме ниже — те же потери в пересчёте на минуты в день по каждому сценарию: Прерывания вопросами коллег 45 мин/день Ручной ежедневный отчёт 30 мин/день Поиск нужной версии данных 20 мин/день Поиск в портале без входа не используется Вики, которая умирает База знаний, которой пользуются Отдельный проект «когда будет время» Побочный продукт ежедневных действий (диктофон, расшифровка) Контент собран без ТЗ на вход и поиск Точка входа продумана до того, как написана первая статья Автор статьи неизвестен, обновлять некому У каждого раздела есть владелец Правится раз в квартал по инициативе Правится по факту: 3 неудачные попытки — новая инструкция Экономика: что это стоит и что даёт Настройка вебхука, транскрибации и промпта — разово 8–15 часов инженера; эксплуатация — счёт за токены и STT на порядок ниже стоимости одного часа сотрудника в месяц (оценка); прямой эффект на одной инструкции — экономия около 30 минут (с ~40 до ~7 минут), а на отдел набегает порядка 20 часов в месяц за счёт снятых прерываний (оценка). Разберём вклад именно механики «диктофон → расшифровка → инструкция», не смешивая с другими инициативами вроде мониторинга звонков или дашбордов — у них своя отдельная экономика. Стоимость внедрения. Формула словами: (часы инженера на настройку) × (ставка часа инженера) = разовые вложения. Настройка вебхука Telegram-бота, сценария транскрибации и промпта упаковки в n8n или Make — разовая работа инженера, оценочно 8–15 часов на первую рабочую версию (тестирование, обработка ошибок, шаблон в Google Sheets). По стандартной для рынка часовой ставке инженера это укладывается в диапазон одного-двух рабочих дней специалиста (оценка). Стоимость эксплуатации. Формула словами: (число инструкций в месяц) × (стоимость транскрибации и вызова модели на одну инструкцию) = счёт за месяц. Транскрибация голосовых и работа дешёвой модели на структурирование текста — низкий по объёму трафик токенов. При потоке 10–20 инструкций в месяц счёт за месяц остаётся на порядок ниже стоимости одного часа работы сотрудника — на порядок дешевле часа одного сотрудника. Прямой эффект. Формула словами: (сэкономленные минуты на одну инструкцию) × (число новых инструкций в месяц) ÷ 60 × (ставка часа сотрудника) = прямая экономия в месяц. Возьмём небольшой отдел и консервативную оценку: письменная инструкция руками отнимала у автора порядка 30–40 минут — по аналогии с другими ручными задачами фиксации данных в отделах, например ежедневный отчёт вручную занимал около 30 минут в день, — а через диктофон и автоматическую упаковку — 5–7 минут надиктовки плюс проверка черновика владельцем раздела. Экономия на одну инструкцию — около 30 минут, консервативно. При 10 новых инструкциях в месяц: 30 мин × 10 ÷ 60 = 5 часов в месяц — меньше одного рабочего дня одного сотрудника. Немного — это только прямая экономия на написании текста. На диаграмме — сравнение времени на одну инструкцию до и после ИИ-упаковки: 40 мин было 7 мин стало Экономия времени на одну инструкцию — с ~40 минут ручного написания текста до ~7 минут надиктовки на диктофон и проверки черновика владельцем раздела (оценка). Косвенный эффект больше прямого. Он не в скорости написания, а в снятых прерываниях. Формула словами для своего случая: (число сотрудников) × (минуты в день на устные вопросы коллегам) × 20 рабочих дней ÷ 60 = потери на прерывания в часах в месяц; доля, которую снимает рабочая база знаний (сотрудник находит ответ сам, не отвлекая коллегу), — это и есть ожидаемый эффект. Если у небольшого отдела уходит хотя бы 15 минут в день на «спросить коллегу вместо поиска в базе» на человека — а по цитате из этой же компании 15 минут непрерывной работы уже воспринимаются как удача, — суммарно на отдел набегает пара часов в день, ×20 рабочих дней = порядка 40 часов в месяц — почти целая рабочая неделя одного сотрудника. Если рабочая база знаний закрывает хотя бы половину таких вопросов напрямую, консервативная оценка снятого риска — около 20 часов в месяц, то есть половина обычной рабочей недели. Это оценка вклада именно базы знаний: сдвиг в реальных компаниях обычно даёт связка из базы знаний и регламента приёма запросов, вклад одного инструмента отдельно выделить нельзя. Что мы не считаем эффектом: время, которое сотрудник тратил на устные ответы коллегам, никуда не делось из его дня как «сэкономленное» — оно просто перестало быть прерыванием и стало временем на его собственную задачу. Это реальный выигрыш в фокусе внимания, но не прямая строка в бюджете, и складывать её с прямой экономией на написании текста нельзя — это два разных по природе эффекта. Правило Не запускайте базу знаний как отдельный проект с отдельным дедлайном. Она либо встроена в то, как люди уже работают, либо превращается в дом без дверей, о котором вспоминают на архивной полке. С чего начать в понедельник Выпишите три-пять вопросов, которые вам или коллегам задают чаще всего устно за последнюю неделю, — это и есть первые статьи базы, а не абстрактный план разделов. Назначьте владельца на каждый будущий раздел базы поимённо, а не «на отдел» — раздел без владельца устаревает первым. Настройте один канал приёма голосовых сообщений (Telegram-бот) для фиксации того, «как я это сделал», даже если технической упаковки в инструкцию ещё нет — начните с ручной расшифровки. Проверьте точку входа: сможет ли новый сотрудник за минуту найти ответ без вопроса коллеге. Если нет — чините вход, а не добавляйте контент. Введите правило трёх итераций: неправильно — неправильно — правильно, и на третий раз действие обязательно закрепляется инструкцией, а не остаётся в памяти исполнителя. Через месяц прогоните реестр статей через промпт-аудит — устаревшие и дублирующие статьи убивают доверие к базе быстрее, чем их отсутствие. Три числа — 80, 22, 17 — из истории в начале статьи чинятся не новым порталом. Чинятся правилом: один источник, один владелец, один способ проверки. Похожая логика применима и к контролю качества работы людей — переопределённые оценки в этой компании сначала показывают пробел и рекомендацию, а не штраф, и это тоже форма базы знаний, только персональной. Подробнее — в материале про контроль качества звонков без ОКК . А там, где база знаний должна пополняться из сканов и фото документов, а не из голосовых, полезно посмотреть, как точность распознавания документов выросла с 59% до 85% . Всё остальное — красивая обёртка, которая рано или поздно останется домом без дверей. Проверьте свою базу одним способом: попросите нового сотрудника найти в ней ответ на реальный рабочий вопрос. Если он вернётся с пустыми руками или пойдёт спрашивать коллегу — база не работает, сколько бы статей в ней ни было. Как сделать так, чтобы знания попадали туда автоматически — из планёрок, переписок, разборов, — механика в бесплатном курсе для руководителей . Три правила, которые сделали нашу базу живой Первое: пополняется автоматически. Если наполнение базы — отдельная задача в чьём-то списке, она не будет выполняться. У нас статьи рождаются из разборов и планёрок, а не из подвига одного энтузиаста. Второе: у каждой статьи есть срок годности. Не обновлялась полгода — попадает в список на проверку. Устаревшая инструкция хуже отсутствующей: по ней сделают неправильно и с чистой совестью. Третье: искать проще, чем спрашивать. Пока поиск в вашей базе работает хуже, чем вопрос в чате, вы проигрываете. Это единственный критерий, который вам стоит замерять. И замерять его руками, а не верить отчёту о числе статей, — отдельный навык руководителя: вопрос звучит не «сколько у нас документов», а «за сколько секунд новый человек нашёл ответ». Начните с одного: возьмите вопрос, который вам задают чаще всего, и запишите ответ туда, где ваши люди его найдут. Один вопрос в неделю — и через год у вас будет база, которой пользуются. Как автоматизировать пополнение из планёрок и переписок — в бесплатном курсе . Мы у себя завели правило: любой вопрос, заданный дважды, становится статьёй. Не идеально, зато работает без отдельного человека — и через полгода у нас накопилось ядро, которым реально пользуются. ## Как построить систему контроля качества звонков: от записи до отчёта руководителю URL: https://davidgerstein.pro/kachestvo/kontrol-kachestva-zvonkov-mehanika/ Дата: 2025-01-20 Направление: Контроль качества Цифры: 25%→100% охват · 66 звонков сверки · 10 чек-листов Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Я прошёл этот путь целиком — от «слушаю выборочно, когда есть время» до конвейера, который оценивает каждый разговор. Ниже то, что я бы хотел знать в начале: где именно ломается, сколько стоит и почему первые оценки машины нельзя показывать команде. Полная механика контроля качества звонков: от чек-листов до дашборда. Если вы собираетесь ставить это у себя — здесь весь путь, включая цифры и места, где мы спотыкались. Как работает контроль качества звонков на ИИ Ручной контроль закрывает в среднем 25% разговоров — остальное руководитель не слышит вообще. Машинный конвейер поднимает охват до 100% и обходится дешевле одной ставки контролёра: около $300 в месяц на весь поток. Доверять оценкам можно только после калибровки: отдел контроля качества сверил 66 звонков вручную и получил разрыв с машиной в 25,5 процентных пункта . Без такой сверки цифры выглядят убедительно и означают не то, что кажется. Почему «прослушать пару разговоров» — это не контроль Проверьте свою ситуацию: сколько процентов разговоров у вас слушает хоть кто-нибудь? Если меньше половины, вы не контролируете качество, вы делаете выборочные замеры настроения. Контроль качества звонков — это система, которая проверяет каждый (а не выборочный) разговор менеджера с клиентом на соответствие скрипту, полноту работы с возражениями и соблюдение регламента, и превращает это в оценку, отчёт и обратную связь. Пока контроль выборочный — вы видите не качество работы отдела, а качество работы тех 10–25% сделок, которые случайно попали в выборку контролёра. Старший менеджер по контролю качества Ира слушала звонки ушами, пока их было тридцать в день. При таком объёме это работало: она успевала прогнать через себя весь пул за смену. Как только звонков стало в разы больше, а отдел вырос до 8 менеджеров, тридцать в день превратились в полторы сотни — и ручной контроль физически перестал закрывать больше четверти потока. Это не история про лень или недостаток квалификации: одна пара ушей просто не масштабируется. 25% было 100% стало На диаграмме — охват звонков контролем: ручная прослушка одним контролёром закрывала около четверти потока отдела из 8 менеджеров, автоматическая выгрузка и ИИ-скоринг после калибровки доводят охват до полного объёма. Где ломается. Одна пропущенная ошибка в контроле качества может стоить дороже, чем весь годовой бюджет системы контроля: сорванный крупный контракт, испорченные отношения с клиентом, юридический риск из-за незафиксированного обещания менеджера. Разбор одной такой ошибки и того, во что она обошлась, — дальше, в разделе про чек-лист из пяти критериев. Дальше в статье — не про то, «как приятно, когда всё автоматизировано», а про то, из каких узлов реально собирается система, где она чаще всего рвётся и сколько это стоит на цифрах условной компании: отдел продаж 8 менеджеров, оборот ~9 млн ₽ в месяц, средний чек ~180 тыс. ₽, цикл сделки ~6 недель. Из чего физически состоит система Пять элементов. Посмотрите, что из этого у вас уже есть — обычно половина. Рабочая система контроля качества звонков — это не одна нейросеть, а конвейер из шести узлов: выгрузка и идентификация записи, транскрибация, классификация типа звонка, оценка по чек-листу, сведение с ручной проверкой на калибровке и выдача отчёта руководителю. Выпадение любого узла делает всю цепочку бесполезной — оценка на неполном тексте так же вредна, как оценка звонка, который вообще не тот, что нужно было оценивать. Узел Что делает Частая поломка Выгрузка и идентификация Достаёт запись из CRM и привязывает к сделке, менеджеру, этапу Система не понимает, какой звонок из серии — целевой Транскрибация Превращает аудио в текст Обрезается по лимиту символов ячейки, текст режется на середине фразы Классификация Определяет тип: первичный лид, продажа, вторичный звонок, встреча Один и тот же промпт применяется ко всем типам без разбора Оценка по чек-листу Выставляет баллы по релевантному именно этому типу чек-листу Один чек-лист на полсотни пунктов вместо пяти релевантных критериев Калибровка Сверяет оценку модели с ручной оценкой человека Калибровку пропускают, чтобы быстрее «запустить» Отчёт Собирает баллы в личный кабинет руководителя Отчёт есть, но по нему нельзя провалиться в конкретный звонок Так выглядит финальный отчёт, в который стекаются результаты всех узлов конвейера — от выгрузки до калибровки: Отчёт: контроль качества звонков 2 600 звонков в месяц 100% звонков под контролем 66 звонков сверки ИИ/человек Менеджер Ср. балл Статус Менеджер 4 7/10 есть red flags Менеджер 2 9/10 норма Дальше разберу каждый узел отдельно — потому что именно на стыках между ними компании теряют месяцы на настройку. Выгрузка и идентификация У нас на этом шаге ушла неделя: телефония отдавала записи без привязки к сделке, и мы сначала не понимали, чей это звонок. Правильная выгрузка — это не «слушать всё подряд», а автоматическая привязка каждой записи к сделке по уникальному ID, менеджеру и времени, с триггером на нужном этапе воронки, а не на ручном действии менеджера. Первая версия почти всегда строится на допущении «менеджер переведёт сделку на промежуточный этап, и мы поймём, что звонок целевой». Это допущение не работает: менеджер переводит этапы непостоянно, первый звонок может оказаться холостым, а следующий за ним система вообще не захватывает. Рабочее решение — выгружать все звонки из CRM с уникальными идентификаторами (ID сущности, менеджер, время звонка), а триггером для оценки встречи делать не ручной перевод этапа, а заполнение обязательного поля с аудиозаписью на этапе «встреча проведена». Перед оценкой конкретной встречи система дополнительно поднимает контекст предыдущих звонков с тем же клиентом — иначе оценка получится обрывочной, как будто менеджер начал разговор с чистого листа. Где ломается. «Проблема любой системы, которая связана с любой CRM, — как понять, что это именно тот звонок, который нужно оценить» — с этого вопроса начинается почти любой проект контроля качества, и на нём же чаще всего стопорится на месяц-два. Транскрибация: изнанка, о которую всё разбивается Здесь вас ждёт первая настоящая проблема, и она не про ИИ: если запись обрывается, вы получите уверенную оценку неполного разговора. Транскрибация — самое незаметное звено конвейера, и именно оно чаще всего портит итоговую оценку: если текст обрезан, модель оценивает не звонок, а его обрывок, и делает это уверенно, не сигнализируя об ошибке. Классический сценарий: транскрипт заливают прямо в ячейку таблицы, а у ячейки есть лимит символов. Длинный звонок обрезается на середине фразы, ИИ получает неполный текст и неправильно оценивает качество разговора — причём внешне отчёт выглядит абсолютно рабочим, никаких ошибок и алертов. Именно с недоверия к таким «плывущим» оценкам на обрезанных транскриптах Ира начала пересматривать весь конвейер: если бы она не сверяла оценку модели с тем, что реально было в разговоре, расхождение так и осталось бы незамеченным. Рабочее решение простое: вместо вставки полного текста в таблицу система сохраняет краткий фрагмент и добавляет ссылку на полный текст в отдельном хранилище, где его можно открыть при разборе. Подробнее про эту и другие технические ловушки — в разборе про транскрибацию, которая обрывается на полуслове . Сколько критериев вам реально нужно Короткий ответ: пять. Всё, что больше, ваши люди перестанут заполнять честно. Рабочий чек-лист — это 5 критериев под конкретный тип звонка, а не 50 универсальных пунктов на все случаи сразу: чем длиннее список, тем ниже согласованность между тем, как оценивает его человек, и тем, как оценивает его модель. Готовые системы контроля качества на рынке обычно предлагают один универсальный чек-лист на все звонки. Это не работает: первичный звонок лида, звонок в рамках сделки и вторичный контакт с уже действующим клиентом требуют разных критериев — то, что критично на первом касании (выявить потребность), не имеет смысла проверять на встрече, где клиент уже подписывает договор. Рабочий вариант — набор из отдельных чек-листов под тип звонка (в проверенных конфигурациях их обычно около десяти), а внутри каждого — пять критериев вместо полусотни. Разбор, почему пять критериев дают более честную оценку, чем громоздкий универсальный список, и во сколько может обойтись пропущенная в чек-листе ошибка, — в материале про пять критериев вместо полусотни пунктов . ИИ-скоринг против ручной оценки Ваш способ проверить, можно ли доверять машине, — калибровка: параллельные оценки и разбор расхождений. Без этого вы просто верите, а вера в управлении плохой инструмент. ИИ-скоринг звонков нельзя запускать на полный охват без калибровки: модель систематически «плывёт» — по одному и тому же звонку при повторной обработке может выдать разные баллы, и без сверки с человеком это расхождение никто не заметит, пока не станет дорогим. Рабочая практика — параллельный прогон: за контрольный период (в проверенной конфигурации — 66 звонков) оценка идёт одновременно у модели и у живого контролёра, по каждому звонку считается дельта отклонения. Если дельта стабильно небольшая — можно постепенно передавать модели больше объёма. Если дельта скачет — проблема либо в чек-листе (слишком общие формулировки), либо в промпте (модель не понимает контекст), либо в самой транскрибации. Именно на этом этапе руководители чаще всего произносят вслух то, что раньше держали при себе: «оценка не всегда адекватна» — и это нормальная, рабочая стадия проекта, а не повод его закрыть. Полная механика калибровки — от первой сверки до расхождений с ручной проверкой — разобрана в материале про то, как нейросеть научили оценивать звонки менеджеров . Где ломается. Компания без доказанной эффективности рискует автоматизировать контроль на цифрах, в которые никто не верит: «я не готов автоматизировать контроль качества, потому что не понимаю, работает ли методология и сколько это будет стоить» — типичная позиция руководителя до калибровки, и это правильная осторожность, а не сопротивление прогрессу. Контроль переписок и SLA ответа: где теряются деньги, пока все смотрят только на звонки Контроль качества нельзя ограничивать звонками: часть сделок сгорает не в разговоре, а в паузе между сообщениями в мессенджере — и эту паузу видно только через отдельный слой мониторинга, а не через прослушку. Рабочая связка здесь двухуровневая. Первый уровень — оперативный, Telegram-бот с алертами, если менеджер не ответил клиенту дольше установленного норматива. Второй — ежемесячный аналитический отчёт про недостатки эмпатии и деловой коммуникации в переписке, на основе которого строится точечное обучение. В зафиксированной практике средний ответ на сообщение держался на уровне 8 часов — но это число нужно проверять отдельно от рабочего времени: 8 часов с учётом ночи и 8 часов в рабочий день — принципиально разные результаты. Отдельное правило для тишины клиента: если ответа нет больше 24 часов после первого касания, отправляется повторное сообщение через 4 часа, а если и на него нет реакции — включается прописанный сценарий эскалации, а не тишина с обеих сторон. Все переписки при этом должны идти через фиксируемые каналы (открытые линии CRM), а не через личный WhatsApp менеджера — иначе при споре с клиентом компании нечем подтвердить свою позицию. Саботаж менеджеров: почему система контроля вызывает сопротивление и как его снять Менеджеры сопротивляются контролю качества не потому, что им есть что скрывать, а потому что оценку, которую они не понимают и с которой не могут поспорить, воспринимают как произвол — и это сопротивление снимается не приказом, а прозрачностью процедуры. Рабочий инструмент — калибровочная сессия «глаза в глаза» с каждым менеджером: руководитель разбирает одну реальную встречу, показывает автоматическую оценку и чек-лист, вслух проговаривает точки согласия и расхождения. Смысл не в том, чтобы менеджер согласился со всеми баллами, а в том, чтобы он видел логику модели и мог указать на её слепые зоны — это одновременно и обучение системы, и снятие тревоги команды. Пропуск этого шага — самый частый способ получить формально работающую систему контроля и фактически саботирующий её отдел продаж. Подробный разбор, как внедрить контроль звонков и не остаться без отдела продаж, — в материале про менеджеров против прослушки . С чего начать: минимальный контур за одну неделю Минимальный рабочий контур на неделю — это не внедрение полной системы, а ручная сверка на небольшой выборке звонков в Google Таблице, чтобы получить первые цифры до того, как тратить деньги на интеграцию. Выгрузить вручную 15–20 звонков за неделю из CRM (или попросить менеджера по автоматизации настроить разовую выгрузку по API) в Google Drive. Прогнать их через транскрибацию (любой доступный сервис распознавания речи) и вставить в Google Таблицу — сразу с учётом лимита символов ячейки, короткий фрагмент плюс ссылка на полный текст. Составить один чек-лист на 5 критериев под самый частый тип звонка в отделе (обычно это первичный звонок лида). Оценить эти же звонки вручную и параллельно прогнать через ИИ по тому же чек-листу. Посчитать дельту между оценками — это и есть ваша стартовая метрика доверия к будущей автоматизации. Этого достаточно, чтобы через неделю принести на планёрку не мнение «наверное, стоит попробовать нейросети», а таблицу с конкретными цифрами расхождения. Похожий путь — от 25% ручного охвата до 100% через нейросеть — уже проходили на другом отделе продаж, где итог считали в оценках и деньгах: 7139 оценок в месяц при затратах около $300 и всего одном негативном отзыве команды на весь запуск — детали в разборе контроля качества без штатного ОКК . Три промпта под три задачи контроля Мы пришли к этому не сразу: первый универсальный промпт давал усреднённую оценку, которая никого не устраивала. Один промпт не закрывает весь контроль качества: классификация типа звонка, оценка по чек-листу и анализ переписки на эмпатию — три разные задачи с разной ценой ошибки, и под них нужны разные модели. Промпт 1. Классификация типа звонка (дешёвая модель, например gpt-4o-mini). Используется как первый фильтр перед подключением тяжёлого промпта оценки. Вход — транскрипт, полученный по вебхуку из Bitrix24 при смене статуса сделки. Пример ответа модели: Промпт 2. Оценка звонка по релевантному чек-листу (дорогая модель, например GPT-4o или Claude Sonnet). Подключается после классификации, использует контекст предыдущих звонков с тем же клиентом. Вход — из amoCRM API: транскрипт, тип звонка (из промпта 1), история предыдущих касаний. Пример ответа модели: Промпт 3. Анализ переписки на эмпатию и деловую коммуникацию (дешёвая модель, ежемесячный batch-прогон). Вход — выгрузка чатов за месяц из Google Sheets, куда стекаются диалоги из открытых линий CRM. Пример ответа модели: Экономика: сколько стоит и когда окупается Наши цифры даю как ориентир — считайте на своём потоке и своей ставке контролёра. На отделе из 8 менеджеров с оборотом 9 млн ₽/мес и чеком 180 тыс. ₽ система контроля качества окупается в течение 1–2 месяцев после завершения калибровки — но первые три месяца параллельного прогона придётся платить дважды: за ручной контроль и за ИИ одновременно. Разовая настройка интеграции (выгрузка из CRM, классификация, чек-листы, личный кабинет) — это в среднем 2-3 недели работы программиста или подрядчика. Дальше — ежемесячная стоимость обработки: при 8 менеджерах и примерно 15 звонках в день на человека набегает около 2600 звонков в месяц, обработка каждого (транскрибация + классификация + оценка) через связку дешёвой и дорогой модели обходится примерно в 19 ₽ за звонок, а в сумме выходит около 50 000 ₽ в месяц — раскладка ниже в таблице. Статья Сумма (легенда, оценка) Комментарий Разовая настройка интеграции 150 000 ₽ Выгрузка из CRM, классификация, чек-листы, кабинет Обработка звонков ИИ, ежемесячно 50 000 ₽/мес ~2600 звонков × ~19 ₽ (транскрибация + скоринг) Доп. время ОКК на калибровку (3 мес.) 40 000 ₽/мес ~40 часов ручной сверки по ставке 1000 ₽/час Экономия ФОТ после отказа от 1 ставки контролёра 60 000 ₽/мес При переходе на 100% автоматический охват Снижение риска сорванных сделок 450 000 ₽/мес ~2,5 спасённые сделки из ~50/мес при чеке 180 тыс. ₽ Сделок в месяц ≈ оборот / средний чек = 9 000 000 / 180 000 = 50. Если 10% сделок зависает из-за пропущенных ошибок в звонках (не выявлено возражение, забыт follow-up) — это 5 сделок под риском, то есть риск в деньгах ≈ 5 × 180 000 = 900 000 ₽/мес до внедрения контроля. Если контроль спасает половину из них — выгода ≈ 450 000 ₽/мес (оценка). посчитайте на своих цифрах оборот в месяц, ₽ % зависших сделок % спасаемых контролем экономия ≈ {X} ₽ в месяц формула: оборот × доля зависших сделок × доля спасаемых контролем; оценка сверху Что мы не считаем эффектом: время, которое контролёр качества освобождает при переходе на выборочную ручную проверку, — если эти часы просто перераспределяются на другие задачи, а не сокращают ФОТ, в деньги их не переводим. Итог: ежемесячные расходы на систему (50–90 тыс. ₽ на калибровочной фазе) многократно перекрываются экономией на ФОТ и спасёнными сделками ещё до конца первого квартала эксплуатации. Похожую экономику, но в конкретных цифрах чужого внедрения — 7139 оценок в месяц за $300 — уже показывали выше, в разборе про контроль качества без штатного ОКК , на примере отдела без штатного ОКК. Важно не путать эффект: экономия здесь — результат именно контроля качества звонков, а не всего комплекса автоматизации отдела продаж. Где ломается. Ошибка в коде интеграции может обходиться дорого даже на этапе тестов: зафиксированный случай — циклический запрос за одну ночь съел 40 долларов. Это немного в абсолютных числах, но это сигнал: система должна работать с лимитами и алертами на аномальный расход с первого дня, а не после первого инцидента. Зрелость по уровням: где вы сейчас Найдите свой уровень и посмотрите, что делает следующий — это и есть ваша ближайшая задача. Зрелость системы контроля качества измеряется не количеством купленных инструментов, а долей звонков под контролем и тем, насколько команда доверяет оценке — на старте это обычно 25% и недоверие, через год — 100% и встроенное в регламент обучение. Уровень Охват звонков Что уже работает Старт (недели 1–4) ~25%, вручную Ручная сверка на выборке (в проверенной практике — 66 звонков), 1 базовый чек-лист, первые цифры дельты между человеком и моделью Квартал (мес. 2–3) 50–80%, параллельный прогон 10 чек-листов под разные типы звонков, калибровочные сессии с каждым менеджером, классификация типа звонка автоматическая Год 100%, полностью автоматически Отказ от отдельной штатной единицы контроля, речевая аналитика переписок, SLA-бот по мессенджерам, отчёт по эмпатии ежемесячно Набор из 10 чек-листов под разные сценарии — не избыточность, а следствие того, что разные типы звонков реально проверяются разными критериями; как это выглядит в готовой конфигурации — уже разбирали в разделе про калибровку выше. Чек-лист на первый понедельник Прогнать пять шагов минимального контура из раздела выше: выгрузка, транскрибация, чек-лист на 5 критериев, ручная плюс ИИ-оценка, дельта. Назначить дату калибровочной сессии с одним менеджером — на разбор реальной встречи. Проверить, где сейчас хранится переписка с клиентами: если в личном WhatsApp — начать перевод в фиксируемый канал CRM. Начните не с техники, а с одного вопроса своему руководителю отдела: сколько звонков он послушал на прошлой неделе и что после этого изменилось. Ответ покажет, нужна ли вам автоматика или сначала нужна привычка разбирать. Как собрать контур целиком — в бесплатном курсе для руководителей . Что мы поняли за три месяца эксплуатации Мы построили этот контур и получили красивые цифры охвата. А потом я обнаружил, что оценки почти не превращаются в разговоры с менеджерами: система работала, управление — нет. Навык, который тут вырастает и которого раньше не было ни у кого в отделе: судить о качестве чужого разговора по записанному правилу, а не по впечатлению. Я сам долго думал, что это интуиция руководителя и её нельзя формализовать. Оказалось, можно — и первый же чек-лист показал, что мы с руководителем отдела оценивали одни и те же звонки по-разному на четверть. Мой личный вывод после года с этим контуром: техническая часть здесь занимает от силы треть усилий. Остальное — привычка руководителя отдела разбирать результаты и менять по ним скрипты. Без этой привычки вы получите самый дорогой в мире генератор отчётов.