Якщо ви вже використовуєте HubSpot, налаштували кілька робочих процесів, кілька листів для підтримки клієнтів, базові нагадування...
…але ваші автоматизовані листи досі виглядають майже однаково для всіх – хоча ви маєте дані, які вже зберігаються в об’єктах Contacts, Companies, Deals і Tickets, – ви фактично не добираєте значну частину потенційного доходу та цінності для утримання клієнтів.
У цій статті ми розберемо одну чітку, але прикладну задачу:
Чи можна включити дані стандартних об’єктів HubSpot до автоматизованих листів – і використати їх для більш розумної, контекстної комунікації?
Так, можна. І якщо робити це чіткою структурою та з чистими даними, це кардинально змінює сприйняття клієнтами вашої email‑комунікації.
1. Ви користуєтесь HubSpot, але не використовуєте всі можливості автоматизації
Більшість команд, з якими ми працюємо в Velainn, знаходяться в подібній ситуації:
-
HubSpot налаштований.
-
Є кілька форм, списків і робочих процесів.
-
Декілька автоматизованих електронних листів надсилаються на основі простих тригерів (наприклад, «заповнена форма», «став MQL»).
Однак найцінніші дані: вартість угоди, дата поновлення, статус підтримки, рівень облікового запису — рідко з'являються в автоматизованих електронних листах у послідовному, структурованому вигляді.
Для B2B-IT, SaaS-компаній та сервісних компаній з тривалим циклом взаємодії з клієнтами це втрачена можливість. Персоналізація та логіка на основі об'єктів можуть допомогти вам:
-
Розпланувати електронні листи відповідно до ключових етапів (укладені угоди, поновлення, порушення SLA).
-
Налаштувати повідомлення на основі рівня облікового запису, галузі або етапу обслуговування.
-
Інформувати клієнтів про те, що для них дійсно важливо: проєкти, контракти та підтримка.
Перевага: HubSpot надає вам більшу частину цієї інформації у придатному для використання вигляді. Справжня робота полягає в тому, щоб знати, де це знайти і як надійно поєднати.
2. Що таке стандартні об’єкти HubSpot — і як вони співвідносяться з вашим бізнесом
CRM-система HubSpot побудована на невеликому наборі стандартних об’єктів:
-
Контакти — окремі особи.
-
Компанії — клієнтські профілі.
-
Угоди — можливості продажів, контракти, продовження договорів.
-
Квитки – запити на підтримку або обслуговування.
Ці об’єкти містять структуровані дані та є основою платформи. Вони також відіграють ключову роль у робочих процесах та автоматизації.
Для типового бізнесу в сфері ІТ/SaaS/послуг це зазвичай виглядає так:
-
Угоди → нові продажі, розширення та поновлення.
-
Квитки → інциденти, помилки, завдання з онбордингу нових співробітників або запити клієнтів.
-
Компанії → клієнти, партнери або облікові записи з інформацією про сегмент, ARR та життєвий цикл.
-
Контакти → люди, з якими ви спілкуєтеся, з позицією в компанії, уподобаннями та історією взаємодії.

На вищих рівнях HubSpot та з увімкненими функціями комерції, ви також можете працювати з додатковими стандартними об’єктами в автоматизованих електронних листах, такими як пропозиції, рахунки-фактури, підписки та кошики.
Кастомні об’єкти стають у нагоді, коли ваша бізнес-логіка не вписується в ці категорії (наприклад, «Проєкти», «Курси» або складні «Підписки»). Але для більшості невеликих ІТ-команд та команд SaaS правильне використання Контактів / Компаній / Угод / Квитків уже забезпечує значну перевагу в релевантності електронних листів.
3. Отже… Чи можна додавати стандартні об’єкти HubSpot до автоматизованих листів?
Перейдемо до головного питання.
Коротка відповідь:
Якщо ви використовуєте автоматизовані маркетингові листи в Marketing Hub Professional або Enterprise, ви можете без проблем отримувати дані зі стандартних об’єктів CRM за допомогою токенів персоналізації — не тільки з контактів, а й з інших записів, залежно від того, що послужило тригером для відправки листа.
А саме:
-
Усі маркетингові листи можуть мати базову персоналізацію, таку як:
-
Місцезнаходження офісу (з налаштувань нижньому колонтитулі листа).
-
Тип підписки.
-

