Chatbot Case Studies – 4 Patterns for Factories in Thailand

Search for chatbot case studies and you get a wall of impressive numbers — deflection rates, ticket volumes, hours saved. Look closer and almost all of them come from domestic Japanese call centres or from Western B2C companies. Very little of it transfers to a manufacturing site in Thailand where the majority of the workforce speaks Thai. So instead of listing named-company success stories, this article covers the four implementation patterns we are asked about most often in our day-to-day factory IT work. For each pattern you get the target workload, the problem it replaces, the conditions under which it actually pays back, the mistakes that keep recurring, and a realistic cost band. Decide which pattern you are in first, and product selection becomes a much easier conversation later.

Why someone else’s chatbot case study does not transfer to your site

Case study articles are hard to use because they publish the outcome and omit the preconditions that produced it. “Inquiries dropped 30 percent” tells you nothing about how many inquiries there were per month, who was asking and in what language, or how many source documents the answers were drawn from. Change those preconditions and the same product with the same configuration produces a different result.

Across the sites we support, what separates success from failure is almost never the capability of the product. It is where the inquiries sit on three axes.

• Who is asking. Every employee, or only production floor operators, or a mix that includes Japanese expatriate staff.
• What the answer is grounded in. A single set of policies, or a mix of equipment manuals and historical corrective-action records.
• How long an answer stays valid. Unchanged for years, or rewritten several times a year as laws and benefit schemes change.

Cut the population of inquiries along those three axes and implementation projects at Japanese-owned manufacturers in Thailand separate cleanly into four patterns. The rest of this article walks through them in turn.

Where the external numbers stand in 2026

Before the patterns, it is worth fixing the current external picture. Industry survey numbers should be read at arm’s length, but they are useful background when you are arguing for a budget internally.

Deloitte’s “State of AI in the Enterprise 2026,” fielded between August and September 2025 among 3,235 IT and business leaders across 24 countries, found that 74 percent of respondents expect their organisation to be using AI agents by 2027. Only 21 percent said they had mature governance in place for agentic AI. The survey documents a wide gap between the appetite to deploy and the readiness to control what has been deployed.

McKinsey’s June 2023 report “The economic potential of generative AI – The next productivity frontier” analysed 63 use cases spanning 16 business functions and estimated that generative AI could produce USD 2.6 trillion to 4.4 trillion in annual economic value. Customer operations accounts for a large share of that total. Two caveats matter — the estimate dates from 2023, and it describes potential value rather than value realised.

Trade coverage of McKinsey’s more recent “State of AI” survey reports that 88 percent of responding organisations use AI regularly and that generative AI use has reached 72 percent, up sharply from 33 percent in 2024. Yet close to two-thirds of respondents have not reached the stage of scaling AI across the enterprise. On agents specifically, 62 percent remain in experimentation and only 23 percent have moved to full deployment. Fifty-one percent of respondents reported experiencing some negative consequence, and 30 percent cited inaccuracy of outputs.

Gartner, in a press release dated 25 June 2025, predicted that more than 40 percent of agentic AI projects will be cancelled by the end of 2027. The reasons given are escalating costs, unclear business value, and inadequate risk controls. The same release describes “agent washing” — rebranding existing products as agents — and estimates that of the thousands of vendors in the market, only around 130 are genuine.

Adoption is moving; governance and payback design are where projects stall. That is the 2026 picture in one sentence. The four patterns below are an attempt to make the payback design concrete, one pattern at a time.

Pattern 1 — Internal FAQ and policy lookup, the usual first project

The most common first deployment is a bot that tells employees where policies and forms live and what they say.

What it handles

How to check remaining annual leave, the cut-off date for expense claims, where the travel request form lives, how to book the annual health check. Questions whose answer is written down, definitively, in one document. A substantial share of everything that reaches general affairs and IT falls into this bucket.

Two properties define this pattern. The set of question types is finite, and the evidence behind the answers is closed inside a single body of documents — work rules and the internal policy manual. That is precisely why the build is light.

The problem it replaces

The situation we see repeatedly at Thai sites is that the policies themselves are perfectly well maintained, but employees have no idea where they are. Shared folders are nested several levels deep, and revision history shows up as filenames like “latest,” “latest 2” and “final,” so only the document owner knows which one is in force. The rational employee response is to stop searching and ask general affairs instead, because asking is faster.

The second problem is key-person dependency on the answering side. When one person is the only one who reliably knows which version is current, inquiries stall whenever that person is on leave.

When it actually pays back

This pattern delivers when the following conditions hold.

