When someone in the office says “we should put in a chatbot,” the first decision is not which product to buy. It is who builds it, and how far they build. Chatbot development covers everything from signing up for an off-the-shelf SaaS product, to assembling a flow in a no-code AI tool, to a full-scratch system build, to a generative AI setup that answers from your own internal documents. Initial cost runs from tens of thousands of yen to well past JPY 11 million. This article is written for IT and DX managers at Japanese manufacturers operating in Thailand and across ASEAN, and it works through two questions using public data and where things stand in 2026 – build in-house or outsource, and whether to go generative AI at all.
What chatbot development actually means – four ways to build
In practice, the phrase “chatbot development” is used for four completely different jobs. If those four stay blurred when the proposal goes up for approval, you end up with a project called “development” that is really a SaaS renewal, or one called “a simple rollout” that turns into a multi-million-yen system build. Start by separating them.
Approach 1 – SaaS (subscribe and configure)
You license a finished product from a vendor and register answer scenarios and expected questions through an admin console. The word “development” gets used, but what you actually write is configuration and content, not code.
The strength is speed. A few weeks from contract to launch is realistic. The weakness is that you cannot step outside the frame the vendor built. Anything specific to your company – pulling stock levels from the ERP, returning actual output figures from the production management system – is capped by whether the standard feature set already supports it.
Approach 2 – No-code and low-code AI (assemble it)
You build the conversation flow in a GUI and connect only the parts that need it to external systems through APIs or light scripting. A growing number of products in this band now let you layer generative AI answer generation onto parts of the flow, which has made it the middle ground between SaaS and full-scratch – and, in practice, the band most companies land in.
Because your own staff can drive the build, it tends to become a hybrid that is neither purely in-house nor purely outsourced. A common split is to have an external partner do the initial build and keep the ongoing improvement cycle inside the company.
Approach 3 – Full-scratch (design it from zero)
Requirements, screens, the conversation engine, admin functions and external integrations are all built to order. You get complete freedom to design around your own business processes, and in return both cost and timeline move up by an order of magnitude.
In manufacturing, this becomes necessary when, for example, your equipment codes or part-number system carry interpretation rules unique to your plant, and no off-the-shelf search logic can reach the right answer. Put the other way around – if you cannot articulate that necessity, there is no reason to choose full-scratch.
Approach 4 – Generative AI and RAG (answer from your own documents)
A large language model generates answers while referring to your manuals, standards, procedures and past inquiry history. This is called RAG, or Retrieval-Augmented Generation. The critical difference is that you do not have to write scenarios in advance – as long as the documents exist, the system can start answering.
That said, “just feed it documents and it works” is only half true. In reality, quality is decided by design calls – which documents are in scope, how finely they are split for retrieval, and what the bot is told to say when it finds no supporting source. Miss that design effort in the estimate and your number lands at roughly half of what the project actually costs.
The four approaches side by side
Lined up by who does the building, the cost band and the workloads each one suits, the picture looks like this.
| Approach | Who mainly builds it | Initial cost band | Best suited to |
|---|---|---|---|
| SaaS | Vendor plus your own admin | Tens of thousands to a few hundred thousand yen | First-line handling of common questions |
| No-code AI | Mainly your own staff | JPY 50,000 to over 800,000 | Automated replies for routine work with light integration |
| Full-scratch | External vendor or in-house dev team | JPY 1 million to over 11 million | Deep integration with core systems and bespoke requirements |
| Generative AI and RAG | External vendor and your team jointly | Varies widely with configuration | Answering from internal documents with traceable sources |
What matters in this table is not the number of zeros but the relationship between the two middle columns – who builds it and what it costs. Decide the building party and the cost band is largely already decided; start from the cost band and you will pick the wrong building party. The feature-level comparison of the approaches themselves is covered in Chatbot comparison – how to choose among four approaches, so this article stays on the organisational decision.
Build in-house or outsource – four tests
Almost every company would prefer to build in-house if it can. The problem is mixing that preference into the assessment of whether it can. Run the assessment mechanically against these four tests.
Test 1 – Does a real owner exist for the AI and the data
The question here is not “do we have someone who knows AI.” It is who collects the internal documents the chatbot will read, who cleans them up, and who keeps updating them – as named people, not roles on a chart.
With a generative AI build you do not have to train a model. What you do have to do is gather manual PDFs, drop the outdated revisions, and repair documents whose tables and layout have broken so a machine can read them. That work cannot be done by an AI engineer. It can only be done by someone inside the company who understands the work. If you cannot place that person internally, outsourcing will not produce results either – unless the arrangement explicitly includes gathering and formatting those documents.
Test 2 – How deep is the differentiating requirement
The answer changes depending on whether the content is “general FAQ” or “information that exists only in your company.”
Opening hours, holidays, where to submit a form – the structure of that information is the same at every company. Standard SaaS features are enough there, and building it out adds no value. Inspection procedures per equipment model, safety rules specific to your Thailand site, delivery conditions per customer – none of that ships inside anyone else’s product. Building out only the differentiating areas is the single split that most affects return on spend.
Test 3 – Security and data residency requirements
Whether internal documents may be sent to an external cloud is the first thing IT has to confirm. At Japanese manufacturers, documents containing drawings, cost data or customer names are in some cases restricted from leaving the country under head-office policy.
If the system runs at a Thailand site, the scope of Thailand’s Personal Data Protection Act (PDPA) also comes into play. Once employee inquiry logs contain names or employee numbers, that data has to be handled as personal data, and where it is stored, how long it is kept and how it is deleted all have to be designed in. The tighter these requirements are, the less an off-the-shelf SaaS product can satisfy them, and the more the answer shifts toward approaches where you control the configuration yourself.
Test 4 – Who keeps improving it after launch
A chatbot is not finished on launch day. Launch day is the starting line. Someone has to review the list of questions it failed to answer every week and decide whether to add documents or change the scope of what it answers.
Sites that launch without assigning that role commonly lose their users within about three months. Two “it did not answer me” experiences in a row and people stop coming back. If you cannot secure an owner for that cycle, an outsourcing arrangement that includes ongoing operation usually works out cheaper in the end.
The 2026 default is hybrid
Run through the four tests and you notice something – for most companies the answer is not a binary choice. In fact, in 2026 enterprise deployments, buying SaaS for routine responses and custom-building only the differentiating work in-house or with a vendor – a hybrid model – accounts for roughly 70% of implementations, according to industry analysis.
This is not a compromise. It is a rational design. Build everything and the cost explodes; buy everything and you differentiate on nothing. Where you draw the line between what you buy and what you build is what chatbot development decision-making has actually become.
What chatbot development costs – the order of magnitude moves with the approach
Now to cost. The ranges differ so much per approach that saying “the going rate is X” without qualification is meaningless.
Cost range for no-code AI builds
For a no-code AI chatbot, initial cost benchmarks look like this.
| Complexity of the build | Initial cost benchmark |
|---|---|
| Minimal | JPY 50,000 to 150,000 |
| Basic | JPY 150,000 to 400,000 |
| Complex | JPY 400,000 to 800,000 |
| Very complex | JPY 800,000 and above |
Build time in this band runs one to two months, and monthly running cost after launch is typically JPY 10,000 to 50,000. If this is your first chatbot and the goal is to cut internal inquiry volume, you will usually land inside this range.
Cost range for full-scratch builds
Full-scratch development, by contrast, sits at a different level entirely.
| Complexity of the build | Initial cost benchmark |
|---|---|
| Minimal | JPY 1 million to 3 million |
| Basic | JPY 3 million to 6 million |
| Complex | JPY 6 million to 11 million |
| Very complex | JPY 11 million and above |
Build time runs two to nine months or more, and monthly running cost is JPY 40,000 to 200,000. Compared with the no-code band, initial cost is roughly 14 to 20 times higher depending on the tier, and running cost is exactly four times higher. Whether you have a requirement that justifies that gap is the only criterion for choosing full-scratch.
Generative AI and RAG – and the payroll cost of building in-house
Looking at English-language benchmarks, enterprise generative AI chatbots are quoted at roughly USD 30,000 to 250,000, and custom RAG builds at roughly USD 30,000 to 150,000. Converted to yen that is a band of several million to several tens of millions, overlapping the upper tiers of full-scratch.
The item most often missed is the payroll cost of building in-house. Estimates put a dedicated in-house team at USD 400,000 to 700,000 per year in salary alone, with 40% to 60% cost reduction available by shifting to an external partner. In-house does not mean the cost disappears – it means the cost moves to a different line in the budget, and that needs to be understood before the proposal goes up for approval.
How long payback takes
Payback benchmarks are also published. A basic deployment typically pays back in six to nine months; an enterprise-scale build in 18 to 24 months.
That gap is not only about scale – it reflects how the benefit arrives. First-line handling of common questions cuts inquiry volume from the day it launches, whereas a build integrated with core systems produces no benefit until the business process itself changes. Set the payback expectation too short and the project gets judged “not delivering” at the six-month mark and is stopped before it has been given time to mature.
For projects inside Japan, note that the IT Introduction Subsidy can in some cases cut effective initial cost to around one third. Investment for a Thailand site is normally out of scope, but if you sequence it as a pilot at the Japanese head office that establishes the pattern and then roll the result out to Thailand, there is room to use the scheme.
How to read the cost breakdown – and why per-response cost is a better lens than monthly fees – is worked through in Chatbot cost – price it per response, not per month.
Decisions to make if you go generative AI (RAG)
Choose the generative AI route and one question always appears at the technology-selection gate – RAG or fine-tuning.
Why RAG became the mainstream choice
As of 2026, an estimated 80% of enterprise LLM deployments use RAG. There are three reasons.
First, you only swap the source data – no model retraining. When a manual is revised, replace the file and the bot answers from the new content the next day. Second, answers can be tied back to the source document. On a factory floor, being able to trace why the system answered the way it did matters as much as the answer being correct. Third, it keeps you free to change models. Generative AI models turn over roughly every six months, and a configuration that does not depend on one specific model is exactly what determines how long the asset lives.
When fine-tuning earns its place
Fine-tuning trains your own data into the model itself, which does produce higher accuracy on domain-specific phrasing and terminology. On the other hand, development cost is put at 40% to 80% higher than RAG, and every data update means retraining.
| Consideration | RAG | Fine-tuning |
|---|---|---|
| Handling data updates | Swap the source document and you are done | Retraining required |
| Development cost | Relatively low | 40% to 80% higher than RAG |
| Showing the basis for an answer | Can cite the source document | Difficult to show |
| Domain accuracy | Depends on document quality | High |
| Switching models | Straightforward | Training investment is locked to one model |
In production, the reported pattern is convergence on a hybrid – RAG as the foundation, with light fine-tuning layered on for narrow needs such as interpreting specialist terminology. Estimate on the assumption of fine-tuning from the start and you get a cost overrun plus an update cycle that stalls.
Four things to settle before you price a RAG build
RAG estimates swing wildly between companies because these four points are still open when the rough number is produced.
- Scope of source documents. Which folders, and up to which revision. Take the whole company’s document set in scope and the confidentiality classification work alone runs into months.
- Level of document pre-processing. If scanned PDFs or image-only manuals are in the mix, text extraction is a separate line of effort. For manufacturing shop-floor documents this is usually the heavy part.
- Behaviour when no source is found. Generate an answer anyway, or hand off to a person. Leave this open and you get plausible-sounding wrong answers.
- Update owner and frequency. Who replaces documents, on what cycle. A RAG build with no operating design is obsolete within six months.
The practical steps and cost logic for building RAG over factory technical documents are covered in RAG implementation – cost and how to run the project.
What is different when you build at a Thailand or ASEAN site
Several issues that domestic Japanese articles never raise apply at a Thailand site.
Local staff AI literacy is changing fast
The Thai government opened pre-registration on 19 August 2026 and starts service on 31 August, offering more than 30 generative AI services including ChatGPT and Gemini free for one year to five million citizens aged 15 and over. The budget is around THB 1.6 billion, roughly JPY 7.7 billion. Pre-registration reportedly passed one million people shortly after opening.
The stated objectives are developing digital talent, raising labour productivity, and lifting the AI adoption rate from the current 10.7% to over 20% during 2027.
The practical implication is clear. Your internal chatbot will now launch into an environment where Thai staff are already comfortable with the act of asking a generative AI a question and getting an answer. The biggest barrier in Japanese-company deployments used to be “nobody uses it,” and the nature of that problem has changed. In its place is a new benchmark – if it is less convenient than the free general-purpose AI they already use, they will not use it. Set your internal chatbot quality bar using instincts from a few years ago and you will misjudge it badly.
How to assess local development resources
Thailand has a reasonable number of providers doing chatbot work. There are foreign-owned data and AI firms such as Adastra, which has generative AI chatbot experience in manufacturing, and Thai-founded startups such as ZWIZ.AI that support both Thai and English. It is not a market without options.
For a Japanese manufacturer, however, technical capability is not the only criterion. Can the vendor hold a conversation with both the head-office IT department in Japan and the Thai subsidiary? Can requirement-definition minutes be kept in Japanese? Can they answer a Japanese security review in a way that passes? Decide before contracting which side carries the language and business-practice bridge, or requirements definition alone will consume twice the effort you planned for. Selection criteria for development partners, and how to read their contracts and quotations, are set out in How to choose an AI development company.
Multilingual support is a terminology problem, not a translation problem
A chatbot at a Thailand site usually has to cover three languages – Japanese, Thai and English. The problem that arises is not translation accuracy. It is that the same equipment or process is called three different things on the floor.
It is entirely normal for one process to be referred to by a Japanese abbreviation by the expatriate staff, by a Thai term by the Thai line leader, and by an alphanumeric code in the system. Because RAG retrieves against the words in the documents, that variation turns directly into retrieval misses. The fix is not a higher-performance model. The fix is to build and register a synonym dictionary. That work cannot be outsourced – it takes someone who knows the floor a few days to produce. If it is not in the estimate, it will turn out to be the cause of most “it cannot answer that” complaints after launch.
Data residency and head-office policy
Which region processes the generative AI workload has to line up with head-office information security policy. Processing in a Japanese data centre, or somewhere inside ASEAN including Singapore, changes both response time and cost. Leave this check until later and the build finishes only to be blocked at head-office review, forcing a redesign. The safe move is to agree the processing region with head-office IT before work starts.
What to prepare before you brief anyone
The accuracy of an estimate depends on how much the requesting side sorted out before the conversation started. The items below should be settled first whether you outsource or build in-house.
Inventory the expected questions from real data
Start by collecting the last six months of inquiry records. Helpdesk tickets, emails to general affairs, even notes a line leader kept of questions they were asked. Sort them by frequency and work out what share of the total the top 30 account for.
In practice, the top 30 questions frequently account for a substantial share of all inquiries. Once you know that ratio, the initial scope defines itself. You do not need a bot that answers everything – a bot that reliably answers the top 30 delivers more real value. The concrete procedure for running that inventory is also covered in Automating internal inquiries.
Decide what it must not answer, first
Chatbot projects rarely go wrong over questions the bot could not answer. They go wrong over questions it should never have answered and did.
Pay, performance reviews, labour disputes, safety-critical work judgements, interpretation of contract terms. None of these can be guaranteed correct, and the damage from a wrong answer is severe. Declare them out of scope up front and route them to a human. Write that boundary into the requirements document and it doubles as an acceptance-test criterion later.
Put acceptance criteria in numbers
“High accuracy” cannot be signed off. In practice you write it like this.
| Type of criterion | How to express it |
|---|---|
| Correct answer rate | Share of a pre-built set of 100 expected questions for which the correct source document was cited |
| Handling of wrong answers | Number of generated answers in the declared out-of-scope areas must be zero |
| Response time | Upper limit on time from question submitted to answer displayed |
| Escalation rate | Share of sessions handed off to a human, with a breakdown |
That 100-question test set is something the requesting side has to build. Let the vendor build it and you get a list of questions the system can already answer.
Fix the operating model and the improvement cycle
Decide who runs post-launch operation and how often. The minimum is one person who reviews the log of unanswered questions once a week and decides whether to add documents or change scope. The effort is one to two hours a week, but whether that time is actually protected makes all the difference to usage rates six months later.
Frequently asked questions
What exactly does chatbot development refer to?
Four different jobs go by that name – configuring a SaaS product, assembling a flow in a no-code tool, building a full-scratch system, and building with generative AI and RAG. Cost spans tens of thousands of yen to over JPY 11 million, so when the topic comes up internally, confirm first which approach everyone is talking about.
How much does chatbot development cost?
For no-code AI, budget JPY 50,000 to over 800,000 initially and JPY 10,000 to 50,000 per month. Full-scratch sits at JPY 1 million to over 11 million initially and JPY 40,000 to 200,000 per month. Generative AI and RAG builds fall between the middle and upper end of that spread, varying heavily with the volume of source documents and how much pre-processing they need.
Should we build in-house or outsource?
Judge it not on whether you have an AI engineer, but on whether you have someone who will collect and clean the internal documents and keep updating them after launch. If you can secure that person, in-house or partial outsourcing works. If you cannot, an outsourcing arrangement that includes operation is the realistic answer. As of 2026, the hybrid pattern – buying the routine part and building only the differentiating part – accounts for roughly 70% of deployments.
With generative AI, can it answer internal questions without any training?
With RAG, yes – it reads your internal documents and answers without model retraining. But it cannot retrieve correctly if the documents are out of date, if scanned images were never converted to text, or if the same equipment goes by several different names on the floor. Answer quality is decided by the state of the documents you point it at, not by the performance of the model.
How long should we allow for development?
One to two months for no-code AI, two to nine months or more for full-scratch. On top of that comes your own preparation – collecting and organising internal documents, inventorying expected questions and building the test set. Whether you can run that preparation in parallel is what actually determines how quickly the system goes live.
Summary
The key points from this article.
- Chatbot development splits into four approaches – SaaS, no-code AI, full-scratch, and generative AI with RAG – and once you decide who builds it, the cost band is largely decided too.
- The build-versus-outsource decision runs on four tests – whether a real owner exists to collect and keep updating internal documents, how deep the differentiating requirement is, security requirements, and who operates it after launch – not on whether you employ an AI engineer.
- In 2026 enterprise deployments, the hybrid model of buying the routine part as SaaS and custom-building only the differentiating part accounts for roughly 70%.
- No-code AI costs JPY 50,000 to over 800,000 initially and JPY 10,000 to 50,000 per month. Full-scratch costs JPY 1 million to over 11 million initially and JPY 40,000 to 200,000 per month.
- A dedicated in-house team is estimated at USD 400,000 to 700,000 per year in payroll, with 40% to 60% reduction available through outsourcing. Building in-house does not remove the cost – it moves it to another budget line.
- Payback benchmarks are six to nine months for a basic deployment and 18 to 24 months for an enterprise-scale build.
- On the generative AI side, RAG is mainstream at roughly 80% of deployments, and fine-tuning costs 40% to 80% more to develop. Production systems commonly converge on a RAG-centred hybrid.
- In Thailand, pre-registration opened on 19 August 2026, and from 31 August a government programme will provide more than 30 generative AI services free for one year to five million citizens aged 15 and over. Local staff AI literacy is rising quickly, and the quality bar for internal chatbots has to rise with it.
- The four things to settle before briefing anyone are the top 30 expected questions, the out-of-scope list, numeric acceptance criteria, and the named post-launch operator.
Most companies that stumble on chatbot development did not pick the wrong technology. They started collecting quotations before deciding who would build it and who would run it. Settle those two and the choice of approach narrows itself down automatically.
It is perfectly reasonable to talk to us while you are still working out which approach applies to you and where the line between buying and building should sit. TOMAS TECH is based in Bangkok and supports Japanese manufacturers on the ground – from requirements definition through build to post-launch operating design – for internal inquiry automation and generative AI and RAG systems. We are happy to help with something as early as an inventory of expected questions or a discussion of how to sequence the project, so if you are at the review stage, please get in touch through our contact page.
References
- AI Chatbot Development Cost Benchmarks – Walker’s Initial cost, build duration and monthly running cost ranges for no-code AI and full-scratch builds
- AI Chatbot Development Cost – Deliverable Cost ranges for enterprise generative AI chatbots and payback period benchmarks
- AI Chatbot Development, Build vs Buy vs Customize – TekRevol Annual payroll estimates for in-house teams, cost reduction through outsourcing, and the share of hybrid deployments
- RAG vs Fine-Tuning 2026 Decision Framework – Winder.AI RAG adoption share, the development cost gap against fine-tuning, and when to use each
- Chatbot Cost Guide 2026 – Digital Reclame How Japan’s IT Introduction Subsidy can compress initial cost
- Thai government to provide generative AI services free to citizens for one year – Nikkei Pre-registration from 19 August 2026 and service start on 31 August, more than 30 services covered, budget of about THB 1.6 billion, and the AI adoption rate target
- Chatbot development companies in Thailand – ensun Directory of providers doing chatbot development work in Thailand
- Top Chatbot Developers in Thailand – Clutch Thailand-based development firms and the languages they work in
