Opprette en autonom CRM-hendelsesetterforsker med Nova

Jeg har brukt en betydelig del av karrieren min på å arbeide tett med CRM-data. Og hvis det er én ting som aldri har sluttet å være frustrerende, er det dette: I det øyeblikket en varsling forteller deg at en leadkilde har falt, vet du allerede at det vanskelige ikke er selve oppdagelsen. Det vanskelige er alt som kommer etterpå.

I denne artikkelen ville jeg se nærmere på dette fra en mer detaljert vinkel.

Mønsteret var alltid det samme: Antall leads fra kilde X i Tyskland faller over natten. Varselet utløses. Du åpner SQL-klienten din, begynner å lage hypoteser og kjører den første spørringen. Resultatet endrer neste hypotese. Du kjører en ny spørring. Og så en til. Er nedgangen isolert til Tyskland, eller rammer den den samme kilden i andre markeder også? Sviktet pipelinen på et bestemt tidspunkt, eller var det gradvis? Er det et problem på skjemanivå, eller noe i den bredere kildefamilien? 

Hver hendelse så lik ut på overflaten. Undersøkelsen bak var alltid annerledes. Du kunne ikke skrive en fast regel som dekket dem alle, fordi riktig fremgangsmåte avhang helt av hva dataene viste. 

Og når du først hadde svaret, måtte du forklare det. Drift, salg, ledelse. De trengte å handle på det, noe som betydde at du måtte oversette spørreresultater til et klart og nøyaktig språk, og gjøre det raskt. Denne oversettelsen skjedde hver eneste gang. Det var repetitivt, det var tidkrevende, og det fantes ingen måte å generalisere det med regler.

Jeg begynte å tenke på dette prosjektet ikke som et bidrag til en hackathon, men som en løsning på noe som virkelig hadde plaget meg i årevis.

Den autonome CRM-hendelsesetterforskeren er et agentbasert system bygget på Amazon Nova Pro V1 gjennom Amazon Bedrock, der Amazon Athena håndterer kjøring av spørringer.

Deteksjonssteget er enkel SQL. En forberedende spørring sammenligner de siste 28 dagene med CRM-data mot de siste 7 dagene, og flagger enhver kombinasjon av kilde og land med et volumfall på over 50 %. Den delen trenger ikke en språkmodell.

Det som skjer videre, trenger derimot det. Hver flaggede anomali sendes til Nova Pro V1 sammen med et avgrenset sett med forhåndsregistrerte navngitte Athena-spørringer. Nøkkelordet er avgrenset. Nova får ikke tilgang til vilkårlig SQL. Den får tilgang til nøyaktig de spørringene som er relevante for denne typen hendelser: volumtrend dag for dag, volum for land i samme gruppe, kildefamiliens peers i andre land, tidsstempel for sist sett og et utvalg på radnivå for endelig inspeksjon.

Nova leser resultatet av hver spørring før den bestemmer seg for om den skal kalle den neste. Hvis de to første spørringene slår fast at fallet gjelder hele landet, tilfører ikke kildefamiliespørringen noe. Nova hopper over den. Hvis bevisene peker i en uventet retning, fortsetter den. Veien formes av dataene, ikke av hardkodet forgreningslogikk skrevet på forhånd av et menneske som ikke kan forutse alle scenarioer.

Sesjonsminnet bærer funn videre mellom anomali-iterasjonene innenfor den samme deteksjonssyklusen. Hvis Nova bekrefter en svakhet som gjelder flere land for den første flaggede kilden, hopper påfølgende undersøkelser for den samme kildefamilien helt over peer-analysen. Systemet gjentar ikke arbeid det allerede har gjort.

Resultatet er en strengt typet JSON-konklusjon: rotårsak, mønsterklassifisering, forklaring i klartekst og operasjonell påvirkning. Klar til å leveres til hvem som helst, teknisk kyndig eller ikke.

Demoen kjøres mot et syntetisk datasett med 500 000 CRM-leadposter som dekker fem måneder, med to bevisste avvik lagt inn i den siste uken. Det første er isolert: FR | LinkedinForm går til null over natten. Det andre er bredere: GB | web_form og DE | web_form faller begge med 85 %, noe som representerer en svikt i en kildefamilie på tvers av flere land.

For det franske avviket kjører Nova hele løpet. Den sporer trenden, sjekker likeverdige kilder i Frankrike, undersøker kildefamilien i andre markeder og henter ut det nøyaktige tidspunktet da pipelinen stoppet.

For det tyske avviket, som følger i samme deteksjonssyklus, identifiserer Nova tidlig at fallmønsteret samsvarer med den flerlandssvakheten som allerede er fastslått for GB | web_form. Spørringen mot kildefamilien hoppes over. 
Færre steg, samme kvalitet på konklusjonen.

Det er dette demoen er laget for å vise. Ikke at systemet kan kalle en spørring. Men at det kan slutte å kalle en når bevisene allerede besvarer det neste spørsmålet.

Demolenke: https://www.youtube.com/watch?v=jmkgq3DpeTc 

Den mest åpenbare fordelen er tid. Gjennomsnittlig tid til løsning for denne typen hendelser går ned fra timer til minutter, uten at en dataanalytiker må stå tilgjengelig og bytte kontekst hver gang en varsling utløses.

Den mindre åpenbare fordelen er imidlertid konsistens. Når et menneske undersøker manuelt, avhenger kvaliteten på resultatet av hvem som gjør det, hvor mye tid vedkommende har, og hvor godt vedkommende kjenner akkurat denne typen avvik. Et autonomt system produserer den samme strukturerte utdataen hver gang, uavhengig av hendelsesvolum eller tidspunkt på døgnet.

Arkitekturen er ikke begrenset til overvåking av leadkilder. Enhver datahendelse i CRM der hypoteserommet kan defineres på forhånd, er en aktuell kandidat: avvik i konverteringsrate, topper i dupliserte poster og feil i datakvalitet på feltnivå. Det er registreringslaget for verktøy som endres. Agentlogikken forblir den samme.

Neste steg er å koble deteksjonslaget til et eksisterende varslingssystem, slik at undersøkelsen utløses automatisk i stedet for på forespørsel. Det lukker sløyfen fullstendig og gjør det som i dag er et verktøy du kjører, til et system som kjører seg selv.

Kildekoden er offentlig. Stacken består av Python, Boto3 og aktive AWS-legitimasjoner med tilgang til Bedrock og Athena. Hvis du allerede bruker AWS, tar oppsettet under tretti minutter.

Github-lenke: https://github.com/selimsevim/nova-crm-investigator