Almost every dealership website is built for the two weeks someone spends choosing a car, and then ignored for the five years they own it.

Which is strange, because that is where the repeat money is. Servicing, parts, the next set of tyres, the APK, and eventually the trade-in. We build automotive websites and the AI agents behind them, and the most useful work is almost never on the sales pages.

Inventory people can actually search

Start with the basics, because a lot of sites still get them wrong. People do not search the way the stock system is organised. They search by what they can afford per month, whether it fits a pram, whether it will pass the next inspection, and how far it is from them.

A dark car photographed in profile, the kind of listing image a dealership inventory page is built around

Worth having on every listing

  • Monthly cost, not just the sticker price — it is how most people decide
  • Service history in plain language, not a scan of a stamped booklet
  • When the next inspection is due, so nobody gets a surprise
  • A contact option that keeps the car attached to the message
  • Enough photos of the boot and back seats, which is what people actually zoom into
Xaonic campaign graphic: a dealership vehicle search and listing page shown on mobile and desktop
Browse, compare, ask a question — with the vehicle still attached to the conversation.

Most questions are about service, not sales

Look at what people phone up about. A warning light came on. Is this noise normal. Do I need to come in before the holiday. How much is a service on this model. None of that is a sales question, and all of it currently costs a human on the phone fifteen minutes.

Xaonic campaign graphic: a website chat answering a customer question about a dashboard warning light
"What does this light mean?" is the most common question nobody designs for.

Website chat handles a good chunk of it, as long as it is honest about what it does not know. The customer describes what the car is doing, gets a sensible answer about whether it can wait, and moves on. If it is something that needs a real opinion, it goes to a service advisor with the conversation already attached, so the customer does not explain it twice.

Close-up of a car dashboard with illuminated warning indicators

From question to booked appointment

The question and the booking should be one continuous thing. Most sites make them two unrelated features, so the customer gets a helpful answer and then has to go find a form and type everything in again.

  1. They describe the problem

    In their own words, in chat. Not by picking from a dropdown of service codes that mean nothing to them.

  2. They get a straight answer

    What it probably is, whether it can wait, roughly what it costs, and how long the car will be in.

  3. An advisor steps in when it matters

    For anything diagnostic or expensive. The advisor sees the whole thread, so the customer is not starting over.

  4. They pick a time

    Real availability from the workshop diary, with the vehicle and the job already filled in.

Xaonic campaign graphic: booking a service appointment in three steps — pick the service, pick a time, confirm
Pick the service, pick a time, done. Times shown are examples.

If a customer has to explain the noise twice, the website did not help — it just delayed the phone call.

Mechanic working on a car wheel in a service bay

The Netherlands and Dubai

Same brief, different build. The two markets pull on different parts of the system.

Netherlands

  • The APK is a recurring, predictable reason to come back — worth building the whole reminder flow around
  • Occasions move on price and history, so the service record has to be legible
  • People book online and expect it to be self-service, including the rescheduling
  • Dutch and English, and the Dutch needs to read like a person wrote it

Dubai

  • Heat is the service driver — batteries, AC and tyres come up far more often
  • Registration renewal is the recurring hook, the way the APK is in the Netherlands
  • WhatsApp carries most of the conversation, so booking has to work there too
  • Several languages in one inbox, and the advisor handover has to survive the switch

Where we would start

  1. Online service booking with real workshop availability — fastest thing to make useful
  2. Service chat that answers from your own documentation and hands over cleanly
  3. Inspection and registration reminders, because that is repeat revenue you already earned
  4. Inventory search rebuilt around how people actually filter
  5. Then tie it together, so one customer record covers sales and service

We usually suggest the booking flow first. It is the shortest path to something customers notice, and it does not need the rest of the site to change. The chat and the agent handover sit under AI services; the site and the booking itself are custom application development.

Questions we get asked

Can this connect to our existing workshop or DMS system?
That is the normal case. The booking flow is only worth having if it reads real availability, so we build against whatever system holds the diary rather than asking you to switch.
What stops the chat from giving wrong technical advice?
It only answers from your documentation and pricing, and it is built to hand over to a service advisor when the question needs a real opinion. You can read every conversation it had.
We are a service centre, not a dealership. Does this still apply?
Most of it, yes. The inventory part will not matter to you, but the chat, the booking and the reminders are the same build and usually a bigger win.
Do you only work in the Netherlands and Dubai?
No. Those two come up most often in automotive work, so the market notes above are the ones we can speak to properly.