AI chatbot development
One question, answered from what you actually published.
Follow a real customer question through the whole system — what it understood, what it was allowed to read, what it answered, and the moment it stops and fetches a person.
- Two questions in one
- Place: Nashik
- Product: bed frame
No punctuation, two questions at once, at 11:40pm. Real questions look like this, and the system has to work on them rather than on a tidy version.
- Delivery → serviceable areas
- Lead time → furniture category
- Customer → not signed in
One question about coverage, one about lead time. They are answered from different places, so each is looked up separately.
- Delivery policy · updated Tue
- Furniture category page
- Internal pricing sheet
- The open internet
It reads an approved set — your published pages, your policies, the content you nominate. Not the open web, and nothing you have not agreed to.
- “Nashik — standard area”
- “Frames are made to order”
- Nothing found on this frame
Two passages answer the question. A third thing was asked that the approved content does not cover, and that gap is carried forward rather than filled in.
- Delivery policy
- Furniture category page
- Nothing invented
The answer is assembled from what it found. Where the content does not say something, the answer does not either.
- Source attached to the answer
- Updated date carried through
Showing the source is what makes an answer checkable. It is also what stops a confident wrong answer travelling further than it should.
- Asks which frame
- Offers to track an order
It asks the one thing it needs instead of guessing, and offers the action a person in this position usually wants next.
- Conversation goes with them
- Topic already identified
- No repeating the question
This is the part most chatbots get wrong. A person is reachable at every step, and everything said so far goes with the customer.
Illustrative interface · sample data
How it answers
It looks things up. It does not make things up.
A custom chatbot answers by finding the relevant passage in content you approved, then writing a reply from it. That single difference is what separates a business chatbot from a clever one.
A custom AI chatbot answers from a set of sources the business has approved — published pages, policies, help articles and nominated documents. When a question is asked, it finds the passages that actually address it and writes the reply from those, so an answer can be traced back to the content it came from.
Taken as typed, including the messy parts — two questions in one line, a place and a product.
It searches only the approved sources for passages that address what was asked. Nothing outside that set is consulted.
Two passages answer it. What is not covered stays uncovered rather than being filled in with something plausible.
The reply is written from those passages, with the source attached so the customer can check it.
Which sources a chatbot may read is a decision you make with us before it is built, and it can be changed afterwards without rebuilding anything.
The source layer
You choose what the chatbot is allowed to read.
A chatbot is only as good as the content behind it, and only as safe as the boundary around that content. Both are decisions you make, not defaults we hand you.
The chatbot reads an approved source layer that you define: published pages and policies, help articles and FAQs, and documents you nominate. Content behind permission is only used where a customer is signed in and entitled to it. Anything not in that set — the open internet, unapproved documents, systems that were never connected — is not read at all.
- Published website pages
- Policies — delivery, returns, warranty
- Help articles and FAQs
- Documents you nominate
- Their own orders and history
- Their account and saved details
- Role-specific content, where scoped
- Records from a connected system
- The open internet
- Documents you have not approved
- Systems that were never connected
- Anything another customer can see
The boundary is set with you before the chatbot is built, and it is a setting rather than a rebuild — sources can be added or removed as your content changes.
Channels
One answer system, wherever they already ask.
People ask where they already are. The same approved sources and the same boundaries sit behind every surface, so an answer does not change depending on where the question was typed.
The same chatbot can be exposed on a website, inside a signed-in customer area, on WhatsApp where the provider setup allows it, and to a support team working alongside it. Each surface is connected where the project and the provider setup allow, and all of them answer from the same approved sources.
The widest surface, and usually the first one built.
Where a customer is known, the answer can include their own orders and account.
Where your provider account and template approvals are in place.
The same answers, drafted for whoever is handling the conversation.
Each channel is connected where the project and the provider setup allow it. WhatsApp in particular needs your own business account and approvals, which we confirm with you before it is scoped in — it is not something that comes switched on.
Where it helps
Good at the repeated questions. Not in charge of the hard ones.
The value is in the volume of ordinary questions that arrive at 11pm. The judgement calls stay with your team, and a chatbot that knows the difference is the one worth building.
A chatbot is well suited to repeated questions with a known answer: policies and process, product and service explanations, order and account lookups where a customer is signed in, collecting the details a request needs, and starting the right next step. Negotiation, complaints, exceptions and decisions that affect money or contracts stay with people.
- The same question, hundreds of timesDelivery areas, timings, warranty, how a process works
- Explaining what you sellProducts, services, what is included and what is not
- Looking something upAn order, a booking or an account, where they are signed in
- Collecting what a request needsThe details a person would otherwise ask for twice
- Starting the right next stepRouting to the correct form, page or team
- Anything being negotiatedPrice, terms, or a deal that is still moving
- A complaint that mattersWhere the tone of the reply is most of the answer
- Exceptions to your own rulesSomeone has to decide, and it should be a person
- Decisions with money attachedRefunds, credits, contracts, anything hard to reverse
- Anything sensitiveHealth, legal, employment, safeguarding
We scope the first version around the questions you already receive most, which we usually find in your existing inbox and chat history rather than guessing at them.
The edge
The most important thing it says is “I don’t know”.
Every chatbot meets a question its sources do not answer. What it does in that second is the difference between a useful tool and a liability.
When a question falls outside the approved sources, the chatbot says so rather than guessing. Depending on what is missing it will ask one clarifying question, point to the person or page that can help, or open a handover with everything said so far attached. The unanswered question is also recorded, so the gap can be closed.
A customer now believes something you never said, and your team finds out when they try to hold you to it.
One question back is faster than a wrong answer, and it is what a person would do.
Sending someone to the right place beats paraphrasing something safety-related.
Saying so plainly costs nothing. Inventing an answer costs a customer.
Every question it could not answer is logged as a gap. That list is one of the more useful things a chatbot produces, and it is what the next content update is built from.
Handover
When a person takes over, they already know everything.
The worst moment in customer support is being asked to explain it all again. A handover that carries context is the whole reason a chatbot is worth having in front of a team.
A customer can reach a person at any point in the conversation. When that happens the chatbot passes the whole exchange across — the original question, everything said since, the topic it identified and what it was about to suggest — so nobody is asked to start again. Where a CRM or helpdesk is connected, that context can be written into the record too.
- Somebody from the team is joining.
- They are not asked to repeat anything.
- The conversation carries on in the same window.
- The original questionWord for word, as it was typed
- Everything said sinceThe full exchange, in order
- The topic it identifiedDelivery · furniture lead time
- What it was about to suggestSo the person can agree or correct it
- Their account, where signed inOrders and history they are entitled to see
- The record in your own systemWhere a CRM or helpdesk is connected
- The full conversation, already read.
- The topic, and what the bot was going to say.
- Whatever the connected system knows about them.
Where the relevant system is connected, the handover can include context from the conversation. Which systems those are, and what they can accept, is confirmed with you during scoping rather than assumed.
What it learns
The chatbot is also the best listening device you own.
Every question it could not answer is a gap in your content that customers were already hitting — you just never saw them. Closing those gaps is what makes the next month’s answers better.
A chatbot is kept current by updating the content behind it, not by retraining anything. When an approved page or policy changes, later answers use the new version. Questions it could not answer are recorded as gaps, so the content that is missing is known rather than guessed at.
- 01It records what it could not answerNot a score — a list. The questions that arrived, and which ones had no approved source behind them.
- 02The gaps become obviousA question asked once is noise. The same question asked all month is a page you have not written.
- 03You update the sourceSomeone edits the policy, the FAQ or the product page — in your own words, in your own system.
- 04The answers changeThe chatbot reads the approved version. Nothing is retrained, and nothing has to be rebuilt.
- Installation on large framesasked 31 times
- Delivery to Nashikasked 24 times
- Mattress sizing guideasked 12 times
- Trade account pricingasked 9 times
Counts here are sample data. On a live chatbot these are simply how many times a question arrived — a count of conversations, not a performance claim.
Relevant capability work
Where we have built answering surfaces.
No chatbot product case is published yet. These are delivered projects carrying an AI advisor and a bounded answering surface — the capability this page describes, built elsewhere.
Questions
Asked before commissioning one.
- What is a custom AI chatbot?
- A chatbot built around your business rather than configured from a template. It answers from content you have approved, follows the boundaries you set about what it may read, connects to the systems you already run where that is useful, and hands over to your team at the points you decide. The wording, the scope and the escalation rules are yours.
- How is it different from an off-the-shelf chatbot?
- An off-the-shelf tool gives you a widget and asks you to fit your business into it — a fixed set of integrations, someone else’s answer style, and a monthly seat price. A custom build starts from how you actually answer customers today, reads the sources you nominate, and lives in your own stack. For a business with standard questions and no unusual systems, an off-the-shelf tool is often the right answer, and we will say so.
- Where does the chatbot get its answers from?
- From an approved source layer you define with us: published pages and policies, help articles and FAQs, and documents you nominate. When a question arrives it finds the passages in those sources that address it and writes the reply from them, with the source attached. It does not answer from general knowledge about your industry.
- Can it use our website as a source?
- Yes, and that is usually where the first version starts, because your published pages are already written, already approved and already the version you stand behind. Pages are read as sources rather than copied, so when a page changes the chatbot uses the new version.
- Can it use our documents and knowledge base?
- Yes, where you nominate them. Policy documents, help centre articles, internal process notes and product sheets can all sit in the approved layer. What matters is that somebody decides which documents belong there — an unreviewed folder is how a chatbot ends up quoting a draft.
- Can we control what it is allowed to read?
- That control is the point. You define three things: what it may always read, what it may read only when a customer is signed in and entitled to it, and what it must not read at all. Anything outside that boundary is not consulted. The boundary is a setting rather than a rebuild, so it can change as your content does.
- What happens if it does not know the answer?
- It says so. Depending on what is missing it asks one clarifying question, points to the page or person that can help, or opens a handover with the conversation attached. It does not guess. Every unanswered question is also recorded as a gap, which is how the missing content gets identified.
- Can it hand over to a real person?
- Yes, at any point, and a person is reachable at every step rather than only after the chatbot has failed. The whole exchange goes across — the original question, everything since, the topic identified and what it was about to suggest — so the customer is never asked to explain it again.
- Can it work on WhatsApp?
- Where your provider setup allows it. WhatsApp needs your own business account and message template approvals, which we confirm with you before scoping it in. It is not something that arrives switched on, and the same approved sources sit behind it as behind the website.
- Can it work inside a customer portal or signed-in area?
- Yes, and that is where it becomes most useful, because a known customer can be answered about their own orders, bookings and account rather than only about general policy. What a signed-in person may see is governed by the same permissions as the rest of the portal.
- Can it connect to our CRM or support system?
- Where the system allows it. We confirm what each tool can genuinely expose — an API, a documented integration, an export — before designing anything around it. Connected properly, a handover can create or update a record so the conversation is not stranded in a chat window.
- Can the chatbot take actions, not just answer?
- Yes, within limits you set. Looking something up, starting a request, booking a slot or routing to the right team are all reasonable. Anything that moves money, changes a contract or is hard to reverse should sit behind a person, and we design that boundary with you rather than assuming it.
- Can different users see different information?
- Yes. An anonymous visitor gets published content. A signed-in customer can additionally be answered about their own records. A member of your team can be given internal material where that is scoped. The chatbot inherits whatever permission model the surrounding system already has.
- How are knowledge updates handled?
- By updating the content, not by retraining. When an approved page, policy or article changes, later answers use the new version. Nobody has to teach the chatbot separately, which matters because a second copy of your policies is a second thing to keep correct.
- Does Branditify need access to our systems?
- Only to what is genuinely needed, and agreed in writing before anything starts. Often that is read access to content and a test environment rather than production. Where a connection to a live system is required we scope the narrowest access that does the job.
- Who owns the chatbot, the content and the conversations?
- You do. The configuration, the approved source layer, the conversation history and any code written for you are yours, handed over as agreed in scope. There is no Branditify chatbot product, no seat price and no version to license.
- What determines the scope of a chatbot project?
- Mainly four things: how much approved content exists and what state it is in; how many channels it has to appear on; how many systems it has to read from or write to; and how much it is allowed to do rather than only answer. A website chatbot reading published pages is a different job from one answering signed-in customers about live orders.
- What makes a chatbot project complicated?
- Usually the content, not the AI. Policies that contradict each other, answers that live only in somebody’s head, and questions whose real answer is “it depends” are what take the time. The second thing is permissions — deciding who may be told what, which is a business decision rather than a technical one.
- How does a project start?
- With your existing questions. We look at the inbox, chat log or call notes you already have, find what is actually asked most, and check whether your published content answers it. That produces a scoped first version aimed at real volume rather than a demo built around questions nobody asks.
Start here
Bring us the questions you already get.
The inbox, the chat log, the same five things people ask every week. That is the material a useful chatbot is built from, and it is the fastest way to see whether one is worth building at all.