# Директор и машина — Финансы: полные тексты (часть 1 из 2)

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

## Управленческая отчётность: один источник правды вместо трёх мнений
URL: https://davidgerstein.pro/finansy/upravlencheskaya-otchetnost/
Дата: 2026-08-31
Направление: Финансы
Цифры: 3 обязательных атрибута показателя, расхождение прибыли 39 879 vs 38 790, выручка в файле и дашборде разошлась в сотни раз
Коротко: Управленческая отчётность — это не набор отчётов, а один источник правды на каждый показатель, с назначенным хозяином и расписанием обновления. Пока источников больше одного, руководитель не управляет, а выбирает между версиями реальности: на сверке в компании на 40 человек дашборд показал прибыль 39 879 против ожидаемых 38 790, а выручка в файле и в дашборде разошлась в сотни раз — причину на встрече не установили. Рабочая конструкция: 3 атрибута у каждого показателя (источник, хозяин, срок обновления), 1 сводный отчёт вместо нескольких, фиксированный день недели и светофор по нормативам вместо ручного поиска проблем.

Суммы пересчитаны на условную компанию — пропорции, механика и выводы реальные. Вас спрашивают, сколько компания заработала в прошлом месяце. Вы открываете таблицу финансиста — одна цифра. Выгрузка из 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/blog/upravlencheskaya-otchetnost-msb/
Дата: 2026-09-03
Направление: Финансы
Цифры: 25%→10% доля просроченной дебиторки (60+ дней); ~19 000 ₽/мес экономии времени финансиста (оценка); 40–50 тыс ₽ премия за перевыполнение плана
Коротко: Кассовый разрыв — это не убыток, а нехватка денег на счёте в конкретный день: в плохой месяц он доходил до 1,2 млн ₽ и обнаруживался в день платежа. Лечится не кредитом, а расписанием: остатки по счетам минус обязательные платежи на 7–14 дней вперёд, пересчитанные в фиксированный день недели. Двухнедельный план задач финансиста и автоматическая сверка данных снизили долю просроченной дебиторки (60+ дней) с 25% до 10%. Настройка автоматического отчёта заняла около 8 часов, эксплуатация — около 600 ₽ в месяц.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Что такое кассовый разрыв и почему его видят в день платежа Кассовый разрыв — это не убыток и не нехватка прибыли, а нехватка денег на счёте в конкретный день: платить уже надо, а поступления ещё не пришли. В отчёте о прибыли он не виден в принципе — только в графике платежей на две-четыре недели вперёд. Если вы держите этот график в голове, а не в таблице, разрыв обнаружится в день платежа. В компании на 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 минут — автоматизация уведомлений рефералам
Коротко: Просроченная дебиторская задолженность копится не из-за «плохих клиентов», а из-за отсутствия регламента возврата и ежедневного контроля по срокам. В разобранном кейсе клиент потребовал вернуть всю крипто-предоплату за день — компания вернула 270 000 ₽ из 330 000, удержав расходы и бонус. За 6 недель после внедрения ежедневного дашборда доля просрочки старше 30 дней снизилась с 24% до 11% (оценка).

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Просроченная дебиторская задолженность растёт не потому, что клиенты плохие. Она растёт, потому что у вас нет правила, что делать в день просрочки, — и каждый случай решается заново, в панике и по-разному. Ниже — история, в которой клиент потребовал вернуть предоплату целиком за один день, и то, что мы перестроили после неё. Если у вас в компании возвраты и просрочки разруливаются «по ситуации» — это про вас. Просроченная дебиторская задолженность: что делать в первую очередь Просроченная дебиторская задолженность копится не из-за плохих клиентов, а из-за отсутствия регламента возврата и ежедневного контроля по срокам. Долг зреет тихо: никто не отвечает за конкретную дату, напоминание уходит, когда сумма уже стала проблемой. После постановки контроля доля просрочки 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/dashboard-dlya-rukovoditelya/
Дата: 2026-08-31
Направление: Финансы
Цифры: 2 недели без единого захода, 1 вопрос к каждому блоку, переход в карточку важнее любого графика
Коротко: Дашборд руководителя умирает не от плохих данных и не от дизайна, а от отсутствия названного адресата: дашборд отдела продаж собрали, запустили и показали — через 2 недели выяснилось, что в него не заходит никто, потому что не назвали, кто по нему принимает решения. Рабочая проверка каждого блока — одним вопросом: какое действие человек совершает, увидев это. Главный элемент дашборда не график, а переход в карточку объекта одним кликом. Отдельная вкладка под то, что нельзя пропустить, работает лучше, чем те же данные внутри общей таблицы.

