Експертиза · CRM і продажі

Система, в якій видно, кого зачеплено, через який канал і що далі.

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

Обговорити проєкт

Вже збудованоДві власні реалізації, у продакшені, наведені нижче. (1) MEGA CRM — система, за допомогою якої наша команда веде власну комерційну діяльність: `server.js` має 9.516 рядків і 99 HTTP-маршрутів, у репозиторії є 96 SQL-міграцій і близько 95.000 рядків TypeScript в інтерфейсі, а останній commit — від 18 серпня 2026. (2) CRM-конектори платформи Kallina: 12 серверних функцій для amoCRM, 4 для Bitrix24, плюс задокументований OAuth-потік для Zoho CRM і 10 функцій для Google Sheets. Важливе уточнення: **MEGA CRM не продається.** Ми показуємо його як доказ майстерності, а не як продукт — він не має суворої ізоляції даних між клієнтами і не має потоку встановлення, який не передбачає доступ до сервера. Послуга — це «ми будуємо для вас таку систему», а не «ми даємо вам ліцензію на нашу».

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

Система, яку ми показуємо як доказ, — це та, з якою працюємо ми. Вона структурована на окремі проєкти, кожен зі своїм типом організації та своєю схемою полів, щоб одна й та сама програма працювала і для міської ради, і для приватної компанії, без нових колонок у базі для кожного нового типу. Під організацією знаходяться контакти, над ними — кампанії. Lead піднімається через маршрут із семи стадій, від «не контактували» до «договір підписано», і може бути зачеплений через дев’ять різних каналів, від дзвінка voice agent до візиту.

Складна частина, і та, яку вчиш на власній шкірі, — це не надсилання. Це зупинка. Система має робочі години, записані в коді, списки виключення, дедуплікацію за адресою, написаною малими літерами — не за організацією —, період охолодження між кампаніями, денну стелю, розділену між кампаніями, і вимикач, який відмовляється запускати orchestrator, без шляху обходу. Кожен із них додали після того, як одного разу чогось не вистачило. Ми перелічуємо їх не як список функцій, а як список уроків.

Друга річ, яку ми майже завжди будуємо, — це автоматичне заповнення. CRM, у якому дані записують вручну, спорожнюється за три тижні. У нас виклик voice agent записується сам на картку організації, з transcript і резюме, і переводить lead далі по маршруту, якщо результат дзвінка це виправдовує. Відповіді на email збираються з поштової скриньки кожні десять хвилин і прив’язуються до відправлення, яке їх спричинило. Відкриття та кліки відстежуються окремо. Людина втручається, щоб вирішити, а не щоб вводити дані.

Запобігання спаму в CRM — запити, за якими варто стежити · відео румунською, із субтитрами та розшифровкою українською

Повна транскрипція

Вітаю! У сьогоднішньому аналізі ми розбираємо проблему, з якою в якийсь момент стикається абсолютно будь-який бізнес, що хоче масштабуватися. Як саме автоматизувати комерційний prospecting, щоб усе не перетворилося на дратівливий і агресивний спам? Ми хочемо рости, хочемо підвищувати ефективність, це ясно. Але сьогодні ми заглядаємо під капот захопливого технічного матеріалу, щоб побачити, як спам запобігають рівно 6 чіткими, кільцевими механізмами, інтегрованими в справді безпечну кібернетичну систему. Ідеться не лише про стандартні налаштування, які ми ставимо галочкою і забуваємо про них, а про реальні архітектури, факти й цифри. Ходімо в дані! Добре, коротко, ось структура нашої розмови. Починаємо з проблеми розгону без гальм, потім аналізуємо кейс, інцидент із 42 повідомленнями, переходимо до ядра аналізу, тобто 6 механізмів захисту, говоримо про правильне керування відписками і завершуємо класичною дилемою: коли варто будувати систему, а коли краще її купити.