• Monthly inquiry volume exceeds roughly 700. Below that you will not reach the break-even discussed later in this article.
• Policies in scope have been consolidated into a single current version, with a named owner for revisions.
• Someone is explicitly responsible for updating the chatbot whenever the authoritative version of an answer changes.

Skip the third condition and six months later you own a machine that confidently returns obsolete answers. The discipline of treating internal inquiries as a problem of “which version of the answer is authoritative” is the foundation of any helpdesk automation project, and it is covered in more depth, down to how to build the register, in our article on automating the internal helpdesk.

Where it goes wrong

The most frequent mistake is loading far too many FAQ entries at launch. Prepare 300 questions and you will still find that the top 30 account for 60 to 70 percent of everything asked. The other 270 add maintenance load and, worse, become the entries that quietly go stale when a policy is revised.

The second most frequent mistake is underestimating variation in how people phrase questions. A scenario-based bot does not work out on its own that “annual leave,” “paid holiday,” “ลาพักร้อน” and the Japanese equivalent all refer to the same entitlement. If synonym registration is not built into your operating routine, first-month self-service rates land at roughly half of what was projected.

Choose a generative AI approach and the failure mode inverts. Publish without implementing source citation and plausible-sounding wrong answers start circulating as though they were policy. In the policy domain, attaching the source clause reference to every answer is a design precondition, not an enhancement.

Cost band

For a scenario-based FAQ bot, budget THB 80,000 to 150,000 for the initial build and THB 220,000 to 300,000 per year to run. That annual band covers the platform subscription, the amortised share of the build, and the internal maintenance effort the system generates.

The method of building cost up in layers is covered in our article on chatbot cost structure, which breaks the total into five layers. When comparing quotations side by side, make sure every number covers the same layers. Some vendors include integration with existing systems in the build fee and some do not.

Pattern 2 — Multilingual helpdesk, where a Thai language chatbot is really tested

This is the pattern with the largest demand among Japanese manufacturers in Thailand, and simultaneously the hardest to execute.

What it handles

A helpdesk that takes the same question in Thai, English and Japanese and returns the same substance in each. Thai employees ask in Thai, Japanese expatriates ask in Japanese, managers of other nationalities ask in English. Meanwhile the policies those answers rest on typically exist as a Japanese head-office version and a separate Thai work-rules document, with the English version reduced to a summary.

The language of the question does not match the language of the evidence. That mismatch is the real technical problem behind any multilingual chatbot.

The problem it replaces

The recurring failure at Thai sites is answers that diverge by language. The Japanese head-office policy gets revised, and it takes months for the change to reach the Thai work rules. In between, someone who asked in Japanese and someone who asked in Thai received different answers. As long as humans are answering, an experienced coordinator quietly corrects for the gap from memory. The moment you put it on a machine, the divergence is published automatically and at scale.

The other problem is a linguistic bottleneck in first-line response. At a site where general affairs has exactly one Thai staff member who is fluent in Japanese, every inquiry funnels to that person, who becomes a single point of failure in practice.

When it actually pays back

• For each policy document, it is decided which of the three language versions is authoritative.
• Model numbers, equipment names, internal jargon and the proper names of benefit schemes are managed as a do-not-translate list.
• There is a mechanism for measuring self-service rates by language. A blended average hides weak Thai performance behind strong Japanese performance.

Where the translation should happen in the stack — duplicating the FAQ per language, translating only the incoming question, or searching with multilingual embeddings — is compared across three approaches in our chatbot implementation guide. Read that alongside the pattern framework here and the configuration you need narrows quickly.

Where it goes wrong

The single biggest error is running acceptance testing on Thai retrieval against the same threshold used for Japanese. Thai is written without spaces between words, so word segmentation accuracy directly drives retrieval hit rate. A configuration that scores 90 percent correct answers in Japanese can fall into the 70s in Thai. If you have not measured that gap before go-live, Thai-speaking employees abandon the tool very quickly after launch.

The second is a cost miscalculation. Languages that do not use the Latin alphabet consume substantially more tokens for the same meaning. A phrase that fits into four or five tokens in Japanese or English can consume 15 to 20 or more in Thai, and under consumption-based pricing the cost of non-Latin languages can run three to eight times higher. Extrapolate an annual budget straight from the measured figures of a Japanese-language proof of concept and you will overshoot in production.

Multilingual chatbot technology keeps widening its coverage of Southeast Asian languages, but a language appearing on a vendor’s supported list and that language producing usable accuracy against documents full of your own internal terminology are two different claims. Judge on a test using your own documents, not on the vendor’s language table.

Cost band

