Minibar charges with AI, without double charges: a reviewed workflow for ASA HOTEL

Why charges are where AI must be careful

Answering “who arrives today?” incorrectly is annoying. Charging the wrong guest, or the right guest twice, is a complaint, a refund and a bad review.

Room charges are a perfect example of work AI can speed up, as long as the process is designed for mistakes. This article shows how Steward handles minibar charges in ASA HOTEL, and why each safety step exists.

The workflow in four steps

1. Housekeeping reports what was taken

A room attendant or the minibar team reports consumption as a short list:

Room 312: 2 × still water, 1 × peanuts. Room 418: 1 × white wine.

2. Steward identifies the right guest and prepares the charges

Someone with Write access asks Steward in the minibar project:

Prepare minibar charges: room 312, two still water (article 1001, €3.50 each) and one peanuts (article 1007, €4.00); room 418, one white wine (article 1020, €18.00).

Steward first reads who is currently in each room. A room number alone is ambiguous, because guests change. Steward binds each charge to the current reservation and room guest and prepares separate charge documents for separate rooms. It checks the identity again immediately before execution. If the guest changed in the meantime, the proposal stops instead of charging the new guest.

Clear input helps. The hotel operations guide explains the identifiers that matter: article code, quantity, exact amount and room or reservation.

3. A person approves, always

Room charges always require approval in Steward by default, even if someone switched the chat to Automatic. The approver, typically the front-office manager with Approve access, opens the proposal and checks:

• the room and the guest the charge is bound to,
• each article, quantity and amount,
• that rooms are not mixed up.

They approve or reject the whole batch. Rejecting with a short message (“418 is red wine, not white”) lets Steward prepare a corrected proposal.

4. The result is recorded, including uncertain ones

After approval, Steward sends the charges to ASA and records the result in the conversation.

What happens if the connection drops

This is the important part. Sometimes a request reaches ASA, but the answer never comes back, for example because of a timeout or a network interruption. At that moment, nobody knows whether the guest was charged.

A naive script or AI tool would try again. If the first attempt actually succeeded, the guest is now charged twice.

Steward does the opposite:

1. The result is marked uncertain. It is never retried automatically.
2. Further ASA changes on that connection are held. Reads continue to work.
3. A person with Approve and Read access checks the account in ASA and records what happened: applied or not applied, with the ASA reference as evidence.
4. Only then can new changes be prepared, as fresh proposals with the usual approval.

That costs a minute in a rare case and prevents the most embarrassing error a front desk can make.

Who does what

Role	Project role
Minibar team	Contributor
Front-office manager	Manager
Reception	Viewer

ASA must also allow the account to post charges. That needs the postRoomCharge method and a suitable licensed module. Steward never tests write permissions by trying them.

A record you can show

Every charge has a trail in the project: the original report, the prepared proposal, who approved it and when, and the result from ASA. When a guest disputes a minibar item at check-out, reception can see exactly what was charged and on whose instruction. See Who approved that?

Get started

You need Manager access to the proposal’s project to approve or reject changes. Contributors can prepare changes and review the details. Approval rechecks the executor’s current project access and the enabled connection before execution.