Клиент открывает переписку, чтобы найти последние фото. Менеджер уточняет, какую смету ему отправили, а прораб ждёт решения по дополнительной работе. Если вы узнаёте свой процесс, первую версию кабинета удобно начать с одного объекта. Мы предлагаем связать в нём этапы, фотоотчёты и изменения сметы, чтобы клиент понимал ход ремонта и видел, что именно ему предлагают согласовать.
Ниже разберём состав MVP, то есть первой рабочей версии, на условном примере работ по полу. Покажем две версии сметы и дадим сценарии, по которым можно принять разработку: от доступа к своему объекту до повторного нажатия кнопки при пропавшем ответе. Отдельно определим, где заканчивается запись решения в интерфейсе и начинается договорное оформление. Такой разбор помогает согласовать объём разработки и сравнить предложения подрядчиков.
Состав MVP · Пример допработы · Проверки приёмки
Что включить в первую версию на одном объекте
Для пилота мы предлагаем один законченный путь: клиент входит, открывает свой объект, смотрит этап и фото, изучает изменение и принимает решение. Менеджер публикует информацию и видит ответ. Прораб готовит отчёт и описание работ. Эту цепочку можно проверить до подключения всех объектов компании.
В состав MVP войдут: вход и доступ к объекту, план этапов, фотоотчёт с датой и пояснением, текущая смета с историей версий, предложение допработы и решение клиента. Уведомление вернёт клиента к новому предложению. Документы и обращение по объекту добавим в пилот, если они нужны для этой цепочки. Платежи выделим в отдельный модуль: на старте это может быть реестр счетов и подтверждённых поступлений, если онлайн-оплата не требуется.
Каждый этап должен отвечать на простые вопросы: что запланировано, что сейчас происходит, кто отвечает и какого действия ждут от клиента. Мы предлагаем хранить плановые и фактические даты отдельно. Если срок меняется, клиент увидит причину и обновлённый план; завершённый этап сохранит историю.
Табели бригады, закупки, склад, себестоимость и распределение исполнителей относятся к внутреннему учёту. Мы включим их в отдельный объём, если они нужны компании. Для клиентского пилота важнее определить, кто готовит данные и кто разрешает их публикацию. Например, прораб загружает фото, менеджер проверяет подпись и публикует отчёт. Клиент получает готовую информацию по своему объекту.
Как мы связывали статус и общение в CentreVisa
В CentreVisa мы собрали обращения в одной системе, выделили визовый сценарий и каталог других услуг. После отправки анкеты клиент возвращается к своим заявкам: видит обращения в работе и завершённые, задаёт вопрос консультанту и обсуждает документы в чате заявки.
Реальный проект 13FOX
Статус рядом с вопросом клиента
В CentreVisa обращение сохраняет контекст, когда клиент возвращается в приложение.
В кабинете ремонта сообщение «пришлите фото» стоит связать с этапом и ответственным. Обращение получит статусы «принято», «в работе», «ответ отправлен» и дату последнего ответа. Точные названия мы согласуем с вашей командой, чтобы клиент и менеджер одинаково понимали состояние вопроса.
Что клиент должен понять из фотоотчёта
Допустим, на объекте идёт подготовка пола. В отчёте мы предлагаем показать дату съёмки, помещение или зону, выполненную работу и комментарий к следующему шагу. Дата загрузки хранится отдельно: вчерашнее фото, отправленное сегодня, не должно выглядеть сегодняшним состоянием ремонта.
Иллюстрация сценария
Материалы и план одного объекта
Один снимок общей комнаты и подробный кадр проблемного участка могут объяснять разные вещи. Подпись свяжет фото с работой: «основание подготовлено», «обнаружено отклонение», «требуется решение по изменению». Правила съёмки и публикации задаёт подрядчик; кабинет поможет сохранять порядок отчётов.
До запуска мы предложим проверить отчёт на телефоне клиента и на устройстве прораба: загрузку нескольких фото, неудачную отправку, поворот изображения, увеличение детали и исправление подписи. Если на объекте слабая связь, важно заранее решить, достаточно ли повторной загрузки или нужен отдельный режим работы без сети. Второй вариант изменит состав разработки.
Как показать допработу и две версии сметы
Продолжим условный пример. К исходным работам по полу добавляется выравнивание основания. Для демонстрации примем объём 12 м² и цену 1 500 ₽ за м², включая работу и материалы. Добавка составит 18 000 ₽: смета версии 3 на 480 000 ₽ превратится в предложение версии 4 на 498 000 ₽. Это условные данные, на которых удобно проверить интерфейс и расчёт.
В предложении мы покажем причину, состав работ, объём, единицу измерения, цену и разницу с текущей версией. Если изменение сдвигает план, рядом появятся затронутый этап и перенос срока. В нашем примере это два рабочих дня; в проекте причину и длительность задаёт подрядчик. Клиент должен увидеть оба последствия до решения.
Версия 4 сначала будет предложением. Клиент сможет согласовать её, отклонить с причиной или задать вопрос. Если менеджер исправит объём после отправки, появится новая версия для нового решения. Старую запись согласия мы сохраним вместе с тем содержанием, которое человек видел.
У решения будут номер предложения, версия, объект, учётная запись согласующего и время записи на сервере. На стороне сервера мы проверим право согласующего и актуальность предложения при сохранении решения, в той же операции. Неактуальную версию сервер не примет. Например, открытая вчера ссылка на версию 4 после появления версии 5 должна показать, что предложение изменилось, и предложить прочитать новые условия.
Приёмка согласования: откройте предложение на двух устройствах. На первом измените его от имени менеджера, на втором попробуйте согласовать старую страницу от имени клиента. Новая версия должна потребовать отдельного решения, а журнал должен сохранить историю.
Как связать решение в кабинете с договором
Запись в интерфейсе фиксирует действие пользователя. Чтобы придать ей предусмотренный договором юридический эффект, нужно определить полномочия согласующего, способ его идентификации, точное содержание предложения и порядок оформления изменения. Клиент, собственник квартиры и плательщик могут быть разными людьми; доступ к фото ещё не даёт права менять стоимость работ.
Электронная форма сделки зависит от воспроизводимости неизменного содержания и достоверного определения лица, выразившего волю: это следует из статьи 160 ГК РФ. Для признания документов с простой или неквалифицированной электронной подписью равнозначными бумажным действуют условия закона или соглашения сторон; правила простой подписи раскрыты в статьях 6 и 9 закона № 63-ФЗ.
Для ремонта, который физлицо заказывает для личных нужд, отдельно проверим письменное согласие на платные допработы. С 1 сентября 2025 года пункт 3.1 статьи 16 закона о защите прав потребителей требует письменного согласия, если закон не предусматривает иное; заранее выбранные отметки согласия запрещены. Условия разъясняет Роспотребнадзор. Мы заложим отдельное действие клиента и сохранение того предложения, которое он подтвердил.
Поэтому мы заранее разберём с вашим юристом и ответственным за договоры, какие действия допускаются в кабинете и когда нужно дополнительное соглашение, электронная подпись или обмен документами. Для бытового и строительного подряда могут действовать разные условия. Экран согласования получит формулировку, которая соответствует выбранному порядку, а пакет решения сохранит версию сметы и приложенные файлы.
Согласование допработ, приёмка выполненного этапа и подтверждение оплаты будут отдельными событиями. Клиент может согласиться с новой стоимостью, но ещё не принять результат и не оплатить счёт. На экране мы покажем эти состояния раздельно, чтобы команда не начинала следующий шаг по неверному признаку.
Где хранить данные и что делать при сбое CRM
Перед интеграцией мы составим карту данных: кто создаёт объект, кто публикует этап, где хранится смета и какая система подтверждает оплату. Если CRM уже ведёт клиентов и договоры, кабинет получит привязку к их записям. Для версий сметы и решений нужно выбрать одну основную систему, иначе менеджер и клиент могут увидеть разные условия.
Сервер проверит доступ к каждому объекту, документу и фото. Скрытая кнопка на экране не защищает файл от чужой ссылки. Мы заложим проверку владельца и роли при каждом запросе, в том числе для скачивания документов. Такой подход соответствует рекомендациям OWASP по контролю доступа.
Если кабинет хранит решения, он сможет записать согласие в своей базе и отдельно показать «передача в CRM ожидается». Если главным местом записи выбрана CRM, при её недоступности клиент увидит, что подтверждение ещё не получено. Этот выбор мы закрепим в задании. Уведомление менеджеру отправится после сохранения решения; неудачная доставка уведомления не отменит само решение.
Для повторной отправки понадобится идентификатор операции: он поможет серверу распознать уже сохранённое согласие, если ответ пропал в сети. В предусмотренном сценарии повторный клик вернёт результат той же операции. Журнал ошибок и ручная сверка дадут менеджеру возможность разобраться, когда обмен не завершился.
Реестр платежей тоже должен показывать источник и актуальность. Загруженная клиентом квитанция может иметь статус «на проверке»; статус «оплачено» появится после подтверждения из выбранного источника. Подключение эквайринга, чеков и возвратов мы оценим отдельно, если они войдут в первую версию.
Из каких работ складывается стоимость кабинета
Для оценки мы возьмём описанную цепочку на одном объекте и разложим её на работы. Так в предложении станет видно, что входит в цену: экран сметы, хранение версий, права согласующего и обработка повторной отправки. Общие факторы бюджета подробнее разобраны в статье о стоимости разработки личного кабинета.
- Процесс и прототип: роли, состояния этапа, состав предложения и сценарий решения клиента.
- Клиентская и служебная части: просмотр объекта, публикация отчёта, документы и управление предложениями.
- Данные и доступ: вход, привязка клиента к объекту, версии и журнал событий.
- Обмен: поля CRM, направление передачи, повторы и сверка; выбранный источник платежей.
- Приёмка и запуск: проверка на ролях клиента, менеджера и прораба, перенос пилотных данных, резервное копирование и восстановление, обучение ответственного.
Сильнее всего состав меняют готовность CRM и исходных данных, режим без сети, способ подписи, онлайн-оплата и отдельные приложения для iOS и Android. Для пилота можно начать с веб-кабинета, который открывается по ссылке с телефона, если этого достаточно для выбранного пути. Потребность в приложениях мы проверим по работе с камерой, уведомлениям и связи на объекте.
Попросите подрядчика указать включённые сценарии, исключения, расходы после запуска и порядок оценки новых функций. Стоимость поддержки будет зависеть от размещения, хранения фото, уведомлений и интеграций. Когда две команды оценят одну цепочку и одни ошибки, их предложения можно будет сравнить по существу.
Сценарии, по которым можно принять разработку
Мы предлагаем пройти пилот как клиент, менеджер и прораб. Возьмите тестовый объект, фотоотчёт, две версии сметы и ещё один объект для проверки чужого доступа. Данные должны быть обезличены. В таблице ниже зафиксирован ожидаемый результат, который можно включить в задание.
| Проверка | Действие | Ожидаемый результат |
|---|---|---|
| Доступ | Клиент открывает ссылку на фото другого объекта | Сервер отказывает; фото и данные чужого объекта не выдаются |
| Фотоотчёт | Прораб загружает вчерашние фото сегодня; менеджер публикует | Виден этап, дата съёмки и подпись; дата загрузки сохранена отдельно |
| Версия сметы | Менеджер меняет объём после отправки предложения | Создана новая версия; старое согласие не перенесено на неё |
| Полномочия | Пользователь с правом просмотра пытается согласовать | Сервер отклоняет действие; уполномоченный клиент может принять решение |
| Повтор | Ответ пропадает после сохранения; клиент нажимает снова | По тому же идентификатору возвращается сохранённый результат; второй записи решения нет |
| Сбой обмена | CRM недоступна при согласовании | Статус соответствует выбранному месту записи; менеджер видит ошибку и может сверить результат |
| Документ | После решения клиента менеджер открывает пакет согласования | Найдены версия, состав, сумма, изменение срока, согласующий и время; оформление соответствует договору |
| Платёж | Клиент добавляет квитанцию к счёту | Статус «на проверке» сохраняется до подтверждения выбранным источником оплаты |
После этих проверок полезно дать клиенту пройти обычный путь без подсказок: найти свежий отчёт и понять, чего ждут от него по допработе. Если он не различает текущую смету и предложение, доработать нужно сам экран. Затем мы предложим проверить второй объект и смену менеджера, чтобы пилот можно было расширять.
Что подготовить для первого кабинета
Пришлите список этапов одного ремонта, пример фотоотчёта, две обезличенные версии сметы и одну допработу с решением клиента. Добавьте роли сотрудников, название CRM и правило, кто имеет право менять стоимость. По этим данным мы предложим состав первой версии и проверки для приёмки.
Если вы уже готовы обсуждать реализацию, переходите к разработке кабинета заказчика ремонта. Для сравнения более широкого состава подойдёт решение с личным кабинетом. Начать разговор можно через форму ниже: укажите контакт, а примеры передайте после связи с командой.
Разберём один объект и одну допработу
Пришлите этапы ремонта и пример изменения сметы. Мы разложим путь клиента на экраны, роли и обмен данными, предложим состав первой версии и критерии готовности.