Customer-Facing Chatbots 2026: Decide What It Must Not Answer First

Late on a Friday afternoon, a Thai sales administrator opened the same screen for the third time. She was trying to answer a single line that had arrived from a customer on LINE, “When is PO-24817 shipping?” Look up the order number in the core system, check with production control, get back to the shipping team. Fourteen minutes gone, and that was one of more than 20 inquiries of the same kind that day. This is usually the scene that starts a discussion about a customer-facing chatbot. But the first decision is not how much you let it answer. It is what you refuse to let it answer.

The first decision for a customer-facing chatbot is what it must not answer

An internal chatbot and an external chatbot are technically almost the same thing. Documents are retrieved, a generative model summarises them, and the answer comes back in a conversational form. The components are barely different.

What differs is what happens when the answer is wrong. That is the one decisive difference. And a chatbot that goes live to customers without that difference built into its design will, sooner or later, create a liability for the company.

An internal wrong answer is rework, an external wrong answer is a promise

Suppose the internal helpdesk bot quotes an outdated rule and says that leave requests must be filed three working days in advance. If the employee notices, it gets corrected. The loss is the time that employee spent plus the effort of the correction. The hard part of internal AI is mostly this problem of answers going stale, and we set out the structure of it in Internal helpdesk automation 2026: the four version gaps that make answers go stale.

External is different. When a bot on your website tells a customer “this order is scheduled to ship on 25 August,” the customer receives that as your company’s answer. If you correct it the next day and say the system was wrong and the real date is 3 September, the customer may already have rebuilt their own production plan around a 25 August arrival. A correction can restore the facts. It cannot restore the other party’s decisions.

In short, an internal wrong answer costs you rework, while an external wrong answer is treated as a promise. That single point changes where the design has to start.

“The AI said it” is not a shield

A useful episode occurred in Canada in February 2024. A chatbot on an airline’s website gave incorrect guidance about bereavement fares. The company argued, in substance, that the chatbot was a separate legal entity responsible for its own statements. The Civil Resolution Tribunal in British Columbia rejected that argument, treating the chatbot as part of the company’s own website, and found the company responsible. The total ordered was CAD 812.02, of which CAD 650.88 was damages for the fare difference and the remainder was pre-judgment interest and tribunal fees (commentary on Moffatt v. Air Canada by McCarthy Tetrault, CBC News coverage).

The amount is small, and this was the decision of a single Canadian forum, an administrative tribunal to be precise. It does not extend as such to the legal systems of Thailand or Japan, and this article does not attempt any legal interpretation. Even so, the practical implication is clear enough. If a similar dispute arises, an explanation along the lines of “the bot said it, not us” may not carry. Designing on that assumption is the safer course.

In B2B manufacturing, the dispute usually takes a much quieter form. It happens inside the relationship with the customer’s purchasing department rather than in a courtroom. When someone says, “Your chat told us 25 August last month, so we built our line schedule around that,” who inside your company owns that statement? Moving ahead with automation before that is settled is much like handing the company seal for quotations to someone who has no authority to use it.

Which is why design starts with answering authority

Do not carve out the scope by feature. Splitting the work into an “FAQ function” and an “order status function” reflects internal development convenience, and it has nothing to do with how heavy the promise looks from the customer’s side.

What you should carve up is answering authority. If a human wrote exactly the same wording in an email, would it stand as a statement from the company? If yes, the bot may say it. If no, the bot may not. That is the entire test. The next section turns that test into three layers you can actually operate.

The three layers of answering authority: L1 fixed answers, L2 ledger lookup, L3 judgment

Sort customer inquiries into three groups by the source of the answer. Sorting by source is the point. Not by difficulty, not by frequency, not by the length of the question. Sort by where the answer comes from.

These three layers are the same categories used in the model calculation later in this article. Both volumes and hours are counted layer by layer.

L1: the layer whose only source is a static document

