← All posts

Customer support in Norwegian: Bokmål, Nynorsk and the rules that apply

What a Norwegian-speaking support queue actually requires: two written standards, an AI agent that does not mix them, and GDPR obligations enforced by Datatilsynet.

Serving Norwegian customers is not the same as adding one more language to a dropdown. Norway has two official written standards — Bokmål and Nynorsk — and a customer who writes in one and receives an answer in the other notices immediately. Add the Norwegian implementation of the GDPR, supervised by Datatilsynet, and the practical requirements for a Norwegian support queue become quite specific.

Two written standards, one customer base

Start with the split. Bokmål is the written standard for roughly 85% of Norwegians and the default in most commercial contexts; Nynorsk is the standard for the rest, dominant in parts of Western Norway, and required in a defined share of communication from public bodies. They are not dialects of one another — the pronouns, the negation and much of the everyday vocabulary differ — so a reply that mixes forms reads as careless rather than as regional colour.

For a private company, no law requires you to answer in Nynorsk. The reason to do it anyway is that a Nynorsk-writing customer who receives Bokmål has been quietly told which kind of customer you were built for. Matching the standard the customer chose costs one setting and one knowledge base; failing to match it is the kind of small friction that shows up in churn long before anyone files a complaint.

Detect and mirror instead of standardising

The practical rule for a support team is to detect and mirror, not to standardise. When a customer writes «Kvar er bestillinga mi?», the answer belongs in Nynorsk; when they write «Hvor er bestillingen min?», it belongs in Bokmål. Lavenity treats the two as separate languages throughout — the widget, the operator console and the AI agent each carry both — precisely so that mirroring is the default rather than a manual correction.

Automated answers are where this usually breaks. A model told simply to "answer in Norwegian" will drift between the two standards inside a single reply, mixing «ikke» and «ikkje» in consecutive sentences. Ven AI Agent is given the written standard explicitly and instructed not to swap, and the language it used is reported back with every answer, so a drift is visible in reporting rather than only in a customer complaint.

Keep the AI agent from mixing the standards

Knowledge coverage is the other half. An AI agent grounded in a knowledge base that only exists in Bokmål can answer a Nynorsk question, but it will paraphrase from the wrong standard and lose precision on exactly the terms that matter — delivery, refund, cancellation. Tag each document with its language, keep the Bokmål set complete, and add Nynorsk versions of the twenty articles that actually generate conversations rather than translating the whole library at once.

On the data side, the obligations are the ordinary GDPR ones as applied in Norway: a lawful basis for processing support conversations, a data processing agreement with the provider, clear information to the customer, and a retention period you can defend. Datatilsynet is the supervisory authority a Norwegian customer would complain to, and it publishes guidance in Norwegian that is worth reading in the original rather than through a summary.

GDPR, Datatilsynet and support conversations

None of this requires a Norwegian office. It requires two written standards treated as two languages, an AI agent that keeps them apart, knowledge content tagged by language, and a retention and processing setup you could explain to a regulator. Get those four right and a Norwegian customer gets the same quality of answer as an English-speaking one — in the standard they actually write.

A Norwegian launch checklist for a support team

Set the widget language per site rather than per workspace, so a Norwegian domain opens in Norwegian instead of English with a language switcher. Enable both no and nn for the AI agent, then run ten test conversations — five in each standard — and read the replies for mixed forms rather than only for correctness. «Ikke» inside an otherwise Nynorsk answer is the single most common failure, and it is easy to catch before customers do.

Then decide what your knowledge base owes each standard. Complete Bokmål coverage is the baseline; for Nynorsk, start with the articles behind your twenty most frequent conversations — delivery, returns, payment, account access — and tag each document with its language so retrieval prefers the right one. Review the AI reporting monthly for handoffs that happened because no source existed in the customer's standard, and translate those articles next.

Finish with the paperwork before the launch rather than after it. Confirm the lawful basis for processing support conversations, sign the data processing agreement, set a retention period you can justify, and make sure your Norwegian-language privacy information says what actually happens to a chat transcript. If a customer or Datatilsynet asks, the answer should already be written down.

Frequently asked question

Do we have to answer Norwegian customers in Nynorsk?

A private company is not required to. The obligation to use both written standards in a fixed proportion applies to public bodies, not to commercial support. The argument for doing it anyway is commercial rather than legal: a customer who writes Nynorsk and consistently receives Bokmål learns that your product was built with someone else in mind, and matching the standard they chose costs one language setting plus a short set of translated knowledge articles.

Sources