Headless CRM: do svého CRM se skoro nedívám

Data ze svého CRM si už skoro nevytahuju klikáním. Zeptám se. "Kolik máme rozjednaných příležitostí a v jaké fázi?" Odpověď přijde za pár sekund — a já jsem přitom neotevřel jedinou obrazovku, nepostavil report ani nepřidal filtr.

Tomu se říká headless CRM. Systém zůstává tam, kde je — vlastní data, logiku, oprávnění a integrace — ale rozhraní, kterým se ho ptáte, je jiné. Chat, agent, BI nástroj, vlastní aplikace. Hlava se odpojila od těla.

Vypadá to jako téma pro vývojáře. Není. Je to rozhodnutí o tom, kam v CRM projektu utratíte peníze.

Cena reportingu není v reportech

Klasický reporting není pomalý kvůli technologii. Je pomalý kvůli cyklu: chci číslo — zadám požadavek — někdo postaví report nebo si i sám postavím report — číslo už neplatí. Ten cyklus se dá zrychlit, ale nedá se zlevnit pod určitou hranici, protože každá otázka má vlastní frontu.

Skutečná cena tohohle modelu není v reportech, které postavíte. Je v otázkách, které nikdo nepoloží. Manažer, který ví, že třetí doplňující dotaz znamená další týden čekání, se u druhého zastaví. Rozhodne se z toho, co má. To se nikde nevykazuje jako náklad, ale je to ten největší.

Když se dá CRM zeptat přímo, ad‑hoc otázka nestojí nic. Přehled ukáže, co se stalo. Analýza řekne proč. A rozdíl mezi nimi není v nástroji, ale v tom, kolik otázek za sebou stihnete položit, než vás to přestane bavit.

Kde to používám

Reporting bez reportů. Pravidelné výkazy zůstávají jako reporty. Všechno ostatní je dotaz. Počet reportů, které někdo musí udržovat, tím dlouhodobě klesá — a to je položka, kterou většina firem nikdy nespočítala.

Vytěžení textu. Nejcennější věci v CRM často nejsou v polích, ale v textu — v poznámkách, popisech, komunikaci. Klasicky se to nefiltruje. Jazykový model to přečte a vytáhne z toho strukturu, která se dá dál počítat. S výhradou, ke které se dostanu níž.

Kontrola kvality dat. Tohle je použití, které jsem původně nečekal a dnes je pro mě nejužitečnější. Otázka typu "kolik příležitostí ve fázi vyjednávání má datum uzavření v minulosti" odhalí stav CRM rychleji než jakýkoli adopční dashboard. Headless přístup je nejlepší auditní nástroj, který na svoje data máte, protože se ptá bez ohledu na to, co obrazovka schová.

Čtyři podmínky, bez kterých to nefunguje

1. Kvalita se přesouvá do datové vrstvy

Headless znamená, že veškerá kvalita je v datech a v API. Pokud máte logiku schovanou v UI — validace navěšená na layoutu, povinné pole jen na obrazovce, proces spuštěný z tlačítka — headless ji obejde.

Rozbije se to asymetricky. Čtení přes API je nevinné. Zápis přes API vytvoří záznam, který by žádná obrazovka nepustila dál: příležitost bez produktu, aktivita bez vazby na klienta, případ bez kategorie. Nikdo si toho nevšimne, protože v UI to nikdo neuvidí — dokud se to za pár měsíců neobjeví v reportingu jako nevysvětlitelná odchylka. Pak se hledá chyba v reportu. Chyba je v tom, že se validace nikdy nepřesunula z obrazovky do modelu.

Praktický test: kolik vašich validačních pravidel je vázaných na page layout nebo record type? To číslo je velikost vaší expozice.

2. Oprávnění platí i bez obrazovky

Model viditelnosti dat musí být na úrovni dat, ne na úrovni layoutu. Agent, který se ptá, jede často pod integračním uživatelem — tedy s vyššími právy než člověk, kterému odpovídá.

U retailové divize velké banky, kde jsem dělal na datovém modelu a modelu viditelnosti, se to ukázalo v celé velikosti. Sdílení tam bylo zčásti navržené "přes obrazovky": kdo vidí co, se řešilo tím, kdo dostane jaký layout a jaký record type. Fungovalo to dokonale, dokud byla obrazovka jediná cesta k datům. Ve chvíli, kdy se objeví druhá cesta, tenhle model neexistuje.