Почнімо! Отже, ключове питання, з якого ми стартуємо, таке. Як ми переконуємося, що автоматизація, яку ми впроваджуємо, просто не стає спамом? Тут неймовірно тонка межа. Намір за цим завжди добрий: ми хочемо контактувати з людьми, генерувати продажі, але якщо системі дозволити сліпо прискорюватися без дуже суворих технічних перевірок, закодованих прямо в її структурі, вплив на бренд може бути катастрофічним. Переходимо до розділу 1, розгін без гальм. Давайте подивимося на фундаментальну проблему явності в цих автоматизованих системах. Уявіть собі це як дуже потужну машину, але без гальмівної системи. Коли стандартний софт не узгоджується з щоденною реальністю роботи, усе швидко йде шкереберть. Наприклад, припустімо, що команда взаємодіє і з державними адміністраціями, і з приватними компаніями. Абсолютно протилежні структури ухвалення рішень, правда? Їхні дані просто не вміщуються в ті самі жорсткі поля в типовому CRM.

І що відбувається на практиці? Люди починають тримати правду окремо — у файлах Excel або в нотатках на столі, тоді як основна автоматизація продовжує працювати вхолосту на неправильних даних. Це просто хаос. І наше джерело має тут абсолютно геніальну цитату, жорстку правду з індустрії. CRM, у який дані вносять вручну, спорожнюється за 3 тижні. Це дуже логічно. Люди втомлюються, з’являються помилки, а моральний стан падає. Продажники мають будувати стосунки, а не бути роботами для введення даних. Чи то розумний voice agent, який автоматично транскрибує дзвінки, чи то e-mail, які самі синхронізуються у фоновому режимі кожні 10 хвилин, суть зрозуміла. Автоматичне наповнення даних більше не розкіш. Це обов’язкова основа будь-якої функціональної системи. Переходимо до другого розділу, інциденту з 42 повідомленнями. Давайте розберемо анатомію реального збою.

42. Це не просто будь-яке число, а реальна історія з кампанії prospecting, яка запустила справжню технічну реформу. Уявляєте? Одна поштова скринька отримала рівно 42 повідомлення протягом кількох годин, в один і той самий день. Звісно, технічна команда спершу подумала: окей, це баг, банальна петля в коді, яка надсилає без кінця. Але коли уважніше подивилися в базу даних, реальність виявилася набагато складнішою. Пояснення? Систему налаштували витягувати й надсилати повідомлення по організації, а не по e-mail-адресі. Отже, з логічної точки зору алгоритм спрацював ідеально. Він знайшов 42 юридично окремі компанії. Проблема, і це реальність, яку ми часто бачимо на місцевому ринку, була в тому, що всі ці 42 юридичні особи використовували рівно одну й ту саму адресу e-mail. Або це була адреса материнської компанії, або того самого зовнішнього бухгалтера, який адміністрував десятки компаній.

Юридичні особи були унікальні на папері, але кінцева адреса повідомлення була одна. І щоб поставити все в перспективу, знаєте, скільки реальних людей із плоті й крові постраждали від цієї лавини повідомлень? Лише 11. 11 осіб, які адміністрували ці десятки бізнесів. Цей інцидент дуже чітко довів одну річ. Добрі наміри й код, який на перший погляд здається правильним, ніколи не є достатніми. База даних завжди має невидимі зв’язки, і система має їх передбачати. А це підводить нас до найважливішої частини, розділу 3. Шість механізмів захисту, тобто гальма, закодовані прямо в серці системи. Ось і рішення. Джерело детально описує захисне кільце, що складається з шести окремих механізмів, які перевіряють один одного. 1. Встановлення жорстких робочих годин між 8 і 18. Ніхто не хоче e-mail із продажем у неділю о 3 ночі.