L1 is the layer where the answer already exists, fixed, inside a document. Goods receiving hours at the plant, the format of required paperwork, where export documents must be submitted, contact details for the responsible desk, a general explanation of payment terms. These stay constant until they are changed, and when they change you replace the document.

There are two things to get right at L1. First, manage the source documents in one place, with version control. Second, always attach the source document name and its last revision date to the answer. A single clause such as “based on the delivery specification revised in April 2026” lets the customer verify it themselves, and turns the bot’s answer from a standalone declaration into a reference.

A wrong answer at L1 is essentially rework. The customer brings the wrong paperwork, or arrives at the wrong time. Annoying, but a correction restores the situation.

L2: reading the core system, read-only. This is where the value is

L2 is the layer where the answer sits inside the core system. Give it an order number and it returns the delivery date, give it a part number and it returns stock, it tells you whether something has shipped, it returns payment status from an invoice number. The question at the top of this article, “When is PO-24817 shipping?”, belongs here.

This is the layer with the largest effect. It has the highest volume of the three layers at 540 cases, and each case takes longer than the 6 minutes of an L1 case. And yet the value a human adds amounts to going to look at a system and transcribing what is on the screen. No judgment is involved.

L2 has three design conditions.

1. Keep it read-only. Do not let the chatbot write into the core system. Concretely, do not create any path where a customer’s message triggers a change in order data. Changes always go through a person.
2. Always state the as-of time of the information. Write “on the shipping plan as of 14:30 today.” Values in the ledger move. Without an as-of time, the customer will read the number as a fixed promise.
3. When the lookup fails, do not quietly guess. The order number is not found, several records match, the requester’s entitlement cannot be verified. The worst possible outcome is a bot that fills the gap with “probably sometime this week.” If it cannot look it up, it hands over to a person. Build this behaviour first, before anything else.

A wrong answer at L2 cannot be taken back. More precisely, the facts can be corrected, but the production plan the customer has already moved will not move back. So at L2 you build “never answer wrongly” before you build “answer correctly.”

L3: the bot handles intake only. It never says yes or no

L3 is the layer where the answer exists only in a person’s head. Can we accept a rush order, can we agree to a discount, can we absorb a requested spec change, how do we respond to a complaint? None of this is settled by stock levels and process data alone. The relationship with the customer, this period’s utilisation, fairness towards other customers, cost. This is territory for human judgment.

Do not let the bot step into L3. That is the first condition of the design.

That does not mean there is nothing for the bot to do at L3. It can take intake. The nature of the request, the part number concerned, the requested date, the quantity, contact details, urgency. It collects these in a structured way and passes them to the responsible person, who then receives a tidy request sheet rather than a forwarded email that explains nothing. This time saving is real. In Type C below it is counted as a saving of 8 minutes per L3 case.

But the bot does not answer yes or no. “We can accommodate a rush order” and “we cannot” are both phrases a bot must never use. “A member of our team will check and come back to you today” is where the bot’s remit ends.

Handling questions that cross layers

Real inquiries do not sit neatly in one layer. A single email saying “When is PO-24817 due? If it slips past next week, could you ship 100 pieces first as a partial delivery?” contains both L2 (delivery date lookup) and L3 (whether partial delivery is acceptable).

The principle here is simple. The lower-layer answer may be returned, but the moment a higher layer is mixed in, hand the entire conversation to a person. In the example above, answer the delivery date, follow it with “our team will come back to you about the partial delivery,” and escalate to the responsible person at the same time.

What you must not do is ignore the L3 part, answer only the L2 part, and close the conversation. From the customer’s side, that leaves room to read the silence as “they did not raise it because partial delivery is fine.” Do not build a design in which silence looks like consent.

One more thing. Do not make the escalation destination an inquiry form. The customer has already written the request in chat. Making them type the same thing again into a form makes the experience worse than it was before automation. Put what the bot collected straight into the queue of the responsible person. L3 intake includes that final step.

