AI Is Spreading in Japanese SMBs. Why Do Chatbots Still Not Stick?

A few weeks after launch, the person who set the chatbot up moves to another project. Nobody else has the admin login. Meanwhile the shop changes its return policy, and the chatbot keeps quoting the old one. A customer screenshots the wrong answer and sends it to the front desk. Someone says "let's just turn it off for now", and that is the end of it.

Nothing in that story is about the AI model being weak. It is a story about a tool that had no owner.

This article is about that gap: why AI use in Japanese companies keeps growing while chatbots so often fail to take root, and what to check before you sign anything. It is written for owners and general managers of small and mid-sized companies, and for the agencies who advise them.

AI use is rising, and it rises with company size

The IPA (Information-technology Promotion Agency, Japan) published its "DX Trends 2026" report on 16 July 2026. It shows AI adoption climbing with company size: nearly 8 in 10 firms with 1,001 or more employees use AI, against 16.6% of firms with 101 or fewer. The same report shows what people mostly use it for: summarizing, translating, and proofreading text came out at 82.5%.

That last figure is worth pausing on. The everyday use of AI is small, personal, and low-risk: one person tidying a document. A customer-facing chatbot is a different animal. It speaks for the company, around the clock, to people who never agreed to be a test audience, and someone has to keep it correct.

Yano Research Institute's "2026 Edition: Actual Use and Outlook of Generative AI and AI Agents" (published 28 November 2025) says over 40% of companies use generative AI, while AI agents sit at about 3% (3.3%). Generative AI is now ordinary; agents that act on their own are still rare. Most companies are working out how to use the plain version well.

Two caveats before we draw conclusions. These surveys measure AI in general, not chatbots specifically, and they use different definitions of "use". Treat the numbers as a direction of travel, not as a chatbot adoption rate.

Being "in use" and being "working" are different things

Adoption figures count companies that have started. They do not count the ones that started, watched usage fade, and quietly stopped.

Small companies tend to hit the same two walls: no clear picture of what to use AI for, and nobody in-house to push it forward. Notice that neither is "the AI is not smart enough". Both are questions about people and purpose.

The chatbot-specific literature says the same. GENIEE's CX Navi article on why chatbots fail lists seven patterns:

• the goal was never made clear
• the FAQ or knowledge behind the bot is thin
• users cannot find the bot
• answers are not accurate enough
• no KPI, so nobody can tell whether it works
• no team to maintain it
• no way to hand over to a human

Read the list again slowly. Only one item, answer accuracy, is about the model. Even that one usually comes back to the knowledge behind it. The other six are decisions a company makes, or fails to make, before and after launch.

Hu-Connect's August 2026 write-up on RAG describes what this looks like in practice: a bot trained on internal FAQs that, some weeks after release, started giving plausible but wrong statements about product specifications. Usage dropped to nothing. The model did not get worse. The source material had aged and nobody was watching.

Where the model does matter: hallucination, briefly

It would be dishonest to say the model never matters. Hallucination, meaning a fluent answer that is simply wrong, is a real risk, and KDDI's business column on avoiding hallucinations treats it as a practical concern for smaller companies too.

Retrieval-augmented generation (RAG) helps. Instead of answering from whatever the model remembers, the bot first looks up your own documents and answers from them. That narrows the room for invention. It does not close it. If the documents are old, contradictory, or missing, RAG will faithfully answer from old, contradictory, or missing material, or say it cannot answer.

So the useful mental model is this: RAG moves the question from "can the AI be trusted" to "can our knowledge be trusted". That is a better question for a company to face, because it is one you can actually work on. It is also why the operations side matters so much. We wrote about that in more detail in why RAG chatbots reduce hallucination and where they still fail.

Three things to settle before you buy

If you take one practical thing from this article, take this. Before comparing vendors, answer three questions internally. If you cannot, no vendor can save the project.

1. Goal

"Introduce AI" is not a goal. "Reduce the number of times staff answer the same opening-hours and delivery questions" is. The narrower it is, the easier it is to build the first version, and the easier it is to tell later whether it worked.

Pick the questions you actually receive. Open your inbox, your LINE chat log, or the phone memo notes, and look at the last two months. You will usually find that a small set of question types accounts for most of the volume. Start there and leave the exotic cases to people.

Decide, too, what success looks like in numbers you can pull without a special project. It might be the count of inquiries staff handle by hand, the number of chats that end without a human, or how often a customer asks "so can I talk to a person". A KPI you cannot measure will be forgotten by the second month, and then the project has no way to defend itself when someone asks whether it is worth the cost.

