Overview
Storebox already used Fonio for AI-powered phone support. I helped expand the product toward a website chatbot pilot, focusing on how the assistant should behave, which live systems it should use, how it should handle incomplete information, and how we would measure whether it was actually useful.
The real challenge wasn’t adding a chatbot. It was making sure the assistant could use live data safely, and knew when not to answer.
How it works
- Customer“What’s the cheapest available cabin near me?”
- Understand intent
- Call the correct Storebox toolSearch current locations and availability
- Validate active inventory, price and booking informationComplete, current result
- Can the answer be verified?
-
Provide the verified optionCheapest available cabin, with price and booking linkCommunicate uncertainty and refer to supportNo invented prices, availability or links
Conceptual illustration.
The layers behind the chat
My role
- Prompt and system behaviour
- Tool and API logic
- Multilingual behaviour
- Hallucination prevention
- Fallback and support-referral logic
- Booking-assistance behaviour
- AI QA and test scenarios
- Severity classification
- Success criteria and KPI design
- Transcript and tool-failure analysis
How I approached it
Start with real customer demand
Salesforce and Customer Service demand showed which questions come up most often, which topics could be automated safely, which still need human judgement, and where automation could reduce repetitive support work.
Treat tool calls as part of the product
A fluent answer isn’t enough. QA also checks the correct location, the correct size interpretation, current availability, the correct cabin, the correct price and valid booking information.
Design failure states deliberately
Tool failures, timeouts, incomplete results and unsupported requests need explicit product behaviour: how to handle missing information and partial responses, when to retry, what safe fallback wording says, and when to refer the customer to support.
Key decisions
- Verified data or no claimThe assistant must not invent prices, availability, links or access information. If something can’t be verified, it isn’t presented as fact.
- The latest language winsThe assistant follows the language of the customer’s most recent message.
- Referral is part of the productWhen the AI can’t resolve something safely, referring the customer to support is an intentional outcome.
- Automate where demand justifies itAutomation priorities are based on real Customer Service demand and expected customer value.
- Severity matters more than pass rateAn awkward sentence is not the same as an incorrect price or availability result.
Technical and operational complexity
The assistant has to handle location search by city, postcode, location or coordinates; availability; cabin sizes; the cheapest and largest available options; pricing and booking links. Beyond search, it follows defined rules for payments, invoices, insurance, reservations, promotions, viewing requests and support requests.
Only ACTIVE inventory may be shown, and incomplete or timed-out tool results need safe handling.
QA severity
What the pilot measures
- Usage
- Safe self-service
- Answer accuracy
- Critical error rate
- Incorrect price or availability responses
- Incorrect links or access information
- Tool timeouts
- Safe fallback behaviour
- Referral accuracy
- Changes in Customer Service demand
Outcome
The work created a structured product, QA, safety and measurement framework for expanding an existing AI assistant toward a website chatbot pilot. The product was designed around verified data, live tools, explicit business rules, safe failure behaviour and measurable customer-service outcomes.
The objective was to help customers resolve repetitive questions safely, support verified booking journeys and refer them correctly when automation was not the right answer.
What I learned
The most important part of an AI product is rarely the model itself. The real product work is designing everything around it: data, tools, business rules, failure states, safety boundaries, QA and success metrics.