Oprettelse af en autonom CRM-hændelsesefterforsker med Nova

Jeg har brugt en betydelig del af min karriere på at arbejde tæt sammen med CRM-data. Og hvis der er én ting, der aldrig holdt op med at være frustrerende, så er det dette: Øjeblikket en alarm udløses og fortæller dig, at en lead-kilde er faldet, ved du allerede, at den svære del ikke er opdagelsen. Den svære del er alt det, der kommer efter.

I denne artikel ville jeg se nærmere på dette.

Mønsteret var altid det samme: Leads fra kilde X i Tyskland forsvinder natten over. Alarmen udløses. Du åbner din SQL-klient, begynder at opstille hypoteser og kører den første forespørgsel. Resultatet ændrer den næste hypotese. Du kører en ny forespørgsel. Så endnu en. Er faldet isoleret til Tyskland, eller rammer det den samme kilde på tværs af andre markeder også? Fejlede pipelinen på et bestemt tidspunkt, eller skete det gradvist? Er det et problem på formularniveau, eller noget i den bredere kildefamilie? 

Hver hændelse så ens ud på overfladen. Undersøgelsen under overfladen var altid anderledes. Man kunne ikke skrive en fast regel, der dækkede dem alle, fordi den rigtige vej afhang helt af, hvad dataene viste. 

Og så, når du havde dit svar, skulle du forklare det. Drift, salg, ledelse. De skulle handle på det, hvilket betød, at du skulle oversætte forespørgselsresultater til almindeligt sprog, der var præcist, klart og hurtigt. Den oversættelse skete hver gang. Den var gentagende, tidskrævende, og der var ingen måde at generalisere den med regler.

Jeg begyndte at tænke på dette projekt ikke som et hackathon-bidrag, men som en løsning på noget, der oprigtigt havde generet mig i årevis.

Den autonome CRM-hændelsesefterforsker er et agentisk system bygget på Amazon Nova Pro V1 via Amazon Bedrock, hvor Amazon Athena står for udførelsen af forespørgsler.

Detektionstrinnet er ligetil SQL. En forberedende forespørgsel sammenligner de seneste 28 dages CRM-data med de seneste 7 dage og markerer enhver kilde- og landekombination med et volumenfald på over 50 %. Den del kræver ingen sprogmodel.

Det, der sker derefter, kræver en. Hver markeret anomali sendes til Nova Pro V1 sammen med et afgrænset sæt præregistrerede Athena Named Queries. Nøgleordet er afgrænset. Nova får ikke adgang til vilkårlig SQL. Den får kun adgang til præcis de forespørgsler, der er vigtige for denne type hændelse: dag-for-dag-volumentrend, volumen for sammenlignelige lande, sammenlignelige kildefamilier i andre lande, tidsstempel for sidste observation og en række-for-række-stikprøve til endelig gennemgang.

Nova læser resultatet af hver forespørgsel, før den beslutter, om den skal kalde den næste. Hvis de første to forespørgsler fastslår, at faldet er landsdækkende, tilføjer kildefamilie-forespørgslen intet. Nova springer den over. Hvis beviserne peger et uventet sted hen, fortsætter den. Forløbet formes af data, ikke af hårdkodet forgreningslogik skrevet på forhånd af et menneske, som ikke kan forudse alle scenarier.

Sessionshukommelsen bærer fund videre på tværs af anomaligennemgange inden for samme detektionscyklus. Hvis Nova bekræfter en svaghed på tværs af flere lande ved den første markerede kilde, springer efterfølgende undersøgelser af samme kildefamilie sammenligningsanalysen helt over. Systemet gentager ikke arbejde, som det allerede har udført.

Outputtet er en strengt typet JSON-dom: grundårsag, mønsterklassifikation, forklaring i klart sprog og operationel påvirkning. Klar til at overrække til hvem som helst, teknisk eller ej.

Demoen kører mod et syntetisk datasæt med 500.000 CRM-leadposter, der spænder over fem måneder, med to bevidst indsatte anomalier i den sidste uge. Den første er isoleret: FR | LinkedinForm falder til nul natten over. Den anden er bredere: GB | web_form og DE | web_form falder begge med 85%, hvilket repræsenterer en fejl i en kildefamilie på tværs af flere lande.

For den franske anomali kører Nova hele forløbet. Den sporer udviklingen, undersøger sammenlignelige kilder i Frankrig, undersøger kildefamilien på tværs af andre markeder og finder det præcise tidspunkt, hvor pipelinen stoppede.

For den tyske anomali, som følger i samme detektionscyklus, identificerer Nova tidligt, at faldmønsteret svarer til den flerlandesvaghed, der allerede er fastslået for GB | web_form. Forespørgslen om kildefamilien springes over. 
Færre trin, samme kvalitet i konklusionen.

Det er det, demoen er designet til at vise. Ikke at systemet kan kalde en forespørgsel, men at det kan lade være med at kalde en, når beviserne allerede besvarer det næste spørgsmål.

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

Den mest oplagte fordel er tid. Den gennemsnitlige tid til løsning for denne type hændelse falder fra timer til minutter, uden at en dataanalytiker skal være til rådighed og skifte kontekst, hver gang en advarsel udløses.

Men den mindre oplagte fordel er konsistens. Når et menneske undersøger manuelt, afhænger kvaliteten af resultatet af, hvem der udfører opgaven, hvor meget tid vedkommende har, og hvor fortrolig vedkommende er med netop den type anomali. Et autonomt system producerer det samme strukturerede output hver gang, uanset antallet af hændelser eller tidspunktet på døgnet.

Arkitekturen er ikke begrænset til overvågning af lead-kilder. Enhver CRM-dataincident, hvor hypotesrummet kan defineres på forhånd, er en kandidat: afvigelser i konverteringsrater, spidsbelastninger i dubletposter og fejl i datakvaliteten på feltniveau. Det er værktøjsregistreringslaget, der ændrer sig. Agentlogikken forbliver den samme.

Næste skridt er at forbinde detektionslaget til et eksisterende alarmsystem, så undersøgelsen starter automatisk i stedet for efter behov. Det lukker kredsløbet helt og gør det, der i dag er et værktøj, du selv kører, til et system, der kører af sig selv.

Kildekoden er offentlig. Stakken består af Python, Boto3 og aktive AWS-legitimationsoplysninger med adgang til Bedrock og Athena. Hvis du allerede er på AWS, tager opsætningen under tredive minutter.

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