Неделя превращения штата в систему: как один человек управляет портфелем вилл, финансами и командой через AI-агентов

В 5 утра Тригуна, мой балийский менеджер, проснулся от уведомления. Один из ботов отправил в рабочий чат отчёт про незавершённый чек-аут на вилле №7. Через два часа другой написал «Напоминание #6». В три ночи третий рапортовал что переезд отеля на новую управляющую компанию прошёл успешно, прислал лог из 14 строк. Балийцы спят с 21 до 06, никто это не читает в реальном времени, но звуки в телефоне будят.

Это была одна ночь обычной недели в операционке портфеля, который я веду один. 16 активных вилл на острове Бали, 9 инвесторов, каждый вложил свою сумму от полумиллиона рублей до нескольких миллионов и хочет видеть прозрачные цифры каждый день. Растущий SaaS для автоматизации продаж, где сейчас восемь живых клиентов в разных странах — от продавцов услуг в Таиланде до юристов-переводчиков в городе. Контент, который публикуется на четыре платформы одновременно. И всё это управляется не наёмными людьми, не менеджерами с зарплатой, а системой из 18 AI-агентов, каждый из которых делает одну работу правильно.

Ночная тишина: как 13 источников болтовни стали одной очередью

Утром я открыл код и посчитал. Если в рабочий чат пишут виллы-операционка (Тригуна читает это в реальном времени чтобы координировать команду на месте), финансовая сверка (нужна к 8 утра чтобы инвесторы видели свежие цифры), системные алерты о ошибках (могут подождать несколько часов), уведомления гостей о чек-ине (срочные, нужны в момент), то у меня 13 разных точек где боты инициируют сообщение в Telegram рабочий чат. И только одна из них знала про ночное время на Бали (21:00-06:00).

Проблема была в том что все остальные 12 источников были написаны независимо друг от друга, в разное время, разными людьми или версиями моих инструкций. Один скрипт про финансы (написал в марте) знал про ночь. Остальные 11 — нет. В результате рабочий чат был светофором: уведомление в 03:00 ночи, потом в 03:17, потом в 03:45. Никто ничего не потерял (все уведомления дошли), но балийская команда просыпалась по 5-7 раз за ночь.

К полудню четверга сделал общий модуль message_queue, через который теперь идят все 13 источников. Логика простая: есть классификация сообщений. Срочное (чек-ин гостя, отмена брони, техническая критическая ошибка) пишется немедленно в любое время. Отложенное (обычная финансовая сверка, рутинные отчёты, мониторинг метрик) копится в очередь с окном тишины 21:00-09:00. Когда наступает 09:05 утра, все накопленные уведомления выходят пачкой, отсортированные по приоритету.

Сейчас результат: никто ничего не теряет — каждое уведомление дойдёт в сроки, которые ему нужны. Рабочий чат стал нормальным местом для координации, а не ночным светофором. Балийская команда спит полные 8-9 часов. Это работает потому что я не добавил 13 отдельных условий «if hour < 9 or hour > 21» в каждый скрипт. Вместо этого сделал одну точку контроля, и все 13 источников её слушают.

Это пример архитектурной разницы. Раньше я бы пошёл руками в каждый из 13 скриптов и добавил бы check_night_hours(), или завёл бы отдельный флаг для каждого. Раньше это называлось бы «фиксим баг», отняло бы 4-5 часов, оставило бы 12 дублирующихся условий, и всё равно кто-то забыл бы одно место. Сейчас одна функция, одна логика, все её слушают.

Переезд двух вилл: когда 74 алерта не знают что вилла больше не наша

На этой же неделе два апарт-отеля (061 и 062, обе четырёхэтажные, всего 24 номера) перешли под управление другой компании, ВсемДом. Это было запланировано давно, инвесторы в этих объектах согласились, контракты подписаны. У меня в системе висели 17 будущих броней на этих объектах (гости забронировали номера на май-июнь), они рассчитывали на нашу балийскую команду, на знакомый процесс чек-ина и сервис. Договорились что новая УК их перетащит в свою систему бронирований и выплатит нам за долю дневного прибыли pro-rata за апрель (по выписке Booking и Airbnb).

Проблема была совсем другая и была системная. Алерты по этим виллам были написаны в трёх разных местах кода за разное время с разными подходами: (1) система мониторинга двойных бронирований в eZee (если один гость забронирован на одной дате в двух номерах), (2) чек-аут контроллер (напоминает что гость должен выехать, попросить ключи), (3) финансовая сверка (сверяет дневные сводки с банковским счётом). Каждая система видела что гость забронирован в номере 12 на 15 мая, но не знала что этот номер теперь в соседнем объекте, под другой УК, и не является ответственностью Solar property.