As the figure sets out, the three layers are ordered not by difficulty but by whether a wrong answer can be taken back. L1 can be restored with a correction, L2 lands after the customer’s plan has already moved, L3 binds the company. That order is also the order in which you should push automation forward.

Out-of-authority answer rate: measure it before containment rate

The standard chatbot metric is the containment rate, the share of conversations completed without handing over to a person. It appears in almost every vendor proposal. For an internal bot, that is fine. For a customer-facing bot, there is a different metric you should measure first.

The definition, and how to count it across 100 logs

Out-of-authority answer rate = the number of cases in which the bot returned a definitive answer to a question belonging to L3, divided by the number of logs sampled.

Measuring it requires no system. The following steps are enough.

1. Pull 100 recent conversation logs at random.
2. Read them one by one and check whether the conversation contains an L3 question (feasibility, price, spec change, complaint).
3. If it does, check whether the bot’s answer was definitive (“we can”, “we cannot”, “it will be…”).
4. There is only one test. “If a sales representative sent this exact wording to the customer by email, would it stand as a statement from the company?” Mark the ones that would not.
5. Divide the number of marked cases by 100. That is your out-of-authority answer rate.

Two people split 100 logs and read them. That is the whole exercise. Repeat it once a month with the same procedure. No special tooling and no vendor dashboard is required. Excel and a log export function are enough.

Some cases will be genuinely hard to judge. When in doubt, mark them. For a customer-facing bot, treating grey as black is the safe side.

Why you should not raise the containment rate first

The work of raising the containment rate consists of making the bot answer questions that used to be handed to a person. Widening the answering scope, cutting confirmation steps, tightening the conditions under which the bot replies “let me check with our team.” All of it points the same way.

Do that while the out-of-authority answer rate is above 0%, and here is what happens. The only thing that speeds up is the rate at which you issue answers the company cannot stand behind. One out-of-authority answer in 100 becomes three in 100 once the scope widens, that is 3% of every conversation the bot handled. And those are precisely the ones a human used to stop.

So fix the order.

• Stage 1: measure the out-of-authority answer rate. If it is not 0%, drive it down by narrowing the scope, loosening the escalation conditions, or banning definitive phrasing.
• Stage 2: once the out-of-authority answer rate is 0%, go after the containment rate.
• Stage 3: after raising it, measure the out-of-authority answer rate again. If it has risen, go back to Stage 1.

That order is the practical conclusion of this article. Run it in reverse and the metric that looks like progress, the containment rate, is the only one that moves, while risk accumulates without ever becoming visible.

One clarification. An out-of-authority answer rate of 0% does not mean the bot is clever. In most cases it is the result of having narrowed the scope correctly. A narrow bot is worth more than a broad, dangerous one, because what the customer wants is not conversational skill but correct information.

Cost and payback for a customer-facing chatbot: a model calculation for a Thai plant

From here we work in numbers. This is a calculation built on stated assumptions, not your company’s actuals. Even so, the structure shows which numbers matter and which do not.

One note on scope: the calculation assumes inquiries have been steered towards chat, and applies the automation rates to the full case counts in each layer. If phone inquiries remain, discount the benefit by that share as you read.

The model company and its current cost (753,300.00 THB per year)

A Japanese-owned automotive parts manufacturer in Chonburi Province, Thailand. 180 employees, 50 trading customers, 24 business days per month.

Every benefit figure in this article is calculated against this 753,300.00 THB per year as the single baseline. The same saving is never counted both as an offset to the initial investment and as a recurring annual benefit.

L2 takes as long as 14 minutes per case because you open the core system, look up the order number, and then go back and forth with production control or the shipping team. Simply transcribing a value from a screen would not take that long. Most of those 14 minutes is time spent asking other people.

