Kommo + Adobe Sign: автоматическая отправка документов на подпись из воронки

Нативной интеграции между Kommo и Adobe Sign нет. Менеджеры создают документы вручную в Adobe Acrobat или Word, загружают в Adobe Sign, вводят email получателя — и только потом возвращаются в Kommo чтобы поставить задачу «ожидаем подписи». Когда документ подписан, Kommo не узнаёт об этом автоматически — менеджер снова заходит в Adobe Sign, проверяет, вручную меняет этап сделки.

Кастомная интеграция закрывает этот цикл: документ формируется из полей сделки, уходит на подпись при переводе на нужный этап, а статус подписания синхронизируется в карточку без участия менеджера.

Почему нет нативной интеграции

Adobe Sign имеет готовые коннекторы с Salesforce, Microsoft Dynamics, ServiceNow и другими enterprise-системами. Для Kommo официального коннектора нет — Adobe приоритизирует крупные CRM с большой корпоративной базой.

Zapier содержит Adobe Sign как trigger/action, но с ограничениями:
— Нет шаблонизации документа с подстановкой полей из Kommo
— Webhook от Adobe Sign при подписании можно получить только через платный план
— Нет обработки отказа от подписи или истечения срока

Kommo marketplace имеет DocuSign и PandaDoc как альтернативы — если компания уже работает в экосистеме Adobe (Acrobat Pro, Creative Cloud), смена на DocuSign создаёт дополнительные расходы и переобучение.

Что умеет кастомная интеграция

Отправка на подпись по триггеру:
— Менеджер переводит сделку на этап «Согласование договора»
— Kommo Digital Pipeline вызывает backend через webhook
— Backend читает поля сделки: имя клиента, сумму, условия, реквизиты
— Создаёт Adobe Sign Agreement из шаблона через POST /agreements
— Подставляет поля через merge fields шаблона (Adobe Sign поддерживает {{field_name}})
— Записывает Agreement ID и ссылку для подписания в карточку Kommo
— Отправляет клиенту письмо от Adobe Sign с ссылкой (нативно через Adobe Sign)

Синхронизация статуса:
— Adobe Sign отправляет webhook при каждом изменении статуса Agreement
— AGREEMENT_ACTION_COMPLETED -> статус в Kommo: «Подписан», дата подписания
— AGREEMENT_ACTION_DECLINED -> задача менеджеру: «Клиент отказался подписывать»
— AGREEMENT_EXPIRED -> задача: «Срок подписания истёк, нужно переотправить»
— Опционально: при полном подписании — автоматический перевод сделки на следующий этап

Скачивание подписанного документа:
— После AGREEMENT_ACTION_COMPLETED backend скачивает PDF через GET /agreements/{id}/combinedDocument
— Загружает в Kommo как вложение к сделке (POST /api/v4/leads/{id}/files)
— Менеджер видит подписанный договор прямо в карточке

Работа с шаблонами Adobe Sign

Adobe Sign поддерживает два подхода к шаблонизации:

Library Templates — готовые документы в Adobe Sign с merge fields. При создании Agreement из шаблона передаёте значения полей:

{
  "fileInfos": [{ "libraryDocumentId": "TEMPLATE_ID" }],
  "participantSetsInfo": [{
    "role": "SIGNER",
    "memberInfos": [{ "email": "client@example.com", "name": "Иван Иванов" }]
  }],
  "mergeFieldInfo": [
    { "fieldName": "client_name", "defaultValue": "Иван Иванов" },
    { "fieldName": "deal_amount", "defaultValue": "15000" },
    { "fieldName": "contract_date", "defaultValue": "05.05.2026" }
  ],
  "name": "Договор #123 - Иван Иванов",
  "state": "IN_PROCESS"
}

Transient Document — загружаете готовый PDF (сгенерированный на лету из шаблона Word/DOCX через python-docx или WeasyPrint) и подписываете его. Этот подход даёт полный контроль над документом, но требует генерации PDF на стороне backend.

Для большинства случаев Library Templates достаточно и проще в поддержке: юридическая команда правит шаблон в Adobe Sign, разработчик не трогает код.

Несколько подписантов

