GPT-саммари звонков и писем пишутся в карточку контакта HubSpot не нативной “AI”, а связкой из трёх элементов: триггер на завершённую активность через workflow-webhook, вызов OpenAI на транскрипте, и запись результата в кастомное property или на timeline через CRM API. Нативного механизма, который читает транскрипт звонка и сам кладёт структурированное саммари в нужное поле контакта, в HubSpot нет - и именно поэтому это решается кодом, а не настройкой.
В Exceltic.dev такие сборки мы делаем под команды, где менеджеры физически перестали писать итоги после звонков. Закономерность одна и та же: чем больше звонков в день, тем короче или вообще пустее заметка в карточке. К концу квартала half воронки - это контакты, по которым никто не помнит, о чём договаривались. AI-саммари не “улучшает” процесс, оно его закрывает: итог появляется в карточке автоматически в момент завершения звонка, без участия менеджера.
Почему нативного AI-саммари в HubSpot не хватает
У HubSpot есть AI-функции вокруг звонков: транскрипция, выделение ключевых моментов в интерфейсе записи. Проблема в том, где это живёт и в каком виде. Нативные insights привязаны к экрану записи звонка и к conversation intelligence, а не к property контакта или сделки. Их нельзя надёжно вытащить в нужное поле, отфильтровать по ним в списках, использовать в workflow как условие или показать менеджеру в самом верху карточки в одну строку.
Второе ограничение - формат. Нативное саммари отвечает на вопрос “что было сказано”, а команде продаж нужен ответ на вопрос “что делать дальше”: договорённость, следующий шаг, возражение, бюджет, дата. Это не транскрипт и не пересказ, это извлечение полей. Языковая модель с заданным промптом и схемой выдаёт ровно такую структуру; нативный движок - нет.
Третье - язык и тон. Команды, которые работают на нескольких рынках, хотят саммари на русском, даже если звонок был на английском, и в своём формате. Нативные функции этого уровня контроля не дают.
То же касается писем. Длинная переписка из десяти сообщений - это контекст, который новый менеджер на сделке читать не будет. Саммари треда в одно поле контакта решает проблему передачи дел между людьми. Это близкая по природе задача к тому, что мы разбирали в материале про транскрипты встреч в карточку, только источник здесь - сам HubSpot.
Что реализуется
Сборка состоит из четырёх частей: триггер на завершённую активность, получение транскрипта или текста письма, вызов OpenAI и запись результата обратно в HubSpot. Разберём технические детали каждой.
Триггер: workflow-webhook, а не Webhooks API
Здесь первая ловушка, на которой спотыкаются самодельные сборки. Webhooks API в HubSpot не поддерживает подписку на engagements - звонки, заметки, письма, встречи и задачи. Подписаться напрямую на событие “звонок завершён” через стандартный webhook subscription нельзя.
Рабочий путь - workflow с webhook action. В contact-based или deal-based workflow ставится триггер по активности (например, “logged call” с заполненным транскриптом), а на выходе - webhook на ваш сервис с ID звонка и контакта. Webhook action в workflow требует Operations Hub Professional или Enterprise. Это бюджетное ограничение, которое надо знать до старта, а не после.
Альтернатива без Operations Hub - polling: ваш сервис периодически запрашивает свежие звонки через CRM API и обрабатывает новые. Дешевле по лицензии, дороже по задержке и сложнее по идемпотентности.
Получение транскрипта
Для звонков транскрипт берётся через Recordings & Transcripts API. Записи и транскрипты в HubSpot отдаются по аутентифицированным URL, и есть отдельный endpoint, которым интеграция отмечает запись как готовую к транскрибации. Если телефония внешняя (Aircall, RingCentral и подобные), транскрипт может приходить от неё - тогда OpenAI получает текст напрямую, минуя транскрипцию HubSpot.
Для писем текст треда читается через CRM API по engagement письма, связанному с контактом.
Вызов OpenAI
Транскрипт уходит в Chat Completions с системным промптом, который задаёт не пересказ, а извлечение полей. Модель по умолчанию - gpt-4o-mini: на summarization она справляется, а стоит несоизмеримо дешевле старших моделей. Тарификация по токенам: примерно $0.15 за 1M входных токенов и $0.60 за 1M выходных (актуальные цифры всегда сверять в прайсинге OpenAI).
Чтобы оценить порядок: средний 20-минутный звонок - это около 3-4 тысяч токенов транскрипта. Саммари на выходе - 200-400 токенов. Один звонок обходится в доли цента. Даже сотня звонков в день - это единицы долларов в месяц на модель.
Ключевое - structured output. Промпт просит вернуть JSON с фиксированными полями: краткий итог, следующий шаг, возражения, упомянутый бюджет, дата следующего контакта. Свободный текст модели нельзя писать в типизированное property HubSpot без потери смысла - поэтому JSON парсится, и каждое поле кладётся в своё место.
Запись обратно в HubSpot
Заранее, один раз, создаётся кастомное property через POST /crm/v3/properties/contacts с авторизацией Bearer <private-app-token>. Тип - string с fieldType: textarea для самого саммари, отдельные property для “следующего шага” и “даты”. После каждого звонка результат пишется через PATCH /crm/v3/objects/contacts/{id} в эти поля.
Если саммари должно быть видно в ленте активности, а не только в свойствах, оно дополнительно записывается на timeline как note-engagement, привязанный к контакту и сделке. Два варианта не взаимоисключающие: property - для фильтрации и workflow, note на timeline - для чтения в контексте истории.
Privacy и идемпотентность
Два вопроса, которые в продакшене решают всё.
Privacy: транскрипт звонка уходит на сторонний сервис (OpenAI). Для команд в EU это вопрос GDPR и data processing agreement. У OpenAI есть условия, по которым данные API не используются для обучения, и опции data residency - но это надо закрыть на уровне договора и зафиксировать в политике, а не предполагать. Если данные нельзя выпускать наружу вообще - вариант self-hosted модели, но это другой бюджет.
Идемпотентность: один звонок не должен породить два саммари при ретрае webhook или повторном polling. Решается ключом дедупликации - ID звонка пишется в служебное property или в локальную базу, и повторная обработка того же ID пропускается. Без этого при любом сбое сети карточка получит дубль.
Как это работает пошагово
- Менеджер завершает звонок в HubSpot, транскрипт появляется на записи.
- Workflow ловит событие “logged call” и шлёт webhook на ваш сервис с ID звонка и контакта.
- Сервис проверяет ID по ключу дедупликации - если уже обработан, выходит.
- Сервис тянет транскрипт через Recordings & Transcripts API.
- Транскрипт уходит в OpenAI Chat Completions с промптом на извлечение структуры.
- Модель возвращает JSON: итог, следующий шаг, возражения, бюджет, дата.
- Сервис парсит JSON и пишет поля через
PATCHв кастомные property контакта. - Опционально - создаёт note-engagement на timeline для чтения в ленте.
- ID звонка помечается как обработанный.
Вся цепочка от завершения звонка до появления саммари в карточке - секунды. Менеджер открывает контакт через минуту и видит готовый итог.
Реальный кейс с цифрами
B2B-команда на HubSpot, 6 sales-менеджеров, около 70 исходящих и входящих звонков в день суммарно. До внедрения заметка после звонка заполнялась примерно в 35% случаев, и то одной строкой. Передача контакта между менеджерами означала прослушивание записей вручную - 15-20 минут на контакт.
После внедрения AI-саммари:
- Заполнение итога по звонкам - 100%, потому что не зависит от человека.
- Поле “следующий шаг” заполнено по каждому контакту - на нём построили workflow напоминаний.
- Время на передачу контакта между менеджерами упало с 15-20 минут до 1-2 минут чтения.
- Стоимость модели - около $9 в месяц при 70 звонках в день на
gpt-4o-mini.
Главный эффект оказался не в экономии минут, а в том, что head of sales впервые смог фильтровать воронку по содержанию звонков - находить все сделки, где упоминалось конкретное возражение или конкурент, через стандартный фильтр по property. Раньше эта информация существовала только в головах менеджеров.
Для кого подходит
Это решение оправдано, если:
- Команда делает десятки звонков в день и заметки страдают первыми.
- Контакты передаются между менеджерами, и контекст теряется.
- Нужна фильтрация и автоматизация по содержанию разговоров, а не только по факту звонка.
- Есть Operations Hub Pro/Enterprise (для workflow-webhook) или готовность к polling-варианту.
Это избыточно, если звонков единицы в неделю, или если команда дисциплинированно пишет итоги сама. Технология не лечит процесс, в котором проблемы нет.
Если вы только выбираете, на какой CRM строить такие сборки, и сравниваете подходы, полезен будет наш обзор Kommo CRM - модель данных и доступ к API там устроены иначе, и для некоторых команд это упрощает именно такие AI-интеграции. А если HubSpot уже стоит и речь о других AI-сценариях вокруг звонков, мы разбирали смежную тему в материале про то, что теряет нативная интеграция HubSpot с Gong.
Термин: engagement. В HubSpot это объект активности - звонок, заметка, письмо, встреча или задача, привязанный к контакту, компании или сделке. Саммари пишется либо в property самого контакта, либо как отдельный note-engagement на его timeline.
Термин: property. Поле объекта в HubSpot. Кастомное property создаётся один раз через Properties API и дальше заполняется через update объекта. В отличие от текста на timeline, по property можно фильтровать списки и строить условия в workflow.
Термин: structured output. Режим, в котором языковая модель возвращает не свободный текст, а данные по заданной схеме (JSON с фиксированными полями). Без него извлечённое саммари нельзя надёжно разложить по типизированным полям CRM.
Часто задаваемые вопросы
Можно ли обойтись без Operations Hub Pro?
Да, через polling: сервис сам периодически запрашивает свежие звонки через CRM API и обрабатывает новые. Минус - задержка между звонком и саммари (зависит от интервала опроса) и более сложная логика идемпотентности. Workflow-webhook быстрее и надёжнее, но требует платного тарифа Operations Hub.
Какая модель OpenAI оптимальна?
Для summarization звонков gpt-4o-mini - разумная база: качество достаточное, стоимость в десятки раз ниже старших моделей. Старшую модель имеет смысл подключать только если саммари идёт в сложные сценарии, где важны нюансы интонации и подтекста. Для извлечения “итог - следующий шаг - возражение” разницы почти нет.
Безопасно ли отправлять транскрипты звонков в OpenAI?
Данные через OpenAI API не используются для обучения моделей по условиям использования, но для EU-команд это всё равно вопрос GDPR: нужен data processing agreement и фиксация в внутренней политике. Если данные нельзя выпускать наружу в принципе - остаётся вариант self-hosted модели за другой бюджет. Это решается на старте проекта, не постфактум.
Что если транскрипт неточный?
Качество саммари не выше качества транскрипта. Если телефония даёт плохую транскрипцию (шум, акценты, перебивания), саммари это унаследует. Поэтому для команд с критичными звонками источником транскрипта часто берут специализированную телефонию, а HubSpot получает уже готовый текст.
Можно ли так же суммировать письма, а не только звонки?
Да, механика та же: текст email-треда читается через CRM API, уходит в OpenAI, результат пишется в property контакта. Это особенно полезно при передаче сделки - новый менеджер видит саммари переписки вместо десяти писем.
Bottom line
GPT-саммари звонков и писем в карточку HubSpot - это не настройка, а небольшая, но аккуратная сборка: workflow-webhook (или polling), Recordings API, OpenAI с structured output и запись в кастомное property через CRM API. Технических ловушек ровно три - отсутствие нативных webhook на engagements, идемпотентность и privacy - и все они решаются на этапе проектирования. Стоимость модели несущественна; ценность - в том, что итог каждого звонка появляется в карточке без участия менеджера и становится фильтруемым.
Если в вашей команде заметки после звонков заполняются через раз, а контекст теряется при передаче контактов - в Exceltic.dev собираем такую интеграцию под вашу телефонию и формат саммари. Напишите, что у вас за стек звонков и где живут контакты, дальше разберём.