Lock&Go AI Assistant
The information was all there, on the site. Someone arriving at eleven at night with a question about luggage storage had to dig for it themselves, across the FAQ pages. Or send an email and wait until morning.
The assistant answers questions about the service in plain language, drawing on the FAQs published on the Lock&Go site. Ask whether you can leave a backpack for three hours near the station and you get the answer, not a list of links. Eight conversations out of ten end without anyone on the team stepping in.
What we built
- Answers built on Lock&Go's own content. The assistant does not draw on the model's general knowledge. It searches the site's FAQs, takes the passages that bear on the question, and writes the answer from those. When the FAQs change, the answer changes: there is no second place to update the information.
- The source next to the answer. Every answer names the FAQ entry it came from. The traveller can check it, the Lock&Go team can see why the assistant answered the way it did — and how often each entry gets cited.
- A stated "I don't know". On questions about an existing booking — where is my PIN, can I move the time — the assistant does not attempt an answer. It says it cannot and hands over to a person. That happens in 14% of conversations, and it is the number the team watches.
- A spend cap per conversation. Every conversation carries a cost limit, and the model has a monthly budget. A conversation that passes the cap closes and says so, handing over to a person instead of going on costing money.
- A test environment before anything ships. Whoever runs the assistant can play out a real scenario — an existing booking, a conversation that blows the budget — and see the answer, the source and the cost with no customer involved.
- Every exchange traced. Question, retrieved passages, answer produced, actual cost: all of it stays inspectable. When an answer is wrong you can see where it came from, and you fix the FAQ instead of the model.
The unanswered questions become a list
An assistant that says "I don't know" produces data that did not exist before: which questions customers actually ask, and which of them the site does not cover.
The console keeps count. Thirty-four people asked whether there is a storage point at Bergamo Orio al Serio; coverage on booking and refund questions sits at 58% while pricing and sizes are at 94%. These are not dashboard metrics: they are the list of FAQs to write, ordered by how many people are waiting for each one.
How it runs in production
An assistant that answers on company data is not built by training a model. It is built by giving it access to the right documents at the right moment, and a boundary to stay inside.
The boundary here is deliberately narrow: the assistant sees the FAQs, and nothing else. It does not see the booking database, the payments, or customer data. A question outside the boundary does not produce a wrong answer — it produces a refusal and a handover to a person.
The same FAQs serve the site widget, WhatsApp and the email inbox, in Italian, English, French and Spanish, with the language picked up from the question itself. An answer written once reaches every channel, with no versions drifting apart.
The spend cap does the same thing for cost. A conversation going nowhere is a cost that grows without producing value: the limit closes it before that happens.
Where a person decides
On anything with a consequence. The assistant informs: how the service works, what it costs, where the hubs are, what happens if you arrive late. It does not book, modify, cancel, or reach into an existing reservation.
When a question moves from information to operation, the conversation goes to the Lock&Go team. That is a design choice, not a technical limit: on a service where a customer's luggage is locked inside a locker, an automated mistake costs more than the automation is worth.
