Express checkout orchestrator

An express checkout orchestrator prepares a departure the guest never has to stand at the desk for. It does not complete that departure. Quality here is a proposed checkout that cites the guest folio and cites payment capture. If either cite is missing, the proposal stays empty. A front-office manager still confirms checkout and still confirms key release. Do not auto-checkout. Do not auto-release the key.

The guest sees speed: the folio arrives by message, payment closes, the door credential dies, housekeeping can enter. The desk sees a draft, not a finished stay. Property management and guest-journey systems in this class (Canary, Mews, Oracle Hospitality, Agilysys) already hold the stay record, the folio lines, the authorization or settlement, and the lock state. The agent reads those records and writes something a person can accept or reject. Accepting is checkout. The draft is not.

A guest who used a frictionless self-check-in agent on arrival still needs that human close on the way out. Fast in does not authorize unsupervised out.

Start from the reservation that is due to leave. Do not start from a prompt that only says check this guest out.

Load the stay: confirmation or reservation ID, room, departure date, in-house status, and whether the guest asked for express or remote checkout. If the PMS already shows checked out, stop. There is nothing to propose.

Load the folio: folio ID, balance, posted charges, pending charges, tax, incidentals, open packages, and whether outlet posting is still live. Breakfast, minibar, parking, and spa tickets often land after the guest has left the building. An in-house folio that is still receiving those postings is not ready.

Attach a payment cite: the authorization, capture, or settlement identifier already stored against that folio in the PMS or payment gateway. Copy it from the system of record. Do not invent a last-four, a batch ID, or a paid-in-full line because the balance looks like zero.

A cite a manager can verify is a folio number they can open and a capture or settlement ID they can open on the same stay. If those two records do not open, the proposal is not ready.

If a charge is disputed, do not propose checkout. Send the folio to the folio dispute classifier and wait. A disputed line is not a settled account.

Write the proposal only when stay identity, folio identity with balance, and payment capture cite all exist. Phrase it as a request:

Propose checkout for reservation 48291, room 714, folio F-714-0901, balance 0.00, capture AUTH-19C4 posted against that folio. Confirm checkout. Confirm key deactivate.

Leave every field you cannot cite blank. Do not fill gaps from a similar stay, from a shared card token, or from what the guest typed in chat.

Which product holds the record does not change the sequence. Digital folio and messaging may live in Canary. The PMS may be Mews, Oracle Hospitality, or Agilysys. The orchestrator does not rank those tools. It requires a cited stay, a cited folio, and a cited payment from whichever of them is the system of record on that property.

A checkout with no folio cite is a name and a room. Names collide, rooms get moved, and posting windows stay open after the taxi is called. If the agent cannot point at the folio document, it writes no proposal and reports the gap: stay loaded, folio cite missing, do not checkout.

A missing payment cite is the other hard stop. A zero balance can mean a capture already posted, a manager adjustment, a hold that has not captured, or a night audit that has not rolled. Zero is not a capture. Do not invent a payment. Do not copy a capture from another stay that happens to share a card on file. Leave the proposal empty and say so: folio F-714-0901 has no capture cite, do not checkout.

The third failure is treating the draft as checked out. Housekeeping is told the room is vacant while the lock still holds the guest credential. Or the guest gets a you-have-checked-out note while they are still in the corridor. The draft looked complete, so staff skipped confirmation. That skip produces occupied-clean conflicts, walk-backs through a live key, and folios that keep taking charges after the team thought the stay was closed.

If the hour is still in play, late checkout, delayed flight, early car, settle timing with the departure time optimizer before you assemble a checkout proposal. A confirmed checkout at the wrong hour is still a bad checkout.

The front-office manager, or the duty manager covering the desk, is the person who changes stay status.

They open the proposal. They match the folio cite to the PMS folio. They match the payment cite to the settlement or authorization record. They look for pending outlet postings that landed after the agent loaded the folio. Then they confirm checkout.

Only after that confirmation do they confirm key release: deactivate the credential in the lock system, set the room to dirty or inspect, and let housekeeping see vacancy.

Keep the confirms separate. Checkout first. Key release second. Do not reverse them. Do not collapse them into a single already-done flag. If capture fails between the two, the guest is still in-house until a person decides otherwise. If the guest is still on property with luggage, keep the key live until checkout is actually confirmed.

Downstream communication waits. A personalized farewell message generator can send the folio copy and a goodbye after checkout is confirmed. Sending that note against an unconfirmed draft is another way of treating the draft as done.

Do not let runners, housekeeping boards, or chat macros infer vacancy from a draft in a queue. Vacancy is a confirmed checkout plus a confirmed key release. Anything earlier is an occupied stay with a suggested next action.

Room 714, Saturday. The guest messages that the keys are on the desk and they want express checkout. Run the orchestrator. Do not change the stay yet.

The agent loads stay 48291: in-house, room 714, departure today. It loads folio F-714-0901. Breakfast for two is still pending from the restaurant, posted after the guest walked out. There is an authorization hold from check-in, not a capture, because the pending breakfast has not settled.

The correct proposal is empty. The agent reports stay loaded, folio loaded, breakfast pending, no capture cite. It does not invent a capture from the original authorization. It does not mark 714 vacant. It does not send housekeeping. It does not tell the guest they have checked out.

The duty manager sees the gap, waits for the outlet posting, captures against the updated folio, then reviews a new proposal that cites F-714-0901 and the new capture ID. They confirm checkout. They then confirm key deactivate. Housekeeping gets the room after both confirms.

If breakfast had already posted and the capture cite was already on the folio, the first proposal would have been usable: stay, folio, payment cite, still waiting on the same two human confirms. The guest never visited the desk either way. The difference is whether the account actually closed.

Load the stay and the folio. Attach a payment cite from the system of record. Leave blanks when a cite is missing. Let a front-office manager confirm checkout. Let them confirm key release. Never treat the draft as the departure.