Сайт и AI-агент для продажи одного дома: семь версий, четыре разбора и честные итоги

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

Живой сайт: dubldom2026.ru · Бот: @barhatdom_bot · Архив версий и разборов: dubldom2026.dev.uspeshnyy.ru

Аудио-обзор кейса

Разговорный подкаст по материалам проекта, 5 минут — если удобнее слушать, чем читать.

Клиент и задача

Мини-посёлок «Бархат» внутри большого КП «Бархатово Лес», 65 км от МКАД по Киевскому шоссе. Четыре барнхауса ДубльДом на общем тупике: три построены и заселены, в продаже четвёртый. У него 91 м² вместе с террасой, 7 соток, цена 12 900 000 ₽. Дом в производстве, сборка идёт в этом году.

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

Задача формулировалась в четыре пункта:

1. Сделать сайт, который продаёт через ежемесячный платёж, а не через пугающую цену.
2. Сделать агента, который ведёт разговор за собственника: отвечает, считает, записывает на показ.
3. Искать покупателей там, где они сами спрашивают совета, — в тематических чатах, без спама.
4. Всё, что требует человека, передавать собственнику в понятном виде.

Семь версий сайта и четыре разбора между ними

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

Шаг	Что произошло
v1	«Дом в берёзах»: цена «или платёж, как аренда», калькулятор, галерея
v2	три правки первой дизайн-критики: ленивая загрузка фото, промежуточная кнопка, расчёт уходит в Telegram
Разбор №1	четыре прохода: дизайн-критика, эвристики Нильсена, доступность по WCAG 2.1, взгляд четырёх разных покупателей
v3	частые вопросы, калькулятор с переключателями, подписями для скринридера и сбросом
Know-how	объяснение для клиента, почему лендинг сработает, и первое предложение Telegram-агента
v4 и v5	новое позиционирование «мини-посёлок из четырёх домов» — и та же история в порядке, удобном для заявки
Разбор №2	v4 против v5: доверие или конверсия
Чек-лист фактов	все цифры с сайта — собственнику на подтверждение
v6	3D-план, настоящее аэрофото, SEO-база
Разбор №3	восемь проходов по секциям, 55 находок
Против шаблонов	финальный проход против типового почерка AI-дизайна
v7	всё вместе — версия, которая стала живым сайтом

flowchart LR
    A["Версия сайта"] --> B["Разбор:<br/>несколько проходов<br/>с разных позиций"]
    B --> C["Находки<br/>сгруппированы<br/>по пересечениям"]
    C --> D["Следующая версия<br/>закрывает группы,<br/>а не пункты списка"]
    D --> A
    C --> E["Спорные решения<br/>объяснены письменно"]

Приоритет по пересечениям. Четыре прохода первого разбора дали десятки находок. Чинить по списку не стали: находки сгруппировали по тому, где они пересекаются. Один переделанный калькулятор закрыл девять находок сразу. До этого он был непригоден для скринридера, обновлялся без подсветки и молча обрезал ввод — 50 млн превращались в 8,89.

Новое позиционирование сломало путь к заявке. Когда сайт переписали на «мини-посёлок из четырёх домов», второй разбор нашёл, что у двух моделей домов нет кнопки заказа, калькулятор считает только готовый дом, а «Готов: 1» из четырёх читается как недострой. Позиционирование оставили, порядок блоков и кнопки поправили.

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

Против почерка AI. Финальный проход искал признаки типового AI-дизайна: восемь ячеек одного веса, цветную полосу слева у карточки, прыгающие цифры. Средняя оценка секций выросла с 3,75 до 4,92 из 5. Шрифт, который стоит в «чёрном списке» этих правил, оставили осознанно — в разборе объяснено почему.

Что делает сайт

Первый экран начинается не с цены, а с платежа: «~70 000 ₽/мес — как съём двушки в Москве». Цена стоит второй строкой, спокойным шрифтом.

Калькулятор считает три программы: семейную под 6%, IT под 8% и базовую под 15%. Учитывает материнский капитал и показывает, сколько льготные программы экономят на переплате против базовой ставки. Минимальный взнос, границы слайдера и платёж на первом экране зависят от цены и пересчитываются вместе с ней — это пригодилось, когда в продаже сменился дом.

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

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

Как это выглядит в работе

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

Разговор в Telegram

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

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