2. Owner

A chatbot needs someone who spends a small but regular amount of time on it. Not a large amount. A few hours a month is often enough once things are stable. But it has to be a named person, with a backup for holidays, and it has to appear in that person's actual duties, not only in a kickoff slide.

This is the point where agencies can be genuinely useful. Many small companies do not have anyone who can take this on. An agency that agrees to be the operator, with a monthly review, turns "nobody's job" into a service. If you are the agency, say so explicitly in the proposal. If you are the client, ask whether that is included, and what it covers.

The other half of ownership is the human handoff. Decide in advance what the bot does when it cannot answer, who receives the escalation, and how quickly. GENIEE lists "no handoff" as a failure pattern for a reason: a customer who gets stuck with a bot and no exit does not blame the bot, they blame your company.

3. Knowledge upkeep

Your bot is only as current as its documents. Ask yourself where the truth lives today. If prices, opening hours, and return conditions each live in a different place, and each is edited by a different person, the bot will inherit that mess.

A workable approach is dull and effective:

• Keep one source per topic, not five slightly different ones
• Name an editor for each source
• Set a review rhythm, such as the first Monday of the month, plus a rule that any change to a policy triggers an update the same day
• Look at the questions the bot could not answer, and turn the frequent ones into new entries

That last habit is the one that separates bots that improve from bots that decay. Every unanswered question is a free suggestion for what to write next.

For most small companies, the first version does not need to be large. A modest set of accurate, well-organized answers beats a big pile of half-current documents, because the bot can only be as reliable as what you gave it.

What to ask any chatbot vendor

These questions work for any vendor. Ask them of us as well.

• How does the knowledge get in, and how does it get updated? Can a non-engineer change it? What happens to the bot's answers after an edit, and how long does that take?
• What does the bot do when it does not know? Does it guess, refuse, or hand over? Can you control the wording?
• Can staff take over? Where does the escalation go, and does the customer have to repeat everything?
• What can you see afterwards? Which questions were asked, which failed, and can you export it?
• Who does the operations work, and is it included? Vendors often sell setup and go quiet after launch. Ask what the second and third month look like.
• Where is the data stored, and what leaves that place? A precise answer is better than a comforting one. Some processing may involve external AI services, and a vendor who says nothing ever leaves anywhere deserves a follow-up question.
• What can we not do? A vendor who cannot name limits has either not looked or is not telling you.

If you would like a fuller list to walk through with a team, our implementation checklist for Japanese SMBs is a good companion, and five common failure patterns shows what the skipped steps look like afterwards.

What "start small" actually looks like

"Start small" is a convenient phrase, but it decides nothing without a picture. Here is one, as a way of thinking rather than a template.

Limit it to one channel. On LINE, that means the official account's inquiries first, and the website widget later. Limit the topics to a handful you found in real history: opening hours, how to change a booking, how the pricing works, delivery and return conditions. For each, prepare one source document with the correct answer and name its editor.

Then build the exit for when the bot cannot answer. Decide where the handoff goes (email, a phone number, a pointer to live chat) and what the bot says when it gets there. That wording matters more than it seems. "I don't know" and "A staff member will check this, and we will reply by the next business day if you write within opening hours" land very differently with a customer. Only write what your team can actually keep. A promise you cannot keep is worse than none.

After that, have a few colleagues use it. Before customers see it, let staff ask questions in a customer's words, and gaps in the documents show up quickly. Problems found here are much cheaper to fix than ones found after launch.

Once live, you enter the monthly review described above. Widen the scope only after that review has run comfortably two or three times. There is no rush. A bot that tries to take every inquiry from day one usually outgrows what its owner can handle, and slides into one of the failure patterns listed earlier.

Starting small is not the same as being timid. With a goal, an owner, and a way to keep knowledge current, even a narrow bot builds trust inside the company, and widening from trust is quicker, and quieter, than launching wide.

What to look at in the first few months

Launch day is a starting point, and it is where many companies relax and let go. The "no team" and "no KPI" items on the GENIEE list happen right here.

You do not need heavy analysis. Repeat the same short review every month.

First, read the questions that actually arrived. They usually differ from the ones you expected, because customers ask in their own words rather than yours. They write "I want to stop" instead of "cancel", and "how much to get it delivered?" instead of "shipping fee". Those phrasings show you what your documents are missing.

