Developing an AI assistant starts with listening to customers

This is how conversations about a house begin. Someone describes their family, their plans for the next few years, the grandma who may move in with them. It is hard to translate that straight into square metres and a number of rooms, and that is exactly how a classic house design catalogue works.

For a long time, the Danwood website worked like a catalogue: you browse houses, download the catalogue, an advisor gets in touch. Yet a house often means a twenty-five-year mortgage. Before talking to a salesperson, people want to understand on their own what is possible, what it costs and what the build involves. These questions come up long before anyone is ready for a sales conversation, and often outside office hours.

Danwood wanted to give these people a knowledgeable guide online: someone who knows the offer, answers their own questions and will eventually prepare the conversation with an advisor.

There were two options: a ready-made SaaS chatbot platform or a custom application on a language model API. We chose a custom application because Danwood needed three things that off-the-shelf tools did not provide to a sufficient degree:

• control over the assistant's behaviour: how it answers, when it asks follow-up questions, what it does not promise,
• freedom to add tools: house search, a knowledge base, new data about the designs,
• analytics developed on our side: insight into what people actually ask about, not just the number of chat openings.

We buy the language model, infrastructure and monitoring as standard services. What is custom is Danwood's data, the recommendation logic, the way the conversation is led, the CMS integrations and the measurement. These are the elements that decide whether the assistant helps sell Danwood houses or just talks about houses in general.

We deliberately started small: house search running on data from Magnolia CMS and simple conversation analytics. Above all, the first version was meant to answer one question: would customers in Germany, who are cautious about personal data, want to talk to AI at all? Or would they immediately ask for a human?

They did. From May to 25 October, the assistant held over 5,600 conversations. In October there were 40 a day on average, almost 50% more than in May.

In the first version, we wrapped the assistant in restrictions: don't do this, answer like this, stick to this path. We wanted to be sure it would never say anything Danwood wouldn't say.

The effect was the opposite of what we intended. The conversation started to resemble old chatbots. It was enough to ask differently than our scenarios assumed, and the conversation stalled. The artificial intelligence turned out to be not very intelligent.

We loosened the restrictions and trusted the model where it does better than rules. The assistant should understand on its own that a family of “two plus two” needs at least three bedrooms. Hard rules stayed where they protect the customer. The assistant does not promise that a house may be built on a given plot, because an advisor checks that. When no house meets all the requirements, it says so directly and asks what the customer would rather give up, instead of quietly offering “similar” designs.

Once the conversation started to flow, it turned out that people were asking about more than the designs. They asked about subsidy programmes, about how the build works, about what is included in the price and what they have to arrange themselves.

So we added the FAQ and articles from Danwood's knowledge base (Wissenszentrum). The editorial team tags an article in Magnolia, and every time it is added or edited, it goes into the assistant's knowledge base. The assistant answers and links to the source, so the customer can read the details on the Danwood website. In October, only 2% of knowledge base searches ended without a match, and two in three answers based on the knowledge base included a link to an article.

For Danwood, this means that content created for the website anyway does double duty: for the reader and for the assistant, without separately “feeding” the AI.

Then came the questions a catalogue can't handle. Customers were no longer asking only about floor area and the number of bedrooms. They wanted to know what everyday life in the house would be like: does the kitchen connect to the pantry, does the bedroom have its own bathroom, can a separate flat for the parents be set aside.

The number of tools grew, and the questions got harder. Every change could improve one conversation and break another. That is why an automated testing app was built in Magnolia, available to the Danwood and SYZYGY teams.

The rules are written by the business, not by a developer. How the assistant should talk is set out in a single document: when to ask follow-up questions, what never to promise, when to suggest contacting an advisor. These rules become criteria in plain language, for example “the assistant does not ask for contact details”. You don't need to know code to read them, challenge them or add new ones.

A test looks like an ordinary conversation. It starts with a real customer question, then AI plays the customer, and a second AI checks whether the assistant followed the rules.

The judge also has to earn trust through numbers. Before AI results start deciding on acceptance, we compare them with human ratings on control conversations. The threshold is at least 80% agreement. We are rolling out the new version of the app in stages: the first stage is already in the code, and human rating and comparison with the judge are under construction.

For Danwood, this means acceptance based on results, not impressions. Every new version of the assistant goes through the same tests, and whatever it can't do yet shows up straight away as a red result. Danwood's knowledge about its offer and about how to talk to customers doesn't stay in people's heads or in emails; it becomes a testable requirement.