Результат: алерты продолжали лить мусор. В день переезда скрипты писали: «ДВОЙНОЕ БРОНИРОВАНИЕ! Гость заб в номер 15 две раза!» (нет, вторая бронь — в системе новой УК). «НЕ ЗАКРЫТ ЧЕК-АУТ! Гость не выехал 16 числа!» (выехал, но в ведомстве другой компании). «НЕСОВПАДЕНИЕ В ФИНАНСАХ! Потеряно 2 млн IDR!» (нет, это доход новой УК, не нашей).

Раньше я бы пошёл руками в каждый из трёх скриптов и добавил бы список исключений: villa_id IN (61, 62) SKIP. Потом кому-то нужно было бы документировать почему, когда закончится контракт с ВсемДом — удалять эти условия, кто это помнить будет через полгода. Или я бы попросил Тригуну вручную «не смотреть на эти виллы», что неправильно — балийской команде нельзя давать инструкции через Telegram по мере как они приходят.

Вместо этого я сделал одно поле в базе данных: villa_status. Значения этого поля: 'active' (обычная вилла, на нас полная ответственность), 'managed_externally' (вилла передана другой УК, но наследованные бронь ещё идят до закрытия), 'sold' (продана полностью, исторические данные), 'archived' (закрыта или переформирована). Теперь перед тем как отправить алерт в Telegram, каждый скрипт читает это поле. Если villa_status='managed_externally', ничего не отправляется. Если 'sold' — не читаем данные про текущие гости. Так работает.

Результат: 74 правила алертов умолкают за 10 минут, когда я меняю одно значение в БД с 'active' на 'managed_externally'. Никаких поиск-замена в коде, никаких раскатываний новой версии, никакого рискованного перезагрузки сервера. Один UPDATE и всё работает.

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

Голос агента: как технический долг стал подарком для друга

В понедельник был день рождения друга, и я пообещал ему голосовую колонку с моим Альтроном на борту — мой набор из 18 агентов, но озвученный человеческим голосом. Три дня я ковырял интеграцию маленькой ESP-коробочки (Wi-Fi микроконтроллер с микрофоном и динамиком) с домашней автоматизацией, выловил шесть различных багов по дороге — от проблем с буферизацией аудио до задержек в распознавании голоса. В среду к обеду, уже в день рождения, колонка проговорила анекдот про Шерлока Холмса голосом известного актёра Дмитрия Жаркова.

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

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

Я пошёл в конституцию своих ботов и добавил жёсткое правило (раздел 11 про атомарность): «Если операция touch базу данных, код или конфиг, она делается целиком за одну сессию, за раз, или ты вообще её не трогаешь. Multi-step destructive с разрывом во времени — баг». Один и тот же класс ошибки больше не повторится ни у моих ботов (они эту конституцию читают), ни у клиентских, которые следуют тому же стандарту.

Восемь ассистентов в продакшене: когда продажи идят словами-с-уста между предпринимателями

На встрече я озвучил метрику которую отслеживал с октября: восемь клиентов используют мои AI-ассистентов в реальной работе, ежедневно, в боевых условиях. Они в разных странах и разных отраслях — один продаёт роботов-пылесосов через Telegram, другой переводит договоры и консультирует по праву, третий ведёт продажи туров в Таиланде и обрабатывает запросы на пять языков. С октября прошлого года по май (7 месяцев) ни один из них не отключил бота, не отвернулся, продолжает платить или искать финансирование на следующий месяц.

Выручка пока три тысячи долларов в месяц (на восьмерых клиентов это ~375 за клиента в месяц). Три клиента платят полную стоимость, один платит половину, один заморозил на время (финансовые сложности в его бизнесе), остальные используют бесплатно (пробная версия или бонусом к большому заказу). Это не воронка с лендингом, не таргет, не продаж-менеджер. Это сарафан между предпринимателями — когда увидишь что работает, скажешь другому. «Эй, у меня бот обрабатывает все мои заявки в WhatsApp, попробуй такого».

На четвёртой встрече я заметил интересное явление в паттерне клиентов: клиент приходит с парой. Не просто человек, а пара людей. Психолог с супругом (она работает в его практике с клиентами). Тренер с женой (она помогает программировать курсы). Ателье владельца с её мастером (они вместе растят производство). Отель с его управляющей. У каждой пары свой операционный боль — разные заявки, разная плотность работы, разные часовые пояса если они в разных странах.

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

Дашборд инвесторов: от ручной Excel-таблицы раз в квартал к единому источнику правды