Look at the weight of each layer. L2 is 45% by volume, and by hours it is 126.0h out of 279.0h, roughly 45%. L3 is only 15% by volume but takes 105.0h out of 279.0h, roughly 38%. L1 is 40% by volume yet accounts for only 48.0h out of 279.0h, roughly 17%. L1, the largest layer by volume, is in fact not eating much of the workload. Miss this at the outset and you end up reasoning that “FAQs are the biggest bucket, so start with FAQs,” and landing on a small result.

Converted to cost per case, L1 is 22.50 THB (6 minutes x 225 divided by 60), L2 is 52.50 THB and L3 is 131.25 THB. Separately, the reason chatbot quotations should be compared per response rather than by monthly fee is set out in Chatbot costs 2026: compare per response, not per month. This article does not deal with the methodology of cost comparison itself.

Comparing Type A, Type B and Type C

Split the automation scope into three types.

• Type A: automate L1 only (70% of L1 contained)
• Type B: L1 (70%) plus L2 (60%), with read-only reference to the core system
• Type C: L1 (70%) plus L2 (75%) plus L3 intake (8 minutes saved per L3 case, with no yes-or-no answers)

All figures are in THB. Payback period is initial investment divided by net benefit per year.

Three things can be read from this.

First, Type A is weak as an investment. Saving 403.2h a year is only about 12% of the 3,348.0h annual workload, and against a gross benefit of 90,720.00 THB the running cost is 60,000 THB. Only 30,720.00 THB of net benefit is left, and payback takes 5.86 years. Automating L1 alone should be evaluated as an experience question, letting customers download a form at any hour of the day, rather than as a return-on-investment question.

Second, Type B pays back fastest. Saving 1,310.4h a year is about 39% of the annual workload. Against a net benefit of 150,840.00 THB, the initial investment of 520,000 THB pays back in 3.45 years. It is the only one of the three types that comes in under four years.

Third, Type C saves the most hours yet pays back the slowest. Saving 1,825.2h a year is about 55% of the annual workload, and the gross benefit of 410,670.00 THB is the largest of the three. Even so, once you subtract the running cost of 264,000 THB, the net benefit is 146,670.00 THB, below Type B’s 150,840.00 THB. The initial investment is 980,000 THB, roughly 1.9 times Type B. The result is a payback period of 6.68 years.

As the figure shows, initial investment and annual net benefit are not proportional. Increasing the investment causes net benefit to plateau at Type B and actually fall at Type C. The next section breaks down why.

Why the increment to Type C does not pay back

Comparing Type B and Type C as two separate options leads to the wrong decision. Type C contains Type B, so the correct way to look at it is to isolate the increment and evaluate that on its own.

The added portion is negative on an annual basis. It is not that the payback period is long. It does not pay back. Without recovering a single baht of the 460,000 THB initial investment, a shortfall of 4,170.00 THB accumulates every year.

Look inside the increment. The gross benefit of +115,830.00 THB is the sum of two items. Raising the L2 automation rate from 60% to 75% accounts for 226.8h a year (= 51,030.00 THB), and the 8 minutes saved per case through L3 intake accounts for 288.0h a year (= 64,800.00 THB). Together that is 514.8h a year, worth 115,830.00 THB.

The added running cost, meanwhile, is 120,000 THB a year. Divide that by the 514.8h saved and you get roughly 233 THB per hour, above the 225.00 THB hourly rate of sales administration. You are substituting for human work at a running cost higher than the human.

The ceiling at which the increment breaks even is a running cost equal to the gross benefit, +115,830.00 THB per year. The actual +120,000 THB exceeds that by about 3.6%. The gap is 4,170.00 THB a year, small in absolute terms. That is exactly what makes it awkward. On paper the proposal can honestly claim that “the benefit increases” and “hours saved are the highest,” while the fact that the increment is negative is invisible in the totals table.

Why does only the running cost jump? Because what the additional external-facing automation carries is not the cost of producing answers.

• Monitoring: people periodically reading back the answers that were issued. Measuring the out-of-authority answer rate is part of this.
• Multiple languages: the cost of maintaining answer wording in Japanese, English and Thai. As you add customers, you add languages.
• Audit logs: the cost of storing who was told what, and when, in a form that can be retrieved later.

