Meet Kotha: Dekhval’s Customer Conversation Engine
Kotha is Dekhval’s AI engine for customer conversations, customer context and human handoff. In an implementation for a Bangladeshi fashion direct-to-consumer brand, it sends replies automatically across WhatsApp, Messenger and Instagram. The customers commonly ask about sizes, colour availability and discounts. Refunds, complaints, order changes and delivery cancellations remain decisions for people.
That division of work is the starting point for understanding Kotha. An assistant can answer a customer’s question without having permission to make every decision that follows from the conversation.
This is the first article in a four-part series about Kotha: what it handles, how it connects to orders, how customer context supports a conversation, and how a team oversees the work.
What does an AI engine mean here?
Dekhval uses “engine” to describe a capability that can be incorporated into a business system. It has eight AI engines, each with a defined area of responsibility. Kotha covers conversations and customers. Other engines cover work such as order operations, stock and accounts, voice, images, motion, marketing content and documents. Three engines are live; five are in development.
A product combines the capabilities needed for a particular kind of operation. Dekhval Commerce, for example, is a multi-engine commerce product. Kotha supplies its conversation capability; the complete product has responsibilities beyond the inbox.
WhatsApp, Messenger and Instagram are channels where a customer can reach the business. The inbox is an interface for working with those conversations. Kotha is the engine behind the conversation work. That distinction helps a team describe what it needs without treating one messaging app as the whole system.
What Kotha handles in the fashion-brand implementation
For the fashion brand, Kotha replies directly to customers. It does not prepare drafts for staff to approve before sending.
The recurring questions are familiar to a retail team: what sizes are available, whether a product comes in a particular colour, and whether there is a discount. Those questions give the implementation a concrete subject to work with. They also identify the business information that needs an owner: product details, availability and the terms of an offer.
Automatic sending makes the quality of that information consequential. As an implementation principle, the team should establish which source answers each question and what happens when an answer is missing. A plausible answer about an unavailable size is still a wrong answer. The same applies to an expired offer.
The confirmed channels and sending behaviour describe this implementation. They should not be read as a promise that every Kotha installation has identical connections, permissions or configuration.
Where a person must take over
In this store, refunds, complaints, order changes and delivery cancellations require a person’s decision. Answering a question about a discount also needs to be distinguished from granting a new discount; the latter needs an explicit permission decision when scoping an implementation.
These boundaries matter because a conversation can change direction. A customer might start by asking about a colour and then ask to change an existing order. The second request creates a different task, with consequences for the order and the people fulfilling it.
A useful handoff should give the colleague enough context to continue: what the customer asked, what has already been said and what decision is needed. That is a design requirement to agree and test for the workflow. The precise routing and takeover sequence in this implementation is outside the scope of this introduction.
Our AI integration brief template explains how to specify permitted actions, handoff ownership and acceptance checks before expanding an assistant’s responsibilities.
How Kotha fits beside Chalan and Khata
Conversations can involve information or actions owned by another part of the business. Dekhval separates those responsibilities across engines:
| Engine | Responsibility |
|---|---|
| Kotha | Customer conversations, customer context and human handoff |
| Chalan | Order intake and confirmation, dispatch, delivery, returns and cash-on-delivery reconciliation |
| Khata | Stock, accounts, credit and instalments |
A question about availability belongs to a customer conversation, but the stock record has its own owner. A customer’s request to cancel a delivery arrives as a message, but changing the delivery is an operational action. Defining both sides prevents a team from assuming that permission to reply includes permission to alter a record.
In a connected implementation, the project needs to specify what information passes between these responsibilities and what actions are allowed. The engine definitions establish ownership; the actual connections need to be demonstrated and tested in the system being delivered.
The second article in this series will focus on the boundary between Kotha’s conversation work and Chalan’s order work.
Customer context needs a specific meaning
Customer context is part of Kotha’s product scope. For a business evaluating it, the useful next question is: which information can this implementation actually retrieve and use?
A previous exchange, a customer record and an order record can each help someone continue a conversation, but they are different sources. Access to one does not establish access to the others. Likewise, operating across several channels does not by itself establish that the system recognises the same person across all of them.
Define the required context in concrete terms when planning the system. Which record should be available? How is it matched to the customer? Who can correct it? The third article will examine customer context in more detail, using the evidence available for that workflow.
What to establish before introducing Kotha
Start with a small set of representative customer requests and agree on the expected behaviour for each. For a retail implementation, a useful first discussion covers:
- The routine questions the assistant may answer and the approved sources it can use.
- Whether it sends replies automatically or prepares them for review.
- The requests that require a person, and who receives them.
- The records it may read and the actions it may take in other systems.
- Who updates product information, offers and policies after launch.
Evaluate the setup against those tasks, including what the business’s existing tools already provide. The relevant question is whether the complete workflow fits the operation and has a clear owner after launch.
Dekhval develops the engines and products. Premium Design Company’s role is design, development and integration, working with Dekhval as our AI integration and automation partner. Our AI integration service is a starting point for discussing a customer workflow and the systems it needs to connect to. For scope and budgeting, see our guide to AI integration costs.
The remaining articles will cover the conversation-to-order connection, customer context and human oversight. Each will separate the engine’s responsibility from the behaviour demonstrated in a particular implementation.