Because cross-language retrieval across three languages is required, this pattern is normally built as generative AI combined with retrieval-augmented generation. Budget THB 400,000 to 600,000 for the initial build and THB 700,000 to 800,000 per year to run. What pushes this band upward is document preparation cost plus the consumption-based overshoot on Thai.

One further point. Conversation logs will contain employee names and staff numbers. Enforcement of Thailand’s personal data protection law is now in a serious phase, so log retention periods, whether logs may be used for training, and who may access them all need to be decided at the design stage.

Pattern 3 — Shop floor troubleshooting, which cannot start without documents

This pattern takes inquiries from the production floor. The upside is large, but the entry requirements are far tougher than for the others.

What it handles

What an equipment alarm code means, how to perform first-line isolation when a line stops, how often a consumable should be replaced, what was done last time the same symptom appeared. The askers are operators and maintenance technicians. At sites with no Japanese engineer present on the night shift, this pattern is worth disproportionately more.

The problem it replaces

Shop floor inquiries are not high in volume. What makes low volume serious is that the cost per incident is large. While the line is down, there is a stretch of time in which nobody knows who to ask, and that stretch converts directly into loss.

The structural problem is that the evidence behind the answers was never written down. Equipment manuals sit on a shelf in their original English or German, while the actual remedies live in the head of one veteran maintenance technician. Historical corrective-action records are in paper files or scattered across departmental spreadsheets.

When it actually pays back

• One to two years of corrective-action records have been digitised as symptom, cause and remedy sets.
• The relevant sections of equipment manuals can be retrieved by machine model and type number.
• There is a usable input method from a shop floor terminal. Gloved hands cannot type, so you need voice input or a selection-based narrowing interface.

The first condition is the real gate. Requesting chatbot quotations before the corrective-action records have been digitised means buying a box with no answers in it.

Where it goes wrong

The most common error is planning without counting the document preparation effort as part of the cost. Digitising and structuring corrective-action records takes months and a real labour bill, depending on scope. It is not unusual for that upstream work to cost more than the chatbot build itself.

The second is measuring the wrong thing. Evaluate this pattern on “reduction in inquiry volume” and you will almost certainly conclude that it cannot pay back. Shop floor inquiries are few, so even if you eliminate the equivalent of THB 40 of first-line handling effort per inquiry, you never reach the annual running cost. What this pattern should be measured on is not volume but downtime reduction. If time to reach first-line isolation drops from 20 minutes to 5 minutes, the value is those 15 minutes multiplied by the hourly loss rate of the line.

Because the proportion of tacit knowledge is high, the self-service ceiling is also lower here than in the other patterns. Plan on it topping out around 30 to 40 percent, and design the handoff path to a human for the remainder from day one.

Cost band

The chatbot itself runs THB 300,000 to 500,000 to build and THB 450,000 to 600,000 per year to operate. As noted, preparing corrective-action records and work instructions is a separate line item. Before you request quotations, establish what format your corrective-action records are currently in and how far back they survive. Until that is settled, no vendor can produce an accurate quotation.

Pattern 4 — HR and back office, high value but it needs review

The fourth pattern handles questions about HR policy and social security.

What it handles

Social security benefit claims, how severance is calculated, eligibility for maternity and parental leave, procedures tied to residence registration, how to complete various application forms. It resembles Pattern 1 at first glance, but the difference is decisive — the answers rest not only on internal policy but on Thai labour law and the social security system.

The problem it replaces

Answers in this domain have a short shelf life. Every time a law is amended or a scheme is switched over, the correct answer is rewritten. Worse, questions cluster around the changeover date itself, of the form “if I apply next month, which scheme applies to me.”

Individual agreements complicate matters further. Where an employee’s individual employment contract carries terms different from the general rule in the work rules, an answer grounded only in the general policy is simply wrong.

When it actually pays back

• Scheme changeover dates are documented explicitly, as which scheme applies from when to when.
• Employees with individual agreements can be defined as a condition under which the machine does not answer and routes to a human instead.
• There is a review process in which a person checks HR answers before they are published.

The third condition is the one most often dropped, and in this domain it is mandatory. The risk of generative AI helpdesks producing answers that are factually wrong has been repeatedly flagged, and commentators specifically warn against publishing without a review process in areas like HR policy where an error translates directly into financial detriment for an employee. If a machine incorrectly declares someone eligible or ineligible for a benefit, issuing a correction does not restore trust.

Design thinking specific to the HR domain is covered in our article on AI for HR inquiries.

Where it goes wrong

The failure unique to this pattern is evaluating it on “answers given.” Most HR and general affairs inquiries end in the submission of a form. The machine can explain the scheme perfectly, but if the wrong form is filed the submission bounces back and the coordinator’s workload has not moved.

