Deep Messaging Integration Methodology by Metabot

The World That Started to Speak

From Interfaces to Dialogue

Over the past ten years, the digital world has undergone a paradigm shift.
Previously, people interacted with systems through forms, buttons, and interfaces.
Now they interact with words.

The user no longer visits websites — they write.
They don’t look for a support phone number — they ask a question.
They don’t install an app — they just open a messenger.

Communication has ceased to be a “channel.”
It has become an operational environment —
a place where deals are made, decisions are taken, and data is born.

---

Business as Dialogue

For companies, this means one thing:
Dialogue is the new form of organizing processes.

Where there once was a support department, now there is a chat center.
Where there once was a CRM, now there is an interactive communication interface.
Where there once was a landing page, now there is a dialogue scenario
personalized for each user.

Business is learning to speak in the digital space —
and this conversation must be connected with its systems, data, and people.
Otherwise, it won’t become part of the value creation chain.

---

Messengers vs Applications

Messengers won not because they are more convenient —
but because they are more natural.

They don’t require onboarding, don’t need updates,
and they operate in the user’s native language.

For business, this opened up the opportunity to create services
that live directly inside Telegram, WhatsApp, VK, or a web chat.

A chatbot = a mobile app without an app.
It can sell, consult, accept orders, send notifications, or educate.
And most importantly — it connects to the enterprise core systems.

---

From Channel to Infrastructure

But simply “launching a bot” is not enough.
True value emerges when dialogue is embedded into the architecture of the business.

When CRM, ERP, Helpdesk, and the marketing platform are connected
with messengers into a single contour
where data and events move bidirectionally.

This gives rise to a new engineering logic —
ComOps, Communication Operations — the communication operating system.
And its first layer is the Deep Messaging Integration (DMI) methodology.

---

The Architecture of Deep Integration

Definition of DMI

Deep Messaging Integration (DMI) is a way to connect messengers and internal systems
so that dialogue becomes part of the business process.

It is not a marketing integration or mass messaging tool.
It is an engineering architecture where every system event can trigger a communication,
and every user response can trigger an action in the system.

---

Three Layers of Integration

DMI is built on three interconnected levels:

Layer	Purpose	What Happens
Communicative Layer	Interaction with the user	Dialogues, notifications, scenarios, forms
Operational Layer	Execution of operations & logic	Scenario runs, plugins, tables, automation
Integration (API) Layer	Connection with IT systems	REST endpoints, identification, data exchange

These three layers merge into a single stream — the Dialog Bus.
It works like a nervous system: it receives a signal, processes it, and sends a response.

---

How the Integration Cycle Works

[User]
↓  (Message)
[Communicative Layer / Metabot]
↓  (Intent, Context)
[Operational Layer]
↓  (API Call)
[Core System / CRM, ERP]
↑  (Data, Events)
[Metabot / Dialogue]
↑  (Response, Notification)
→ New Context and Memory

Each cycle is complete:
a dialogue generates an action,
an action generates data,
data generates a new interaction.
Thus, a living link between communication and operation is created.

---

The Communication Layer in Metabot

On the Metabot platform, communications are implemented via low-code scenarios.
Each scenario is an executable dialogue program with conditions, variables, and transitions.

Types of scenarios:

• Greeting and onboarding flows
• Service notifications
• Interactive surveys and forms
• Transactional dialogues (orders, payments)
• Personalized bot assistants

A scenario can be triggered automatically by a system event
or launched manually by an operator.

---

Operational and Integration Layers

• The Operational Layer executes commands in real time: JS plugins, tables, Service Blueprints, event bus.
• The Integration Layer provides REST endpoints through which business systems trigger communications.

Example:

POST /bots/{botId}/call/users/update
POST /bots/{botId}/call/order/thank-you

Each endpoint has an alias, a request body (script_request_params),
and a result (success: true).

---

DMI Switching Logic

1. A system event → triggers a Metabot endpoint.
2. Metabot launches the corresponding communication in the bot.
3. The bot processes the user’s reply and returns data to the system via API.
4. Context and attributes are stored in memory.

The result — a closed loop “event ↔ communication ↔ action ↔ context”,
which becomes part of the company’s operational cycle.

---

Why It Matters

Deep integration changes the role of communications:
from a channel — to infrastructure,
from marketing — to operations,
from support — to intelligence.

Strategic Planning: Customer Journey and Service Blueprint

Before designing specific scenarios or integration points,
it’s important to see the overall picture of how the customer interacts with your business.
Two interrelated methodologies are used for this:

1. Customer Journey Map (CJM) — the customer’s path, describing the external experience and touchpoints.
2. Service Blueprint — the map of internal processes and systems that deliver that experience.

Between them lies the domain of Deep Messaging Integration (DMI):
it connects the external user experience (CJM) with the internal infrastructure of the company (Service Blueprint),
turning communications into an operational layer.

---

Customer Journey Map (CJM): The Customer’s Path

Customer Journey Map (CJM) is a visualization of the path your customer takes when interacting with your product or company —
from the first brand encounter to repeat purchases and recommendations.

Creating a CJM helps you understand at which stages the customer needs communication
and where dialogue automation can increase value.

---

How to Use CJM in the Context of Metabot

1. Define the persona and goal.
   Who are you designing for: a client, a partner, an installer, a dealer, etc.?
   Define the goal: registration, purchase, learning, support.

2. Break the path into stages.
   Example:
   Awareness → Registration → First Purchase → Delivery → Feedback → Repeat Order

3. Define touchpoints.
   Where and through what the customer interacts: website, Telegram, email, offline meetings, bot dialogues.
   These touchpoints become future communication nodes in Metabot.

4. Describe emotions and needs.
   What does the customer feel at each stage?
   Where do they get confused, frustrated, or delighted?
   This helps define the tone of voice and timing of communications.

5. Find opportunities for improvement.
   Identify where communication can reduce friction, accelerate progress, or add value.
   For example: webinar reminders, automatic delivery status updates, hints during registration.

---

The Link Between CJM and Communication Maps

CJM shows the customer journey on a strategic level.
Once you see the entire route, you can zoom in on specific sections —
and turn them into Metabot Communication Maps, which describe concrete messages, participants, and API calls.

💡 Thus, a communication map is a localized fragment of a CJM,
implemented as scenarios and automations inside Metabot.

---

Customer Journey Table Template (for independent use)

Customer Journey Stage	Customer Goal / Why They Do It	Customer Actions	Emotions 😊😐😞	Needs & Pains	Touchpoints	Communication (Scenario / Message)	Integrations / Systems	Opportunities for Improvement	Responsible

Tips:

• You can expand columns in Miro, Notion, or Google Sheets.
• Emojis help visualize emotional peaks.
• The last two columns (“Opportunities” and “Responsible”) correspond to backstage elements from the Service Blueprint.

---

Example (Case: “Registration and Onboarding in a Telegram Bot”)

Customer Journey Stage	Customer Goal / Why They Do It	Customer Actions	Emotions 😊😐😞	Needs & Pains	Touchpoints	Communication (Scenario / Message)	Integrations / Systems	Opportunities for Improvement	Responsible
Awareness	Learn about the service	Reads a post / receives a link from a friend	🙂	Doesn’t want to waste time installing apps	Social Media, Landing	Bot message “Hi! I’ll show you how it works without registration”	Tilda, UTM tags	Add CTA for direct transition to bot	Marketer
Registration	Create a profile	Writes to bot, enters phone number	😐	Worries about data security	Telegram	Scenario registration_flow — contact request	CRM / API /users/connect-bot	Reduce registration steps	ComOps Architect
First Use	Check how it works	Passes an intro quiz	😊	Wants to quickly see value	Telegram Bot	Scenario welcome_tour — mini onboarding	Metabot / CMS	Add a short demo video	Product Manager
Feedback	Share impressions	Leaves a rating 👍	🙂	Wants feedback to be heard	Telegram	Scenario feedback_form — NPS survey	BI / Webhook /feedback/received	Add thank-you message	Analyst
Repeat Interaction	Get value again	Returns after a reminder	😊	Wants regular advice	Telegram, Email	Scenario retention_tips — series of useful messages	CRM, Mailer	Test content pushes	Marketer

---

How to Use

1. Copy the table and fill it in for your product.
2. Stages can be taken from the CJM (Discovery → Registration → Onboarding → Usage → Feedback → Retention).
3. The Communication and Integrations columns are your ComOps zone,
   where communication maps and integration points are created.
4. Once the table is filled, you can visualize it as a ComOps Loop:
   customer step → message → system action → feedback.

📘 Where to find templates:
Examples and ready-made templates for creating CJM and Service Blueprints are available in public libraries on Miro, Figma, or FigJam.

---

Service Blueprint: The Map of Internal Processes

If CJM reflects the external customer experience,
then the Service Blueprint shows what happens inside the company to make that experience possible.
It is a visual model of all the components and systems involved in service delivery,
and how they interact.

---

Why Service Blueprint Matters in the Context of Metabot

