Hebrew Chatbot for Website and WhatsApp: What Works

What is a Hebrew chatbot and how does it work

A Hebrew chatbot is a system that understands questions in Hebrew, searches for the answer in information the business provided, and responds automatically. It can run on a website, in WhatsApp, or both simultaneously, and connect to a CRM to log inquiries or retrieve customer information.

We build these bots around OpenAI or Anthropic models, with an n8n layer managing the flow: receiving the question, searching the knowledge base, constructing the answer, and sending it. The bot does not invent information – it answers only from what we fed it, and if it does not know, it says so explicitly or transfers to a person.

Hebrew presents a real technical challenge: large language models are trained primarily on English, and they tend to make mistakes in conjugations, tenses, and gender distinctions. We solve this in three ways: choosing a model that handles Hebrew better (GPT-4 or Claude Opus), detailed instructions in the prompt about how to phrase answers, and repeated testing of responses before the system goes live.

Where does the bot run – website or WhatsApp?

A website bot runs in a chat window embedded in the page, connecting to our server via webhook. It suits businesses that want to answer frequent questions, direct visitors to the right pages, or capture contact details. The advantage: you control the design and experience. The disadvantage: the visitor must be on the site to use it, and cannot return to the conversation after closing the page.

A WhatsApp bot runs through Meta’s WhatsApp Cloud API, connected to the same answer engine. It suits businesses whose customers already reach out via WhatsApp, or those who want to send proactive updates (order confirmed, appointment tomorrow morning). The advantage: the conversation stays in the customer’s history, and they can return to it whenever they want. The disadvantage: you pay Meta for each conversation, and message structure is more limited than on a website.

We build both versions from the same core: same answer engine, same knowledge base, same CRM connection. What changes is only the interface – how the message comes in and how it goes out.

Where does the bot know what to answer from?

A Hebrew bot knows what to answer only from what we explicitly fed it. We build a knowledge base containing all the business’s answers, policies, prices, and processes. Sources can be: website pages, FAQ documents, price tables, or CRM records.

This information is uploaded to a vector store, which allows the bot to quickly search for the most relevant passage to the question. When a customer asks “how much does it cost?”, the system searches all passages discussing prices, selects the most relevant ones, and passes them to the language model along with the question. The model reads, understands, and constructs an answer in Hebrew.

If the information does not exist in the base, the bot does not invent. We define clear behavior for it: “I don’t know, I’m transferring you to a representative” or “I didn’t find information about that, can I help with something else?”. This is better than a wrong answer that will create a problem later.

How does the bot connect to a CRM?

Connection between the bot and CRM happens via API or webhook, depending on what the CRM supports. When a customer asks a question, the bot can retrieve their details from the CRM (“you have an open order from Tuesday”), and log the conversation as a new activity.

We build this connection in n8n: one node receives the message from the bot, a second node sends a request to the CRM (for example searching for a customer by phone number), a third node passes the information to the language model, and a fourth node sends the answer back to the customer. If the customer requests something requiring human handling, the bot creates a ticket or task in the CRM and transfers the conversation.

This connection works in real time, but we build it with a timeout: if the CRM does not respond within three seconds, the bot answers without the specific information and suggests the customer try again or contact a representative. This is better than a twenty-second delay that causes the customer to abandon the conversation.

How long does it take to set this up?

Setting up a Hebrew chatbot takes between two weeks and a month, depending on the amount of information and complexity of connections. The first stage is information gathering: we go through frequent questions with the business, identify sources (website, documents, tables), and build an organized base. This takes one to two weeks, and is the most critical stage – a bot with partial or outdated information is worse than no bot.

The second stage is building and testing: we set up the flow in n8n, connect the model, upload the information, and test dozens of questions. We fix phrasing errors, improve the prompt, and ensure the bot does not invent answers. This takes a week.

The third stage is controlled launch: the bot goes live, but only for some visitors or only during certain hours. We monitor conversations, see where it struggles, and add information or improve instructions. After two weeks of controlled operation, the bot moves to full activity.