Цифры пересчитаны на условную компанию — механика и выводы реальные. Если у вас есть дашборд, но вы не можете назвать имя человека, который по нему принимает решения, — дашборда у вас нет, есть витрина. Наш прожил ровно 2 недели с нулём заходов, и данные в нём всё это время были в полном порядке. Что должно быть на дашборде руководителя Только те блоки, из которых следует конкретное действие, и обязательный переход в карточку объекта одним кликом. Полезный минимум для отдела продаж: пайплайн по менеджерам, дата последнего контакта, дни в статусе со светофором по нормативу, конверсия договоров в оплату. Главная причина смерти дашбордов — не данные и не дизайн. Дашборд отдела продаж собрали, запустили, показали, а через 2 недели выяснилось, что в него не заходит никто: не назвали, кто по нему принимает решения. Красивый дом, в который никто не вошёл История, после которой я перестал радоваться готовым дашбордам. Собрали. Данные тянутся, графики строятся, всё аккуратно. Показали команде, все покивали. Через две недели случайно выясняется: заходов ноль . Не «мало» — ноль. Первая реакция была предсказуемой: значит, не те показатели, надо доделать. Полезли разбираться — с показателями всё нормально. Проблема оказалась в другом: мы не назвали, кто по этому дашборду принимает решения. Он существовал как витрина: посмотреть можно, а зачем — непонятно. Если вы не можете назвать имя человека, который принимает решения по вашему дашборду, — он умрёт через две недели, и виноваты будут данные. У нас в периметре была история покрупнее и с той же болезнью. Портал: собрано 400 тысяч вопросов с автоответами, сделан дизайн, контент готов — а технически система не собралась. Формулировка коллеги стала внутренним термином: «красивый дом, но дверей нету, как зайти непонятно» . Дашборд без адресата — ровно тот же дом. Всё построено, войти некому. Один вопрос к каждому блоку Проверка, которой я теперь прогоняю любой экран. Встаньте перед своим дашбордом и на каждом блоке ответьте: какое действие человек совершает, увидев это? Не «понимает ситуацию», не «держит руку на пульсе» — действие. Кому звонит, что открывает, о чём спрашивает. Блок Какое действие следует Вердикт Сделки без касаний дольше норматива Открыть карточку, позвонить менеджеру Оставить Дата последнего контакта по клиенту Написать клиенту сегодня Оставить Конверсия договоров в оплату по менеджерам Разобрать с тем, у кого просело Оставить График выручки по месяцам за 2 года Никакого — прошлое неуправляемо Убрать или спрятать в архив Круговая диаграмма источников лидов Никакого без разреза по качеству Переделать Общее число лидов за период Никакого — цифра для хвастовства Заменить на лиды в работе на менеджера Обычно после такой ревизии остаётся четыре-шесть блоков вместо пятнадцати. И это не обеднение: каждый график, из которого не следует действие, крадёт внимание у того, из которого следует. Человек, открывший экран с пятнадцатью блоками, не изучает их — он скользит взглядом и закрывает. Отбирать проще, когда у каждого показателя заранее записаны источник, хозяин и срок обновления : блок, у которого этих трёх атрибутов нет, почти всегда и оказывается лишним. Переход в карточку важнее любого графика Самое недооценённое место. В нашем дашборде продаж работает не аналитика сама по себе, а то, что из любой строки можно провалиться в конкретную сделку — одним кликом, прямо в карточку. Без этого перехода сценарий выглядит так: руководитель видит проблемную сделку, переключается в CRM, ищет её по фамилии клиента, не находит с первого раза, отвлекается на звонок — и не возвращается. Я наблюдал это десятки раз и сам так делал. С переходом сценарий другой: увидел, кликнул, оказался в карточке, написал менеджеру. Двадцать секунд вместо пяти минут и без потери намерения по дороге. Правило Работающая аналитика заканчивается действием, а не наблюдением. Если из вашего дашборда нельзя попасть в объект, о котором он рассказывает, — вы построили не инструмент, а отчёт с картинками. Разница в том, что отчёт читают раз в месяц, а инструментом пользуются каждый день. Что реально выводим Состав нашего дашборда продаж — не как эталон, а как пример логики отбора. Каждый блок отвечает на вопрос про действие. Пайплайн по менеджерам. Кто чем занят и сколько у кого в работе. Действие: перераспределить нагрузку, если у одного втрое больше. Дата последнего контакта по каждой сделке. Самый работающий блок вообще. Действие: связаться с теми, о ком забыли. Заброшенные сделки без касаний видны сразу, а не при ручной ревизии раз в квартал. Дни в статусе и светофор по нормативу. Зелёный, жёлтый, красный по каждой стадии. Действие: разобраться с красными сегодня. У нас сделка провисела 540 дней и всё это время считалась живой — именно потому, что дней в статусе никто не считал. Конверсия договоров в оплату. Разрыв между «подписали» и «заплатили» — место, где деньги теряются тише всего. Действие: дожать конкретные неоплаченные договоры. Источники сделок. Только в связке с качеством, иначе бесполезно. Действие: перераспределить бюджет. Отдельно был запрос, который многое объясняет про смысл дашборда: показать договоры с разрезом — имя менеджера, клиент, сумма, дата выставления и была ли встреча . Зачем: чтобы видеть, когда сделки закрываются после встреч, а когда без них. Это не любопытство — это проверка гипотезы, что встречи вообще нужны. Хороший дашборд позволяет такие гипотезы проверять, а не только смотреть на итоги. Блоки с явным действием — 60% ценности Переходы в карточки объектов — 30% Обзорные графики и итоги — 10% Отдельная вкладка под то, что нельзя пропустить Приём, который сработал лучше, чем ожидалось. У нас есть категория клиентов, которых нельзя терять по невнимательности: крупный чек, высокая цена ошибки. Формально они видны в общей таблице — вместе со всеми остальными. Мы вынесли их в отдельную вкладку с ежедневной проверкой статусов и переходом в карточку. Ничего технически сложного: тот же список, отфильтрованный по порогу суммы. Эффект оказался непропорционален усилиям, и причина в психологии, а не в данных. В общей таблице такой клиент требует, чтобы про него вспомнили. В отдельной вкладке он сам напоминает о себе фактом её существования. Вспоминать — плохой механизм , он ломается ровно в тот день, когда вы заняты. По той же логике мы вынесли отдельно платёжный календарь и контроль персонального обслуживания. Каждая вкладка — это одна ответственность одного человека, а не срез данных. Разбирал этот случай подробно — платёжный календарь . Кто смотрит: сверху вниз или каждый своё Развилка, которую стоит пройти осознанно. Первый вариант: дашборд смотрит собственник, а остальные получают выжимку. Второй: каждый руководитель смотрит своё подразделение сам — маркетинг, продажи, платёжный календарь, персональное обслуживание. Мы пришли ко второму, и разница оказалась не в удобстве. Пока переходы видит только первое лицо, руководители работают с итоговой цифрой в голове и узнают о проблеме, когда её называют вслух на планёрке. Когда каждый видит свою конверсию рядом с нормативом, часть проблем решается без вашего участия — просто потому, что человек видит своё отклонение. Неприятная сторона: до этого он его не видел годами, а вы были уверены, что он в курсе. Я через это прошёл и рекомендую не обижаться, а исправлять. Данные есть, решений нет Худший сценарий не «дашбордом не пользуются», а «дашбордом пользуются, но ничего не меняется». Он выглядит благополучно и потому живёт годами. Наш пример честнее любого чужого: контур оценки разговоров выдал 7 139 оценок , а в управленческое решение превратилась ровно одна . Данные копились, экран работал, петля не замкнулась. Проверка на своём дашборде: назовите три решения, принятые по нему за последний месяц. Не «посмотрели и обсудили» — решения: кого-то перераспределили, кому-то позвонили, что-то отменили. Если трёх не набирается, у вас витрина. Лечится это не доработкой экрана, а ритуалом: фиксированный день, когда по дашборду проходят и принимают решения вслух. Как это устроено в недельном цикле — разобрал отдельно . Четыре способа убить дашборд, которые выглядят как забота Добавить всё, что попросили Каждый руководитель на демонстрации просит что-то своё, и отказать неловко. Через три итерации экран превращается в свалку, где нужное соседствует с тем, что попросили один раз для проверки гипотезы и забыли. Правило простое: новый блок добавляется только вместе с ответом на вопрос про действие, и раз в квартал проводится ревизия на вылет. Показывать всё за всё время Соблазн вывести историю за два года понятен: выглядит солидно. Но управляемо только ближайшее — эта неделя, этот месяц. История нужна раз в квартал при планировании, а не ежедневно. Уберите её на отдельную вкладку, и главный экран сразу станет читаемым. Обновлять реже, чем принимаются решения Дашборд, обновляющийся раз в сутки, бесполезен для того, кто принимает решения по ходу дня. Мы делали отчёт по воронке с ежечасным обновлением именно поэтому: сделка, которая встала утром, должна быть видна днём, а не завтра. И обратное верно — ежечасное обновление показателя, по которому решают раз в месяц, только создаёт шум. Сделать вход неудобным Самая обидная категория. Отдельный логин, VPN, ссылка, которую надо искать в переписке, — и всё, дашборд не открывают. Не потому что он плох, а потому что каждое открытие стоит усилий. У нас он живёт по своему адресу, открывается с телефона и не требует вспоминать пароль каждый раз. Это не про удобство, это про то, будут им пользоваться или нет. Как понять, что дашборд прижился Три признака, все наблюдаемые без опросов. Первый: на планёрке на него ссылаются, а не приносят свои выгрузки. Пока люди готовят собственные таблицы к встрече, у дашборда нет доверия — и обычно оно отсутствует не зря: где-то он расходится с реальностью, и это стоит найти. Второй: в него заходят не в день разбора. Если пики посещений приходятся строго на четверг перед планёркой, значит, им пользуются как подготовкой к отчёту, а не как рабочим инструментом. Ровный поток заходов среди недели — признак, что он встроился в работу. Третий: вас перестали спрашивать цифры. Самый приятный признак. Если раньше вопрос «а сколько у нас сейчас в пайплайне» прилетал вам, а теперь человек смотрит сам, — дашборд занял своё место. И заодно вернул вам изрядный кусок времени, который раньше уходил на пересказ данных. Промпт: ревизия дашборда Ревизию можно провести самому, но чужой взгляд полезен тем, что не жалеет блоки, на которые потрачена работа. Опишите машине состав экрана и попросите быть безжалостной — а потом решайте сами, потому что она не знает вашего контекста. Навык, который тренируется Проверять любой экран вопросом «какое действие отсюда следует» — навык, который экономит месяцы разработки. Он работает не только на дашбордах: на отчётах, на письмах, на презентациях для команды. Везде одинаково: если из увиденного не следует действие, человек это не запомнит и не применит. Дашборд — самый дорогой способ узнать эту истину, потому что его сначала разрабатывают, потом наполняют, потом презентуют, и только потом обнаруживают, что заходов ноль. Мы прошли этот путь целиком, и я до сих пор считаю те две недели самыми полезными в истории проекта. Все компании сейчас на одной беговой дорожке, и данных на ней у всех примерно поровну. Обгоняют не те, у кого больше графиков. Обгоняют те, у кого от увиденной проблемы до звонка ответственному проходит двадцать секунд, а не пять минут и одно отвлечение. Проверьте сегодня свой дашборд этим вопросом — пройдите по блокам и назовите действие для каждого. Выпишите те, где действия нет, и уберите их на следующей неделе. Экран станет беднее и полезнее.

