Расписание клининга: дорога, доступ и загрузка бригад

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

Возьмём условный пример. Первая уборка планируется с 09:00 до 12:00. Передача результата и сбор оборудования занимают ещё 20 минут, оценка дороги — 40 минут, допуск на втором объекте — 10 минут. Без дополнительного запаса готовность начать вторую работу получается в 13:10. Заказ на 12:30 не становится выполнимым только потому, что предыдущая запись календаря заканчивается в полдень. Все числа учебные: реальные интервалы нужно получать из данных вашей команды и конкретного маршрута.

У заказа и бригады разные интервалы

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

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

Длительность работы должна относиться к конкретному составу команды и согласованному объёму. Оценка для трёх исполнителей не превращается автоматически в ту же оценку для двух. Не задавайте линейное правило без проверки: отдельные операции нельзя ускорить простым добавлением людей, а оснащение может стать ограничением. В карточке полезно хранить основание плановой длительности и изменения состава, влияющие на возможность выполнить обещанное время.

Дорога — оценка с условиями, а не постоянное свойство адреса

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

Храните ожидаемое время пути как плановую оценку с источником, а не как гарантированное обещание клиенту. Диспетчер должен видеть неопределённость и правила её обработки. Запас выбирают по наблюдениям компании: тип района, условия парковки, характер услуг и допустимость опоздания. Не существует одного числа минут, подходящего всем бригадам. Если измерений пока нет, начните с явного допущения и его последующей проверки вместо скрытого нулевого интервала.

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

Допуск на объект храните как рабочее условие

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

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

Изменение первого заказа затрагивает последующие

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

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

План и факт нельзя складывать без обозначений

Для анализа опоздания определите, какое событие сравниваете с обещанием: прибытие к зданию или готовность приступить внутри помещения. Это не всегда одна минута. Если команда приехала вовремя, но ждала представителя, запись должна объяснять ожидание, а не автоматически назначать виновного. Отчёт нужен для изменения процесса, поэтому отдельно храните наблюдаемое событие и причину, подтверждённую ответственным. Не превращайте предположение диспетчера в установленный факт. За один период могут измениться объём работ, условия доступа и маршрут; сравнение без этих условий будет вводить руководителя в заблуждение.

Как принять календарь в новой CRM

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

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

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