-
Автоматизовані маркетингові листи, пов’язані з workflow, можуть використовувати маркери з:
-
Угод — наприклад, сума, власник, дата закриття угоди.
-
Квитків – з Service Hub Starter/Professional/Enterprise.
-
Налаштованих об’єктів, підписок, рахунків-фактур, пропозицій, кошиків та користувачів на їхніх рівнях підтримки.
-
Важливе правило:
Тип запису, на основі якого запускається ваш workflow, визначає, токени яких об’єктів ви зможете використати в цьому автоматизованому листі.
Якщо ваш workflow (робочий процес) базується на угодах, ви можете використовувати властивості угод.
Якщо він базується на квитках, ви можете використовувати властивості квитків тощо.
Для послідовностей у Sales Hub та індивідуальних листів ви також можете вставляти дані CRM за допомогою токенів персоналізації, пов’язаних із контактами та відповідними записами. Механізм та обмеження дещо відрізняються, але принцип залишається таким самим: HubSpot використовує зареєстрований запис (та пов’язані з ним записи) для розпізнавання токенів під час відправки.
4. Як на практиці додавати дані з CRM до ваших листів
Тут починається практична частина.
4.1. Основа: зв'язки між об'єктами
HubSpot не вгадує, яку угоду чи запит використовувати.
Він спирається на визначені зв’язки між об’єктами:
-
Контакт пов’язаний з компанією, однією або кількома угодами та, можливо, кількома запитами (квитками).
-
Ці зв’язки можуть мати мітки/теги (наприклад, «Основна компанія», «Особа, що приймає рішення»), які мають значення, коли існує кілька пов’язаних записів.

Ви можете керувати цими зв’язками та автоматизувати їх за допомогою робочих процесів (workflow) — наприклад:
-
Пов’язувати контакти із компаніями, коли певні поля збігаються.
-
Масово застосовувати або оновлювати мітки зв’язків.
Якщо зв’язки є хаотичними або непослідовними, ваша персоналізація також буде хаотичною та непередбачуваною.
4.2. Як використовувати токени персоналізації в автоматизованих листах
Коли ви створюєте автоматизований лист і підключаєте його до робочого процесу (workflow):
-
Оберіть правильний тип об’єкта для робочого процесу (workflow) .
-
Приклад: робочий процес на основі угоди для онбордингу після закриття угоди.
- Приклад: робочий процес на основі квитка (ticket) для оновлень щодо статусу підтримки.
-
- Додавайте токени, що відповідають даному типу об’єкта. У автоматизованому листі HubSpot дозволяє обирати токени на основі:
- Зареєстрованої угоди (сума, стадія, дата закриття, власник).
- Зареєстрованого квитка (ID, статус, пріоритет, конвеєр).
- Інших підтримуваних стандартних / кастомних об’єктів залежно від вашої підписки.
- Посилайтеся на пов’язані записи, де це доречно. Наприклад, електронний лист у робочому процесі на основі угоди (deal-based workflow) може містити:
- Назву компанії (через пов’язану компанію).
- Ім’я контактної особи (через основний пов’язаний контакт).
-
Тип плану або MRR (з властивостей угоди).
Усе це HubSpot підставляє автоматично в момент відправки, спираючись на зареєстрований запис і його асоціації. Якщо модель даних і зв’язки впорядковані, листи виглядають точними та контекстними, а не загальними.
5. Реальні приклади застосування для ІТ-команд, команд SaaS та сервісних команд
Нижче наведено шаблони, які ми у Velainn регулярно застосовуємо для невеликих та зростаючих B2B-команд.
Автоматизація на основі угод
Нагадування про поновлення
-
Тип робочого процесу: на основі угоди.
-
Тригер: стадія угоди — «Активний клієнт», а до дати поновлення залишається X днів.
-
Параметри електронного листа:
-
Сума та термін дії угоди.
-
Поточний план або пакет.
-
Менеджер з обслуговування клієнтів (CSM) або власник облікового запису.
-

