AI Chatbot Handling Up to 85% of Routine Enquiries

The chatbot detects the customer’s language and intent, understands informal and mixed-language messages, and answers using information approved by the business. When a request requires professional judgment, missing information, or manual action, the conversation moves to an employee.

These enquiries were important to customers but often did not require professional expertise. Handling them manually took time away from conversations that needed judgment, empathy, or access to another business system.

Messages also continued outside working hours. Customers could contact the business in the evening or at the weekend and wait until an employee became available.

The business needed the chatbot to act as a second support shift. While employees were offline, it would handle approved routine enquiries, provide immediate information, collect the details needed for follow-up, and transfer unresolved conversations to the team for the next working period.

A conventional scripted chatbot would not have solved the problem. Customers used different languages, combined languages in one message, wrote informally, made spelling mistakes, and described services without knowing their official names.

The chatbot analysed the conversation to determine the customer’s preferred language and intent. It could interpret:

• mixed-language messages;
• slang and informal wording;
• abbreviations;
• spelling mistakes;
• descriptions that did not use the official service name.

It distinguished between routine questions, booking enquiries, complaints, spam, requests for an operator, and conversations outside its approved scope.

This allowed customers to describe what they needed in their own words.

Employees could edit the content directly or upload existing documents through the administrative panel.

When a price, schedule, policy, or service description changed, the business updated it in one place. The chatbot then used the revised information in future conversations without requiring a new scripted flow or code change.

This reduced dependence on developers and helped keep customer information consistent across AI and human support.

Administrative panel

The administrative panel was designed for employees responsible for chatbot configuration, business information, access, and operating rules.

Administrators could:

• enable or disable the chatbot;
• select its operating mode;
• configure working days and hours;
• define when AI or operators respond;
• edit the chatbot name and response settings;
• manage language and communication instructions;
• define the approved answer scope;
• configure operator handover conditions;
• configure spam and irrelevant-message handling;
• maintain the knowledge base;
• upload and remove supporting documents;
• manage administrators and operators;
• review WhatsApp connection status and settings.

The administrative panel controlled how the system behaved. It was not intended for handling individual customer conversations.

The business could set different working hours for each day of the week and adjust or switch the active mode at any time when operational needs change.

Operators could:

• see active conversations in one inbox;
• review customer details and conversation history;
• see whether a chat was handled by AI or required attention;
• take ownership of a conversation;
• reply to the customer manually;
• use an AI-generated draft;
• return the conversation to AI mode;
• close the conversation;
• review AI usage for the selected chat.

When an operator took control, automatic customer-facing replies stopped. This prevented the customer from receiving parallel or conflicting answers from AI and an employee.

The operator received the full conversation history and could continue without asking the customer to repeat the request.

Sensitive requests move to an operator

The chatbot transferred a conversation when:

• the customer asked to speak to a person;
• the required information was unavailable;
• the request fell outside the approved scope;
• professional assessment was required;
• the situation was sensitive or disputed;
• an action had to be completed manually.

For the delivered healthcare-related workflow, the chatbot was restricted from making diagnoses, recommending treatment, replacing a consultation, or minimising potentially urgent symptoms.

No confirmation without a system response

The chatbot did not claim that an appointment or application had been completed unless the relevant business system confirmed it.

Without a booking integration, it could collect the customer’s preferred date, requested service, and contact details. It then explained that an employee would confirm availability.

This created a clear boundary between collecting information and completing a verified business action.

Answers stay within approved information

The chatbot used the company’s knowledge base as its factual source. If the information required to answer a question was unavailable, it did not fill the gap with an assumption and transferred the conversation to an operator instead.

Access and deployment controls

Administrators managed chatbot settings, users, and business information, while operators worked with customer conversations.

API credentials were stored as protected secrets. Test and production environments were separated, and automated checks ran before deployment.

AI data processing

The chatbot used the OpenAI API to interpret messages and generate responses. Only the context required for the current request was sent to the model.

OpenAI states that API inputs and outputs are not used to train its models by default. Additional retention controls may be available depending on the organisation and API configuration.

Business setup and AI tuning

We configure the chatbot around your services, business information, customer questions, supported languages, escalation rules, and response style.

Testing and refinement

Before launch, we test the chatbot against real customer scenarios, including unclear requests, informal wording, missing information, operator handover, and cases where a human should take over.

Launch and post-launch warranty

After testing, the chatbot is released to production and followed by a one-week warranty period for issues within the agreed scope.