Гарантийный контур застройщика: единый реестр дефектов от приёмки до закрытия гарантии

Отрасль и клиент

Контекст отрасли

Как возникает задача

После завершения строительства работа девелопера с качеством объекта не заканчивается.

Перед получением ключей покупатель осматривает квартиру. Для долгосрочного найма комнаты фиксация передачи устроена иначе — это цифровое досье передачи комнаты, а не гарантийный контур после сдачи новостройки. Во время осмотра могут обнаруживаться:

• царапины и повреждения окон;
• сколы плитки;
• дефекты отделки;
• повреждения дверей;
• проблемы с сантехникой;
• неровности стен и пола;
• неисправность розеток;
• проблемы вентиляции;
• повреждения общих зон.

Часть дефектов устраняется до подписания документов. Часть фиксируется как замечания к приемке.

Однако после передачи квартиры начинается другой процесс — гарантийная эксплуатация объекта.

Через несколько недель или месяцев собственник может обнаружить:

• промерзание оконного узла;
• протечку;
• неисправность инженерного оборудования;
• трещины;
• проблемы с дверями;
• дефекты отделки;
• недостатки фасада;
• дефекты благоустройства;
• недостатки общедомового имущества.

По действующей редакции статьи 7 Федерального закона №214-ФЗ минимальный гарантийный срок для объекта долевого строительства составляет три года, для технологического и инженерного оборудования — также не менее трех лет, а для отделочных работ и элементов отделки — не менее одного года. Требование должно быть связано с дефектом, обнаруженным в соответствующий гарантийный период.

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

Кто участвует в процессе

Обычно это несколько подразделений:

• Отдел заселения — проводит передачу квартир и фиксирует первичные замечания.
• Служба качества — разбирает техническую природу дефекта.
• Гарантийный отдел — принимает обращения собственников и контролирует их выполнение.
• Подрядчики — устраняют дефекты по своим видам работ.
• Управляющая организация — может выявлять проблемы общего имущества (см. кейс управления МКД для эксплуатационного учёта дефектов дома).
• Юридический отдел — подключается при претензиях и спорных случаях.
• Покупатель — сообщает о проблеме, предоставляет доступ в квартиру и подтверждает либо оспаривает результат устранения.

Что уже цифровизируется на российском рынке

Рынок нельзя считать пустым.

Например, «Контур.Недвижимость» предлагает отдельные сценарии внутренней и клиентской приемки: фиксацию замечаний со смартфона, передачу дефектов подрядчикам, формирование документов, уведомление дольщиков и контроль устранения замечаний. На публичной странице сервиса указана стоимость 250 ₽ за объект для внутренней приемки и 500 ₽ за объект для клиентской.

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

PlanRadar позволяет фиксировать дефекты непосредственно на объекте, прикреплять фото, назначать ответственного подрядчика и формировать отчеты. В опубликованном самой компанией кейсе «Сибпромстроя» решение использовалось именно для приемки отделочных работ и дефект-менеджмента.

Planado предлагает чек-листы приемки, фотофиксацию, акты и мобильную работу. На момент исследования публичные тарифы составляли от 935 до 1 776 ₽ в месяц за пользователя при годовой оплате в зависимости от набора функций.

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

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

Она возникает в другом сегменте:

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

Клиент

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

Масштаб

Компания:

Команда, связанная с приемкой и гарантией

• руководитель службы качества — 1;
• координаторы гарантийного отдела — 5;
• инженеры/мастера — 6;
• сотрудники офиса заселения — 7;
• юрист, периодически работающий с претензиями — 1;
• сотрудники подрядчиков — около 60 пользователей потенциального внешнего контура.

Средний поток

В обычный месяц:

В периоды массовой передачи дома нагрузка может вырастать в два-три раза.

Инструменты до внедрения

• CRM девелопера — покупатели и сделки;
• 1С — договорная и финансовая информация;
• Excel — гарантийный реестр;
• Telegram — взаимодействие с подрядчиками;
• электронная почта — официальные письма;
• телефония — обращения собственников;
• фотографии в смартфонах сотрудников;
• сетевые папки — акты и дефектные ведомости.