2. Постійні списки виключень, тобто блокування чутливих установ, як-от шкіл або посольств. 3. І це б запобігло попередньому інциденту: обов’язкова дедуплікація за e-mail-адресою, переведеною в малі літери, а не за назвою компанії. 4. Період охолодження 5 днів для будь-якої адреси, з якою вже контактували, щоб уникнути задушення аудиторії. 5. Жорсткі денні ліміти, щоб не дратувати глобальні антиспам-фільтри. І, нарешті, шостий механізм — кнопка паніки. Серед усіх цей механізм 6, тобто kill switch, або аварійний вимикач, — справді ключова річ. Його впровадили саме після того інциденту з 42 повідомленнями. Що це таке насправді? Проста змінна, яка, якщо її активувати, просто забороняє центральній системі запускатися далі. Без винятків, без будь-якої прихованої команди для перезапису в коді. Будь-яка серйозна архітектура автоматизації потребує такої фізичної, у переносному сенсі, кнопки, яку абсолютно будь-хто з менеджменту може натиснути, не маючи знань із програмування.

Переходимо до четвертого розділу, правильне керування відписками. Бо, увага, це означає набагато більше, ніж просте посилання, поставлене в кінці сторінки. Після того як ви надіслали повідомлення, якщо людина хоче вийти з бази, процес має бути бездоганним і захищеним. Аналіз показує нам надійний процес у три кроки. Крок 1. Відписка з антіву одним кліком, яка або відповідає новим глобальним стандартам, як-от RFC 8058. Крок 2. Візуальний центр налаштувань, де людина може обрати, який тип повідомлень більше не хоче отримувати. Але крок 3 — це, по суті, найкритичніший, і саме на ньому багато систем дають збій. Повне видалення. Це не означає поставити позначку неактивно. Це означає видалення адреси з, увага, 6 різних таблиць бази даних, плюс перенесення її до постійного чорного списку.

Лише так ви гарантуєте, що ця адреса не з’явиться наче чарівним чином під час наступного масового імпорту даних. І ми говоримо не лише про технологію. Ми говоримо про повагу та юридичну відповідність прямо в нижньому колонтитулі e-mail-у. Хто ви? Хто є офіцером DPO? Яка саме правова підстава, на якій ви надіслали повідомлення? І особливо, з якого публічного реєстру ви спочатку витягли дані? Наше джерело підкреслює золоте правило. Ці підстави треба перевіряти заново після кожної законодавчої зміни. Чому? Тому що ви можете мати найдорожчу систему у світі. Якщо на підставі скасованого закону ви перетворили технологію на великий фінансовий ризик для компанії. Переходимо до останнього, п’ятого розділу. Коли будувати, а коли купувати? Давайте подивимось на правильну відповідь для зрілої комерційної інфраструктури. Документація підходить до цього рішення вкрай об’єктивно.

Готовий CRM «під ключ» — це абсолютно ідеально. З однією лише великою умовою. Щоб ваш робочий процес ідеально відповідав логіці, яку задумали творці платформи. Однак рішення побудувати персоналізоване рішення стає єдиним шляхом у трьох чітких ситуаціях. Коли ви взаємодієте з дуже різними типами організацій, коли у вас величезний обсяг автоматизацій, у яких ручна робота стає неможливою, і, найважливіше, коли у вас є суворі правила захисту, як-от ті шість механізмів, які готове коробкове ПЗ просто не може вам гарантувати на такому глибокому рівні. Добра новина? Побудувати щось безпечне в бекенді не означає викинути у вікно інструменти, які команда вже знає. Ці механізми захисту можуть працювати тихо як невидимий шар безпеки, водночас підключаючись до звичних інтерфейсів. Існують демонстровані архітектури, які мають конектори, що виконують десятки двонапрямних функцій із популярними системами, як-от Amos ERM, Bitrix24, Zohos ERM або навіть класичні таблиці Google Sheets.

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

Що входить

Робота, за складовими

Дані входять у потік, із дедуплікацією за трьома ключами

Файл до 50 MB завантажується і обробляється в потоці, партіями по 200 рядків, щоб не перевищити час виконання бази, а прогрес повертається в реальному часі, по одному рядку для кожного кроку. Перед імпортом будується індекс дедуплікації за трьома ключами — податковим кодом, адресою email і телефоном — і перевіряються адреси: формат, одноразові домени, невалідні шаблони. Та сама організація не потрапляє двічі під двома по-різному написаними назвами.