• It helps identify which internal processes and systems support each stage of the customer journey.
• It helps define where to create integration points (API, Webhook, Data Sync).
• It exposes bottlenecks in the infrastructure that prevent seamless conversational experiences.

---

Classical Structure of a Service Blueprint

Level	What It Describes	Example in the Context of Metabot
Customer Actions	Customer’s actions	Sent a message to the bot, confirmed an order
Front Stage Interactions	Visible interactions	Operator replied in chat, bot sent a scenario
Back Stage Interactions	Invisible processes	CRM updated a status, script created a ticket
Support Processes	Supporting systems and data	Database, API, automation in Metabot

---

How to Create a Service Blueprint for Integration

1. Define the goal and persona.
   For whom and why you’re analyzing the process (e.g., client onboarding or order processing).

2. Describe the interaction stages.
   Break the process into steps: request → processing → delivery → feedback.

3. Mark all touchpoints.
   Where and through which channels the customer interacts with the company (bot, website, email).

4. Divide into levels.
   Front stage — what the customer sees.
   Back stage — what employees and bots do.
   Support processes — which systems provide support.

5. Add integrations.
   Mark where APIs or events are needed for data exchange between systems.

---

Blueprint → DMI → Integrations

Once the Service Blueprint is ready, you can see
where the process can connect to dialogues in messengers.
These points become Metabot endpoints and DMI integration points,
described in the next section.

💡 Service Blueprint is the operational layer,
while Deep Messaging Integration makes it come alive, connecting system events and real dialogues within the ComOps architecture.

---

Service Blueprint Template (for independent use)

Level / Stage	Awareness	Ordering	Purchasing	Receiving	Using / Onboarding	Feedback
Customer Actions
Front Stage Interactions
Back Stage Interactions
Support Processes / Systems

How to fill:

• Top row (Customer Actions) — what the customer does.
• Then move down: what happens inside the company.
• You can add arrows, dependencies, or notes if working in Miro, FigJam, or Notion.

---

Example (Case: “Onboarding a New Client in the Service”)

Level / Stage	Awareness	Registration	First Use	Support	Feedback	Renewal
Customer Actions	Sees a Telegram post and joins the bot	Enters phone number, receives greeting	Goes through mini-tutorial	Asks a question in chat	Rates the experience 👍	Gets a renewal reminder
Front Stage Interactions	Message from marketer, link to bot	Bot: scenario registration_flow	Bot: scenario welcome_tour	Operator replies manually	Bot: feedback_form	Email or bot: renewal_offer
Back Stage Interactions	CRM creates lead via UTM link	Metabot creates record leadId ↔ userId	Metabot updates attributes	Support CRM creates ticket	BI records NPS response	CRM updates subscription status
Support Processes / Systems	Telegram Ads, Analytics	CRM, API /users/connect-bot	Metabot Runtime, JS scripts	Helpdesk, Knowledge Base	BI, PostgreSQL, DataLens	CRM + Mailer

📘 Where to find templates:
Examples and ready-made templates for creating CJM and Service Blueprints are available in public libraries on Miro, Figma, or FigJam.

---

ComOps Loop: How CJM and Service Blueprint Connect

Customer Journey shows the external customer experience — path, emotions, and touchpoints.
Service Blueprint describes the internal processes and systems that deliver that experience.
Between them lies the ComOps Loop — the loop connecting these two worlds through:

• Communication Map — a map of dialogues and scenarios (how the system talks to the user);
• Integration Points Map — a map of integration points (how systems talk to each other).

---

🔁 Visual Scheme of the ComOps Loop

┌─────────────────────────────────────┐
│       CJM: Customer Path            │
│   (experience, emotion, touchpoint) │
└─────────────────────────────────────┘
               ▲
               │
               ▼
┌─────────────────────────────────────────────┐
│        COMOPS: CONNECTING NODE              │
│  Communication Map ↔ Integration Points     │
│   (dialogues ↔ APIs, scenarios ↔ processes) │
└─────────────────────────────────────────────┘
               ▲
               │
               ▼
┌─────────────────────────────────────┐
│ Service Blueprint: Processes        │
│ (systems, APIs, internal actions)   │
└─────────────────────────────────────┘
      🔄 Feedback Cycle

💡 ComOps is the connecting contour between experience and operation.
It turns customer steps from the CJM into system actions from the Service Blueprint,
and system responses back into dialogues — creating a continuous communication loop.

Designing Communications

The Communication Map — the Heart of Integration

Every process starts not with an API and not with a bot —
but with a communication map.

A communication map is a document that links business events
with communications, roles, and actions.

It answers a simple question:

Who, when, and why needs to say something to the user?

The map is built according to the communication loop principle:

Event → Communication → Participants → Actions → Result → New Event

---

Structure of a Communication Map

Here’s the basic table structure:

№	System Event	Communication / Scenario	Participants	Channel	User Action	Response / Result	API / Trigger
1	New order	“Thank you for your order”	Client	Telegram	—	Payment confirmation	/bots/{id}/call/order/thank-you
2	Order status changed	“Your order has been shipped”	Client	Telegram, Email	—	Clarifies delivery address	/bots/{id}/call/order/status
3	New ticket	“Your request has been created”	Client, operator	Web, Bot	May reply	/bots/{id}/call/ticket/new
4	Operator reply	“Is your issue resolved?”	Client	Telegram	Can rate	/bots/{id}/call/ticket/feedback

This table is a live map that allows the designer to see
what happens between the system and the user.

---

Example: Communication Map for User Registration

№	Event	Communication	Channel	User Action	Scenario	API
1	User registered	Greeting + data collection	Telegram	Enter name, city	registration_flow	/bots/123/call/user/register
2	Email not confirmed	Reminder to confirm email	Telegram	Click “Confirm” button	email_confirm	/bots/123/call/user/email
3	Profile completed	Thank you + intro instruction	Telegram	—	welcome_final	/bots/123/call/user/complete

Thus, communication becomes part of the user journey (CJM),
and the map becomes a tool for alignment between business, development, and integration teams.

---

Example from the Fmlst Case (Family Network)

Event	Communication	Participants	Channel	Result
New post created	“A new family event has been posted!”	All family members	Telegram	Received notification + link
New comment added	“Someone commented on your post”	Post author	Telegram	Opens dialogue
Profile updated	“New data in family profile”	Profile owners	Telegram	Confirms updates

📘
Here, each communication is part of a “live event feed.”
The platform doesn’t just notify — it connects people and actions, forming the family’s digital fabric.

---

Communication Map as a Design Tool

• One process = one map.
• The map describes not only message texts but also logic.
• Maps are stored in the project as artifacts — exported to JSON and connected to the bot.
• Each map has a unique ID and is linked to API endpoints.

👉 Thus, the map becomes the bridge between business and code.

---

Integration Points and API

What Is an Integration Point

An Integration Endpoint is the place where the system and the bot meet.

The business system (CRM, website, ERP) calls Metabot,
and Metabot triggers the communication scenario.

Example:

POST https://app.metabot24.com/bots/123/call/order/thank-you
Authorization: Bearer {token}
Content-Type: application/json

{
"order_id": 9821,
"user_id": "54321",
"amount": 3500,
"status": "paid"
}

Response:

{
  "success": true,
  "message": "Communication sent",
  "trace_id": "e9fa-234c-118a"
}

---

How to Design Integration Points

Each point must be documented:

Field	Description
Alias	Unique scenario code
URL	/bots/{botId}/call/{alias}
Method	POST
Auth	Bearer {token}
Request	JSON with data
Response	JSON with result
Owner	Responsible owner or team

Example description:

Alias: order_thankyou
Purpose: send thank-you message for order
Owner: ecommerce-team

---

Integration Classification

Type	From	To	Example
Inbound	System → Metabot	CRM calls bot	“New order — send notification to client”
Outbound	Metabot → System	Bot calls API	“User confirmed payment — update order”
Bidirectional	Both directions	Full event cycle	“Order created → bot notified → client replied → system updated status”

---

Example Integration Diagram

 ┌────────────────────┐
 │   Core System      │
 │ (CRM / ERP / Site) │
 └────────┬───────────┘
          │ REST API (POST /call/{alias})
          ▼
 ┌────────────────────┐
 │     Metabot API    │
 │  Scenario Engine   │
 └────────┬───────────┘
          │
          ▼
 ┌────────────────────┐
 │  Messenger / User  │
 └────────────────────┘

Each arrow represents a real webhook or API call, forming a communication cycle.

---

Authorization and Security

• All calls are protected by a Bearer Token tied to a specific project.
• Each partner/integration can have its own restricted token.
• Metabot logs every trace_id — a complete request path.
• All data is transmitted via HTTPS; event history is available in the admin panel.

---

Debugging and Documentation

Metabot provides a built-in Swagger interface: https://app.metabot24.com/docs/{botId} where requests can be tested and responses viewed in real time.

For integrators, there is a “Dry Run Mode” — sending test events without triggering actual communications.

---

API Calls Inside a Scenario

Sometimes the communication itself needs to call the system back. For example, after a user’s reply:

callApi({
  url: "https://crm.example.com/api/order/update",
  method: "POST",
  body: {
    user_id: ctx.user.id,
    order_id: ctx.data.order.id,
    action: "confirm_payment"
  }
})

Thus, the dialogue becomes part of the business process, and the scenario acts as a bidirectional connector between worlds.

---

End-to-End Identification and Data Synchronization

Why End-to-End Identification Matters

For a dialogue to become part of a business process,
the system must know who it’s talking to.

As long as we simply message someone in Telegram — it’s communication.
When we understand which CRM client this conversation belongs to — it’s integration.
And when an event in the CRM can trigger a personalized communication in the messenger —
that’s end-to-end identification.

---

Basic Identification Model

Each system has its own identifiers:

System	Identifier	Example
CRM / ERP	userId	125
Metabot	leadId or personId	TG-9072612
Messenger (Telegram / VK)	chatId	540278913

To connect these worlds, we create a mapping table of IDs — stored in Metabot’s database.

Example record:

{
  "userId": 125,
  "leadId": "TG-9072612",
  "chatId": 540278913,
  "isActive": true,
  "source": "telegram",
  "connected_at": "2025-10-15T11:24:52Z"
}

---

How the Link Is Established

Step 1. User Initiates Authorization

Via chatbot:

Hello! To continue, please authorize.
Enter your phone number or email.

Step 2. The Bot Searches for the User in the Core System

GET /user
{
  "phone": "79187777777"
}

If the user is found — returns userId. If not — creates a new user (POST /user).

Step 3. The Bot Notifies the System That the User Connected the Bot

POST /users/connect-bot
{
  "userId": 125
}

Now the system knows this user has an active bot in Telegram.

Step 4. The Mapping Table Is Updated

Metabot creates the record userId ↔ leadId ↔ chatId.

---

Authorization: Alternative Scenarios

• Telegram Login: confirmation via tg://resolve?domain=... The Telegram phone is compared with the CRM phone.
• SMS Code: if two-factor confirmation is needed.
• OAuth / SSO: when integrated with corporate portals.

---

Bidirectional Connection

Once the link is established:

• The system can trigger a communication using userId. Metabot will find leadId and deliver the message to the user.
• The chatbot can update user data in the CRM via /api/user/update endpoint.

Example:

{
  "userId": 125,
  "email": "new@domain.com",
  "city": "Moscow"
}

---

Data Synchronization: Two Approaches

Pull Model (On Demand)

The chatbot receives only the ID of a resource (e.g., an order) and loads data itself via API.

{
  "script_request_params": {
    "orderId": 9821,
    "userId": 125
  }
}

The bot then calls the API:

GET /orders/9821

and retrieves everything needed for communication.

• 📌 Pros: flexible, fewer schema changes required.
• 📉 Cons: requires accessible APIs and fast responses.

---

Push Model (Full Data Packet)

The system sends all event information directly in the request to the bot.

{
  "script_request_params": {
    "userId": 125,
    "order": {
      "id": 9821,
      "status": "shipped",
      "amount": 3500
    }
  }
}

• 📌 Pros: no extra API calls needed.
• 📉 Cons: heavier payload, less flexible when schema changes.

---

Hybrid Model

In practice, a hybrid is often used:

• The system sends key IDs (userId, orderId).
• The bot performs pull requests for context if needed.

"script_request_params": {
  "userId": 125,
  "orderId": 9821
}

Then the bot calls:

GET /orders/9821/details
GET /users/125/profile

---

Event Exchange Architecture

 ┌────────────────────┐
 │     Core System    │
 └────────┬───────────┘
          │ Webhook / API
          ▼
 ┌────────────────────┐
 │      Metabot       │
 │  (Integration Bus) │
 └────────┬───────────┘
          │ Script Engine
          ▼
 ┌────────────────────┐
 │  Messenger / User  │
 └────────────────────┘
          ▲
          │ User Reply
          │ API / Callback
          ▼
 ┌────────────────────┐
 │     Core System    │
 └────────────────────┘

This cycle can repeat many times within a single process — creating a living operational loop of communications.

---

Error Handling and Logging

Metabot returns standard codes and messages:

Code	Meaning	Example
200	OK	{ "success": true }
401	Authorization error	{ "message": "Invalid token" }
404	Endpoint not found	{ "message": "Endpoint not found" }
500	Internal error	{ "message": "Script error at line 23" }

All events are logged with a trace_id, allowing you to trace the full chain:

CRM event → Metabot endpoint → scenario → messenger → user → callback → CRM update

---

Example: Full Cycle “New User Registration”