For that reason this pattern is better measured not on answer accuracy alone but on whether the employee was routed to the correct form. Measured on “answered,” self-service comes out at 50 to 60 percent. Measured on “guided to the correct application,” it can exceed 70 percent. Same system, different metric, materially different view of the payback.

The second issue is seasonal concentration. Inquiries in this pattern spike around year-end tax adjustment and bonus periods. Calculate break-even from an annual average and you will understate the real reduction in peak load.

Cost band

Budget THB 150,000 to 250,000 for the initial build, plus THB 60,000 to 200,000 on top where integration with an existing HR system is required. Annual running cost is THB 300,000 to 450,000. Because integration swings the number so heavily, decide up front whether you will include employee-specific answers such as remaining leave balance lookups. Leave them out and the cost lands close to Pattern 1.

Comparing the four patterns — ceilings and break-even volumes

Here are the four patterns side by side from a payback perspective. The self-service ceilings are design-level guidance based on what we observe at the sites we support; they are not published statistics from a research firm. The break-even volumes are derived from an assumed THB 40 per human-handled inquiry, which is 8 minutes at an hourly rate of THB 300.

The number to notice is the break-even for Pattern 3 at roughly 2,700 inquiries a month. Essentially no factory receives 2,700 shop floor inquiries in a month. Pattern 3, in other words, is structurally incapable of paying back on first-line labour savings alone. It can still be justified — but only because it is measured differently.

Once you know which pattern you are in, you also know which metric to build the approval request on. Conversely, if you leave that mapping undecided and apply “inquiry reduction rate” as a single uniform evaluation axis, the investment cases for Patterns 3 and 4 will be rejected every time.

The failure mode of collapsing all four patterns into one bot

This is the most frequent failure among the projects that reach us.

Someone decides that if the company is buying a chatbot anyway, it should do everything — internal FAQ, shop floor troubleshooting and HR inquiries, all on one bot. A single point of contact sounds good for users, and one licence looks cheaper than several.

But the four patterns differ in the documents behind their answers, in how often those documents change, in the accuracy demanded, and in the consequences of getting an answer wrong. Merge them and three things happen.

First, the accuracy standard of the strictest pattern drags everything else down. Because a benefit eligibility determination must not be wrong, the overall answering behaviour is made conservative. Soon a simple question about where to find a policy also gets “please confirm with the responsible department,” and Pattern 1 users walk away.

Second, ownership of updates dissolves. It becomes ambiguous whether general affairs, HR, production engineering or maintenance guarantees the authoritative version of any given answer, and the result is that nobody updates anything. Six months later all that remains is a machine returning stale answers.

Third, cost allocation becomes impossible. No department’s budget owns the running cost, and the line item floats unresolved into next year’s budget cycle.

The escalating costs and unclear business value that Gartner cites as reasons agentic AI projects get cancelled describe exactly this state. The way to avoid it is straightforward — stand each pattern up as its own separate service, and unify only the entry point afterwards. Presenting a single front door to users while keeping the knowledge bases and update ownership separate behind it is not technically difficult. The reverse order, integrating first and separating later, is effectively a rebuild.

Which pattern should you start with

When more than one pattern applies to your site, the choice of where to start determines whether the project succeeds. Here is the sequence we recommend.

Stage 1 — Choose the pattern

Start by actually collecting inquiries from the last three months — 100 of them is enough — and classifying each into one of the four patterns. Skip this and decide by feel that “we get a lot of shop floor questions,” and you will discover later that routine general affairs questions were in fact the overwhelming majority.

It is common for the classification to show that the pattern with the highest volume and the pattern with the highest loss per incident are not the same pattern. For the first deployment, choose the high-volume one. Payback is easier to demonstrate and the organisation banks a success. Pattern 3, with its high loss per incident, is realistically a second or third project.

Stage 2 — Proof of concept

Test the chosen pattern against 30 to 50 real questions. What you are verifying is not the product demo but accuracy against your own documents. Where more than one language is involved, always measure per language.

Run the proof of concept for four to six weeks. Shorter and you will not see the patterns of phrasing variation; longer and the production decision drags until the internal momentum is gone.

Stage 3 — Production

Launch production deliberately narrow in scope. Since the top 30 questions cover 60 to 70 percent of the total, there is no need to load everything on day one. Starting narrow and adding entries based on logs of unanswered questions keeps the maintenance burden far lighter.

Have the handoff path to a human ready from the first day of operation. Without it, users stop using the tool after a single failed attempt.

Stage 4 — Embedding it in the operation