Stage	Duration	What happens
Information gathering	1-2 weeks	Identifying questions, organizing sources, building base
Building and testing	1 week	Setting up flow, connecting model, manual tests
Controlled launch	2 weeks	Partial operation, monitoring, fixes
Full operation	Ongoing	Routine monitoring, information updates, improvements

What happens when the bot does not know how to answer?

When a Hebrew bot does not know how to answer, it must say so explicitly and offer an alternative. We build a fallback path for every bot: if the system does not find a relevant answer in the base, it responds “I didn’t find information about that, I’m transferring you to a representative” or “I’m not sure of the answer, you can leave details and someone will get back to you”.

This path is triggered by a confidence score the model returns. If the score is below a threshold we set (usually 0.7), the bot does not answer at all, but transfers. This is better than a vague answer that will confuse the customer.

Additionally, we build a weekly report of questions the bot could not handle. The business sees these questions, decides whether to add information to the base, and we update. This way the bot improves over time – it learns from its gaps.

For more information on how we build chatbots and automated response systems, you can read in our solutions hub.

Can the bot handle multiple languages simultaneously?

A bot can handle multiple languages, but it requires separate building for each language. OpenAI and Anthropic models understand dozens of languages, but the knowledge base must be translated, and the prompt must be adapted. We build bilingual bots (Hebrew and English) like this: the system identifies the language of the first question, continues in that language, and searches for answers in the matching base.

The challenge is not technical but content: if information exists only in Hebrew, the bot cannot answer accurately in English. It can translate, but the translation may miss nuances or change meaning. Therefore we recommend building a multilingual bot only if there is complete information in every language.

In practice, most businesses we work with choose to focus on Hebrew only, and leave English to human representatives. This is better than a bot that answers in English partially or inaccurately.

How much does it cost to run such a bot?

The cost of running a Hebrew chatbot consists of three components: one-time building cost, monthly infrastructure cost, and variable usage cost. Building cost depends on complexity: a simple bot with a fixed knowledge base costs less than a bot connected to a CRM using dynamic information. We build bots with custom adaptation, so cost varies by need.

Monthly infrastructure cost includes n8n (if the business is not already running it), information storage, and a server running the flow. For a small or medium business this is usually between two hundred and five hundred shekels per month.

Variable usage cost depends on conversation volume and the model we chose. OpenAI charges by token (a word is about one token in Hebrew), and Claude works the same way. A bot handling a hundred conversations per day with an average of ten messages per conversation will cost between one hundred and three hundred shekels per month in model usage. If the bot runs on WhatsApp, you need to add Meta’s conversation costs – each conversation the business initiates costs a few agorot, depending on category.

For a detailed comparison of automation platforms and costs, you can read our guide on n8n versus Make.

What is the difference between a bot and an AI agent?

A bot answers questions according to information we fed it. An AI agent can also perform actions: change a CRM record, send a reminder message, or book a service. The difference is in permissions and complexity.

A bot is built to read information and return an answer. It does not change anything in backend systems. An agent is built to make decisions and act: “The customer requested to postpone a meeting, I check the calendar, find an alternative date, and update both sides”. This requires more careful building, because an agent’s mistake can cause real damage.

We build bots when the goal is to answer and direct, and agents when the goal is to execute. For most businesses, a bot is the right starting point: it is simpler to set up, safer to operate, and easier to maintain. After it runs for six months and we see where it helps, we can add agent capabilities in a controlled manner.

How do you measure whether the bot works?

Measuring success of a Hebrew bot depends on what it is supposed to do. If the goal is to answer frequent questions and reduce load on representatives, we measure: how many conversations the bot closed alone, how many were transferred to a representative, and how much time on average representatives save.

If the goal is to capture leads, we measure: how many people left details through the bot, how many of them became real inquiries, and what is the conversion rate compared to a regular form.

We build a monitoring dashboard showing these metrics in real time. It also includes examples of conversations the bot handled, so the business can see how it behaves in practice. If there is a problem – the bot answers incorrectly, or does not understand a certain type of question – we see it quickly and fix it.

Another metric we track is satisfaction: we ask at the end of each conversation “Did you receive a helpful answer?”, and track percentages. If satisfaction drops, it is a sign that information has become outdated or the bot needs improvement.