Event: User submits a form on the website System: CRM creates userId = 125 Integration: → CRM calls /bots/{botId}/call/users/connect-bot → Metabot greets the user in Telegram → The user confirms phone number → Metabot calls /api/user/confirm in CRM → CRM activates the profile → Metabot sends the final message:

“Welcome, {name}! Your personal account has been activated.”

📊 That’s it — one loop, one contour, one source of truth.

---

The Key Principle of DMI

Communication = Operation + Context + Identification.

Without ID mapping — the bot remains a “toy.” Without system linkage — communication is meaningless. Only the combination of all three levels creates a living digital ecosystem.

---

Interaction Architecture

General Scheme of the Digital Dialogue

┌──────────────────────────┐
│        User              │
│  (Telegram / WhatsApp)   │
└───────────┬──────────────┘
            │
            ▼
┌──────────────────────────┐
│  Communicative Layer     │
│  (Metabot: scenarios, UI)│
└───────────┬──────────────┘
            │
            ▼
┌──────────────────────────┐
│  Operational Layer       │
│  (Low-code runtime, JS)  │
└───────────┬──────────────┘
            │
            ▼
┌──────────────────────────┐
│  Integration Layer       │
│  (REST API, Webhooks)    │
└───────────┬──────────────┘
            │
            ▼
┌──────────────────────────────┐
│  Core System                 │
│  (CRM / ERP / CMS / Helpdesk)│
└──────────────────────────────┘

📘 The logic is simple:

1. An event occurs in the core system (e.g., an order is placed).
2. The system triggers the corresponding communication in Metabot via API.
3. The bot contacts the user in the messenger, sends a message or starts a dialogue.
4. The user’s response is sent back to the system via callback API.
5. The system updates its data and, if necessary, initiates a new cycle.

---

Principle of Bidirectional Exchange

Deep Messaging Integration is based on two data flows:

Flow	Direction	Scenario Example
Outbound (system → bot)	An event triggers a communication	“New order,” “Status changed”
Inbound (bot → system)	A user action triggers a system event	“User confirmed payment,” “User left feedback”

🎯 The goal is for these two flows to close into a single operational loop,
where every message becomes part of the business process.

---

The Feedback Loop

CRM → Metabot → Messenger → User → Metabot → CRM

This cycle is the neural impulse of the organization.
It connects people, processes, and data in real time.

Such loops form the foundation of the Communication Operating System (ComOps),
where communication becomes infrastructure.

---

State and Context Management

Inside Metabot, every interaction is stored in memory:

• lead_id — user identifier,
• session_id — unique dialogue session,
• context — variable set (profile, previous steps, answers),
• attributes — parameters saved across scenarios.

This enables:

• The bot to “remember” where the user left off.
• Personalized communications.
• CJM analytics and segmentation by attributes.

---

Example Architecture for a Large Company

Scenario: REHAU Communications with Installers

[Installer / Telegram]
      ⇅
[Metabot Bot / Scenario "Registration + Personal Cabinet"]
      ⇅
[REHAU Portal]
      ⇅
[CRM + Webinar + BI]

📍 Here Metabot acts as a switching middleware:

• Events from the portal (registration, webinar, order) trigger webhooks in Metabot.
• Metabot manages scenarios, context, and memory.
• User responses are logged and synchronized back to the CRM and BI systems.

---

REHAU Communication Map

№	Event	Communication	Participant	Channel	API / Endpoint
1	Installer registered on portal	“Welcome!”	Installer	Telegram	/users/connect-bot
2	New webinar scheduled	“You are invited to training”	Installer	Telegram	/events/webinar-invite
3	Webinar completed	“Rate the training quality”	Installer	Telegram	/events/webinar-feedback
4	Feedback sent	“Thank you for your feedback”	Installer	Telegram	/feedback/received

📊
Each step — a system event,
each communication — a Metabot scenario,
each action — a new entry in BI analytics.

---

Example Integration Map for eCommerce

Event	Integration Point	Description	Communication
New order	/order/thank-you	Send thank-you and order details	“Thank you for your purchase!”
Order status updated	/order/status	Notify about shipment	“Your order has been shipped!”
Delivery completed	/order/delivered	Request feedback	“Please rate your delivery”
New review	/order/review	Send bonus	“Thank you for your feedback!”

---

Example: Family Service Fmlst

Architecture:

Fmlst CMS → Metabot → Telegram → Family Users

Communication Map:

Event	Communication	Participants	API
New post created	“A new family event occurred!”	All family members	/post/new
New comment added	“Someone commented on your post”	Post author	/comment/new
New family member	“Welcome to the family!”	All users	/users/new

