Skip to content
XICBOT

Settings

Deutsch
Read + Write with permissions

Individual Functions for Your Own Processes

At XICBOT an individual function is not a special build bolted onto the assistant but a tool of its own, with a key, a schema, a target address, a minimum role and an approval path.

In plain language

We also build custom functions for your process. Each function is a tool of its own with fixed rules. The assistant proposes to use the tool. Then your system answers. Only what your system returned goes into the chat. It is set beforehand what may run on its own. Everything else only happens after a click.

Request an individual function View tool control

  • Answers with a source reference
  • Loads only after your consent
  • No minimum term, cancellable monthly

The assistant proposes the call, your system answers, and only what your endpoint returned goes back into the conversation. What may run automatically and what happens only after a click is settled beforehand in the tool's record — not left to the model's judgement.

42 of 48
answers carrying a source reference
XICBOT, own measurement series of 11 September 2026
8 of 8
questions without a basis declined instead of guessed
XICBOT, own measurement series of 11 September 2026
2,670
sections from 70 documents in our own knowledge base
XICBOT, count in our own database
24.1 KB
loader on your page, compressed
XICBOT, own measurement of the delivered files
The assistant does not calculate, it asks, Example conversation, reconstructed
  1. Visitor:What does a canopy of 6 by 3.5 metres with one side wall cost?

  2. Assistant:I pass the dimensions to the company's own price calculation and tell you what comes back from there. Otherwise I would be estimating.

    • preis_kalkulation · input: width 6, depth 3.5, side wall 1 · answer: 4 items, 2,184 € net
    • System rule: never state a result that did not come back
  3. Visitor:As a quote, please.

  4. Assistant:For that I create a record in the quoting system. I do not run that on my own: you read beforehand what will be handed over and confirm it with a click.

    • angebot_anlegen · writing · state: proposal · confirm or decline
  5. Visitor:Confirmed.

  6. Assistant:The record is in place. A second click on the same confirmation does not create a second one — a lock in the database prevents that, not a check in the interface.

    • State: executed · approval path: visitor confirmed · input, result and duration in the log

Ask it yourself, Assistant of this website

Automated assistant

Enter sends, Shift and Enter starts a new line.

The assistant only loads after your consent. Privacy

Building Blocks of Individual Functions

Two statements are readily conflated; here they stand apart. Included in what is delivered are seventeen build forms: seven at the core — capture an enquiry, take an appointment request, hand over to a human, search the catalogue, put together a basket in the chat and lead on into the shop, call a stored address, pre-fill a form on your site once the visitor confirms — plus ten adapters for inventory, calendar, catalogue, customer management and ticketing. Definable as your own action is whatever your system offers through an endpoint: you enter key, schema, address and minimum role, and XICBOT makes the call. The calculating happens in your system, not in the assistant. How a single call proceeds is set out under tool control; how the finished assistant reaches your website under integration and embedding.

