Chatbot development
in Amsterdam

WhatsApp is the channel most people in the Netherlands already use for messaging. That makes it a natural home for a customer service bot alongside a website widget. Building on it, however, means working inside rules that do not apply anywhere else. The relevant one is called the WhatsApp Business Platform. Not the simple app used by very small operations.

The first rule concerns who may speak first. A business cannot simply message a phone number cold. Only once a customer has opted in through an agreed channel, or has messaged the business directly, does the business gain the right to reply. That opt-in is a platform rule. It is enforced by the messaging provider itself, and it governs every automated conversation before a single reply gets sent.

Once a conversation opens, a customer service window starts running. It is a fixed period, counted from the most recent message sent by the customer, during which the business can send free-form replies of any content. Outside that window, free-form text is blocked entirely. No exceptions. It does not matter what the bot might otherwise want to say.

After the window closes, only pre-approved template messages get through. These are message formats submitted for approval in advance, with fixed wording and defined placeholders for details such as an order number or a delivery date. Free-form improvisation is not an option here. A bot designed for this channel needs a library of such templates ready and waiting. They should cover the situations most likely to arise once a window has lapsed: a delayed order, a restock notice, a follow-up on an open ticket that has gone quiet.

Handover to a human agent works differently here than on a website chat. A business phone number acts as a single endpoint. A bot routing a customer to a live agent has to preserve context and conversation history inside that same number, rather than opening a separate channel. Getting this wrong shows up immediately. A customer who has already explained a problem once should never be asked to repeat it after being passed along. That kills trust fast.

The language layer brings its own complications. Dutch builds long compound words rather than short phrases, so a single word can carry what English would split across three or four terms. A customer typing a shipping question, a delivery question or a complaint may reach for one of several long compound forms for the same underlying idea. Simple keyword matching trained on short English terms misses most of them. It just does not see them.

Spelling adds a second layer of noise. Dutch diminutive endings such as -je and -tje change the shape of a word. Everyday spelling also varies across a handful of accepted forms and regional habits. An intent matching setup built for this market needs training examples reflecting that range, with word stems and compound splitting handled directly, rather than a straight import of an English pipeline with Dutch words dropped in.

None of this is exotic engineering. It just needs planning from the first design pass. Skip that planning, and the cost shows up later, usually at the worst possible moment. Retrofitting compound aware matching, a template library and a proper handover flow onto a bot built for a different channel and a different language costs far more than building them in from the outset.

A chat bot lives inside a small floating window. The decisions around that window matter as much as anything the bot says once opened. Placement, timing and default state shape whether a visitor ever starts a conversation at all.

Position is the first choice, and it is more constrained than it looks. The bottom right corner is the near universal default. It rarely collides with primary navigation or the main call to action on a page. Moving it elsewhere without a strong reason usually just confuses returning visitors who expect it in the familiar corner.

The harder decision is whether the widget opens itself. A bot that pops open uninvited, seconds after a page loads, interrupts a visitor who has not yet decided whether they even want help. It reads as pushy on a first visit. Nobody likes that. It also trains regular visitors to close it on reflex before reading a single word.

A proactive opening tied to behavior works better than one tied to a timer. Triggers based on scroll depth, time spent on a pricing page, or a second visit to the same product within a session, single out moments where a visitor plausibly wants help. That beats interrupting everyone equally regardless of intent.

Mobile changes the calculation further. Screen space is scarce. A widget that behaves reasonably on a desktop monitor can cover a meaningful share of a small screen once expanded. Many teams collapse the bot to a small icon on mobile by default. Some delay its appearance until a visitor has scrolled past the first screen, rather than porting desktop behavior unchanged.

The minimized state deserves its own attention. A small unread badge, or a short preview line drawn from the first message, gives a visitor a reason to open the window without committing to a full conversation first. An empty circle icon with no context asks for a click on faith alone. That is a hard sell. Most visitors will not give it one.

None of these choices are permanent once shipped. Placement, trigger conditions and the minimized preview are all worth testing against real visitor behavior, rather than settled once during initial build. A trigger that performs well on a content heavy blog can perform badly on a short checkout flow. The two pages often deserve different settings entirely.