A modern AI assistant does not only answer questions, it acts. It reads the systems your business already uses and, on request, performs real actions in them: it looks into the calendar and suggests free slots, creates a qualified lead in the CRM, checks stock in the inventory system or opens a support ticket. This is made possible by a technique known as function calling, which you can think of as a collection of clearly defined actions the assistant is allowed to trigger. The decisive difference from a rigid menu bot: the assistant understands the request in natural language and picks the right action itself. Just as important is control: reading (Read) is harmless, writing (Write) only happens after a clear approval. This article explains how an assistant reads and controls tools, which systems can be connected, how approvals and security work and which concrete cases this covers. Around 60 percent (McKinsey) of all occupations include activities of which at least a good third can be automated. It is exactly these recurring tasks that a well-connected assistant takes over.
What Function Calling Means
A language model alone can understand and phrase text, but by itself it has no access to your calendar, your customer database or your stock. Function calling closes exactly this gap. You give the assistant a list of functions, each with a clear name, a description and the details it needs. One function might be called read_free_slots and expect a date, another create_lead expecting name, contact and request. When a visitor phrases their concern, the assistant recognizes which function fits, takes the required details from the conversation and triggers it. The result flows back into the reply. This turns a pure conversation into an action, without the visitor having to search for a form or operate a portal.
It is important that the assistant does not invent functions. It can only trigger the actions you have explicitly given it, and only with the details intended for them. That makes the process predictable: every possible action is defined, documented and individually securable beforehand. At XICBOT these functions are tailored individually to your business and your systems, instead of shipping an assistant with generic default actions. Which actions make sense depends on your industry and your tools, and that is exactly the point of tool control and custom functions.
Menu Bot, Builder Kit or Controlled Assistant
To see why function calling makes a difference, it helps to look at the alternatives. A classic menu bot works with fixed click paths: the visitor taps through predefined buttons, and anything the tree does not foresee ends in a dead end. A builder-kit chatbot is quick to set up but answers from generic scripts, does not know your specific business and cannot make anything happen in your systems. A controlled assistant understands free language, is trained on your business, reads your data live and triggers defined actions. The difference is not cosmetic: it decides whether a question becomes a completed task or just another pointer to a contact form.
Menu bot
Fixed decision trees and click paths. Quickly grasped but inflexible: whatever is not foreseen leads nowhere, and complex concerns end at the form.
Builder-kit chatbot
Set up fast, but answers from generic templates. It knows neither your prices nor your stock and cannot perform any action in your systems.
Controlled assistant
Understands natural language, is trained individually, reads your systems live and acts through defined actions with approvals instead of merely pointing.
For the choice, one simple question helps: if all you need is to guide visitors to the right pages, a simple bot may be enough. But as soon as answers must come from your real data and steps such as a booking or a lead handover are meant to actually happen, there is no way around a trained, connected assistant. This is exactly the fit XICBOT provides, not off the shelf, but built for your systems and your workflows.
Briefly explained: Read and Write
What the Assistant Reads (Read)
Before an assistant can act sensibly, it must know the current state. That is why reading is the basis of every control action. A well-connected assistant reads the content of your website and subpages, your shop catalogue with variants, prices and availability, your opening hours and locations, documents and data sheets, the internal knowledge base, the calendar availability as well as the order and delivery status. It therefore does not answer off the cuff but on the basis of your real, up-to-date data. If someone asks whether an item is available in size M, the assistant checks the inventory system and states the actual stock instead of giving a general reply.
Reading has a pleasant side effect: it keeps the assistant up to date without anyone having to maintain texts constantly. If a price changes in the inventory system or a free slot in the calendar, the assistant reflects that automatically because it queries the source live. So that answers stay bound to your own content and the assistant does not guess into the blue, it works against a maintained knowledge base. More than half of website visits today come from mobile devices (Statcounter), where nobody wants to click through subpages to a stock display. A short question in the chat and a precise answer from the system are clearly faster here.
Calendar
Free slots, booked appointments and availabilities, so the assistant makes realistic suggestions instead of naming wishful times.
CRM
Existing contacts, enquiries and notes, to place conversations in context and avoid duplicate records.
Inventory system
Stock, prices, variants and delivery times in real time instead of outdated figures on a subpage.
Ticketing system
Open cases and their status, so the assistant gives information without burdening the support team.
Documents and FAQ
Data sheets, PDFs, price lists and help articles as a source for reliable, traceable answers.
Order and delivery status
Where is my order, when does it arrive: the assistant reads the current status directly from the system.
What the Assistant Controls (Write With Approvals)
Reading alone saves time, but the real gain comes when the assistant acts. On the writing side it puts products in the cart, changes quantities, applies vouchers and promotions, shows shipping costs and leads to checkout. It books and reschedules appointments, requests a callback, prefills contact forms and hands a structured lead to the CRM or an inbox. It creates support tickets, signs up to a newsletter, starts a configurator or a calculation and, on request, provides a quote or a file. Each of these actions is a previously defined function with clear limits, not a free command to a system.
To keep this safe, a simple principle applies to writing actions: show first, then do. The assistant summarizes what it is about to perform and asks for confirmation. Only after the approval is the action actually triggered. This way the visitor sees exactly what happens and stays in control while the actual work is taken off their hands. Which actions may run without a query and which need an explicit approval is up to you. An appointment that is only suggested is uncritical; a purchase or a binding booking should always be confirmed.
The approval principle
The Four Most Important Systems in Detail
In practice it is above all four systems that an assistant reads and controls: calendar, CRM, inventory and ticketing. They cover the most common recurring tasks, from scheduling and lead capture to stock information and support relief. Which connection makes sense in a given case depends on your tools; the connection itself is done cleanly via integration and interfaces.
Calendar
Read: free slots and existing appointments. Write: book, reschedule, cancel, send confirmation and reminder. This relieves the phone and reception, more at the booking assistant.
CRM
Read: existing contacts and enquiries. Write: create a qualified lead, add a note, hand over a prefilled form. A conversation becomes a clean record, see the lead assistant.
Inventory system
Read: stock, prices, variants, delivery time. Write: fill the cart, change quantity, apply a voucher, lead to checkout. The chat becomes a sales channel, see the cart assistant.
Ticketing system
Read: open cases and status. Write: create a ticket, set category and priority, escalate to a human. Fewer routine questions in support, see the support assistant.
In the shop in particular this pays off: around 70 percent (Baymard Institute) of online carts are abandoned. An assistant that answers a question at the right moment, gives the shipping note and fills the cart directly in the chat addresses exactly the doubts that otherwise lead to a bounce. The interplay of reading and controlling turns a question about availability into a completed purchase, without a media break and without the visitor having to leave the chat.
Which Tasks Pay Off First
Not every task is equally worth automating. Two questions help with prioritization: how often does a concern recur, and how well can it be standardized? Frequent, clearly standardizable cases such as appointment requests, stock and delivery enquiries, recurring FAQ or lead capture bring immediate, noticeable relief and are well suited as a starting point. Rare or highly individual concerns, such as a tricky complaint or in-depth expert advice, are better left to a human; here the assistant only prepares and hands over with context. Prioritization often decides success more than the technology does: start in the wrong place and you build a lot while relieving little.
Automate first
High frequency, clearly standardizable: appointment requests, opening hours, stock and delivery status, standard FAQ, lead capture. Greatest relief at the lowest risk.
Add later
Medium frequency or more logic: cart and checkout, vouchers, configurator, rescheduling with reminder. Sensible once the core runs reliably.
Leave to a human
Rare, individual or sensitive: complaints, binding advice, exceptions. The assistant gathers the concern and hands over with full context.
Where to begin is revealed by everyday practice: wherever the same questions come up daily, the lever is greatest. Which topics those are is made visible by conversation analytics, which shows which questions dominate the chat and where knowledge gaps sit. This way the assistant grows along real demand instead of a wish list, and every expansion step pays into measurable relief rather than piling up functions almost no one uses.
Security, Permissions and Data Protection
An assistant that controls systems needs clear boundaries. That is why each connection gets only the permissions it truly needs. An assistant that suggests appointments must be able to read the calendar and create entries, but it needs no access to accounting or personnel data. This principle of least privilege limits the scope of effect from the outset. Writing actions are additionally secured by approvals, and every executed action is logged, so it is always traceable what happened when.
Because personal data may be involved, data protection is part of the picture from the start. XICBOT processes data in Germany and the EU, with a data processing agreement, data sovereignty and a clear deletion concept. On request, European or self-hosted language models are used so that sensitive content does not leave your own environment. More on this under privacy and hosting. An assistant can err, so it does not replace expert advice but leads to a human with full conversation context on sensitive topics.
| Aspect | Reading (Read) | Controlling (Write, with approval) |
|---|---|---|
| Effect | Changes nothing, pure information | Creates or changes, after confirmation |
| Example | Free slots, stock, delivery status | Book appointment, create lead, open ticket |
| Approval | Usually runs in the background | Conscious confirmation before execution |
| Permissions | Only read access needed | Tightly limited write access |
| Log | Optionally recorded | Every action traceably logged |
Concrete Cases From Practice
The interplay of reading and controlling becomes most tangible in concrete workflows. The following cases show how a question in the chat becomes a completed task, without anyone from your team having to step in, as long as no approval for a sensitive step is needed.
- Rescheduling: A customer asks for a later appointment. The assistant reads the calendar, suggests free slots, reschedules after confirmation and sends the new confirmation together with a reminder.
- Lead from the conversation: A prospect describes their project. The assistant asks targeted follow-up questions, prefills the form and, after approval, creates a qualified lead in the CRM instead of an unstructured email.
- Stock information and purchase: Someone asks about an item in a specific variant. The assistant checks the stock in the inventory system, shows a product card, adds the item to the cart after confirmation and leads to checkout.
- Delivery status without waiting: A customer wants to know where their order is. The assistant reads the status from the system and answers in seconds, around the clock.
- Support ticket with context: A request cannot be solved immediately. The assistant creates a ticket with category and priority, attaches the conversation history and escalates to a human when needed.
- Callback and configurator: For an advice-intensive service the assistant captures the callback request, or it starts a calculation and provides the result as a quote.
Where the Limits Are and the Human Takes Over
As much as a connected assistant takes on, its limits matter just as much, and they are set deliberately. It does not replace expert advice: legal, tax, medical or otherwise binding questions belong with qualified people. Here the assistant is a signpost that takes in the concern and hands over with full conversation context, rather than giving information it cannot be responsible for. An AI assistant can err; that is why answers are bound to your own content, writing steps need an approval, and when information is missing the assistant says so openly instead of guessing.
- Binding advice: legal, tax or medical questions go to a human as a signpost, not as the assistant's own answer.
- Complaints and escalation: with frustration or sensitive topics, a direct handover beats a forced automated reply.
- Exceptions without a defined action: whatever no stored function covers is not improvised but passed on.
- Technical gaps: if a system is briefly unavailable, the assistant says so honestly and offers the route back via a human.
Good design means drawing these lines in advance: which topics always lead to a human, which actions always need a confirmation and what happens when a system does not respond. This keeps the assistant a relief and not a risk. It takes the recurring load so your team has time for the cases that demand real judgment, more on this at the support assistant, which solves routine and escalates cleanly.
How a Function Call Works Step by Step
Behind the simple user experience is a clear flow. First the visitor phrases their concern in their own words. The assistant understands the intent and picks the right one from the defined functions, for example read free slots. If details are still missing, it asks briefly, for instance about the preferred day. Then it reads the data from the connected system and suggests concrete options. If the visitor wants to book, the assistant summarizes the writing action and asks for approval. Only then does it trigger the booking, confirm it and log the step. The whole process takes seconds and feels to the visitor like a normal conversation.
Start small, expand cleanly
The economic appeal is obvious: the assistant handles recurring enquiries and tasks around the clock, in seconds and in the visitor's language, while your team focuses on the cases that really need a human. By 2027 chatbots will become the primary customer service channel for around a quarter (Gartner) of organizations, and even today around 81 percent (Harvard Business Review) of customers try to solve their issue themselves before reaching for the phone. An assistant that not only knows your tools but operates them meets exactly this expectation. At XICBOT it is built individually tailored to your business, from tool control through custom functions to clean integration.
- Identify the systems the assistant should read and control: calendar, CRM, inventory, ticketing
- Define a clearly scoped function with a narrow effect for each action
- Separate Read from Write: reading in the background, writing only after approval
- Grant the least possible permissions per connection and log every action
- Consider data protection from the start: hosting in Germany, data processing agreement, deletion concept
- Start with a few actions and expand cleanly step by step