MCP Битрикс24 позволяет подключить внешний ИИ-клиент к CRM: прочитать доступную сотруднику карточку сделки, подготовить изменение и запросить подтверждение перед записью. Для этого у Битрикс24 есть официальный MCP-сервер. Рабочий сценарий начинается с проверки прав сотрудника, доступных инструментов и того, что покажет клиент перед выполнением действия.
Подключение сервера
Официальный MCP-сервер Битрикс24 подключает внешний ИИ-клиент к CRM. Администратор разрешает интеграцию, сотрудник подключает свою учётную запись, а доступные действия ограничены его правами и возможностями тарифа.
У Битрикс24 есть официальный MCP-сервер для управления CRM и задачами из внешнего ИИ-клиента. Администратор сначала включает подключение внешних ИИ в настройках портала. Затем сотрудник настраивает соединение: поддерживаются варианты с OAuth и токеном подключения в зависимости от клиента. После авторизации проверьте список доступных инструментов в вашем клиенте: возможности сервера развиваются, а отдельные действия зависят от прав и настроек портала. Официальный адрес и текущие шаги подключения смотрите в справке Битрикс24. Общие способы интеграции CRM через REST API, вебхуки и сценарии разобраны в материале о подключении нейросети к Битрикс24; здесь речь про официальный MCP-сервер и безопасную работу с карточкой сделки.
Важное различие: сервер mcp.bitrix24.com подключается к данным вашего портала и выполняет разрешённые действия. Отдельный сервер mcp-dev.bitrix24.com помогает разработчику искать документацию REST API и служит справочником для разработчика без доступа к карточкам портала. Для рабочей задачи менеджера нужен первый вариант. Перед запуском проверьте, какие данные внешняя ИИ-система получит от Битрикс24 и какие правила вашей компании регулируют такой обмен. Начните с чтения карточки на учебной сделке, затем отдельно испытайте запись и подтверждение. Доступ к CRM задавайте ролью сотрудника внутри Битрикс24; текстовое ограничение в промпте помогает модели выбрать действие; защиту данных обеспечивают права CRM и проверка вызовов.
Чтение карточки
Менеджер передаёт агенту идентификатор или ссылку на сделку и просит краткую сводку. Клиент через MCP обращается к доступным инструментам Битрикс24. Содержание ответа зависит от прав вошедшего сотрудника и полей конкретной карточки: стадия, сумма, ответственный, связанные контакты и история действий могут требовать разных запросов. Поэтому сначала проверьте, какие поля реально возвращаются в вашем портале. Попросите агента указать источник каждого важного вывода: поле карточки, дату комментария или связанную задачу. Если сводка упоминает договорённость с клиентом, менеджер должен открыть исходную запись и проверить её перед звонком.
- Выберите учебную сделку и сотрудника с типичной ролью отдела продаж.
- Проверьте чтение карточки: какие поля и связанные элементы видны через MCP при правах этого сотрудника.
- Попросите сводку со ссылками на карточку и датами найденных записей; сравните её с исходными данными.
- Повторите запрос из роли с меньшими правами и убедитесь, что закрытые сделки и действия остаются недоступными.
Сводка помогает ориентироваться в длинной истории, но она остаётся черновиком. Модель способна пропустить важный комментарий, перепутать владельца задачи или неверно связать две даты. Для решения по сделке менеджер сверяет критичные поля с карточкой. Отдельно проверьте режим приватности внешнего ИИ-клиента: условия хранения запросов и содержание передаваемых данных зависят от выбранного сервиса. При необходимости используйте только разрешённый компанией клиент и минимальный набор полей.
Запись с подтверждением
Изменение стадии, комментария или задачи влияет на работу команды. Битрикс24 описывает запрос подтверждения перед действием через внешний ИИ-клиент, но конкретный экран и доступный набор действий зависят от клиента. Покажите менеджеру черновик в форме «сделка — поле — старое значение — новое значение — основание». До подтверждения запись в CRM оставляют прежней. После подтверждения повторно прочитайте карточку и убедитесь, что изменилось именно согласованное поле. Если подтверждение истекло или карточку успели изменить коллеги, запрос следует пересобрать из актуальных данных. Для дополнительных ограничений можно поставить собственный проверяющий слой между клиентом и рабочим процессом, если стандартного подтверждения вашей команде недостаточно.
- Попросите агента подготовить изменение на учебной сделке и показать исходное и новое значения.
- Проверьте, какие права нужны для действия и видит ли менеджер конкретную карточку.
- Отклоните первый черновик: убедитесь, что карточка осталась прежней.
- Подтвердите исправленный вариант через интерфейс клиента и повторно прочитайте карточку.
- Зафиксируйте запрос, подтвердившего сотрудника, результат операции и ссылку на запись для разбора спорных случаев.
Журнал действий
Для контролируемого запуска полезен журнал запросов и результатов. Записывайте только необходимые данные: кто запросил чтение или изменение, когда клиент вызвал инструмент, какое действие подтвердил сотрудник, какой результат вернул Битрикс24. Возможности аудита в самой платформе и в ИИ-клиенте различаются, поэтому на пилоте проверьте, где остаётся запись каждого шага. Журнал с конфиденциальными полями защищайте теми же правилами доступа, что и данные CRM. При разборе ошибки сопоставляйте запись клиента с историей карточки: успех записи подтверждают ответ инструмента и повторное чтение карточки.
| Событие | Что проверить | Зачем это нужно |
|---|---|---|
| Чтение карточки | Сотрудник, роль, идентификатор сделки | Проверка границы доступа |
| Черновик изменения | Поле, старое и предложенное значение | Понятное подтверждение |
| Подтверждение | Кто и какое действие подтвердил | Связь решения с записью |
| Результат записи | Ответ инструмента и повторное чтение карточки | Проверка фактического изменения |
Журнал помогает найти повторяющиеся ошибки: агент выбирает соседнюю сделку, использует устаревший комментарий или готовит изменение без основания. Владелец сценария разбирает такие случаи и уточняет инструкции для модели, права роли или порядок подтверждения. После изменения настроек повторяйте контрольные запросы на учебной сделке. Если в клиенте отсутствует нужная история действий, подготовьте отдельный способ фиксации событий до масштабирования на весь отдел.
Ведёте ли журнал того, что ИИ менял в карточках сделок?
Проверка допуска
Проверка допуска начинается с учебной сделки без реальных клиентских данных. Используйте две роли: менеджер, которому доступна сделка, и сотрудник с ограниченным доступом. Проверьте чтение, попытку найти закрытую сделку, отклонение черновика и запись после подтверждения. Успешным считается контур, в котором закрытые данные остаются вне ответа, отклонённый черновик сохраняет карточку без изменений, а подтверждённое действие отражается в повторном чтении. Отдельно проверьте отзыв подключения: после закрытия доступа клиент должен прекратить работу с порталом. Повторяйте эту проверку при смене ролей, клиента или набора MCP-инструментов. Для выбора между агентом и обычной автоматизацией CRM пригодится сравнение сценариев; внедрение под ключ описано на странице автоматизации процессов.
Отдельно испытайте ошибочный запрос из длинного комментария в сделке. Внешний текст карточки может содержать просьбу сменить стадию, раскрыть контакты или игнорировать правила. Такой фрагмент следует считать содержимым карточки; вызов инструмента разрешает только прямой запрос сотрудника. Покажите менеджеру, какие поля попали в контекст модели, и проверьте отсутствие скрытых полей в сводке. После теста сохраните контрольный запрос и ожидаемый результат рядом с настройками подключения. При изменении роли сотрудника или смене ИИ-клиента прогоните те же сценарии повторно: различия в отображении подтверждения и составе инструментов способны изменить поведение контура.
Начните с чтения одной учебной сделки и проверки прав двух сотрудников. Запись подключайте после успешного теста подтверждения, журнала и повторного чтения карточки. В рабочем контуре сохраняйте только нужные разрешения и проверяйте изменения на актуальных данных.