Нативная интеграция HubSpot и Slack работает - но создаёт ровно одну проблему: через неделю менеджеры отключают уведомления, потому что #sales превращается в лог-файл. Ниже - что именно не так с нативным подходом, какие паттерны реально работают, и как собрать схему webhook -> Slack API с условным роутингом и Block Kit-форматированием.
Почему нативная интеграция - это антипаттерн при масштабе
HubSpot App Marketplace предоставляет официальное приложение Slack. Оно подключается за 5 минут и начинает слать уведомления: новые сделки, смена стадии, задачи. На команде из 3 менеджеров и 20 сделок в месяц - нормально. На команде из 12 менеджеров, 4 сегментах клиентов и 200+ активных сделках - это катастрофа.
Типичная картина через 2-3 недели после подключения:
- Канал #sales получает 150-300 уведомлений в день
- 80% из них нерелевантны конкретному менеджеру (чужие сделки, мелкие обновления, технические изменения полей)
- Менеджеры отключают Slack-уведомления или мьютят канал
- Критические события (крупная сделка сдвинулась в «Negotiation», горячий лид завис без активности) теряются в потоке
Решение не в том, чтобы меньше уведомлять - а в том, чтобы уведомлять правильно: нужного человека, в нужный канал, с нужным контекстом.
Что умеет нативная интеграция (и где потолок)
Приложение HubSpot для Slack, по данным официальной документации HubSpot, поддерживает:
- Уведомления о событиях через HubSpot Workflows (создание сделки, смена Deal Stage, новый контакт)
- Поиск по HubSpot-объектам через slash-команду
/hubspot [запрос] - Базовое создание задач из Slack (
/hubspot task create) - без привязки к объектам CRM - Action Buttons в уведомлениях: создать задачу, залогировать активность, обновить свойство (доступно в части уведомлений)
Потолок нативной интеграции - это её архитектурное ограничение: уведомление отправляется в один заранее сконфигурированный канал. Нативно нет:
- Условного роутинга по атрибутам сделки (сумма, ICP-сегмент, geography, стадия)
- Block Kit-форматирования с произвольными полями и кнопками
- DM конкретному ответственному менеджеру по событию
- Дедупликации (одно и то же событие не триггернёт несколько уведомлений)
- Учёта рабочих часов по таймзоне менеджера
При настройке через HubSpot Workflows можно создать несколько workflow с разными условиями - каждый отправляет уведомление в свой канал. Это работает, но быстро становится неуправляемым: для 5-6 условий роутинга нужно 5-6 отдельных Workflow, которые потом сложно поддерживать и отлаживать.
Что не работает без кастомной схемы
Условная маршрутизация по ICP, сумме и стадии
Практический сценарий: компания работает с тремя сегментами - Enterprise (сделки от $50k), Mid-Market ($10k-50k) и SMB (до $10k). Логика уведомлений принципиально разная:
- Enterprise: любое движение сделки - в #enterprise-deals, DM аккаунт-менеджеру и VP Sales
- Mid-Market: уведомление при смене стадии в «Proposal Sent» и «Negotiation» - в #midmarket-pipeline
- SMB: только при закрытии (Closed Won / Closed Lost) - в #smb-results
Нативная интеграция с этим не справляется. HubSpot Workflows позволяют добавить условия (if Deal Amount > 50000), но полноценную многоуровневую маршрутизацию с динамическим выбором канала реализовать не получится - это не тот инструмент.
Форматированные сообщения с Block Kit
Нативное уведомление выглядит примерно так:
New deal stage: Acme Corp -> NegotiationЭто текст без контекста. Менеджер не видит сумму, не знает кто ответственный, нет ссылки на сделку в HubSpot, нет кнопки для быстрого действия.
Slack Block Kit - это JSON-формат для структурированных сообщений с секциями, полями, кнопками и изображениями. Уведомление на Block Kit выглядит принципиально иначе: заголовок со стадией, блок с суммой и ответственным, прямая ссылка на сделку в HubSpot, кнопки «Назначить встречу» и «Создать задачу». Менеджер видит весь контекст и может среагировать прямо из Slack.
Пример Block Kit payload для уведомления о сделке:
{
"blocks": [
{
"type": "header",
"text": {
"type": "plain_text",
"text": "Сделка перешла в Negotiation"
}
},
{
"type": "section",
"fields": [
{ "type": "mrkdwn", "text": "*Компания:*\nAcme Corp" },
{ "type": "mrkdwn", "text": "*Сумма:*\n$85,000" },
{ "type": "mrkdwn", "text": "*Ответственный:*\n@john" },
{ "type": "mrkdwn", "text": "*Стадия:*\nNegotiation" }
]
},
{
"type": "actions",
"elements": [
{
"type": "button",
"text": { "type": "plain_text", "text": "Открыть в HubSpot" },
"url": "https://app.hubspot.com/contacts/PORTAL_ID/deal/DEAL_ID",
"style": "primary"
},
{
"type": "button",
"text": { "type": "plain_text", "text": "Создать задачу" },
"action_id": "create_task",
"value": "DEAL_ID"
}
]
}
]
}Двусторонняя реакция на сделку из Slack
Одностороннее уведомление (HubSpot -> Slack) - это половина ценности. Реальная экономия времени - когда менеджер может среагировать прямо в Slack без открытия CRM.
Нативная интеграция поддерживает ограниченный набор Action Buttons, но привязка к конкретному объекту CRM работает непредсказуемо. Для полноценного двустороннего взаимодействия нужна кастомная Slack App с обработчиком action-коллбэков: нажатие кнопки «Создать задачу» в Slack-сообщении -> backend обрабатывает action -> создаёт Task в HubSpot через API с привязкой к нужной сделке.
Дедупликация уведомлений
HubSpot может тригернуть несколько событий за короткое время: менеджер обновил 3 поля в сделке - в Slack прилетит 3 уведомления за 30 секунд. Нативная интеграция не умеет группировать события.
Кастомная схема решает это через буферизацию с таймаутом: первое событие по сделке запускает таймер (30-60 секунд), все следующие события за это время группируются, затем отправляется одно сводное уведомление.
Кастомная схема: webhook + Slack API
Архитектура: HubSpot Webhook -> backend-сервис -> Slack API.
Шаг 1: настройка HubSpot Webhook
HubSpot поддерживает webhooks через HubSpot Webhooks API. Настройка через Settings -> Integrations -> Private Apps -> создать Private App с правами на объекты CRM, затем в Webhooks указать URL backend-сервиса и типы событий (deal.stageChange, deal.creation, deal.propertyChange).
HubSpot отправляет POST-запрос на указанный URL при каждом событии. Payload содержит objectId (ID сделки), propertyName, propertyValue, changeSource.
Шаг 2: backend-логика роутинга
При получении события backend обогащает данные: запрашивает сделку через HubSpot CRM API (нужны сумма, ответственный, ICP-сегмент, стадия), применяет правила роутинга и отправляет форматированное сообщение в Slack:
def route_deal_notification(deal: dict) -> str:
amount = float(deal.get('amount', 0) or 0)
segment = deal.get('hs_custom_segment', '')
if amount >= 50000 or segment == 'enterprise':
return '#enterprise-deals'
elif amount >= 10000:
return '#midmarket-pipeline'
else:
return '#smb-results'
def build_slack_payload(deal: dict, event_type: str) -> dict:
return {
'channel': route_deal_notification(deal),
'blocks': build_block_kit_blocks(deal, event_type)
}Шаг 3: маппинг HubSpot owner -> Slack user ID
Для DM-уведомлений нужно сопоставить HubSpot owner ID с Slack user ID. Это делается один раз через небольшой конфигурационный файл или таблицу в БД. Slack API принимает user ID как channel в chat.postMessage - это и есть DM.
Шаг 4: Slack App с обработчиком actions
Для двустороннего взаимодействия (кнопки в Block Kit) нужна Slack App с Interactivity URL - endpoint, который Slack вызывает при нажатии кнопки. Backend обрабатывает action, вызывает HubSpot API и подтверждает выполнение через respond() прямо в Slack-треде.
Весь стек: Python или Node.js сервис (Firebase Functions / AWS Lambda / Railway), HubSpot Private App, Slack App с Bot Token и scopes chat:write, im:write, channels:join.
Реальный кейс
SaaS-компания, B2B, 14 менеджеров в 3 странах, HubSpot Sales Hub Professional. До кастомной интеграции: нативное приложение HubSpot + Slack, один канал #deals, 180-250 уведомлений в день. Через 3 недели 11 из 14 менеджеров отключили уведомления канала. Несколько Enterprise-сделок на стадии Negotiation оставались без реакции 24-48 часов, потому что уведомления тонули в потоке.
После кастомной схемы:
- Роутинг по 4 каналам: #enterprise (от $50k), #midmarket ($10k-50k), #smb (до $10k), #deals-won (все закрытые)
- DM ответственному при зависании сделки без активности более 5 дней
- Block Kit с суммой, стадией, следующим шагом и кнопкой «Открыть в HubSpot»
- Уведомления только в рабочие часы по таймзоне менеджера (9:00-19:00)
- Дедупликация: несколько изменений в течение 60 секунд - одно сводное сообщение
Результат через месяц: 15-25 уведомлений в день на канал #enterprise (вместо 200+ во всё), все менеджеры вернули уведомления, среднее время реакции на Enterprise-событие снизилось с 18 часов до 2 часов.
Подробнее о том, как автоматизировать AI-саммари звонков в контакт HubSpot, описано в статье про HubSpot AI summary звонков.
Для кого это актуально
Кастомная схема HubSpot Webhook + Slack API оправдана если:
- Команда продаж от 6-8 менеджеров и выше
- Есть несколько сегментов сделок с разными приоритетами (Enterprise vs SMB)
- Менеджеры работают в разных часовых поясах
- Нативные уведомления уже отключены или игнорируются
- Важна скорость реакции на Enterprise-события (часы, не дни)
Если команда маленькая и пайплайн однородный - нативная интеграция через HubSpot Workflows с несколькими условными ветками закроет большинство потребностей. Для сравнения с альтернативными CRM-платформами и подходами к уведомлениям - обзор Kommo CRM показывает другую модель работы с мессенджерами.
Если нужна кастомная схема - Exceltic.dev проектирует и реализует интеграции HubSpot с Slack: роутинг по условиям, Block Kit, двустороннее взаимодействие, дедупликация.
Часто задаваемые вопросы
Можно ли настроить условный роутинг полностью через HubSpot Workflows без кода?
Частично. Для 2-3 условий (например, сумма выше порога -> другой канал) это реализуемо через несколько Workflows с разными триггерами и действиями. При 5+ условиях или динамическом роутинге по кастомным свойствам - Workflow-подход становится неуправляемым: каждое изменение логики требует редактирования нескольких Workflow одновременно.
Что такое Block Kit и нужен ли он?
Block Kit - это система форматирования сообщений в Slack через JSON-блоки: секции, поля, кнопки, изображения. Официальная документация: api.slack.com/block-kit. Без Block Kit уведомление - это строка текста. С Block Kit - структурированная карточка сделки с кнопками действий. Для информационных уведомлений Block Kit необязателен. Для двустороннего взаимодействия (кнопки) - обязателен.
Нативная интеграция HubSpot + Slack поддерживает Action Buttons - этого не достаточно?
Нативные Action Buttons (создать задачу, залогировать активность) появились в 2024-2025 году и работают для базовых сценариев. Ограничение: действие не всегда привязывается к конкретной сделке из уведомления, нет возможности добавить кастомные кнопки с произвольными action_id, нет возможности программно обработать нажатие и выполнить логику на стороне backend.
Сколько занимает реализация кастомной интеграции?
Типовой проект включает: HubSpot Private App и настройку Webhooks, backend-сервис с роутингом и дедупликацией, Slack App с Block Kit и обработчиком actions, маппинг owner -> Slack user ID. Обычно 2-3 недели. Поддержка и расширение логики роутинга после запуска - минимальная.
Как обеспечить надёжность доставки уведомлений?
HubSpot Webhooks имеют retry-механизм: если endpoint вернул не 200, HubSpot повторяет запрос несколько раз. На стороне backend важно: отвечать 200 немедленно (не ждать Slack API), обрабатывать событие асинхронно, хранить идентификаторы обработанных событий для идемпотентности (чтобы повторный retry не создал дублирующее уведомление).
Нативная HubSpot + Slack интеграция - хорошая точка старта, но при росте команды и пайплайна она превращается в источник шума. Кастомная схема на webhook + Slack API решает это на уровне архитектуры: правильный сигнал, правильному человеку, в правильное время. Если это описывает вашу ситуацию - опишите логику уведомлений, Exceltic.dev разберёт условия роутинга.