Уровень цифровизации нельзя назвать низким.

Проблема в другом: каждый инструмент автоматизирует свой фрагмент процесса, но ни один объект данных не проходит через весь гарантийный цикл.

Как было

Как бизнес работал до продукта

Типичный процесс выглядит следующим образом.

1. Шаг 1. Покупатель сообщает о проблеме
   • по телефону, email, форме на сайте, через УК или знакомому сотруднику;
   • координатор определяет ЖК, дом, квартиру, собственника, характер проблемы, дату передачи.
2. Шаг 2. Информация переносится в Excel
   • строка: ЖК → дом → квартира → ФИО → телефон → дефект → дата → статус;
   • фотографии остаются в почте или мессенджере — данные уже разделяются.
3. Шаг 3. Назначается осмотр
   • инженер получает сообщение, телефон и краткое описание;
   • связывается с покупателем и договаривается о времени.
4. Шаг 4. Инженер осматривает дефект
   • фотографирует, делает заметки, определяет тип и ответственного подрядчика;
   • информация снова передаётся координатору.
5. Шаг 5. Формируется задача подрядчику
   • координатор пишет в чат: квартира, описание, фото;
   • при нескольких подрядчиках — параллельные переписки.
6. Шаг 6. Подрядчик сообщает об устранении
   • отправляет фото, но без ответа: кто проверил, когда выполнено, подтвердил ли собственник, повторялся ли дефект.
7. Шаг 7. Excel обновляется вручную
   • координатор меняет статус; при забывчивости отчётность расходится с реальностью.
8. Шаг 8. Руководитель запрашивает отчёт
   • просроченные дефекты, статистика подрядчиков, открытые обращения — часть данных сверяется вручную.
9. Шаг 9. Возникает повторное обращение
   • поиск старой строки Excel, переписки, фото, акта, исполнителя — одна из самых дорогих точек процесса.

Основные проблемы

Операционные

Финансовые и управленческие

Пользовательские

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

Матрица проблем

Основной продуктовый инсайт

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

Чек-лист решает только первые десять минут жизни дефекта. Та же проблема — единый идентификатор и непрерывная история — разбирается на примере управления инцидентами на парковочных объектах.

После него начинаются:

• назначение;
• диагностика;
• переписка;
• ремонт;
• перенос срока;
• повторный осмотр;
• спор;
• закрытие;
• иногда повторное открытие через несколько месяцев.

Поэтому главным объектом системы должна быть не приемка и не заявка.

объект → покупатель → дефект → диагностика → подрядчик → устранение → проверка → закрытие → история.

Главный объект — дефект

Он должен отвечать минимум на восемь вопросов:

1. Где обнаружен?
2. Кто сообщил?
3. Когда обнаружен?
4. Относится ли он к гарантии?
5. Кто отвечает за устранение?
6. Какой срок установлен?
7. Какие действия уже выполнялись?
8. Кто подтвердил результат?

Если эта структура существует, приемка квартиры становится одним из источников появления дефекта.

Гарантийное обращение покупателя — вторым.

Осмотр общего имущества — третьим.

Почему существующие инструменты не полностью закрывают сценарий

Концепция продукта

Суть продукта

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

Что система объединяет

В одном месте находятся:

Основные роли пользователей

User Flow

Сценарий №1. Дефект обнаружен при передаче квартиры

Инициатор: инженер приемки

Ключевой объект: дефект

1. Инженер открывает квартиру.
2. Покупатель и чек-лист.
3. Помещение.
4. Фото.
5. Категория.
6. Подрядчик по справочнику.
7. Срок.
8. Реестр.
9. Покупатель видит замечание.

Сценарий №2. Покупатель сообщает о гарантийном дефекте

Инициатор: покупатель

1. Вход по телефону.
2. Квартира.
3. «Сообщить о проблеме».
4. Описание и фото.
5. Координатор видит гарантийный период.
6. Задача проверки (гарантийность решает сотрудник).

Сценарий №3. Подрядчик устраняет дефект

Ключевой объект: статус «Ожидает проверки»