An assistant on a website is only as good as the content and data it works with. When conversations show that something is missing or doesn't add up, someone has to find it in the CMS and fix it. On a website with over 250 house designs, a knowledge base, an FAQ and several language versions, going through it page by page is tedious, and it's easy to miss something. A simple keyword search isn't enough either, because the same information can be written in different ways: in other words, with a number written differently, or in another language version.

That is why we built an MCP plugin for Magnolia. MCP (Model Context Protocol) is a standard that lets an AI tool work in another system under clearly defined rules. The plugin is used by the SYZYGY team that develops the Danwood website: AI working alongside editors and developers (for example Claude) can use it to:

• search all the website's content with a single query: pages, house cards, FAQ, product lines, events, all language versions,
• read any page together with its layout,
• ask a precise question about the data, for example “all houses under €300,000 with at least three bedrooms”,
• put together an entire new page or a fix as a draft for an editor to review.

That last capability changes the most. AI builds the whole page at once, with all its sections, texts and photos, from the same ready-made components the Danwood editorial team uses. It follows the website's design rules, for example alternating sections with the photo on the left and on the right, and it looks at every photo in the library before inserting it. So a new page looks like the rest of the website from its first version, and instead of assembling it component by component, the editor gets a ready draft to read and correct. A person always has the final say: AI can't publish anything, and deleting a page requires an editor's approval. You can also see who requested each change, and only selected people can write through the plugin.

What this gives the people who work on the Danwood website

• Editorial team: new pages faster. AI puts together a draft page from existing components, and finds and looks at photos in the library on its own. The editor reads the draft, corrects it and publishes it.
• Offer data: an audit no one would do by hand. Through MCP, AI checked the data of 230 houses and recalculated over 3,000 rows of room areas. The result: 120 issues in 101 houses, each with evidence, its location in the CMS and a distinction between “confirmed / suspected / no data”. Example: a single-storey house with a height of 61.1 m, most likely 6.11 m with a misplaced decimal point. This matters for the assistant too, because it answers based on the same data.
• Content consistency: one fix everywhere. When, for example, the number of houses built changes, fixing it on one page isn't enough. A single search through MCP shows every place where the old value is still on the website, including other language versions.
• Fixing errors without a queue. Errors on the website and in the data that AI finds during any work for Danwood go to Jira every Monday as a single combined ticket. Since MCP went live in production, an editor can immediately prepare a fix with AI as a draft and publish it after review.

The next step is a full loop with the conversations: an AI analyst collects customer questions from the assistant, uses MCP to check whether the website answers them, and points out content gaps. We are building this part right now. A person always decides what goes into the sprint.

A conversation partner available when customers need one. More than six in ten conversations start outside office hours: in the evening, at night, at the weekend or on a public holiday. Most questions come in between 9 and 10 pm, and the busiest day is Sunday.

An assistant that leads to the offer. In October, in more than 7 in 10 conversations it showed cards of specific houses, three to four per conversation on average. In more than half, it gave a link to a filtered catalogue, and in almost 9% it recommended a show house, almost always on its own initiative. In 25 days of October, it recommended 230 different designs, which is most of the offer, not just a few of the most popular houses.

An assistant that doesn't guess. When there is no answer or no matching house, it refers the customer to a Danwood advisor. 0.4% of messages are left unanswered.

Conversations that keep getting deeper. In May, 65% of conversations ended after one question; in October, only 51%. Conversations with at least three questions are almost twice as common as in May: 26% versus 14%.

First-hand knowledge about demand. When a customer names a house type, 43% of the time it's a bungalow, and in October as much as 48%. Three in four floor areas customers search for fall between 100 and 174 m². There are now more than three times as many conversations about the total cost of the build, for example the foundation slab and utility connections, as in May; the same goes for conversations about what exactly the turnkey price includes. These are signals for the offer, content and campaigns that can't be read from page views alone.

Today the assistant is a consultant: it knows the offer and answers questions on its own, without involving the Danwood team. The next step is an advisor. The assistant should ask follow-up questions, understand the customer's situation and judge whether it's the right moment to contact Danwood. And a Danwood advisor will then get more than a phone number: they will know who is going to live in the house, what they are looking for and what they have already asked about.

• the assistant application on a language model API and its ongoing development,
• integration with Magnolia CMS: house search, FAQ, the Wissenszentrum knowledge base,
• an AI tool for analysing floor plans and house data, with human review,
• an automated testing app in Magnolia,
• conversation analytics and regular reviews with an AI analyst,
• an MCP plugin for Magnolia for the team that develops the website.

Danwood contributed knowledge about its offer and customers, and approved the data, criteria and test scenarios.

Before we build anything, we check what your customers ask about, what data you already have and how you will measure whether the assistant helps. The first version can be small. What matters is that it learns from real conversations from day one.