CRM автоматизація: як прибирати дублікати лідів і ставити пріоритет менеджеру

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

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

Чому ліди дублюються

У малому бізнесі джерела заявок рідко зібрані в одну систему. Частина клієнтів приходить через форму сайту, частина пише в Telegram, хтось відповідає на email, а хтось залишає повторну заявку після реклами. Формально це різні події. Практично це може бути один контакт із тим самим телефоном або email.

Найчастіші причини дублів:

• телефон записаний у різних форматах: +380, 0800, пробіли, дужки, дефіси;
• email має різний регістр або зайві пробіли;
• менеджер вручну створив картку після дзвінка, а форма вже створила рядок автоматично;
• клієнт звернувся з різних каналів у різні дні;
• стара заявка була закрита, але клієнт повернувся з новою потребою.

Якщо просто додавати кожну подію новим рядком, Google Sheets швидко перетворюється на список шуму. Правильніше розділити дві сутності: контакт клієнта і події навколо нього. Для першого етапу це можна зробити навіть у простій таблиці, якщо перед записом нормалізувати дані й шукати збіг. Схожу логіку варто тримати поруч із процесом автоматизації обробки замовлень у Google Sheets і Telegram, бо там теж важливо не плодити дублікати подій.

Які поля потрібні для дедуплікації

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

Окремі поля phonenorm і emailnorm можуть здаватися зайвими, але саме вони роблять дедуплікацію передбачуваною. Менеджер бачить людський формат, а скрипт працює зі стабільним значенням.

Нормалізація телефону й email

Перед пошуком дубля треба привести контакти до одного формату. Це не складний AI-процес, а звичайна інженерна гігієна.

function normalizePhone(phone) {
  if (!phone) return "";

  let digits = String(phone).replace(/\D/g, "");

  if (digits.startsWith("0") && digits.length === 10) {
    digits = "38" + digits;
  }

  if (digits.startsWith("380") && digits.length === 12) {
    return "+" + digits;
  }

  return digits ? "+" + digits : "";
}

function normalizeEmail(email) {
  return String(email || "").trim().toLowerCase();
}

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

Як знайти дублікат ліда

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

function findDuplicateLead(leads, incomingLead) {
  const phoneNorm = normalizePhone(incomingLead.phone);
  const emailNorm = normalizeEmail(incomingLead.email);

  return leads.find((lead) => {
    const samePhone = phoneNorm && lead.phone_norm === phoneNorm;
    const sameEmail = emailNorm && lead.email_norm === emailNorm;

    return samePhone || sameEmail;
  });
}

Якщо дубль знайдено, не треба просто ігнорувати нову заявку. Вона може містити важливий сигнал: клієнт повернувся, змінив повідомлення, зайшов з іншої сторінки або став більш готовим до покупки. Тому краще оновити sources, last_touch, додати нову нотатку і за потреби підняти score.

Об'єднання джерел без втрати історії

Погана дедуплікація каже: "такий телефон уже є, нічого не робимо". Хороша CRM автоматизація каже: "такий клієнт уже є, додамо нову подію до його історії".

function mergeLeadEvent(existingLead, incomingLead) {
  const sources = new Set([
    ...(existingLead.sources || []),
    incomingLead.source
  ].filter(Boolean));

  return {
    ...existingLead,
    sources: Array.from(sources),
    last_touch: new Date().toISOString(),
    page_url: incomingLead.page_url || existingLead.page_url,
    message: incomingLead.message || existingLead.message,
    status: existingLead.status === "lost" ? "reopened" : existingLead.status
  };
}

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

Як рахувати простий lead score

Lead scoring не має бути магією. Якщо менеджер не розуміє, чому лід отримав 85, система швидко втрачає довіру. На старті достатньо прозорих правил: джерело, цільова сторінка, бюджет, роль клієнта, повторний контакт, терміновість.

function scoreLead(lead) {
  let score = 0;

  if (lead.source === "referral") score += 25;
  if (lead.source === "google_ads") score += 15;
  if (lead.page_url?.includes("/services/")) score += 20;
  if (Number(lead.budget) >= 1000) score += 20;
  if (lead.role === "owner" || lead.role === "director") score += 15;
  if ((lead.sources || []).length > 1) score += 10;
  if (lead.message?.match(/терміново|сьогодні|завтра/i)) score += 10;

  return Math.min(score, 100);
}