1. Уведомление.
2. Карточка.
3. Принятие.
4. Работа.
5. Фото после.
6. «Работа выполнена».
7. Проверка инженером или покупателем.
8. «Закрыт».

Сценарий №4. Повторный дефект

1. «Проблема повторилась» в закрытом дефекте.
2. Новые фото.
3. Повторное открытие в той же истории.
4. Счётчик повторных устранений.

Сценарий №5. Дефект придомовой территории

Ключевой объект: зона объекта (без покупателя)

1. ЖК.
2. Двор.
3. Площадка.
4. Фото.
5. Подрядчик по благоустройству.

Функциональная архитектура

MVP и MoSCoW

MVP

Приоритизация MoSCoW

UX, стек и план

UX/UI-концепция

Главный рабочий экран: очередь дефектов

Координатор не должен начинать день с абстрактного dashboard.

Ему нужна очередь.

Верхние быстрые фильтры:

Ниже таблица:

Главное действие:

обработать следующий проблемный дефект.

Ниже — короткая демонстрация рабочего экрана координатора гарантийного отдела.

Карточка дефекта

Верхняя часть:

Дефект №D-02648

ЖК → дом → квартира → помещение.

Далее:

• статус;
• срок;
• покупатель;
• подрядчик;
• описание.

Центральная область — фотографии.

Ниже — хронология.

Справа на desktop:

• изменить статус;
• назначить;
• перенести срок;
• сформировать отчет.

Мобильный экран инженера

Главный сценарий:

«Мои осмотры сегодня»

Карточка:

11:30 ЖК «Северный квартал» квартира 184 проблема: продувание окна покупатель: ожидает

Кнопки:

Открыть осмотр

Позвонить

Клиентский экран

Покупателю не нужна внутренняя терминология.

Вместо:

Статус: ContractorExecution

он видит:

Подрядчик устраняет дефект

и пояснение:

Следующее обновление ожидается до 14 сентября.

Аналитический экран

Нужны конкретные управленческие вопросы:

Какие подрядчики системно просрочивают?

Какие дефекты повторяются?

В каких домах растет количество гарантийных обращений?

Техническая архитектура

Для рассматриваемого масштаба микросервисы не нужны.

Frontend

Vue 3 + TypeScript

Один frontend-код может обслуживать:

• desktop;
• tablet;
• мобильный браузер;
• PWA.

Дополнительно:

• Pinia;
• Vue Router;
• IndexedDB для локальных черновиков;
• Service Worker.

Backend

Laravel 12

Модульный монолит.

Основные доменные модули:

• Objects;
• Units;
• Customers;
• Inspections;
• Defects;
• Contractors;
• Communications;
• Documents;
• Notifications;
• Audit.

Laravel подходит небольшому проекту благодаря:

• готовой авторизации;
• очередям;
• валидации;
• ORM;
• файловым абстракциям;
• удобной генерации PDF/API;
• относительно быстрому CRUD-развитию.

Database

PostgreSQL

Основные таблицы:

projects

buildings

units

customers

unit_customers

inspections

defects

defect_status_history

defect_media

contractors

contractor_work_types

messages

documents

users

roles

Storage

Фотографии нельзя хранить как blobs в PostgreSQL.

Используется S3-совместимое хранилище.

Файл получает:

• UUID;
• связь с дефектом;
• автора;
• дату;
• MIME;
• checksum;
• размер;
• тип: before / after / attachment.

Auth

Сотрудники

email + пароль + 2FA для администраторов.

Покупатели

телефон + одноразовый код.

Подрядчики

email или телефон + приглашение.

Integrations

Для MVP:

• SMS;
• email;
• импорт квартир и покупателей через CSV.

После пилота:

• API CRM;
• webhooks;
• 1С при реальной необходимости.

Infrastructure

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

В действующей редакции 152-ФЗ при сборе персональных данных граждан РФ запись, систематизация, накопление, хранение, изменение и извлечение с использованием баз за пределами РФ по общему правилу не допускаются.

В архитектуре:

