Актуализирането на контактни данни, предпочитания и статуси в CRM след взаимодействие или промяна е една от задачите, при които AI днес вече може да поеме голяма част от работата. Не защото AI е достатъчно „умен“, за да разбира клиентите, но защото самата задача изисква малко интерпретация. Промяна на адрес, нов телефонен номер, промяна на статус от лийд към клиент: това са полета, които се попълват, не се оценяват.
Три оси определят това тук: структурираност, обем и цена на грешките.
Структурираността получава висока оценка, защото CRM по дефиниция работи с фиксирани полета. Име, имейл адрес, категория на предпочитания: това са данни с фиксирано място и фиксиран формат. Няма свободен текст, който трябва да се интерпретира, няма контекст, който трябва да се преценява. Това прави задачата подходяща за обработка, базирана на правила: ако поле X се промени в източник Y, актуализирай поле X в система Z.
Обемът също е висок. При компания с обширна клиентска база става дума за десетки до стотици промени на ден, разпределени в отделни, малки действия. Точно вида работа, при която повтарящ се, предвидим модел тежи повече от инцидентните изключения. Висок обем в комбинация с висока структурираност е комбинацията, при която автоматизацията се изплаща най-бързо.
Цената на грешките е по средата. Погрешно актуализиран телефонен номер е неприятен, но обикновено поправим при следващия контакт. При по-чувствителни полета, като предпочитания за плащане или съгласие за маркетингова комуникация, грешките тежат по-сериозно. Затова валидацията не е излишна стъпка, а условие.
Пространството за преценка и клиентският контакт получават оценка от средна до висока, и точно там се крие нюансът. Част от промените на статус са еднозначни: клиент се премества, адресът се променя, готово. Но не всяка промяна е толкова проста. Когато служител в отдел „Обслужване на клиенти“ след телефонен разговор трябва да прецени дали оплакване оправдава промяна на статус на „риск от прекратяване“, това вече не е въвеждане на поле, а преценка. Тази част остава човешка работа, или поне се предава на служител, който одобрява или отхвърля с основание.
При компания с прост клиентски профил и малко изключения делът, който AI може да поеме, е следователно по-висок, отколкото при компания със сложни клиентски отношения, много персонализирани договорености или чувствителни лични данни. Съответствието с нормативните изисквания играе роля и тук: колкото повече дадено поле засяга информация, чувствителна по ОРЗД, или договорни споразумения, толкова по-рано е желателна човешка проверка, преди дадена промяна да стане окончателна.
Технологията, която вече се използва днес, е предимно RPA: софтуер, който според фиксирани правила пренася данни от един източник в друг, сигнализира дублирани записи и попълва полета въз основа на фиксирано съответствие. Това не е изкуствен интелект, който „разбира“ кой е клиентът, а автоматизирана обработка на структуриран вход.
Три гранични условия определят дали това работи:
Ако липсва едно от тези три, задачата се връща обратно към втора категория: AI прави предложението, служител одобрява или отхвърля.
Това, което сега се променя, не е, че служителите стават излишни, а че тяхното време се измества от въвеждане на данни към контролна работа. Докато преди служител преписваше на ръка промяна на адрес, сега той преглежда списък с предложени промени и кликва „одобрено“ или „неодобрено“. Това е различна задача, с различно разпределение на времето, не непременно по-малко работа, но различна работа.
Тази промяна протича успоредно на това, което се случва при въвеждане на поръчки в системата и при проверка и комуникация на статуса на поръчка: и там моделът е структуриран вход, висок обем, ограничена цена на грешките, с изключения, които остават при човек. Който се пита как това се съотнася с други клиентски задачи, ще открие подобно съображение при предоставяне на информация за наличности и срокове за доставка, където действа същото напрежение между скорост и случаите, изискващи малко повече обяснение. А за онези, които разглеждат CRM работата преди всичко като част от по-широк процес, прегледът на работата във финансовия отдел е добра отправна точка, тъй като клиентските и фактурните данни често споделят едни и същи изходни системи.
Дали и колко бързо това ще бъде въведено в дадена организация не е само технически въпрос. Последствията за персонала, които евентуално произтичат от това, попадат под собствените законови изисквания на работодателя; тази страница не се произнася по този въпрос.
Тази страница описва една задача изолирано. Реалната картина възниква едва когато тази задача се разглежда наред с другите задачи в дадена компания: някои с подобен профил, други напълно различни. За да получите първо впечатление от това, има безплатен бърз тест: дванадесет въпроса, без акаунт, с резултат индикация каква част от часовете в този профил днес могат да бъдат поети от AI. Пълният анализ на работата, който разгражда работата на компанията на задачи и изчислява за всяка задача капацитет в еквивалент на пълно работно време, все още е в процес на изграждане.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.