Co musí umět vaše CRM data, než do nich pustíte AI
Každý dodavatel vám dnes prodá "AI do CRM". Agenti, asistenti, prediktivní skóring, generované e-maily. Poptávka je obrovská a demo vypadá vždycky skvěle — protože demo běží nad čistými daty.
Pak přijde realita: AI asistent doporučí klientovi produkt, který už tři roky má. Agent odpoví na dotaz podle smlouvy, která byla dávno vypovězená. Skóring se učí z pipeline, kterou obchodníci roky vyplňovali "aby byl klid".
AI nezlepšuje data. AI data zesiluje — včetně těch špatných.
Pět podmínek, bez kterých to nefunguje
Z projektů v bankách a z architektury kolem Salesforce Data Cloudu se mi ustálilo pět podmínek, které si ověřte dřív, než podepíšete AI licence.
1. Jeden klient = jeden profil
Pokud máte téhož klienta třikrát — jednou z e-shopu, jednou z pobočky, jednou z kampaně — AI pracuje se třemi cizími lidmi. Identity resolution je nudná, mravenčí práce, ale bez ní je každá personalizace loterie.
A pozor na opačný extrém: příliš agresivní párování slije dohromady dva různé lidi.
Rozhodnutí, jak pravidla nastavit, se přitom nedělá podle "match rate". Dělá se podle toho, která chyba vás bude bolet víc. V marketingu je duplicita nepříjemná — pošlete něco dvakrát. Chybné sloučení je incident, protože ukážete data jednoho člověka druhému. U obsluhy na přepážce nebo v kontaktním centru je ten poměr ještě vyhrocenější. Takže: zvolte prahovou hodnotu podle ceny obou typů chyby, ne podle procenta spárovaných záznamů.
Druhá věc, kterou si vymiňte předem: sloučení musí být vratné. Zdrojové záznamy a rozhodnutí o spárování zůstávají uložené. Destruktivní merge, po kterém už nezjistíte, co se s čím slilo, je jediná varianta téhle práce, kterou nejde opravit.
2. Jasný zdroj pravdy pro každou entitu
Kde vzniká klient? Kde smlouva? Kde souhlas s marketingem? AI vrstva je systém reference, ne systém záznamu — když nevíte, který systém má pravdu, AI si vybere náhodně a bude si jistá.
Z toho plyne jedno pravidlo, na které se v návrzích zapomíná: v AI vrstvě se nesmí opravovat. Když uživatel opraví, co mu agent řekl, ta oprava musí skončit ve zdrojovém systému. Pokud skončí jen v profilu nad daty, stane se jedna ze dvou věcí. Buď se při dalším načtení ztratí, nebo přežije — a pak máte čtvrtou verzi pravdy, o které nikdo neví, že existuje. To je horší než ta původní chyba.
3. Data musí vědět, kdy přestala platit
Všechny tři příklady z úvodu mají stejnou příčinu a není to kvalita dat v obvyklém smyslu. Ta data byla správná. Jenom už neplatila.
Produkt, který klient měl a už nemá. Smlouva, která byla platná a byla vypovězená. Fáze obchodu, která byla aktuální před osmnácti měsíci. Člověk si tuhle vrstvu domyslí, protože vidí datum a odhadne kontext. Model ne. Bere aktuální stav a historii jako totéž, pokud mu nedáte důvod je rozlišit.
Prakticky to znamená tři věci. Rozlišit stav od události — "klient má produkt" je stav, "klient si produkt sjednal" je událost, a spočítat se z toho dá jen jedno. Mít u atributů, kde to má smysl, platnost od–do, ne jen poslední zapsanou hodnotu. A vědět, jak často se data obnovují, v poměru k tomu, jak často se podle nich rozhoduje. Denní obnova pod rozhodnutím, které se dělá v reálném čase na přepážce, je konstrukční chyba, ne provozní detail.
4. Data, která AI smí vidět
V bance jsme řešili model viditelnosti dat pro tisíce uživatelů — kdo smí vidět kterého klienta. AI agent tuhle otázku nemá menší, má ji větší: jede často s vyššími právy než uživatel, kterému odpovídá.
Ve výsledku máte dva použitelné vzory a musíte si jeden vybrat vědomě. Buď agentovi předáváte kontext tázajícího se člověka a odpověď se počítá v jeho právech — dražší na návrh, ale odpovídá to tomu, co uživatel vidí na obrazovce. Nebo agenta omezíte na dataset, který je bezpečný pro každého, kdo se smí ptát — jednodušší, ale musíte umět říct, co v tom datasetu není a proč.
Třetí varianta, tedy integrační uživatel s právy na všechno a doufání, že se nikdo nezeptá na nic nevhodného, je bezpečnostní incident s konverzačním rozhraním.
Čtvrtá varianta, je opět integrační uživatel, ale se správně zadefinovanými oprávněními k objektům a polím. Nevýhodou může být potřeba mít takových integračních uživatelů více než jednoho, aby se naplnili potřeby více oddělení.
A ještě jedna věc, kterou nikdo nemá v prvním návrhu: co se ptalo a co se odpovědělo, musíte logovat. Odpověď agenta je nová plocha, kde data opouštějí systém. V regulovaném prostředí to není doplněk, ale součást zadání.
5. Rozsah podle use case, ne "všechno pro jistotu"
Platformy jako Data Cloud účtují za konzumaci. Nalít do nich všechna data "ať tam jsou" znamená platit za ingestion, storage i processing dat, která žádný use case nepotřebuje.
Co lidi zaskočí, není ten první import. Je to opakovaný přepočet. V konzumačním modelu roste cena s tím, jak často se nad daty něco počítá — segmentace, párování identit, aktivace. Takže se cena neváže na objem, ale na objem krát frekvence. To je číslo, které v prvním rozpočtu nikdo neuvidí, protože se první měsíc platí za nahrání.
Začněte jedním měřitelným scénářem a datovým modelem pro něj. Nejen kvůli ceně — hlavně proto, že u jednoho scénáře poznáte, jestli ty čtyři podmínky nad ním opravdu platí. U dvaceti to nepoznáte u žádného.
Správné pořadí vrstev
Zdrojové systémy → konsolidace dat s identity resolution → jednotný klientský profil s modelem oprávnění → AI vrstva → měřitelný use case s kontrolní skupinou.
AI je až čtvrtá vrstva z pěti. A ta pátá je stejně důležitá: kontrolní skupina. Pokud nasadíte personalizaci nebo AI doporučení bez kontrolního vzorku, nikdy nedokážete, že to funguje — a za rok nebudete umět obhájit rozpočet.
Dodám k tomu jedno varování z praxe: kontrolní skupinu je snadné navrhnout a těžké udržet. Ve chvíli, kdy první výsledky vypadají dobře, přijde otázka, proč vlastně část klientů necháváme bez toho lepšího zacházení. Argument je pochopitelný a odpověď na něj musíte mít připravenou dřív, než ta otázka zazní. Jinak vám kontrolní skupina zmizí přesně v momentě, kdy začíná být cenná.
Pět otázek na dodavatele, než podepíšete
Krátká verze celého textu, použitelná na schůzce:
- Pod jakým uživatelem agent čte data? A jak se to chová, když se ptá člověk s omezeným přístupem?
- Kde skončí oprava? Když uživatel řekne agentovi, že údaj je špatný, do kterého systému to zapíše?
- Jak často se data obnovují a co stojí jeden přepočet? Ne cena za GB, ale cena za cyklus.
- Která pole jsou pro AI autoritativní a kdo to zdokumentoval? Pokud odpověď zní "vezme si to všechno", nemáte zadání.
- Jak poznáme, že to funguje? Konkrétní metrika a konkrétní kontrolní skupina, jinak si za rok budete gratulovat k něčemu, co byste měli i bez toho.
Pokud dodavatel odpoví na všech pět, mluvíte s někým, kdo to už nasazoval. Pokud odpovídá na první tři obecně a na poslední dvě odkazem na roadmapu, kupujete demo.
Kde tenhle přístup selhává
Aby to nebylo jednostranné: obrácená chyba existuje a je taky drahá.
Když se z "nejdřív data" stane dvouletý datový program bez jediného dodaného use case, není to lepší než koupit AI napřed. Jen se to hůř pozná, protože to zní odpovědně. Datový projekt bez use case nemá kdy skončit — vždycky zbývá jeden systém, který ještě není zapojený.
Rozumná verze je obojí naráz, ale v pořadí: jeden úzký scénář, k němu jen ta data, která potřebuje, a pořádek udělaný jen na nich. Pak druhý scénář, který si část té práce vypůjčí. Pořádek v datech se dělá po scénářích, ne po systémech.
Co si z toho odnést
Otázka nezní "kterou AI koupit". Zní: "Kdybych dnes položil AI agentovi otázku o svém nejlepším klientovi, odpověděl by z dat, za která bych dal ruku do ohně?"
Pokud ne, máte nejdřív datový projekt, pak AI projekt. V tomhle pořadí je to investice. V opačném je to drahé demo.
Ty samé podmínky platí i tehdy, když nechcete agenta, ale jen se chcete svého CRM ptát vlastními slovy — o tom jsem psal v textu Headless CRM: do svého CRM se skoro nedívám.
Připravuji firmám datovou architekturu, na které AI dává byznysový smysl. Domluvme si konzultaci na tvadvisory.cz/kontakt.