• приложение размещается в российском дата-центре;
• PostgreSQL — в РФ;
• объектное хранилище — в РФ;
• резервные копии — в отдельной российской зоне/ЦОД.

Monitoring

Минимальный набор:

• централизованные application logs;
• Sentry-совместимый error tracking;
• CPU/RAM/disk monitoring;
• очередь задач;
• статус cron;
• алерт ошибок резервного копирования.

Backup

PostgreSQL:

• ежедневный full backup;
• WAL/PITR при необходимости production-ready версии;
• хранение нескольких поколений копий.

Файлы:

• versioning;
• lifecycle backup.

Обязательно периодически выполнять тестовое восстановление.

Использование AI в разработке

AI способен заметно сократить рутинную часть разработки, но не отменяет технический контроль.

Анализ требований

AI полезен для:

• декомпозиции интервью;
• составления user stories;
• поиска противоречий;
• формирования acceptance criteria.

Разработчик или product manager обязан проверить бизнес-логику.

Проектирование таблиц

AI может предложить:

• ER-структуру;
• миграции;
• индексы;
• связи.

Но особенно внимательно проверяются:

• ownership;
• история статусов;
• soft delete;
• уникальные ограничения;
• правила удаления покупателей.

CRUD и API

Здесь эффект высокий.

AI способен быстро создать:

• Laravel controllers;
• resources;
• form requests;
• policies;
• endpoints;
• OpenAPI-документацию.

SQL

Полезно для:

• аналитических запросов;
• тестовых выборок;
• поиска дублей.

Сложные запросы нужно проверять через EXPLAIN ANALYZE.

Тесты

Хороший сценарий применения:

• feature tests;
• permission tests;
• status-transition tests;
• API tests;
• edge cases.

AI часто хорошо увеличивает покрытие уже понятной логики.

UI

Можно ускорить:

• формы;
• таблицы;
• фильтры;
• модальные окна;
• загрузку файлов.

Но AI хуже принимает решения о том, какие элементы вообще должны присутствовать на рабочем экране.

Debugging

Полезны:

• анализ stack trace;
• поиск причины SQL-ошибки;
• race conditions;
• ошибки очередей;
• логические гипотезы.

Где выигрыш небольшой

AI не сильно помогает в:

• интервью с гарантийным отделом;
• наблюдении за реальной приемкой квартиры;
• понимании внутренних полномочий;
• согласовании процесса с подрядчиками;
• обучении сотрудников.

Что нельзя бездумно делегировать AI

Особенно:

• модель прав доступа;
• обработку персональных данных;
• архитектуру;
• production deployment;
• миграции данных;
• backup;
• правила гарантийных сроков;
• юридическую квалификацию дефекта;
• безопасность загрузки файлов.

Сложные технические задачи

План разработки

Реалистичная оценка сроков

Один разработчик без AI

Один разработчик с AI-инструментами

AI особенно помогает на CRUD, тестах и документации.

Он значительно меньше ускоряет:

• discovery;
• пилот;
• права доступа;
• интеграцию с процессом заказчика.

Команда 2–3 человека

Почему MVP не стоит обещать за 3–4 недели

За это время можно сделать прототип.

Но не надежный продукт с:

• загрузкой фотографий;
• ролями;
• покупателями;
• подрядчиками;
• аудитом;
• PDF;
• мобильной адаптацией;
• резервным копированием;
• тестами.

Оценка бюджета разработки

MVP небольшой командой

Если один сильный разработчик выполняет большую часть функций, денежный бюджет может быть ниже, но календарный срок увеличится.

Инфраструктура

Для начального масштаба:

20–50 тыс. ₽ в месяц, включая:

• серверы;
• БД;
• storage;
• backup;
• мониторинг.

SMS оплачиваются отдельно по фактическому объему.

Поддержка

120–250 тыс. ₽ в месяц

в зависимости от SLA и объема развития.

Метрики и ROI

Метрики «до / после»

Наиболее надежный эффект здесь — не сокращение самого ремонта, а сокращение административного времени вокруг ремонта.

Как рассчитывается эффект

ROI для клиента

Риски и выводы

Рынок и масштабирование

Насколько продукт специализирован