Second, look at the questions the bot could not answer and the ones handed to a person. Take the most frequent, and decide for each: add it to the knowledge, build it into a guided flow, or accept that a human should answer it. The bot does not have to handle everything. Questions that depend on individual circumstances, complaints, and anything contractual are often better left with people, and a bot that declines them gracefully protects trust overall.

Third, go back to the number you picked as your goal. Did the count of manually handled inquiries fall? If not, is the bot unused, or used but not resolving anything? The answer changes your next move. Unused points to discoverability: the LINE menu, where the widget sits on the site, the greeting text. Used but unresolved points to the knowledge.

That is where "users cannot find the bot", from the GENIEE list, comes in. Plenty of bots go unused because the entrance is invisible, not because answers are poor. On LINE, telling people up front what the bot can help with, through the menu or the welcome message, can make a real difference.

You do not need perfection in the first months. Look, fix, look again. Whether you can keep that loop going is what separates the opening scene of this article from a bot that stays.

Where OneBot fits, and where it does not

OneBot is a RAG chatbot platform from VAON Vietnam that connects to LINE Official Accounts and to websites. Here is how it maps onto the three parts above, with the limits included.

Knowledge in. You can register text, upload files (PDF, Word, Excel, PowerPoint; up to 50MB per file), or have it read a website. The admin screen shows whether each item is learned, pending, or failed. If your product or price list lives in Google Sheets, there is a sync option that uses a small Apps Script you paste into the sheet. Be aware of what that means: it is not a one-click connector, it needs a one-time Google authorization step, and it treats each row as a block of text. Google Docs and login-protected pages cannot be read by the website crawler.

Scenarios where the answer should not be free-form. For guided flows, such as "choose a menu item, then answer two questions", there is a visual workflow builder with question, message, lead-capture, and end nodes. In LINE those questions appear as buttons.

Trial. There is a 14-day free trial, so you can put your real documents in and see how it answers before deciding anything.

What OneBot does not do for you. It does not decide your goal or pick your owner. It does not make your source documents correct; if they are wrong, the bot will be wrong in a well-organized way. We do not promise an answer-accuracy figure, because accuracy depends on what you feed it. Some capabilities, such as connecting several AI providers, are still in beta, and we would rather you ask than assume. Data is hosted on servers located in Japan, but generating an answer uses external AI services, so we do not describe it as never leaving Japan.

If you are an agency, the operational part is a natural place to build a monthly service on top of the platform. That is a business decision for you, and the tool does not make it for you.

Before you sign anything

Print the table above and fill it in with the people who will actually run the bot. If you get stuck on "owner" or "knowledge upkeep", that is useful information: it means the project needs a decision, not a product.

If you would rather test a real bot with your own documents than read another article, you can start a 14-day trial. And if you want to talk through the three questions with someone first, get in touch.

FAQ

Is it true that most SMB chatbot projects fail?

We do not have a reliable failure rate for Japanese SMBs, and we would not trust one that claims to. What surveys do show are the recurring causes: unclear goals, thin knowledge, no owner, no KPI, no human handoff. GENIEE's CX Navi lists these, and they are all things a company can fix before launch.

Which matters more, the AI model or the operations?

Both matter, but for most small deployments operations decide the outcome. A stronger model cannot fix an out-of-date price list. Fix the knowledge and the owner first, then compare models.

How much staff time does a chatbot need after launch?

It depends on how often your information changes and how many questions arrive. Plan for a small, regular slot, for example a monthly review of unanswered questions plus same-day updates when a policy changes. We do not have a universal number, and you should be wary of anyone who gives you one.

Does RAG eliminate hallucination?

No. RAG reduces it by making the bot answer from your documents, but if those documents are outdated or contradictory the answers will be too. Good retrieval plus well-kept knowledge plus a handoff path is the realistic combination.

We have no IT person. Can we still run one?

Yes, if the day-to-day work is editing documents rather than writing code. That is the kind of work OneBot's admin screen is built around. The harder question is who owns it, which is a staffing decision, and some companies ask their agency to take it on.

Where is our data stored?

OneBot data is hosted on servers located in Japan. Generating answers uses external AI services, so we do not say data never leaves Japan. If this matters for your legal or compliance situation, ask us for specifics and involve your own advisor.

What should the first goal be?

Choose the repeated questions your staff answer most often, over the last one or two months, and aim to handle those. A narrow first goal is easier to build and easier to measure than a broad one.

How do we try this without a long commitment?

OneBot has a 14-day free trial. Bring the real documents you would use and check how the answers look before deciding.