AI Chatbot in New Zealand

The only kind worth building

A general-purpose model knows a great deal about the world and nothing at all about your returns policy, your lead times, or which of your products fits which model. Asked anyway, it will produce something plausible — which is worse than useless, because a confident wrong answer about your business is one your customer will act on.

The chatbots that work are grounded: they search your content first and answer only from what they find, with a link to the source. The technique is well established and it is what any competent developer will propose. If someone quotes a chatbot without explaining where its answers come from, that is the whole question left unanswered.

Start with the questions you already get

Export a few hundred recent support emails or chat transcripts and sort them. Most businesses find a startlingly small number of questions make up most of the volume — delivery times, stock, returns, sizing, opening hours, "does this work with that".

That list is your project brief, and it is worth more than any feature discussion. It tells you what content the bot needs, roughly how much of your support load it can absorb, and whether the answer is a chatbot at all or six better-written pages on your website.

Three levels, three prices

Answering from content is the safe starting point. Documentation, policies, product information, guides. It can only tell people things you have already published, so the worst case is that it fails to answer rather than that it invents something.

Answering about a customer — where is my order, what do I owe, when is my service due — is far more useful and needs a genuine login. The interesting engineering is not the AI; it is making certain one customer can never be shown another's information, no matter how the question is phrased.

Taking actions — booking, cancelling, raising a return — is the most valuable and the most careful. Every action needs an explicit confirmation, an audit trail, and a way to reverse it. A bot that can create something a person did not intend is a support problem, not a support solution.

Make it say "I don't know"

This is the single most important thing to test, and the easiest to check before you hire anyone. Ask each developer to demonstrate their bot refusing to answer a question outside its knowledge.

Some will show you exactly that, cheerfully, because they have thought hard about it. Some will show you a bot that answers anyway. That one demonstration tells you more about the quality of the build than an hour of discussion about which model they use.

A good bot, faced with something it cannot support, says it does not know and offers a person. Customers forgive that instantly. They do not forgive being told something untrue in a confident tone.

Costs, honestly

Building one is $15,000 to $35,000 for a content chatbot, more once it authenticates customers or takes actions. Running one is usually a few cents per conversation — often under $100 a month at genuine traffic.

Ask for the cost per conversation rather than a monthly estimate. Monthly estimates assume traffic that has not happened yet; the per-conversation number tells you what success costs, which is the version worth planning for.

The ongoing cost that catches people out is content. A bot answering from documentation you stop updating gets worse every month, quietly, and nobody notices until a customer quotes an obsolete policy back at you.

Handover matters more than intelligence

The measure of a good deployment is not how many questions it answers. It is how gracefully it stops.

Ask how a customer reaches a person, whether that happens automatically after repeated failure, whether the human sees the conversation so far, and what happens outside business hours. A bot that answers 70% of questions well and hands over the rest cleanly beats one that answers 85% and traps people in a loop.

Comparing quotes

• Grounding. Where do answers come from, and are they cited?
• Refusal. Demonstrated, not described.
• Review. How will you see what it has been saying and correct it? There should be a screen.
• Portability. How hard is it to change model provider in a year? The answer should not be "we would rebuild it".
• Cost per conversation, not per month.

Describe the questions your customers actually ask and where the answers live today. Developers who have shipped these will tell you which of the three levels you need — and quite often that the first one is enough.