Důsledek není technický, ale právní. Ředitel, který dostane odpověď zahrnující portfolio, ke kterému nemá mandát, není bug. V regulovaném prostředí je to incident, který se hlásí. A oprava se nedělá v agentovi — dělá se v sharing modelu, což je projekt na měsíce, ne úprava promptu.

Když si z tohohle textu odnesete jednu věc, ať je to tato: headless nasazujte až po revizi modelu oprávnění, ne naopak.

3. Jeden zdroj pravdy

Když se zeptáte na číslo a odpověď může vzniknout ze tří míst, headless jen zrychlí zmatek.

Vypadá to jako triviální podmínka, dokud nesáhnete na firmu, která má CRM, ERP a finanční výkaz z Excelu. Pipeline existuje ve všech třech, ve všech třech je jiná a všechny tři jsou obhajitelné, protože každá počítá něco trochu jiného. Klasický reporting tenhle spor drží pod pokličkou, protože každý report má autora, který ví, odkud čerpá. Dotaz autora nemá.

Nejhorší varianta je přechodové období. Když se odstavuje starší CRM a historie aktivit se migruje po částech, existuje legitimní stav, kdy jedna entita žije ve dvou systémech naráz. Tenhle stav je v migračním plánu zdokumentovaný a řízený. Pro dotazovací vrstvu ale znamená, že se odpověď bude měnit podle toho, kterého systému se právě ptáte. Pokud v takové fázi jste, headless odložte, nebo mu explicitně řekněte, který systém platí pro které období.

4. Auditovatelnost

U každé odpovědi musíte umět zjistit, z čeho vznikla. Bez toho je to věštba s pěkným rozhraním.

V regulovaném prostředí to není volitelná vlastnost. Když jsem v bance psal dokumentaci pro regulátora ke správě klíčů a ochraně dat, opakovala se pořád stejná otázka — a je to i ta správná otázka na headless: ukažte mi cestu od výstupu ke zdroji. Odpověď "to řekl model" není odpověď.

Prakticky chcete u každého dotazu vidět dotaz samotný, filtr a identifikátory záznamů, ze kterých číslo vzniklo. Ne jako debug funkci pro architekta — jako standardní součást odpovědi. Pokud si výsledek nemůžete kdykoli rozpadnout na záznamy, nepoužívejte ho pro rozhodnutí, které budete obhajovat.

Pátá podmínka: sémantika

Tuhle jsem si přidal až praxí, protože v původním textu chyběla a je z celé pětice nejpodceněnější.

Datový model může být technicky správný a přitom nečitelný. Pole se jmenuje Custom_Field_12__c. Picklist "Status" má patnáct hodnot ze tří různých období, z toho čtyři nikdo nepoužívá od roku 2019. Slovo "příležitost" znamená v jednom týmu podepsanou smlouvu a v druhém první schůzku. Člověk si to přebere, protože zná kontext a zná historii firmy. Model si to nepřebere. Odpoví — sebevědomě a špatně.

To je nejnebezpečnější režim provozu, jaký může headless mít. Chybějící odpověď si všimnete. Odpovědi, která je vedle, ale vypadá rozumně, si nevšimne nikdo.

Řešení není technické. Je to zdokumentovaná sémantická vrstva: co které pole znamená, která metrika se počítá jak, které pole je pro danou entitu autoritativní, co je deprecated a nemá se používat. Nikdo si tuhle položku do rozpočtu CRM projektu nedá, protože nemá obrazovku a nejde ji odprezentovat. Přesně proto je to první věc, která u headless chybí.

Kde mi to nefungovalo

Čtyři věci, se kterými jsem reálně bojoval. Tři z nich nebyly v AI.

Konektor. Nejslabší místo celého řetězce není model. Je to spojení k datům. Co konektor umí, definuje, na co se vůbec můžete zeptat: které objekty vidí, jestli zvládne agregaci nebo jen vytáhne záznamy, kolik jich vytáhne, pod jakým uživatelem jede. Značnou část času jsem nestrávil formulováním otázek, ale tím, abych z konektoru dostal spolehlivě to, co jsem chtěl. Praktický důsledek: než někomu slíbíte, že se bude CRM ptát vlastními slovy, otestujte konektor na svých třech nejtěžších otázkách. Ne na "kolik máme klientů".