Outwards the contract is narrow and identical for every build form: XICBOT sends a POST carrying build form, operation, tool key, conversation id and input, and expects an answer with an ok field and the data. A connected system therefore needs no knowledge of XICBOT, only an endpoint that understands this one envelope. If the ok field is missing, the answer counts as a breach of contract, not as a result.

  • Your Rules Stay Where They Are Maintained

    Tiers, customer groups and case distinctions stay in the system that already maintains them. The assistant passes the input across and takes from the answer exactly the fields the tool declared. A field your system sends on top of that never reaches the model.

    • Before execution the input is trimmed to the fields of the schema
    • Adopted text values hold 600 characters, lists 20 entries
    • Tenant and account identifiers are blocked as field names
    • The administration endpoint executes nothing itself
  • One Way Out, Four Hard Limits

    Every tool that talks to a foreign system goes through the same connector. If each build form built its own call, the question would not be whether a limit is missing, but in which one.

    • The target address is checked when it is entered and again immediately before the call
    • The resolved addresses are checked, not merely the name
    • Redirects are not followed: a redirection counts as an error
    • An answer above 64 KiB is discarded, not used in truncated form
    • The deadline sits at eight seconds and can be set per tool between one and twenty
  • Calculators and Configurators

    A calculator in the conversation is a tool with a schema for the inputs and an endpoint that knows the price. XICBOT brings no price or stock truth of its own; what appears in the conversation comes from your answer. If your endpoint fails, the assistant names the failure rather than a figure.

    • The schema for the inputs holds at most twenty fields
    • The call has an eight-second deadline, settable per tool between one and twenty
    • A response above 64 KiB is discarded rather than used in truncated form
    • If your endpoint stays silent the call ends as timeout; any other error ends as failed
  • Schema and Required Fields

    A schema of your own holds at most twenty fields. Required fields are the union of what the build form demands and your own list — but only what also appears in the schema. If a required field is missing, the call is not executed at all. Null, empty text and an empty list count as missing; a 0 is a value.

    • Field names follow a fixed pattern; anything that does not match is filtered out
    • tenant_id, mandant, mandant_id and konto_id are blocked as field names
    • For a known build form the kind and schema come from the registry, not from the request
    • A schema without fields goes out as an empty object — otherwise the model rejects the call
  • Several Steps, but Capped

    Several calls within one answer are provided for, but limited: an answer does not execute more than five, and the sixth is logged as a capped call. Once the month's allowance is largely used up, the cap drops to one call per answer. A step that fails is not repeated — there is no second attempt and no background run.

    • Counting happens in the database from the start of the running answer, not in memory
    • The capped call sits in the log and carries the field chain_capped in the tool row
    • The visitor reads a sentence of its own for this, not the internal counter marker
    • A failure ends as failed, an exceeded deadline as timeout — neither is made up later
  • Approval and Log

    On creation and change every non-reading kind is forced to confirmation, whatever the request says. Without confirmation only what reads and is explicitly set to automatic will run. Every call leaves a row that is written before execution and updated afterwards.

    • Seven states: proposed, confirmed, executed, rejected, expired, failed, deadline exceeded
    • The approval path sits beside it: automatic or visitor confirmed
    • Input, result, duration and error text sit in the same row
    • In the widget duration and approval path are absent and the error text is replaced by a generic sentence

What these building blocks share is the point at which they stop: every outbound call runs through the same connector with target check, time limit and size cap. An individual function therefore brings no route of its own onto the network, only a schema of its own.

Which building blocks your case needs is settled by the end of the initial conversation — together with the question of which details your system has to see for it and which it never gets to see.

12 requests per minute

cap per visitor on the public widget interface

applies per visitor and assistant; that allows one question every 5 seconds, and the series waits 5.5 seconds to keep clear of our own brake

What Comes With It and What You Define Yourself

The list below names, for each build form, the key under which it sits in an assistant's tool set and the approval it carries. Five of these ten adapters write and are therefore always subject to confirmation; two reading ones require confirmation by default as well because they touch a personal matter. A tool belongs to exactly one assistant, not to the tenant — a second assistant for a different purpose has its own set.

