Cafe order handoff mapКарта передачи заказа в кафе
A prepared drink does not mean a cafe order is ready to serve. This map identifies who assembles station results, who acknowledges a revision and how an outstanding item remains visible after partial service.В кафе приготовленный напиток не означает готовый к подаче заказ. Эта карта определяет, кто соединяет результаты разных станций, кто подтверждает изменение и как незавершённая позиция остаётся видимой после частичной подачи.
The ticket connects station workЗаказ объединяет работу станций
The server owns the guest promise: items, service method and accepted changes. Each station owns its items and actual preparation state. The runner receives the whole order with visible parts rather than disconnected “ready” messages.Официант ведёт обещание гостю: состав, способ подачи и принятые изменения. Каждая станция отвечает только за свои позиции и фактическое состояние приготовления. Сотрудник подачи получает общий заказ с видимыми частями, а не несколько несвязанных сообщений «готово».
Distinguish submission to a station, station acceptance, readiness and service to the guest. They are different events with different owners. If staged service is allowed, define who agrees it with the guest and where the outstanding-item list remains.Отделите отправку на станцию, принятие станцией, готовность и подачу гостю. Это разные события с разными ответственными. Если порядок допускает подачу частями, укажите, кто согласует её с гостем и где остаётся список ожидаемых позиций.
Handoffs within one orderПередачи по одному заказу
This map assumes an explicit link between each item and its order. A transition is permitted after the fact is recorded and the next role accepts it. This is a process design; automatic routing or station displays in SABSUS require separate verification.Карта предполагает явную связь каждой позиции с исходным заказом. Переход разрешён после записи факта и принятия следующей роли. Это проект рабочего порядка; наличие автоматического маршрута или экрана станции в SABSUS требует отдельной проверки.
Guest order acceptedЗаказ принят у гостя
- Responsible roleОтветственный
- Server → stationsОфициант → станции
- Record / dataЗапись / данные
- Order, items, service method and sequenceЗаказ, позиции, способ и последовательность подачи
- Permitted next stepРазрешённый следующий шаг
- Accept items for preparationПринять позиции в исполнение
- Exception / recoveryИсключение / восстановление
- Unclear revision: return clarification to the serverНеясное изменение: вернуть уточнение официанту
Station finished an itemСтанция закончила позицию
- Responsible roleОтветственный
- Station → runnerСтанция → подача
- Record / dataЗапись / данные
- Item, version, actual readinessПозиция, версия, факт готовности
- Permitted next stepРазрешённый следующий шаг
- Assemble the permitted portion of the orderСобрать разрешённую часть заказа
- Exception / recoveryИсключение / восстановление
- Another part unfinished: retain its waiting stateДругая часть не готова: сохранить её ожидание
Revision authorizedИзменение разрешено
- Responsible roleОтветственный
- Server → station and runnerОфициант → станция и подача
- Record / dataЗапись / данные
- Revised version and original-item dispositionНовая версия и решение по старой позиции
- Permitted next stepРазрешённый следующий шаг
- Continue after recipients acknowledgeПродолжить после подтверждения получателей
- Exception / recoveryИсключение / восстановление
- No acknowledgment: owner checks receiptНет подтверждения: владелец проверяет получение
Items delivered to the guestПозиции переданы гостю
- Responsible roleОтветственный
- Runner → order ownerПодача → владелец заказа
- Record / dataЗапись / данные
- Actually served items and outstanding itemsФактически поданные позиции и остаток
- Permitted next stepРазрешённый следующий шаг
- Close fulfilment for delivered itemsЗакрыть исполнение принятых позиций
- Exception / recoveryИсключение / восстановление
- Remake: open a linked taskПеределка: открыть связанную задачу
Cancellation after preparation startsОтмена после начала приготовления
Hypothetical example: a table orders drinks and a pastry, then declines the pastry while the bar is preparing the drinks. The server records a revision request for that item. Its station owner confirms whether work can stop and what has already happened.Условный пример: к столу заказаны напитки и выпечка, но гость отказывается от выпечки, когда бар уже готовит напитки. Официант оформляет запрос на изменение конкретной позиции. Ответственный за эту позицию подтверждает, можно ли остановить её исполнение и что уже фактически сделано.
After the authorized decision, the server passes the accepted revision to the runner and affected station. The runner acknowledges assembly against that version. An old paper mark or verbal instruction should not simultaneously govern the same order without reconciliation.После решения уполномоченного сотрудника официант передаёт принятую версию подаче и затронутой станции. Подача подтверждает, что собирает заказ по новой версии. Старая бумажная отметка или устное указание не должны одновременно управлять тем же заказом без сверки.
Partial service and missing acknowledgmentЧастичная подача и потерянное подтверждение
If drinks are served before food, the service record closes only those delivered items. The remainder retains its station, guest-contact owner and next expected event. A blanket “served” marker hides the outstanding promise and makes shift handover harder.Если напитки поданы раньше еды, запись подачи закрывает только переданные позиции. Оставшаяся часть сохраняет станцию, владельца связи с гостем и следующее ожидаемое событие. Общая отметка «подано» без такого различия скрывает невыполненное обещание и мешает следующей смене.
When a station has not acknowledged a revision, the server checks receipt before promising the new outcome. A damaged or remade item retains its original reference, reason and replacement task. Financial treatment and actual consumption are resolved separately under the cafe’s rules.Когда станция не подтвердила изменение, официант проверяет его получение до обещания нового результата. Если приготовленная позиция испорчена или переделана, фиксируются исходная позиция, причина и новая задача. Финансовое решение и фактический расход разбирают отдельно по правилам кафе.
Review before ticket closureПроверка перед закрытием заказа
The order owner reconciles served items, authorized cancellations, open remakes and confirmed settlement. A missing item needs a resolution rather than disappearing from the list. When another server takes over the table, retain open promises and the latest accepted version.Владелец заказа сверяет поданные позиции, разрешённые отмены, открытые переделки и подтверждённый расчёт. Отсутствующая позиция должна иметь решение, а не просто исчезнуть из списка. При передаче стола другому официанту сохраняются все открытые обещания и последняя принятая версия.
Agree this procedure with the team before mapping it into a SABSUS configuration. Check change permissions and visibility of incomplete orders for actual work roles without assuming automation. The process can be configured independently; current platform terms are on the pricing page.Согласуйте этот порядок с командой до переноса в конфигурацию SABSUS. Проверьте права изменения и видимость неполного заказа на реальных рабочих ролях без предположений об автоматике. Настроить процесс можно самостоятельно; действующие условия платформы вынесены на страницу тарифов.
Quick answersКороткие ответы
Who decides to serve an order in stages?Кто решает подавать заказ частями?
The designated service owner, under cafe procedure and the guest agreement. A single station reporting readiness does not itself make that decision.Назначенный владелец обслуживания по согласованному порядку кафе и договорённости с гостем. Готовность отдельной станции сама по себе не является таким решением.
Should a cancelled item be deleted?Удалять отменённую позицию?
Retain its order link, reason and authorized resolution in accessible history. Otherwise an unsent item becomes indistinguishable from one prepared and then cancelled.Сохраняйте её связь с заказом, причину и разрешённое решение в доступной истории. Иначе невозможно отличить неотправленную позицию от уже приготовленной и отменённой.
What if staff have two brief versions?Что делать при двух версиях задания?
The order owner pauses the disputed handoff, identifies the effective accepted version and obtains acknowledgment from affected roles. Do not ask a station to guess the latest guest promise.Владелец заказа останавливает спорную передачу, определяет действующую принятую версию и получает подтверждение затронутых ролей. Не просите станцию самостоятельно угадывать последнее обещание гостю.