- Print
- DarkLight
- PDF
Overview
The Simulator folder is located in Stages > Stage name > Communications Orchestrator > Messengers > Simulator folder.
A solution for organizing live chat between a client and a human operator is built on the Simulator within Communications Orchestrator. In the Communications Orchestrator > Simulator folder, you'll find:
- Processes for the operator's workspace to handle dialogs
- Chat history, client profiles, analytics, dashboards.
BP: business processes. which you can reconfigure and adjust.
bp > chats > freeze chat: the process that handles the freeze event in dialogs = dialog closure. In this process, transactions against customer and operator accounts are made for analytics collection, as well as the change of dialog connections with streams.
bp > chats > create employee > create dashboards: this process starts on occurrence of the “Creation of the new employees actor” event, and the creation of new dashboards for a new operator.
bp > chats > send file from operator to client: sending of files from an operator to a customer is performed in this process.
bp > chats > update agent status: this process starts on occurrence of the “update actor employees” event if the status field is altered. In this process, transactions against operator accounts are made for tracking the time the operator's being in each status.
bp > chats > done chat: in this process, the Done reaction in the operator chat is handled.
bp > chats > get available chatId: the process retrieves a free new chatId from a queue.
Scripts: stores the processes for each script in Simulator in which the handling of all requests from the scripts.
Widget: widget processes.
Generator chatId: processes for generating a unique chatId.
Setup Simulator Cache: the process starts automaticaly when a Communications Orchestrator is created. It goes through all the entities created in Simulator and unites them into a single cache object. This object is stored in the Simulator Cache State Diagram and is used in most processes for a quick access to Simulator objects.
Simulator Entities Contained in the Folder
After creating Communication Orchestrator in Corezoid, a set of necessary forms, actors, and accounts for orchestrating messages between the client and the operator, as well as for collecting analytics, was imported into your workspace in Simulator.
When you create a Communications Orchestrator in Simulator, the following entities are created:
1. Forms (Editors->Forms section of the Simulator main menu, Custom Forms tab)
These are used to describe the structure of data for uniform objects (actors).
Forms are very flexible, and their model can be changed or extended as needed. Any attributes described in the form can be used to build filters or selections of actors. The following types of forms were created:
- employees: Describes the data structure of employees (operators, supervisors, etc.)
The Group field refers to the filter for all actor groups.
The Status field refers to the filter for all operator statuses.
Describes the structure of groups. Groups can be used to combine several employees and apply any mass actions to the group.
Groups are added as an example and are not used by default in the logic of Communications Orchestrator
- users: Describes the structure of clients data from various channels
Provided below is the minimal set of user attributes. It can be extended as needed and included in any business logic.
- chats: Describes the structure of chats data
The User field refers to the filter by all users actors.
The Operator field refers to the filter by all employees actors.
The Channel field refers to the filter by all channels actors.
The Status field refers to the filter by all chatStatuses actors.
The channels, chatStatuses, and operatorStatuses forms serve as dictionaries. You can create as many dictionaries as needed and start using them in your processes.
2. Actors (Simulator->Actors bag section of the Simulator main menu)
If Forms describe the structure of actor data, Actors bag is where we work with the actual actors. An actor can be anything: a specific operator, a specific client, a specific chat, and so on.
On the Actors bag page, you can do the following:
- Apply fast filters.
- Configure your own filter, pin it, and grant access to colleagues
When creating a filter, you can reference any attributes of the actors it owns. You can also construct the display of the table with filter results using the Columns to display in actors bag setting.
Your Communications Orchestrator is created with several ready-to-use filters. Check them to pin the tab in Actors bag for quick access.
- Create new actors, view actor details, Edit actor, etc.
If, for example, you need to add a new operator or expand the status directory, you can simply click the Create button in the Actors bag, select the appropriate form (which type of actor you are creating), and fill out the form.
To create an actor of the employee type in the form, you need to enable the Optional fields toggle and choose the corresponding user in the Single account user field, who is registered in the system. By doing this, you establish a connection between the actor and the actual user in the system. A user can only be associated with one actor in the workspace at a time.
This action is necessary for the logic of distributing dialogs between operators, which is configured in the /startChat process.
When creating Communication Orchestrator, one employee actor is created corresponding to the user who created Communication Orchestrator.
- View actor’s accounts
Accounts can be used to track any action, event or other changes.
After creating Communication Orchestrator, several accounts were created for clients and operators, where the following are accounted for:
- the number of chats per operator (active / total)
- ratings given by clients to the operator
- how much time the operator spent in different statuses.
Correspondingly, in Corezoid, processes are built that respond to triggers to create transactions and update account balances.
Account balances can also be used in business logic. For example, the activeChats account on actor-employees is involved in the logic of distributing dialogs between operators. More details can be found in the /startChat process.
If you need to start keeping track of anything else, simply open an account for the corresponding type of actors, specify the currency - what to track, and build processes to create transactions.
3. Events (Simulator->Events section of the Simulator main menu)
The Events section is the main working space for agents handling dialogs.
There are 2 modes for viewing the list of events: Regular mode and Split mode.
For working with multiple dialogs simultaneously, we recommend using the Split mode. It allows you to switch between conversations with one click while seeing the full picture of your dialogs: the appearance of new dialogs, new reactions in current dialogs, etc.
In Simulator, you can distribute events (dialogs) to different streams. Adding an event to a stream equals creating a connection (edge) between event actors and stream actors. There are 3 system streams: To Do, To Sign, Starred. After creating Communication Orchestrator, 2 new streams were added: Active chats and Closed chats.
To stop displaying system streams and enable the display of the ones you need, click on the settings icon and check the boxes for the streams you want to display.
Active chats: New dialogs get listed in this stream and remain there until they are closed. The logic for adding a new dialog to this stream is configured in the /startChat Corezoid process.
Closed chats: Dialogs are moved to this stream from Active chats immediately after the chat status changes to closed.
You can create new streams and configure the logic for adding dialogs to them as you see fit. For example, streams based on the themes of inquiries or based on the channels of inquiries. Or streams based on the duration of the dialog, etc.
The same dialog can be maintained in multiple streams simultaneously.
4. Dialog components
- Dialog name: a dialog can have any name. The following dynamic structure is used:
{channel} - {chatId} - {userName}
Where:
channel: the channel of the inquiry
chatId: a unique chat ID generated in the chatId generator process. The algorithm can be modified.
userName: user name retrieved from a users actor
- Card of an actor which was added to the dialog: a card of a chats actor, which characterizes the dialog itself, is added to the dialog. You can change this in the processes.
- Shared with: indicates who has been added to the dialog and with what roles. Also, the operator can manually share the dialog with another operator or a group.
- Linked actors: a list of actors associated with the dialog. Linking the dialog to actors is necessary for displaying the selected dialog in the history of events for these actors. Currently, history is linked to actors in:
- Streams: activeChats / closedChats
- Employees: the actor of the operator who is handling the dialog
- Users: the actor of the client who contacted support
- Done: This action is tied to the logic of completing the dialog from the operator's side.The Simulator Receiver Corezoid process tracks the event that the dialog has been completed, triggering the /NPS process.
You can modify this logic. - Running Scripts within the dialog with the option to specify the recipients.
- Snippets: allow the fast use of predefined phrases.
5. Dashboards: using analytics with dialogs
If account balances are tracked for actors such as operators or users, etc., on the dashboards, it's possible to visualize the balances or transaction dynamics.
How to configure Dashboards
The architecture of Communications Orchestrator inherently includes the logic for automatically creating four dashboards as soon as employee actor is created.
You an view these dashboards in Graphs > Dashboards. A separate layer is created for each employee with metrics specific to them.
This logic is built in the bp > chats > create employee > create dashboards process and can be changed or expanded.
Switching between the layers:
6. Widget
After Communications Orchestrator has been created, a widget actor was created, which you can acces in Simulator under the Communications section.
In the Embed code tab, you can obtain the embed code for the widget and add it to your website or any test environment.
7. Scripts
Together with the widget the Welcome and Chat rating scripts were created.
Start Script: This script executes when the widget is launched.
Final Script: It executes when the user clicks the close button (X) in the widget.
Scripts configuration and logic
- The configuration of these scripts and their execution logic can be modified.
- In Corezoid, processes for interacting with scripts are located in the Communications Orchestrator > Messengers > Simulator > Scripts folder.
- After creating Orchestrator, replace Corezoid credentials in the script settings with your ones.
- Create an API Key in Corezoid and grant Task management access to this API Key for each main receiver script. (Process “script - {scriptName} - main receiver”).
- Fill in the corresponding parameters in the settings of each script: API login, API secret, Company ID, Dev process ID, Prod process ID. You can specify the same Dev and Prod processes if desired.
Agent panel script
- Used for changing the operator's status to avoid giving operators direct access to actors-employees
- You can add this script to favorites to add it to the side panel (it will appear on the panel after refreshing the page).
- Every change in the operator's status is logged on the respective accounts and displayed on dashboards
- The logic for this is configured in the process bp > chats > update agent status.
- If you add new statuses, you'll need to modify this process accordingly.