Below them sit the cases of the Custom package: they are not part of the kit but are set up per assistant as an action of their own — with key, schema, target address, minimum role and approval path. Calculating and record-keeping happen in your system; the assistant asks, applies and passes on what came back.

  • Capture an Enquiry (lead)

    Writes name, email, telephone and request into the company inbox and attaches files the visitor uploaded during the conversation. Writing, and therefore always with confirmation.

    • The call first stands at proposed and executes nothing
    • The one-time key is formed from conversation, tool key and sorted input via sha256
    • The bolt against a double click sits in the database, not in the controller
    • An accepted enquiry additionally raises the outbound event lead.created
  • Appointment (appointment)

    Requesting, rescheduling and cancelling sit in one build form, together with the free list, which calculates free times from the company's appointment kinds minus the appointments already requested or confirmed at XICBOT. A request is only created if the appointment kind is known to the company, the lead time fits and the moment falls inside a window; availability is checked under a lock, and the request only becomes an appointment once the company confirms it. The preview follows the act — cancel, reschedule and request each read as their own sentence.

    • The company's appointment kinds sit in the schema as a selection list in the field kind
    • Availability is checked under a lock, not merely read
    • The schema demands only the start — a request may come into being without a name
    • A request that has been taken raises the event appointment.requested
  • Hand Over to a Human (handoff)

    Sets the conversation to escalated, creates an enquiry and notifies a human. A second handover in the same conversation triggers no second message. The visitor is not told by which route the company is notified.

    • Sets the state of the conversation to escalated
    • A second handover returns duplicate_prevented rather than an error
    • The approval path is recorded alongside: automatic, visitor_confirmed or, in test conversations and via the API, operator_confirmed
  • Search the Catalogue (product_search)

    Knows four forms: search, compare, bundle, also bought. It returns at most six hits and answers only from the company catalogue; a stated article key beats the search term. Without a term and without a key there is no result but a note, and a comparison needs two articles.

    • Four forms: search, compare, bundle, also_bought
    • At least one and at most six hits per call
    • A reference from a foreign card does not lead out of the company catalogue
    • If it stays at one article, there is no comparison
  • Hand Over a Basket (cart)

    Six kinds of change, at most 99 units per item. The basket sits with XICBOT, but with no price or stock truth of its own: the total uses the live price from the shop, and if the shop does not answer, the price from the last sync together with its date. “Continue” leads to the stored shop address, with a pickup token attached. Through a read-only pickup address at XICBOT the shop can fetch the basket with that token; the shop connects this pickup through an integration of its own.

    • Six kinds of change: set, add, update, remove, clear, coupon
    • The handover carries a random pickup token that exists only inside the address
    • The card in the conversation shows items, total and a shipping line
    • The bolt made of conversation and input prevents a duplicated handover
  • Order Status (order_status)

    Reads the status of an order in your connected inventory system — and by default still requires a confirmation, because it is a personal matter. Reading is no free pass here.

    • Area inventory management, kind read, approval confirm
    • One of two reading build forms that still require a click by default
    • Your system's answer is filtered down to the result fields named in the adapter
  • Change an Order (order_change)

    Changes an order in the connected system. Writing, with confirmation, and with a one-time key in the call's header so that a repeated call does not take effect twice on the other side.

    • Area inventory management, action order.change
    • The one-time key only travels out as a header for non-reading build forms
    • Writing never receives automatic — that is already in the adapter contract
    • A response without the field ok counts as a breach of contract, not as a result
  • Stock (inventory_status)

    Reads stock levels and by default runs without asking, because the build form touches nothing personal and writes nothing. Like every reading build form, it can be switched to “with confirmation”.

    • Area inventory management, kind read, approval automatic
    • Before every call the resolved A and AAAA addresses are checked, not just the name
    • The call does not follow redirects; a 3xx response is an error
  • Price from the Catalogue (price_lookup)

    Reads a price from a foreign catalogue, without a query. The price comes from your system; the assistant passes it on instead of forming it.

    • Area catalogue, kind read, approval automatic
    • Adopted text fields hold 600 characters, lists 20 entries
    • If nothing comes back, the assistant names the failure instead of a figure
  • Calendar (calendar_availability, calendar_booking)

    The assistant reads free slots from the connected calendar without a query; an entry into that calendar writes and only goes out after confirmation.

    • Area calendar: calendar_availability on automatic, calendar_booking on confirm
    • Both go through the same connector with target check, deadline and size cap
    • The adapter sees tool, input, conversation id and one-time key — not the calling sentence
  • Customer Management (crm_lead, crm_activities)

    Creating a record writes, and reading a customer's activities requires a confirmation by default too. The minimum role a tool needs is stored on the tool: public, member, admin, owner.

    • Area customer management: crm_lead writing, crm_activities reading with confirmation
    • After the click, role and required fields are checked again, not only beforehand
    • In the widget the role is always public, even if an administration login happens to run alongside
  • Create a Ticket (ticket_create)

    Creates a ticket in your system out of the conversation — writing, with confirmation, carrying the conversation context in the envelope.

    • Area ticketing system, kind write, approval confirm
    • The outbound envelope carries adapter, domain, operation, action, tool, conversation_id and input
    • The response is filtered down to the result fields named in the adapter
  • Note a Callback (callback_note)

    Records a request for a callback. This is the documented form of what elsewhere is readily described as a completed form: a wish is noted, no form is submitted.

    • Area customer management, kind write, approval confirm
    • The preview names the input in plain words before the visitor confirms
    • Afterwards the matter sits in the log with input, result, duration and approval path
  • Call Your Own Address (http)

    This is where the individual function comes into being: a tool with your key, your schema and your address. The build form is classified as reading and stands on confirmation. Your endpoint decides what comes back — a calculation, a configuration, information from an internal application.

    • The key is lower case, with underscores, 3 to 64 characters, and unique per assistant
    • The title holds 120 characters, the description 600
    • A stored access token is replaced by __set__ when read back and is never returned
    • A target that redirects or points at a private address cannot be reached
  • Calculate and Configure

    The calculation logic stays where it is maintained: tiers, customer groups and multi-level case distinctions sit in your system; the assistant gathers the inputs in conversation and reports what your endpoint returned.

    • Price and quotation calculator based on your pricing logic
    • Product configurator, step by step along your options and rules
    • ROI and savings calculator from the visitor's input
    • Financing and leasing calculator — as an enquiry, not as an offer
    • Quantity tiers, customer groups and multi-level case distinction
  • Connect and Query

    Each of these queries is a tool with a target address that is checked before and after name resolution. Identification comes before any account information, and reading is no free pass there.

    • Order and delivery status including shipment history from your connected inventory system
    • Availability from the inventory system instead of a fixed statement
    • Customer account and CRM lookup after identification
    • An external data source or price API of your own
    • Connection to existing systems through one endpoint per task
  • Automate and Hand Over

    Several steps within one answer are foreseen and capped. Each step leaves its own line in the log, and writing steps wait for confirmation before they go out.

    • Multi-level lead qualification scored against your criteria
    • Create and route a ticket, priority included
    • Callback or appointment with confirmation
    • Escalation to the specialist team with notification
    • Chains of read, calculate, create, confirm and hand over
  • Deliver and Provide

    Whatever leaves at the end of a case is an action with approval as well — not a side effect of the answer. The assistant fills in a form only after the visitor has confirmed the details; it is submitted only if you allow submission and the visitor agrees, and the call is logged.

    • Fetch quotation data from your system and show it in the conversation as text
    • Fetch the address of a file or data sheet from your system and state it in the conversation as text
    • Pre-fill a form after confirmation and submit it if you allow it and the visitor agrees
    • Deep link to a product, a subpage or a prepared basket
  • Sources a Case Can Read From

    Every individual function begins with the data it is allowed to read. What that can be depends on the build forms above and on your own endpoint — not on a fixed list at our end. What the assistant answers from texts, by contrast, sits in the knowledge base rather than in the tool set.

    • The company catalogue with variants, prices and availability
    • Connected inventory system, order status and calendar through the adapters
    • Customer management and ticketing, each with a minimum role
    • An application of your own behind an endpoint that understands the envelope
  • What Comes Back From a Call

    Reading is followed by the action, and the action by the log. The assistant applies what your system returns and chains steps within one answer — up to the cap. How a single call proceeds technically is set out under tool control.

    • Capture an enquiry and file it in the company inbox
    • Request, reschedule or cancel an appointment, each with a preview
    • Create a ticket and pass the conversation context along
    • Hand over to a human with the full context
    • Assemble a basket in the chat and link through to the shop with “Continue”
    tool control

