Victor Arias
ZEKI is a medical chatbot that handles inquiries 24/7 on a cloud backend on AWS: it understands the question in natural language, answers from its knowledge base, hands over to a person when the case requires it and scales on its own when more people come in. The service stayed available at all hours and cut the inquiries previously handled by hand by 60%.
| Client | ZEKI |
| Industry | Digital health |
| Service | Cloud Services |
| Stack | AWS, Chatbot with natural language AI, Cloud backend, Knowledge base, Handover to a human, Automatic scaling, History and metrics |
| Duration | 1-2 months |
| Our role | Cloud infrastructure and backend on AWS for the chatbot: natural language AI, knowledge base, handover to a human, automatic scaling and history with metrics. |
| Published | December 14, 2022 |
A health inquiry does not respect office hours: it arrives at night, at the weekend and at times when nobody is there to answer. And it is almost always the same question, repeated hundreds of times, which is exactly the ground where a chatbot earns its place.
ZEKI is a medical chatbot running on a cloud backend on AWS: it understands the inquiry in natural language, answers from its knowledge base, hands over to a person when the case requires it and scales on its own when more people come in. The service stayed available 24/7 and cut the inquiries previously handled by hand by 60%.
The challenge: inquiries that do not arrive during office hours
In healthcare, volume is not spread like the working day. Doubts appear when patients have them, and if nobody answers at that moment, the inquiry is lost or piles up for the next day. It is an availability problem, not a staffing one.
Demand is not constant
There are peak hours and dead hours, and neither necessarily matches the team on duty. Sizing for the peak means paying for idle capacity the rest of the time; sizing for the average means falling over exactly when the most inquiries come in.
A chatbot cannot make answers up
In health, an invented answer is worse than no answer. The chatbot has to stick to the information the team has validated and, when the inquiry goes beyond that, acknowledge it instead of improvising. That boundary is what separates a useful assistant from a problem.
When the case gets complicated, a person is needed
No automated flow covers every case, and it should not try to. What matters is that the conversation reaches a person with all the context: what the patient asked and what has already been answered, so they do not have to start over.
The solution: a chatbot with AI on AWS
The chatbot was built on AWS, with infrastructure ready to scale with demand and the conversation history stored for review. The work focused on what holds the service up: the knowledge base, the handover to people and the metrics to know what gets resolved on its own.
Patients ask when the doubt appears: availability is the first part of the service.
Natural language and knowledge base
The chatbot understands the question as it is written, without forcing patients to choose between rigid menus, and answers with the information the team keeps validated. The knowledge base is what allows correcting an answer in one place and having that change apply to every following conversation.
Handover to a human without losing context
When an inquiry goes off script, the conversation passes to a person with the history in front of them. The patient does not repeat what they already said and whoever takes over does not start blind, which is what usually breaks the experience in poorly built chatbots.
Automatic scaling and history
The AWS infrastructure grows when more people come in and shrinks when they leave, so a peak in inquiries does not become an outage. The conversation history and the metrics dashboard show what is being asked, what is resolved on its own and where handovers are happening more than they should.
How we implemented it in one to two months
The project started with the questions, not the technology: which inquiries arrive, which repeat and which the system cannot answer. That list shaped the knowledge base and decided when a person has to take over.
The goal is not to replace support, but to make sure only what needs a person reaches a person.
Starting with the real questions
Before building the chatbot we reviewed the inquiries already reaching the team: the repeated ones, the urgent ones and those that do not allow an automated answer. That classification defines what goes into the knowledge base and what is handed over from the first message.
Measuring how many inquiries are resolved on their own
The metric that matters is not how many conversations the chatbot opens, but how many it closes without intervention. It was tracked from the start alongside the handover rate, so the knowledge base could be adjusted instead of accepting the initial result as final.
Results
The service was delivered with the chatbot running on AWS, the knowledge base loaded and handover to people working. These were the needs and how they were solved:
| Need | How it was solved |
| Handling inquiries outside office hours | Chatbot available 24/7 on the AWS infrastructure |
| Understanding the question as the patient writes it | Natural language AI, with no rigid menus |
| Answering without improvising | Knowledge base validated and maintained by the team |
| Resolving the cases the chatbot does not cover | Handover to a person with the conversation context |
| Holding up through peaks in inquiries | Automatic scaling in the cloud |
The measured results of the project: 24/7 availability and 60% fewer inquiries handled by hand. Both figures are the same story: what the chatbot resolves on its own stops occupying the team, which keeps only what genuinely needs a person.
What a support chatbot needs
If you want to handle inquiries without depending on the clock, these are the points that decide whether the chatbot helps or gets in the way:
- Genuine 24/7 availability, which is what covers the inquiries that today go unanswered.
- Natural language, so patients ask the way they ask and not the way the system expects.
- A validated knowledge base, maintained by the team and correctable without touching the chatbot engine.
- Handover to a person with context, without making the patient repeat what they already said.
- Infrastructure that scales on its own, so a peak in inquiries does not become an outage.
- History and metrics, to know what is asked, what is resolved on its own and where too much is handed over.
If you want to handle inquiries around the clock without growing the team, our cloud services page explains how we work, and you can write to us to go through it together.
Frequently asked questions
What can a medical chatbot solve and what can it not?
It solves the repetitive part: opening hours, test preparation, frequent questions and procedures, which is where most of the support time goes. It does not diagnose or replace a professional: when a query goes off script, the chatbot has to pass the conversation to a person instead of improvising an answer.
Why does a health chatbot need the cloud?
Because demand is not constant: it concentrates outside office hours, during campaigns and around specific moments, and a fixed server forces you to size for the worst day. The cloud allows scaling automatically when more people come in and scaling back down afterwards, without paying for capacity used only a few hours.
What does a knowledge base add to a chatbot?
It keeps answers in a single place that can be corrected without touching the chatbot engine. That is what stops the system from learning in any random way: the team reviews what is being asked and adjusts the information, so improving the chatbot means editing answers, not rebuilding the development.
How long does it take to launch a support chatbot?
This project was delivered in one to two months. The schedule is set by the knowledge base, the cloud integration, the handover to people and the history with metrics to see which inquiries are resolved on their own.