Высоко.

Он не пытается заменить:

• CRM;
• ERP;
• приложение жителя;
• строительный контроль;
• 1С.

Он автоматизирует узкий участок:

передача → дефект → гарантия → подрядчик → подтверждение.

Целевая компания

Наиболее подходящий сегмент:

• 500–3 000 передаваемых квартир в год;
• несколько параллельных ЖК;
• собственная гарантийная служба;
• десятки подрядчиков;
• уже существует CRM.

Для компании, сдающей 100 квартир в год, Excel может оставаться экономически рациональным.

Кто принимает решение

Чаще всего:

• директор по качеству;
• директор по эксплуатации;
• операционный директор;
• IT-директор.

На решение влияют:

• гарантийная служба;
• отдел заселения;
• юридический отдел;
• служба информационной безопасности.

Цикл продажи

Для регионального девелопера реалистична модель:

1–4 месяца.

Если потребуется:

• интеграция с CRM;
• проверка безопасности;
• сложный договор;
• импорт старой гарантии,

цикл увеличится.

Основные барьеры

1. «У нас уже есть Excel».
2. «У нас есть CRM».
3. «Подрядчики не будут регистрироваться».
4. «Покупатели продолжат звонить».
5. Нужно импортировать старые объекты.
6. Конкурирующие платформы уже предлагают приемку и гарантийные сценарии.

Россия → Казахстан

Архитектура может масштабироваться, но нельзя просто скопировать:

• юридические правила;
• документы;
• уведомления;
• справочники.

Ядро дефект-менеджмента переносимо.

Другие сегменты

Логично расширять продукт только на близкие процессы:

• апартаменты;
• коммерческие помещения в жилых комплексах;
• машиноместа;
• кладовые.

Уходить в универсальное управление строительством не требуется.

Риски

Roadmap

MVP

Цель — доказать, что единая карточка дефекта сокращает административные потери.

Функции:

• объекты;
• квартиры;
• покупатели;
• дефекты;
• фото;
• подрядчики;
• статусы;
• сроки;
• история;
• клиентский доступ;
• PDF;
• простой отчет.

V1

После пилота:

• полноценный offline;
• CRM API;
• уведомления;
• 2D-планы квартир;
• шаблоны приемки;
• календарь осмотров;
• статистика подрядчиков;
• массовые операции.

V2

Когда накопится достаточно данных:

• поиск повторяющихся дефектов;
• группировка массовых проблем;
• автоматическое назначение по видам работ;
• расширенная аналитика домов;
• контроль гарантийных периодов по типам элементов.

Later

Только если рынок подтвердит спрос:

• электронное подписание;
• интеграции с другими системами девелопера;
• AI-функции;
• расширенный API;
• white-label клиентский интерфейс.

AI-функции продукта

AI не является ключевой частью продукта на текущем этапе.

Основная ценность достигается обычной автоматизацией.

После накопления данных можно рассматривать следующие функции.

1. Классификация обращения

Вход

«Когда ветер, из окна в детской сильно дует».

AI предлагает:

Помещение: детская

Категория: окна

Тип: продувание.

Польза

Ускорение обработки.

MVP

Нет.

2. Предложение подрядчика

AI использует:

• категорию;
• историю;
• объект;
• справочник договоров.

Результат:

вероятный исполнитель — подрядчик оконных конструкций.

Решение подтверждает координатор.

3. Поиск повторяющихся проблем

Если за месяц появляется:

• 24 обращения;
• один дом;
• одна серия окон;
• одинаковое продувание,

система предлагает создать потенциальный массовый инцидент.

Это потенциально одна из наиболее ценных AI-функций.

4. Резюме длинной истории

Для юриста:

Дефект зарегистрирован 4 сентября. Осмотр проведен 5 сентября. Подрядчик выполнил ремонт 12 сентября. Покупатель сообщил о повторном дефекте 2 октября.

Резюме обязательно строится только по фактам системы.

5. Проверка качества фотографии

AI может предупредить:

изображение слишком темное;

или:

дефект невозможно различить.

Полезно, но вторично.

Что AI не должен делать