None of these scale with the automation rate. They scale with the breadth of the scope. The moment you add L3 intake, the conversations under monitoring expand from “conversations that returned facts” to “conversations involving human judgment,” and the unit cost of reading them back goes up. The same applies to languages. Putting an L1 FAQ into three languages is one thing. Running L3 intake questioning in three languages without it breaking down is a much heavier maintenance burden.

None of this rejects Type C. It only says that trying to justify Type C on return on investment will fail. If there is a reason to choose Type C, it lies in objectives that are not in this calculation, such as giving customers a first response around the clock to avoid lost opportunities, or eliminating missed rush requests. In that case, choose it in full knowledge that the increment is negative, and define and measure a different benefit. Push the approval through under the banner of hours saved, and you will have nothing to say in year two.

Sensitivity analysis: what makes Type B work is the lookup path on the core system side

Type B’s payback of 3.45 years assumes that 60% of L2 is contained. Here is what happens when that assumption breaks.

Figures in THB. The L1 automation rate of 70%, the initial investment of 520,000 THB and the annual running cost of 144,000 THB are held constant.

Dropping from 60% to 40% stretches payback from 3.45 years to 6.28 years, an increase of 2.83 years. That 6.28 years is slower than Type A’s 5.86 years. Type B, at nearly three times the investment, falls below Type A on payback purely because L2 does not move.

As the curve in the figure shows, payback does not move linearly with the L2 automation rate. Around 40% the slope is steep, and a small difference matters a great deal. Towards 70% the slope flattens. The pain of the downside is greater than the room on the upside.

So what determines the L2 automation rate? Not the eloquence of the answers. It is whether a machine can uniquely resolve the number the customer actually uses.

Three things commonly block this in practice.

1. The number the customer quotes is not the number you use internally. Customers write their own PO number. Your core system manages things by your own order number. If that mapping table is not in the master data, the bot can look up nothing. Human staff bridge the gap from experience, so this disconnect is invisible in day-to-day operations.
2. One number carries multiple line items. A single PO covers several part numbers, each with a different delivery date. “When is PO-24817 due?” has no unique answer. Unless you decide in advance whether to return the latest date or list every line item, the bot will cheerfully return just one of them.
3. There is a lag before shipping status reaches the core system. It is not unusual for goods to have left yesterday while the system only reflects it on the morning of the next business day. Answer “it has not shipped yet” in that state and the answer contradicts the facts.

None of these belong to the chatbot implementation project. They are core system housekeeping. That work comes first. Put the other way round, in a company where these three points are already in order, Type B will come up faster than expected. Check your own master data and interfaces before you select a vendor.

Channel design: LINE in Thailand, Zalo in Vietnam

Which channel you put the bot on is not a question of features. It is a question of records.

Design on the assumption that the first point of contact is LINE

In Thailand, LINE is effectively the first point of contact. According to DataReportal’s “Digital 2026: Thailand”, LINE had 56 million monthly active users in Thailand as of October 2025. That is 78.2% of the total population of 71.6 million, and 82.6% of the 67.8 million internet users (94.7% of the population).

This is not only a consumer phenomenon. In B2B as well, messages land directly in an individual purchasing officer’s LINE. You can ask people to send it by email, but anything urgent still arrives on LINE.

In this article’s model plant, the channel mix is 55% email, 30% phone and 15% LINE, which is 180 cases a month arriving via LINE. (The fact that L3 judgment in the three-layer model is also 180 cases a month is a coincidence of both ratios being 15% of 1,200 cases. The two are different cuts of the data, so do not conflate them.)

The first thing to settle in channel design is not the order in which you roll channels out. It is which channels’ conversations land in the system of record. Measuring the out-of-authority answer rate requires the logs to be in one place. Add channels first and try to consolidate records afterwards, and there will always be a channel that never gets consolidated.

