Frictionless self-check-in agent

A self-check-in agent is allowed to assemble a proposed check-in. It is not allowed to mark the guest as in-house, and it is not allowed to encode or release a room key. The quality bar is narrow: the proposal must cite ID verification, payment capture, and the assigned room. If any of those three cites is absent, the draft stays empty. A front-office manager still confirms check-in and key issuance.

That split matters on a busy arrival evening. A kiosk or arrival tablet can collect documents and a payment method. Guest-facing arrival tools and property systems in this class include Canary, Agilysys, Oracle Hospitality, and Mews. Use the system your property already runs as the source for the reservation, the payment record, and the room assignment. The agent reads those records and proposes a stay a person can accept. It never treats its own draft as the completed check-in.

Staff confirmation is not a courtesy step. ID documents can fail to match the reservation name. A card can authorize and then decline on capture. A room can sit in assigned status while housekeeping has not released it. The desk is the last place those conflicts are resolved before a key goes to the guest.

Start with the arrival reservation, not with a blank stay. Pull the booking from the PMS for today's arrivals so the agent works against a real confirmation number, stay dates, guest count, and rate plan. If the booking itself is incomplete, stop and send it to incomplete reservation flagging instead of inventing missing stay details.

Attach the ID cite next. The cite is a verification result tied to the reservation, not a photo sitting in a folder. Typical sources are a kiosk scan, a desk scan, or an upstream id document OCR parser that returns a match or mismatch against the name on the booking. Record which document type was used, whether the name matches the booking, and whether verification passed. Do not paste raw document images into the proposal. Cite the verification record.

Attach the payment cite second. Capture means an authorization or deposit actually posted against this reservation, not a card number typed into a chat. Cite the token or last four digits on file, whether a hold posted if house policy requires one, and the timestamp of that posting. If the guest is on a travel-agent or corporate guarantee, cite that guarantee only when the PMS already stores it.

Attach the room cite last. The assigned room must come from inventory: a room number the PMS has already allocated to this reservation, in a ready status your house uses (vacant and inspected, or the equivalent). Do not pick a room because it is next to a preference, and do not type a number from memory. If the guest needs an accessible room or another arrival accommodation, route that through the accessibility need trigger so the assignment is a recorded inventory decision, not a free-text note.

Once all three cites are present, the agent may fill the proposal: reservation identity, ID verification result, payment capture result, and assigned room. That is the entire quality output. A welcome line belongs in a separate personalized welcome message generator after the stay is actually opened. A queue wait time predictor can help staff decide whether the next arrival should use the kiosk. It is not part of the check-in draft.

Illustrative example: a guest is already on tonight's arrivals list. The kiosk returns a passed ID verification against the booking name. The PMS shows a successful authorization on the card on file. Housekeeping status on the assigned room is ready. The agent writes a proposed check-in that names those three records. The front-office manager opens the proposal, compares it with the PMS screens, confirms check-in, then encodes the key. If the ID step had failed, the same agent would have left the proposal empty.

Empty is a valid, preferred output. Do not write a partial check-in that looks complete. A proposal with two strong cites and a blank room is worse than a blank proposal, because the next person may assume the room is implied.

If ID verification did not run, or ran and failed, leave the proposal empty and surface the gap to the desk. Walk-up guests, expired documents, and name mismatches all belong here. The agent does not produce a half-complete check-in.

If payment did not capture or authorize per house policy, leave the proposal empty. Do not borrow a card from a companion's other reservation. Do not treat a verbal promise to pay at checkout as a cite unless the PMS already records that exception as a valid guarantee.

If no room is assigned in inventory, or the assigned room is not ready, leave the proposal empty. A preference for a high floor is not an assignment. A room number remembered from a previous stay is not an assignment.

When the proposal is empty, the front-office manager still owns the arrival. They can send the guest back to ID capture, retry payment, wait for housekeeping, or complete a traditional desk check-in. The agent does not fill gaps with guesses so the kiosk can keep moving.

The front-office manager, or the supervisor covering the desk, is the only role that turns a proposal into a stay. Open the PMS check-in action on the same reservation the agent loaded. Verify the three cites on the native screens: ID status, payment or guarantee, assigned room, and ready status. Then confirm check-in in that system.

Issue the key only after that confirmation. Encoding a key from the proposal screen, or from a kiosk that assumed success, skips the control this page exists to protect. Keep key issuance on the confirmed stay record in the same property system you already use for keys, whether that stack is Canary, Agilysys, Oracle Hospitality, Mews, or another system in that class.

Do not auto-check-in. Do not auto-issue a key. Those two automations collapse ID, payment, and inventory errors into a guest who is already in a room. The agent stops at the proposal. Staff start at confirmation.

If the manager rejects the proposal, leave the reservation in pre-arrival status. Log the reason with other desk exceptions so the next attempt can attach a corrected cite instead of reusing a failed one.

Three failure modes show up when teams treat speed as quality.

A check-in with no ID cite is the first. The payment posted and a room is assigned, so the draft looks ready. Without a verification record, you cannot show who stood at the kiosk. Do not complete the proposal. Do not let the kiosk present a key. Send the guest to ID capture or to the desk.

Treating the draft as checked in is the second. Someone sees a filled proposal and updates the room rack, the housekeeping board, or a welcome text as if the stay were open. Folio postings and door access then disagree with the PMS. Train the desk to ignore any stay state that did not come from the PMS check-in action. The proposal is a checklist, not a status change.

Inventing a room number is the third. The agent, or a rushed operator, types a vacant-looking room because the assigned room is still dirty, or because the guest asked for a number they liked. That number is not a cite. It is a conflict with inventory, with in-house guests, and with housekeeping. If the PMS has not assigned a ready room, the proposal stays empty until it has.

Cites are also per reservation and per arrival date. Do not copy yesterday's ID, payment, or room records onto tonight's arrival because the name looks the same. Reload the arrival, attach today's records, and leave blanks when any of those records is missing.