Интеграция CRM и таск-трекера: заявка превращается в задачу без ручного переноса

Интеграция CRM и таск-трекера строится на событиях: смена этапа сделки в CRM отправляет вебхук, сервис-посредник создаёт проект и задачи в трекере через API и возвращает ссылку в сделку. Для каждого поля назначается одна система-источник, каждое событие пишется в журнал, неудачные запросы повторяются. Так выигранная сделка становится проектом без ручного переноса, а продажи видят статус работ без вопросов в чате.

Статья для технических директоров, руководителей проектных офисов и тимлидов IT-компаний и студий, которые устали переносить заявки из CRM в Jira или Plane вручную. Внутри схема событий, маппинг полей, возможности API и вебхуков Twenty, Plane, amoCRM и Jira, обработка ошибок, выбор владельца и чек-лист запуска.

Зачем связывать CRM и таск-трекер

В большинстве IT-компаний между продажами и производством стоит человек. Менеджер выиграл сделку, написал в общий чат, проектный менеджер завёл проект в трекере, скопировал куски предложения и попросил контакты клиента. Через месяц продажи спрашивают, на каком этапе проект, а производство уточняет, что именно было обещано.

Интеграция убирает ручной перенос и создаёт сквозную связь. В карточке сделки есть ссылка на проект и его статус, в проекте — ссылка на сделку и вся коммерческая история. Это особенно важно для студий и аутсорс-команд, где одна компания-клиент может иметь несколько проектов, допродажи и поддержку.

Интеграция не заменяет процесс. Если в CRM нет понятной воронки и критериев этапов, автоматика будет создавать проекты из случайных сделок. Сначала наведите порядок в продажах, как описано в статье о внедрении CRM в IT-компании, потом связывайте системы.

Схема событий

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

Событие	Действие	Источник	Приёмник
Сделка переходит в этап «Оценка»	Создать задачу на оценку для техлида со ссылкой на сделку	CRM	Таск-трекер
Задача на оценку закрыта	Записать оценку и комментарий в сделку	Таск-трекер	CRM
Сделка переходит в «Выиграна»	Создать проект из шаблона, этапы и стартовые задачи	CRM	Таск-трекер
Проект создан	Записать ссылку на проект в сделку	Таск-трекер	CRM
Изменена плановая дата старта в сделке	Обновить дату в проекте и уведомить менеджера проекта	CRM	Таск-трекер
Проект переходит в статус «Завершён»	Отметить сделку, создать задачу менеджеру на допродажу поддержки	Таск-трекер	CRM
Сделка проиграна после оценки	Закрыть задачу на оценку с причиной	CRM	Таск-трекер

Для старта хватает двух-трёх строк: «Выиграна → проект», «проект создан → ссылка в CRM» и «проект завершён → отметка в CRM». Остальное добавляется после первого месяца работы.

Путь одного события по шагам

Разберём главный сценарий на связке Twenty и Plane.

1. Менеджер переводит сделку в этап «Выиграна». Twenty отправляет вебхук с идентификатором сделки.
2. Сервис-посредник проверяет подпись запроса и записывает событие в журнал.
3. Сервис смотрит в таблицу соответствия. Если проект для этой сделки уже есть, событие помечается как повтор и обработка заканчивается.
4. Сервис запрашивает через API Twenty полные данные сделки: компанию, тип работ, контакт, плановую дату старта, ссылку на предложение.
5. По типу работ выбирается шаблон, и через API Plane создаются проект и стартовые задачи: онбординг клиента, kick-off, доступы, первая итерация.
6. Идентификатор проекта сохраняется в таблице соответствия, а ссылка на проект записывается в сделку через API Twenty.
7. Менеджер проекта получает уведомление, а в журнале событие отмечается как успешно обработанное.

Если на любом шаге API вернуло ошибку, событие уходит в повтор, а не теряется. Тот же порядок работает для amoCRM и Jira: меняются только вызовы API.

Какие поля синхронизировать

Главное правило: у каждого поля одна система-источник. Коммерческие данные живут в CRM, рабочие — в трекере. Если поле можно править в обеих системах, рано или поздно они разойдутся.

