Projekty

Z exportu databáze na seznam, na který jde volat

Distributor chemických surovin si koupil export z komerční firemní databáze: 228 firem v Německu, Švýcarsku a Nizozemsku, 43 sloupců na firmu. Obchodník ho otevřel, chvíli se v něm hrabal a zavřel ho. Data byla technicky v pořádku a obchodně nepoužitelná.

Co ten seznam ve skutečnosti stál

Cena exportu je ta menší položka. Skutečná cena je čas obchodníka, než z jednoho řádku vznikne hovor: dohledat, kdo ve firmě o nákupu rozhoduje, najít na něj kontakt a ověřit, že firma vůbec ještě funguje a není to konkurence.

• 39 firem mělo v exportu web, který už neexistuje. Zjistíte to až ve chvíli, kdy na něj kliknete.
• 133 kontaktů mělo funkci „Managing Director“. Ředitel nerozhoduje o nákupu suroviny do laboratoře.
• Laboratorní funkci, tedy roli, která o nákupu opravdu rozhoduje, mělo v celém exportu 5 kontaktů.
• Část seznamu byla klientova konkurence, ne potenciální zákazník.

Při zhruba 20 minutách ruční rešerše na firmu je to asi 76 hodin práce obchodníka, než odejde první e-mail. Modelový odhad, ne fakturovaná položka; slouží k porovnání s tím, co pipeline zvládne přes noc.

Řešení

Postavil jsem obohacovací pipeline, která bere export takový, jaký je, a firmu po firmě z něj dělá obchodní nástroj. Ověří, že web žije, přečte, co firma skutečně dělá, a podle toho ji oboduje na relevanci vůči klientovu sortimentu. Konkurenci vyřadí. Teprve u firem, které projdou, dohledává konkrétní lidi a jejich kontakty.

• Skórování relevance podle toho, co je na webu firmy, ne podle NACE kódu v exportu
• Automatické vyřazení konkurence a mrtvých domén
• Dohledání kontaktů s prioritou na role, které o nákupu rozhodují
• Ověření e-mailových adres, aby obchodník nepsal do prázdna

Výsledek

Ta poslední dlaždice je schválně malá. Adres se dohledalo 138, ale ověření není razítko — 68 jich odpovědělo, 18 je odvozených z firemního vzoru, 19 nešlo zkontrolovat a 33 se ukázalo jako neplatných. Právě těch 33 je důkaz, že se ta kontrola opravdu dělá; kdo hlásí samá ověřená čísla, ji nedělá.

Rozpočet na data: nula. Žádná nakoupená kontaktní databáze, žádná licence — veřejné zdroje, vlastní obohacovací pipeline a SMTP kontrola, kterou si pouštím sám. Placené průchody přes komerční databáze byly v nabídce jako doplněk a nakonec se nepoužily. Tohle není o tom, že se dá ušetřit; je to o tom, že ta rešeršní část, za kterou se platí, je ta vlastní.

Obchodník začíná u 143 firem, o kterých ví, proč tam volá, místo u 228 řádků, které musí nejdřív prověřit. Klient je na jeho přání anonymizovaný, živá data v náhledu aplikace jsou skrytá.

Automatizace fakturace

Globální logistická firma zpracovávala mezinárodní fakturaci ručně: tým čtyř lidí přepisoval údaje mezi TMS systémem, celní databází a účetnictvím. Každá zásilka čekala na papírování, v průměru 48 hodin.

Výchozí stav

• 4 pracovníci na plný úvazek jen na přepis dat mezi třemi systémy
• Chybovost ručního přepisu ~3 %, každá chyba znamenala zdržení na celnici
• Fakturace limitovala růst: víc zásilek = víc lidí

Řešení

Postavil jsem event-driven orchestraci nad vlastním middlewarem: každá událost v TMS (naložení, přechod hranice, doručení) automaticky spouští validaci dat, vygenerování celních dokumentů a zaúčtování. Napojil jsem ji na stávající systémy přes API, takže firma nemusela měnit software. Lidé řeší jen výjimky, které pipeline označí k ruční kontrole.

• Napojení na stávající TMS a účetní systém přes API, bez výměny softwaru
• Validační vrstva s pravidly pro 14 zemí
• Dashboard výjimek, tým vidí jen případy vyžadující rozhodnutí

Náhled řešení

Náhled monitorovacího dashboardu pipeline (ilustrační data).

Výsledek

Čísla výše jsou modelovaná, ne naměřená u klienta. Ukazují rozsah a typ dopadu, ne provozní statistiku dodané zakázky. Doložená čísla jsou jenom u studie Galochrom výše.

Interní AI asistent

Interní helpdesk banky dostával přes 900 dotazů denně, od resetů hesel po výklad interních směrnic. Odpovědi hledalo 12 operátorů v dokumentaci čítající tisíce stran. Veřejné AI nástroje byly kvůli regulaci nepoužitelné.

Výchozí stav

• Průměrná doba odpovědi 4,5 hodiny, špičky přes den
• Přísné požadavky: žádná data nesmí opustit infrastrukturu banky
• Znalosti roztříštěné v directivách, wiki a e-mailových vláknech

Řešení

Nasadil jsem stavového konverzačního agenta na architektuře RAG, který běží kompletně v privátním cloudu banky. Vytrénoval jsem ho výhradně na interní dokumentaci; odpovědi dokládá citacemi zdrojů a složité případy předává lidem s celým kontextem konverzace.

• Privátní vektorová databáze, API bez retence dat
• Každá odpověď s odkazem na zdrojovou směrnici, auditovatelnost
• Eskalační protokol: nejistota → předání operátorovi, nikdy odhad

Náhled řešení

Náhled konverzace s interním agentem (ilustrační data).

Výsledek

Čísla výše jsou modelovaná, ne naměřená u klienta. Ukazují rozsah a typ dopadu, ne provozní statistiku dodané zakázky. Doložená čísla jsou jenom u studie Galochrom výše.

Predikce odchodu zákazníků

SaaS platforma pro správu vozových parků ztrácela zákazníky potichu: když klient přestal produkt používat, tým se to dozvěděl až z výpovědi. Customer success reagoval pozdě a plošně.

Výchozí stav

• Měsíční churn 4,1 % a rostl s velikostí zákaznické báze
• Signály odchodu ležely v telemetrii, kterou nikdo nevyhodnocoval
• Customer success obvolával zákazníky naslepo

Řešení

Navrhl jsem prediktivní middleware, který čte telemetrii produktu v reálném čase, skóruje riziko odchodu každého účtu a sám spouští odstupňované zásahy: od personalizovaného onboarding e-mailu po úkol pro account manažera s přesným popisem, co se u klienta děje.

• Napojení na produktovou telemetrii, CRM a e-mailing přes API
• Model rizika přetrénovávaný každý týden na čerstvých datech
• Zásahy eskalují podle skóre, automatika řeší lehké případy, lidé kritické

Náhled řešení

Náhled dashboardu rizika odchodu (ilustrační data).

Výsledek

Čísla výše jsou modelovaná, ne naměřená u klienta. Ukazují rozsah a typ dopadu, ne provozní statistiku dodané zakázky. Doložená čísla jsou jenom u studie Galochrom výše.