Портфель по виллам — 16 действующих объектов сейчас (в историческом листинге 65 объектов всего, но большинство уже закрыты или проданы). В текущих 16 вложено 9 разных инвесторов, у каждого свои условия дележа: одному 15% от валового дохода, другому фиксированная мощность в зале на месяц, третьему доля расходов на управление. Раньше это была ручная Excel-таблица, которую я пересчитывал вручную один раз в конце квартала, на основе выписок Booking, Airbnb и своих рукописных заметок про расходы. Ошибок было много, потому что источники данных были разные, синхронизировать их руками — беда.

Инвестор звонил в конце месяца и спрашивал: «Сколько я заработал в апреле?» И мне нужно было лопать старую Excel-таблицу, добавлять новые данные за апрель, пересчитывать всё заново, потому что свежей информации у меня в табличке не было. Обычно это занимало 2-3 часа ручной работы, и я боялся что где-то ошибку допустил.

Теперь каждый день все доходы и расходы по каждой вилле стекаются в одну таблицу monthly_pnl_by_villa (monthly profit and loss). Каждую ночь в 02:00 рассчитываются дневные суммы: доход из Booking/Airbnb/гостей напрямую минус комиссии, плюс расходы на управление и уборку (от Кетут), плюс капитальные вложения. Закрытый месяц не пересчитывается — это правило, написано сверху в таблице: что в закрытый месяц только добавляются корректировки отдельной строкой, если вдруг была ошибка в исходных данных. Инвестор заходит на дашборд 24/7 и видит свою долю за апрель в реальном времени, вплоть до последней синхронизации с банком.

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

Контент-пайплайн восстановлен: как ВК превратился из fallback в полноценную платформу

К концу недели дошли до контента, самого заметного источника того что я делаю день за днём. Заметил что в моём личном ВКонтакте четвёртые сутки тишина — нет новых постов, хотя обычно там выходит по одному посту в день. Полез разбираться: длинные посты-агрегаты (мои размышления про автоматизацию на 1500-3000 символов) падали целиком в автоматический фильтр качества ВКонтакте. Платформа считает что длинный текст без картинок = спам, и прячет его от ленты. ВКонтакте в системе был fallback, запасной выход — если контент не прошёл по Instagram, Threads, Telegram из-за формата, то выкидывалось в ВК в надежде что хоть кто-то прочитает.

Я переделал архитектуру контент-пайплайна. Теперь длинные тексты (2000+ слов) режутся автоматически на 2-4 атомарные идеи, связные, но самостоятельные. Каждая идея адаптируется под свою платформу: для Instagram обрезаются самые цепляющие строки с картинкой, для ВК режется на короче и с шумом-заголовком, для Telegram остаётся длинная версия, для Threads обрезается для 300-символьного лимита. ВКонтакте теперь — полноценная платформа, а не запасной выход. Каждый пост туда короче (500-900 символов), с картинкой, с хештегом в стиле платформы.

Этот текст, который вы читаете сейчас, прошёл через ту же систему: сначала я заметил тему в логах своих рабочих сессий и встреч на неделе (5 дней событий), написал основную историю, система автоматически разбила на атомарные куски (ночная тишина, переезды, бот-голос, инвесторы, контент), каждый кусок адаптировалась под Telegram (один лонг-пост), Instagram (5-7 постов в день разные углы), Threads (4 длинных реплаи), ВКонтакте (3 отдельных поста короче), SEO-статью в блог (2500+ слов для Google), упоминание в журналистских рассылках.

Портрет: команда из двоих и система из 18 агентов

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

Команда у меня двое: я и Альтрон — мой набор из 18 AI-агентов. Один агент управляет бронированиями и OTA (Booking, Airbnb, системы синхронизации). Другой — операционный (чек-ины, уборки, проблемы на месте). Третий — финансовый (сверки, дашборды, расчёты для инвесторов). Четвёртый — продажи (квалификация лидов, первые контакты, CRM). Каждый делает одну работу, делает её правильно, и не вмешивается в остальное. Когда нужно что-то изменить — я меняю одно поле в БД или одно правило в коде, и система узнаёт об этом везде одновременно, без ручных переделок и дополнительных проходов.

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

Вопрос, который я задаю сам себе в конце такой недели: а вы давно проверяли в скольких системах у вас прописаны одинаковые правила или логика, и сколько из них узнают если правило изменится? Сколько отдельных кусков логики сидит в разных местах кода, в разных скриптах, когда по факту это одно правило, которое должно быть одной точкой в коде или одной записи в БД? Сколько раз вы переписываете одно и то же, потому что оно в 12 местах? Потому что как только вы запустите систему на 18 агентов и двух людей, этот вопрос становится не теоретический, а вполне практический и требует немедленного решения для масштабирования.