Which of these cases end up in your assistant is settled case by case: one case, one build form, one schema, one address, one approval path. The cases above are the scope of the Custom package, not a list every assistant carries in full.

Many of these build forms also carry the ready-made assistants: the cart assistant, the booking assistant and the lead assistant are the same tool set, arranged differently. Which sector reaches for what is shown on the references page; the assignment to the packages sits under pricing, the evaluation of conversations under conversation analytics.

When the foreign system stays silent, Example conversation, reconstructed
  1. Visitor:Where is my order 10482?

  2. Assistant:I will query the status in the inventory system. The call only reads, but it needs your confirmation because it concerns a personal matter.

    • order_status · reading, yet subject to confirmation · state: proposal
  3. Visitor:Confirmed.

  4. Assistant:The inventory system did not answer within the deadline. So I have no status and will not state one. I do not retry on my own — shall I pass your request on with the order number?

    • State: deadline exceeded · no result stored, only the error text · no second attempt
    • The visitor reads a generic sentence here; the error text itself is visible only in the admin view
  5. Visitor:Yes, please.

  6. Assistant:Passed on, together with the conversation so far and the order number. If you click the same handover again in a moment, no second notification arises.

    • handoff · conversation escalated · enquiry in the inbox · one-time key applies

8 of 8

questions without a basis declined instead of guessed

