Contents
- Account
- Channel
- Chat
- Dialog
- Dialog owner
- Client
- Conversation
- Agent
- Catalog subagent
- Agent version
- Agent settings
- Prompt
- Scenario
- Step
- Step data
- Conditions
- Action
- State variable
- Scenario context
- Signal
- Work dashboard
- Dashboard task
- Document
- Delayed action
- Schedule
- Active chat
- Billing period
This section describes the main entities and concepts of the Chat Assistant service.
Account
An account is a CRM account within which chats with clients, agents, knowledge base documents, and connection settings for the system are created.
A new account is created automatically when the "Chats" module is activated in the CRM.
Channel
A channel is the source of the conversation with the client: WhatsApp, Telegram, the website's online consultant, Instagram, and others. An agent is configured to work on certain channels, and it is by the channel that the system decides which agent should handle a particular conversation.
Chat
A chat is the conversation with a specific client on a specific channel. The same person writing on different channels is represented in the system as several separate chats.
Dialog
A dialog is an individual enquiry within a chat. A dialog has a status (open or closed) and an owner. Over its history, a single chat can contain many dialogs: the client got in touch, the question was resolved and the dialog was closed; later the client wrote again — a new dialog opened.
Dialogs are not stored in the conversation history as separate objects, but they affect the agent's work through events: assigning a dialog can start the agent, and closing it can stop the agent and clear the conversation context.
Dialog owner
The owner is whoever is currently handling the dialog: the bot or a manager. Whether the agent can reply to the client depends on the owner: it replies only when the dialog belongs to the bot. While a manager is handling the dialog, the agent does not intervene in the conversation, although it keeps receiving messages and can perform background actions. This is the key security barrier between the agent and the client.
Client
A client is the representation of the other party on a specific channel (WhatsApp, the online consultant, etc.) that the agent works with. It is created automatically and linked to the corresponding client card in the CRM.
The same person writing on different channels is represented in the system as several separate clients — each with their own conversation, and each billed separately.
Conversation
A conversation is the history of communication with the client in Chat Assistant: messages from the client, managers, and agents, as well as the agent's internal calls and system data, starting from the moment the agent is enabled on the channel. Different agents can work on the same conversation, for example during and outside working hours.
A single client can have several conversations; however, in the usual case only a manager starts a new one, using a special command in the chat. At any given moment, the agent works with only one active conversation of the client.
A conversation is linked to the client's active dialog in the CRM and makes it possible to perform actions on it — for example, distributing or closing the dialog. The dialogs themselves, however, are not stored in the conversation history as separate objects.
Agent
An agent is a separate virtual assistant that has its own name, tasks, communication style, and a set of scenarios it uses to help resolve routine matters in the chat with the client. For example, one agent may be responsible for client support, another for sales or reminders.
It brings together how the assistant is perceived in the interface, what tasks it solves, what tone it communicates in, and which service scenarios it supports. Importantly, an agent is not a one-off setup but a "container" for the agent's evolution: it can be developed through versions, have its logic changed, its instructions refined, and different capabilities connected, while preserving a single recognisable entity for the business and the users. Simply put, it is a manageable character-service around which the user experience is built.
Besides the ordinary agent for working in the chat, there is also a separate subtype of agent for working on a comments channel, where replies must be sent quoting the client's original message.
Catalog subagent
The catalog subagent is a separate assistant that searches for products and services in the connected CRM catalog and assembles the order contents or cart from them. The main agent calls on it when items need to be selected during the conversation. For details, see the Catalog subagent section.
Agent version
An agent version is a specific version of the configuration. It is to the version that all of the agent's working settings are tied: instructions, working modes and chat channels, scenarios, signals.
A specific agent can have only one running active version.
Agent settings
The agent's main settings include:
- the chat channels the agent works on
- the working mode: working or non-working hours based on the system settings
- the language of communication
- the general style, tone, and length of replies, the delay before replying, and splitting the reply into several messages
- automatic reminders to the client about an unfinished dialog
- closing a dialog that has been handled and is logically complete
- access to the catalog of products or services in the system
- expanding the knowledge base based on clients' unanswered questions
Prompt
A prompt is the basic set of instructions for the agent, which is central to describing the agent's identity, its positioning, and the tasks it must solve when communicating with clients.
In the agent settings you can add several prompts in slots with different logical purposes. A slot is a special place within the agent's system instructions that lets you adjust the agent's behaviour in the desired direction and add the context it needs for its work. The main prompt is mandatory.
The full list of slots and their functions is described in the Instructions section.
Scenario
A scenario is a predefined logic of the agent's behaviour, assembled from individual steps. The steps are linked to one another by transitions, and it is the scenario that determines everything useful the agent can do: ask questions, collect data, create orders, hand the dialog over to a manager. For details, see the Scenario steps section.
Step
A step is the basic unit of a scenario and the main building block of the agent's useful work. A step is called either by the agent itself during the conversation or by the system in response to an event (a message, a signal, a timer). Inside the step you define the data to collect and the actions the system will perform. A set of linked steps forms the scenario. For details, see the Scenario steps section.
Step data
Step data (step variables) are the values the agent extracts from the conversation when a step is called: phone, name, type of enquiry, the chosen option. Each field has a type — from string and number to composite types (phone, address, order contents) and reference values from the CRM; by the type, the agent understands what to collect, and the step's actions save what was collected to the client card or order and branch the scenario. A field can be marked as required: while such fields are not filled in, the step does not run to completion. For details, see the Step data section.
Conditions
Conditions (universal activation conditions) are system checks that determine a step's availability: for example, working hours, a client tag, a signal value. They work the same way for steps of any type and are performed by the system itself before the step reaches the agent. If a condition is not met, the step is unavailable — the agent will not see it, and an event step will not fire. For details, see the Conditions section.
Action
An action is an operation the system performs when a step runs: save data to the client card or order, go to another step, hand the dialog over to a manager, start the agent, and others. Actions are performed by the system, not the agent, and the agent itself does not see them — for it, a step is a "black box". All of the agent's useful functions are made up of the set of actions packaged into steps. For details, see the Actions section.
State variable
A state variable is a value that is saved within the conversation and is not visible to the agent. It is written by the "Update state variable" action and used by conditions to branch the scenario. Unlike the scenario context, state variables are preserved between the dialogs of a single chat. For details, see the Data sources for conditions section.
Scenario context
The scenario context is one of the instruction mechanisms for the agent. It is added by the "Update scenario context" action, and it is shown to the agent in the work dashboard as a background instruction, influencing its reasoning on subsequent steps. Unlike a state variable, the context is visible to the agent. For details, see the Scenario instructions section.
Signal
A signal is a background characteristic of the conversation that the system determines automatically and separately from the agent's main work: for example, the client's mood, the type of enquiry, the presence of a complaint. Signal values are shown to the agent and can trigger scenario steps or take part in conditions. For details, see the Signals section.
Work dashboard
The work dashboard is the summary of the current state that the system shows the agent on every turn: which data has already been collected, what is missing, what tasks are pending, and which step to move to next. The dashboard strongly influences the agent's actions and updates in real time. This is dynamic data — it is not stored in the conversation history. For details, see the Work dashboard section.
Dashboard task
A dashboard task (agent task) is a specific instruction the system gives the agent in the work dashboard: collect the missing data for a step, carry out an instruction, go to the next step. Tasks appear and are removed as the scenario progresses — it is through them that the system guides the agent. For details, see the How the agent works through a scenario section.
Document
A document is the unit of the knowledge base: reference material that the agent retrieves on demand during the conversation (prices, delivery terms, answers to frequent questions). Documents come in different types — text, file, link, question-answer — but any of them ultimately becomes the text the agent searches through for an answer. For details, see the Knowledge base section.
Delayed action
A delayed action (reminder) is the running of a scenario step by a timer after a set time. It is used to bring the agent back to work later: to remind the client about an unfinished dialog or to continue the conversation if the client has gone quiet. For details, see the Delayed actions section.
Schedule
A schedule is a set of defined time windows (working hours by day of the week, taking into account the time zone and breaks) that the agent's behaviour relies on. Besides the CRM's general working hours, you can create your own schedules for different tasks and reference them in the agent's working mode, in scenario conditions, and when launching delayed actions. For details, see the Schedules section.
Active chat
An active chat is the billing unit: the agent's conversation with the client on a single channel during the billing period (30 days). Billing is for active chats, not for the number of messages or dialogs, and only for those in which the agent actually worked. The same person on different channels means different active chats. For details, see the Billing section.
Billing period
A billing period is the agent's 30-day billing cycle. Within the period, the cost of an active chat is fixed, and at the end it is recalculated for the next period. It is tied to the agent as a whole, not to a specific version, so switching versions does not reset it. For details, see the Billing section.