Статусы заказа как часть сервиса

Статус становится частью сервиса, когда он обозначает реальное событие, а не желание сотрудника успокоить гостя. «Готов» означает, что заказ действительно можно выдавать. «Готовится» означает, что приготовление началось. Если слова расходятся с действиями, экран только усиливает недоверие.

Ниже — словарь для смены и гостя. Он не задаёт универсальных минут: время реакции зависит от формата заведения, состава заказа и нагрузки. Его задача — синхронизировать смысл переходов.

Если читать 30 секунд

• Каждый статус меняют после наблюдаемого события, а не заранее.
• Сотрудник следующего этапа должен понимать, что именно ему передали.
• «Ожидает оплаты» используется только в сценарии предоплаты; приготовление нельзя начинать до успешного платежа.
• Гостевая ссылка показывает состояние, но не исправляет забытый переход.
• Роли, допустимые действия и исключения нужно прогнать на контрольном заказе до открытия.

Словарь «статус → событие → роль → обещание»

В «Умном кафе» заказ без обязательной предоплаты создаётся как «Новый», затем проходит подтверждение, приготовление, готовность, выдачу и закрытие. При онлайн-оплате до приготовления заказ может быть создан сразу как «Ожидает оплаты»: это начальное состояние, а не обязательный переход после «Нового» на экране гостя.

Статус	Наблюдаемое событие	Кто меняет по регламенту точки	Что понимает гость
Новый	Заказ создан и попал в контур точки	Дежурный ещё не принял	«Заказ получен системой и ждёт решения смены»
Ожидает оплаты	Для заказа требуется успешная предоплата	Платёжный сценарий и дежурный контролируют результат	«До оплаты приготовление не начнётся»
Принят	Смена проверила состав, стол, комментарий и возможность исполнения	Дежурный по приёму	«Заведение взяло заказ в работу»
Готовится	Кухня или бар фактически начали приготовление	Ответственный станции	«Заказ сейчас готовят»
Готов	Все позиции собраны и доступны для выдачи	Ответственный за сборку или кухню	«Можно ждать выдачу или подходить по правилам точки»
Выдан	Заказ передан гостю либо завершена доставка	Сотрудник выдачи или доставки	«Заказ получен»
Закрыт	После выдачи не осталось операционных действий	Администратор либо принятый процесс	«Жизненный цикл завершён»
Отменен	Смена или платёжный сценарий прекратили исполнение	Роль с правом отмены	«Заказ не будет приготовлен или выдан»

Технические коды этих состояний: new, awaiting_payment, confirmed, in_progress, ready, delivered, closed и cancelled. Русские названия в таблице совпадают со смыслом рабочего интерфейса; код нужен только при точной проверке переходов.

В публичном демо можно увидеть гостевой экран и автоматическую последовательность статусов тестового заказа. Эта проверка помогает прочитать последнюю колонку словаря, но не показывает права сотрудников, ручные переходы или работу реальной точки.

Колонка роли — не автоматическое назначение продукта. Заведение само решает, кто нажимает действие. Важно закрепить владельца этапа: иначе повар считает, что «Готов» ставит выдача, а выдача ждёт повара.

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

Переход выполняется только вперёд по реальному событию

Точная карта разрешённых переходов в сервисе выглядит так:

• new → awaiting_payment, confirmed или cancelled;
• awaiting_payment → confirmed или cancelled;
• confirmed → in_progress или cancelled;
• in_progress → ready или cancelled;
• ready → delivered или cancelled;
• delivered → closed.

Разрешённый переход new → awaiting_payment остаётся частью конечного автомата, но типичный заказ с обязательной предоплатой создаётся сразу в awaiting_payment. Поэтому не следует описывать ожидание оплаты как неизбежный второй шаг каждого нового заказа.

Повторное нажатие того же статуса обрабатывается как безопасное отсутствие изменения. Это помогает при повторном нажатии кнопки или запросе. Но перескочить из «Нового» сразу в «Готов» нельзя: система отклонит неверный переход.

Предоплата добавляет отдельные ограничения. Если точка принимает онлайн-оплату до приготовления, заказ нельзя подтвердить и перевести в работу до успешного платежа. Если включён запрет выдачи до оплаты, статус «Выдан» также блокируется без подтверждённого платежа.

Эти проверки защищают последовательность, но не знают реальную кухню. Сервер не видит, поставил ли повар блюдо на пасс. Человек должен менять статус после факта, а не для ускорения красивой цепочки.

Где заканчивается ответственность каждого этапа

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

Кухня или бар начинает этап «Готовится» после фактического старта. Если заказ распределён по станциям, заранее определите, кто собирает общий результат. Иначе одна готовая позиция преждевременно переведёт весь заказ дальше.

Сборка или выдача ставит «Готов» только после проверки комплекта. Стакан на стойке без десерта не делает весь заказ готовым. «Выдан» появляется после передачи гостю, а не когда сотрудник только позвал номер.

Администратор разбирает отмены и закрывает завершённые заказы по принятому порядку. Отмена требует объяснения гостю вне самого короткого ярлыка: статус сообщает итог, но не причину.

При большом числе карточек роли удобнее применять через трёхпроходный разбор очереди. Очередь определяет, на что смотреть сейчас; статус фиксирует уже произошедшее событие.

Почему ранний статус хуже позднего

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

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

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

Контрольный заказ для согласования словаря

Перед открытием проведите один заказ от создания до закрытия. На каждом переходе сотрудник должен вслух назвать событие, которое уже произошло.

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

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

Для проверки действий в мессенджере пригодится регламент уведомлений Telegram и MAX. Сообщение может содержать кнопку следующего статуса, но нажимать её следует только после события из словаря.

Как разбирать зависший этап

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

Симптом	Вопрос смене	Исправление
Много новых карточек	Кто обязан принять или отменить?	Назначить дежурного и резерв
Долго «Готовится»	Кто собирает общий заказ?	Назвать владельца комплекта
«Готов», но не выдан	Где происходит передача гостю?	Закрепить роль выдачи
«Выдан», но не закрыт	Нужен ли отдельный контроль после выдачи?	Добавить закрытие в пересменку
Отмена без объяснения	Кто связывается с гостем?	Описать канал и причину

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

Сервис начинается с совпадения слов и действий

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

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