eight questions deliberately outside the material; the wording of every answer is in the measurement file

A Tool Belongs to One Assistant

  • The tool set hangs on the individual assistant, not on the account: a second assistant for a different purpose gets its own.

  • A tool's key is lower case, between three and sixty-four characters long, and used only once per assistant.

  • The allowance in the top right is the same figure the cap on tool calls later hangs on.

Demo account with sample data, German interface
Assistant management: the existing assistant with its key on the left; on the right the form for a new assistant with name, template and language, plus the current month allowance.

From the Case Description to an Approved Tool

The path is the same for every individual function, and it does not end at programming but at approval. Six steps, two of which deal exclusively with what the assistant may not do.

  1. Describe the Case

    First comes the sentence a visitor will say, and the answer they expect. From it emerges which details the assistant has to gather, which system answers them and at which point a human should agree.

  2. Choose the Build Form

    If an existing adapter covers the case — order status from a connected inventory system, calendar, ticket, customer management — it is used. Only when none fits does a tool for a free call against your own address come into being. A new special route is the exception, not the starting point.

  3. Define Schema and Required Fields

    The schema names every field the assistant may pass on, and at most twenty of them. Anything not in it is stripped from the request before it goes out. If a required field is missing, no call is made at all; the assistant asks instead.

  4. Enter the Address and Have It Checked

    The target address is registered, the deadline set, and it is settled which response fields may return to the conversation at all. The address is checked before and after name resolution; the call does not follow redirects, and an oversized response is discarded.

  5. Settle the Approval Path and Preview

    For each action it is settled whether it runs automatically or waits for a click, and which role it requires at minimum. Writing tools are hard-set to confirmation anyway. The sentence the visitor reads before clicking is stored alongside and is not regenerated later.

  6. Test, Then Operate

    What is tested is not only the successful case but the failure: if the foreign system stays silent, the assistant says so instead of guessing. In operation every call sits in the log with input, result, duration and approval path, and further cases are added as tools of their own.

Between step four and step five lies the point where projects most often get stuck: the target address is in place, but nobody has decided which response fields may return to the conversation at all. Unnamed fields never reach the model — that is the gain, but it costs a decision.

After going live the path stays open: a further case becomes a further tool on the same assistant. The line on your website is not touched for it.

What an Individual Function Costs

Three things determine the effort: how many cases the assistant is to cover, whether an existing adapter fits or a call of your own is needed, and whether your system already offers an endpoint or has yet to receive one. Which of these applies is clarified before the quotation, not after.

Custom package

from 4,900 € net setup

Minimum term: none, cancellable monthly

  • Individual: setup from 4,900 € net, operation based on scope
  • Tailored actions, workflows and your own cases
  • API connections, calculations and configurators included
  • European or self-hosted language models as a separate project by arrangement

All prices net, plus VAT Source: XICBOT price list, as of 11 September 2026

Individual functions belong to the Individual package: setup from 4,900 € net, with operation based on scope (hosting in Germany, ongoing operation, care, updates, data protection). Included are tailored actions, custom logic, API connections, calculations and configurators; European or self-hosted language models are possible as a separate project by arrangement and are not included in standard operation. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.