Поле	Источник	Куда передаётся	Комментарий
Название клиента	CRM	Трекер	В название проекта или отдельное поле
Ссылка на сделку	CRM	Трекер	Обязательно, это главный якорь
Тип работ	CRM	Трекер	Определяет шаблон проекта
Объём работ или ссылка на предложение	CRM	Трекер	Лучше ссылкой на документ, чем текстом
Плановая дата старта	CRM	Трекер	Менять только в CRM
Менеджер по продажам	CRM	Трекер	Как наблюдатель проекта
Ссылка на проект	Трекер	CRM	Записывается после создания
Статус проекта	Трекер	CRM	Только итоговые статусы, не каждая задача
Сумма сделки	CRM	Не передаётся	Без необходимости в трекер не нужна

Сумму сделки и персональные данные контактов без необходимости в трекер не передавайте. Проектной команде обычно достаточно имени и роли контактного лица, а полная карточка доступна по ссылке на сделку тем, у кого есть права в CRM.

API и вебхуки: что дают системы

Все четыре системы, с которыми мы работаем чаще всего, умеют отдавать события и принимать данные. Отличаются детали.

Twenty

Twenty открыта и строится вокруг API: любую запись можно создать, прочитать и изменить извне, а на события подписаться через вебхуки. Встроенные воркфлоу умеют реагировать на изменения записей и отправлять HTTP-запросы. Для сложной логики у Twenty есть фреймворк приложений, где серверные функции пишутся на TypeScript.

Plane

У Plane есть публичный API и вебхуки, а также встроенные Automations и Runner для запланированных действий. В 2026 году появились MCP-коннекторы и AI-агенты внутри рабочего пространства. Для интеграции с CRM обычно хватает API для создания проектов и задач и вебхуков на смену статуса. Конкретный набор событий сверяйте с документацией разработчика для вашей версии, особенно если Plane развёрнут self-hosted.

amoCRM

amoCRM отдаёт вебхуки на события сделок и контактов и предоставляет API для чтения и записи. Это стандартный путь для связки с внешними системами, и казахстанские интеграторы хорошо его знают.

Jira

Jira принимает данные через REST API, а Jira Automation умеет запускать правила по входящему вебхуку и отправлять веб-запросы. Простые сценарии можно собрать прямо в Automation, сложные лучше вынести в отдельный сервис.

Комбинации Twenty с Plane и amoCRM с Jira встречаются чаще всего, но схема одинакова для любых пар. Если вы ещё выбираете трекер, посмотрите наше сравнение Plane и Jira.

Архитектура: напрямую или через посредника

Есть три способа связать системы.

Напрямую через встроенные автоматизации. Воркфлоу в CRM отправляет запрос в API трекера. Быстро и без отдельного сервера. Минусы: логику повторов и ошибок сложно контролировать, а сопоставление идентификаторов хранить негде.

Через облачный no-code-коннектор. Удобно для прототипа. Но данные проходят через ещё одного вендора, и обычно за пределами Казахстана.

Через собственный сервис-посредник. Небольшое приложение, которое принимает вебхуки, хранит таблицу соответствия идентификаторов, вызывает API, ведёт журнал и повторяет неудачные запросы. Это наш выбор по умолчанию для production-интеграций: код в репозитории, логика прозрачна, хостинг там же, где CRM и трекер.

Контекст Казахстана. Если Twenty и Plane развёрнуты self-hosted на серверах в Казахстане, чтобы данные оставались в стране, интеграция не должна выводить эти данные за рубеж. Облачный коннектор, через который проходят имена, телефоны и почты контактов, может свести на нет смысл локального хостинга. Сервис-посредник лучше разместить у того же казахстанского хостера и передавать в трекер минимум персональных данных.

Ошибки, повторы и идемпотентность

Интеграция, которая работает в демо, и интеграция, которая работает год, отличаются обработкой ошибок. Что нужно предусмотреть:

• Идемпотентность. Один и тот же вебхук может прийти дважды. Перед созданием проекта сервис проверяет по таблице соответствия, не создан ли он уже для этой сделки.
• Повторы с паузой. Если API трекера недоступно или вернуло ошибку лимита, запрос повторяется через увеличивающиеся интервалы.
• Очередь неудачных событий. После нескольких неудачных попыток событие откладывается в отдельную очередь, а владелец получает уведомление.
• Журнал. Каждое событие пишется с временем, источником, результатом и ответом API. Без журнала разбор инцидента превращается в гадание.
• Проверка подлинности вебхуков. Сервис принимает запросы только с секретом или подписью, иначе любой может создать проект в вашем трекере.
• Технические пользователи. Отдельный API-ключ для интеграции в каждой системе. Видно, что изменила автоматика, и ключ легко отозвать.
• Ручной перезапуск. Возможность повторно обработать конкретное событие из журнала без правки базы.

Владелец интеграции

У интеграции должен быть один владелец. Не «IT-отдел», а конкретный человек, который получает уведомления об ошибках, разбирает очередь неудачных событий, согласует изменения полей в обеих системах и обновляет сервис. Обычно это инженер внутренних систем или технический владелец CRM. Если интеграцию делал подрядчик, договоритесь заранее, кто будет её владельцем после сдачи, и получите код, доступы и описание событий.

Самая частая причина поломок — не сбой API, а изменение структуры. Кто-то переименовал этап сделки в CRM или удалил поле в трекере, и сопоставление перестало работать. Поэтому правило простое: любые изменения полей и этапов, участвующих в интеграции, согласуются с её владельцем.

Чек-лист запуска

1. Составлена таблица событий, и для старта выбраны два-три ключевых.
2. Для каждого синхронизируемого поля определена система-источник.
3. Созданы технические пользователи и API-ключи в CRM и трекере.
4. Сервис-посредник хранит таблицу соответствия идентификаторов.
5. Настроены повторы, очередь неудачных событий и уведомления.
6. Вебхуки проверяются по секрету или подписи.
7. Интеграция проверена на тестовых сделках, включая дубли вебхуков и недоступность API.
8. Персональные данные в трекер передаются по минимуму, интеграция не выводит их за пределы выбранного хостинга.
9. Назначен владелец, и команда знает, к кому идти при сбое.
10. Описано, как менять поля и этапы, участвующие в интеграции.

Как мы это делаем

Мы начинаем с диагностики: как сейчас сделка попадает в производство, где теряется информация, какие системы уже стоят и где хранятся данные. Затем запускаем пилот на одном сценарии — обычно «сделка выиграна → проект в трекере» — с одной командой продаж и одним проектным офисом. Когда сценарий отработал на реальных сделках, добавляем остальные события и передаём интеграцию владельцу вместе с документацией.

Подробнее о подходе — на странице внедрения CRM Twenty и amoCRM.

---

Источники. Twenty: twenty.com и github.com/twentyhq/twenty. Plane: github.com/makeplane/plane и plane.so/pricing. amoCRM: amocrm.ru.

Термины простыми словами

Вебхук

Сообщение, которое CRM сама отправляет другой системе в момент события, например при переходе сделки в «Выиграна». С него начинается цепочка создания проекта.

API

Интерфейс, через который программа читает и записывает данные в CRM или трекере без ручной работы. Через API сервис-посредник создаёт проект и задачи.

Сервис-посредник

Небольшое отдельное приложение между CRM и трекером: принимает вебхуки, вызывает API, ведёт журнал и повторяет неудачные запросы. Его размещают у того же хостера, что и системы.

Маппинг полей

Таблица соответствия: какое поле CRM в какое поле трекера переходит и какая система для него главная. Без неё данные в двух системах со временем расходятся.

Идемпотентность

Защита от двойной обработки: если одно событие пришло дважды, второй проект не создаётся. Сервис сверяется с таблицей соответствия, был ли проект уже заведён.

Очередь неудачных событий

Место, куда откладываются события, которые не удалось обработать после нескольких попыток. Владелец интеграции получает уведомление и разбирает их вручную.

No-code-коннектор

Облачный сервис, где интеграцию собирают без программирования. Удобен для прототипа, но данные клиентов проходят через ещё одного поставщика, обычно за пределами Казахстана.

Self-hosted

Установка CRM или трекера на собственном сервере, например у казахстанского хостера. Если системы стоят так ради хранения данных в РК, интеграция не должна выводить данные за рубеж.