Кожен дотик записується на картку організації

Дев’ять каналів комунікації, від voice agent і дзвінка людини до візиту, і маршрут із семи стадій із реальними мітками: неконтактований, контактований, відповідь отримано, пропозицію надіслано, активно зацікавлений, переговори, контракт підписано. Біля кожної стадії написано, який відсоток має перейти далі — не як обіцянка, а як орієнтир для того, хто дивиться на воронку і хоче знати, де саме втрачається.

Дзвінок voice agent сам переводить lead далі

Коли агент завершує дзвінок, результат потрапляє в систему через webhook, чий підпис перевіряється: transcript, резюме, sentiment, адреса запису, тривалість. Організація ідентифікується за номером телефону, через функцію, написану в базі для форматів, у яких номери з’являються в реальних даних, а дзвінок прив’язується до її картки. Якщо результат — «зацікавлений» або «зустріч заплановано», lead автоматично підіймається по маршруту, і йому оновлюється дата останнього контакту.

Надсилання має гальма, а не лише прискорення

Робочі години, записані в коді: 08:00–18:00, часовий пояс Кишинів, понеділок–субота. Списки виключення для шкіл, ліцеїв, дитсадків, посольств і консульств. Дедуплікація за адресою, написаною малими літерами — не за організацією, відмінність, яка має величезне значення, коли кілька компаній використовують одну й ту саму поштову скриньку. Охолодження п’ять днів між кампаніями для тієї самої адреси. Глобальна денна стеля, розподілена пропорційно між кампаніями, плюс стеля на запуск, щоб надсилання були розкидані на кілька годин, а не блоком.

Вимикач, який неможливо обійти

Оркестратор кампаній перевіряє змінну середовища перед усім іншим. Якщо вона встановлена, він відмовляється запускатися і виходить — немає аргументу командного рядка, який це обійде, немає «примусово». Це додали 1 травня 2026 року, після інциденту з дубльованими надсиланнями. Система, яка надсилає від вашого імені, потребує зупинки, яку може натиснути людина, що не є програмістом.

Відписка в один клік, у три кроки

Перший крок — стандартний заголовок відписки в один клік, згідно з RFC 8058 — вимога, яку великі email-провайдери ставлять для масових надсилань. Другий — центр уподобань, де відписку можна також скасувати. Третій — повне видалення на вимогу, яке стирає адресу з шести таблиць, додає її до постійного списку блокування і залишає слід у журналі. Усі три захищені токеном, прив’язаним до отримувача, щоб ніхто не міг відписати когось іншого.

Відповіді та реакції збираються самі

Відповіді на email читаються з поштової скриньки через Microsoft Graph, кожні десять хвилин, і автоматично прив’язуються до відправлення, яке їх спричинило. Стан доставки синхронізується від провайдера надсилання. Відкриття відстежуються пікселем, кліки через redirect, а панелі deliverability показують домени з проблемами. Окремий сервіс стежить за кредитом, що залишився, у платних провайдерів і дає сповіщення до того, як він закінчиться — не після.

Пошук за тим, що робить організація, а не лише за тим, як вона називається

Окрім повнотекстового пошуку, запит перетворюється на вектор за допомогою моделі embedding, а зіставлення виконується в базі через власну функцію, з регульованим порогом подібності (за замовчуванням 0,25) і з обмеженням на проєкт. Практично: «фірми, які займаються холодильними перевезеннями» знаходить і організації, у назві яких немає жодного з цих слів.

Підключення до CRM, який у вас уже є

Якщо ваша команда вже працює в CRM, ми не замінюємо її за замовчуванням. Ми написали й запустили конектор для amoCRM — 12 серверних функцій, зокрема повний потік OAuth, оновлення токена та перевірку стану — а також Bitrix24 з OAuth і webhook, гід з OAuth для Zoho та десять функцій для Google Sheets, від читання структури аркуша до імпорту контактів.

Як це виглядає

Шлях, крок за кроком.

Спочатку модель, потім інтерфейс

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

Маршрут і стадії, записані як правила, а не як звичка

