Задача
Задачи в отеле не существуют по отдельности — они выстроены в цепочку и упираются в состояние номера. После выезда номер нужно убрать, проверить и вернуть в продажу. Найденная при уборке неисправность должна дойти до техника, а не остаться в голове горничной. Запрос гостя на дополнительное полотенце — до ближайшей свободной горничной на этаже.
Без единой системы всё это живёт в звонках, бумажных листах и разрозненных чатах. Руководитель не видит реальную загрузку смены. Ресепшен не знает, когда номер станет готов, и отвечает гостю «скоро». Гость обращается по одному и тому же вопросу второй раз. А если исполнитель не успевает, задача не эскалируется — она просто теряется.
Отелю был нужен единый источник правды: что требуется сделать, кто отвечает, к какому сроку, что мешает исполнителю, какие номера готовы к заселению и где нарушается SLA.
Решение
Четыре источника задач. Задача появляется из события PMS, обращения гостя, ручного поручения менеджера или расписания. Интеграция слушает жизненный цикл проживания: планируемый и фактический check-out, early check-in, смену статуса номера, продление, переселение, установку DND, блокировку номера и возврат его в продажу. К выезду система заранее создаёт задачу на уборку с требуемым временем готовности. Регламентные работы — обходы, профилактика кондиционеров, deep cleaning, подготовка залов к мероприятию — создаются по календарю или счётчику.
Диспетчеризация в два шага. Сначала dispatch engine отсекает всех, кто не может взять работу: не то подразделение, нет квалификации или допуска, смена не активна, зона или этаж закрыты, нет доступа к номеру, нет нужного оборудования, висит конфликтующая критичная задача. Оставшихся система ранжирует: расстояние до объекта, текущая и прогнозная загрузка, приоритет и остаток SLA, последовательность маршрута по этажу, специализация, справедливость распределения, история работы с этим номером, время до конца смены. Результат — рекомендация с причиной, а не вердикт чёрного ящика. После отказа, просрочки, окончания смены или появления более срочной работы очередь пересчитывается.
Готовность номера. Уборка — не изолированный тикет, а часть сквозного статуса: Occupied → Due out → Dirty → Cleaning → Clean → Inspection → Ready, с ответвлением в Maintenance и Out of order. Под сценарии свои шаблоны: stayover, checkout cleaning, turndown, deep cleaning, смена белья, уборка общественной зоны. Супервайзер получает очередь инспекций, фиксирует замечания и возвращает работу на доработку; после подтверждения статус номера уходит обратно в PMS, и ресепшен видит готовность без звонка в службу.
Неисправность как наряд. Сообщение о неработающем кондиционере превращается в work order с номером комнаты, категорией HVAC, срочностью и историей оборудования. Техник получает паспорт устройства, историю ремонтов, чек-лист диагностики, список требуемых деталей, инструкции по безопасности и возможность списать запчасть. Если номер нельзя безопасно использовать, задача сама переводит его в Out of order и уведомляет front office.
Связанные задачи. Сложная заявка распадается на цепочку. Переселение гостя запускает подготовку нового номера, доставку багажа, изменение доступа и проверку исходного номера — и всё это остаётся одним кейсом. Повторное обращение гостя по той же проблеме не создаёт новую несвязанную заявку, а продолжает существующую с повышенным приоритетом.
Мобильное место и работа без сети. У сотрудника — очередь на смену, следующая рекомендованная задача, маршрут по этажам, чек-листы, фото до и после, голосовая заметка, сканирование QR-кода номера или оборудования, запрос помощи и фиксация блокирующей причины. Offline-first клиент работает в служебных помещениях и зонах без связи: действия пишутся локально и синхронизируются позже с защитой от дублей и конфликтов.
SLA до нарушения, а не после. Для категории задаются время принятия, время первого действия, целевой срок, допустимые часы выполнения, правила напоминаний и уровни эскалации. Система предупреждает о риске просрочки, а не только фиксирует случившуюся: при отсутствии реакции задача переназначается или поднимается к руководителю подразделения и duty manager.
Результат
Отель получил одну очередь работ вместо звонков и разрозненных чатов. Задача доходит до конкретного человека с дедлайном и чек-листом, а не растворяется между сменами.
Ресепшен отвечает гостю по факту, а не «примерно»: видит прогноз готовности номера и статус обращения — Requested, On the way, Completed. Горничная идёт по маршруту, а не по списку из головы супервайзера. Техник приезжает с паспортом оборудования и историей ремонтов. Супервайзер разбирает не жалобы постфактум, а очередь инспекций с фотографиями и замечаниями.
Руководителю стало видно то, чего раньше не было видно совсем: время от check-out до Ready, доля повторных обращений, first-time-fix rate, причины блокировок, перегруженные подразделения и backlog по этажам. Ручной диспетчеризации стало меньше, но чёрным ящиком система не стала: менеджер вмешивается, платформа сохраняет причину override и сразу пересчитывает остальные очереди.
Контур рассчитан на несколько отелей одной управляющей компании: общие шаблоны и нормативы наследуются на объекты, а команды, этажи, категории номеров и локальные правила остаются независимыми — сеть видит сводную картину, не смешивая операционные очереди.