Покупатель подписал договор. Теперь ему нужно найти документы по своей квартире и выбрать время приёмки. При ручной записи сотрудник сверяет договор, ищет файл и согласует время в переписке. Эти действия отнимают время у клиентского сервиса и создают риск потерять договорённость. Первая версия кабинета должна провести человека по этому пути до понятного результата.
Мы предлагаем оценивать такой MVP, то есть первую рабочую версию, по действиям клиента и сотрудников. В смету войдут связь человека с договором, доступ к файлам, подтверждение записи, перенос и передача замечания в работу. Ниже разберём границы каждого блока и дадим матрицу, с которой можно запросить сопоставимые предложения. Для запроса оценки можно сразу взять матрицу блоков и чек-лист пилота.
Что именно считать в стоимости MVP
Для оценки кабинета дольщика сначала нужно согласовать роли, источник каждого вида данных и результат каждого действия. Цена получится из подготовки процесса, интерфейсов клиента и сотрудников, серверных правил, интеграций, проверки и запуска. Число экранов помогает оценить дизайн, но не показывает объём работы с правами и обменом данными.
Например, строка «документы» может означать общий список памяток по корпусу или персональные файлы по договору с обновлением из CRM. Строка «приёмка» может включать только выбор времени либо ещё ручную запись сотрудником, перенос, отмену и повтор после сбоя. Для сравнения смет эти различия нужно раскрыть до итоговой суммы.
Мы предложим пилот одного корпуса: клиент входит, видит свою квартиру и доступные документы, записывается на приёмку, получает подтверждение и отправляет замечание. Если гарантийные обращения обрабатывает другая команда в другой системе, оценим их отдельным блоком. Поиск покупателя и продажи агентства, а также обращения жителей в управляющую компанию имеют свои процессы и ответственных.
Веб-кабинет с удобной версией для телефона подходит для проверки этого пути. Отдельное мобильное приложение добавит работу по платформам, публикации и сопровождению. Его стоит включать в оценку, когда понятны регулярные сценарии после передачи квартиры. Общий принцип оценки ролей и модулей мы разбираем в статье о стоимости личного кабинета.
Иллюстрация сценария
От корпуса к конкретной квартире
Документы, запись и обращение должны быть связаны с квартирой, к которой у человека есть доступ.
Как клиент возвращается к своему обращению
В CentreVisa мы собрали заявки, статусы и общение с консультантом в одном мобильном сервисе. Клиент открывает «Мои заявки», видит обращения в работе и завершённые, продолжает переписку и прикладывает файл. Такой личный сценарий помогает удержать документы и обсуждение рядом с конкретным обращением.
Реальный проект 13FOX
CentreVisa: заявка, статус и файл
Клиент возвращается к обращению и видит контекст предыдущего разговора.
В кабинете дольщика мы предложим похожую связь обращения с личным контекстом, затем добавим договор, квартиру, расписание и ответственных за передачу. Процесс проверим с клиентским сервисом девелопера: сотрудник должен понимать, где взять данные и как завершить действие, которое начал покупатель.
Кто вправе видеть квартиру и документы
Доступ начинается со связи участник → договор → квартира. Вход по коду подтверждает доступ к телефону. Чтобы открыть сведения по квартире, система должна ещё проверить, на каком основании человек связан с договором и какие действия ему разрешены.
Допустим, в договоре два участника. Оба могут читать документы, а запись на приёмку по согласованному правилу меняет только один. Представитель получает отдельные полномочия на нужные действия и срок. Эти правила нужно утвердить вместе с клиентским сервисом и юристом; простой список телефонов их не описывает.
Мы составим матрицу разрешений: просмотр квартиры, скачивание документа, запись, перенос, отправка замечания. Сотруднику сервиса дадим доступ к его зоне работы, а изменение полномочий и исправление связи с договором вынесем в отдельные действия. В истории сохраним, кто и когда их выполнил.
Проверка для сметы: клиент открывает ссылку на документ другой квартиры. Сервер должен отказать в доступе, даже если адрес файла известен. OWASP рекомендует проверять право на конкретный объект при каждом запросе. Такое правило понадобится и для записи, и для замечания.
При смене участника или окончании полномочий обновляется доступ к связанным объектам. Поэтому стабильный внутренний идентификатор человека, договора и квартиры полезнее номера телефона как единственной связи: контакт может измениться, а история должна остаться у правильного договора.
Откуда приходят документы и статус
До разработки мы разберём, где сотрудники сейчас ведут договор, сведения о квартире и файлы. CRM хранит работу с клиентами; договорные документы могут лежать в другой системе. Кабинету нужен согласованный источник каждого вида данных и понятный признак их актуальности.
| Данные | Источник в примере | Что согласовать |
|---|---|---|
| Участник, договор, квартира | CRM застройщика | ID, связь объектов, изменение участников и прав |
| Персональные документы | Система договорных документов | Версия файла, разрешённые получатели и обновление |
| Расписание и запись | Сервис записи на приёмку | Ресурсы команды, место сохранения брони, перенос |
| Замечание и результат работы | Сервисная система девелопера | Ответственный, статусы, фото, история и закрытие |
Это пример распределения данных. В вашем проекте несколько строк могут вести в одну систему. Мы проверим доступные методы API, то есть способы чтения и изменения данных, права технической учётной записи, ограничения и условия конкретного аккаунта. Например, REST-доступ Битрикс24 ограничен правами пользователя и разрешениями приложения. По одному названию CRM состав обмена не определить.
Направления обмена запишем явно: договор и квартира приходят в кабинет; подтверждённая запись и замечание уходят в систему сотрудников; статус обработки возвращается клиенту. Если источник недоступен, кабинет показывает время последнего обновления и понятное состояние операции, а сотрудник видит ошибку и способ её повторить.
Общая памятка по приёмке и персональный документ требуют разных правил публикации. Для каждого файла согласуем категорию, получателя, версию и допустимые действия. Скачивание PDF и электронное подписание потребуют разного состава работ. Способ подписи, статус документа и юридически значимые уведомления отдельно сверим с договором и действующими правилами.
Календарь должен завершаться подтверждённой записью
Свободное время в календаре становится записью после проверки и сохранения в системе, которая управляет расписанием. Интервал записи, или слот, занимает часть расписания команды. Мы уточним, сколько команд принимает квартиры, сколько встреч может идти одновременно, какие нужны промежутки между ними и кто открывает запись на корпус.
Представьте, что два покупателя выбирают последнее свободное время. В месте сохранения записи система повторно проверяет доступность и принимает только допустимое число броней. Второму клиенту покажем, что время уже занято, и предложим доступные варианты. Если их нет, дадим возможность обратиться в клиентский сервис. Эта проверка должна работать и для записи сотрудником вручную.
Перенос тоже требует правил. Мы предложим сохранить прежнюю запись, пока новая не подтверждена. Если новый слот уже заняли, клиент остаётся со старым временем. Сотрудник видит историю, а сообщения о переносе отправляются после успешного изменения.
Ещё один сценарий: запись сохранена, но ответ не дошёл до телефона. Повторный запрос должен распознать прежнюю операцию и вернуть её результат по согласованным правилам. Такой подход описан в Amazon Builders’ Library о безопасных повторах API. Период распознавания повтора и поведение при новом выборе нужно определить в проекте.
SMS, письмо или уведомление в приложении сообщают о результате. Подтверждённая дата остаётся видна в кабинете, даже если сообщение не доставлено. Канал, провайдер, стоимость отправки и обработка ошибок доставки войдут в отдельную строку оценки.
Замечание и гарантийное обращение: два маршрута работы
Для замечания при передаче мы предложим короткую форму: помещение, элемент, описание и фото. Обращение связывается с квартирой, получает номер и попадает ответственному. Клиент видит статус и следующее действие; сотрудник сохраняет результат работы в той же истории.
Статус «работа завершена» показывает действие исполнителя. Закрытие обращения зависит от согласованной проверки: кто подтверждает результат, как прикладывает доказательство и когда можно открыть вопрос повторно. Мы заложим эти переходы в процесс и проверим их на пилоте.
После передачи квартиры у гарантийного обращения могут быть другие основания, ответственные и сроки. Поэтому в смете отдельно укажем его маршрут, передачу в сервисную систему и правила ответа. Приложение будет показывать решение уполномоченного сотрудника. Правовую оценку, сроки и гарантийные условия согласуем с юристом по актуальным правилам и договору.
Матрица для сравнения предложений подрядчиков
Отправьте каждому исполнителю один и тот же состав. Попросите вернуть для каждой строки трудозатраты или фиксированную цену, допущения, зависимости и критерий готовности. Тогда будет видно, сколько стоит работа и какие условия могут изменить оценку.
| Блок сметы | Что включить в MVP | Как принять работу |
|---|---|---|
| Подготовка и прототип | Путь одного корпуса, роли, источники и исключения | Сотрудник клиентского сервиса проходит путь клиента и подтверждает правила |
| Вход и доступ | Связь участника с договором и квартирой, снятие прав | Свои данные доступны; чужие объекты и файлы закрыты |
| Документы | Разрешённые файлы, версия, актуальность и источник | Обновление видно; старая версия обработана по правилам |
| Приёмка | Запись, перенос, отмена, ручная запись и уведомление | Ёмкость не превышена; повтор возвращает прежнюю запись |
| Замечания | Фото, ответственный, статусы, история и проверка | Обращение проходит весь согласованный маршрут |
| Обмен и запуск | CRM, сервисная система, журнал ошибок, сверка, пилот | После сбоя данные сверены; сотрудник может продолжить работу |
К этой матрице добавьте отдельные строки гарантии, электронной подписи, мобильного приложения и переноса старых данных, если они нужны. Попросите назвать доработки на стороне CRM и доступность специалистов, которые их выполнят. Так зависимость от другой команды попадёт в оценку заранее.
Бюджет запуска складывается из согласованных работ и обязательных разовых расходов. Если исполнитель считает в часах, он указывает трудозатраты и ставку по блокам. Регулярные платежи учитываются отдельно: размещение, хранение файлов, сообщения, лицензии и поддержка. Уточните, какие платежи уже входят в сопровождение, чтобы не посчитать их дважды.
Для обсуждения резерва полезнее назвать конкретную неизвестность: качество связей договора и квартиры, доступность API или правила гарантийной команды. После проверки этой неизвестности оценку можно уточнить. Универсальная стартовая сумма не подскажет, включены ли именно ваши условия.
Как ограничить пилот и проверить его готовность
Мы предложим запустить один корпус с известными договорами и утверждённым расписанием. Для начала можно выбрать один канал уведомлений и оставить сложные изменения полномочий сотруднику. При этом сохранятся серверные проверки доступа, история операций и восстановление обмена: они нужны уже для первого реального пользователя.
До запуска вместе с сервисом согласуем ожидаемый результат каждого сценария. Этот список можно приложить к заданию подрядчику:
После пилота смотрим, где клиент всё ещё обращается к менеджеру, какие операции сотрудник переносит вручную и какие ошибки требуют вмешательства. Эти наблюдения дадут основание для следующей версии: расширения на другие корпуса, гарантии или отдельного приложения.
Что уточнить до запроса оценки
Можно ли добавить кабинет к действующему сайту?
Да, если можно связать учётные записи, безопасно выдавать документы и подключить нужные системы. Мы проверим существующую серверную часть. Иногда кабинет удобно выделить в отдельный сервис, сохранив переход с сайта застройщика.
Можно ли начать без полной CRM-интеграции?
Для ограниченного пилота можно согласовать импорт и действия сотрудника. В оценке нужно назвать, какие данные обновляются вручную, кто отвечает за их актуальность и сколько операций остаётся в таком режиме. Запись всё равно требует одного места сохранения и общих правил ёмкости.
Что сильнее всего меняет стоимость?
Разные права участников, качество связей договоров и квартир, обмен с несколькими системами, исключения записи и отдельный маршрут гарантии. Для каждого блока нужна граница первой версии и критерий проверки.
Нужно ли включать электронную подпись сразу?
Если без неё выбранный процесс не завершится, она входит в состав первой версии. Тогда отдельно проверяем вид подписи, участников, документы, провайдера и правовые условия. Для доступа к информационным файлам состав может быть проще.
Разберём путь от договора до передачи квартиры
Пришлите обезличенный пример этого пути, роли участников, перечень документов и названия CRM и сервисной системы. Мы разберём состав MVP, направления обмена и условия предварительной оценки. Начать можно с описания процесса обычными словами.
Как мы предлагаем организовать разработку, описано на странице кабинета дольщика. Нажмите кнопку, чтобы открыть форму для связи. Результат разбора — перечень функций первой версии, карта обмена и основания расчёта сметы.