Answering and acting are different products
Most AI chat conversations are about facts the company already published: opening hours, the returns window, whether a plan includes a feature. A model with access to your help content handles those, and that is the job people usually mean when they say AI chat.
The questions that actually consume your team are different. Where is my order? Has my payment gone through? Can you cancel the one I placed by mistake? None of those can be answered from published content, because the answer is specific to one person and lives in a system somewhere.
An AI that can call out to that system — look up the order, read the ticket, post to your backend — is doing something categorically different from retrieving a paragraph. It is worth being clear about the difference, because the risks are different too. A wrong answer is embarrassing; a wrong action changes data.
The four kinds of action, and why the split matters
In MyLiveChat these are configured as tools the model may call, under Tools (Smart Actions) in the dashboard, and they come in four kinds. The important thing is not the list but the line running through it.
- Knowledge search — searches your own training content for material matching the visitor's question. Reads only.
- Ticket lookup — fetches a summary of a ticket by its number, scoped to your account. Reads only.
- URL fetch — retrieves an allowlisted page and returns its text, which is how you expose something that lives on a status page or a published feed. Reads only, and only from addresses you have allowed.
- Webhook — posts the arguments to a URL you configure, signed so your endpoint can verify the request really came from us, and returns whatever your endpoint replies. This is the one that can change something.
Three of the four can only read. Exactly one can write. Every decision about risk in this area follows from that split, so it is worth internalising before you configure anything: an order is only ever created, a refund only ever issued, a record only ever written by the fourth kind.
Start with reads, and earn the writes
The temptation with a new capability is to reach for the impressive demo — the bot that issues the refund. Resist it for a release or two. The read-only actions carry most of the value and almost none of the danger, and they teach you things you need before you let anything write.
An order-status lookup removes a large, boring, repetitive category of contact. It runs hundreds of times before you have to trust it with anything, and every one of those runs tells you whether the model calls the tool at the right moment, whether it passes sensible arguments, and whether it handles a miss gracefully.
Only when you can answer those from your own logs does a writing action make sense. And when you build one, scope it narrowly. A tool called cancel_order that takes one order number and refuses anything already shipped is a tool you can reason about. A general-purpose update_account that takes a field name and a value is one nobody can.
If your first instinct is that the AI should not be answering this category at all, that is a legitimate answer too — our guide on deciding when your AI chat should answer works through where to draw that line.
The approval gate, and why it refuses the way it does
There is a setting that requires a human to approve actions that change data. When it is on, the writing kind of tool is refused before it runs, and the refusal is deliberately shaped: the model is told not to claim the action was completed, and to offer to connect the visitor to a person instead.
That last detail is the one worth copying into your own thinking. The dangerous failure is not a blocked action — it is a blocked action the visitor believes succeeded. A customer who leaves the chat convinced their subscription was cancelled, when nothing happened, will find out at the next invoice, and that conversation is far more expensive than the one you avoided.
The refusal also happens at the point of execution rather than in the prompt, which matters because prompts can be talked around and an execution boundary cannot. If you take one design idea from this page, take that one: enforce the limit where the work happens, not where the instructions are written. Visitors do try to talk their way past instructions, which our guide on manipulation attempts covers in more detail.
Every call is logged, and that is the feature
Every action invocation is recorded — the ones that worked, the ones that errored, the ones that timed out, the ones that were refused. It is easy to read that as an audit checkbox. It is better read as your only real instrument.
Nothing else tells you whether the capability is working. Conversation volume does not, because a bot that never calls a tool looks the same from the outside as one that calls it perfectly. Satisfaction scores do not, because they lag and they are noisy. The invocation log tells you directly: how often the model reaches for each tool, how often that ends in an error, and which tool is quietly failing every third call because an endpoint got slow.
Review it deliberately in the first weeks, the same way you would review AI answers. A tool that errors ten per cent of the time is worse than no tool, because the bot has learned to promise something it cannot deliver.
Design the action, not just the prompt
Most of the quality in this area comes from the shape of the tool rather than the wording around it.
- Take the narrowest input that works. An order number is a good argument. A free-text description of what the customer wants is not.
- Return a small, plain answer. The model has to turn the response into a sentence; a compact status and date does that well, a large blob invites invention.
- Set a timeout you can live with, and remember the visitor is watching a pause. A slow action is a bad action even when it eventually succeeds.
- Fail soft, and say so. When a call fails the bot should say it could not check right now and offer a person — never guess the answer it was about to look up.
- Verify the signature on your endpoint. The request is signed for you; an endpoint that ignores the signature is an open door with a lock hanging off it.
- Log on your side too, with the same identifiers, so a disputed action can be traced from both ends.
What to tell the visitor
Say plainly when the assistant is doing something on the visitor's behalf. Let me check that order for you before a lookup, and a clear statement of the outcome after it, is the whole requirement — and it doubles as an expectation-setter for the pause while the call runs.
Be equally plain about the boundary. If the assistant can check an order but cannot cancel it, the honest sentence is that it can look it up and that a person handles cancellations. Visitors accept a stated limit easily. What they do not forgive is discovering the limit after they thought the thing was done.
And keep the handoff close. Any action that is refused, fails, or falls outside scope should end in a route to a human rather than an apology loop — the pattern our AI chatbot is designed around, and the one that keeps an automated conversation from becoming a trap.
What to measure
- Invocations per tool, and the trend. A tool nobody calls is either badly described or solving a problem you do not have.
- Error and timeout rate per tool. This is the number that decides whether a capability is helping; watch it per tool, because one bad endpoint is invisible in an average.
- Refusals, if you run the approval gate. A rising count is a signal about what customers keep asking the bot to do, which is useful product information.
- Conversations resolved without a person in the categories the actions cover, compared against the same categories before you enabled them.
- Contacts that follow an action, within a day. An action that works but generates a follow-up question has not saved the contact, only moved it.
Naming matters beyond readability. Readiness screens find your actions by searching their names and descriptions for keywords, so why your AI tool name decides what the dashboard counts is worth reading before you settle on a convention.