Продукт

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

Как объединить данные CRM, финансов, телефонии и разработки в проверяемый рабочий процесс.

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

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

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

Онлайн-школа WowSpeak: amoCRM + Wazzup. В опубликованном Wazzup кейсе школа использует статус и дату возврата клиента в CRM для автоматических сообщений. Через Wazzup также отправляются анкеты и напоминания об уроках. Это пример совместной работы данных о продаже и канала общения; внедрение выполнено средствами описанной в кейсе интеграции. Кейс WowSpeak у Wazzup.

ActivSports: amoCRM + Wazzup24. Интегратор Aspire описывает подключение Wazzup24 к amoCRM для общения с клиентами через WhatsApp из CRM. Источник подтверждает конкретную компанию и связку систем. Результаты этого проекта не являются результатами Context4. Кейс внедрения Aspire.

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

MANGO OFFICE описывает передачу пропущенных звонков в Битрикс24 и контроль их обработки. Интеграция Битрикс24 и MANGO OFFICE.
Финтабло документирует передачу сделок из CRM и сопоставление полей. Это отдельный продукт «Коннектор Финтабло», а не функция Context4. Инструкция Финтабло.
Linear документирует создание задач из ошибок Sentry и связь между ними. Это штатная интеграция поставщиков. Документация Linear.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В MANGO OFFICE выполните telephony.history.request за согласованный период не длиннее 28 дней. Сохраните key. Получайте отчёт через telephony.history.result, соблюдая pollAfterMs; pending ещё не означает отсутствие звонков.
Из готового отчёта выделите входящие без ответа по правилам полей поставщика. Не считайте любой код завершения пропуском; учитывайте последующие отвеченные звонки того же клиента в выбранном периоде. Сохраните entry_id и номера.
В Битрикс24 найдите контакт через crm.contact.list, затем прочитайте crm.contact.get и связанные сделки через crm.deal.list / crm.deal.get. Сопоставляйте нормализованный внешний номер, затем сохраняйте ID контакта. Если номер общий или найдено несколько контактов, передайте выбор человеку.
Через task.task.list проверьте, есть ли уже задача на этот звонок. Покажите найденный контакт, сделку, время звонка, ответственного и предложенный срок. После разрешения выполните task.task.create, сохранив в описании ссылку на клиента и entry_id звонка.
Проверьте задачу через 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 — существующие задачи, их состояние, команду и обсуждение. Агент объединяет технические признаки ошибки с текущим планом работ.

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

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

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

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

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

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

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

Далее изучите подключение сервисов, действия и результаты и работу через AI и MCP.