What should an AI website chatbot be allowed to do?
An AI chatbot for a small-business website needs clear limits on what it can answer, prepare and change. Start with approved public information and a reliable route to a person. Give it permission to change bookings or customer records only when those actions have been separately designed and tested.
The important buying question is becoming: what authority are you giving the assistant? A fluent conversation tells you little about whether it should be allowed to make a promise on your behalf.
What has changed in the AI conversation?
On 4 November 2026, OpenAI published a DevRev customer story describing AI systems that combine company information with tools and controls over the actions they can take. The story discusses answering requests, taking approved actions and preparing a person to act.
This is a vendor-published example of enterprise service software, rather than independent proof of results for a UK sole trader. It does not announce a new UK small-business package. Its useful lesson is the distinction between providing an answer and doing something to a business system.
Our recommendation is to make that distinction explicit in your brief. A chatbot that explains your service area and an agent that changes an appointment need different permissions, even if both appear in the same chat window.
Separate answering, preparing and acting
Use three headings when discussing an AI and automation project:
| Permission | What it could mean | Boundary to agree |
|---|---|---|
| Answer | Explain services using approved public information | Say when the answer is unavailable; do not invent terms |
| Prepare | Draft a reply or summarise a request for your team | Keep the result clearly marked as awaiting review |
| Act | Change a booking or write to a customer system | Restrict the action, check authority and record the outcome |
These are planning categories, not a claim that every chatbot product supports them. Ask the supplier to demonstrate the actual controls.
“Prepare a booking request” should leave your diary unchanged. “Book the appointment” changes something a customer may rely on. Your brief should say which outcome is intended and what confirms success.
Write one permission card for each job
Before connecting a tool, fill in this short worksheet for the task you want it to handle:
- Job: What exact request should it help with?
- Information: Which approved pages or records may it read?
- Allowed result: Is it answering, producing a draft or changing something?
- Approval: Who can authorise a change, and what must they see first?
- Exceptions: Which requests must go straight to a person?
- Failure: What should the customer see if a connection fails?
- Owner: Who checks the information and can pause the tool?
For an initial pilot, we would keep the scope small enough that the owner can inspect its work. This follows the direction of the National Cyber Security Centre's guidance on adopting agentic AI: begin with tightly defined tasks, retain oversight and avoid unrestricted access to sensitive information or critical systems. That guidance was published in May 2026; it is supporting advice, not this week's announcement.
A fictional example: arranging a repair visit
Imagine a small appliance-repair business wants help outside office hours. This is a hypothetical example, not a Panda customer result.
Its first permission card might allow the chatbot to explain the published service area and prepare a visit request. It could ask for the appliance type and a short description, then pass the request to the team. It would say that an appointment has not been confirmed.
The assistant would have no authority to diagnose a dangerous fault, agree a final repair price or move somebody else's booking. A request needing judgement would go to the team through an agreed contact route.
If the business later wants confirmed appointments, that becomes a separate piece of work: checking available slots, establishing who may make or change a booking, handling duplicate requests and reporting what actually happened. A message saying “all booked” is insufficient when the diary has not changed.
You can discuss these requirements as part of a bespoke website brief. They should be scoped explicitly, including any integrations and ongoing support.
Test the awkward conversations
A polished demonstration usually follows the expected path. Ask to see these cases as well, using fictional details in a test setup:
- An unsupported promise: Ask for a discount or guaranteed completion date the business has not approved. The assistant should avoid making it up.
- Missing information: Ask a question the source material cannot answer. Check that it admits the gap and offers a useful next step.
- An unapproved action: Ask it to change a booking while it only has permission to prepare requests. The underlying system should remain unchanged.
- A failed connection: Interrupt the test integration. The customer should receive an accurate status, rather than a false success message.
- A repeat request: Submit the same request twice. Check how the workflow avoids an unintended duplicate.
- A person requested: Ask to contact the team. Make sure there is an accessible route, including when nobody is available immediately.
This is a proposed acceptance checklist, not a claim that these tests prove a system safe in every situation. Repeat relevant checks when its sources, permissions or connected tools change.
Keep the website useful without the chatbot
Your service details, contact options and next steps should remain easy to find on the page. Visitors should be able to understand the business without starting a conversation.
If those basics are unclear, help with the existing website may be the useful first step. Keep the chatbot's source information current too: a helpful answer about last month's offer can still mislead today's visitor.
If you are considering an assistant, talk to Panda about one specific task. Bring an ordinary request and an awkward exception. We can discuss the workflow and review points, then scope what would need building, testing and supporting before anything connects to a live system.