AI for HORECA: Hours, Allergens and Orders

How can a restaurant, café or pastry shop use artificial intelligence?

By turning information the business already holds — opening hours per location, products, ingredients, allergens, ordering procedures — into something customers can reach through natural conversation, at any hour. The AI interprets what the customer wants; the business data supplies the facts; software controls the process.

BigLearn built a generative AI customer assistant for a renowned traditional Portuguese pastry house based in Lisbon — holder of more Best Pastel de Nata awards than any other, with more than eighty years of history. The assistant answers questions about stores, opening hours, products and allergens, and can start an order — all in one conversation, available around the clock.

None of the questions is hard. Answering them every time is.

«Is the downtown shop open today?» «What time does the mall branch close?» «Does this contain nuts?» «I'd like 50 pastéis de nata for tomorrow.» Taken one at a time, none of these is difficult.

The difficulty is answering them accurately, repeatedly, and whenever the customer decides to ask. Several locations with different hours, a long product list and detailed allergen information make it harder each year — while customers increasingly expect the answer to be there already.

The shop closes. Digital service does not have to.

Someone decides to order at 11pm. Someone is organising an event for Sunday. Someone is checking an allergen before choosing. Someone is outside Portugal, planning a trip to Lisbon. The need appears when it appears.

A website can publish all of this — but the customer still has to find it, pick the right store page and interpret it. Conversation reverses the work: instead of browsing, they ask «what time does the downtown shop open tomorrow?» or «I need pastéis de nata for thirty people», and the assistant starts the right interaction immediately.

Allergens: the one place the AI must not guess

A model knows recipes. That is exactly the problem. Asked whether a product contains nuts, a language model can produce a confident answer from what it knows about similar pastries — and be wrong about this one.

So allergen answers come only from controlled product information supplied by the business. When that information is missing or insufficient, the correct behaviour is not a careful guess: the assistant says it cannot confirm and points the customer to a human. This is the shortest rule in the project and the one that matters most — when the answer matters, not knowing is better than inventing.

It is the same rule we apply where a wrong answer is a commitment rather than an inconvenience, such as prices and availability in the real estate email assistant.

A model knows pastry. It does not know this pastry shop.

A large language model can explain what a pastel de nata is. It does not know that house's products, the current hours of each location, the registered allergen information, or how ordering works there — and it never will, because that information is not public and it changes.

So the application supplies the relevant business knowledge with each interaction: customer question + business knowledge + business rules + model = a contextualised answer. When hours change or a product is added, the source is updated and the next conversation uses it. Nothing is retrained.

A sentence becomes an order

«I'd like 40 pastéis de nata tomorrow morning» already contains four things: the intent, the product, the quantity and the timing. What is missing is the collection location, the exact time and the contact details — so the assistant asks only for those, rather than presenting a form for everything.

To the customer it is a sentence. To the application it is type: order · product: pastel de nata · quantity: 24 · date: tomorrow · status: collect missing information. Once the required fields exist, AWS Lambda triggers the next step of the ordering workflow. That crossing from language into a business process is the whole difference between an AI application and a chatbot.

A chatbot answers. This one decides what kind of thing it is being asked.

Three requests arrive through the same box and are not the same at all. «What time do you close?» is an information request. «Does this contain a specific allergen?» requires controlled knowledge and a refusal path. «I want to order 30» starts a workflow.

A chatbot is built around question → answer. This is built around understand → ask → collect → structure → validate → execute → respond. The interface looks identical to the customer; what changes is what happens behind it.

Why AWS Lambda, and what the model is not allowed to do

The model does not run the application. AWS Lambda receives the message, validates it, loads the relevant business context, works out what information is still missing, calls the model, processes the output, converts the conversation into structured data, starts the ordering workflow and writes the logs.

The division is deliberate: generative AI is good at «what is this customer trying to do»; ordinary software is better at «do we have every required field before creating this order». A question is an event, an order is an event — which makes serverless the natural fit, and lets customer service, business context, AI, ordering and integration live as separate components with clear jobs.

AI is not only for banks and multinationals

This project's real point is not the pastry. It is that a traditional Portuguese business can use the same underlying technology as a bank — large language models, AWS Lambda, APIs, context engineering, workflow automation — for an objective that is not sophisticated at all: answer customers better.

HORECA suits this unusually well. Hotels, restaurants and cafés field the same questions endlessly — hours, locations, menus, ingredients, allergens, reservations, orders, availability — and most of that information already exists inside the business. What was missing was a way to reach it. Natural language is a universal interface to knowledge a company already has.

The same architecture adapts to restaurants, bakeries, chains, catering companies, hotels and multi-location operators. Which is why the work does not start with the chatbot — it starts with the business process. The first question is not «which chatbot should we install», it is «which business problem can artificial intelligence actually solve here».

Tradition stays in the bakery

The AI does not make the pastries, and it does not replace the people who do. It does not stop a customer from speaking to a person when that is what they want. It solves a different problem: making business information and selected digital processes available when customers need them.