Стадії, через які проходить lead, що просуває його далі і що повертає назад, хто за що відповідає на кожній. Ми також пишемо автоматичні правила — який результат дзвінка піднімає lead, яка неактивність опускає його — тому що маршрут, який рухається лише тоді, коли хтось згадає натиснути, — це не маршрут, а список.

Канали, які самі приносять дані

Дзвінки з телефонії або від voice agent, відповіді з поштової скриньки, форми на сайті, webhook-и з інших систем. Кожен канал підключається й тестується окремо, а для кожного ми визначаємо, що відбувається з даними, які не підходять ні до чого в базі — бо саме вони тихо губляться.

Гальма перед прискоренням

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

Передача: процедури, ролі, документація

Хто яку роль має, як додати людину, як зупинити кампанію, куди дивитися, коли щось не пішло, що робити на запит на видалення. Комерційна система, яку вміє зупинити лише той, хто її створив, — це ризик, а не актив.

Канали, що сходяться до однієї картки: дзвінок голосового агента, дзвінок людини, email і відповідь із поштової скриньки, форма на сайті, webhook з іншої системи — і гальма, що вирішують, що йде назад.

Дані

Чого торкаємося, де воно лежить і скільки лишається

Запитання, які ставить кожен, у кого є відповідальний за захист даних, — поставлені тут раніше, ніж їх поставить він.

Де зберігаються дані і як вони структуровані: PostgreSQL через Supabase, із 96 версіонованими міграціями. Структура ієрархічна: проєкти, під ними організації з гнучкими полями в JSONB і вектором пошуку в повному тексті, під ними контакти, а кампанії залежать від проєкту. Кожен проєкт визначає власну схему полів — тому одна й та сама програма обслуговує і публічні адміністрації, і приватні компанії, без збільшення бази для кожного нового типу організації.
Що написано в підвалі кожного надісланого email: Повна ідентичність компанії — назва, податковий код, зареєстрована адреса — адреса відповідального за захист даних, посилання на правову підставу та звідки походить адреса: публічні реєстри й публічні профілі, сказано прямо, а не натяком. Плюс відписка в один клік і резервний варіант із відповіддю одним словом. Те, що стосується правової підстави, перевіряється щоразу при зміні закону — масове надсилання, яке цитує застарілу підставу, є проблемою, навіть якщо решта бездоганна.
Хто що бачить: Доступ здійснюється через автентифікацію, маршрути застосунку закриті за gate, а зона адміністрування має ще один gate. Ролі розділені: адміністрування, власник, продажі, prospectare та окрема роль для автоматичного агента — бо агент, який пише в систему, не повинен мати прав людини. Відкритої реєстрації немає.
Що ми явно перевіряємо під час встановлення: Що кожен секрет фактично налаштований на сервері: секрет, яким підписуються вхідні webhook-и, і секрет, яким підписуються токени відписки. Це перевірки, які здаються формальними, доки не виявляється, що без них не обійтися: перевірка підпису не має з чим порівнювати, якщо секрет відсутній, а передбачуваний токен — це токен, який нікого не захищає. Ми вносимо їх до списку передавання, а не до припущень.
Що видаляється на запит і що залишається: Повне видалення прибирає адресу з шести таблиць і поміщає її до постійного списку блокування, щоб подальший імпорт не міг її повернути. Залишається слід у журналі, з причиною — бо потрібно мати змогу довести, через рік, що запит було виконано. Статистичні агрегати, які нікого не ідентифікують, теж залишаються.

Випадок

Одна адреса отримала 42 email-и за день. Це не було циклом.

Ситуація

У кампанії з пошуку потенційних клієнтів для організацій одна поштова скринька отримала 42 повідомлення того самого дня. Перша, зручна, гіпотеза — це цикл у коді. Ні.

Що ми збудували