## Показатели отдела продаж: не «сколько», а «где просело»
URL: https://davidgerstein.pro/blog/kakie-otchety-nuzhny-rukovoditelyu/
Дата: 2026-08-31
Направление: Финансы
Цифры: 4 перехода вместо 1 итога, конверсия 14% при плане 23%, средний чек +35% к плану на фоне провала
Коротко: Показатели отдела продаж в недельном отчёте должны показывать причину, а не результат: итоговая выручка — уже случившееся, управляемы только переходы между этапами. Разбор реальной недели: 80 000 € при плане 100 000, закрыто 7 сделок из 16, общая конверсия 14% против плана 23%. Разложение по переходам показало, что провал не на входе — конверсия во встречу 55% при 49 встречах, — а на закрытии: из встреч в договор дошли 22%. При этом средний чек шёл выше плана и в одиночку выглядел успехом. Отдельный сюжет: 3 менеджера продавали стабильно больше, чем 6–7.

Суммы пересчитаны на условную компанию — пропорции, механика и выводы реальные. Какие показатели отдела продаж смотреть в недельном отчёте Если у вас в недельном отчёте стоят выручка и число сделок — вы смотрите на результат, а не на управляемые показатели отдела продаж. Смотреть надо шесть строк: четыре перехода — лид → квалификация → встреча → договор → оплата — плюс средний чек и нагрузку на менеджера. Решение принимается по тому переходу, который просел сильнее всего относительно плана. В разобранной неделе итог был 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% — это много или мало? Без вашего собственного норматива ответа нет, и планёрка превращается в обмен мнениями. Норматив не обязан быть научным: возьмите лучший месяц за год и считайте его ориентиром, пока не наберёте статистику. Главное, чтобы он был записан и не менялся задним числом под результат. Сравнение с прошлой неделей вместо плана Соблазнительно и почти всегда вредно. Прошлая неделя могла быть провальной, и рост к ней — не достижение. Ещё хуже с сезонностью: сравнение соседних недель в период спада показывает падение там, где всё идёт по норме. Сравнивайте с планом и с той же неделей прошлого года, а недельную динамику держите как справку. Отчёт, который читает один человек Если раскладку видите только вы, менеджеры продолжают работать с итоговой цифрой в голове. Переходы должны быть видны тем, кто на них влияет: конверсия из встречи в договор — забота менеджера, а не ваша. Мы дошли до этого через дашборд , где руководители смотрят своё подразделение сами, вместо того чтобы получать выжимку сверху. Что делать с найденным провалом Разложение показывает место, но не причину. Дальше работает простая последовательность, и она короче, чем кажется. Первое: посмотрите руками десять случаев. Не отчёт, а сами сделки, которые не дошли до договора. В нашем случае это означало послушать разговоры со встреч. Десяти хватает, чтобы увидеть закономерность, а если закономерности нет — это тоже ответ: значит, дело не в этапе, а в потоке. Второе: сформулируйте гипотезу проверяемо. «Низкая мотивация» — не гипотеза, её нельзя проверить за день. «Менеджеры не выясняют бюджет до презентации» — гипотеза: берём десять записей, считаем, в скольких прозвучал вопрос про бюджет. Третье: правьте один этап за раз. Если чинить одновременно вход и закрытие, через месяц вы не поймёте, что сработало. Скучно, зато к третьему месяцу у вас появляется знание, а не набор одновременных изменений. Именно так конверсия у нас и росла — на процентный пункт в месяц. Не рывком: рывки в этих цифрах обычно означают, что поменялся способ подсчёта, а не работа. Промпт: разложить неделю на переходы Если у вас нет автоматической сборки, разложение можно сделать руками за пятнадцать минут — или отдать машине выгрузку и получить готовую раскладку с гипотезами. Гипотезы проверяйте, они бывают убедительно неверными. Как это выглядит через полгода Стоит сказать, ради чего вся эта дисциплина, — потому что первые недели она ощущается как лишняя работа. Через два-три месяца еженедельных разборов у вас накапливается ряд по каждому переходу. И вот тут появляется то, чего не даёт ни одна отдельная неделя: вы начинаете видеть не события, а тенденции . Конверсия во встречу держится, а из встречи в договор медленно ползёт вниз третий месяц подряд — в отдельной неделе это тонет в шуме, в ряду видно сразу. Второе, что появляется, — способность отличать случайность от проблемы. Одна плохая неделя ничего не значит: у нас были недели, где всё просело из-за праздников и одного заболевшего менеджера. В ряду такие провалы видны как выбросы, а не как повод устраивать разбор полётов. Это, кстати, снимает изрядную часть нервотрёпки: перестаёшь реагировать на каждое колебание. Третье — самое ценное для планирования. Зная свои переходы, вы можете считать назад: чтобы получить нужную выручку при вашей конверсии, требуется столько-то встреч, а для них — столько-то лидов. План перестаёт быть цифрой, спущенной сверху, и становится расчётом, который команда может проверить. Спорить с расчётом гораздо сложнее, чем с желанием собственника. И последнее наблюдение, неприятное. Когда переходы становятся видны всем, часть проблем решается сама — просто потому, что человек видит свою цифру рядом с нормативом. Неприятно тут то, что до этого он её не видел годами, и вы считали, что он в курсе. Навык, который тренируется Раскладывать результат на переходы — базовый навык чтения любой воронки: продаж, найма, производства, обучения. Везде одна механика: итог неуправляем, управляемы переходы между состояниями. Проверка на себе за минуту. Возьмите последний недельный результат и ответьте: какой конкретно переход просел сильнее всего? Если вы можете назвать только итоговую цифру — отчёт у вас есть, управления по нему нет. Все компании сейчас на одной беговой дорожке. Обгоняют не те, кто быстрее реагирует на плохую выручку, — на неё реагировать поздно. Обгоняют те, кто в понедельник видит просевший переход и правит его, пока он не превратился в выручку следующего месяца. Выпишите сегодня четыре перехода последней недели — на листе бумаги, без всякой автоматизации. Посчитайте проценты, поставьте рядом свой норматив и назовите вслух тот переход, где отклонение самое большое. Пятнадцать минут, и вы либо подтвердите то, что думали, либо обнаружите, что чинили не то место.

