When Lena forwards a request: what must happen after the chat

An AI concierge for Saas-Fee can help with a specific request only if it distinguishes “requested” from “confirmed”. Between 26 and 28 September 2026, Lena Concierge revised the workflows for requests to accommodation hosts and restaurants: replies are linked to the right request, unanswered requests have a defined endpoint, and guests should receive the outcome. This is verified progress in the code, not a published success rate in guest operations.

Review date: 2 October 2026.

Why a good answer is not enough

“Can we check in later?” and “Is there a table tomorrow evening?” are not simply information questions. A person at the accommodation or restaurant must decide. Forwarding the request cannot be presented as approval. The concierge needs a traceable sequence: record the request, send it to the responsible contact, identify the reply and tell the guest the outcome.

This matters for destinations too. A SECO paper on digitalisation in Swiss tourism (2025) describes guest service as a digital process and emphasises connections between hotels, providers and destination organisations. The OECD tourism report published on 1 July 2026 identifies opportunities for digital tools and AI to improve operations and personalise experiences. These sources provide industry context; neither measures Lena’s impact.

What changed in Lena this week

Requests to hosts remain traceable until the reply reaches the guest

The update of 26 September introduced a status lifecycle for early check-in, late check-in and late check-out requests. It applies to guests with a personal accommodation link, provided the required WhatsApp and Twilio settings are in place. A general question about check-in hours does not automatically become a request to the host.

Lena can send the request to the accommodation contact with a reference code. The host can approve or decline using that code. The reply should return to the guest, who can also retrieve the status in the chat. The workflow has configuration limits: some messages require WhatsApp templates, and delivery status is visible only with the stated configuration. The implementation establishes the workflow, not that every connected property already uses it.

The update of 28 September addresses two gaps. If the accommodation contact changes, an old pending request must no longer be treated as a current request to the new contact. A scheduled, protected background job expires overdue requests. It cannot prevent a slow host reply, but it gives the pending state a defined limit.

A restaurant table requires an unambiguous confirmation

The update of 27 September changed how restaurant replies are interpreted. Free-form text no longer confirms a table. Previously, even a refusal containing the word “confirm” could be mistaken for approval. Now the confirmation button is required. If the same restaurant has several pending requests without a unique reference, the system does not guess which one was confirmed. Repeated button presses should not send duplicate confirmations to the guest.

If the restaurant does not reply, the update of 27 September closes a sent, unconfirmed request after two hours with the status “no response”. The intended guest message explicitly says that no table has been reserved and provides the restaurant’s contact details when available. A later unambiguous confirmation can still change the status. Delivery to the guest depends on the available contact and messaging service; a recorded send attempt does not prove that every guest received the message.

Who can benefit from this workflow

Guests receive a more precise account of the actual state of a check-in request or table enquiry. The distinction between sent, confirmed and closed without a reply matters. There is no published evidence yet of how often this reduces misunderstandings in operation.

Hotels and holiday apartments can associate a request with the property, guest and responsible contact’s reply instead of losing it among isolated chat messages. This requires a maintained contact, appropriate WhatsApp configuration and a clear internal process for handling requests.

Destinations could use these defined handoffs between guests and local businesses to understand the service processes a shared digital guest companion needs. Lena provides building blocks; these technical changes do not establish a destination-wide rollout or a demonstrated operational effect.

What needs to be checked next

• •Use authorised real test contacts to check that hosts and restaurants receive messages under the production WhatsApp configuration and guests see the final status.
• •Test missing, ambiguous and late replies end to end, including a change of accommodation contact.
• •In a pilot, measure how many requests reach a correct outcome, how long replies take and where delivery fails. No metric for these results has been published.
• •Define who takes over when nobody replies and which businesses actually participate. No participation or partnership is claimed here.

These are next checks, not promised dates or features already introduced.

Related reading

Why tourism AI must understand the resort explains the geographical boundaries of knowledge. The September Lena update covers the broader project status. This article focuses on a specific request’s path to a reply.