Аудит автоматизации: кладбище тихо сломанных вещей

Я управляю 16 виллами на Бали без операционного офиса. Нет штата менеджеров, которые снимают трубку и отвечают на каждый запрос. Вместо них — команда ботов, скриптов и баз данных, которая работает круглосуточно: отвечает гостям в Instagram и WhatsApp, ведёт бронирования, обновляет цены на платформах, формирует финансовые отчёты для инвесторов. Всё это работает без моего участия в каждом конкретном действии.

И я привык к тому, что «оно само»: гость написал — через 15 секунд получил ответ, дашборд обновился — данные актуальны, рассылка отработала — сообщения доставлены. Примерно такая картина у меня в голове. Красивая и удобная картина.

10 мая 2026 года я решил проверить, насколько она соответствует реальности. Провёл один полный день, проходя по ключевым точкам системы. Нашёл четыре поломки. Три из них система не сообщала ни разу — никакого алерта, никакой ошибки в интерфейсе, полная тишина. Всё выглядело живым. Часть давно не работала.

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

Как выглядит «рабочая» система изнутри — и почему это опасно

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

Потом система начинает работать стабильно. Гости довольны, бронирования идут, деньги поступают. Постепенно ты перестаёшь смотреть на внутренности. Зачем? Всё же работает. И ты переключаешь внимание на стратегию, на новые проекты, на другие задачи. Это нормально — именно ради этого и строится автоматизация.

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

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

Я думал, что у меня не так. Оказалось — так же.

Кейс 1. Поллер Instagram молчал 22 дня и пропустил 304 сообщения

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

Я зашёл в логи этого механизма и увидел дату последней успешной проверки: 18 апреля 2026 года. Сегодня — 10 мая. Прошло 22 дня.

За эти 22 дня механизм не проверял входящие вообще. Гости писали в Instagram — и получали тишину. Никакого ответа, никакого автоматического «мы скоро свяжемся с вами», ничего.

Когда я вытащил список необработанных сообщений за этот период, получилось 304 диалога. Среди них — живой лид от 5 мая. Человек написал с конкретным запросом: две виллы, три недели, август. Написал за пять дней до моей проверки и не получил никакого ответа. Вероятно, ушёл к конкурентам или решил, что Instagram-аккаунт заброшен.

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

Никакого алерта не было. Я узнал об этом только потому, что пошёл проверять руками.

Что сделал сразу

Написал лиду от 5 мая вручную — объяснил задержку, предложил уточнить даты. Восстановил работу механизма. Добавил ежедневную проверку: если за сутки не было ни одного обработанного входящего из Instagram — это аномалия, нужно уведомление. В нормальном режиме за день приходит минимум 3-5 сообщений. Ноль — не норма, это сигнал разбираться немедленно.

Кейс 2. Два WhatsApp бота шесть недель противоречили друг другу

Второй кейс — сложнее по последствиям. У меня два номера WhatsApp для работы с гостями: основной и резервный. В определённый момент я обновил инструкции для бота — там появились более чёткие формулировки про условия заселения и политику отмены бронирования. Конкретные формулировки вместо размытых.

Но в процессе обновления я применил новые инструкции только на один номер. Второй остался со старой версией. И это продолжалось шесть недель — с конца марта до середины мая.

Конкретная ситуация: гость спрашивает про отмену бронирования. С основного номера бот говорит: возврат возможен за 14 дней до заезда. С резервного — за 30 дней. Разные сроки, разные условия, один бизнес. Если в ходе переговоров гость писал на оба номера — а такое бывает, когда первый отвечает медленнее или гость просто не запомнил, какой номер основной — он получал взаимоисключающую информацию.

Сколько таких разговоров было за шесть недель? Я не знаю точно. Проверил последние три недели — нашёл несколько диалогов, где использовались оба номера. Часть из них закончилась бронированием, часть — нет. Насколько противоречие в условиях повлияло на решения — установить уже невозможно. Это и есть самое неприятное в подобных поломках: ущерб неизмерим.

Никакого предупреждения от системы не было. Оба бота работали. Просто с разными данными и разными правилами.

Что изменил

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

Кейс 3. Аккаунт для голосовых заметок протух 9 мая

Третий кейс — короткий по деталям, но показательный по механике. Именно он лучше всего иллюстрирует, как система может принимать запросы и при этом ничего не делать.

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

9 мая истёк токен авторизации этого инструмента. Голосовые я продолжал отправлять — инструмент принимал их без единого сообщения об ошибке. Но расшифровка не происходила, данные никуда не попадали. Всё уходило в пустоту.

Я не знал об этом до 10 мая. За день-два до аудита отправил несколько голосовых заметок с задачами и идеями. Они исчезли.

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

Что изменил

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

Кейс 4. Дашборд инвесторов: минус 1.2 миллиарда против плюс 190 миллионов

Четвёртый кейс — самый тяжёлый по смыслу. У меня есть дашборд для инвесторов, которые вложили деньги в виллы. Там видна прибыль по каждому объекту, баланс, история выплат. Инвесторы заходят туда и смотрят, как работает их вложение. Это живой инструмент принятия решений, не просто таблица с цифрами.