## Финансовый контроль бизнеса: где расходятся цифры CRM и кассы
URL: https://davidgerstein.pro/blog/sverka-platezhej-crm/
Дата: 2026-08-15
Направление: Финансы
Цифры: сдвиг дат 18–36 часов · дефицит кэша ~700 тыс. ₽/мес (оценка) · возврат сокращён примерно на пятую часть
Коротко: Финансовый контроль бизнеса рушится не на бланках, а на определениях: расхождения между CRM и бухгалтерией чаще всего возникают не из-за воровства, а из-за трёх вещей: даты сделок технически съезжают при синхронизации на 18–36 часов, момент признания дохода в CRM и в кассе не совпадает, возвраты нигде не фиксируются отдельным регистром. Сверка работает, если строить её на регулярных выгрузках и автоматическом сравнении, а не на доверии к интерфейсу CRM.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас каждый месяц повторяется одна и та же сцена — маркетолог показывает выручку из 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/debitorka-pod-kontrolem/
Дата: 2026-08-07
Направление: Финансы
Цифры: лимит на порядок меньше нужного · долг перед поставщиком ~1,1 млн ₽ · дефицит кассы ~900 тыс ₽/мес
Коротко: Контроль дебиторской задолженности держится на трёх метриках, которые видны каждый день без запроса: объём долга, распределение по срокам и по пакетам услуг. Без резерва на цикл между расходом и платежом клиента компания рано или поздно занимает деньги под зарплату — в одном из кейсов такой разрыв обернулся долгом перед поставщиком на ~1,1 млн ₽.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Назовите три числа: сколько вам должны, сколько из этого просрочено и у кого самый большой долг. Не можете — значит, дебиторкой в вашей компании не управляет никто, и это не фигура речи. Если вы держите эти три числа в голове, а не в отчёте, — у вас не контроль, у вас память двух-трёх человек. Она работает ровно до отпуска, увольнения или просто загруженной недели. Дальше вы узнаёте о своих деньгах от того, кому не заплатили. Ниже — три метрики, которые закрывают этот вопрос, и способ собирать их без ручного свода каждую неделю. Что такое контроль дебиторской задолженности на практике Контроль дебиторской задолженности — это три числа, которые видны в системе каждый день и которые не нужно ни у кого запрашивать: общий объём долга клиентов, его распределение по срокам просрочки и распределение по пакетам услуг. Отчёт раз в месяц контролем не является: к моменту его выхода решение уже принято или упущено. Собирается это так: выгрузка сделок из 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 дня после срока. Назначить день и час недели, когда финансовые данные точно собраны, и планировать разбор дебиторки именно на это время, а не на утро по неполным цифрам. Что сделать в понедельник: соберите три метрики из этой статьи руками — один раз, на бумаге. Час работы даст вам картину, которой у вас, скорее всего, никогда не было. Автоматизацию поставите потом, когда поймёте, на что смотреть каждую неделю. Механика — в бесплатном курсе . И правило, которое я вывел для себя: разговор о деньгах с клиентом всегда легче до просрочки, чем после. До — вы уточняете сроки. После — вы требуете. Разница в тоне огромная, а определяется она одним: знаете ли вы о приближении срока заранее. Как это выглядело у нас Мы начинали с того, что дебиторку никто не смотрел системно: помнили пару крупных должников, остальное всплывало случайно. Первый же собранный список показал, что мелких просрочек больше, чем крупных, и в сумме они дают больше денег — просто их не видно поодиночке. Дальше мы сделали скучную вещь: назначили день недели, в который список смотрится, и человека, который его приносит. Никакой автоматизации на старте не было — обычная выгрузка и полчаса времени. Эффект пришёл в первый же месяц, и только потом мы отдали сбор машине. И назову вслух то, что обычно остаётся за скобками. Держать деньги под контролем через машину — это отдельный управленческий навык, и осваивать его придётся лично вам, а не вашему финансисту. Руководитель, который умеет собрать конвейер и читать его сводку за пять минут, стоит дороже руководителя, который умеет только спросить «сколько нам должны» и ждать полдня ответа. Ещё пару лет назад это было приятным дополнением к профессии. Сейчас это входной билет. Мой вывод: контроль дебиторки — это привычка, а не система. Систему можно купить, привычку придётся завести самому. Заведите эту привычку на этой неделе: назначьте день, назначьте человека, посмотрите первый список. Как автоматизировать сбор потом — в бесплатном курсе .