flowchart TD
    A["Кнопка на сайте<br/>с меткой места"] --> B["Первое сообщение<br/>под эту метку"]
    B --> C["Свободный разговор:<br/>цель, бюджет, сроки"]
    C --> D["Расчёт платежа<br/>калькулятором, не моделью"]
    D --> E{"Готов смотреть?"}
    E -->|"да"| F["Свободные часы<br/>из календаря собственника"]
    F --> G["Событие с напоминаниями<br/>за сутки и за два часа"]
    E -->|"молчит"| H["Напоминания<br/>на 1, 3, 7 и 14-й день"]
    E -->|"торг, сложный вопрос"| I["Тема «Нужен Иван»<br/>в рабочей группе"]

Запись на показ настоящая. Бот запрашивает занятость календаря на неделю вперёд и предлагает только свободные часы с 10 до 19. Нажатие создаёт событие с напоминаниями за сутки и за два часа. Выбрал человек другое время — запись переносится, а не дублируется. Если календарь недоступен, бот не пишет «записал», а передаёт заявку собственнику.

Напоминания замолчавшим. Если человек пропал, бот напомнит о себе на 1, 3, 7 и 14-й день: новый факт о посёлке, фото участка, приглашение на показ, разговор об условиях. Текст каждого касания переписывается под историю конкретного человека. Пишет только с 9:00 до 22:00 и не чаще раза в сутки. Пока человек отвечает, напоминаний нет; просьба больше не писать или запись на показ останавливают цепочку совсем.

Рабочая группа вместо админки

Лиды приходят не в личные сообщения собственника, а в группу с темами:

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

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

Отдельной админки нет — её роль играет сам бот. У покупателя пять команд, у администратора восемь: сводка по лидам, ссылки с метками для рекламы, список чатов парсера, управление администраторами и группами.

Поиск покупателей в чатах

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

Чаты выбирались не по числу подписчиков, а по живости обсуждений: покупатели пишут в комментариях, а не в самом канале. Из 13 кандидатов 8 оказались мёртвыми, с нулём сообщений в сутки.

Порог выбран на данных. Сначала он стоял на 0,40, чтобы ловить ранний интерес. За первые трое суток классификатор оценил 51 сообщение и прислал две карточки — обе оказались шумом: тёплый гараж «когда-нибудь» и морозильник для дома, который человек уже строит. Порог подняли до 0,55. Слабые сигналы по-прежнему сохраняются в базе, но собственнику больше не приходят.

Инженерные решения

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

Время показа знают только кнопки. Кнопки со свободными часами прикрепляются к самому ответу бота, а не приходят отдельным сообщением. Если модель всё же предложила время сама, её ответ заменяется нейтральным: иначе текст спорит с календарём.

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

flowchart LR
    A["Запрос к модели"] --> B{"Основная<br/>ответила?"}
    B -->|"да"| C["Ответ покупателю"]
    B -->|"нет"| D["Резерв № 1"]
    D -->|"нет"| E["Резерв № 2"]
    D -->|"да"| C
    E -->|"да"| C
    E -->|"нет"| F["Заявка собственнику<br/>без выдумки"]
    D --> G["Алерт администраторам:<br/>невосстановимые сразу,<br/>временные — пачкой"]
    E --> G

Резерв для модели. Если основная модель не отвечает, запрос уходит ко второй, затем к третьей; калькулятор работает и на резерве. Невосстановимые ошибки сообщаются сразу, временные — когда накопятся, не чаще раза в шесть часов на тип сбоя, со счётчиком, общим для всех процессов. Ошибки ключа и баланса больше не повторяются по три раза — раньше это стоило 14 секунд задержки на каждое сообщение.

Трекер визитов без сырых IP. Сайт отправляет визиты в собственный обработчик, IP хранится только как хеш с дневной солью.

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

Всё в одном Docker Compose. Бот, парсер, планировщик, веб-часть, миграции, PostgreSQL и Redis — семь сервисов на одном сервере за nginx. Если воркеру не хватает токена или сессии, он не падает в цикл перезапусков, а ждёт.

Что проверила эксплуатация

Это самая полезная часть кейса. Всё ниже случилось на самом деле.

Сервер умер вместе с бэкапами. Сервер перестал отвечать и восстановлению не подлежал. За вечер сайт и бот переехали на новый: DNS, сертификаты и весь стек поднялись без правок кода. А база лидов пропала. Ночная выгрузка в облако молча не работала как минимум несколько недель, и отметка об ошибке лежала в логе на том же умершем сервере. Когда выгрузку возвращали, выяснилось, что прежнее место для копий было в хранилище с публичным доступом. Теперь дампы уходят в закрытое хранилище, аккаунт сервера не может их удалить, каждая копия сверяется по размеру, а восстановление отрепетировано на временной базе.

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

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

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

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

