Клининговая компания в Казахстане обслуживала несколько десятков объектов в разных частях города и пригороде. Основной задачей проекта стало создание единой системы, которая отвечала бы на простой операционный вопрос: «Что сейчас происходит на каждом объекте и есть ли риск, что обязательная уборка не будет выполнена?»
Содержание
Клининговая компания в Казахстане обслуживала несколько десятков объектов в разных частях города и пригороде: офисы, торговые помещения, склады, небольшие бизнес-центры и административные здания.
Часть объектов убиралась ежедневно, часть — несколько раз в неделю. На одних площадках постоянно работали закрепленные клинеры, на других сотрудники приезжали по графику или подменяли коллег.
По мере роста количества контрактов появилась операционная проблема: руководитель знал, какие уборки запланированы, но не всегда мог быстро определить, какие из них действительно состоялись.
Подтверждение выполнения работ существовало сразу в нескольких форматах:
Если клиент сообщал утром, что вечером уборка не была выполнена, восстановление событий превращалось в отдельное расследование: кто должен был приехать, был ли сотрудник на объекте, когда он начал работу, какие зоны убирал, были ли фотографии и почему супервайзер не увидел проблему раньше.
Основной задачей проекта стало создание единой системы, которая отвечала бы на простой операционный вопрос:
«Что сейчас происходит на каждом объекте и есть ли риск, что обязательная уборка не будет выполнена?»
Та же логика эксплуатационного слоя для multi-site сети разбирается в кейсе диспетчеризации сети коммерческих парковок — для парковочной инфраструктуры, а не клининговых контрактов.
Проблема заключалась не столько в планировании смен, сколько в отсутствии надежной фиксации фактического исполнения.
Например, в расписании стояла уборка офиса с 19:00 до 21:00. Для диспетчера такая задача считалась назначенной. Но назначение сотрудника еще не означало выполнение работы.
Могло произойти несколько ситуаций:
Контролировали
план
Требовалось контролировать
факт
Для этого было недостаточно добавить еще один отчет. Необходимо было перестроить сам процесс подтверждения уборки.
Похожая фрагментация подтверждений через чаты и таблицы характерна и для гостеприимства — см. решение для календаря уборок в отелях и глэмпингах.
В проекте выделили четыре основные роли.
Для сотрудника система должна быть максимально простой. На объекте ему не нужна большая корпоративная CRM.
Рабочий сценарий
получить задание → подтвердить прибытие → выполнить обязательные действия → приложить подтверждения → завершить работу.
Основной интерфейс клинера реализован как мобильный PWA-интерфейс по образцу разработки корпоративных PWA-приложений — его можно открыть со смартфона без сложного обучения.
Диспетчер отвечает за текущую ситуацию. Ему нужен не архив отчетов, а оперативная панель отклонений.
Видит
Супервайзер контролирует несколько объектов и разбирает исключительные ситуации:
Руководителю нужна агрегированная картина:
Вместо попытки контролировать сотрудников через постоянные звонки система строит цифровую цепочку доказательств выполнения работы.
Каждая уборка становится отдельным заданием со своим жизненным циклом:
Запланировано → Назначено → Сотрудник прибыл → Работа начата → Выполняется → Завершено → Проверено.
Дополнительно существуют статусы отклонений:
Статус формируется не только вручную. Система учитывает события, которые происходят во время работы:
Таким образом, руководитель видит не сообщение «убрал», а последовательность подтвержденных событий.
Одним GPS-контролем решили не ограничиваться.
На части объектов геолокация внутри здания работает нестабильно, а координаты сами по себе не доказывают, что сотрудник действительно получил доступ к нужной зоне.
Поэтому использовали комбинированное подтверждение.
На объекте размещается QR-код. Сотрудник открывает задание и сканирует его при начале работы.
Система сохраняет:
QR-код привязан к конкретному объекту и не заменяет авторизацию сотрудника.
Если уборка начинается необычно далеко от объекта или значительно позже установленного окна, система не обязательно блокирует сотрудника, а создает операционное отклонение.
Это важное решение: интерфейс не должен мешать выполнить работу из-за технической погрешности. Его задача — показать диспетчеру ситуацию, требующую проверки.
В начале смены сотрудник видит только свои задания.
Например:
19:00 — офис, 3 этаж
Адрес объекта
Плановое время: 90 минут
Статус: «Можно начинать»
После прибытия сотрудник нажимает «Начать уборку».
Система предлагает отсканировать QR-код объекта.
После подтверждения открывается чек-лист:
У конкретного объекта может быть собственный набор зон и требований.
Для некоторых пунктов достаточно отметить выполнение. Для критичных зон требуется фотография. Та же связка чек-листа и фото, но для выбора объекта, а не для уборки, — осмотр производственной площадки по чек-листу проекта.
Если сотрудник замечает проблему, не связанную непосредственно с уборкой — например, протечку, разбитый дозатор или отсутствие расходных материалов — он может нажать «Сообщить о проблеме», выбрать категорию и приложить фотографию.
Событие сразу становится доступно супервайзеру.
Одной из ключевых функций стала обработка уборок, которые должны были начаться, но не начались.
Для каждого задания хранится допустимое временное окно.
Например:
Если в 19:15 подтвержденного начала нет, задача автоматически попадает в блок внимания диспетчера.
Система показывает:
«Уборка не начата. Исполнитель назначен. Связь с объектом отсутствует.»
Диспетчер может:
Если сотрудника заменили, история первоначального назначения не исчезает.
Это позволяет позднее понять, какие объекты и сотрудники чаще всего создают необходимость срочного перепланирования.
Вторая важная часть системы — цифровая карточка каждого объекта.
Раньше информация об объекте могла быть распределена между договором, таблицей, сообщениями супервайзера и памяткой сотруднику.
Теперь в карточке объединены:
Например:
Для каждой зоны можно задать собственный чек-лист.
Сотрудник перед сменой видит только актуальные инструкции:
На временной шкале отображаются:
Так супервайзер может открыть объект и увидеть не только сегодняшнюю ситуацию, но и повторяющийся паттерн проблем.
Та же идея единой истории объекта с QR-подтверждением на месте разбирается в кейсе эксплуатационного двойника многоквартирного дома — для управляющей компании жилого фонда, а не клининговых контрактов.
Главным рабочим экраном диспетчера стал dashboard текущего дня.
Вместо обычного отчета он построен по принципу management by exception — внимание пользователя направлено в первую очередь на то, что идет не по плану. Тот же подход к диспетчерскому экрану описан для диспетчеризации курьерской доставки.
Наверху отображается сводка:
Ниже — все задания дня.
Можно быстро отфильтровать:
Диспетчеру больше не требуется последовательно писать каждому клинеру и спрашивать статус.
Если процесс идет нормально, объект практически не требует внимания.
Если появляется отклонение, система поднимает его наверх.
Фотоотчет не сделали отдельной папкой с сотнями изображений.
Каждое фото имеет контекст:
объект → уборка → зона → пункт чек-листа → исполнитель → время.
Например:
Объект: офис
Зона: кухня
Требование: «Очистить рабочую поверхность»
Фото после выполнения
Исполнитель: сотрудник смены
Время: 20:12
Для обязательных фотографий система проверяет сам факт их наличия перед завершением задания.
Если какая-либо фотография отсутствует, сотрудник видит конкретное сообщение:
«Для завершения добавьте фотографию зоны "Санузел, 2 этаж".»
В дальнейшем эта же структура позволяет добавить автоматический анализ фотографий без перестройки основного процесса.
Если супервайзер или заказчик обнаруживает недостаток, он создается не как сообщение в чате, а как замечание, связанное с конкретным объектом и уборкой.
Например:
Замечание: загрязнение пола возле входа.
Зона: входная группа.
Приоритет: высокий.
Ответственный: текущая смена.
Требуется: переделка и контрольное фото.
После выполнения сотрудник прикладывает новую фотографию.
Замечание получает статус «Исправлено», но окончательное закрытие может выполнить супервайзер.
Таким образом появляется полноценная цепочка:
уборка → замечание → переделка → подтверждение → закрытие.
Один из наиболее важных процессов выглядит следующим образом.
История фиксирует:
Первоначальный исполнитель → невыход → причина → назначена замена → новый исполнитель → фактическое начало.
Такой подход позволяет впоследствии анализировать причины сбоев, а не просто исправлять расписание задним числом.
После появления структурированных событий стало возможно автоматизировать часть работы диспетчера.
Например:
Если плановое время начала прошло более чем на допустимый интервал и события
startedнет, то создать отклонение «Уборка не начата».
Или:
Если сотрудник пытается завершить задание и обязательный пункт чек-листа не выполнен, то не завершать задание и показать недостающий пункт.
Или:
Если уборка завершена и присутствует открытое критичное замечание, то направить задание супервайзеру на проверку.
Правила остаются прозрачными и управляемыми. Для базового контроля не требуется сложная AI-модель.
Это также упрощает разбор спорных ситуаций: руководитель может понять, почему система отметила конкретное задание как проблемное.
Для первой версии сознательно не стали объединять управление клинингом, расчет зарплаты, бухгалтерию, склад и клиентский портал в одну систему — эти контуры логичнее подключать позже через интеграции Laravel с 1С.
MVP был сфокусирован именно на доказуемом исполнении работ.
В него вошли следующие блоки.
Карточки объектов, зоны, инструкции, графики и QR-коды.
Список клинеров и супервайзеров, роли, доступность и привязка к заданиям.
Создание разовых и повторяющихся заданий.
Начало работы, QR-подтверждение, чек-лист, фотографии, фиксация проблем и завершение.
Экран сегодняшних уборок и отдельная очередь отклонений.
Фотографии сохраняются в контексте конкретного объекта, задания, зоны и сотрудника.
Для каждого задания существует журнал: кто → что → когда сделал.
Система сообщает ответственным не о каждом нормальном событии, а преимущественно об отклонениях: уборка не началась, сотрудник опаздывает, задание осталось незавершенным, отсутствует обязательное фото, зарегистрирована проблема, требуется переделка. Так система не превращается в еще один источник информационного шума.
Система спроектирована как единое прикладное веб-приложение без избыточной инфраструктуры.
Client
Для диспетчеров, супервайзеров и руководителей используется адаптивный веб-интерфейс. Для клинеров тот же frontend работает как PWA, оптимизированный под смартфон.
API
Backend отвечает за пользователей и роли, объекты, расписание, задания, чек-листы, статусы, журнал событий, работу с фотографиями, правила контроля, уведомления и отчеты. REST API оставляет возможность позднее подключить Telegram-бот, клиентский кабинет, отдельное мобильное приложение и интеграции с учетными системами.
Data
Особое значение имеет task_events. Вместо хранения только текущего статуса система фиксирует последовательность событий: assigned, qr_verified, started, checklist_updated, photo_uploaded, issue_created, completed, verified. Это дает возможность восстанавливать фактический ход любой уборки.
Queue / cache
Обработка уведомлений, проверка просроченных заданий, подготовка отчетов, фоновая обработка фотографий.
Storage
В PostgreSQL остаются метаданные и связи с объектом, заданием, зоной и сотрудником.
Infrastructure
Для типового развертывания достаточно цепочки Nginx → Laravel → PostgreSQL + Redis + S3-хранилище. Приложение разворачивается через Docker-контейнеры без Kubernetes и отдельной микросервисной инфраструктуры.
До внедрения системы информация двигалась в основном через людей:
До
клинер → сообщение → супервайзер → сообщение → диспетчер → таблица → руководитель.
После
запланировано → сотрудник назначен → подтверждено прибытие → зафиксировано выполнение → сохранены доказательства → автоматически выявлены отклонения.
После внедрения основным источником статуса стало само задание.
Коммуникация между людьми не исчезла.
Но Telegram и телефон перестали играть роль базы данных.
Ими стали пользоваться для решения исключений, а не для хранения истории операций.
Самое заметное изменение — возможность перейти от постоянного ручного контроля к контролю отклонений.
Руководителю больше не нужно проверять каждый объект.
На одном экране видно:
История стала пригодна для анализа.
Можно посмотреть:
Для корпоративного клиента становится возможным сформировать отчет не на основе ручного комментария менеджера, а на основе накопленных событий.
В отчете могут отображаться:
При спорной ситуации менеджер открывает конкретную уборку и видит всю цепочку событий.
Это особенно важно для распределенных объектов, где представитель заказчика физически не присутствует во время каждой уборки.
Проект не сводился к цифровизации существующего журнала уборок.
Главным изменением стала сама модель операционного управления.
Раньше компания пыталась получить подтверждение постфактум.
После внедрения системы выполнение работ стало оставлять структурированный цифровой след автоматически в процессе смены.
В результате компания получила:
Точные показатели эффекта зависят от количества объектов, графиков и организационной структуры конкретной компании, поэтому результат проекта корректнее оценивать через операционные показатели: снижение количества необнаруженных вовремя невыходов, сокращение ручных проверок статусов и полноту цифровой истории выполненных работ.
После накопления достаточного объема структурированных данных систему можно развивать постепенно.
Модель анализирует обязательные фотографии и отмечает случаи, требующие внимания супервайзера:
AI здесь не должен автоматически объявлять уборку качественной или некачественной. Его полезнее использовать как первичный фильтр для инспектора — в том же духе, что и сценарии AI-автоматизации бизнес-процессов на накопленных операционных данных.
На основании истории смен можно рассчитывать риск проблемного назначения, учитывая:
Результатом становится не автоматическое наказание сотрудника, а предупреждение диспетчеру при составлении расписания.
При невыходе система может ранжировать возможных замен:
Для корпоративных контрактов можно добавить автоматический контроль:
какие обязательные работы по договору должны быть выполнены → какие реально подтверждены системой → где возникает риск нарушения обязательств.
Связав фактическое время работы с плановым нормативом, система сможет показывать:
Таким образом, первоначальный продукт для подтверждения факта уборки постепенно превращается в операционную систему управления распределенной клининговой компанией — без необходимости сразу создавать тяжелую комплексную платформу.
Нужна разработка операционного контура клининга, контроля уборок на объектах, MVP на Laravel + Vue — частный разработчик на Laravel ведёт такие проекты от архитектуры до запуска. Другие концепции — в каталоге решений.