## Сколько стоит ИИ на самом деле: мои счета, минус $40 за ночь и шлюз учёта
URL: https://davidgerstein.pro/blog/skolko-stoit-ii-realnye-rashody/
Дата: 2026-08-01
Направление: Финансы
Цифры: −$40 за ночь · ~$300/мес за 100% звонков · 11 сервисов на шлюзе
Коротко: Эксплуатация ИИ для среднего бизнеса стоит сотни долларов в месяц, а не миллионы в год: оценка всех звонков ~$300/мес. Дорогое — внедрение и люди. Учёт расходов ставится до первого запуска: одна зациклившаяся строчка кода сожгла $40 за ночь.

Цифры компании и отдела продаж в этом тексте — обобщённый профиль сервисного бизнеса: 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 примерах и сравнить качество. Завести единую точку входа для вызовов модели, даже если сервисов пока два. Поставить лимит расходов на уровне двух ожидаемых месячных сумм и оповещение — на уровне одного. Логировать каждый вызов (сервис, дата, токены, стоимость, модель) в таблицу, а не смотреть общий баланс раз в месяц. Отделить эффект в деньгах от эффекта в часах: если часы фактически не высвободились, эта цифра не идёт в отчёт руководству. Резюме короткое. Видеть, сколько стоит ИИ в вашей собственной операции, — управленческий навык, а не бухгалтерия: пока вы не знаете себестоимость одного звонка или одного документа, вы не можете сказать, окупается ли работа, и любые разговоры о пользе остаются разговорами. Навык ставится один раз и дальше работает на каждой следующей задаче. Сделайте на этой неделе одно: найдите, сколько именно ушло за прошлый месяц и на какие задачи. Даже если это будет неточная прикидка по трём счетам — вы удивитесь, сколько решений станет очевидными сразу после появления этой цифры. У меня стало очевидным, что половину задач надо гонять через модель попроще, — и счёт упал вдвое без потери качества. Как поставить учёт нормально, с разбивкой по сервисам и стоп-краном на превышение, — разбираю по шагам в бесплатном курсе .