CRM под свой бизнес без программиста в штате

Мой бизнес - субаренда коммерческой недвижимости: беру помещение целиком, нарезаю на блоки, сажаю арендаторов. Рутины в этом деле больше, чем кажется со стороны: отсмотреть сотни объявлений, посчитать финмодель по каждому кандидату, начертить нарезку, вести блоки до заселения, выставлять счета. Готовые CRM с этим не помогали, а свой софт всегда означал разработчиков, бюджет и месяцы ожидания. В июле 2026 года я собрал CRM сам, диалогом с ИИ. Первую сборку и доработки я описал в исходном кейсе от 3 сентября; ниже сохраняется эта история.

Результат. Субарист PRO начинался как моя система для субаренды. В первой публикации я описал единый процесс: отбор помещений, расчёт финансовой модели, планировка, воронки объектов и блоков, счета и договоры. Первую версию и дальнейшие доработки я уже описал ниже. Это история собственного инструмента, который стал доступен другим людям.

На 4 октября 2026 года публичный счётчик Субарист PRO показывал 18 активных подписок. Это число подписок с действующим доступом по счётчику системы. По нему нельзя определить число оплат за месяц, активность людей в кабинете или сколько времени CRM им сэкономила. Публичная сводка меняется вместе с состоянием системы; приведённое здесь число относится к дате проверки.

Экран или график из исходной публикации от 3 сентября 2026 года.

Почему готовые CRM не подошли

Универсальные CRM устроены вокруг звонков и сделок: лид пришёл, менеджер позвонил, сделка закрылась. Субаренда живёт иначе. Сначала объект проходит отбор по данным: трафик, ставки соседей, маржа. Потом финмодель, договор с собственником, нарезка помещения на блоки. Потом у каждого блока своя судьба: объявление, показы, задаток, заселение, счета. Это две воронки, чертёж и бухгалтерия, связанные в один процесс.

Натягивать такой процесс на чужую схему - значит вести половину дела в таблицах рядом с CRM. Ровно так рутина и растёт быстрее выручки: системы не разговаривают друг с другом, а стыки между ними закрывает человек. Свой софт связывает эти этапы в одном процессе; раньше для его разработки требовались разработчики и бюджет.

Что было описано в первой публикации о CRM

В первой публикации от 3 сентября я описал такой состав системы. Это история её первой версии; свежая проверка каждого действия здесь не заявлена:

• Лента помещений. Объявления с Авито проходят чистку от шлака, каждое получает балл чистоты, оценку трафика, расчёт ставки субаренды вокруг и маржи. История появления и исчезновения объявлений помогает вернуться к объекту и проверить его состояние. Исчезновение объявления не доказывает, что помещение сдано.
• Карточка объекта. Ответ на вопрос «на трафике ли помещение» с причинами, сравнение цены с соседями, заведения в трёхстах метрах по открытым картам, аналоги и подходящие сети.
• Финмодель. Нарезка на один, два или три блока, налоги по УСН или патенту, помесячный поток на три года, окупаемость. Выгрузка в Excel помогает отдельно проверить исходные значения и результат расчёта.
• Деление помещения. Редактор планировки: подложка из фото или скана, контур, резка, стены, входы и витрины, чистовик в стиле БТИ с экспортом картинки - готовая схема для объявления.
• Заселение блоков. Своя воронка после подписи: блок идёт от «свободен» до «заселён», схема помещения раскрашивается цветом стадий, у каждого блока файлы и объявление.
• Счета, акты, договоры. Светофор статусов, «выставить всем» одной кнопкой, отправка почтой, реестр договоров со сроками и шаблоны для скачивания.
• Чек-листы и напоминания. Мои же плейбуки отбора и переговоров, переведённые в галочки с гейтами, и напоминания по московскому времени.

Каждый пункт когда-то был ручной работой в таблицах, мессенджерах и на бумаге.

Лента помогает собрать исходные сведения для отбора помещения. Дальше человек проверяет конкретный объект, условия договора и исходные данные расчёта. Объявление из внешнего источника может исчезнуть или попасть в неполную выдачу. Поэтому исчезновение строки из ленты само по себе не доказывает, что помещение сдано, а рассчитанная маржа ещё не означает, что сделка состоится.

У такого инструмента есть две отдельные проверки. Первая - правильно ли система рассчитала результат из полученных данных. Вторая - полны ли сами данные и относятся ли они к нужному объекту и периоду. Число объявлений и частота обновления не заменяют этих проверок. Без свежего согласованного снимка источника я не обновляю в этом кейсе прежние числа по ленте и не обещаю её полноту.

Как это строилось: ночь на костяк, два месяца на правду

Первая версия появилась в ночь на второе июля: лента, карточки, финмодель, лендинг. Дальше график коммитов честно показывает, как живёт такой проект.

Экран или график из исходной публикации от 3 сентября 2026 года.

Пик первой недели - 86 коммитов: система обрастала разделами быстрее, чем я успевал их пробовать. Потом волны пошли на спад, и их характер поменялся. Правки перестали быть «добавить раздел». Они стали «починить то, обо что споткнулся в реальной работе»: кривые сканы планировок, просрочка счетов по московскому времени, права доступа к личной базе контактов. В середине июля багов накопилось столько, что я остановил новые функции и потратил несколько дней на разбор системы от А до Я - лечили причины, не симптомы. Так история доработок выглядела на дату первой публикации. Число коммитов показывает работу над кодом; оно не подтверждает надёжность процесса или экономию времени.

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

Границы автоматизации

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

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

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

Когда свой софт того стоит

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

Затем можно посчитать ручную работу вокруг таблиц: кто переносит сведения, сколько времени занимает перенос, где появляются ошибки. Для этого нужна одна и та же задача до и после изменения. Порядок такого разбора есть в карте утечек. Число функций в CRM не заменяет замер.

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

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

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

Обновление 4 октября 2026 года

В публичной сводке проверены 18 активных подписок. Подключение платёжного провайдера уже отражено в прежнем обновлении; противоречащий ему абзац о демонстрационной оплате заменён. История первой сборки остаётся историей на дату исходной публикации. Новые экраны, показатели использования и результат автоматических напоминаний здесь не заявлены.

Кейс остаётся примером моей собственной системы. Чтобы перенести похожий подход в другой бизнес, сначала нужно описать его процесс: какие сведения поступают, что система рассчитывает, какое действие готовит и где требуется решение человека. Порядок такой работы описан на странице CRM под ваш бизнес; выбрать первую задачу помогает разбор бизнеса.

Источники обновления

• Исходный публичный кейс. История и показатели первой версии; прочитан 4 и 5 октября 2026 года.
• Публичное число активных подписок Субарист PRO. Снимок от 4 октября: 18; это действующий доступ, не число подтверждённых оплат.