# Deep Messaging Integration (DMI): методология ## Методология глубокой интеграции мессенджеров в бизнес-процессы ## Аннотация Методология описывает системный подход к внедрению **диалоговых интерфейсов и мессенджеров** в бизнес-процессы предприятия. Она раскрывает архитектуру **коммуникационного и операционного слоя Metabot**, объясняет, как проектировать **карты коммуникаций**, **точки интеграции**, **синхронизацию данных** и **сквозную идентификацию пользователей** между системами. Документ предназначен для архитекторов, аналитиков и интеграторов, создающих инфраструктуру цифровых коммуникаций, и не включает когнитивный слой и AI-компоненты. ## Мир, который заговорил ### От интерфейсов к диалогу Последние десять лет цифровой мир пережил смену парадигмы. Раньше человек взаимодействовал с системой через **формы**, **кнопки**, **интерфейсы**. Теперь он взаимодействует **словами**. Пользователь больше не заходит на сайты, он пишет. Не ищет телефон поддержки — задаёт вопрос. Не устанавливает приложение — просто открывает мессенджер. Коммуникация перестала быть «каналом». Она стала **операционной средой** — местом, где совершаются сделки, принимаются решения, рождаются данные. --- ### Бизнес как диалог Для компаний это значит одно: **диалог — новая форма организации процессов.** Там, где раньше был отдел поддержки, теперь — чат-центр. Где была CRM — интерактивный интерфейс общения. Где был лендинг — теперь сценарий диалога, персонализированный под конкретного пользователя. Бизнес учится **разговаривать** в цифровом пространстве, и этот разговор должен быть связан с его системами, данными и людьми. Иначе он не станет частью цепочки создания ценности. --- ### Мессенджеры против приложений Мессенджеры победили не потому, что удобнее. А потому что они — **естественнее**. Им не нужен онбординг, не требуется обновление, они работают на привычном языке пользователя. Для бизнеса это открыло возможность создавать сервисы, которые живут прямо внутри Telegram, WhatsApp, VK или веб-чата. **Чат-бот = мобильное приложение без приложения.** Он может продавать, консультировать, принимать заказы, уведомлять, обучать. И самое важное — он подключается к ядру систем предприятия. --- ### От канала к инфраструктуре Но просто «запустить бота» — недостаточно. Настоящая ценность появляется, когда диалог **встраивается в архитектуру бизнеса**. Когда CRM, ERP, Helpdesk и маркетинг-платформа связаны с мессенджерами в единый контур, в котором данные и события двигаются двусторонне. Так рождается новая инженерная логика — **ComOps**, *Communication Operations* — операционная система коммуникаций. И на её первом уровне лежит **методология Deep Messaging Integration (DMI)**. --- ## Архитектура глубокой интеграции ### Определение DMI **Deep Messaging Integration (DMI)** — это способ соединить мессенджеры и внутренние системы так, чтобы диалог стал частью бизнес-процесса. Это не маркетинговая интеграция и не рассылки. Это инженерная архитектура, где каждое событие системы способно вызвать коммуникацию, а каждый ответ пользователя — вызвать действие в системе. --- ### Три слоя интеграции DMI строится на трёх взаимосвязанных уровнях:
СлойНазначениеЧто происходит
**Communicative Layer**Взаимодействие с пользователемДиалоги, уведомления, сценарии, формы
**Operational Layer**Исполнение операций и логикиЗапуск сценариев, плагины, таблицы, автоматизация
**Integration (API) Layer**Соединение с ИТ-системамиREST эндпоинты, идентификация, обмен данными
Эти три слоя соединяются в единый поток — **Dialog Bus**. Он работает так же, как нервная система: получает сигнал, обрабатывает его, отправляет реакцию. --- ### Как работает цикл интеграции ``` [Пользователь] ↓ (Сообщение) [Communicative Layer / Metabot] ↓ (Намерение, контекст) [Operational Layer] ↓ (API-вызов) [Основная система / CRM, ERP] ↑ (Данные, события) [Metabot / Диалог] ↑ (Ответ, уведомление) → Новый контекст и память ``` Каждый цикл завершён: диалог порождает действие, действие порождает данные, данные порождают новое взаимодействие. Так создаётся **живая связь между коммуникацией и операцией**. --- ### Коммуникационный слой в Metabot На платформе Metabot коммуникации реализуются через **low-code сценарии**. Каждый сценарий — это исполняемая программа диалога с условиями, переменными и переходами. Типы сценариев: - приветственные, онбординг; - сервисные уведомления; - интерактивные опросы и формы; - транзакционные диалоги (заказы, оплаты); - персонализированные бот-ассистенты. Сценарий может запускаться автоматически по событию из системы или вручную оператором. --- ### Операционный и интеграционный слои - **Operational Layer** исполняет команды в реальном времени: JS-плагины, таблицы, Service Blueprints, event bus. - **Integration Layer** предоставляет REST эндпоинты, через которые бизнес-системы вызывают коммуникации. Например: ``` POST /bots/{botId}/call/users/update POST /bots/{botId}/call/order/thank-you ``` Каждый эндпоинт имеет alias, тело запроса (`script_request_params`), и результат (`success: true`). --- ### Коммутационная логика DMI 1. Событие в системе → вызов эндпоинта Metabot. 2. Metabot запускает нужную коммуникацию в боте. 3. Бот обрабатывает ответ пользователя и через API возвращает данные в систему. 4. Контекст и атрибуты сохраняются в памяти. Результат — **замкнутый цикл «событие ↔ коммуникация ↔ действие ↔ контекст»**, который становится частью операционного цикла компании. --- ### Почему это важно Глубокая интеграция меняет роль коммуникаций: из канала — в инфраструктуру, из маркетинга — в операции, из поддержки — в интеллект. --- ## Стратегическое планирование: Customer Journey и Service Blueprint Прежде чем проектировать конкретные сценарии или точки интеграции, важно увидеть **общую картину взаимодействия клиента с вашим бизнесом**. Для этого используются две взаимосвязанные методологии: 1. **Customer Journey Map (CJM)** — путь клиента, описывающий внешний опыт и точки контакта. 2. **Service Blueprint** — карта внутренних процессов и систем, обеспечивающих этот опыт. Именно между ними и находится зона ответственности **Deep Messaging Integration (DMI)**: он соединяет *внешний пользовательский опыт* (CJM) с *внутренней инфраструктурой компании* (Service Blueprint), превращая коммуникации в операционный слой. ### Customer Journey Map (CJM): путь клиента **Customer Journey Map (CJM)** — это визуализация пути, который проходит ваш клиент при взаимодействии с продуктом или компанией: от первого знакомства с брендом до повторных покупок и рекомендаций. Создание CJM помогает понять, **на каких этапах клиенту нужна коммуникация** и где можно повысить ценность за счёт автоматизации диалогов. --- #### Как использовать CJM в контексте Metabot 1. **Определите персону и цель.** Для кого вы проектируете путь: клиент, партнёр, монтажник, дилер и т.д. Сформулируйте цель: регистрация, покупка, обучение, поддержка. 2. **Разбейте путь на этапы.** Пример: `Осведомлённость → Регистрация → Первая покупка → Доставка → Обратная связь → Повторный заказ`. 3. **Определите точки контакта.** Где и через что клиент взаимодействует: сайт, Telegram, email, офлайн-встречи, бот-диалоги. Эти точки станут **будущими узлами коммуникаций** в Metabot. 4. **Опишите эмоции и потребности.** Что клиент чувствует на каждом этапе? Где он теряется, раздражается, радуется? Это помогает выбрать тональность сценариев и время коммуникации. 5. **Найдите возможности для улучшения.** Отметьте, где коммуникация может убрать трение, ускорить шаг, добавить ценность. Например: напоминание о вебинаре, автоматический статус доставки, подсказка при регистрации. --- #### Связь CJM и карт коммуникаций CJM показывает **путь клиента на стратегическом уровне**. Когда вы видите полный маршрут, можно сделать **zoom-in** на конкретные участки — и превратить их в **карты коммуникаций Metabot**, где описываются конкретные сообщения, участники и API-вызовы. > 💡 Таким образом, **карта коммуникаций — это локализованный фрагмент CJM**, > реализованный в виде сценариев и автоматизаций внутри Metabot. --- #### Шаблон таблицы Customer Journey (для самостоятельного заполнения)
Этап пути клиентаЦель клиента / зачем он это делаетДействия клиентаЭмоции 😊😐😞Потребности и болиТочки контактаКоммуникация (сценарий / сообщение)Интеграции / СистемыВозможности для улучшенияОтветственный
*Подсказка:* - Колонки можно расширять в Miro, Notion или Google Sheets. - Эмодзи помогают быстро видеть эмоциональные пики. - Последние две колонки (“Возможности” и “Ответственный”) — это backstage из Service Blueprint. --- #### Пример заполнения (кейc: “Регистрация и онбординг в Telegram-боте”)
Этап пути клиентаЦель клиента / зачем он это делаетДействия клиентаЭмоции 😊😐😞Потребности и болиТочки контактаКоммуникация (сценарий / сообщение)Интеграции / СистемыВозможности для улучшенияОтветственный
**Осведомлённость**Узнать о сервисеЧитает пост / получает ссылку от друга🙂Не хочет тратить время на установку приложенийСоцсети, лендингСообщение бота «Привет! Расскажу, как всё работает без регистрации»Tilda, UTM-меткиДобавить CTA с быстрым переходом в ботМаркетолог
**Регистрация**Создать профильПишет в бот, вводит номер😐Беспокоится о безопасности данныхTelegramСценарий `registration_flow` — запрос контактаCRM / API `/users/connect-bot`Сократить шагов регистрацииАрхитектор ComOps
**Первое использование**Проверить, как работаетПроходит интро-опрос😊Хочет быстро понять ценностьTelegram ботСценарий `welcome_tour` — мини-онбордингMetabot / CMSДобавить короткое видео-демоПродакт
**Обратная связь**Поделиться впечатлениемОценивает опыт 👍🙂Хочет, чтобы отзыв был учтёнTelegramСценарий `feedback_form` — опрос NPSBI / Webhook `/feedback/received`Добавить благодарственное сообщениеАналитик
**Повторное взаимодействие**Получить пользу повторноВозвращается по напоминанию😊Хочет регулярных советовTelegram, EmailСценарий `retention_tips` — серия полезных сообщенийCRM, MailerТестировать контент-пушиМаркетолог
Как использовать 1. Скопируй таблицу и заполни для своего продукта. 2. Этапы можно брать из CJM (Discovery → Registration → Onboarding → Usage → Feedback → Retention). 3. Колонки *Коммуникация* и *Интеграции* — это твоя **ComOps-зона**, где создаются карты коммуникаций и точки интеграции. 4. Когда заполните таблицу — можно визуализировать как **ComOps Loop**: клиентский шаг → сообщение → действие системы → обратная связь. > **📘 Где найти шаблоны**. Примеры и готовые шаблоны для создания CJM и Service Blueprint можно найти в открытых библиотеках Miro, Figma или FigJam. --- ### Service Blueprint: карта внутренних процессов Если CJM отражает внешний опыт клиента, то **Service Blueprint** показывает, что происходит внутри компании, чтобы этот опыт случился. Это визуальная модель всех компонентов и систем, участвующих в предоставлении услуги, и их взаимодействий. --- #### Зачем нужен Service Blueprint в контексте Metabot - Позволяет понять, какие **внутренние процессы и системы** обеспечивают каждый этап пути клиента. - Помогает определить, где необходимо создать **точки интеграции (API, Webhook, Data Sync)**. - Выявляет узкие места в инфраструктуре, которые мешают бесшовному диалоговому опыту. --- #### Классическая структура Service Blueprint
УровеньЧто описываетПример в контексте Metabot
**Customer Actions**Действия клиентаОтправил сообщение в бот, подтвердил заказ
**Front Stage Interactions**Видимые взаимодействияОператор ответил в чате, бот отправил сценарий
**Back Stage Interactions**Невидимые процессыCRM обновила статус, скрипт создал тикет
**Support Processes**Поддерживающие системы и данныеБаза данных, API, автоматизация в Metabot
--- #### Как создавать Service Blueprint для интеграции 1. **Определите цель и персону.** Для кого и зачем вы анализируете процесс (например, онбординг клиента или обработка заказа). 2. **Опишите этапы взаимодействия.** Разбейте процесс на шаги: заявка → обработка → доставка → отзыв. 3. **Отметьте все точки контакта.** Где клиент взаимодействует с компанией и через какие каналы (бот, сайт, email). 4. **Разделите на уровни.** Front stage — что видит клиент. Back stage — что делают сотрудники и боты. Support processes — какие системы обеспечивают работу. 5. **Добавьте интеграции.** Отметьте, где необходимы API или события для обмена данными между системами. --- #### Blueprint → DMI → Интеграции Когда Service Blueprint готов, вы видите, **в каких точках процесс можно связать с диалогами в мессенджерах**. Именно эти точки становятся **эндпоинтами Metabot и точками интеграции DMI**, описанными в следующем разделе. > 💡 Service Blueprint — это операционный слой, > а **Deep Messaging Integration** делает его живым, соединяя системные события и реальные диалоги в ComOps-архитектуре. --- #### Шаблон Service Blueprint (для самостоятельного заполнения)
Уровень / ЭтапAwarenessOrderingPurchasingReceivingUsing / OnboardingFeedback
**Customer Actions**
**Front Stage Interactions**
**Back Stage Interactions**
**Support Processes / Systems**
*Как заполнять:* - Верхний ряд (Customer Actions) — то, что делает клиент. - Далее вниз: кто и что происходит внутри компании. - Можно добавлять стрелки, зависимости или примечания, если делаете в Miro, FigJam или Notion. --- #### Пример заполнения (кейc: «Онбординг нового клиента в сервисе»)
Уровень / ЭтапAwarenessRegistrationFirst UseSupportFeedbackRenewal
**Customer Actions**Видит пост в Telegram и переходит в ботВводит номер, получает приветствиеПроходит мини-инструкциюЗадает вопрос в чатеОценивает опыт 👍Получает напоминание о продлении
**Front Stage Interactions**Сообщение от маркетолога, ссылка на ботБот: сценарий `registration_flow`Бот: сценарий `welcome_tour`Оператор отвечает вручнуюБот: `feedback_form`Email или бот: `renewal_offer`
**Back Stage Interactions**CRM создаёт лид по ссылке UTMСервис Metabot создаёт запись `leadId ↔ userId`Система Metabot обновляет атрибутыSupport CRM создаёт тикетBI фиксирует NPS-ответCRM обновляет статус подписки
**Support Processes / Systems**Telegram Ads, AnalyticsCRM, API `/users/connect-bot`Metabot Runtime, JS scriptsHelpdesk, Knowledge BaseBI, PostgreSQL, DataLensCRM + Mailer
> **📘 Где найти шаблоны**. Примеры и готовые шаблоны для создания CJM и Service Blueprint можно найти в открытых библиотеках Miro, Figma или FigJam. --- ### ComOps Loop: как соединяются CJM и Service Blueprint Customer Journey показывает **внешний опыт клиента** — путь, эмоции, точки контакта. Service Blueprint описывает **внутренние процессы и системы**, которые этот опыт обеспечивают. А между ними находится **ComOps Loop** — петля, которая связывает эти два мира через: - **Communication Map** — карта диалогов и сценариев (как система говорит с пользователем); - **Integration Points Map** — карта точек интеграции (как системы говорят между собой). --- #### 🔁 Визуальная схема ComOps Loop ``` ┌──────────────────────────────┐ │ CJM: Путь клиента │ │ (опыт, эмоции, контакт) │ └──────────────────────────────┘ ▲ │ ▼ ┌──────────────────────────────────────────┐ │ COMOPS: СВЯЗУЮЩИЙ УЗЕЛ │ │ Communication Map ↔ Integration Points │ │ (диалоги ↔ API, сценарии ↔ процессы) │ └──────────────────────────────────────────┘ ▲ │ ▼ ┌─────────────────────────────────────┐ │ Service Blueprint: Процессы │ │ (системы, API, внутренние действия) │ └─────────────────────────────────────┘ 🔄 Цикл обратной связи ``` > 💡 **ComOps — это связующий контур между опытом и операцией.** > Он превращает шаги клиента из CJM в действия систем из Service Blueprint, > а ответы систем — обратно в диалоги, создавая непрерывную коммуникационную петлю. --- ## Проектирование коммуникаций ### Карта коммуникаций — сердце интеграции Каждый процесс начинается не с API и не с бота — а с **карты коммуникаций**. Карта коммуникаций — это документ, который связывает **события бизнеса** с **коммуникациями, ролями и действиями**. Она отвечает на простой вопрос: > Кто, когда и зачем должен что-то сказать пользователю? Карта строится по принципу **петли коммуникации**: ``` Событие → Коммуникация → Участники → Действия → Результат → Новое событие ``` --- ### Структура карты коммуникаций Вот базовая структура таблицы:
№Событие в системеКоммуникация / сценарийУчастникиКаналДействие пользователяОтвет / результатAPI / триггер
1Новый заказ“Спасибо за заказ”КлиентTelegram—Подтверждение оплаты`/bots/{id}/call/order/thank-you`
2Статус заказа изменён“Ваш заказ отправлен”КлиентTelegram, Email—Уточняет адрес`/bots/{id}/call/order/status`
3Новый тикет“Заявка создана”Клиент, операторWeb, BotМожет ответить`/bots/{id}/call/ticket/new`
4Ответ оператора“Ваш вопрос решён?”КлиентTelegramМожет оценить`/bots/{id}/call/ticket/feedback`
Эта таблица — **живая карта**, по которой проектировщик видит, что происходит между системой и пользователем. --- ### Пример: коммуникационная карта регистрации пользователя
№СобытиеКоммуникацияКаналДействие пользователяСценарийAPI
1Пользователь зарегистрировалсяПриветствие + сбор данныхTelegramВвести имя, город`registration_flow``/bots/123/call/user/register`
2Email не подтверждёнНапоминание о подтвержденииTelegramНажать кнопку “Подтвердить”`email_confirm``/bots/123/call/user/email`
3Профиль заполненСпасибо + стартовая инструкцияTelegram—`welcome_final``/bots/123/call/user/complete`
Таким образом, коммуникация становится **частью пользовательского пути (CJM)**, а карта — инструментом согласования между бизнесом, разработкой и интегратором. --- ### Пример из кейса Fmlst (семейный сайт)
СобытиеКоммуникацияУчастникиКаналРезультат
Создана новая публикация“В семье появилось новое событие!”Все участники семьиTelegramПолучили уведомление и ссылку
Добавлен комментарий“Кто-то прокомментировал ваш пост”Автор публикацииTelegramПереход в диалог
Обновлена анкета“Новые данные в профиле семьи”Владельцы профиляTelegramПодтверждение изменений
📘 Здесь каждая коммуникация — это часть **“живой ленты событий”**. Платформа не просто уведомляет — она связывает людей и действия, формируя цифровую ткань семьи. --- ### Коммуникационная карта как инструмент проектирования - Один процесс = одна карта. - Карта описывает не только тексты сообщений, но и **логику**. - Карты хранятся в проекте как артефакты — экспортируются в JSON и подключаются к боту. - Каждая карта имеет уникальный ID и связана с API-эндпоинтами. 👉 Таким образом, карта становится **переходным звеном** между бизнесом и кодом. --- ## Точки интеграции и API ### Что такое точка интеграции **Integration Endpoint** — это место, где система и бот встречаются. Бизнес-система (CRM, сайт, ERP) вызывает Metabot, а Metabot — сценарий коммуникации. Пример: ``` 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" } ``` В ответ: ```json { "success": true, "message": "Communication sent", "trace_id": "e9fa-234c-118a" } ``` --- ### Как проектировать точки интеграции Каждая точка должна быть описана в документации:
ПолеОписание
**Alias**Уникальный код сценария
**URL**`/bots/{botId}/call/{alias}`
**Method**`POST`
**Auth**`Bearer {token}`
**Request**JSON с данными
**Response**JSON с результатом
**Owner**Владелец сценария
Пример описания: ``` Alias: order_thankyou Purpose: отправка благодарности за заказ Owner: ecommerce-team ``` --- ### Классификация интеграций
ТипОткудаКудаПример
**Входящая (Inbound)**Из системы → MetabotCRM вызывает бот“Новый заказ — отправь уведомление клиенту”
**Исходящая (Outbound)**Из Metabot → системуБот вызывает API“Пользователь подтвердил оплату — обнови заказ”
**Двусторонняя (Bidirectional)**Обе стороныПолный цикл событий“Создан заказ → бот уведомил → клиент ответил → система изменила статус”
--- ### Пример схемы интеграции ``` ┌────────────────────┐ │ Основная система │ │ (CRM / ERP / сайт) │ └────────┬───────────┘ │ REST API (POST /call/{alias}) ▼ ┌────────────────────┐ │ Metabot API │ │ Scenario Engine │ └────────┬───────────┘ │ ▼ ┌────────────────────┐ │ Messenger / User │ └────────────────────┘ ``` Каждая стрелка — это **реальный webhook или вызов**, который формирует коммуникационный цикл. --- ### Авторизация и безопасность - Все вызовы защищены **Bearer Token**, привязанным к конкретному проекту. - Для каждого партнёра/интеграции можно выдать отдельный токен с ограничениями. - В логах Metabot сохраняется `trace_id` — полный путь запроса. - Данные проходят через HTTPS, а история событий доступна в панели администратора. --- ### Отладка и документация Metabot предоставляет встроенный **Swagger-интерфейс**: `https://app.metabot24.com/docs/{botId}` где можно тестировать запросы и видеть ответы в реальном времени. Для интеграторов предусмотрен “Dry Run Mode” — отправка тестовых событий без запуска реальной коммуникации. --- ### Логика вызова API внутри сценария Иногда коммуникация сама вызывает систему обратно. Например, после ответа пользователя: ```javascript 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" } }) ``` Таким образом, диалог становится **частью бизнес-процесса**, а сценарий — двусторонним соединителем между мирами. --- ## Сквозная идентификация и синхронизация данных ### Зачем нужна сквозная идентификация Чтобы диалог стал частью бизнес-процесса, система должна **знать, кто с ней говорит**. Пока мы просто пишем пользователю в Telegram — это коммуникация. Когда мы понимаем, **к какому клиенту CRM она относится** — это уже интеграция. А когда событие в CRM способно **вызвать персональную коммуникацию** в мессенджере — это и есть **сквозная идентификация**. --- ### Базовая модель идентификации Каждая система имеет свои идентификаторы:
СистемаИдентификаторПример
CRM / ERP`userId`125
Metabot`leadId` или `personId``TG-9072612`
Messenger (Telegram / VK)`chatId`540278913
Чтобы соединить эти миры, мы создаём **таблицу соответствий ID** — она хранится в базе Metabot. Пример записи: ```json { "userId": 125, "leadId": "TG-9072612", "chatId": 540278913, "isActive": true, "source": "telegram", "connected_at": "2025-10-15T11:24:52Z" } ``` --- ### Как устанавливается связь #### Шаг 1. Пользователь инициирует авторизацию Через чат-бот: ``` Здравствуйте! Чтобы продолжить, авторизуйтесь. Введите ваш телефон или email. ``` #### Шаг 2. Бот ищет пользователя в основной системе ```json GET /user { "phone": "79187777777" } ``` Если пользователь найден — возвращается `userId`. Если нет — создаётся новый пользователь (`POST /user`). #### Шаг 3. Бот сообщает системе, что пользователь подключил бота ```json POST /users/connect-bot { "userId": 125 } ``` Теперь система знает, что этот пользователь имеет активный бот в Telegram. #### Шаг 4. Таблица связей пополняется Metabot создаёт запись `userId ↔ leadId ↔ chatId`. --- ### Авторизация: альтернативные сценарии - **Telegram Login:** подтверждение через `tg://resolve?domain=...` Сравнивается телефон Telegram с телефоном в CRM. - **SMS-код:** если нужно двухфакторное подтверждение. - **OAuth / SSO:** при интеграции с корпоративными порталами. --- ### Двусторонняя связь Теперь, когда связь установлена: - Система может вызвать коммуникацию по `userId`. Metabot сам найдёт `leadId` и доставит сообщение пользователю. - Чат-бот может изменить данные пользователя в CRM. Через эндпоинт `/api/user/update` он отправит запрос обратно. Пример: ```json { "userId": 125, "email": "new@domain.com", "city": "Москва" } ``` --- ### Синхронизация данных: два подхода #### Pull-модель (по запросу) Чат-бот получает только `ID` ресурса (например, заказа) и **сам подгружает данные** по API. ```json { "script_request_params": { "orderId": 9821, "userId": 125 } } ``` Бот вызывает API: ``` GET /orders/9821 ``` и получает всё, что нужно для коммуникации. - 📌 *Плюсы:* гибкость, меньше изменений при расширении данных. - 📉 *Минусы:* требует доступных API и быстрых ответов. --- #### Push-модель (полный пакет данных) Система передаёт **всю информацию** о событии прямо в запросе к боту. ```json { "script_request_params": { "userId": 125, "order": { "id": 9821, "status": "shipped", "amount": 3500 } } } ``` - 📌 *Плюсы:* не требуется дополнительный API-запрос. - 📉 *Минусы:* больше нагрузка и объём данных, менее гибко при изменениях схемы. --- ### Комбинированная модель На практике часто используется гибрид: - Система передаёт основные ID (userId, orderId). - Бот при необходимости делает `pull`-запросы за контекстом. ```json "script_request_params": { "userId": 125, "orderId": 9821 } ``` Затем бот: ``` GET /orders/9821/details GET /users/125/profile ``` --- ### Архитектура обмена событиями ``` ┌────────────────────┐ │ Основная │ │ система │ └────────┬───────────┘ │ Webhook / API ▼ ┌────────────────────┐ │ Metabot │ │ (Integration Bus) │ └────────┬───────────┘ │ Script Engine ▼ ┌────────────────────┐ │ Мессенджер / │ │ Пользователь │ └────────────────────┘ ▲ │ Ответ пользователя │ API / Callback ▼ ┌────────────────────┐ │ Основная │ │ система │ └────────────────────┘ ``` Этот цикл может повторяться многократно в одном процессе — создавая **живой операционный контур коммуникаций**. --- ### Обработка ошибок и логирование Metabot возвращает стандартные коды и сообщения:
КодСмыслПример
`200`OK`{ "success": true }`
`401`Ошибка авторизации`{ "message": "Invalid token" }`
`404`Эндпоинт не найден`{ "message": "Endpoint not found" }`
`500`Внутренняя ошибка`{ "message": "Script error at line 23" }`
Все события логируются с `trace_id`, что позволяет восстанавливать цепочку: ``` CRM event → Metabot endpoint → scenario → messenger → user → callback → CRM update ``` --- ### Пример полного цикла “Регистрация нового пользователя” **Событие:** Пользователь заполнил форму на сайте **Система:** CRM создаёт `userId = 125` **Интеграция:** → CRM вызывает `/bots/{botId}/call/users/connect-bot`. → Metabot приветствует пользователя в Telegram → Пользователь подтверждает номер → Metabot вызывает `/api/user/confirm` в CRM → CRM активирует профиль → Metabot отправляет финальное сообщение: > “Добро пожаловать, {имя}! Ваш личный кабинет активирован.” 📊 Всё: одна петля, один контур, одна точка истины. --- ### Ключевой принцип DMI > **Коммуникация = операция + контекст + идентификация.** Без связи между ID — бот остаётся «игрушкой». Без связи с системой — коммуникация бессмысленна. Только в комбинации трёх уровней возникает **живая цифровая экосистема**. --- ## Архитектура взаимодействия ### Общая схема цифрового диалога ``` ┌──────────────────────────┐ │ Пользователь │ │ (Telegram / WhatsApp) │ └───────────┬──────────────┘ │ ▼ ┌──────────────────────────┐ │ Коммуникативный слой │ │ (Metabot: сценарии, UI) │ └───────────┬──────────────┘ │ ▼ ┌──────────────────────────┐ │ Операционный слой │ │ (Low-code runtime, JS) │ └───────────┬──────────────┘ │ ▼ ┌──────────────────────────┐ │ Интеграционный слой │ │ (REST API, Webhooks) │ └───────────┬──────────────┘ │ ▼ ┌──────────────────────────────┐ │ Основная система │ │ (CRM / ERP / CMS / Helpdesk) │ └──────────────────────────────┘ ``` 📘 **Логика простая:** 1. Событие возникает в основной системе (например, заказ оформлен). 2. Через API вызывается соответствующая коммуникация Metabot. 3. Бот связывается с пользователем в мессенджере, отправляет сообщение или запускает диалог. 4. Ответ пользователя возвращается в систему через обратный вызов API. 5. Система обновляет данные и при необходимости инициирует новый цикл. --- ### Принцип двустороннего обмена Deep Messaging Integration строится на **двух потоках** данных:
ПотокНаправлениеСценарий
**Outbound (система → бот)**событие вызывает коммуникацию“Новый заказ”, “Изменился статус”
**Inbound (бот → система)**действие пользователя вызывает событие“Пользователь подтвердил оплату”, “Оставил отзыв”
🎯 Цель — чтобы эти два потока **замкнулись в единый операционный контур**, где каждое сообщение становится частью бизнес-процесса. --- ### Контур обратной связи ``` CRM → Metabot → Messenger → Пользователь → Metabot → CRM ``` Этот цикл — **нервный импульс организации**. Он связывает людей, процессы и данные в реальном времени. Именно из таких петель строится **Communication Operating System (ComOps)**, в которой коммуникация становится инфраструктурой. --- ### Управление состоянием и контекстом Внутри Metabot каждое взаимодействие сохраняется в памяти: - `lead_id` — идентификатор пользователя, - `session_id` — уникальная сессия диалога, - `context` — набор переменных (профиль, предыдущие шаги, ответы), - `attributes` — параметры, сохраняемые между сценариями. Благодаря этому: - Бот “помнит”, на каком этапе остановился пользователь. - Можно персонализировать коммуникации. - Возможна аналитика CJM и сегментация по атрибутам. --- ### Пример архитектуры для крупной компании #### Сценарий: коммуникации REHAU с монтажниками ``` [Монтажник / Telegram] ⇅ [Metabot Bot / Сценарий "Регистрация + ЛК"] ⇅ [REHAU Portal] ⇅ [CRM + Webinar + BI] ``` 📍 Здесь Metabot выступает **прослойкой-коммутатором**: - Из портала в Metabot приходят события (регистрация, вебинар, заказ). - Metabot сообщает монтажнику: “У вас новый заказ”, “Вебинар сегодня в 10:00”, “Оцените качество”. - Ответ монтажника отправляется обратно в CRM и BI-систему. --- ### Коммуникационная карта для REHAU
№СобытиеКоммуникацияУчастникКаналAPI / Endpoint
1Монтажник зарегистрировался на портале“Добро пожаловать!”МонтажникTelegram`/users/connect-bot`
2Назначен новый вебинар“Вы приглашены на обучение”МонтажникTelegram`/events/webinar-invite`
3Вебинар завершён“Оцените качество обучения”МонтажникTelegram`/events/webinar-feedback`
4Отзыв отправлен“Спасибо за обратную связь”МонтажникTelegram`/feedback/received`
📊 Каждый шаг — событие в бизнес-системе, каждая коммуникация — сценарий в Metabot, каждое действие — новая строка в аналитике BI. --- ### Пример карты интеграций для eCommerce
СобытиеТочка интеграцииОписаниеКоммуникация
Новый заказ`/order/thank-you`Отправляем благодарность и детали заказа“Спасибо за покупку!”
Статус заказа изменён`/order/status`Сообщаем об отправке“Ваш заказ отправлен!”
Доставка завершена`/order/delivered`Просим оставить отзыв“Оцените доставку”
Новый отзыв`/order/review`Отправляем бонус“Спасибо за отзыв!”
--- ### Пример: семейный сервис **Fmlst** #### Архитектура: ``` Fmlst CMS → Metabot → Telegram → Пользователи семьи ``` #### Коммуникационная карта:
СобытиеКоммуникацияУчастникиAPI
Новая публикация“В семье новое событие!”Все члены семьи`/post/new`
Новый комментарий“Кто-то прокомментировал пост”Автор публикации`/comment/new`
Новый участник семьи“Добро пожаловать в семью!”Все пользователи`/users/new`
Бот превращает семейный сайт в **живой диалог** — обновления, обсуждения и эмоции происходят прямо в мессенджере. --- ### Пример Helpdesk-интеграции #### Архитектура: ``` Helpdesk ⇄ Metabot ⇄ Telegram / Webchat ```
СобытиеКоммуникацияКаналAPI
Новый тикет“Ваша заявка создана”Telegram`/ticket/new`
Ответ оператора“Ваш вопрос решён?”Telegram`/ticket/reply`
Оценка обслуживания“Пожалуйста, оцените качество”Telegram`/ticket/feedback`
🎯 Результат: - Клиент получает ответы мгновенно. - Поддержка видит ответы и оценки в CRM. - Система автоматически закрывает тикеты при подтверждении. --- ### Аналитика и управление Каждая коммуникация генерирует **лог событий**, который можно собирать и визуализировать в BI:
МетрикаИсточникПример
ВовлечённостьЛоги Metabot82% пользователей ответили на сообщение
Среднее время реакцииBI1,7 мин
Ошибки интеграцииLog Trace0,3%
Конверсия → ЦельCJM Map+27% по цепочке обучения
--- ## Кейс REHAU × Metabot ### Как бизнес-процессы ожили в мессенджерах --- ### Контекст Компания **REHAU** — крупный производитель строительных систем и решений. Её аудитория — **монтажники, дилеры, проектировщики**, распределённые по регионам и сегментам. Основная проблема: - коммуникация была разрознена, - вебинары, порталы, CRM — не связаны, - пользователи терялись между системами. --- ### Решение Metabot внедрил **коммуникационный слой**, который объединил все точки взаимодействия в единый диалог. Теперь монтажник получает всё в одном месте — **в Telegram-боте**: - регистрация в портале, - приглашения на вебинары, - напоминания и тесты, - обратная связь и рейтинг, - уведомления о заказах и баллах. --- ### Технологическая архитектура REHAU Integration Bus ``` [REHAU Portal] → [Metabot API / Webhooks] ⇅ [Metabot Scenario Engine / JS Scripts] ⇅ [Telegram Bot Interface] ⇅ [User / Installer] ``` Ключевые принципы: - Каждое событие на портале вызывает webhook в Metabot. - Metabot управляет сценарием, контекстом и памятью. - Все ответы пользователей логируются и синхронизируются обратно. --- ### Результаты 📈 **Внедрение Deep Messaging Integration дало:** - рост вовлечённости монтажников ×5, - сокращение ручных рассылок на 90%, - оперативную аналитику по активности, - снижение нагрузки на call-центр, - создание персональных digital-профилей. --- ### Из интервью на конференции > “Мы смогли объединить всё: портал, Telegram и CRM — теперь коммуникации не висят отдельно, они стали частью нашей инфраструктуры.” — *Команда REHAU, проект Metabot Connect.* --- ## 💡 Заключение **От интеграции к операционной системе коммуникаций** Глубокая интеграция — это не просто API или бот. Это **новый уровень зрелости бизнеса**, где общение, процессы и данные работают как единое целое. > “Диалог — это новый интерфейс, коммуникация — новая инфраструктура, а Metabot — операционная система, которая объединяет их в живой интеллект предприятия.” --- ## Управление, аналитика и развитие ### Управление интеграциями После запуска Deep Messaging Integration, проект должен **жить и развиваться**. Это не одноразовая настройка — это новая **коммуникационная инфраструктура** компании. Основные роли:
РольОтветственность
**ComOps-архитектор**проектирует коммуникационные петли, карты, API
**Интегратор / разработчик**реализует эндпоинты и сценарии
**Менеджер коммуникаций**управляет контентом и рассылками
**Аналитик / BI-специалист**анализирует метрики и воронки
**Оператор / бот-менеджер**следит за логами, отвечает вручную при необходимости
🧭 Методология DMI предлагает постоянный цикл управления: > **Design → Integrate → Measure → Improve** --- ### Мониторинг и логирование Каждое событие, коммуникация и ошибка должны фиксироваться в логах. Metabot предоставляет системный журнал:
ПолеОписание
`trace_id`уникальный идентификатор цепочки
`source_system`CRM, ERP, Portal и т.д.
`endpoint`alias точки интеграции
`userId / leadId`участник коммуникации
`status`success / fail
`latency_ms`время отклика
`timestamp`дата и время события
📊 Все логи можно экспортировать в BI и строить визуальные отчёты. --- ### Метрики коммуникаций Коммуникации измеряются по тем же принципам, что и процессы:
МетрикаЗначениеПример
**Delivery Rate**процент доставленных сообщений98%
**Engagement Rate**процент пользователей, ответивших на сообщение76%
**Response Time**среднее время реакции1.8 минуты
**Conversion Rate**переход из коммуникации в действие22%
**Satisfaction Index (CSAT)**оценка удовлетворённости4.7/5
**Error Rate**процент неуспешных вызовов API0.4%
Каждая карта коммуникаций превращается в **аналитическую карту**: можно видеть, на каких шагах пользователи теряются и где сценарий требует доработки. --- ### Коммуникационные BI-дашборды В BI можно построить визуальную аналитику: **Примеры отчётов:** - Динамика вовлечённости по неделям - Среднее время ответа - Количество событий на пользователя - Воронка: Событие → Коммуникация → Ответ → Действие - Тепловая карта сценариев 📈 Таким образом, коммуникации становятся **измеримыми и управляемыми процессами**. --- ### Управление качеством и версиями Каждая коммуникационная карта и интеграция должна иметь версионность:
ВерсияИзменениеОтветственныйДата
1.0Базовая регистрацияАрх. Алёна01.02
1.1Добавлен сбор emailАрх. Алёна15.02
1.2Улучшен UXМаркетинг01.03
Metabot поддерживает экспорт и хранение карт коммуникаций в JSON, а также историю изменений, чтобы можно было откатить или сравнить версии. --- ### Безопасность и доступы DMI управляет не только коммуникациями, но и **доступом к данным**: - все вызовы через HTTPS; - токены разграничены по ролям; - события журналируются; - личные данные пользователей (PII) не передаются без шифрования. Для критичных процессов создаются **изолированные эндпоинты** с отдельными ключами, например для платежей, медицинских данных или HR-информации. --- ### Этапы внедрения DMI
ЭтапДействиеРезультат
**1. Анализ процессов**выбираем ключевые сценарии (регистрация, заказ, поддержка)выявлены 3–5 процессов
**2. Построение карт коммуникаций**документируем все события и ролиготов набор карт
**3. Определение точек интеграции**проектируем эндпоинты, тело запроса, ответAPI-документация согласована
**4. Реализация и тестирование**создаём сценарии, интеграции, авторизациюрабочий MVP
**5. Мониторинг и аналитика**подключаем BI, собираем метрикиконтроль эффективности
**6. Масштабирование**добавляем новые процессызрелая коммуникационная инфраструктура
--- ### Роли и организационная модель DMI внедряется в компании как **сквозная функция между ИТ и бизнесом**. ``` ┌──────────────┐ │ Руководство │ └──────┬───────┘ │ ┌────────────┴────────────┐ │ Коммуникационный офис │ └────────────┬────────────┘ │ ┌──────────────┬─────────────┬─────────────┐ │ Архитектор │ Разработчик │ Аналитик BI │ └──────────────┴─────────────┴─────────────┘ ``` Так рождается **ComOps Unit** — подразделение, которое отвечает за коммуникации как за инфраструктуру. --- ## Практические шаблоны и инструменты ### Шаблон карты коммуникаций
№СобытиеКоммуникацияКаналУчастникиДействияAPI
1Новый заказ“Спасибо за заказ”TelegramКлиент—`/order/thank-you`
2Изменился статус заказа“Ваш заказ отправлен”TelegramКлиентПодтверждение доставки`/order/status`
3Заказ доставлен“Пожалуйста, оставьте отзыв”TelegramКлиентОтветить оценкой`/order/feedback`
📘 Используется как рабочая таблица при проектировании DMI. --- ### Шаблон таблицы точек интеграции
Endpoint AliasMethodURLОписаниеRequest ParamsResponse
`users/connect-bot`POST`/bots/{botId}/call/users/connect-bot`Привязка пользователя к боту`{ userId }``{ success: true }`
`order/thank-you`POST`/bots/{botId}/call/order/thank-you`Благодарность за заказ`{ orderId, userId }``{ success: true }`
`comment/new`POST`/bots/{botId}/call/comment/new`Новый комментарий`{ postId, authorId, userIds }``{ success: true }`
--- ### Шаблон технического задания (TЗ) на DMI-проект 1. **Цель:** интеграция мессенджеров в бизнес-процесс X 2. **Системы:** CRM, сайт, ERP, Metabot 3. **Каналы:** Telegram, WhatsApp 4. **Коммуникационные сценарии:** - Регистрация - Подтверждение - Уведомления - Обратная связь 5. **API и события:** описать все эндпоинты 6. **Идентификация пользователей:** `userId ↔ leadId` 7. **Метрики:** вовлечённость, конверсия, удовлетворённость 8. **Безопасность:** авторизация, шифрование, логирование 9. **Артефакты:** карты коммуникаций, таблица эндпоинтов, JSON-сценарии 10. **Сроки и роли.** --- ### Рекомендации по масштабированию - Начинайте с **одного сценария**, но стройте так, чтобы можно было развивать. - Внедряйте **единую таблицу идентификаторов** для всех систем. - Логику коммуникаций оформляйте в виде **карты + эндпоинты + сценарий**. - Интеграции — через REST API или Webhook Proxy, чтобы не менять ядро CRM. - Добавляйте аналитику сразу, с первого дня. --- ## Заключение: от Deep Messaging Integration к Communication Operating System В этой работе мы рассмотрели **первый уровень архитектуры Metabot — Deep Messaging Integration (DMI)**. Мы показали, как **коммуникационный** и **операционный слои** соединяются с бизнес-системами, создавая живую ткань диалогов и событий. Мы **осознанно не касались когнитивного слоя (Cognitive Layer)** — памяти, понимания и интеллекта — он будет раскрыт в отдельной части серии. Если вы только начинаете внедрение, мы рекомендуем **стартовать с коммуникационного слоя**: - настройте простые сценарии взаимодействия, - выстройте пользовательские пути, - улучшите онбординг и конверсию, - поработайте с аудиторией через ссылки и чаты, даже **без глубокой интеграции**. Это даст **быстрый бизнес-результат** и позволит увидеть реальную ценность коммуникаций. Когда потребуется больший эффект — переходите к полноценной интеграции, создавая **end-to-end-сервисы**, где всё работает бесшовно: от CRM до мессенджера. Теперь вы знаете, **как это делать**. Желаем вам успеха в построении собственной коммуникационной инфраструктуры! --- 💬 > “Когда коммуникации становятся инфраструктурой, > предприятие начинает думать и действовать как живой организм.”