Talk Through Your Special Case Once

Describe the process the assistant should map. You get a factual assessment of effort, interfaces and permissions before you commit to anything.

Discuss your special case Tools and approvals in the documentation

Builder Action or Individual Function?

A builder widget brings a few standard actions but quickly reaches its limits as soon as a case becomes more specific. An individual function starts exactly there: your own data sources, your own logic, real calculations and a deep connection to your systems. The comparison shows where the difference lies in everyday practice.

Builder Action

  • Data sources: fixed, predefined fields
  • Actions: a few standard actions
  • Calculations: hardly or not possible
  • Connection: superficial or none at all
  • Control: little insight into what was triggered
  • Limits: target, deadline and response length not adjustable

XICBOT — Individual Function

  • Data sources: catalogue, inventory, calendar, documents or an endpoint of your own
  • Actions: your own actions, several steps per answer, capped
  • Calculations: your logic in your system, the result in the conversation
  • Connection: one envelope per task, reading and writing kept apart
  • Control: an approval path per action and a line in the log
  • Limits: target address checked, deadline set, oversized response discarded

Individual does not mean uncontrolledA language model can be wrong — which is why the assistant does not calculate itself but asks the system that keeps the figure, and states no value that did not come back. You decide per action what may run automatically and where a human confirms; for creating and changing, that choice falls away — there the confirmation is hard-set.

From a Need to a Function

Individual functions show their value where standard answers are not enough. The following journeys are anonymized and illustrative and show how a specific need becomes a matching function.

Today

  • Retail / quote: Individual quotes are put together by phone and email, one at a time
  • Service provider / calculator: Without a calculator every cost statement stays an estimate
  • Service / status: Status questions about orders land in support one by one
  • Practice / appointment kind: Appointment requests arrive by phone, and whether the requested kind is offered at all only becomes clear during the call
  • Service / fault: A fault report is typed out of an email before it reaches the ticketing system
  • Internal / special case: For a process no standard action covers, the callback remains

With the assistant

  • Retail / quote: A tool passes options and quantities to your pricing logic, the result appears in the conversation. The team then handles the special cases instead of every enquiry
  • Service provider / calculator: The assistant gathers the input in conversation, the calculation happens in your system, and back comes a figure with the items behind it — and in case of a failure, the note about it instead of an invented sum
  • Service / status: The status comes from your inventory system, the call is confirmed beforehand by default, and every piece of information sits in the log with input and result
  • Practice / appointment kind: The appointment kinds sit in the schema as a selection list; a request is only taken for a known kind, a fitting lead time and a free window, checked under a lock
  • Service / fault: ticket_create opens the matter carrying the conversation context — writing, and therefore only after a click by the visitor
  • Internal / special case: A tool of your own calls your address; which response fields may return to the conversation is settled by you beforehand

Talk your case throughDo you have a process in mind that goes beyond standard actions? In the initial conversation we walk through it step by step and name which build form carries it, which details your system needs for it and at which point a human confirms.

„We do not promise a flawless know-it-all. We construct the cases your everyday work needs — bound to your logic, executed with permissions and handed over to a human at any time.“ — Our approach

How an idea becomes an accepted assistant is described in from idea to a live AI chat assistant. Which actions are technically possible and where permissions apply is shown in the AI assistant controls your tools. How a purpose-built assistant differs from a template bot is compared in custom assistant or standard chatbot.

Frequently Asked Questions About Individual Functions

The questions below come from conversations with companies that already had a process in mind. They turn less on what is possible than on who decides in case of doubt and what happens when a connected system does not answer.

What exactly are individual functions at XICBOT?

Individual functions are your own actions and processes that go beyond the seventeen shapes shipped with the product. The basis is the tool control: a tool is given a schema, a kind — reading, writing or irreversible — and an approval mode. Reading tools may be set to automatic, anything that writes asks first. The way out to your system runs through exactly one connection with target check, time limit and size limit, without redirects and without access to internal addresses. The tool only ever sees its own schema fields; tenant and account identifiers are blocked as field names. This lets us cover cases no construction kit anticipates — a calculation, a configurator or a multi-step process. Overview under custom functions.

