Почему нейросеть для застройщика покупают не так, как офисный чат
У девелопера данные не лежат в одном месте и не принадлежат одному отделу. В отделе продаж — карточки покупателей с персональными данными, суммы сделок и то, на какие деньги идёт покупка: ипотека, рассрочка от застройщика, собственные средства. В ПТО — проектная и рабочая документация, выпущенная не вами, а проектировщиком, сметы и договоры подряда. На площадке — журнал работ, акты скрытых работ и фотографии, снятые с телефона. Это три разных режима доступа, три разных канала связи и три разных срока хранения, а покупают их одним контуром и одной сметой.
Второе отличие — время. Квартиру продают до того, как дом построен: разговор с одним покупателем тянется от брони до передачи ключей, и всё это время переписка копится. Комплект документации по корпусу тоже не приходит разом — он пополняется всю стройку: изменения от проектировщика, предписания надзора, исполнительная документация подрядчиков. Инструмент, который подключают к такому потоку, живёт в компании годами, а не до конца квартала, и это меняет сам разговор с подрядчиком.
Вопрос первый: где встанет контур и что поедет с площадки
Спрашивать надо не «локально или в облаке» — это вы уже решили, — а где физически будет стоять машина и что должно попадать на неё со стройки. Если единственный канал до площадки — мобильный, качество его вам никто не гарантирует: сигнал внутри корпуса зависит от этажа и от того, что встало между телефоном и вышкой. Гонять по такому каналу диалог с моделью — плохая затея.
Ответ «поставим сервер и подключим всех» означает, что про площадку подрядчик не спрашивал. Ответ, с которым можно работать, звучит иначе: контур стоит в офисе, где лежит основной массив; с площадки уходит файл — фотография акта, скан страницы журнала, короткая заметка; а на случай, когда связи нет вовсе, описан порядок — снятое на телефон доходит до контура позже, а не пропадает вместе с сигналом.
Вопрос второй: как разведены продажи и стройка внутри одного поиска
Периметр закрывает внешний мир, но внутри девелоперской компании рядом работают люди, которым положено видеть разное. Общая база на всю компанию выглядит экономно ровно до первого запроса: поиск не знает, что эти папки лежали в разных шкафах не случайно.
Формулировка «доступ настроим ролями» не значит ничего: роли есть в любой системе. Спрашивайте конкретнее — что увидит менеджер отдела продаж, если спросит поиск про себестоимость корпуса. Рабочий ответ не «он про это не спросит», а «его роль ищет по другому индексу, и в ответе он получит отказ с указанием, к кому идти». То же самое в обратную сторону: сметчик не должен доставать из поиска паспортные данные покупателей только потому, что кто-то положил скан в общую папку.
Вопрос третий: откуда контур узнаёт, что лист заменён
Комплект по корпусу переписывают на ходу, и поиск обязан узнавать об этом раньше прораба: не зная о замене, он выдаст отменённый лист с той же уверенностью, что и действующий. Отличить подмену по самому ответу нечем — он выглядит нормально, уходит на площадку и вскрывается уже на приёмке работ.
У застройщика эта беда устроена не так, как у того, кто документацию выпускает. Со стороны выпускающего она разобрана отдельно — локальный AI для проектного института; там событие «выпущено изменение» рождается внутри организации, и её же система выпуска о нём знает. У вас документация входящая, и приходит она от нескольких организаций сразу: письмом, ссылкой на обменник, папкой на диске. Поэтому вопрос звучит буквально так: что в вашей компании считается сигналом замены и как этот сигнал доходит до поиска. И второе — что покажет ответ: шифр листа с датой или пересказ содержания. Пересказ на стройке проверять дороже, чем найти лист руками.
Вопрос четвёртый: что считается спорным обращением и кто принимает решение
Спорное обращение у застройщика — это не бот в форме, а бронь, поданная агентством на покупателя, который до этого звонил вам напрямую. Дальше спорят не о том, бот это или человек, а о том, чьё обращение было первым и кому платить комиссию. Рядом — обращения одного покупателя с разных номеров и заявки, у которых на входе телефона нет вовсе: если из формы пришли только имя и почта, сводить такое обращение с прежним звонком не по чему.
Поэтому ответ «мы отсекаем ботов» — не про вашу задачу. Спрашивайте, на каком признаке обращение отнесено к повторному, виден ли этот признак человеку и кто снимает пометку. Признак этот задаёте вы сами — правилом учёта брони и обращений, а не подрядчик: контур только сводит вместе то, что у вас уже зафиксировано, и показывает, из чего он собрал вывод. Сырьё для сверки — записи разговоров; как устроен их разбор сам по себе, разобрано отдельно: анализ звонков нейросетью — признака принадлежности обращения он не выдаёт, это ваше правило поверх расшифровки. Решение о комиссии остаётся за человеком: модель собирает основание, а не закрывает спор.
Вопрос пятый: где стоит человек, если модель ошиблась в договоре
Договоры у застройщика идут пачками и по шаблонам: договоры с покупателями, подряд, допсоглашения о переносе срока передачи. Цена ошибки здесь не «неудобно» — это претензия и неустойка, а исправлять её приходится не в файле, а в подписанном документе.
Обещание «модель находит все риски» — маркетинг, а не ответ. Спрашивайте противоположное: что модель делать не имеет права — не согласовывать редакцию, не отвечать покупателю без проверки, не менять срок в документе, — и кто поимённо отвечает за проверку. Что в договоре машинная вычитка находит устойчиво, а что пропускает, разобрано отдельно: нейросеть проверяет договор.
Вопрос шестой: как считали нагрузку — по числу людей или по объёму разбора
Ступени конфигураций и то, что тянет каждая, расписаны на странице AI-сервера: разметка там идёт по числу сотрудников, и по ней видно, о каком порядке денег речь. Но у девелопера нагрузку задаёт не списочный состав. Её задаёт разбор комплектов, а он приходит рывками: старт продаж корпуса, сдача этапа, подготовка ответов на замечания, передача ключей.
Отсюда два вопроса. Первый: на какой одновременной нагрузке считали конфигурацию и чем это подтвердят до закупки — замером на пилоте или словами. Второй: что изменится в расходах, когда стартует следующий корпус. Ответ «возьмите с запасом» — это просьба заплатить за простаивающую видеопамять; ответ «посчитаем на пилоте одного отдела» — рабочий.
Шесть вопросов в одной таблице
| Вопрос | Что он на самом деле проверяет | Чем подтверждается ответ |
|---|---|---|
| Где встанет контур и что поедет с площадки | думал ли подрядчик про мобильный канал стройки | описанный порядок на случай, когда связи нет |
| Что увидит продавец, спросив про себестоимость | разграничение внутри компании, а не только периметр | показ на живом запросе, а не слово «роли» |
| Откуда контур узнаёт о замене листа | работу с входящей чужой документацией | названо событие-сигнал и вид ссылки в ответе |
| На каком признаке обращение считается повторным | понимание спора о принадлежности лида | признак виден человеку, и его можно снять |
| Чего модель делать не имеет права | границу ответственности до запуска, а не после | запрет записан в документе и есть имя проверяющего |
| На какой одновременной нагрузке считали | откуда взялась цифра в смете | замер на пилоте одного отдела |
С чего начинают в девелоперской компании
Первый участок выбирают не по важности, а по готовности материала: берут то, что уже лежит текстом и повторяется от дома к дому. Тогда запуск не упирается в чертежи и сканы, а польза становится видна на живой работе — раньше, чем ПТО доберётся до разбора альбомов.
- •Ответы покупателям на однотипные вопросы про этап стройки и порядок расчётов — с человеком на выходе,
- •Разбор входящих писем от проектировщиков и подрядчиков: что пришло, чего не хватает,
- •Сверка комплекта исполнительной документации с тем, что должно быть закрыто по этапу,
- •Поиск по договорам подряда: сроки, штрафы, порядок приёмки — вместо перелистывания папок,
- •Черновики ответов на обращения и претензии по шаблонам вашего юриста.
И заранее назовите, на каком корпусе подводится итог и какой исход вы сочтёте отрицательным. Без этого разговор о продлении уедет с дела на взаимные ожидания, а рассудить их будет нечем.
Подобрать конфигурацию под три ваших участка — продажи, ПТО и площадку — AI-сервер Stitex.
Частые вопросы
Зачем застройщику своя нейросеть, если есть облачный сервис?
Потому что в одном рабочем контуре у девелопера лежат персональные данные покупателей и экономика проекта — себестоимость корпуса, лимит скидки, остатки непроданного. Загрузка такого материала во внешний сервис делает его оператора получателем этих сведений, и настройками приватности это не решается: решает то, где материал обрабатывается. Второе — срок: инструмент нужен на всю стройку и на следующие корпуса, а облачная модель тарифицируется по токенам — чем активнее её нагружают разбором, тем больше счёт, и потолка у него нет.
Можно ли сделать одну общую базу на всю компанию — продажи, ПТО и стройку?
Технически можно, и на бумаге это выглядит экономно. Но тогда менеджер отдела продаж через обычный поиск достаёт себестоимость корпуса, а сметчик — паспортные данные покупателей: поиск не знает, что эти папки лежали в разных шкафах не случайно. Рабочая схема — отдельные индексы и роль, которая определяет, по какому из них идёт запрос. Проверяется это не заверением «доступ настроим ролями», а показом на живом вопросе.
Что делать с документацией, которая приходит от проектировщика и подрядчиков?
Смотреть надо не на объём, а на то, чем у вас фиксируется факт замены листа: письмо, папка на диске, отметка в реестре у ПТО. Именно это событие должно доходить до поиска, иначе он будет уверенно цитировать отменённый лист. И требование к ответу простое: ссылка на шифр листа с датой, а не пересказ содержания — пересказ на стройке проверять дороже, чем найти лист руками.
Как быть с площадкой, где связь только мобильная?
Контур ставят там, где лежит основной массив документации, — в офисе. С площадки уходит файл: фотография акта, скан страницы журнала, короткая заметка прораба, — а не диалог с моделью через мобильный канал. Спрашивать подрядчика надо про то, что происходит при отсутствии связи: снятое на телефон должно дойти до контура позже, а не потеряться вместе с сигналом.
Кто отвечает, если нейросеть ошиблась в ответе покупателю или в проверке договора?
Человек, за которым закреплён участок, — юрист по договорам, руководитель отдела продаж. Модель готовит основание, решение и подпись остаются за сотрудником. Поэтому до запуска пишется не только то, что контур делает, но и то, чего он делать не имеет права: не отвечать покупателю без проверки, не согласовывать редакцию договора, не менять срок в документе.
Стоит ли дообучать модель на своих договорах и переписке с покупателями?
Нет, и дело не в стоимости обучения. У застройщика ценность ответа держится на том, на что он ссылается: пункт действующей редакции договора, шифр листа с датой, входящее письмо с номером. Дообучение переносит в модель манеру формулировок, но не адреса документов, и после первого же допсоглашения такая модель продолжит уверенно пересказывать прежнюю редакцию срока. Поэтому документы держат снаружи модели: поиск идёт по вашим файлам, найденное отдаётся вместе с адресом, а замена договора или листа меняет ответ в тот же день — без переобучения.