How to build and differentiate the three languages of Japanese, English and Thai, and how much to keep common between them, is covered in Chatbot implementation costs and rollout: multilingual support for a Thai plant. Here we touch on multilingual support only as one of the factors that push up Type C’s running cost.

The problem of conversations to personal accounts falling outside the record

Put the bot on LINE and one thing is almost certain to happen. Customers will message a staff member’s personal LINE rather than the official account.

It is faster that way. And the staff member helpfully answers. What they say never enters the company’s records. If that person leaves, the whole exchange leaves with them. You are spending money on audit logs while the actual promises sit on someone’s personal handset. This is far from unusual.

Introducing a chatbot does not resolve this problem. It makes it visible. The official account’s logs fill up with questions about business hours, while the delivery date commitments live in personal LINE threads. Measure the out-of-authority answer rate and the dangerous conversations never make it into your sample.

The remedy is operational, not technical. At minimum, settle these three points.

• Tell customers explicitly that the official account is the first point of contact. Put it on business cards, order acknowledgements and email signatures.
• Decide on a routine for staff to copy business messages received on personal LINE into the official channel. It will never be followed perfectly, but more will survive than with no rule at all.
• Always issue answers about delivery dates, shipments and invoices through the official channel or by email. On personal LINE, reply with a pointer to the official account. This adds work for the staff member, so it needs to be supported on the performance evaluation side.

If you have a site in Vietnam, the same structural problem appears. Zalo occupies an equivalent position there, and VNG’s Q2 2026 results report 81.3 million monthly active users, 2.2 billion messages per day and around 30,000 official accounts. The platform differs, but the shape of the problem, conversations to personal accounts falling outside the company’s records, is the same.

What to check first about personal data handling

If the chatbot receives customer names, contact details and order content, and sends them to an LLM hosted in an overseas region, the question of cross-border transfer arises.

Under Thailand’s PDPA, two notifications on cross-border transfer were published on 25 December 2023 and took effect on 24 March 2024 (commentary by TMI Associates, in Japanese, commentary by Tilleke & Gibbins, in Japanese).

This article does not attempt any legal interpretation. It goes no further than noting that this exists as an issue to be checked. In practice, the points worth confirming with legal counsel or an outside specialist early in the project are these.

• Which country’s region stores the conversation data, and in which country it is processed. Get the vendor’s answer in writing rather than verbally.
• What the transfer is grounded on, whether that is a country with an adequate level of protection, contractual clauses or another mechanism.
• Whether the contract states that conversation data will not be used to train models.
• The retention period and the deletion procedure. Keeping audit logs for a long time and not holding personal data for a long time frequently pull against each other.

Leave this check until later and you may need a change of region or vendor after development is finished, which breaks the assumptions behind the initial investment. It belongs to the category of work best cleared before requirements definition.

Seven items to settle before you start (checklist)

These are the items to settle internally before you approach a vendor. With these decided, comparing proposals becomes much faster.

1. Build the L3 list. Write out 20 concrete example questions that the bot must not answer. Not abstract categories, but the actual wording that has come in. Collect them from sales, quality assurance and logistics, and you will discover that departments do not agree with one another.
2. Decide the escalation destination and the response time. When an L3 arrives, whose queue does it enter, and within how many hours does a person reply? If “our team will check” turns into the next day, you are better off not automating.
3. Decide where the system of record for logs lives. Multiple channels are fine, but the log lives in one place. Out-of-authority answer rate sampling comes from there.
4. Verify the lookup path on the core system side. Can you resolve your own order number from the customer’s PO number? Have you decided how to respond when one number carries several line items? How many hours behind is the reflection of actual shipments?
5. Decide the standard elements attached to every answer. Source document name and last revision date (L1), the as-of time of the information (L2), the deadline for coming back (L3). Embed all three into the wording templates.
6. Decide who measures, and how often. Once a month, 100 logs, two people reading. Decide it by name. Without a name against it, it stops within two months.
7. Confirm personal data handling with legal. Storage region, grounds for transfer, whether training use is permitted, retention period. Confirm before vendor selection.

