A chatbot that answers patients at night and books consultations

Who the client was and what was getting in the way

An ophthalmology clinic specializing in vision correction. Patients kept asking the same questions: how much a procedure costs, which correction methods are available, whether they are eligible, and which clinic they can book at. About 80% of enquiries were about these four topics. Reception staff answered by email and phone during opening hours.

The problem is that people rarely decide to have eye surgery in the middle of the working day. A patient might read about laser vision correction in the evening, send a question at ten at night, and then wait. If the reply arrives the following afternoon, some people have already asked another clinic in the meantime. That was the first gap.

The second was turning interest into an appointment. Many people asked follow-up questions and received a useful answer, but the conversation ended there. With that volume of enquiries, staff had no time to suggest a specific date for an eligibility consultation.

The third issue was keeping information current. Prices and the scope of procedures changed every few months. A tool with hard-coded knowledge would start misleading patients within a quarter, and that is no small matter in healthcare. The clinic needed something that would keep up with the content on its own website automatically.

What we built

We built a RAG-based chatbot — retrieval-augmented generation — which answers using relevant passages retrieved from a knowledge base, rather than relying on what the model memorized during training. Once a day, a process crawls the clinic’s website, extracts new and changed content, splits it into passages, and adds them to a vector database. A custom page-fetching mechanism collects the content; LangChain handles retrieval and context assembly; GPT-4 generates the answers; and Supabase stores the knowledge passages and conversation history.

We built the chat module in Next.js and embedded it on the clinic’s website as a widget. Instead of an empty text box, patients see several suggested questions to start with: about prices, vision-correction methods, and the eligibility process. It is a small detail, but it shortens the path to a useful first answer and immediately steers the conversation towards topics the clinic wants to handle.

The third element is lead capture. When a conversation shows genuine interest in a procedure, the chatbot suggests booking a consultation, asks for contact details, and passes them to the system the clinic uses to manage patients. We also added conversion tracking and a view of the most common questions, so the clinic can see what people actually ask rather than what it assumes they ask.

How it works today

The whole solution was built in ten days. The first two were spent reviewing the website and deciding which content belonged in the knowledge base and which was purely marketing material that would only muddy the answers. The next five went into building the chatbot, the knowledge-refresh process, and lead capture. The final three days covered embedding it on the website, testing conversations, tuning prompts, and connecting the system the clinic uses to manage patients.

The widget is now available on the website around the clock. The knowledge base refreshes itself daily, so a price change on the website is reflected in chatbot answers without anyone at the clinic having to intervene. Patients who ask a question at night get an immediate answer, and when the conversation turns to a procedure, it ends with a proposed appointment time and their contact details passed on.

The outcome

The clinic can answer questions seven days a week. About 80% of enquiries — the recurring questions about prices, methods, and eligibility — are handled without involving staff. The knowledge base updates automatically every 24 hours directly from the clinic’s website. Conversations do not end with information alone: they lead to consultation bookings because the chatbot suggests a time and captures the patient’s details.

What we would do differently

We would review the website content first and build the chatbot second. A model is only as good as its source material, and every gap in the procedure descriptions on the website immediately became a gap in the answers. We spent a lot of testing time patching those gaps with prompts, although adding the missing paragraph to the website would have been faster.

We would also change when the chatbot suggests an appointment. The first version offered one too quickly and sounded pushy; moving the suggestion a few exchanges later made it feel natural. Finally, we would agree on patient-data handling at the first meeting: what the chatbot collects and where that information goes should be settled then, not during implementation.