Nepopsaný datový model. Tady jsem strávil nejvíc času a tady se narodila pátá podmínka. Model netuší, že "fáze" znamená na dvou objektech něco jiného, že tři pole jsou pozůstatek po migraci a nemá je používat, ani že vazba vede přes spojovací objekt, který nikdo nepojmenoval srozumitelně. Architekt si to dohledá tím, že se zeptá kolegy nebo to pochopí ze systému. Jazykový model se nezeptá. Vybere. Každou hodinu, kterou jsem neinvestoval do popisu modelu, jsem později zaplatil tím, že jsem ten model vysvětloval v promptu — pokaždé znovu.

Kvalita dat. Odpověď může být technicky správná a byznysově bezcenná. Prázdná fáze, datum uzavření v minulosti, tři verze téhož klienta, vlastník, který ve firmě není. Klasický reporting to zamaskuje, protože každý report má filtr, který někdo roky ladil — a ten filtr je nepsaná institucionální znalost. Dotaz žádný takový filtr nemá. První verze odpovědi je proto vždycky horší než report a není to chyba nástroje. Je to chyba dat, kterou report ukrýval. Odtud se ostatně vzalo použití, které jsem popsal výš: jakmile člověk přestane s tou kvalitou bojovat a začne se na ni ptát, má z toho nejlepší datový audit, jaký si může udělat sám.

AI nástroj si u složitých témat zjednodušoval cestu. Tohle mě překvapilo nejvíc. U komplexní otázky — tři objekty, časové okno, jedna výjimka — nástroj nešel celou cestou. Místo průchodu vazbou odhadl. Místo agregace nad všemi záznamy vzal první stránku a dopočítal. Místo "na tohle nemám data" dodal něco pravděpodobného. U jednoduché otázky si toho nevšimnete, protože výsledek je správný. U složité je to největší riziko celého setupu, protože odpověď zní stejně sebevědomě.

Co s tím funguje: složitou otázku rozpadnout na kroky a každý krok si nechat ukázat. Nebo ji jednou zafixovat jako definovaný dotaz a dál už ji nepokládat volně. Co nefunguje: jedna dlouhá otázka a důvěra.

Co to mění v rozpočtu projektu

Většina CRM projektů utratí velké peníze za obrazovky, které uživatelé pak obcházejí exportem do Excelu. Headless ten problém pojmenuje: neptejte se prvně, jak má obrazovka vypadat, ale jestli datová a API vrstva unese, že na obrazovku nikdo nepůjde.

V praxi to znamená přesun peněz, ne jejich úsporu. Ubere se z UI konfigurace a přidá do datového modelu, API vrstvy, modelu oprávnění, sémantické dokumentace a auditní stopy. Součet vypadá podobně. Rozdíl je v tom, co má trvalou hodnotu: obrazovka je aktivum, dokud se nezmění proces. Čistý datový model a funkční API jsou aktivum bez data expirace, protože se přes ně dá postavit jakékoli další rozhraní — včetně těch, která dnes neznáme.

Neznamená to zrušit UI. Znamená to přestat ho považovat za produkt.

Test na tři čísla

Praktická verze, kterou si můžete udělat sami, bez konzultanta. Vezměte tři čísla, na která se ve firmě nejčastěji ptáte, a u každého odpovězte:

1. Kde vzniká? Jeden systém, nebo tři, které se skoro shodují?
2. Dá se spočítat bez otevření obrazovky? Tedy je ta logika v datech a v API, nebo v tom, jak je poskládaný layout a co dělá tlačítko?
3. Umíte doložit, z jakých záznamů vzniklo? Konkrétní seznam, ne popis metodiky.
4. Znamená pro všechny útvary totéž? Zkuste se zeptat dvou lidí z různých týmů na definici. Když se rozejdou, máte sémantický problém, ne datový.

Pokud vám u kteréhokoli ze tří čísel spadne jakýkoli bod, headless vám ho nespraví. Jen vám ho rychleji ukáže.

Co si z toho odnést

Headless CRM není licence, kterou koupíte. Je to důsledek toho, že máte pořádek v datech, oprávněních, API a definicích. Pokud ho nemáte, headless vám ho nevyrobí — jen vám rychleji ukáže, že ho nemáte.

A to je samo o sobě důvod to zkusit. Nejrychlejší audit CRM, jaký znám, je zeptat se ho na tři čísla, která znáte, a podívat se, co přijde.

Podmínky, které platí pro AI nad CRM daty, platí i tady — jednotný profil, zdroj pravdy, model oprávnění a přiměřený rozsah. Rozepsal jsem je v textu Co musí umět vaše CRM data, než do nich pustíte AI.

Připravuji firmám architekturu, kde je CRM použitelné i bez svých obrazovek. Domluvme si konzultaci na tvadvisory.cz/kontakt.