Документ для клиента обещал то, чего код не делал. При сборке базы знаний о проекте каждое утверждение сверили с кодом. Напоминания в документе шли «на 1, 3, 7 и 14-й день, только днём», а в коде само напоминание сдвигало отсчёт — выходило 1, 4, 11 и 25-й день и в любое время суток. Хуже того, если бот передавал разговор человеку, новые сообщения покупателя до нажатия «Взять диалог» никуда не попадали. В тот же день код привели к обещанию, а документ — к коду.

Вывод: описание поведения системы проверяется в коде так же, как цифры калькулятора. Иначе документ становится красивым описанием того, чего нет.

Перед рекламой — исследование, а не креативы

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

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

Что это дало до первого потраченного рубля:

• Сравнение глазами покупателя. Выдача по посёлку показала, с какими домами и ценами будут сравнивать наш, — значит, объявление должно с первой строки объяснять разницу.
• Сверка обещаний. Между объявлением на площадке и сайтом нашлись расхождения, а формулировки про ипотеку потребовали сверки с правилами программ и банком. Реклама на неподтверждённом обещании приводит людей к отказу — худший первый контакт из возможных.
• Слова покупателей. Страхи каркасного дома, счета за электричество без газа, ипотека на строящийся дом — дословными цитатами. Это готовые возражения для текстов и вопросов.
• Минус-слова до создания кампании. Рядом с «барнхаусом в Подмосковье» живёт огромный арендный спрос — «снять посуточно», — а «дом от собственника» почти всегда идёт в паре с «недорого». Для дома за 12,9 млн это список исключений ещё до запуска.

Что получил собственник

Сайт и агента, которые работают круглосуточно без его участия, пока не понадобится именно он.

Рабочую группу, где лиды разложены по темам, а любой разговор можно забрать себе одной кнопкой.

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

Стратегию продаж отдельной страницей: воронка, бюджет, сравнение с продажей через агентство.

Разборы каждой версии и чек-лист фактов — чтобы видеть, почему сайт устроен именно так.

Исследование перед запуском рекламы: 203 находки о конкурентах, покупателях и спросе, план запуска и вопросы, которые нужно закрыть до первого объявления.

Честно о результатах

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

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

Главный вывод для любого подобного проекта: AI-агент усиливает поток покупателей, но не создаёт его. Бюджет на рекламу нужен в любом случае — агент делает так, чтобы каждый оплаченный клик не пропал зря.

Презентация проекта

Цифры

Показатель	Значение
Версий сайта до живой	7
Разборов между версиями / проходов в них	4 / 14
Находок в третьем разборе, все закрыты	55
Средняя оценка секций до и после финального прохода	3,75 → 4,92
Кнопок записи на сайте, каждая со своей меткой	7
Ипотечных программ в калькуляторе	3
Тем в рабочей группе собственника	5
Напоминаний замолчавшему покупателю	4
Команд бота: покупатель + администратор	5 + 8
Провайдеров моделей в цепочке резерва	3
Сервисов в Docker Compose	7
Чатов проверено / отброшено как мёртвые	13 / 8
Купленных Telegram-аккаунтов, оказавшихся мёртвыми	5 из 5
Порог уверенности для лида из чата	0,55
Находок в исследовании перед рекламой	203

Стек. Python 3.12, aiogram 3, Telethon, APScheduler, FastAPI. Модели: Claude Sonnet с вызовом инструментов, резерв — OpenAI и Gemini. Данные: PostgreSQL 16, SQLAlchemy 2, Alembic, Redis 7. Интеграции: Google Calendar API, Telegram Bot API. Сайт: одна страница на HTML, CSS и JavaScript без фреймворков, медиа в облачном хранилище. Инфраструктура: Docker Compose на VDS, nginx, Let's Encrypt.

Что стоит забрать себе

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

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

Тихий отказ опаснее падения. Упавший сервис виден сразу. Модель, которая молча возвращает «не лид», выглядит как спокойный день без заявок. Поэтому резервная цепочка, алерты и «снова отвечает» после восстановления — не украшение, а часть системы.

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

Документ для клиента — тоже код. Сверяйте обещания с реализацией: расхождение на четыре дня в расписании напоминаний обнаружилось только при построчной сверке.

Хотите увидеть, где ваша воронка теряет заявки между сайтом и ответом менеджеру, — бот разберёт путь по пунктам и покажет дыры.

🔎 Найти, где утекают заявкиБесплатно, в Telegram-боте @uspeshnyybot

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

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