Of these seven, items 1, 2, 3 and 6 can be settled internally. They are the parts you can start on today, before any vendor is chosen.

Frequently asked questions

How much does a customer-facing chatbot cost?

In the calculation for this article’s model plant (180 employees, 1,200 inquiries a month), the initial investment ranged from 180,000 to 980,000 THB and the annual running cost from 60,000 to 264,000 THB. The breadth of scope is what moves the figure most. That said, this is a model built on assumptions, not a quotation for your company. When you compare quotations from several suppliers, convert them to a cost per response and align the units before comparing, rather than comparing monthly totals.

Is it acceptable to automate delivery date answers?

It is possible, with conditions. Reference the core system read-only, attach the as-of time of the information to the answer, and hand over to a person rather than guessing when the lookup fails. If those three are implemented, there is considerable value in automating this as L2. In the calculation in this article, the largest net benefit after running costs, and the fastest payback, both came from Type B, which includes L2. Type C is the one with the highest hours saved and the highest gross benefit. Conversely, start without a path that uniquely resolves the customer’s PO number and you will be left with the running cost and no benefit.

Can we combine internal and external use in a single chatbot?

Technically yes, but keep the metrics and the operating routines separate. Internal use can be evaluated on containment rate, and a wrong answer costs rework. External use needs the out-of-authority answer rate looked at first, and a wrong answer becomes a promise. Put the same metrics on the same screen and the external risk looks diluted by the internal performance. If you do combine them, at minimum make sure the logs can be extracted separately.

Is translating the Japanese version enough for a Thai chatbot?

For L1 fixed answers, translating and keeping the versions aligned works. From L2 onwards, you need to check case by case whether the formats of values returned by the core system, such as dates, quantities and item names, hold up in each language. Multiple languages are also an item whose maintenance cost grows with the breadth of the scope. That was one of the reasons the running cost jumped in Type C in this article. Budget for it as the operating cost of realigning every language each time the wording is revised, not as a one-off translation fee.

What should we look at when judging case studies?

Look at how the case study describes the range it refused to automate, rather than at containment rates or hours saved. A case study with no description of scope tells you nothing about the conditions under which the success can be reproduced. Also, do not apply another company’s reduction percentage to your own expected benefit. The benefit is determined by the layer breakdown of your inquiries and the time each one takes, so even within the same industry a different mix produces a different result.

Are external forecasts useful for decision making?

They are useful as reference, but not as your own expected benefit. In an announcement dated 5 March 2025, Gartner predicts that by 2029 agentic AI will autonomously resolve 80% of common customer service issues without human intervention and cut operational costs by 30%. That is a market forecast from an outside organisation, and the figure has no relationship to the model calculation in this article. Do not mix it with the numbers for Types A to C here.

Our management is telling us to bring in AI quickly. How should we proceed?

Cut the scope narrow and decide the metric before you start. In a Gartner survey of 321 customer service leaders conducted from September to October 2025 (published on 18 February 2026), 91% answered that they were under pressure from management to implement AI. In other words, whether to do it is no longer the question. The question is how to set the scope while under that pressure. Start without deciding the scope and you are left with a bot that was built broad and cannot be switched off.

Where should we start with making inquiry handling more efficient?

Start by classifying one month of inquiries into L1, L2 and L3, and measure the actual volumes and the time per case. In this article’s model, L1 accounted for 40% of volume but only about 17% of hours, while L3 at 15% of volume took about 38% of hours. Work through them in order of volume and you land on a small result. Once the classification is done, the layer worth investing in decides itself.

Summary

Designing a customer-facing chatbot starts not with what you let it answer, but with what you refuse to let it answer. The key points of this article are as follows.