Це не "розумна оцінка клієнта", а простий пріоритет для роботи. Вона відповідає на питання: кого треба подивитися швидше. Рішення про якість ліда все одно має залишатися за менеджером або керівником продажів.

Повідомлення менеджеру без зайвого шуму

Якщо відправляти менеджеру кожну дрібну подію, Telegram швидко стане ще одним джерелом хаосу. Тому notification layer має мати правила: повідомляти тільки про нові пріоритетні ліди, повернення старого клієнта або зміну статусу, яка потребує дії.

async function notifyManager(lead) {
  if (lead.score < 60 && lead.status !== "reopened") {
    return;
  }

  const text = [
    `Новий пріоритетний лід: ${lead.name || "без імені"}`,
    `Score: ${lead.score}/100`,
    `Джерела: ${(lead.sources || [lead.source]).join(", ")}`,
    `Сторінка: ${lead.page_url || "не вказано"}`,
    `Статус: ${lead.status}`,
    "",
    "Дія: перевірити картку і призначити next step."
  ].join("
");

  await fetch(`https://api.telegram.org/bot${process.env.TG_BOT_TOKEN}/sendMessage`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      chat_id: process.env.SALES_CHAT_ID,
      text
    })
  });
}

У цій логіці важливо, що Telegram не стає CRM. Він лише підсвічує те, що потребує уваги. Джерелом правди залишається таблиця або CRM-картка.

Коли Google Sheets CRM достатньо

Google Sheets CRM працює добре, коли команда невелика, процес ще змінюється, а головне завдання - швидко навести порядок. Таблиця дає прозорість: усі бачать поля, статуси, відповідальних і причини пріоритету. Для технічної частини корисно звіряти реалізацію з офіційною документацією Google Apps Script Spreadsheet service, а повідомлення менеджерам - з методом Telegram Bot API sendMessage.

Такий формат достатній, якщо:

• лідів десятки або сотні на місяць, а не десятки тисяч;
• менеджерів небагато;
• потрібна кастомна логіка під конкретний бізнес;
• важливо швидко перевірити процес перед впровадженням CRM;
• дані вже приходять у Google Workspace.

Але якщо потрібні складні права доступу, історія комунікацій, воронки по командах, інтеграція з телефонією й угодами, тоді таблиця має стати прототипом, а не фінальною системою. Її завдання - показати, яка логіка справді потрібна.

Як дедуплікація повернула реальну картину по заявках

В одному з робочих сценаріїв проблема виглядала просто: рекламний канал ніби давав багато заявок, але менеджери скаржилися, що частина з них повторюється. У таблиці один і той самий клієнт міг бути записаний як +38 067..., 067... і через email без телефону. Формально це були три ліди. По суті - одна людина, яка поверталася з різних точок.

Після нормалізації телефону й email картина змінилася. Частина "нових" заявок стала повторними контактами, а рекламна статистика стала ближчою до реальності. Менеджери перестали відкривати кілька карток на одного клієнта, а повторне звернення почало сприйматися не як дубль, а як сигнал інтересу.

Найціннішим виявився не сам скрипт, а зміна процесу. Команда почала бачити: хто справді новий, хто повернувся, який канал дав перший контакт, а який повернув клієнта до розмови. Саме з цього CRM автоматизація стає корисною для бізнесу, а не просто "ще одним списком заявок".

Що не варто автоматизувати одразу

Не треба на першому етапі будувати складну scoring-модель, прогноз покупки або AI-висновок про "якість клієнта". Без історичних даних це буде красива, але слабка імітація. Краще почати з того, що точно зменшує хаос:

• нормалізувати телефон і email;
• прибирати очевидні дублікати;
• зберігати джерела контакту;
• оновлювати last_touch;
• рахувати простий score за прозорими правилами;
• повідомляти менеджера тільки про пріоритетні події.

Це дає швидкий практичний ефект і не створює ілюзію, що система "сама все знає". Автоматизація має прибирати рутину, а не ховати рішення в чорну скриньку.

Практичний підсумок

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

Перший робочий крок дуже конкретний: додайте phonenorm, emailnorm, sources, score і last_touch, а перед кожним новим записом перевіряйте дубль. Після цього вже можна додавати повідомлення менеджерам, SLA, автоматичні next steps і повноцінні CRM-інтеграції. Якщо менеджеру потрібен контекст перед контактом, наступним шаром може бути AI помічник для продажів із summary клієнта. Але база одна: дані мають бути чистими, а правила - зрозумілими людям, які щодня з ними працюють.