Підключення голосових AI-агентів до вашої CRM: HubSpot, Salesforce та Pipedrive (з кодом вебхуків)

Підключення голосових AI-агентів до вашої CRM: HubSpot, Salesforce та Pipedrive (з кодом вебхуків)

У проекті на базі Vapi, який ми запустили раніше цього року, ланцюжок «голосовий агент → наш внутрішній API пошуку → читання контакту в HubSpot» показав 410 мс на рівні p50 і 1240 мс на рівні p95. Саме ця цифра стала головною причиною написання цієї статті. Інтеграція голосового агента з CRM живе або помирає залежно від таймінгу, який контролює абонент. Якщо налаштувати це як синхронізацію в Zapier, агент замовкне посеред речення, поки вебхук повільно обробляє дані. Рішення полягає не в збільшенні кількості API-викликів. Потрібні два шаблони, один тайм-аут і резервна фраза. Ось усі три компоненти з кодом, готовим до розгортання.

Більшість гайдів на цю тему пояснюють ідею, а потім продають свій продукт. Жоден із них не надає готового обробника. Ми підемо іншим шляхом.

Ключові висновки

• Голосові агенти підключаються до CRM двома способами: функціональні виклики для живого читання даних під час дзвінка та вебхуки для запису результатів після дзвінка.
• Читання під час дзвінка потребує бюджету в 5 секунд плюс озвученої резервної фрази, щоб абонент ніколи не чув мертву тишу.
• Мапінг даних дзвінка до полів CRM має використовувати ключ ідемпотентності, щоб повторні вебхуки не створювали дублікати записів.
• У Pipedrive відсутній вебхук для змін користувацьких полів, тому потрібно періодично опитувати dealFields за графіком.

Що насправді означає «Інтеграція голосового агента з CRM» (2 методи, а не один)

Інтеграція голосового агента з CRM підключає голосового агента до вашої CRM двома різними способами: функціональні виклики для живого читання даних, поки абонент на лінії, та вебхуки для запису результату дзвінка після його завершення. Живе читання персоналізує розмову; запис після дзвінка фіксує те, що сталося. Вони працюють за різними таймінгами і мають різні сценарії відмов.

Ось ментальна модель в одному реченні: функціональний виклик — це коли голосовий агент ставить запитання вашій CRM посеред речення; вебхук — це коли агент подає звіт після завершення дзвінка.

Функціональні виклики: читання даних у реальному часі

Функціональний виклик — це механізм, за допомогою якого велика мовна модель (LLM) призупиняє генерацію тексту, викликає визначений вами зовнішній інструмент і включає отриманий результат у наступну репліку. Для голосового агента таким інструментом є «пошук цього абонента в CRM». Модель вирішує, що їй потрібні дані, ваш сервер отримує їх, і агент вітає абонента по імені, згадуючи його тарифний план. Якщо вам цікаві глибші технічні деталі, наш гід з функціональних викликів детально розбирає схему визначення інструментів. Проблема в тому, що це відбувається в реальному часі, тому ви змагаєтеся з терпінням абонента.

Вебхуки: запис даних після дзвінка

Вебхук — це POST-запит, який ваш сервер отримує після завершення певної події. Для голосових агентів найважливішою є подія завершення дзвінка: платформа надсилає вам транскрипт, резюме, статус диспозиції та URL-адресу запису щойно дзвінок завершується. Ви берете ці дані та записуєте їх у CRM як активність (Activity), а потім змінюєте етап угоди. Тут немає тиску часу. Абонент вже пішов. Ви можете повторно спробувати, поставити в чергу та узгодити дані.

Більшість виробничих інтеграцій використовують обидва методи. Читають у реальному часі, записують після.

Архітектура: що відбувається під час вхідного дзвінка від початку до кінця

Інтеграція голосового агента з CRM дотримується фіксованого життєвого циклу з п'яти кроків для кожного вхідного дзвінка. Дзвінок надходить, агент читає запис абонента в реальному часі через функціональний виклик, відбувається розмова, спрацьовує вебхук завершення дзвінка, і ваш обробник записує результат у CRM та повідомляє людину, якщо це необхідно. Кожен приклад коду в цій статті прив'язаний до одного з цих п'яти кроків.

Ось потік даних покроково:

1. Надходить вхідний дзвінок. Платформа (Vapi, Retell або ваш власний стек голосового агента) відповідає на дзвінок та ідентифікує абонента за номером телефону.
2. Живий пошук (функціональний виклик). Агент викликає ваш інструмент пошуку, який запитує CRM і повертає контакт, етап угоди та недавній контекст.
3. Розмова. Агент спілкується, за необхідності викликаючи додаткові інструменти (перевірка слотів для зустрічей, пошук замовлення).
4. Вебхук завершення дзвінка. Дзвінок завершується, платформа надсилає POST-запит зі звітом про завершення дзвінка на ваш сервер.
5. Запис у CRM + передача оператору. Ваш обробник реєструє активність, встановлює статус диспозиції, змінює етап угоди та створює завдання для людського оператора з повним контекстом.

Головна діаграма вище точно відповідає цьому процесу: одна вхідна стрілка, розгалуження на «живе читання» та «запис після дзвінка», три картки CRM-призначень і вузол передачі оператору. Тримайте цю картину в голові. Все нижче — це просто заповнення блоків.

Читання даних CRM під час дзвінка (і чому у вас є бюджет 5 секунд)

Так, голосовий агент може отримувати дані з CRM під час дзвінка. Він використовує функціональний виклик, який звертається до вашого endpoint пошуку і повертає результат до того, як агент вимовить наступне речення. Обмеженням є час. Згідно з документацією серверних подій Vapi, виклики інструментів мають тайм-аут, і під час живого дзвінка ваше реальне обмеження — це терпіння абонента, а не API. Виділіть п'ять секунд і підготуйте резервний варіант.

Ось частина, яку ніхто в результатах пошуку не вимірює. На шляху Vapi → внутрішній API пошуку → читання контакту в HubSpot ми зафіксували 410 мс на p50 і 1240 мс на p95 кругового часу для кількох тисяч дзвінків. Більшість запитів швидкі. Але хвіст p95 (обмеження швидкості HubSpot, холодний запуск lambda-функції, повільне отримання асоціацій) — це той момент, коли дзвінки завмирають. Через цей хвіст ми встановили тайм-аут інструменту функціонального виклику на 5 секунд: комфортно вище p95 і комфортно нижче точки, коли людина каже «алло? ви тут?».

І ось правило, яке має значення: якщо пошук у CRM займає більше часу, ніж терпіння абонента, агент має щось сказати. Ніколи не мовчіть. Мертва тиша — найшвидший спосіб втратити дзвінок. У наших проектах агент вимовляє резервну фразу миттєво, як тільки спрацьовує тайм-аут інструменту: "Дайте мені секунду, я перевірю ці дані." Абонент чує природну паузу, характерну для людини, а не збій бота.

Це визначення інструменту функціонального виклику, яке ми використовуємо для живого пошуку в CRM:

{
  "type": "function",
  "function": {
    "name": "lookup_crm_contact",
    "description": "Look up the caller in the CRM by phone number before greeting them. Returns name, plan, and open deal stage.",
    "parameters": {
      "type": "object",
      "properties": {
        "phone": {
          "type": "string",
          "description": "Caller phone number in E.164 format"
        }
      },
      "required": ["phone"]
    }
  },
  "server": {
    "url": "https://api.yourdomain.com/voice/crm-lookup",
    "timeoutSeconds": 5
  }
}

Дві речі роблять цей процес безпечним для голосу. Обмеження timeoutSeconds: 5 не дозволяє агенту чекати вічно. А server.url вказує на ваш endpoint, а не безпосередньо на CRM, тому ви контролюєте кешування, повторні спроби та формат відповіді. Наш досвід показує, що наявність внутрішнього API між агентом і CRM — це найкраще рішення, яке ви можете прийняти; саме там живуть логіка резервного варіанта та мапінг полів.

Запис даних після дзвінка: реєстрація активності, резюме та диспозиції

Щоб зареєструвати дзвінок AI-голосового агента в CRM, ви отримуєте вебхук завершення дзвінка від платформи, витягуєте транскрипт, резюме та диспозицію, а потім надсилаєте POST-запит для створення активності дзвінка в CRM і встановлюєте статус ліда. Тут немає обмежень за часом (абонент уже пішов), тому саме тут ви виконуєте важкі операції запису, повторні спроби та зміни етапів угоди, які ніколи б не ризикнули робити під час дзвінка.

