---
title: "Бизнес-сценарии: два сервиса, одна задача"
description: "Как объединить данные CRM, финансов, телефонии и разработки в проверяемый рабочий процесс."
group: "Продукт"
order: 30
---

## Адреса этого стенда

- Документация: https://context4.me/docs.md
- Индекс для агента: https://context4.me/docs/agent-index.json
- Консоль и подключения: https://console.context4.me/integrations
- MCP: https://context4.me/mcp
- HTTP API: https://context4.me/v1
- Composio base URL: https://context4.me/compat/context4/v1
- OpenAPI: https://context4.me/docs/openapi.json
- Каталог HTTP/MCP: https://context4.me/docs/api-index.json
- Маршруты Composio: https://context4.me/docs/compat-routes.json
- Коннекторы: https://context4.me/docs/connectors.json


# Бизнес-сценарии: два сервиса, одна задача

CRM знает, кому вы обещали перезвонить. Телефония — состоялся ли разговор. Финансовый сервис — какие платежи учтены. Когда AI получает данные из двух систем, он может подготовить следующий шаг с учётом обеих сторон.

Ниже сначала приведены внешние примеры, затем — четыре сценария для реализации через Context4. Это инструкции для настройки агента, а не отчёты о выполненных внедрениях Context4. Экономию времени и рост продаж по ним мы не измеряли.

## Что уже делают компании

