Nepali customers write the way they speak: English nouns inside Nepali sentences, Nepali in Roman letters, Devanagari when formal, and all three inside a single WhatsApp thread. A chatbot trained on clean English FAQs fails these customers on day one — not because the AI is weak, but because nobody designed for the language reality. This guide covers that design: handling all three scripts, choosing the right architecture, and handing off before the bot costs you a sale. For the channels these bots live in, see WhatsApp automation and Viber; for why Romanized queries matter, the localizing Google Ads language section.

1. The three-script reality (design input, not edge case)

A single customer session can contain:

• English: “What is delivery charge to Pokhara?”
• Romanized Nepali: “pokhara ma delivery charge kati ho?”
• Devanagari: “पोखरामा डेलिभरी शुल्क कति हो?”
• Mixed: “COD available cha? Esewa bata pay garna milcha?”

Design consequences: the bot must treat these as one question with four spellings, not four intents. Collect 50–100 real customer messages from your own inbox before building anything — that corpus, not a textbook, is the specification. Note the spelling variance in Romanized forms (kati/katti, cha/chha, milcha/milxa) and normalize them in a preprocessing step or explicit instruction, because matching fails silently otherwise. Seed the corpus deliberately with high-frequency slang markers — greetings like “hajur” and “namaste”, price asks like “kati ho price” or “discount cha?”, location checks like “delivery huncha?” — since these open most real threads and generic training data underrepresents them.

2. Architecture decision: custom GPT vs RAG vs fine-tune

Custom GPT / no-code assistant (start here): upload your FAQs, price lists, policies and branch info as grounding documents with strict instructions to answer only from them. Cost: hours, not weeks. Updating means editing a document, not retraining. Covers FAQs, order status flows, branch/hours info and policy questions — the bulk of SME volume.

RAG over your knowledge base (graduate to this): when documents grow past what fits in instructions (catalogues, 100+ FAQs, multi-branch details), a retrieval layer fetches the relevant passages per question. More engineering, same principle: the bot answers from your documents, and updates ship by editing documents.

Fine-tuning (rarely justified for SMEs): teaches tone and domain phrasing from thousands of example conversations. It does not reliably inject facts — grounded retrieval still does that job. Consider it only with large logged conversation volumes showing consistent, categorized failures. If someone sells fine-tuning as step one for a 20-query-a-day shop, that is a billing decision, not an engineering one.

Model capabilities move quarterly; the architecture decision above outlasts any specific model. Date-stamp model choices in your documentation and re-evaluate yearly.

2B. Tool options (verified October 2026 — recheck before buying)

Three routes fit different team shapes. Treat names below as a dated snapshot; pricing, limits and Nepali-language behavior change, so trial all shortlisted options on your own corpus before committing:

• Hosted bot builders (e.g. Chatbase, Voiceflow): fastest path — upload documents, configure fallback and handoff, embed the widget or connect WhatsApp. Best when no developers are available and grounding documents are under control. Verify: Romanized-Nepali handling on your test set, WhatsApp channel support quality, per-message costs at your expected volume, and data residency terms.
• Custom GPT-style assistants: zero-code grounding with strict answer-only-from-documents instructions. Best for proving the concept in days. Limits show at scale: version control, analytics and multi-channel deployment stay rudimentary.
• API builds (e.g. OpenAI API + your retrieval): full control over normalization (Romanized variant mapping), grounding, evaluation harness and channel integrations. Needs a developer, but it is the only route where the whole pipeline — corpus, retrieval, prompts, handoff — is versioned and testable. Start here only with the 30-question test set from §4 ready on day one.

Selection rule: pick the least engineering that passes your corpus test at your volume. Upgrade routes when failures cluster in ways configuration cannot fix — not when a vendor demo impresses.

3. Grounding documents that prevent hallucination

The bot is only as truthful as its sources. Minimum grounding set:

• Price lists with effective dates and what is excluded
• Delivery areas, fees and timelines per area
• Return, exchange and refund policy in plain language
• Branch addresses, hours, phone numbers
• Payment methods accepted (COD terms, wallet names, QR locations)

Write each as the bot should say it — short, direct, with the number first. Then add the explicit instruction: if the answer is not in these documents, say so and offer the human handoff. An “I don’t know, let me connect you” preserves more revenue than a confident fabrication about prices or policies.

4. Evaluate with real queries, in all three scripts

Before launch and monthly after:

1. Assemble 30–50 real past customer questions covering all three scripts and the mix.
2. Score answers: correct, partially correct, wrong, refused. Wrong is the only dangerous category — track its rate per release.
3. Add every real failure back into grounding documents or instructions, then re-test. The test set grows; the wrong rate shrinks.
4. Watch live conversations weekly for the first month: new phrasings, new topics, and confidence patterns the test set missed.

5. Human handoff rules that protect sales

State these in the bot’s instructions, not in a staff manual:

• Complaints, refunds, and money disputes → human immediately, with full transcript attached.
• Low-confidence answers → human, never a guess restated politely.
• Same question asked twice → human; repetition signals the answers are missing the point.
• After-hours → collect name, number and question with a promised callback window, then keep the promise.

Measure handoff rate, handoff acceptance (did staff actually take it?), and resolution after handoff. A bot with a 30% handoff rate that resolves everything still outperforms a bot with 5% handoff that fabricates the rest.

What to do this week

1. Export 50 real customer questions from inbox and chat; sort by script and topic.
2. Write or tighten the five grounding documents above — most businesses discover their policies were never written down.
3. Stand up a custom GPT on those documents with the refuse-and-refer instruction, and run the 30-question test before any customer sees it.

Related reading: WhatsApp automation, Viber guide, AI marketing guide, hire a digital marketing expert, and contact for training.