The three to six months after go-live are, in practice, the most important period. The McKinsey finding that close to two-thirds of organisations have not reached enterprise-wide scaling is arguably the same phenomenon seen from the other side — a great many deployments stumble at exactly this embedding stage.

There are three things to do here. Review the log of unanswered questions monthly. Build the step of updating the chatbot into the procedure that runs whenever a policy is revised. And look at usage rates broken out by language and by department, then find out what is happening in the segments that are not growing.

Generative AI helpdesks are reported to achieve higher usage and satisfaction than scenario-based ones. That holds, though, only where the source documents are maintained and the update cycle is actually running. Without the operational discipline of the embedding stage, the choice of approach makes no difference.

For choosing the product category itself, our chatbot comparison guide compares four approaches in terms of what each is and is not suited to. Reading it after you have fixed your pattern and before you enter Stage 2 makes selection considerably faster.

Frequently asked questions

How should we start a chatbot project

Not by gathering product information. Start by collecting 100 inquiries from the last three months and classifying them. Once you know which of the four patterns you are in, the required features, the likely cost band and the evaluation metric are all determined at once. Watch a product demo before you classify, and the requirements end up shaped by whatever the demo happened to show.

What does a Thai language chatbot cost

For a three-language helpdesk that includes Thai, budget THB 400,000 to 600,000 for the initial build and THB 700,000 to 800,000 per year to run. There are two reasons this exceeds a Japanese-only configuration. First, the source documents have to be prepared in each language. Second, Thai does not use the Latin alphabet and therefore consumes far more tokens, which inflates the consumption-based portion of the bill. Converting the measured figures from a Japanese-language proof of concept straight into an annual budget will diverge from the invoices you actually receive.

How much will an internal FAQ chatbot reduce inquiries

The ceiling differs by pattern. For an internal FAQ bot pointing people to policies and forms, roughly 60 to 70 percent. Add multiple languages and it is mid-40s to 60 percent. For shop floor troubleshooting, 30 to mid-40s percent. These are the levels we see at the sites we support. They are design-level expectations rather than research firm statistics, but if you put a uniform 70 or 80 percent into an approval request across all patterns, you will almost certainly miss it.

Should we choose generative AI or a scenario-based bot

If the evidence is closed inside one document and the set of question types is finite, a scenario-based bot is sufficient. If answers require searching across multiple documents, or if the phrasing of questions cannot be predicted, generative AI is the better fit. But when using generative AI in the HR or policy domain, treat two things as preconditions — a design that always attaches the source citation to the answer, and a human review process before publication. In this domain, the risk of factually wrong answers translates directly into real harm.

Summary

When you read a chatbot case study, the thing to look at is not the reduction percentage but the preconditions that produced it. Who was asking, in what language, where the evidence sat, and how often that evidence was rewritten. If those three differ from your situation, the result will not reproduce.

Projects at Japanese-owned manufacturers in Thailand sort into four patterns — internal FAQ and policy lookup, multilingual helpdesk, shop floor troubleshooting, and HR and back office. Each has a different self-service ceiling, a different cost band, and a different metric for measuring payback. Pattern 3 in particular cannot structurally pay back on inquiry reduction and has to be measured on equipment downtime.

And do not try to collapse the four patterns into a single chatbot. Because the person accountable for the authoritative version of an answer differs by pattern, the realistic order is to keep the back ends separate and unify only the front door later. Stand up your first deployment on the highest-volume pattern, keep the scope narrow, and expand it by reading the logs of questions it could not answer. That is the path with the fewest failures.

Which pattern do your inquiries fall into, and are you at the volume where that pattern pays back? Those are two questions worth answering internally before you choose a product. As a factory IT integrator, we work on exactly this kind of inquiry triage at manufacturing sites across Thailand every day. Even if you are nowhere near selecting a product, we are happy to take exploratory questions — including how to go about classifying the inquiry data you already have. Get in touch through our contact page.

References

• Deloitte, “State of AI in the Enterprise 2026,” fielded August to September 2025 among 3,235 leaders across 24 countries — Deloitte US
• McKinsey Global Institute, “The economic potential of generative AI – The next productivity frontier,” June 2023 — McKinsey
• Trade coverage of the customer experience implications of McKinsey’s “State of AI” survey — CX Today
• Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027,” 25 June 2025 — Gartner Newsroom
• RICOH Chatbot Service, collected implementation examples by industry, in Japanese — RICOH
• Commentary on usage and satisfaction trends for generative AI helpdesks, in Japanese — SmartAT
• Hallucination risk in generative AI helpdesks and the need for a review process, in Japanese — Helpfeel
• Technology trends in multilingual chatbots — SiteGPT