Впровадження після закриття угоди з позитивним результатом
-
Тригер: стадія угоди змінюється на «Закрито з позитивним результатом».
-
Що використовуємо в листах:
-
Придбаний продукт.
-
Етапи онбордингу, характерні для обраного плану.
-
Посилання, унікальні для робочого простору або середовища клієнта (зберігаються як властивості).
-
Комунікація з використанням сутності "Компанія"
Сегментований онбординг і навчання
- Тип робочого процесу: на основі компанії.
- Умови: галузь, ACV або рівень сервісу.
- Електронні листи адаптують тон і зміст відповідно до:
- Галузі (SaaS, консалтинг, сервісні компанії).
- Сегмента (малий чи середній бізнес, корпорація).
- Моделі підтримки (стандартна чи преміум).
Комунікація щодо послуг на основі квитків
Оновлення статусу та подальший супровід
- Тип робочого процесу: на основі квитка.
- Тригери: зміна статусу квитка на «В роботі», «Очікуємо на клієнта» або «Закрито».
- Електронні листи містять:
- ID квитка, тему, поточний статус і пріоритет.
- Посилання на ваш портал або сторінку підтримки/довідковий центр.
Відгуки
-
Тригер: квиток переходить у статус «Закрито».
-
Лист: запитуємо відгук і прямо посилаємося на цей конкретний квиток (ID, тему), щоб одержувач одразу розумів контекст.