The bot transforms the family site into a living dialogue —
updates, discussions, and emotions now happen directly in the messenger.

---

Example: Helpdesk Integration

Architecture:

Helpdesk ⇄ Metabot ⇄ Telegram / Webchat

Event	Communication	Channel	API
New ticket	“Your request has been created”	Telegram	/ticket/new
Operator response	“Is your issue resolved?”	Telegram	/ticket/reply
Service rating	“Please rate our service”	Telegram	/ticket/feedback

🎯 Result:

• The client receives instant responses.
• Support sees replies and ratings in CRM.
• The system automatically closes tickets upon confirmation.

---

Analytics and Management

Every communication generates an event log that can be collected and visualized in BI:

Metric	Source	Example
Engagement Rate	Metabot Logs	82% of users replied to a message
Average Response Time	BI	1.7 min
Integration Errors	Log Trace	0.3%
Conversion → Goal	CJM Map	+27% through learning flow

---

Case Study: REHAU × Metabot

How Business Processes Came Alive in Messengers

---

Context

REHAU is a large manufacturer of construction systems and solutions.
Its audience — installers, dealers, and designers — is distributed across regions and segments.

The main problem:

• communications were fragmented,
• webinars, portals, and CRM were disconnected,
• users got lost between systems.

---

Solution

Metabot implemented a communication layer
that unified all touchpoints into a single dialogue.

Now an installer receives everything in one place — in a Telegram bot:

• portal registration,
• webinar invitations,
• reminders and quizzes,
• feedback and ratings,
• order and bonus notifications.

---

Technological Architecture: REHAU Integration Bus

[REHAU Portal] → [Metabot API / Webhooks]
      ⇅
[Metabot Scenario Engine / JS Scripts]
      ⇅
[Telegram Bot Interface]
      ⇅
[User / Installer]

Key principles:

• Each portal event triggers a webhook in Metabot.
• Metabot manages the scenario, context, and memory.
• All user replies are logged and synchronized back.

---

Results

📈 Implementing Deep Messaging Integration delivered:

• 5× increase in installer engagement,
• 90% reduction in manual broadcasts,
• real-time activity analytics,
• reduced call center load,
• creation of personal digital profiles.

---

From a Conference Interview

“We managed to connect everything — portal, Telegram, and CRM —
now communications are not hanging separately,
they’ve become part of our infrastructure.”
— REHAU Team, Metabot Connect Project.

---

💡 Conclusion

From Integration to a Communication Operating System

Deep integration is not just APIs or bots.
It is a new level of business maturity,
where conversations, processes, and data operate as one.

“Dialogue is the new interface,
communication is the new infrastructure,
and Metabot is the operating system
that unites them into the living intelligence of the enterprise.”

Management, Analytics, and Development

Managing Integrations

After launching Deep Messaging Integration, the project must live and evolve.
This is not a one-time setup — it’s a new communication infrastructure for the company.

Key roles:

Role	Responsibility
ComOps Architect	Designs communication loops, maps, APIs
Integrator / Developer	Implements endpoints and scenarios
Communications Manager	Manages content and broadcasts
Analyst / BI Specialist	Analyzes metrics and funnels
Operator / Bot Manager	Monitors logs, replies manually when necessary

🧭
The DMI methodology proposes a continuous management cycle:

Design → Integrate → Measure → Improve

---

Monitoring and Logging

Every event, communication, and error must be logged.
Metabot provides a unified system log:

Field	Description
trace_id	Unique identifier of the request chain
source_system	CRM, ERP, Portal, etc.
endpoint	Integration point alias
userId / leadId	Communication participant
status	success / fail
latency_ms	Response time
timestamp	Event date and time

📊
All logs can be exported to BI for visualization and analytics.

---

Communication Metrics

Communications are measured by the same principles as processes:

Metric	Meaning	Example
Delivery Rate	Percentage of messages delivered	98%
Engagement Rate	Percentage of users who responded	76%
Response Time	Average user response time	1.8 minutes
Conversion Rate	Transition from communication to action	22%
Satisfaction Index (CSAT)	User satisfaction score	4.7 / 5
Error Rate	Percentage of failed API calls	0.4%

Each communication map becomes an analytical map —
you can see where users drop off and which scenarios need improvement.

---

Communication BI Dashboards

In BI tools, you can create visualization reports:

Example dashboards:

• Engagement dynamics by week
• Average response time
• Events per user
• Funnel: Event → Communication → Response → Action
• Scenario heatmap

📈
Thus, communications become measurable and manageable processes.