Корисне навантаження завершення дзвінка (Vapi називає це подією end-of-call-report, згідно з їхньою документацією серверних подій) містить транскрипт, згенероване резюме, результат дзвінка, URL-адресу запису та тривалість дзвінка. Ваше завдання — перетворити ці дані в активність CRM і просунути запис вперед.

Ось робочий обробник на Node/TypeScript, який отримує звіт і записує активність дзвінка в HubSpot, а потім просуває етап угоди. Endpoint POST /crm/v3/objects/calls і шаблон асоціації з контактом взяті прямо з гіда HubSpot щодо API дзвінків:

import express from "express";

const app = express();
app.use(express.json());

const HUBSPOT_TOKEN = process.env.HUBSPOT_TOKEN!;
const seen = new Set<string>(); // swap for Redis/DB in production

app.post("/voice/end-of-call", async (req, res) => {
  const report = req.body.message; // Vapi end-of-call-report
  if (report?.type !== "end-of-call-report") return res.sendStatus(200);

  const key = report.call.id; // idempotency key (see field-mapping section)
  if (seen.has(key)) return res.sendStatus(200);
  seen.add(key);

  const { contactId, dealId } = report.call.metadata; // set when call started

  // 1. Write the call Activity (engagement)
  await fetch("https://api.hubapi.com/crm/v3/objects/calls", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${HUBSPOT_TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      properties: {
        hs_call_title: "AI Voice Agent Call",
        hs_call_body: report.summary,
        hs_call_duration: String(report.durationMs ?? 0),
        hs_call_recording_url: report.recordingUrl ?? "",
        hs_call_status: "COMPLETED",
        hs_timestamp: Date.now(),
      },
      associations: [
        {
          to: { id: contactId },
          types: [{ associationCategory: "HUBSPOT_DEFINED", associationTypeId: 194 }],
        },
      ],
    }),
  });

  // 2. Move the deal stage based on disposition
  if (dealId && report.analysis?.disposition === "qualified") {
    await fetch(`https://api.hubapi.com/crm/v3/objects/deals/${dealId}`, {
      method: "PATCH",
      headers: {
        Authorization: `Bearer ${HUBSPOT_TOKEN}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ properties: { dealstage: "qualifiedtobuy" } }),
    });
  }

  res.sendStatus(200);
});

app.listen(3000);

Це та винагорода, яку обіцяв заголовок H1: готовий до розгортання обробник, а не його опис. Не хочете писати код і хостити це самостійно? Альтернатива no-code workflow, така як n8n, може отримувати той самий вебхук і записувати дані в CRM за допомогою візуальних вузлів, жертвуючи деяким контролем над повторними спробами та обробкою помилок.

Мапінг даних дзвінка до полів CRM (без створення дублікатів)

Мапінг полів пов'язує кожну частину даних дзвінка з конкретним об'єктом і полем CRM: намір абонента з властивістю угоди, диспозицію зі статусом ліда, резюме з тілом активності. Тут є дві виробничі пастки: форматування даних для мовлення перед тим, як агент озвучить їх, та використання ключа ідемпотентності, щоб повторний вебхук не створив другий запис для того самого дзвінка.

У наших проектах ми зберігаємо мапінг в одному конфігураційному об'єкті, щоб не-інженери могли редагувати його, не торкаючись обробника. Ось структура реального прикладу:

Перша пастка: форматування для мовлення. Голосовий агент, який читає сирий JSON абоненту, звучить зламано. Форматуйте дані CRM у речення перед тим, як вони потраплять у TTS (синтез мовлення). Не повертайте моделі {"plan":"pro","renewed":"2026-03"}. Поверніть "вони на Pro плані, поновили минулого березня", щоб агент вимовив це природно.

Друга пастка: ідемпотентність. Голосові платформи повторюють вебхуки. Якщо ваш обробник не є ідемпотентним, той самий дзвінок буде зареєстровано двічі, і ви отримаєте дублікати записів. Використовуйте ID дзвінка як ключ:

const key = report.call.id;
if (await store.has(key)) return res.sendStatus(200); // already processed
await store.add(key);
// ...do the CRM write

У виробництві цей store — це Redis або рядок у базі даних з унікальним обмеженням на ID дзвінка, а не Set у пам'яті. Наведений вище Set працює для демо; він втрачає дані щоразу, коли сервер перезапускається.

Перш ніж перейти до розділів по кожній CRM, ось як три платформи відрізняються в аспектах, які дійсно важливі для голосу:

Інтеграція з HubSpot (Vapi → HubSpot, покроково)

Для інтеграції Vapi → HubSpot ви мапите живе читання на пошук контакту, а запис після дзвінка — на активність дзвінка, пов'язану з цим контактом та його угодою. Модель об'єктів HubSpot включає Contact, Deal і engagement (активність), а endpoint POST /crm/v3/objects/calls є вашою ціллю для запису. Це шаблон інтеграції vapi з hubspot, який шукає більшість користувачів.

Живе читання — це функціональний виклик до вашого endpoint пошуку, який запитує GET /crm/v3/objects/contacts/search за номером телефону і повертає контакт та будь-яку відкриту угоду. Запис після дзвінка — це обробник з попереднього розділу: він створює активність дзвінка та асоціює її з контактом через тип асоціації 194, а потім оновлює dealstage угоди через PATCH.

Деталь, яку багато хто пропускає: асоціації в HubSpot мають типи. Асоціація дзвінка з контактом використовує конкретний associationTypeId, і дзвінок не відобразиться в хронології контакту, якщо ви його пропустите. Гід HubSpot щодо API дзвінків містить список ID. Для автентифікації токен приватного додатка є найшвидшим шляхом для одного робочого простору; використовуйте OAuth, якщо ви розгортаєте це для кількох облікових записів HubSpot.

Інтеграція з Salesforce (Об'єкти, автентифікація, читання/запис у реальному часі)

Інтеграція голосового агента з Salesforce читає дані з Contact або Lead під час дзвінка і записує Task (об'єкт активності) після нього. Угода знаходиться в Opportunity. Шаблон ідентичний HubSpot (живе читання через функціональний виклик, запис після дзвінка), але назви об'єктів і потік автентифікації відрізняються. Для запису ви будете використовувати REST API або Composite API.

Для живого читання ваш endpoint пошуку запитує Salesforce за допомогою SOQL-запиту, такого як SELECT Id, Name, Account.Name FROM Contact WHERE Phone = '...', і повертає результат агенту. Для запису після дзвінка ви створюєте Task, де WhoId встановлено на Contact/Lead, а WhatId — на Opportunity, згідно з гідом Salesforce REST API:

await fetch(
  `${INSTANCE_URL}/services/data/v60.0/sobjects/Task`,
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${sfToken}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      Subject: "AI Voice Agent Call",
      Description: report.summary,
      Status: "Completed",
      WhoId: contactId,      // Contact or Lead
      WhatId: opportunityId, // Opportunity
      CallDurationInSeconds: Math.round((report.durationMs ?? 0) / 1000),
    }),
  }
);

Специфічна пастка для голосу: токени OAuth у Salesforce мають термін дії, і ви не хочете, щоб оновлення токена змагалося з вашим 5-секундним бюджетом живого читання. Оновлюйте токени за графіком у фоновому режимі, кешуйте токен доступу і тримайте його «теплим», щоб живий пошук ніколи не платив ціну оновлення під час дзвінка.

Інтеграція з Pipedrive (та, яку всі пропускають)

Інтеграція з Pipedrive працює через Persons, Deals і Activities, і має одну справжню пастку: відсутність вебхука для змін користувацьких полів. Якщо ваш голосовий агент записує дані в користувацьке поле, і вам потрібно реагувати на цю зміну в іншому місці, ви не можете підписатися на неї. Pipedrive не надішле вам вебхук при зміні користувацького поля; вам потрібно періодично опитувати dealFields. Майже ніхто не висвітлює це, і саме тому інтеграції голосового агента з Pipedrive ламаються неочевидним чином.

Життєвий цикл голосу чітко мапиться: живе читання запитує GET /persons/search за телефоном, запис після дзвінка створює активність (POST /activities), пов'язану з Person і Deal, а кваліфікація переводить Deal на наступний етап. Стандартні речі.

Пастка — це користувацькі поля. У Pipedrive користувацькі поля посилаються за допомогою 40-символьного хеш-ключа, а не людської назви, тому ваша конфігурація мапінгу має зберігати щось на зразок dcf558aba6... замість plan_tier. І згідно з документацією Pipedrive DealFields, для них немає події зміни. Якщо сторонній системі потрібно знати, коли агент оновив користувацьке поле, ви опитуєте GET /dealFields і порівнюєте з останнім знімком через cron. Це не елегантно. Але саме так працює Pipedrive, і дізнатися про це о 2-й ночі у виробництві гірше, ніж прочитати це тут.

Передача кваліфікованого ліда: зміна етапу угоди та інформування оператора

Передача оператору — це момент, коли голосовий агент змінює етап угоди при кваліфікації, створює завдання для людського оператора і передає транскрипт та резюме, щоб оператор увійшов у контекст. Якщо зроблено правильно, людина отримує теплий, кваліфікований лід із нотатками, а не холодне ім'я та номер телефону.

Механічно це три операції запису, всі в обробнику після дзвінка: PATCH угоди на кваліфікований етап, POST активності/завдання, призначеного оператору з дедлайном, і додавання резюме дзвінка в тіло завдання. Оператор відкриває свою CRM, бачить «AI кваліфікував: хоче демо Pro, бюджет підтверджено, перевага четвергу» і дзвонить назад підготовленим.

Саме тут проявляється вибір платформи. Якщо ви все ще вирішуєте, на якому двигуні будувати, наш огляд яка платформа найкраще обробляє інтеграцію з CRM порівнює, як Vapi, Retell і Bland надають метадані дзвінків та події вебхуків, і ця різниця безпосередньо впливає на чистоту вашої передачі оператору.

Зробити самому чи передати комусь (чесні години)

Створення виробничої інтеграції голосового агента з CRM займає приблизно 20–40 годин на одну CRM, і години витрачаються не там, де ви очікуєте. Щасливий шлях читання та запису займає, можливо, день. Решта — це управління токенами автентифікації, мапінг полів, обробка резервних варіантів, ідемпотентність та тестування з урахуванням обмежень швидкості та особливостей CRM. То скільки часу це насправді займає? Ось чесний розподіл.

У наших проектах час розподіляється приблизно так: 3–5 годин на автентифікацію та оновлення токенів, 4–6 на мапінг полів і шар форматування для мовлення, 4–8 на обробку резервних варіантів і тайм-аутів, 3–5 на ідемпотентність і видалення дублікатів, а решта — на тестування на реальному трафіку дзвінків. Перша CRM навчає вас шаблону; друга і третя йдуть швидше, але кожна має свою пастку, як-от відсутність вебхука користувацьких полів у Pipedrive.

Чи варто будувати чи купувати? Якщо у вас є розробник, який може розмістити endpoint вебхука, і ви інтегруєте одну CRM, збудуйте це самі. Ця стаття — ваш blueprint. Якщо вам потрібно три CRM, багатокористувацька автентифікація і хтось на чергуванні, коли HubSpot обмежує швидкість о 9 ранку, математика змінюється. Ми детально розглядаємо це рішення в нашому гіді DIY vs найм, а розбивка цін показує, скільки роботи з інтеграції додається до побудови.

Якщо ви не хочете підтримувати все це, ми робимо це для клієнтів. Techsy постачає виробничі голосові агенти, підключені до вашої CRM: читання через функціональні виклики, запис через вебхуки, обробка резервних варіантів — все це. Без тиску в будь-якому напрямку; код вище ваш для запуску незалежно від цього.

Про автора

Мерт Батур Гюрбуз є співзасновником Techsy.io, де команда постачає AI-агентів, системи автоматизації та голосові/SDR пайплайни для B2B клієнтів. Він навчається в Бірмінгемському університеті і пише про стек інструментів LLM, який команда Techsy реально використовує у виробництві. Підключайтеся на LinkedIn.

Часті запитання

Як інтегрувати AI-голосового агента з CRM?

Ви підключаєте агента до CRM двома способами: функціональні виклики для живого читання під час дзвінка та вебхук для запису після дзвінка. Агент шукає абонента в реальному часі через ваш endpoint, потім вебхук завершення дзвінка запускає ваш обробник, який реєструє активність і оновлює етап угоди в CRM.

Чи може голосовий агент отримувати дані з CRM під час дзвінка?

Так. Агент використовує функціональні виклики для звернення до вашого endpoint пошуку, який запитує CRM і повертає дані контакту та угоди до того, як агент вимовить наступне речення. Встановіть тайм-аут інструменту в 5 секунд і озвучену резервну фразу, тому що під час живого дзвінка ви змагаєтеся з терпінням абонента, а не з API.

Як реєструвати дзвінки AI-голосового агента в CRM?

Ви отримуєте вебхук завершення дзвінка від платформи, який містить транскрипт, резюме, диспозицію та URL-адресу запису. Ваш обробник витягує ці дані, надсилає POST-запит для створення активності дзвінка або engagement у CRM, пов'язаної з контактом, і встановлює статус ліда. Тут немає тиску за часом, оскільки абонент уже завершив дзвінок.

Яка різниця між вебхуком і функціональним викликом для голосових агентів?

Функціональний виклик — це живе читання під час дзвінка: агент ставить запитання вашій CRM посеред розмови і миттєво використовує відповідь. Вебхук — це запис після дзвінка: платформа надсилає POST-запит з результатом дзвінка на ваш сервер після його завершення. Функціональний виклик змагається з часом; вебхуки — ні.

Чи інтегрується Vapi з HubSpot, Salesforce та Pipedrive?

Vapi не постачає нативні конектори для всіх трьох, але інтегрується з будь-яким із них через свої інструменти функціональних викликів (живе читання) та вебхуки серверної URL-адреси (запис після дзвінка). Ви направляєте їх на свій власний endpoint, який спілкується з HubSpot, Salesforce або Pipedrive через їхні REST API. Шаблон ідентичний для всіх трьох CRM.

Як мапити дані дзвінка до користувацьких полів CRM?

Зберігайте конфігураційний об'єкт, який мапить кожне поле даних дзвінка до об'єкта та поля CRM. Для HubSpot і Salesforce користувацькі поля використовують зрозумілі внутрішні назви. Pipedrive посилається на користувацькі поля за допомогою 40-символьного хеш-ключа, тому ваша конфігурація зберігає хеш, а не дружню назву. Форматуйте значення для мовлення перед тим, як агент озвучить їх.

Чи може голосовий агент оновлювати мою CRM в реальному часі під час дзвінка?

Він може читати в реальному часі, але більшість виробничих збірок відкладають запис до після дзвінка. Живе читання має бути швидким і безпечним. Живий запис ризикує затримками та частковими оновленнями, якщо дзвінок обірветься посеред запису. Стандартний шаблон — читати в реальному часі, записувати через вебхук завершення дзвінка, що захищає досвід абонента.

Як запобігти створенню дублікатів записів у CRM голосовим агентом?

Використовуйте ключ ідемпотентності; ID дзвінка ідеально підходить. Перед тим, як ваш обробник щось запише, перевірте, чи ви вже обробили цей ID дзвінка; якщо так, поверніть 200 і пропустіть. Зберігайте ключ у Redis або базі даних з унікальним обмеженням, а не в пам'яті, щоб він зберігався після перезапусків. Вебхуки повторюються, тому це обов'язково.

Чи інтегрується Retell з Pipedrive?

Retell інтегрується з Pipedrive через той самий шаблон функціональних викликів і вебхуків, що й будь-яка CRM, навіть якщо нативний конектор не вказано. Ви підключаєте події дзвінків Retell до свого endpoint, який використовує API Activities і Deals Pipedrive. Слідкуйте за обмеженням користувацьких полів: у Pipedrive немає вебхука для змін користувацьких полів, тому ви опитуєте dealFields.

Скільки часу займає побудова інтеграції голосового агента з CRM?

Приблизно 20–40 годин на одну CRM для виробничої збірки. Щасливий шлях швидкий; час йде на автентифікацію та оновлення токенів, мапінг полів, обробку резервних варіантів і тайм-аутів, ідемпотентність та тестування на реальному трафіку дзвінків. Перша CRM найповільніша, тому що вона навчає вас шаблону. Кожна додаткова CRM все одно має свої особливості.