AI Adoption GuideHospitalityArrive
Accessibility need trigger
Classifier detects accessibility-related flags in the guest profile and auto-routes room assignment to compliant inventory.
Hospitality processBookConfirmPrepareArriveStayDepartReviewReturn
By Don, DoneThat’s AI coach · updated
Route the assignment queue, not the room
The accessibility need trigger produces a routing flag, not a room number. It detects an accessibility-related value on the guest profile and moves that arrival into the assignment path used for compliant inventory. A front-office manager still chooses the room.
Auto-assigning from this flag is the first way the workflow fails. The flag means assign from the accessible or otherwise compliant stock, not that this reservation is already in 108. Treating the flag as assigned leaves the board looking complete while the guest has no room, or it parks them in a standard room because the last click happened in the wrong queue.
The source of truth is the profile field, not a guess about what the building contains. Oracle Hospitality, Mews, Cloudbeds, and Canary sit in the same class of property and guest systems. The trigger reads the accessibility field the hotel already maintains on the guest or reservation profile. It does not require a vendor-specific assignment engine, it does not rank those products, and it does not assume any of them can pick the room for you.
This is a quality outcome: the flag is only as good as the cite. If the profile field is empty, the routing flag stays empty.
Load the profile and cite the accessibility field
Load the guest profile attached to the reservation before you write any flag. Open the record the property already uses for returning guests and special requests. Read the accessibility, mobility, or equivalent field as the PMS stores it. Do not start in free-text booking notes, and do not start from an ID scan.
If that field contains an accessibility-related value, emit a routing flag that cites the field by name and restates the stored value. A usable cite looks like: profile accessibility field equals wheelchair-accessible room required. An unusable flag says accessible with no field name and no stored value. A flag with no profile cite is a failure mode. Desk staff cannot tell whether the classifier inferred a need from a comment, from an ID photo, or from nothing.
Keep booking notes in their own lane. Preference extraction from booking notes can surface quiet floor or high floor from comments. Those preferences are not a substitute cite for this trigger. If the notes mention a wheelchair and the profile field is blank, do not invent the accessibility flag from the note. Either a human updates the profile field, or the routing flag stays empty.
The same separation applies to arrival documents. An ID document OCR parser confirms identity. It does not encode mobility needs. Do not let an ID image become an accessibility cite.
Run the load-and-cite step the same way on every arrival:
- Open the reservation and load the linked guest profile.
- Read only the accessibility-related profile field the property already maintains.
- If the field is populated with an accessibility need, write a routing flag that names that field and restates the value.
- If the field is blank, write nothing. Do not backfill from notes, IDs, or a list of rooms the building happens to have.
- Place the flagged reservation in the compliant-inventory assignment queue. Do not write a room number.
Leave the flag blank when the field is silent
Empty stays empty. A silent accessibility field means the classifier has no quality signal. The correct output is no routing flag, not a guessed wheelchair room, not a roll-in shower, and not a probable accessible need.
Inventing a roll-in shower is a specific, common overreach. Properties mix tub-with-grab-bars rooms, roll-in shower rooms, and rooms that are only closer to the elevator. The profile field did not say which of those the guest needs if it said nothing at all. Filling roll-in shower because that room type is scarce and high-stakes creates a wrong assignment and blocks an accessible room that a guest who actually needs it cannot use.
When the field is silent, assignment follows the ordinary room-assignment path. The front-office manager is free to ask the guest at check-in. That conversation can update the profile for the next stay. The trigger does not pre-answer it.
Do not treat a blank as no accessibility need forever. It means the stored field did not authorize a routing flag on this stay. A walk-in who mentions a wheelchair at the desk is a human update to the profile, then a flag on a later stay once the field holds a value.
Finish assignment at the desk
After the flag lands, the front-office manager assigns from compliant inventory. Compliant inventory is the set of rooms the property has already classified as meeting the need the profile field described. The manager still matches date, occupancy, out-of-order status, connecting rooms, and the rest of the board.
Here is one illustrative walk-through, not a measured case. A returning guest arrives on a Tuesday with the profile accessibility field set to wheelchair-accessible room. The trigger writes a routing flag that cites that field and that value, and it places the reservation in the accessible-assignment queue. Three rooms in that queue are sellable tonight. The manager assigns 108 because 110 is marked out of order and 312 is held for a connecting stay. The classifier never wrote 108. If the same guest's profile field had been blank, the queue would not have received a flag, and 108 would not have been reserved on a guess.
Self-check-in must not collapse this step. A frictionless self-check-in agent can collect keys and payment once a human has assigned the room. It should not treat the accessibility routing flag as permission to pick inventory. Auto-assigning at the kiosk is the same failure as auto-assigning in the PMS: the flag was a queue, not a room.
Room setup is a later, different job. Guest preference-based room setup covers pillows, extra towels, and similar in-room requests after the room exists. Accessibility inventory is chosen first. Do not satisfy a mobility flag by adding a shower chair to a standard room and calling the stay assigned.
Failure modes that invent rooms or skip the cite
Three failure modes belong in the runbook next to the happy path.
A flag with no profile cite. The desk sees accessible and cannot audit why. Staff then either ignore the flag or over-comply by blocking scarce rooms. Require the field name and the stored value on every flag. If the cite cannot be produced, drop the flag.
Treating the flag as assigned. The reservation shows as placed when only the queue changed. Night audit, occupancy, and the arriving guest all disagree with the board. Keep assignment state separate from routing state. Assigned means a room number a manager chose.
Inventing a roll-in shower, a wheelchair room, or any specific fixture the profile did not state. The trigger may only restate what the field said. Accessible room required routes to the property's accessible stock. It does not upgrade the need to roll-in shower, hearing-accessible kit, or ground floor unless that is what the field contains.
Run the loop the same way every arrival: load the profile, flag only with a cite, leave blanks blank, and let the front-office manager assign from compliant inventory.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first