Витягування одержувачів було зроблено по організації, а не по адресі. Сорок дві організації використовували ту саму поштову скриньку — цілком звична ситуація в місцевому бізнес-середовищі, де один бухгалтер, материнська компанія або адміністратор обслуговують кілька юридичних осіб. Кожна організація була, коректно, унікальним одержувачем; адреса — ні. Загальна кількість людей, яких зачепив той інцидент, становила 11. Виправлення було з трьох частин, а не з однієї: дедуплікацію перенесли на адресу, записану малими літерами, запровадили охолодження на п'ять днів між кампаніями для тієї самої адреси, а всі скрипти надсилання зобов'язали проходити через спільний модуль захисту — той, що відмовляється реєструвати надсилання без ідентифікатора кампанії. Того самого дня додали й вимикач, який повністю зупиняє оркестратор, без шляху обходу.

Що вийшло

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

Чого цей випадок не каже

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

Питання

Про що нас питають, перш ніж зателефонувати

Ви продаєте CRM, з яким працюєте ви?

Ні, і причина технічна, а не комерційна. Наша система створена під одну команду: у ній немає суворого розділення даних між клієнтами і немає процесу встановлення, який не передбачає доступу до сервера. Щоб її передати комусь, довелося б переписати саме ці дві речі. Ми показуємо її з тієї ж причини, з якої столяр показує свою майстерню — це говорить про ремесло більше, ніж брошура. Ми продаємо побудову системи під те, як працюєте ви.

Чому мені будувати, а не купити готовий CRM?

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

Чи можете ви пов'язати систему з CRM, який ми вже використовуємо?

Так. Ми написали й запустили конектор для amoCRM — 12 серверних функцій, з OAuth-потоком, оновленням токена, отриманням лідів і перевіркою стану — і для Bitrix24, з OAuth і webhook. Для Zoho CRM у нас задокументований OAuth-шлях по регіонах центру обробки даних. А коли реальною джерельною точкою правди для команди є електронна таблиця, у нас є десять функцій для Google Sheets, від читання структури аркуша до імпорту й оновлення контактів.

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

Через підписаний webhook, надісланий у кінці дзвінка. Система бере номер телефону і шукає організацію через функцію, написану з урахуванням форматів, у яких номери з'являються в реальних даних, — а не через порівняння рядків, яке пропустило б половину випадків. Дзвінок зберігається з transcript, резюме, sentiment, адресою запису та тривалістю, прив'язаний до фіші, а правило в коді може перевести lead далі по маршруту залежно від результату дзвінка.

Як ви переконуєтеся, що ми не почнемо розсилати spam?

Через шість механізмів, що перевіряють один одного, а не через добру наміреність: години надсилання, списки виключення за типом установи, дедуплікація за адресою, написаною малими літерами, п’ятиденне охолодження для тієї самої адреси, денні та за один запуск ліміти, і вимикач, який зупиняє orchestrator без обхідного шляху. Нижче — конкретний випадок, який навчив нас, чому дедуплікацію треба робити за адресою, а не за організацією.

Що відбувається, коли хтось просить більше не контактувати з ним?

Він має три рівні, усі захищені токеном, прив’язаним до одержувача. Відписка в один клік, прямо з заголовка email, згідно з RFC 8058. Центр уподобань, де рішення можна й скасувати. І повне видалення, яке прибирає адресу з шести таблиць і додає її до постійного списку блокування — так, щоб імпорт, зроблений через шість місяців, не повернув її назад. Остання частина — це те, що більшість систем пропускає.

Де зберігаються дані і хто може їх бачити?

У базі PostgreSQL, на інфраструктурі, погодженій на початку проєкту, з версіонованими міграціями — тобто кожна зміна структури є файлом, а не ручним втручанням. Доступ розділений за ролями, з окремою роллю для автоматичних агентів, бо система, яка записує в базу, не повинна мати прав людини. Немає відкритої реєстрації і немає публічної поверхні.

Ви можете імпортувати нашу стару базу, разом із дублями?

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

Ви гарантуєте мені зростання продажів?

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

На чому ґрунтуються твердження вище (24 джерел)

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

Як ми працюємо Усі послуги

Що вам хотілося б налагодити?

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

Поговорімо