Adobe Sign поддерживает последовательное и параллельное подписание:

"participantSetsInfo": [
  {
    "order": 1,
    "role": "SIGNER",
    "memberInfos": [{ "email": "client@example.com" }]
  },
  {
    "order": 2,
    "role": "SIGNER",
    "memberInfos": [{ "email": "ceo@yourcompany.com" }]
  }
]

При последовательном подписании: сначала подписывает клиент, потом документ уходит вашему CEO. Webhook AGREEMENT_ACTION_COMPLETED приходит только после подписания всеми участниками.

Для Kommo это означает: статус «Подписан» в карточке появляется только когда все подписи собраны. Промежуточный статус (подписан клиентом, ждём вашей подписи) можно фиксировать через AGREEMENT_SIGNER_COMPLETED event.

Сравнение с DocuSign и PandaDoc

Если у компании нет жёсткой привязки к Adobe — интеграция Kommo и DocuSign или Kommo и PandaDoc дают те же возможности с готовым marketplace-коннектором и меньшими затратами на разработку.

Adobe Sign оправдан если: компания уже платит за Adobe Acrobat Pro или Creative Cloud (Adobe Sign включён), или если юридический отдел требует именно Adobe Sign по корпоративному стандарту.

Реальный кейс

В проекте для консалтинговой компании (10 менеджеров, договоры от $5,000):
— Использовался Adobe Sign по корпоративному стандарту клиента
— До интеграции: подготовка и отправка договора — 15–20 минут на менеджера, 3–5 договоров в день
— После: менеджер переводит в «Согласование» -> договор уходит автоматически через 30 секунд
— Подписанный PDF появляется в карточке Kommo без действий менеджера
— Экономия: ~1 час в день на команду только на документообороте

Для кого актуально

Кастомная интеграция Kommo + Adobe Sign имеет смысл если:
— Компания использует Adobe Sign по корпоративному стандарту (не хочет менять на DocuSign)
— Договоры содержат данные из CRM-полей (имя, сумма, условия, реквизиты)
— Важно видеть статус подписания в карточке без захода в Adobe Sign
— Используются многосторонние договоры (несколько подписантов)

Подробнее о кастомных интеграциях для Kommo CRM — что ещё можно автоматизировать через API.

Часто задаваемые вопросы

Adobe Sign хранит подписанные документы надёжно?

Да. Adobe Sign хранит все документы в зашифрованном виде в облаке Adobe с audit trail — временной меткой каждого действия, IP-адресом, email подписанта. Это соответствует eIDAS (Европа), ESIGN Act (США), имеет юридическую силу в большинстве юрисдикций. Подписанный PDF скачивается через API и дополнительно хранится в Kommo как вложение.

Сколько занимает разработка интеграции?

Базовая интеграция (отправка по триггеру + обновление статуса) — 2–3 недели. Расширенная (несколько подписантов, генерация PDF из шаблона Word, скачивание в Kommo) — 4–5 недель. Срок зависит от сложности шаблонов документов и количества полей для подстановки.

Можно ли использовать несколько шаблонов в зависимости от типа сделки?

Да. Backend читает из сделки кастомное поле «Тип договора» и выбирает соответствующий Library Template ID в Adobe Sign. Один webhook-handler, несколько шаблонов — логика выбора на стороне backend.

Что если клиент потерял письмо от Adobe Sign?

Adobe Sign API позволяет отправить напоминание: POST /agreements/{id}/reminders. В кастомной интеграции это можно автоматизировать: если через 3 дня статус не изменился — backend отправляет напоминание и ставит задачу менеджеру.

Итого

• Нативной интеграции Kommo + Adobe Sign нет; marketplace-коннектор отсутствует
• Кастомная интеграция: Library Template + merge fields из полей Kommo + webhook для статуса
• Подписанный PDF автоматически сохраняется в карточке сделки
• Если нет привязки к Adobe — DocuSign или PandaDoc с готовым Kommo-коннектором проще
• Типовой срок разработки — 2–4 недели

Если вы используете Adobe Sign и ведёте сделки в Kommo — опишите схему документооборота. Exceltic.dev оценит сложность и предложит конкретный план.