Автор: Надалі. Підготовлено редакцією з використанням ШІ.
У магазині є дві картки зі схожим прізвищем, у готелі — кілька гостей з одним номером телефону, а в сервісній компанії — два контакти з адресою загальної поштової скриньки. Команда хоче прибрати дублікати, але помилкове об’єднання може змішати історію різних людей.
Коротко: доручіть ШІ підготувати чергу підозрілих пар, а рішення про об’єднання залиште відповідальному працівнику. Корисний результат першого проходу — пояснення збігів і суперечностей із посиланням на поля, а не «очищена» база.
Цей посібник для власника МСБ та адміністратора клієнтської бази. Нижче — запропонований редакцією робочий процес, не результат випробування продукту. Він не охоплює об’єднання медичних карток, кредитних справ або інших записів із високими наслідками помилки.
1. Спочатку визначте, що представляє картка
Одна людина може мати кілька замовлень. Компанія може мати кілька філій і контактів. Не починайте зі зменшення кількості рядків: запишіть, чи один запис означає людину, організацію, адресу доставки або окреме звернення. Два замовлення одного клієнта не є дублікатами замовлення лише через однаковий телефон.
Урядова рамка якості даних Великої Британії розрізняє унікальність, повноту й точність. Відсутність повторів сама по собі не доводить, що значення правильні. Ми застосовуємо цю відмінність до клієнтської бази: оцінюйте правильність зв’язування, а не лише число вилучених карток.
Домовтеся, хто може підтвердити особу чи організацію за наявними погодженими джерелами. Не збирайте паспортні дані або інші зайві відомості заради зручності очищення.
2. Залиште оригінал і підготуйте окрему робочу копію
Зафіксуйте дату експорту, систему, фільтр і кількість записів. Збережіть постійний ID кожної картки; номер рядка після сортування для цього не підходить. Перевірку збереження кодів під час передавання описано окремо в посібнику про CSV.
Перший навчальний прохід зробіть на вигаданих даних. Для реальної роботи використовуйте лише дозволений інструмент і погоджені поля. Імена, телефони та історія покупок не стають безпечними для довільного сервісу після заміни ID. Якщо немає погодженого середовища для потрібних даних, залиште порівняння всередині системи або виконайте вручну. Межі передавання даних визначайте до експорту.
Нормалізовані значення зберігайте поряд із початковими. Наприклад, окрема колонка може прибирати зайві пробіли для порівняння. Не перезаписуйте оригінальне ім’я й не дописуйте країну до телефону здогадкою.
3. Побудуйте чергу пар, а не наказ на злиття
Почніть із простих перевірок у наявній системі: точні повтори погоджених ключів, порожні поля, суперечності. ШІ використайте для впорядкування вже відібраних кандидатів і зрозумілого опису причин. У невеликій базі такого помічника може взагалі не знадобитися.
Для кожної пари вимагайте:
- ID обох карток і версію джерела;
- поля, що збігаються, з точними значеннями;
- поля, що суперечать одне одному;
- відсутні відомості та питання для перевірки;
- статус «потребує перевірки», без автоматичного вибору основної картки.
Спільний телефон може належати рецепції або сім’ї. Однакова електронна адреса може бути загальною скринькою компанії. Відмінність у транслітерації може пояснювати схожі імена, але не підтверджує тотожність. Розглядайте ці випадки як причини перевірки, а не готові правила злиття.
Не доручайте моделі об’єднувати цілі групи лише через ланцюжок схожості: якщо A схожа на B, а B на C, з цього ще не випливає, що всі три картки належать одному клієнту.
4. Навчальний приклад: одна адреса, два контакти
Приклад вигаданий. Картки C-014 і C-209 мають однакову загальну адресу електронної пошти компанії, але різні імена контактних осіб. У C-014 зазначено закупівлі, у C-209 — приймання доставки. Інших доказів немає.
Правильний результат цього проходу — пара на перевірку зі збереженими ID і поясненням: збігається адреса, відрізняються ім’я й роль, можлива спільна скринька. Об’єднання не погоджене. Навіть упевнене «це один клієнт» у відповіді ШІ не додає нового доказу.
Уповноважений працівник може встановити, що це дві особи однієї організації. Тоді картки залишаються окремими; за потреби їх пов’язують з організацією тільки підтримуваним і погодженим способом. Жодної економії часу чи зміни продажів цей приклад не демонструє.
5. Погодьте долю кожного поля та пов’язаних записів
Якщо дубль підтверджено, визначте основну картку й джерело значення для кожного конфліктного поля. Новіший запис не обов’язково правильніший. Не переносіть згоду на повідомлення, статус відмови або інші важливі ознаки за принципом «беремо заповнене»; відповідальний має перевірити правила конкретного процесу.
Перед зміною адміністратор читає документацію системи. Наприклад, Microsoft описує для Dataverse, що основна картка зберігається, друга деактивується, а пов’язані нотатки й активності прив’язуються до основної. Це конкретна поведінка продукту, не універсальна гарантія для будь-якої CRM.
Перевірте, що станеться із замовленнями, відкритими зверненнями, балами та інтеграціями саме у вашій системі. Запишіть дозволену зміну, виконавця й спосіб перевірки. Якщо повного відновлення не підтримано, не називайте операцію оборотною: зупиніться до окремого рішення відповідального.
6. Перевірте одну погоджену зміну й виміряйте помилки
Перед виконанням повторно прочитайте поточні картки: після експорту їх могли змінити. Спершу перевірте процес на тестових записах у дозволеному середовищі. Збережіть стан до зміни та журнал: старі ID, новий зв’язок, обрані значення, підстава рішення, хто погодив і хто перевірив результат.
Після зміни звірте зв’язки із замовленнями й зверненнями та потрібні підсумки. Саме зменшення кількості карток нічого не доводить. Відмічайте хибно запропоновані пари, підтверджені дублікати, невирішені випадки й час людської перевірки. Окремо перегляньте вибірку карток, яких пошук не запропонував: інакше ви не оцінюєте пропущені дублікати. Вибірка не доводить повноти всієї бази.
Висновок: починайте з контрольованої черги кандидатів. Злиття виконуйте лише після підтвердження, перевірки залежностей і погодження способу відновлення або його обмежень. Якщо черга забирає більше часу, ніж ручна перевірка, змініть критерії або відмовтеся від ШІ на цьому етапі.
Джерела перевірено 1 листопада 2026 року. Доступність вбудованих функцій залежить від вашої системи та прав; цей процес не потребує придбання нової передплати. Продуктові тести не проводилися.
Обкладинка — повторно використана оригінальна ШІ-ілюстрація Надалі: людина звіряє два друковані записи поруч із калькулятором. Це не реальні клієнтські дані й не фото тестування.
