Как спроектировать веб-приложение для обслуживания кондиционеров: объекты, договоры, план ТО, выезды, маршруты и чек-листы. Пошаговый план.
В сервисной компании по кондиционерам обычно болит одно и то же: договоры живут в папках, план ТО - в таблице, выезды - в мессенджере, а закрывающие документы собираются «когда будет время». В итоге теряются контакты, забываются обязательные работы и растут споры с клиентом. Хорошая цель для веб-приложения - собрать эти части в одну понятную систему.
Удобно сразу мыслить цепочкой: «объект -> оборудование -> договор -> план ТО -> выезд -> акт/счет». Тогда любая запись продолжает предыдущую: выезд привязан к конкретному кондиционеру и условиям договора, а акт формируется из факта работ.
Обычно есть 4 роли, и у каждой свои задачи. Универсальная «форма для всех» почти всегда превращается в путаницу.
Самые дорогие ошибки чаще организационные, а не технические. Сезон начался, а по части объектов так и не сделали профилактику, потому что «таблица была у другого сотрудника». Или клиент спорит по счету: «вы не чистили дренаж», а доказать нечем, потому что чек-лист не заполнили, а фото не сохранили.
Теряются и простые вещи: телефоны ответственных на объекте, график доступа, где ключи, какой этаж, какая модель и серийный номер. На выезде это превращается в лишние звонки и простои.
Прежде чем добавлять автоматизацию, договоритесь о единых справочниках и правилах учета. Иначе система будет аккуратно хранить хаос.
Нужен базовый минимум:
Когда основа понятна, первый рабочий вариант собирается заметно быстрее. Например, в TakProsto можно описать роли, справочники и цепочку документов, а затем в режиме планирования (planning mode) попросить AI собрать основные экраны: календарь ТО, карточку объекта и форму выезда с чек-листом.
Начните с двух сущностей: Объект и Оборудование. Это основа для договоров, планового ТО и выездов. Если стартовать со сложных статусов и десятков справочников, команда быстро утонет в заполнении, а мастера снова уйдут в мессенджер.
Объект - это место, куда вы приезжаете. Ему нужен адрес (лучше разложить на город, улицу, дом, корпус, подъезд), контакт на месте (ФИО и телефон) и короткое описание доступа: где ключ, как пройти в техпомещение, в какие часы можно шуметь. Полезны фото: вход, щиток, место установки наружных блоков. Добавьте поле «Заметки» для всего, что не ложится в структуру (например, «охранник просит звонить за 15 минут»).
Оборудование - конкретный кондиционер или система. Минимум: тип (сплит, мультисплит, VRF, фанкойл), модель, серийный номер. Для сервиса важны дата установки и гарантия (дата окончания или срок в месяцах). Если серийник неизвестен при первом визите, не блокируйте создание карточки: пусть мастер добавит его позже.
Связь простая: один объект - много единиц оборудования. В карточке объекта удобно показывать список устройств с быстрыми ориентирами: где стоит (кабинет/зона), внутренний или наружный блок, и любой маркер, который помогает найти устройство на месте.
Чтобы не раздувать форму, держите обязательными только то, без чего невозможно работать:
Все остальное делайте опциональным и заполняемым «по ходу дела». Так база растет без сопротивления.
История изменений нужна даже в простом MVP: кто поменял контакт, кто обновил серийник, кто добавил фото. Это снижает споры с клиентом и помогает новым сотрудникам быстро понять контекст. Если не хотите усложнять, начните с ленты событий: «добавлено оборудование», «изменен адрес», «обновлена гарантия» с датой и автором.
Договор - точка опоры для сервиса: по нему понятно, что именно вы обязаны делать, когда и за какие деньги. Начните с простого: договор должен легко связываться с объектами и конкретными единицами оборудования.
Минимальный состав договора:
Дальше важна привязка. Один договор может покрывать несколько объектов, а внутри объектов - несколько кондиционеров. На практике удобно хранить связи «договор -> объекты» и «договор -> оборудование» отдельно. Так проще делать исключения: например, договор на весь офис, но два серверных кондиционера обслуживаются по другим правилам.
Статусы договора держите короткими и понятными: черновик (согласование), активен (работаем), приостановлен (работы ограничены), завершен (история остается, новые работы не создаем). Эти статусы должны влиять на плановое ТО и на возможность создавать выезды.
Чтобы не путаться во включенных работах и расходниках, сразу зафиксируйте правила: что входит по умолчанию, что оплачивается отдельно и какие лимиты действуют. Пример: чистка фильтров и диагностика входят, дозаправка фреоном - только по согласованию, крепеж и дренажные материалы - в пределах лимита.
Сканы и приложения храните без усложнения: один список файлов у договора (PDF, фото) с типом документа и датой. Плюс короткое поле «особые условия», чтобы мастеру не приходилось искать важную фразу внутри скана.
Плановое ТО удобнее строить не от «когда вспомним», а от сущности План ТО. В ней хранится периодичность (раз в месяц, раз в квартал, раз в 6 месяцев), сезонность (например, весна и осень) и окна посещения: в какие дни и часы объект готов принять мастера. Тогда календарь становится предсказуемым.
Практика показывает, что достаточно:
При создании задач заложите базовые ограничения:
Если на объекте 12 внутренних блоков, а ТО занимает 3 часа, это сразу видно в календаре, и задача не «притворяется» короткой.
Перенос должен быть событием со своей причиной и историей, а не правкой даты задним числом. Рабочая схема: статус «Запланировано -> В работе -> Завершено» и отдельные статусы «Перенесено» и «Отменено» с обязательным комментарием. При форс-мажоре лучше создавать новую задачу и сохранять связь с исходной, чтобы не терять аналитику по срывам.
Уведомления держите простыми: за 3 дня клиенту, за 1 день мастеру, за 2 часа напоминание с адресом и контактом. В planning mode это можно описать текстом и сразу зафиксировать как правило, чтобы оно работало одинаково для всех.
Выезд - точка, где сервис либо подтверждает качество, либо теряет деньги на «непонятно что сделали». Поэтому в системе нужна простая карточка выезда, которую мастер заполняет прямо на объекте.
Карточка должна отвечать на три вопроса: кто был, что сделал, какой результат. Базовые поля: дата и время, мастер, адрес (и зона на объекте), список работ, комментарий клиента. Полезно хранить привязку к договору и конкретным единицам оборудования, чтобы не было ситуации «обслужили не тот блок».
Чтобы диспетчеру и мастеру было видно, где застряла задача, используйте статусы:
«Завершен» означает, что мастер все заполнил. «Закрыт» - что офис проверил данные (фото, подпись, расходники) и принял выезд к оплате или в отчет.
Чек-лист лучше не делать заново каждый раз. Соберите шаблоны по типу оборудования (сплит, кассетный, VRF) и добавьте поправки по договору. Например, в одном договоре обязательна проверка дренажа и антибактериальная обработка, а в другом - только чистка фильтров и контроль температур.
Внутри выезда фиксируйте доказательства и цифры. Достаточно 4-6 обязательных пунктов, иначе мастера начнут «пропускать» форму:
Пример: мастер приехал на офис, где 8 внутренних блоков. По договору нужно ТО раз в квартал. В чек-листе он отмечает чистку фильтров, проверку дренажа, фиксирует температуру на выходе, делает 2 фото на каждый проблемный блок и пишет: «у блока 3 шумит вентилятор, рекомендована замена подшипника». Клиент подписывает, а выезд уходит в «Закрыт» только после проверки офисом.
Если собираете приложение в TakProsto, удобно один раз попросить AI подготовить шаблоны чек-листов под ваши типы кондиционеров и поля карточки выезда, а затем довести их до реальных требований договоров.
Маршрутизация не обязана быть «умной» с первого дня. Для старта достаточно понятных правил, чтобы мастера меньше ездили по городу и чаще попадали в окна клиента.
Маршрут опирается на три вещи: где, когда и сколько времени займет работа. Если этих данных нет или они «на глаз», любой алгоритм будет ошибаться.
Минимум по каждой точке:
На старте работает группировка по районам и близости. Например: «сегодня закрываем север, завтра центр». Внутри района ставьте первыми точки с жесткими окнами, а остальное подстраивайте вокруг.
Срочные заявки лучше вести отдельным статусом и вставлять поверх плановых по простому правилу: «если срочно и рядом - берем; если далеко - переносим ближайшее плановое ТО и уведомляем клиента». Так один вызов не развалит весь день.
Важно хранить не только план, но и факт: время выезда, прибытия, начала и окончания работ. Это быстро покажет, где оценки длительности завышены или занижены.
AI можно использовать как помощника: он предложит порядок точек и черновые расчеты, а диспетчер подтвердит руками. В TakProsto это обычно делается прямо в чате: вы даете список адресов, окна и длительности, а платформа возвращает черновик маршрута.
Пример: у мастера 6 точек на «Юго-Западе», две с окном 12:00-14:00. Сначала ставите их, затем заполняете маршрут ближайшими точками без окна, и в конце оставляете одну «гибкую» на случай срочного вызова.
MVP должен отвечать на три вопроса: где стоит оборудование, что обещали по договору и что именно сделал мастер на выезде. Если это закрыто, система уже дает порядок и меньше споров.
Начните с ролей и пары экранов под каждую. Диспетчеру нужен список объектов и календарь работ, мастеру - задания на сегодня и чек-лист, администратору - справочники и права доступа.
Дальше добавьте базовые справочники: клиенты, объекты (адреса, контакты, режим доступа), оборудование (модель, серийник, место установки), услуги и типовые работы. Не усложняйте: лучше 6-8 обязательных полей, чем идеальная карточка, которую никто не заполняет.
После этого подключайте договоры и автоматическое создание задач ТО. На старте достаточно: срок действия, перечень услуг, периодичность (например, раз в 3 месяца), лимиты (сколько выездов включено) и что считается допработами.
Когда задачи создаются, вводите выезды. На выезде мастер отмечает выполненные пункты, расходники и прикладывает фото до/после. Это экономит время на разбор претензий и помогает контролировать качество.
Минимальная последовательность:
Маршрутизацию и печатные акты можно оставить на потом. А генерацию задач ТО и контроль статусов лучше включить сразу.
Практика: у вас 5 объектов по городу и 25 кондиционеров. В первый месяц диспетчер вручную подтверждает даты выездов, но система сама создает задачи по договору, не дает забыть про объект и собирает единый отчет по каждому выезду.
Если делаете MVP в TakProsto, удобно сначала описать экраны и поля в чате, а затем итерациями уточнять: какие статусы нужны, какие пункты чек-листа обязательны, какие фото требуются.
Первая версия системы почти всегда ломается не из-за сложных расчетов, а из-за мелких решений в данных и процессах. Вот ошибки, которые чаще всего приводят к хаосу через 2-3 недели, и способы их обойти.
Частая ситуация: «клиент» = «адрес». Пока объект один, это работает. Потом у юрлица появляется 5 офисов, склад и серверная, а контакты разные: бухгалтерия, администратор, ответственный по доступу.
Как сделать правильно: разделите сущности. Клиент хранит реквизиты и общие контакты, объект - адрес, режим доступа, парковку, особенности помещения. Тогда не будет путаницы, кому звонить и куда ехать.
Если договор или заявка выглядят как одна карточка с полями, со временем никто не вспомнит, что именно было согласовано и когда менялось. Возникают споры: «вы обещали приехать», «мы переносили», «это было не включено».
Минимум, который спасает: статусы (черновик, согласовано, в работе, закрыто) и журнал событий. Даже короткая история в стиле «перенос с 12 на 14, причина: нет доступа» снимает половину конфликтов.
Мастера перестают заполнять данные, если закрытие выезда превращается в анкету. Итог: отчеты пустые, чек-листы не закрываются, а план ТО становится «на словах».
Рабочий подход: оставьте 3-5 обязательных полей, остальное - по необходимости. Например: «работы выполнены», «фото до/после», «рекомендации», «подпись/подтверждение».
Календарь выглядит красиво только в первый месяц. Потом начинаются переносы из-за доступа, погоды, срочных заявок. Если перенос не фиксируется как событие и не требует причины, плановое ТО быстро становится недостоверным.
Как избежать: перенести можно только через действие «перенос» с обязательной причиной и новым сроком. Полезно показывать просрочку отдельным списком, а не прятать ее в календаре.
Если строить день только по «ближе-дальше», будут опоздания и накладки. Клиенты часто могут принять мастера только в конкретный промежуток, а на некоторых объектах долго оформляется пропуск.
Простой набор правил:
Если собираете MVP в TakProsto, имеет смысл сразу заложить эти ограничения в модель выезда и подсказки для диспетчера, чтобы правила работали по умолчанию, а не держались в голове у одного человека.
Чтобы приложение реально помогало, а не превращалось в «еще одну таблицу», перед запуском проверьте базовые вещи. Большинство сбоев начинается не с планирования, а с неточных данных и неясных правил.
Убедитесь, что у каждого объекта есть понятный способ попасть внутрь. Не ограничивайтесь телефоном клиента: важны окна доступа, правила прохода, ключи, охрана, пропуска, парковка. Эти детали экономят часы и снимают конфликты на месте.
Проверьте, что оборудование привязано к объектам и не «плавает» между адресами. Серийные номера и модели должны быть актуальны, иначе вы не сможете быстро понять историю конкретного блока и типовые проблемы.
Короткая проверка перед стартом:
Перед выездом мастер должен открыть задачу и понимать, что именно делать и что привезти. Простое правило: если по задаче нельзя собрать сумку и понять порядок работ, чек-лист слишком общий.
Мини-чек перед выездом:
После выезда сразу фиксируйте статус, итог и рекомендации клиенту, а также следующую дату ТО. Так это не потеряется в переписках.
Управляющая компания обслуживает 3 объекта: офисный центр, магазин и небольшое кафе. Всего 25 кондиционеров, на выездах работают 2 мастера. Задача на сезон: не забыть плановое ТО, быстро закрывать срочные заявки и давать клиенту понятные отчеты.
За 1 день можно завести базу даже без идеального учета. Начните с карточек объектов (адрес, контакт, режим доступа) и добавьте оборудование по факту обхода: сфотографировали шильдик, записали тип (сплит, кассета), место установки, примерную мощность, серийный номер, если виден. Если номера нет, временно используйте метку вроде «Офис-2 этаж-кабинет 214», позже замените.
Дальше оформляется сезонный договор: период (например, апрель-сентябрь), количество ТО на каждую единицу (2 раза за сезон), что входит (чистка фильтров, проверка дренажа, замер температур, диагностика утечек по признакам), что считается допработами.
После этого система раскладывает плановое ТО по месяцам: 25 штук x 2 = 50 задач. Чтобы не было перегруза, распределите по правилам: в апреле 8 задач, в мае 10, в июне 10, в июле 8, в августе 8, в сентябре 6. Переносы делайте только с причиной (нет доступа, объект закрыт, нужен подъемник).
На ежедневные выезды работает простая схема: один основной маршрут и один резерв под срочные заявки.
Клиенту достаточно 3 отчетов, чтобы было доверие и меньше вопросов: выполненные работы по договору, список замечаний с приоритетом (срочно, в сезон, позже) и рекомендации по замене расходников. Такой подход легко укладывается в систему: видно план, факты и что делать дальше.
Если собираете систему в TakProsto, удобно начать с объектов и договоров в planning mode, а затем попросить AI сгенерировать задачи ТО, чек-листы и шаблоны отчетов под ваши условия.
Чтобы система не превратилась в бесконечный «переделаем потом», сначала соберите требования в одном месте. Толстое ТЗ не нужно: достаточно одного документа, где ясно, кто и что делает каждый день.
Зафиксируйте основу: роли (диспетчер, мастер, руководитель), обязательные поля (объект, оборудование, договор, дата ТО), статусы (запланировано, в работе, выполнено, перенос) и отчеты, которые реально нужны (например, ТО по объектам за месяц и долги по договорам).
Подготовьте материалы, чтобы AI не «догадывался»:
Дальше выберите способ реализации. Своя разработка дает максимум контроля, но старт обычно дольше: экраны, права, база, тесты, деплой. Если нужен быстрый запуск, удобнее платформа, где приложение собирается из чата.
В TakProsto (takprosto.ai) можно в режиме планирования описать сущности и экраны (объекты, договоры, выезды, чек-листы), а затем получить рабочее приложение. Если позже понадобится развивать проект «как свою систему», у платформы есть экспорт исходного кода.
Запуск делайте через пилот. Например, возьмите одну бригаду на 2 недели: фиксируйте выезды, закрывайте ТО чек-листом, смотрите, где теряются данные (фото, подпись, причина переноса). Потом масштабируйте на остальные команды и добавляйте права доступа, чтобы мастер видел только свои выезды, а руководитель - сводные отчеты.
Начните с цепочки «объект → оборудование → договор → план ТО → выезд → акт/счет». Это сразу убирает разрывы в данных: выезд всегда привязан к конкретному кондиционеру и условиям договора, а документы формируются из факта работ, а не из памяти сотрудников.
Разделите минимум на четыре роли: диспетчер (календарь и назначения), мастер (задания и чек-лист), менеджер (клиенты и договоры), бухгалтерия (акты, счета, оплаты). Если всем дать одну и ту же форму и один и тот же набор полей, люди начнут заполнять по-разному, и система быстро превратится в «еще одну таблицу».
Сущность «Объект» — это место работ: адрес, контакт на месте, правила доступа и полезные заметки. «Оборудование» — конкретный блок: тип, модель, серийный номер, дата установки и гарантия. Не смешивайте клиента и объект: у одного юрлица может быть много адресов и разные ответственные.
Не блокируйте работу из-за неизвестного серийного номера. Разрешите создать карточку с типом и моделью (или хотя бы типом), а серийник добавлять позже с выезда, когда мастер сфотографирует шильдик. Важно лишь, чтобы устройство было жестко привязано к объекту и не «переезжало» между адресами без фиксации.
Договор должен отвечать на четыре вопроса: что делаем, когда делаем, за сколько и с какими ограничениями. Минимум — период действия, условия реакции/восстановления (если есть), схема стоимости, лимиты и список работ «входит/не входит». И обязательно храните привязки отдельно: «договор → объекты» и «договор → оборудование», чтобы легко делать исключения.
Сделайте перенос отдельным событием, а не тихой правкой даты. Правило простое: перенос возможен только через действие «перенос» с обязательной причиной и новым сроком, чтобы потом было видно, сколько задач сорвано из‑за доступа, погоды или клиента. Это сильно помогает и диспетчеру, и руководителю при разборе просрочек.
Держите простую карточку выезда, которая закрывает три вещи: кто был, что сделал, какой результат. Добавьте статусы так, чтобы офис видел, где «застряло»: «запланирован», «в пути», «в работе», «завершен» (мастер все заполнил), «закрыт» (офис проверил фото/расходники/подпись). Тогда выезд не попадет в документы, пока нет доказательств и понятного итога.
Используйте шаблоны по типу оборудования (сплит, кассетный, VRF) и донастраивайте под договор. Сделайте 4–6 обязательных пунктов, иначе мастера начнут пропускать форму; обычно хватает фото до/после, ключевых замеров, замечаний, рекомендаций и подтверждения результата. Детальные пункты можно оставлять необязательными и включать только для отдельных договоров или гарантийных случаев.
Для старта хватит правил, а не сложной оптимизации: группируйте выезды по районам и сначала ставьте точки с жесткими окнами, а гибкие — вокруг. Обязательно храните «план» и «факт» (время выезда, прибытия, начало/конец работ), иначе вы не поймете, где ошиблись в оценке длительности и почему график постоянно сдвигается.
Зафиксируйте единые справочники, статусы и обязательные поля до начала разработки, иначе система будет аккуратно хранить хаос. В TakProsto удобно начать с planning mode: описать сущности (объекты, оборудование, договоры, выезды), роли и ключевые экраны, а потом итерациями уточнять обязательные поля и правила уведомлений. Чтобы быстрее перейти к работе, запускайте пилот на одной бригаде на 1–2 недели и только потом масштабируйте.
