Клининг: график 30 бригад по городу и приложение без платы за пользователя

MAATRIX

Когда у клининговой компании три бригады, график можно держать в голове диспетчера и общем чате. Когда бригад тридцать, а объекты разбросаны по всему городу — офисы, торговые центры, жилые комплексы, разовые заказы — ручное управление начинает сыпаться: кто-то не приехал на объект, кто-то приехал вдвое дольше, чем нужно, а клиент звонит и спрашивает, почему уборка не началась. Готовые приложения для полевых сотрудников решают эту задачу технически, но обычно берут плату за каждого пользователя — и чем больше у вас бригад, тем больше вы платите каждый месяц. Ниже — про то, как устроена эта боль на практике и почему для клининговой компании со стабильным штатом бригад разумной альтернативой становится собственная система координации на своём сервере с фиксированной стоимостью независимо от числа сотрудников.

Почему график 30 бригад — это не CRM, а логистика в реальном времени

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

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

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

Ключевое отличие клининга от, например, магазина или мастерской — сотрудник почти никогда не сидит за компьютером. Вся коммуникация идёт через смартфон, часто не самый новый, часто с нестабильным интернетом в подвале торгового центра или на объекте без wifi. Система координации графика должна быть простой до предела: открыл — увидел свои объекты на сегодня, отметил статус, поехал дальше.

Почему готовые приложения для полевых сотрудников дорожают вместе со штатом

На рынке достаточно готовых приложений для управления полевыми командами — трекинг местоположения, распределение задач, чек-листы, фотоотчёты. Технически они закрывают ровно ту потребность, которая описана выше. Проблема в модели тарификации, а не в функциональности.

Подавляющее большинство таких сервисов берёт плату по модели «за пользователя» или «за место» в месяц: чем больше у вас людей, которым нужен доступ к приложению, тем больше строка в счёте. Причём считаются обычно не только сами уборщики в бригадах, но и бригадиры, диспетчеры, иногда даже руководитель, который просто хочет видеть общую картину. Если у компании 30 бригад по два-три человека — это уже 60-90 потенциальных пользователей, даже если реальный доступ с полным набором функций нужен не всем.

Модель «за пользователя» логична для разработчика приложения — она напрямую привязывает выручку к тому, насколько крупный у вас бизнес. Но для клининговой компании это означает, что рост штата бригад — то есть рост самого бизнеса — автоматически увеличивает статью расходов на ПО, причём линейно и без потолка. Наняли пять новых бригад под новый крупный контракт — заплатите за пять дополнительных мест уже в следующем платёжном цикле, независимо от того, окупился ли ещё сам контракт.

Второй нюанс: в клининге состав бригад не статичен. Текучка в отрасли выше, чем в среднем по рынку труда, — сезонные подработки, декреты, увольнения после испытательного срока. Каждое кадровое изменение в модели «за пользователя» — это либо ручное управление лицензиями (не забыть отключить уволенного, не забыть добавить нового), либо переплата за неиспользуемые места, которые никто вовремя не убрал из тарифа.

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

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

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

• Календарь/график по бригадам и объектам. Наряд на день или неделю: какая бригада, какой адрес, время начала и ожидаемая длительность, тип уборки (разовая, регулярная, генеральная).
• Мобильный доступ бригадира. Простой веб-интерфейс, открывающийся в браузере телефона без установки приложения из магазина — это снимает вопрос совместимости с разными моделями телефонов у сотрудников.
• Статусы выполнения. Отметки «выехал» / «на объекте» / «завершено», видимые диспетчеру в реальном времени, без звонков.
• Привязка к объекту, а не только к клиенту. У одного клиента может быть несколько точек (сеть магазинов, бизнес-центр с разными этажами) — система должна различать их как отдельные адреса с отдельным графиком.
• Уведомления о изменениях. Если объект перенесли или отменили, бригадир должен узнать об этом раньше, чем выедет, — через Telegram-бота или push, а не постфактум в общем чате.
• История и фотоотчёты по желанию. Не обязательный минимум, но частое требование клиентов по договору — подтверждение выполненной уборки фото до/после.

Обратите внимание: ничего из этого списка не требует сложной бизнес-логики уровня CRM для продаж или биллинга. Это, по сути, разделяемый календарь с привязкой к адресам и статусами — задача, которая закрывается достаточно простыми инструментами, если не пытаться сразу строить универсальную платформу.

Технологическая база: что реально развернуть на своём сервере

Здесь не нужно писать полноценное мобильное приложение с нуля — это дорого и избыточно для задачи «показать бригадиру его объекты на сегодня». Рабочий подход — собрать систему из open-source инструментов, которые уже закрывают табличную/канбан-логику, и обвязать их простым веб-интерфейсом или ботом поверх.

Практичные варианты базы:

• Табличный планировщик на no-code платформе. Baserow или NocoDB дают представление календаря и канбана из коробки, формы для ввода нарядов диспетчером и REST API, через который можно отдавать бригадиру только его объекты на сегодня — без доступа к чужим данным.
• Канбан-доска по объектам (Wekan, Vikunja) — если график удобнее вести как карточки задач по статусам «назначено → в пути → на объекте → завершено», а не как строгий календарь.
• Простой веб-фронт поверх базы. Небольшая страница-читалка (статический HTML + JS-запрос к API), которая по номеру бригады или логину показывает только сегодняшний список объектов — это закрывает 90% потребности бригадира и не требует установки приложения.
• Telegram-бот для уведомлений и отметок статуса. Дешевле в разработке, чем полноценное приложение, и не требует от сотрудника ничего, кроме уже установленного мессенджера — бригадир пишет боту «выехал» или «закончил», статус фиксируется в базе.

Минимальный стек на VPS для такой связки — Docker Compose с базой данных (PostgreSQL), выбранной no-code платформой, Nginx как reverse proxy с автоматическим SSL и, отдельным контейнером, ботом на Python или Node.js, который читает и пишет в ту же базу через API. Пример каркаса:

version: "3.8"
services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: klining
      POSTGRES_USER: klining
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/postgresql/data

  scheduler:
    image: baserow/baserow:1.28.1
    restart: unless-stopped
    environment:
      BASEROW_PUBLIC_URL: https://grafik.example.com
      DATABASE_HOST: db
    depends_on:
      - db
    volumes:
      - baserow_data:/baserow/data

  bot:
    build: ./bot
    restart: unless-stopped
    env_file: .env
    depends_on:
      - db

  nginx:
    image: nginx:alpine
    restart: unless-stopped
    ports:
      - "443:443"
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./certs:/etc/letsencrypt

volumes:
  db_data:
  baserow_data:

Это не готовое решение под ключ, а рабочий каркас: реальные поля таблиц, логика бота и вид фронта под бригадира вы дописываете под свои процессы. Но именно в этом и смысл — система подгоняется под то, как реально работает ваша диспетчерская, а не наоборот.

Отдельно стоит учесть надёжность: график, который бригады смотрят каждое утро, — критичный сервис. На него стоит поставить мониторинг доступности (например, Uptime Kuma отдельным контейнером) и настроить регулярный бэкап базы — потеря графика на день означает реальный срыв работы, а не просто неудобство.

Экономика: фиксированная стоимость сервера против растущей платы за бригаду

Смысл всей конструкции — не в том, что «своё дешевле по умолчанию», а в том, что структура расходов принципиально разная. Стоимость VPS не зависит от того, сколько у вас бригад — сервер с одинаковыми ресурсами обслуживает и 10, и 40 пользователей интерфейса, пока не упирается в реальный технический предел мощности (а для такой лёгкой нагрузки, как табличный планировщик и бот, этот предел далеко). Плата за готовое приложение с моделью «за пользователя», наоборот, растёт с каждым новым человеком, которому нужен доступ.

Проще всего эту разницу увидеть на относительной шкале — ниже не реальные цены (они у каждого сервиса свои и меняются), а иллюстрация самой формы кривой расходов при росте штата бригад:

Формула простая: цена за пользователя у рассматриваемого сервиса, умноженная на реальное число людей с доступом (включая бригадиров и диспетчеров, а не только уборщиков), против цены аренды VPS нужной мощности плюс время на первичную настройку. Для задачи такого масштаба — календарь, статусы, уведомления на 30-60 человек — достаточно бюджетного VPS: нагрузка на CPU и RAM низкая и растёт медленно даже при увеличении штата.

Точка окупаемости зависит от конкретных цифр вашего договора с текущим сервисом и от того, сколько стоит первичная настройка (своя или подрядчика). Но чем больше бригад в компании и чем стабильнее штат, тем очевиднее преимущество фиксированной модели — экономия на масштабе работает в вашу пользу, а не против неё, как в подписке за пользователя.

Как перейти без остановки текущей работы

Полный переход с готового приложения на самописную систему рискован, если делать его одним днём для всех 30 бригад сразу — любая недоработка в интерфейсе или логике статусов в первый же день сорвёт реальный график. Разумнее двигаться поэтапно:

1. Пилот на 2-3 бригадах. Выберите бригады с опытными бригадирами, которые спокойно отнесутся к смене инструмента, и переведите на новую систему только их, оставив остальных на старом приложении на 2-3 недели.
2. Параллельная работа диспетчера. На время пилота диспетчер ведёт график и в старой, и в новой системе — это лишняя нагрузка, но она защищает от потери нарядов, если в новой системе всплывёт баг.
3. Сбор обратной связи от бригадиров. Их интересует не архитектура, а то, насколько быстро открывается список объектов на медленном мобильном интернете и насколько понятны статусы — это тот фидбэк, который реально нужен на этом этапе.
4. Постепенное расширение. После устранения явных проблем — перевод следующих 10 бригад, потом оставшихся. Полный переход растягивается на месяц-полтора, и это нормально для системы, от которой зависит ежедневная работа.
5. Отказ от старой подписки только после полного перехода. Не разрывайте договор со сторонним сервисом, пока последняя бригада не отработала на новой системе минимум пару недель без сбоев — параллельная оплата на переходный период дешевле, чем риск сорванного графика по всему городу.

Отдельно стоит заранее продумать план на случай отказа сервера — короткая инструкция «что делать диспетчеру, если график недоступен» (резервная выгрузка нарядов на день в PDF или таблицу, отправленная накануне вечером) снимает панику при редких, но возможных сбоях.

Частые вопросы