Инвесторский дашборд для 16 вилл: как за один день открыть инвесторам доступ к реальным цифрам и заменить финансиста с Excel

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

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

Как было до: один финансист, один Excel, один PDF в месяц

До сегодняшнего дня у нас был Паша — финансист, который вёл учёт всего в Google Sheets. Очень хорошо вёл: аккуратно, с формулами, с разбивкой по виллам. Раз в месяц он делал отчёт, превращал его в PDF и отправлял каждому инвестору в WhatsApp. Инвестор получал табличку и верил на слово, что там правильные цифры.

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

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

Утро: синхронизация с Пашиной таблицей и первые баги

Начал утром с попытки синхронизировать нашу базу данных с Пашиной таблицей. Логика была такая: его Google Sheets — источник правды, нужно перенести данные оттуда в систему, которая будет их показывать инвесторам.

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

Потом нашёл баг, который мог дорого обойтись. Отель Casa Solar с 6 номерами показывал нулевую выручку. Система не понимала, что "060#dx" и "060#std" — это номера одного отеля с идентификатором 060. Два разных кода, две разные записи в базе, никакой связи между ними. Бронирования в базе есть, деньги есть — а выручка в отчёте ноль, потому что код не матчится.

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

День: был тёмный экран с нулями — стал личный кабинет

У нас уже был инвесторский раздел на сайте. Теоретически. На практике: тёмный экран, четыре вкладки, половина показывала нули. Никто не пользовался, потому что пользоваться было нечем.

За день я переделал его полностью. Вот что стало доступно после логина каждому инвестору — только по его объектам, ничего чужого:

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

Второй раздел — графики. Динамика выручки по месяцам, сравнение с предыдущим годом, загрузка объекта в процентах. Не потому что графики красиво выглядят — а потому что тренды видны сразу, без ручного анализа таблиц.

Третий раздел — рейтинги гостей. Оценки с Airbnb и Booking, динамика. Это важно: низкий рейтинг влияет на заполняемость и, значит, на прибыль инвестора. Теперь это видно сразу.

Четвёртый раздел — текущие бронирования. Кто, когда, на сколько ночей, какой платформой воспользовался. Не для управления — для понимания загрузки в реальном времени.

Данные приходят из двух источников: eZee PMS (система управления бронированиями) и Telegram-бот расходов, куда вся команда фотографирует чеки. Оба источника уже были подключены к нашей базе данных — дашборд просто читает из неё. Никакого ручного ввода.

Как я нашёл три критических бага сразу после раздачи доступов

Когда я раздал доступы 9 инвесторам, первые фидбеки пришли быстро. И они обнаружили проблемы, которые я не поймал при тестировании.

Баг первый: заглушка вместо страницы. Один инвестор написал "не заходит". Начал разбираться — оказалось, система отдавала укороченный HTML без основного контента при определённых параметрах запроса. Браузерная заглушка вместо полноценной страницы. Починил за 20 минут, но пока не починил — человек видел пустой экран и думал, что система не работает.

Баг второй: неполный учёт расходов. Второй инвестор спросил: "Почему расходы такие маленькие?" Правильный вопрос. Я показывал в разделе расходов только коммунальные платежи и обслуживание. Комиссии (40% от выручки) шли отдельной строкой в финансовой сводке, но инвестор их не заметил. Мог увидеть "выручка 120 миллионов рупий" и прийти за деньгами, а реально после всех комиссий там 50. Переработал отображение так, чтобы все вычеты были в одном месте, последовательно, с итоговой чистой прибылью в конце.

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

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

Почему каждый инвестор видит только свои объекты

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

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

Разграничение реализовано на уровне базы данных: у каждого объекта есть владелец, у каждого пользователя — список его объектов. Запрос всегда фильтруется по этому списку. Никаких дыр, где один инвестор мог бы увидеть данные другого.

Главный инсайт: прозрачность для инвесторов — один день работы

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

Бронирования падают в базу из eZee автоматически. Расходы заносятся через Telegram-бота, который распознаёт чеки. Курс валют подтягивается из API. Всё, что мне нужно было сделать — построить интерфейс, который читает эти данные и показывает их в понятном виде конкретному человеку.

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

Что потеряли, когда пришлось откатываться — и что это значит

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

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

Второй откат: похожая ситуация, другой участок данных. Снова откатил, снова разобрался с маппингом, снова запустил правильно.

Принцип здесь такой: в работе с финансовыми данными важнее сделать правильно, чем сделать быстро. Два отката — это не провал. Это нормальная цена за уверенность в том, что числа правильные. Альтернатива — показать неправильные цифры инвесторам — стоила бы значительно дороже.

Сколько экономит одна автоматизация

Раньше цикл отчётности выглядел так: Паша собирает данные из eZee вручную, вносит в Google Sheets, считает по каждой вилле отдельно, делает разбивку по инвесторам, генерирует PDF, отправляет 9 людям в WhatsApp. Это неделя работы в месяц при том, что всё шло без ошибок. Плюс зарплата финансиста.

Теперь: данные в базе обновляются автоматически из eZee и Telegram-бота. Дашборд читает их в реальном времени. Инвестор заходит сам, видит актуальные цифры. Никаких PDF, никаких ручных расчётов, никакой задержки.

Ноль дополнительных сотрудников. Один день настройки. 16 вилл под контролем в реальном времени.

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

Что будет дальше: что ещё нужно докрутить

Дашборд работает. Инвесторы видят цифры. Но это версия 1.0, и я честно понимаю, что в ней есть неполноты.

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

Второе — сравнение с прогнозом. Сейчас инвестор видит факт. Было бы хорошо показывать, как факт соотносится с планом, который был в момент покупки объекта. Это требует отдельной работы с данными прогнозов, но это важно для долгосрочного доверия.

Третье — мобильная версия. Большинство инвесторов проверяют всё с телефона. Сейчас дашборд технически открывается на мобильном, но не оптимизирован. Это ближайшая задача.

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

Вывод: прозрачность для инвесторов можно автоматизировать за один день — если данные уже в базе

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

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

Паша уходит. Система остаётся. И работает лучше, чем PDF раз в месяц.

Вопрос к тем, кто управляет недвижимостью или бизнесом с инвесторами: ваши партнёры видят цифры в реальном времени или ждут отчёт? Что им мешает видеть больше?

  • Один день — 9 инвесторов и 16 вилл с доступом к реальным данным в реальном времени
  • Два отката синхронизации — правильный маппинг важнее скорости
  • Баг Casa Solar: нулевая выручка из-за несовпадения кодов объекта
  • Три бага нашлись сразу после раздачи доступов — живое тестирование лучше любого QA
  • Ноль новых сотрудников, ноль PDF, данные обновляются из eZee и Telegram-бота расходов
  • Каждый инвестор видит только свои объекты — разграничение на уровне БД
  • Ключевое условие: данные должны уже быть в базе до того, как строишь дашборд

Читайте также

Подписаться на блог в Telegram

Читайте свежие кейсы об AI-автоматизации, системной архитектуре и масштабировании бизнеса.

Подписаться