• An internal wrong answer costs rework, while an external wrong answer is treated as a promise the company has made. Design on the assumption that “the AI said it” may not get you out of it.
• Split answering authority into three layers, L1 (static documents), L2 (reading the core system) and L3 (human judgment), and keep the bot out of L3. At L3 the bot can take intake and nothing more. It never answers yes or no.
• Measure the out-of-authority answer rate before the containment rate. People read 100 logs and judge each one by asking whether the same wording, sent by a sales representative by email, would stand as a statement from the company. Do not raise the containment rate until it reaches 0%.
• In the model calculation, against a current annual customer response cost of 753,300.00 THB, Type B, which automates L1 plus L2, is fastest with a net benefit of 150,840.00 THB and a payback of 3.45 years.
• Type C, with the broadest scope, saves the most hours (1,825.2h a year) yet takes 6.68 years to pay back. Isolate the increment from B to C and it is -4,170.00 THB a year, so the added portion does not pay back. The reason is that additional external-facing automation carries the cost of not giving wrong answers, and that cost scales with the breadth of the scope.
• Whether Type B works depends on whether a machine can uniquely resolve delivery dates, stock and shipping status from the number the customer uses. If the L2 automation rate falls to 40%, payback becomes 6.28 years, slower than Type A’s 5.86 years.
• The first point of contact is LINE in Thailand and Zalo in Vietnam. Before going live on a channel, decide which channels’ conversations land in the system of record.
• Cross-border transfer of personal data exists as an issue to be checked before requirements definition.

At TOMAS TECH, we provide system development and business system implementation support for Japanese-owned manufacturers in Thailand. For customer-facing chatbots too, rather than jumping straight into a development discussion, we start by classifying one month of your inquiries into L1, L2 and L3 with you, and looking together at how much is being spent on each layer. Early-stage questions are entirely welcome, such as “we are not sure whether the assumptions behind Type B hold in our case” or “we want to know what needs to be prepared on the core system side.” Please get in touch through our contact form. We work in Japanese, English and Thai.

References

• Gartner, “Gartner Predicts Agentic AI Will Autonomously Resolve 80% of Common Customer Service Issues Without Human Intervention by 2029” (5 March 2025)

https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290

• Gartner, “Gartner Survey Finds 91% of Customer Service Leaders Under Pressure to Implement AI in 2026” (published 18 February 2026, survey of 321 leaders conducted from September to October 2025)

https://www.gartner.com/en/newsroom/press-releases/2026-02-18-gartner-survey-finds-ninety-one-percent-of-customer-service-leaders-under-pressure-to-implement-ai-in-2026

• McCarthy Tetrault, “Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot”

https://www.mccarthy.ca/en/insights/blogs/techlex/moffatt-v-air-canada-misrepresentation-ai-chatbot

• CBC News, “Air Canada found liable for chatbot’s bad advice on bereavement rates”

https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416

• DataReportal, “Digital 2026: Thailand”

https://datareportal.com/reports/digital-2026-thailand

• TMI Associates, commentary on the notifications on cross-border transfer under Thailand’s Personal Data Protection Act (in Japanese)

https://www.tmi.gr.jp/eyes/blog/2024/15449.html

• Tilleke & Gibbins, commentary on Thailand’s cross-border personal data transfer rules (in Japanese)

https://www.tilleke.com/ja/insights/%E3%82%BF%E3%82%A4%E3%81%AE%E8%B6%8A%E5%A2%83%E5%80%8B%E4%BA%BA%E3%83%87%E3%83%BC%E3%82%BF%E7%A7%BB%E8%BB%A2%E8%A6%8F%E5%88%B6/

• VNG / Zalo user numbers (Q2 2026)

https://www.vietnam.vn/en/zalo-dat-81-3-trieu-nguoi-dung-voi-2-2-ty-tin-nhan-moi-ngay

Note: the model calculation in this article is a worked example based on the stated assumptions. Actual results vary with the layer breakdown of inquiries, the handling time per case and the state of the core system.