При аудите я сравнил данные дашборда с реальными цифрами из базы данных напрямую — без дашборда, просто через запросы к данным. Дашборд показывал суммарный P&L около минус 1.2 миллиарда индонезийских рупий — это примерно минус 75 тысяч долларов. То есть бизнес выглядел убыточным. Серьёзно убыточным.

После исправления логики расчёта цифра изменилась: плюс 190 миллионов рупий — примерно плюс 12 тысяч долларов. Разница — 1.4 миллиарда рупий, около 87 тысяч долларов в пересчёте. Между «бизнес убыточен» и «бизнес прибылен».

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

После добавления корректной амортизации предоплаченных контрактов по месяцам картина стала точной. Но до аудита — инвесторы видели дашборд с ошибкой на 1.4 миллиарда рупий.

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

Три из четырёх поломок система не сообщила

Вот что объединяет все четыре кейса: только в одном случае у меня было ощущение, что что-то не так. Остальные три — система не сообщила вообще. Ни разу. Никаким образом.

Поллер Instagram работал последний раз 18 апреля. Никакого алерта. Никакого «я перестал проверять входящие». 22 дня тишины при том, что бронирования через Instagram — один из ключевых каналов.

Два WhatsApp бота выдавали разные условия шесть недель. Никакого предупреждения «конфигурации не совпадают». Оба работали — просто по-разному. С точки зрения системы мониторинга всё было в порядке.

Инструмент для голосовых принимал сообщения с просроченным токеном без единой ошибки в интерфейсе. Молча принимал и ничего не делал.

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

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

Практический чеклист ежемесячного аудита автоматизации

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

Входящие каналы коммуникации

• Отправить тестовое сообщение в каждый канал — Instagram, WhatsApp, Telegram, форму на сайте. Убедиться, что бот ответил в течение минуты.
• Проверить логи за последние 7 дней: сколько сообщений пришло? Если значительно меньше типичного — возможна поломка, а не снижение интереса аудитории.
• Сравнить количество входящих с количеством обработанных ответов. Расхождение больше 5% — повод разбираться немедленно.

Согласованность конфигураций

• Если несколько номеров, аккаунтов или точек входа — сравнить инструкции для каждого. Условия должны совпадать дословно.
• Последние изменения в правилах и условиях — применены ли они везде, а не только в одном месте?
• Если менялась политика — цены, условия отмены, порядок заселения — проверить все каналы, где это упоминается.

Авторизации и токены

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

Финансовые отчёты

• Взять одну произвольную транзакцию из базы данных и проследить её путь до отчёта: правильно ли она учтена?
• Сравнить итоговые цифры отчёта с ручным расчётом хотя бы за один месяц.
• Особое внимание — к нестандартным платёжным схемам: предоплата за длинный период, рассрочка, агентские комиссии. Именно они чаще всего ломают логику расчёта.
• Если цифра вызывает сомнение — разбираться сразу, не откладывать.

Алерты и уведомления о поломках

• Для каждого критического процесса: есть ли уведомление на случай его остановки? Если нет — добавить.
• Симулировать поломку: остановить процесс на 10 минут. Пришло ли уведомление? Если нет — уведомление не работает, нужно чинить именно его.
• Уведомления должны идти туда, где их точно увидят. Не на почту, которую открывают раз в неделю, не в канал без живого читателя.

Почему это важно даже для небольшого бизнеса с одним ботом

Я слышу возражение: «У меня один Telegram-бот для записи клиентов, зачем мне сложный аудит?» Давайте посчитаем честно, что происходит, когда этот бот перестаёт отвечать на неделю.

Допустим, к вам обычно приходит 20 заявок в неделю. Конверсия в клиента — 15%. Средний чек — 5 000 рублей. За неделю тишины вы теряете 3 клиента — это 15 000 рублей. За месяц тихой поломки — 60 000 рублей только в прямых потерях. Плюс репутация: люди, которые написали и не получили никакого ответа, редко пишут второй раз. Они идут к конкурентам, которые отвечают.

В моём случае с 304 потерянными сообщениями из Instagram за 22 дня математика выглядит серьёзнее — аренда виллы не 5 000 рублей. Но принцип один для любого масштаба: невидимые поломки стоят денег. И чем дольше они живут, тем дороже обходятся.

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

Что изменилось в системе после аудита

Помимо исправления четырёх конкретных поломок, я добавил несколько системных изменений, которых раньше не хватало.

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

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

Третье: для каждого канала коммуникации — минимальный порог активности. Ноль входящих за сутки из Instagram — это аномалия, нужен алерт. Ноль обработанных сообщений за 15 минут — тоже алерт. Система должна сама сигнализировать о тишине, которая ненормальна для данного канала.

Четвёртое: финансовый отчёт каждый месяц проходит контрольную проверку — ключевые цифры сравниваются с ручным расчётом по выборке транзакций. Расхождение больше 5% — разбираться до нахождения причины. Не принимать на веру то, что показывает дашборд.

Ничего революционного в этих изменениях нет. Но именно их отсутствие позволило четырём поломкам жить неделями и месяцами незамеченными.

Главный вывод: автоматизация требует другого вида контроля, а не его отсутствия

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

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

Если убрать даже этот минимальный контроль — система начинает жить своей жизнью. Части выходят из строя тихо. Результаты становятся неточными. Возможности теряются. И внешне это невидимо.

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

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

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