Can the assistant calculate or map a configurator?

Yes, with the calculation happening where the numbers come from: in your system. The assistant guides the steps, collects the details and calls your calculation route. You describe the tool for it yourself — a schema with up to twenty fields, a title up to 120 and a description up to 600 characters; the input is trimmed to that schema before the call, values are capped, and if a required field is missing nothing is executed at all. The call goes to exactly one stored connection, waits at most eight seconds and accepts at most 64 KiB; what comes back are only the result fields you declared. Prices therefore come out of your logic, not out of the language model. More under custom functions.

How does XICBOT connect my existing systems via API?

In the Custom package, through tools you create per assistant: inventory, CRM, calendar, ticketing or an interface of your own. Every tool carries a kind, namely read, write or irreversible, and an approval mode; the preset is to ask back before executing. Kind and schema come from the register and not from the request. Outward, every call takes the same path: the target address is checked before the fetch, and the resolved addresses are checked rather than the name alone, redirects are not followed, a response above 64 KiB is aborted, and a deadline of eight seconds applies. Whatever comes back is filtered down to the declared result fields. More under tool control.

Do I keep control over what the assistant does?

Yes. Every tool carries an approval mode, and the default is confirmation. Without confirmation only something that reads and is explicitly set to automatic will run; every non-reading kind is forced to confirmation when created or changed, no matter what the request says. A call that requires confirmation first ends in the state proposed and executes nothing: the visitor reads the input in plain text, and only their click triggers execution. Every call leaves a log row that is written before execution and updated afterwards, and knows seven states from proposed to deadline exceeded. The model is offered only what you have entered, switched to active and allowed for the role of the conversation.

Can several steps be chained into a workflow?

Yes, in the Custom package. We chain individual actions into a continuous process — for example read out, calculate, create a document, create a ticket and hand over the lead. This creates a path without media breaks in which each step has its own permission: anything that does more than read is first shown to the visitor as a proposal and confirmed by them. The chain is bounded so it cannot run away: per answer the assistant performs at most five tool calls, and only one when the monthly allowance is tight. Every single call is then recorded in the log, with input, result, duration and the path by which it was approved.

What does an individual function cost?

Individual functions belong to the Custom package with a setup from 4,900 € net; operation follows the scope and includes hosting in Germany, care, updates and data protection. There is no list price for operation there, because the number and type of connected systems determine the effort. The package holds 50 seats, 25 assistants, 250 knowledge sources and 20,000 documents and allows tool and API control with custom actions and workflows. We name the binding scope after a free initial consultation. All packages are listed under pricing, typical cases under references. All services can be cancelled monthly; there is no minimum term.

If a question about your case remains, it is usually a question for your own system: is there an endpoint there, and which fields does it hand out? We clarify both in the initial conversation, before anything is set up.

Before the setup

What We Need for a Conversation

It goes fastest if you bring a real case rather than a feature list: the sentence a visitor says, the answer they should get, and the name of the system that knows it. From that it can be said whether an existing adapter suffices or a call of your own is needed. Describe your case

Which Process Should Your Assistant Handle?

Describe briefly the process the assistant should cover — and, if you know it, which system keeps the data for it. We report back which build form fits, which details your endpoint would have to supply and where a confirmation becomes necessary. You can reach us by phone at +49 5123 9579000.

Enquiry in three steps

  1. 1. Topic
  2. 2. Your case
  3. 3. Contact

What is this about?

One click is enough, everything else is optional.

Tell us briefly about your case

Everything in this step is optional. It helps us reply with something concrete straight away instead of asking back.

For example calendar, CRM or inventory management

For example look up a status or create an appointment

When should it start? (optional)
How can we reach you?

Name and email address are enough. We reply personally.

We use your details to handle your enquiry. More on this in the privacy policy.