За кілька років у CRM накопичується все одразу: один клієнт у трьох картках, порожнє поле «галузь», та сама компанія під назвами «ТОВ „Ромашка“», «Ромашка» і «Romashka Trade». Хочеться віддати це моделі: нехай знайде дублікати, заповнить прогалини й наведе лад.
Модель справді може допомогти. Але якщо вона одразу пише в робочу базу, ви отримуєте не чисту CRM, а CRM, у якій помилки виглядають охайно. Неправильно заповненого поля ніхто не помітить, а невдале об’єднання карток може сховати чужу угоду.
Робоча схема розділяє три кроки: модель пропонує, правила перевіряють, а приймає зміну правило або відповідальна людина. Нижче розберемо, як налаштувати це на вже накопиченій базі. Як зробити, щоб нова заявка без втрат потрапляла в CRM, ми писали в статті про розриви між формою та CRM. Тут ідеться про дані, які вже є в системі.
Що робить модель, що перевіряють правила, що вирішує людина
Моделі добре вдаються задачі, де треба прочитати неструктурований текст:
- дістати назву компанії й посаду з підпису в листі;
- запропонувати галузь або категорію клієнта за описом запиту;
- розкласти вільний коментар менеджера по полях;
- знайти пари карток, схожих одна на одну.
Усе це пропозиції. Чи стане пропозиція даними, вирішують правила, які не залежать від моделі й щоразу спрацьовують однаково:
- у які поля взагалі дозволено писати автоматично;
- які значення допустимі, наприклад категорія лише із затвердженого списку;
- які поля обов’язкові й у якому форматі;
- хто або що має право змінювати конкретне поле;
- які переходи між статусами дозволені.
Там, де правило не дає однозначної відповіді, потрібна людина з іменем, а не «відділ продажів загалом». Наприклад, керівник продажів вирішує спірні об’єднання клієнтів, а адміністратор CRM відповідає за довідники. Якщо відповідального немає, спірні випадки накопичуються, і черга перевірки стає ще одним місцем, де губиться робота.
Запропоноване значення зберігається окремо від прийнятого
Головне рішення: пропозиція моделі не записується в основне поле картки. Вона зберігається поруч і має свій статус.
Що зберігати поруч із пропозицією
- саме значення;
- джерело: лист, документ або коментар, з якого його взято;
- час, коли значення витягнуто;
- хто його запропонував: модель із конкретним налаштуванням, правило чи співробітник;
- статус: запропоновано, прийнято, відхилено, конфлікт;
- хто ухвалив рішення і коли.
Так завжди видно, звідки в картці взялося значення. А ще можна покращувати витягування даних, не змінюючи при цьому непомітно для себе правил, за якими запис вважається коректним.
Перевірене не перезаписується
Якщо значення вже підтверджене, наприклад юридичну назву компанії звірено з договором, нова пропозиція моделі не повинна його замінювати. У разі розбіжності збережіть обидва значення й позначте конфлікт для розбору. Інакше наступний запуск збагачення тихо скасує роботу людини.
Правильний формат ще не означає правду
Правило перевіряє форму, а не факт. Категорія може бути із затвердженого списку й при цьому не підходити цьому клієнтові. Правдоподібна назва компанії пройде будь-яку перевірку текстового поля, але може належати іншій юридичній особі зі схожою назвою. Якщо від факту залежить рішення (знижка, договір, звіт), звіртеся з надійним джерелом або передайте питання відповідальному. Немає підтвердження — значення лишається невідомим.
Звідси два обов’язкові тести. У першому значення порушує правило: категорії немає в списку або формат неправильний. У другому значення виглядає правильним, але нічим не підтверджене. Жодне з них не повинно стати прийнятими даними, але причини відмови різні, і система має показувати, яка саме.
Знайти дублікат і об’єднати картки — різні рішення
Модель уміє знаходити схожі картки. Але чи описують два записи одне й те саме, вирішує бізнес-правило, а не оцінка схожості тексту.
Чому людина, компанія, звернення й угода — різні об’єкти, ми розбирали в статті про заявки в CRM. Для очищення накопиченої бази цього замало: правила об’єднання треба погодити до того, як автоматика почне щось зливати.
Питання, на які варто відповісти заздалегідь
- Які ознаки доводять збіг для кожного типу запису? Для компанії це може бути реєстраційний номер, якщо ви його зберігаєте. Для контакту — особиста підтверджена адреса електронної пошти, але не спільна скринька на кшталт info@.
- Які збіги лише створюють кандидата на перевірку: схоже ім’я, спільна адреса офісу, один поштовий домен?
- Хто вирішує, якщо ознаки суперечать одна одній?
- Які значення полів залишаються після об’єднання і з якої картки?
- Що відбувається з пов’язаними задачами, листами, відповідальним менеджером і відкритими угодами?
Збіг — одне рішення, дія — інше
Правило пошуку знаходить можливі дублікати. Що з ними робити, вирішують окремо, і варіанти мають різні наслідки: попередити менеджера, заборонити збереження, об’єднати автоматично або залишити обидві картки й поставити пару в чергу на перевірку. Для невпевнених збігів розумний останній варіант: показати ознаки поруч і не чіпати записи, доки відповідальний не вирішить.
Під час будь-якого об’єднання зберігайте початкові ідентифікатори та історію: які картки злито, за яким правилом, хто підтвердив. Тоді рішення можна простежити, а в разі помилки зрозуміти, що саме відновлювати.
Приклад: той самий контакт, два проєкти
Приклад умовний. Менеджер із закупівель у дистриб’ютора навесні звертається щодо постачання обладнання, а восени — щодо сервісного договору для іншої філії. Контакт один, проєкти різні. Якщо очищення вирішить, що однакові людина й компанія означають дублікат, друга угода розчиниться в першій, і її ніхто не вестиме.
Тому тестів на об’єднання потрібно щонайменше три:
- Одна людина прийшла через два канали. Система має впізнати наявний контакт.
- Та сама людина почала справді новий проєкт. Нова угода має зберегтися.
- Дві різні людини зі схожими іменами, наприклад однофамільці в одній компанії. Їхні картки мають залишитися окремими.
Система, яка бореться з дублікатами, зливаючи реальних клієнтів в одного, провалила другу половину свого завдання.
Як зрозуміти, що очищення не робить гірше
Почніть із пілоту, у якому модель лише пропонує, а записує людина або правило. Так видно якість пропозицій до того, як вони потраплять у робочі дані.
Головна метрика на цьому етапі — частка помилково прийнятих змін: скільки прийнятих значень і об’єднань згодом виявилися неправильними. Щоб її порахувати:
- регулярно беріть вибірку прийнятих рішень і просіть відповідального перевірити їх заново;
- під час кожного виправлення записуйте причину: неправильне джерело, невдале правило, помилка під час ручної перевірки;
- рахуйте поля й об’єднання окремо, бо неправильна галузь і помилково злиті клієнти коштують по-різному;
- стежте за чергою на перевірку: скільки в ній пунктів і як довго вони чекають.
Не оцінюйте очищення за кількістю видалених дублікатів: така метрика заохочує зайві об’єднання. Який рівень помилок допустимий і коли можна дозволити автоматичне прийняття для окремого типу змін, власник процесу вирішує до пілоту, а не за його підсумками.
Чек-лист перед автоматичним записом
- Для кожного поля відомо, чи можна писати в нього автоматично.
- Пропозиції моделі зберігаються окремо від прийнятих значень, разом із джерелом і часом.
- Підтверджені значення захищені від перезапису, конфлікти зберігаються для розбору.
- Для кожного типу запису описано, які ознаки доводять збіг, а які лише створюють кандидата.
- Для знайденого збігу вибрано дію: попередження, заборона, об’єднання або перевірка.
- Описано, які значення залишаються після об’єднання і що відбувається з пов’язаними задачами та угодами.
- Історія об’єднань і початкові ідентифікатори зберігаються.
- Пройдено тести: порушення правила, непідтверджене значення, два канали, новий проєкт, однофамільці.
- Призначено відповідального за спірні випадки, і зрозуміло, як часто він розбирає чергу.
- Визначено, як рахується частка помилково прийнятих змін і який її рівень допустимий.
З чого почати
Виберіть один тип записів і одну проблему: наприклад, дублікати компаній або порожнє поле «галузь». Опишіть правила для цього випадку й увімкніть модель у режимі пропозицій, без запису в робочу базу. За підсумками першого погодженого періоду подивіться, скільки пропозицій прийнято, скільки відхилено і скільки довелося виправити вже після прийняття. Розширювати автоматику варто, коли ці цифри зрозумілі.
Якщо хочете розібрати такі правила для своєї CRM, розкажіть нам, яка база у вас зараз і що в ній заважає роботі, і ми почнемо з одного типу записів.