AI не должен самостоятельно:

• признавать случай гарантийным;
• отклонять претензию;
• определять юридическую ответственность;
• закрывать обращение;
• менять гарантийный срок.

Что получилось в результате

Пример рабочего отчета

Руководитель выбирает:

ЖК «Северный квартал» → Дом 2 → сентябрь 2026

и получает:

• открыто — 142;
• закрыто — 106;
• просрочено — 17;
• ожидает подтверждения — 19;
• повторно открыто — 8.

Ниже:

Здесь уже появляется управленческая информация.

Шесть повторных дефектов окон — основание анализировать не отдельные квартиры, а подрядчика, монтажный узел или конкретную партию.

Ключевые выводы

1. Главная сущность — не заявка покупателя, а дефект

Один физический недостаток может:

• обнаружиться на приемке;
• ремонтироваться;
• закрыться;
• повториться через месяц.

Если каждое событие создавать отдельной несвязанной заявкой, компания снова теряет историю.

2. Покупатель должен быть частью модели данных

Недостаточно хранить ФИО в текстовом поле.

Нужна связь:

покупатель → квартира → приемка → дефекты → гарантийные обращения.

Это позволяет одновременно построить внутренний процесс и прозрачный клиентский интерфейс.

3. «Подрядчик выполнил» не должен означать «дефект закрыт»

Это важное бизнес-правило.

Между ними необходим статус:

«Ожидает проверки».

Иначе статистика будет показывать выполнение быстрее, чем проблема устраняется фактически.

4. Приемка — только начало жизненного цикла

Если продукт останавливается на автоматическом формировании акта, наиболее длинная часть процесса остается за его пределами.

Поэтому конкурентная ценность кейса находится в переходе:

приемка → гарантия.

5. MVP не нужен BIM и тем более 3D

Для этой задачи достаточно:

• структуры дома;
• квартиры;
• помещения;
• категории;
• при необходимости 2D-плана.

Добавление сложной строительной модели повысит стоимость, но почти не улучшит основной гарантийный процесс.

6. AI не является условием успеха

На первом этапе значительно важнее:

• правильные статусы;
• права доступа;
• фотографии;
• история;
• связь покупателя и объекта;
• контроль подрядчика.

AI становится полезен после накопления массива качественных дефектов.

7. Наиболее перспективная AI-функция — не распознавание трещины по фото

Большую бизнес-ценность потенциально дает обнаружение повторяющихся системных проблем.

Если система покажет, что одинаковый дефект возник в 30 квартирах одного дома, это позволяет перейти от ремонта отдельных обращений к управлению качеством строительства.

8. Главная техническая сложность — не CRUD

Сделать форму дефекта сравнительно легко.

Сложнее обеспечить:

• надежную историю;
• мобильную работу;
• фотографии;
• офлайн-синхронизацию;
• строгие permissions;
• хранение персональных данных.

9. Главный бизнес-риск — сильные существующие решения

«Контур.Недвижимость», Domyland, PlanRadar и другие продукты уже закрывают заметную часть рассматриваемого процесса.

Поэтому новый продукт не должен продаваться как «еще одна цифровая приемка».

Более реалистичное позиционирование:

узкий гарантийный контур для девелопера, который хочет автоматизировать дефекты, покупателей и подрядчиков, не заменяя существующую CRM и остальные корпоративные системы.

10. Самая сильная функция удержания — накопленная история объекта

Через два-три года система содержит:

• дефекты каждой квартиры;
• повторные ремонты;
• историю подрядчиков;
• фотографии;
• переписку;
• статистику домов.

Эти данные трудно перенести обратно в Excel без потери контекста.

Именно исторический реестр, а не красивый интерфейс приемки, способен стать основным долгосрочным активом продукта.

Итоговая формула продукта

В упрощенном виде продукт можно описать так:

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

Главный продуктовый эффект заключается не в том, что сотрудник перестает пользоваться Excel как таковым. Изменяется сам принцип управления гарантийными обязательствами:

вместо списка обращений компания получает историю качества каждого объекта и контролируемый жизненный цикл каждого дефекта.