**Онлайн-школа WowSpeak: amoCRM + Wazzup.** В опубликованном Wazzup кейсе школа использует статус и дату возврата клиента в CRM для автоматических сообщений. Через Wazzup также отправляются анкеты и напоминания об уроках. Это пример совместной работы данных о продаже и канала общения; внедрение выполнено средствами описанной в кейсе интеграции. [Кейс WowSpeak у Wazzup](https://wazzup24.ru/blog/kejs-wowspeak/).

**ActivSports: amoCRM + Wazzup24.** Интегратор Aspire описывает подключение Wazzup24 к amoCRM для общения с клиентами через WhatsApp из CRM. Источник подтверждает конкретную компанию и связку систем. Результаты этого проекта не являются результатами Context4. [Кейс внедрения Aspire](https://startup.aspire.agency/work/2024-activsports-wazzup24-amocrm).

Есть и документированные поставщиками рабочие процессы, для которых мы не заявляем отдельного клиента:

- MANGO OFFICE описывает передачу пропущенных звонков в Битрикс24 и контроль их обработки. [Интеграция Битрикс24 и MANGO OFFICE](https://developers.mango-office.ru/support/4_integratsii/1_vse-integratsii/16_bitrix24/3_obrabotka_zvonkov/04_1_4_kontrol_za_obrabotkoy_propuschennogo_zvonka/obzor/).
- Финтабло документирует передачу сделок из CRM и сопоставление полей. Это отдельный продукт «Коннектор Финтабло», а не функция Context4. [Инструкция Финтабло](https://help.fintablo.ru/article/30329).
- Linear документирует создание задач из ошибок Sentry и связь между ними. Это штатная интеграция поставщиков. [Документация Linear](https://linear.app/docs/sentry).

## Перед запуском сценария

Подключите оба сервиса и проверьте доступные инструменты в своём аккаунте. Все перечисленные здесь коннекторы представлены в публичном каталоге Context4 в статусе **beta**. Наличие действия в каталоге не гарантирует доступ в конкретном подключении.

В последовательностях ниже указаны **ключи действий**, например `crm.lead.get`. Это не универсальные имена MCP-инструментов: агент должен выбрать соответствующее подключение, найти действие и прочитать его текущую входную схему. Одинаковый ключ в разных сервисах означает разные инструменты.

Для регулярной работы вашему агенту или приложению нужны расписание либо внешний запуск, хранилище соответствий и журнал выполненных шагов. Описанные сценарии сами по себе их не создают. Сохраняйте ID записей вместе с ID подключения: одинаковые номера в разных аккаунтах не означают одну сущность.

Изменения, отправку сообщений и звонки выполняйте в пределах явно согласованного поручения. Если пользователь ещё не разрешил конкретное действие или правило автоматизации, покажите результат чтения и предложенные изменения до выполнения. Context4 не следует считать гарантией отдельного окна подтверждения в каждом AI-клиенте.

## 1. Напомнить клиенту о следующем шаге: amoCRM + Wazzup

**Задача бизнеса.** Клиент дошёл до согласованного этапа сделки, но менеджеру приходится отдельно искать номер и подходящий шаблон сообщения.

**Данные двух систем.** amoCRM даёт сделку, связанный контакт и его телефон. Wazzup даёт доступные каналы, их состояние и шаблоны с разрешёнными каналами. Агент выбирает сообщение по этапу сделки и проверяет, что его можно отправить выбранным каналом.

### Последовательность для агента

1. В amoCRM выполните `crm.lead.get` для выбранной сделки. Получите связанный контакт через `crm.contact.get`. Если ID контакта не вернулся, используйте заранее проверенное соответствие или уточните его; не выбирайте человека по одному имени.
2. В Wazzup выполните `messaging.channel.list` и `messaging.template.list`. Выберите рабочий канал и подходящий шаблон по возвращённым данным, проверьте его статус и список каналов.
3. Сопоставьте телефон контакта с `chatId`. Для этого коннектора `chatId` — телефон в международном формате, только цифры; ID контакта amoCRM сюда не подходит. Сохраните соответствие «подключение amoCRM + ID контакта → подключение Wazzup + channelId + chatId».
4. Подготовьте текст с учётом полей сделки. Покажите получателя, канал, шаблон и подставляемые значения. После разрешения выполните `messaging.message.send_template`: `templateId` берётся из `templateGuid` выбранного шаблона, значения — из согласованных данных.
5. Сохраните возвращённый `messageId` и состояние операции. Ответ `accepted` означает принятие запроса, а не подтверждённую доставку или прочтение.

**Защита от повторов.** До отправки проверяйте в журнале ключ «подключение + сделка + этап/повод + версия шаблона». Заблокируйте одновременную обработку одного ключа. Не считайте `crmMessageId` доказательством гарантированной дедупликации. Если отправка прошла, а сохранение результата не удалось, сначала проверьте операцию и Wazzup; при неизвестном исходе не отправляйте сообщение автоматически повторно.

**Ожидаемый результат.** Согласованное сообщение для нужной сделки уходит через проверенный канал без ручного копирования номера. В текущем наборе действий Wazzup нет чтения истории переписки или статуса доставки: этот сценарий не может доказать, что клиент давно не отвечал или прочитал сообщение. Правила канала и доступность шаблона проверяются отдельно.

**Поручение агенту:** «Для этой сделки amoCRM подготовь напоминание через Wazzup. Прочитай контакт, каналы и шаблоны. Покажи номер, шаблон и значения; отправь после моего согласования. Если исход прошлой отправки неизвестен, остановись».

## 2. Подготовить работу по оплатам: amoCRM + Финтабло

**Задача бизнеса.** Менеджер видит сумму продажи в CRM, но перед разговором должен проверить учтённые платежи и обязательства.

**Данные двух систем.** amoCRM даёт сделку, контакт и ответственного. Финтабло — связанную финансовую сделку, обязательства и операции. Получается список вопросов по оплате с привязкой к владельцу продажи.

### Последовательность для агента

1. В amoCRM выполните `crm.lead.get`, затем `crm.company.get` или `crm.contact.get` для связанной стороны, если её ID известен.
2. Найдите проверенное соответствие «подключение amoCRM + ID сделки → подключение Финтабло + ID сделки», а также соответствие контрагента. При первичной настройке можно прочитать `deal.list` и `partner.list` в Финтабло и предложить кандидатов человеку. Одинаковое название компании недостаточно; сверяйте реквизиты, если они доступны, и сохраняйте подтверждённые ID.
3. В Финтабло вызовите `deal.get`, `obligation.list` и `transaction.list` для финансовой сделки. Для операций разделяйте план и факт по `isPlan`, учитывайте направление, валюту, период и все страницы ответа.
4. Составьте сводку: сумма сделки в CRM, данные финансовой сделки, неоплаченные обязательства и фактические поступления за выбранный период. Не складывайте обязательства и операции как независимые долги: они могут относиться к одной оплате. Различие сумм вынесите на сверку, не исправляйте его автоматически.
5. В amoCRM проверьте `crm.task.list`. После разрешения создайте через `crm.task.create` задачу ответственному: проверить конкретное расхождение или связаться с клиентом. Срок и тип задачи должны быть согласованы; для проверки результата используйте `crm.task.get`.

**Защита от повторов.** Ключ журнала — «CRM-сделка + финансовая сделка + период сверки + тип задачи». Сохраните ID созданной задачи; перед повтором прочитайте её и список задач. Если чтение Финтабло оборвалось на странице, завершите чтение до выводов. Если задача создалась, а ответ потерялся, сначала найдите её, затем решайте вопрос повтора.

**Ожидаемый результат.** Менеджер получает основанную на двух системах подготовку к разговору и конкретную задачу. Это не банковская выписка в реальном времени и не доказательство просрочки: актуальность загрузки, условия договора, возвраты, налоги и валютные различия нужно учитывать отдельно. Сценарий не меняет финансовый учёт и не объявляет продажу оплаченной только по совпадению суммы.

**Поручение агенту:** «Сверь эту сделку amoCRM с подтверждённой сделкой Финтабло за указанный период. Отдели плановые платежи от фактических. Покажи расхождения и предложи задачу менеджеру, не меняя учётные записи».

## 3. Вернуть пропущенный звонок в работу: Битрикс24 + MANGO OFFICE

**Задача бизнеса.** Пропущенный звонок есть в телефонии, а руководителю нужно понять, кто из известных клиентов остался без следующего шага.

**Данные двух систем.** MANGO OFFICE возвращает записи звонков, номера и время ответа. Битрикс24 даёт контакт, его сделки, ответственного и существующие задачи. Агент проверяет звонок в контексте клиентской работы.

### Последовательность для агента

1. В MANGO OFFICE выполните `telephony.history.request` за согласованный период не длиннее 28 дней. Сохраните `key`. Получайте отчёт через `telephony.history.result`, соблюдая `pollAfterMs`; `pending` ещё не означает отсутствие звонков.
2. Из готового отчёта выделите входящие без ответа по правилам полей поставщика. Не считайте любой код завершения пропуском; учитывайте последующие отвеченные звонки того же клиента в выбранном периоде. Сохраните `entry_id` и номера.
3. В Битрикс24 найдите контакт через `crm.contact.list`, затем прочитайте `crm.contact.get` и связанные сделки через `crm.deal.list` / `crm.deal.get`. Сопоставляйте нормализованный внешний номер, затем сохраняйте ID контакта. Если номер общий или найдено несколько контактов, передайте выбор человеку.
4. Через `task.task.list` проверьте, есть ли уже задача на этот звонок. Покажите найденный контакт, сделку, время звонка, ответственного и предложенный срок. После разрешения выполните `task.task.create`, сохранив в описании ссылку на клиента и `entry_id` звонка.
5. Проверьте задачу через `task.task.get` и сохраните её ID. Если пользователь отдельно поручил именно позвонить, сначала прочитайте `telephony.employee.list` и согласуйте сотрудника с его `extension`, затем используйте `telephony.call.callback` с точным номером клиента и `command_id`.

**Защита от повторов.** Для задачи используйте ключ «подключение MANGO + entry_id + тип следующего шага». Для звонка ведите отдельную запись попытки: принятый запрос нельзя автоматически повторять как обычное чтение. При потере ответа сверяйте операцию и телефонию. Если отчёт истёк (`absent-or-expired`), запросите его заново за тот же период и исключите уже обработанные `entry_id`.

**Ожидаемый результат.** Известные пропущенные обращения получают проверяемый следующий шаг и ответственного. Созданная задача ещё не означает, что клиенту перезвонили; `submitted` у обратного звонка означает отправку команды, а не состоявшийся разговор. Проверяйте полноту отчёта: ограниченный ответ не доказывает отсутствие других звонков. Уже настроенная штатная интеграция может создавать задачи самостоятельно — учитывайте её, чтобы не дублировать работу.

**Поручение агенту:** «Сопоставь пропущенные входящие MANGO OFFICE за этот период с контактами, сделками и задачами Битрикс24. Покажи обращения без следующего шага. Не создавай задачи и не звони до согласования списка».

## 4. Передать ошибку в работу без дубликата: Sentry + Linear

**Задача бизнеса.** Ошибка видна в мониторинге, но перед новой задачей нужно выяснить, не занимается ли ею уже команда разработки.

**Данные двух систем.** Sentry даёт ID ошибки, события, частоту и контекст сбоя в пределах ответа. Linear — существующие задачи, их состояние, команду и обсуждение. Агент объединяет технические признаки ошибки с текущим планом работ.

### Последовательность для агента

1. В Sentry выполните `issue.triage_pack` для выбранной ошибки. Сохраните организацию, проект, числовой ID и ссылку на issue. Не переносите секреты или лишние персональные данные события в задачу.
2. В Linear выполните `issue.search` по сохранённому ID/ссылке Sentry и ключевым признакам ошибки. Для кандидатов используйте `issue.overview`, чтобы прочитать задачу и комментарии. Совпадение заголовков ещё не подтверждает одну причину.
3. Если соответствие уже подтверждено, покажите дополнение к существующей задаче. После разрешения добавьте его через `comment.create`. Если задачи нет, выполните `team.list`, согласуйте команду и содержание, затем вызовите `issue.create`.
4. В описании или комментарии укажите ссылку на Sentry, наблюдаемые факты и период наблюдения. Разделите факты и гипотезы. Сохраните соответствие «организация Sentry + ID ошибки → workspace Linear + ID задачи».
5. Проверьте результат через `issue.get` или `comment.list` в Linear. Покажите пользователю ссылку на созданную либо дополненную задачу.

**Защита от повторов.** До записи захватывайте в своём журнале ключ «организация Sentry + ID ошибки + команда Linear». Для комментария добавьте период или ID последнего обработанного события. Если создание удалось, а журнал не обновился, сначала ищите задачу по ссылке Sentry. При неизвестном исходе не создавайте вторую автоматически.

**Ожидаемый результат.** Команда получает задачу с контекстом реального сбоя либо дополнение к существующей задаче. Создание ссылки в тексте не включает штатную двустороннюю интеграцию Linear–Sentry. Эти шаги не обещают автоматического закрытия Sentry при завершении Linear и не доказывают первопричину без дальнейшего расследования.

**Поручение агенту:** «Прочитай эту ошибку Sentry и найди связанную задачу Linear. Покажи, что уже известно в обеих системах. Предложи комментарий или новую задачу, отдели факты от гипотез и дождись согласования записи».

## Как проверить первый запуск

Начните с одной известной записи. Проверьте, что агент прочитал данные **обоих** сервисов, показал способ сопоставления и сообщил о неоднозначностях. После разрешённой записи откройте результат в исходном сервисе. Повторный запуск должен находить уже выполненный шаг, а сбой второго сервиса — оставлять понятное состояние для продолжения.

Далее изучите [подключение сервисов](https://context4.me/docs/connections.md), [действия и результаты](https://context4.me/docs/actions.md) и [работу через AI и MCP](https://context4.me/docs/ai-mcp.md).