Selected work
SavvyBot
An in-production AI consultation platform that turns approved business knowledge into leads, bookings and orders.
SavvyBot did not start with the question of how to make AI sound better
While working on customer consultation for F&B businesses, I learned that the hard part was not generating a fluent answer. The answer had to come from information the business actually used, avoid promising what the team could not deliver and lead to a clear next step when a customer wanted to buy, book or speak to a person.
A customer may start in a website widget, Messenger or Zalo. They do not care which channel the system is using. They need the right information and should not have to repeat the entire conversation when a staff member takes over.
The ZiniSoft team built SavvyBot from that need. F&B is the main public case, while the platform is designed for several operating contexts across small and medium businesses.
A conversation needs to end in work that someone can handle
Small F&B teams receive product questions, custom requests and order intent throughout the day. Answering the question is only the beginning. A customer may need product guidance, leave contact details, make a booking, create an order or ask for a person. If the conversation ends with an AI response but never becomes work the team can continue, the operating loop is still open.
The source information also changes. A product can become unavailable, a policy can be updated and a special request can fall outside what AI is allowed to conclude. SavvyBot therefore needs to know which knowledge is ready, what is missing and when responsibility must move to a person.
From fragmented conversations to a handoff someone owns
Before
Repeated questions, customer details and order requirements were handled directly inside each conversation. The quality of the next step depended on who was available, what information they had and whether the full context reached the person responsible for acting on it.
Intervention
SavvyBot connects a customer conversation to business knowledge that has been prepared and approved by an operator. It can answer product and policy questions, collect lead context, create a booking or order and hand the conversation to a person when the request should not be handled automatically.
The production scope currently includes a website widget, Messenger and Zalo. The same operating model has been tested across four domains: F&B, education, travel and retail/e-commerce.
Current state
SavvyBot supports live paid deployments and is also used internally in school operations. F&B remains the clearest public case because it combines changing product knowledge, detailed customer requests and a concrete next step in the form of a lead, booking or order.
Public evidence
- Live paid deployments without disclosing customer identity or count.
- Production use through a website widget, Messenger and Zalo.
- Knowledge-based consultation, lead capture, human handoff, booking and order creation.
- Testing across four business domains and internal use in school operations.
Processing time, number of manual steps and completion rate have not yet been measured to the publication standard. This case therefore makes no before-and-after performance claim.
Public operating model
- Customer conversation: a question or request arrives through a supported channel.
- Approved knowledge: the system works from business information prepared for the relevant domain.
- Bounded consultation: AI answers within that context and identifies the next operational intent.
- Recorded next step: the conversation becomes a lead, booking or order when the required information is available.
- Human handoff: a person takes responsibility when context is missing, the customer asks for help or the decision requires judgment.
This is a reconstructed public model, not the internal architecture.
My role and the team’s responsibility
I am responsible for solution architecture and production operations. My work is to connect the conversation channel, knowledge source, business action and human handoff into a workflow that can be operated, observed and recovered when something goes wrong.
The ZiniSoft team designs, builds, tests and evolves the platform. Business operators remain responsible for preparing and reviewing knowledge, handling cases that require judgment and owning the final customer outcome.
Decisions and trade-offs
One platform, domain-specific operating context
SavvyBot uses one product foundation across four domains rather than creating a separate product for each industry. Domain context changes the knowledge, collection requirements and next step, while the core operating boundaries stay consistent.
Accountable knowledge before open-ended answers
SavvyBot prioritizes content prepared by the business instead of allowing a model to answer freely about everything. This narrows the response range, but gives the operator a place to inspect and update the information. When the available knowledge is insufficient, a handoff is safer than an unsupported answer.
Human handoff is part of the workflow
A chatbot should not try to retain every conversation. When evidence is missing, the customer asks for help or a decision affects an order and experience, handoff is the responsible outcome. The trade-off is that the business still needs an available person and a clear intake process.
What SavvyBot taught me
An AI assistant does not become trustworthy because it sounds natural. Its value depends on whether an operator can see where the information came from, what the system may do and who receives the work when AI stops.
SavvyBot reinforced a principle I now use across products: automation does not end at model output. It matters only when that output enters a real workflow with state, a responsible owner and a path for exceptions.
Publication boundary
This case demonstrates that approved business knowledge can be connected to live customer conversations, conversion steps and human responsibility in one production workflow. It does not claim a measured reduction in response time, manual effort or an increase in completion rate.
Customer names, customer data, private infrastructure and internal architecture are not included. The interface images above are reconstructed with fictional data. The public product link is provided as a separate demonstration surface and does not change the evidence boundary of this case.