Логіка на основі різних пов'язаних об'єктів
Лист про ескалацію від менеджера з роботи з клієнтами (CSM)
-
Тип робочого процесу: зазвичай на основі компанії або контакту, з використанням умов, пов’язаних із відповідними квитками та угодами.
-
Приклад набору умов:
-
Стадія життєвого циклу компанії = «Клієнт».
-
Є відкритий квиток із пріоритетом «Високий».
-
Активна угода MRR > X.
-
Дії:
-
Внутрішні сповіщення для CSM.
-
Зовнішній електронний лист клієнту з контактною особою вищого рівня.
Для початку вам не потрібні всі розширені функції. Стандартних об’єктів, чітких зв’язків та зрозумілого дизайну робочого процесу достатньо для створення ефективних шляхів взаємодії.
6. Обмеження, підводні камені та випадки, коли потрібно більше, ніж просто токени
Хоч це і є потужним інструментом, слід пам’ятати про певні обмеження та типові пастки.
6.1. Не всі токени скрізь доступні
Вибір токенів, які ви можете використовувати, залежить від:
- Типу електронного листа (звичайний чи автоматизований) та
- Типу об’єкта, до якого прив’язано робочий процес (Контактів / Компаній / Угод / Квитків).
Наприклад:
Автоматизовані маркетингові листи можуть використовувати токени Угод і Квитків, коли:
-
робочий процес побудовано на основі угоди або квитка;
-
ви маєте відповідний рівень підписки.
Деякі токени користувацьких об’єктів або комерційних даних з’являються лише на вищих тарифних планах або у разі увімкнення певних функцій (підписки, рахунки-фактури, комерційні пропозиції, кошики тощо).
Якщо ви не бачите потрібного параметра у вікні вибору токенів, зазвичай це пов’язано з цими обмеженнями — це не обов’язково означає, що сталася помилка конфігурації.
6.2. Невизначеність асоціацій
Якщо контакт пов’язаний із:
-
Декількома угодами (наприклад, однією новою та однією про продовження) або
-
Декількома квитками.
То HubSpot потребує чітких правил щодо того, який запис використовувати. Тут у гру вступають:
-
первинні асоціації;
-
мітки асоціацій (наприклад, «Поточне поновлення», «Основний квиток»).
Без цього ви ризикуєте посилатися на неправильну угоду або квиток у конфіденційному листі (наприклад, згадуючи старі ціни або інцидент, що не має відношення до справи).
6.3. Якість даних і складність робочих процесів
Дві теми, які постійно зустрічаються під час аудитів:
Якість даних
Порожні поля або невідповідні формати призводять до неправильної персоналізації:
“Привіт, ваша угода зараз на стадії … .”
Ви можете мінімізувати це таким чином:
- Зобов'язати всіх заповнювати певні поля там, де це необхідно.
- Впровадити правила перевірки та випадаючі списки замість вільного введення тексту.
- Уніфікувати схеми присвоєння назв в усіх командах.
Надто складні робочі процеси
- Занадто багато вкладених умов «if/then».
- Циклічна логіка, коли один workflow повторно запускає інший.
Відсутність документації — у результаті ніхто не хоче до цього торкатися.
Механізм робочих процесів HubSpot є потужним, але він виконуватиме лише те, що ви йому задасте. Іноді правильним рішенням є не «додати ще один робочий процес», а зробити крок назад, спростити логіку та перепроектувати архітектуру так, щоб вона безпечно масштабувалася.
7. Коли звертатися за допомогою (і як Velainn може вам у цьому допомогти)
Якщо ви думаєте:
-
«У нас є дані, але ми не впевнені, який об’єкт повинен за що відповідати».
-
«Я не знаю, чи повинен цей робочий процес базуватися на контактах, угодах чи компаніях».
-
«Токени та зв’язки не завжди працюють так, як ми очікуємо».
-
«Якщо ми змінимо робочий процес, я боюся, що ми щось зіпсуємо».
Ви в тій самій ситуації, що й багато невеликих ІТ‑ та SaaS‑команд, яких ми супроводжуємо щомісяця.
У Velainn ми допоможемо вам перейти від ситуації, коли «у HubSpot все відбувається само собою», до чіткого та передбачуваного рівня автоматизації за допомогою:
-
Аудиту вашої поточної конфігурації HubSpot
-
Об’єкти, властивості, зв’язки та робочі процеси.
-
-
Розробки чіткої та масштабованої моделі даних
-
Що зберігається в об’єктах «Контакт», «Компанія», «Угода», «Квиток» та «Налаштований об’єкт».
-
-
Впровадження автоматизованих ланцюжків електронних листів на основі стандартних (та налаштованих) об’єктів
-
Потоки поновлення, адаптація нових клієнтів, комунікація служби підтримки, супровід протягом життєвого циклу.
-
-
Впровадження управління та навчання вашої команди
-
Правила іменування, відповідальність та процеси змін.
-
Навчання, щоб ваша команда розуміла та довіряла тому, що створено.
-
Якщо ви не впевнені, чи (і як) слід використовувати дані стандартних об’єктів HubSpot в автоматизованих електронних листах, ми можемо продемонструвати вам підхід, який найкраще підходить для вашого випадку та рівня підписки.
Хочете побачити, що можна зробити у вашому власному обліковому записі HubSpot?
Поділіться з нами одним реальним сценарієм — наприклад, «нагадування про поновлення за угодою», «оновлення для клієнтів на основі квитків» або «онбординг на основі облікового запису» — і ми допоможемо вам зіставити його з відповідними об’єктами, структурою робочого процесу та шаблонами електронних листів.
Вам не доведеться розбиратися в цьому самостійно. Velainn може перетворити вашу поточну конфігурацію HubSpot на стабільну, масштабовану систему, де автоматизовані електронні листи нарешті відображатимуть багаті дані CRM, які ви вже маєте, — і де ваша команда дійсно довірятиме тому, що HubSpot робить у фоновому режимі.