---

Quality and Version Control

Each communication map and integration must have version control:

Version	Change	Responsible	Date
1.0	Basic registration	Arch. Alena	01.02
1.1	Added email collection	Arch. Alena	15.02
1.2	Improved UX	Marketing	01.03

Metabot supports exporting and storing communication maps in JSON,
along with a change history — enabling rollbacks or comparisons.

---

Security and Access

DMI manages not only communications but also data access:

• All calls go through HTTPS.
• Tokens are scoped by roles.
• Events are fully logged.
• Personal data (PII) is encrypted and not transmitted unprotected.

For critical processes, isolated endpoints with separate keys are created,
e.g., for payments, medical records, or HR information.

---

DMI Implementation Stages

Stage	Action	Result
1. Process Analysis	Identify key scenarios (registration, order, support)	3–5 processes defined
2. Communication Mapping	Document all events and roles	Set of communication maps ready
3. Integration Point Definition	Design endpoints, request/response schema	API documentation approved
4. Implementation & Testing	Build scenarios, integrations, authorization	Working MVP
5. Monitoring & Analytics	Connect BI, collect metrics	Performance under control
6. Scaling	Add new processes	Mature communication infrastructure

---

Roles and Organizational Model

DMI is implemented as a cross-functional capability between IT and business.

            ┌──────────────┐
            │  Leadership  │
            └──────┬───────┘
                   │
      ┌────────────┴────────────┐
      │  Communication Office   │
      └────────────┬────────────┘
                   │
┌──────────────┬───┴─────────┬─────────────┐
│ Architect    │ Developer   │ BI Analyst  │
└──────────────┴─────────────┴─────────────┘

Thus emerges the ComOps Unit — a department
responsible for communications as infrastructure.

---

Practical Templates and Tools

Communication Map Template

№	Event	Communication	Channel	Participants	Actions	API
1	New order	“Thank you for your order”	Telegram	Client	—	/order/thank-you
2	Order status updated	“Your order has been shipped”	Telegram	Client	Confirm delivery	/order/status
3	Order delivered	“Please leave feedback”	Telegram	Client	Reply with rating	/order/feedback

📘 Use this as a working table when designing DMI.

---

Integration Point Table Template

Endpoint Alias	Method	URL	Description	Request Params	Response
users/connect-bot	POST	/bots/{botId}/call/users/connect-bot	Link user to bot	{ userId }	{ success: true }
order/thank-you	POST	/bots/{botId}/call/order/thank-you	Order thank-you message	{ orderId, userId }	{ success: true }
comment/new	POST	/bots/{botId}/call/comment/new	New comment notification	{ postId, authorId, userIds }	{ success: true }

---

DMI Project Technical Specification (TЗ) Template

1. Goal: integrate messengers into business process X
2. Systems: CRM, website, ERP, Metabot
3. Channels: Telegram, WhatsApp
4. Communication Scenarios:
   • Registration
   • Confirmation
   • Notifications
   • Feedback
5. APIs and Events: describe all endpoints
6. User Identification: userId ↔ leadId
7. Metrics: engagement, conversion, satisfaction
8. Security: authorization, encryption, logging
9. Artifacts: communication maps, endpoint tables, JSON scenarios
10. Timeline and roles

---

Scaling Recommendations

• Start with one scenario, but design for scalability.
• Implement a unified ID mapping table across all systems.
• Structure communication logic as map + endpoints + scenario.
• Integrate via REST API or Webhook Proxy without modifying the CRM core.
• Add analytics from day one.

---

Conclusion: From Deep Messaging Integration to a Communication Operating System

In this paper, we explored the first layer of Metabot’s architecture — Deep Messaging Integration (DMI).
We demonstrated how the communication and operational layers connect with business systems,
creating a living fabric of dialogues and events.
We intentionally did not cover the cognitive layer (Cognitive Layer) — memory, understanding, and intelligence —
as it will be described in the next part of the series.

If you are just beginning, we recommend starting with the communication layer:

• Set up simple interaction scenarios,
• Build customer journeys,
• Improve onboarding and conversion,
• Engage your audience via links and chats — even without deep integration.

This will deliver quick business results and demonstrate the real value of communication.

When you’re ready for a greater impact — move to full integration,
creating end-to-end services where everything works seamlessly: from CRM to messenger.
Now you know how to make it happen.

We wish you success in building your own communication infrastructure!

---

💬

“When communications become infrastructure,
the enterprise begins to think and act like a living organism.”

---

This paper is part of the Next Paradigm Foundation’s research series on Metabot — Communication Operating Systems for the AI era.