Nuo gauto el. laiško iki užpildytos „Pipedrive“ kortelės naudojant „n8n“

Dvi dirbtinio intelekto darbo eigos, kurios paverčia neapdorotus potencialių klientų el. laiškus struktūrizuotais CRM įrašais, kurie yra išanalizuoti, įvertinti, patikrinti ir paruošti pardavimų komandai.

Problema: CRM sistema, kuri laukia, kol atsiras laisvas žmogus

„Pipedrive“ įrašas tampa naudingas tik tada, kai žmogus jį užpildo, ir būtent šiame etape pardavimo procesas sustoja. Gaunamas potencialaus kliento laiškas. Kažkas turi jį perskaityti, nuspręsti, kas yra tas asmuo ir kokia organizacija, patikrinti, ar dar nėra įrašo „Pipedrive“, sukurti trūkstamą informaciją, įvertinti, ar verta skambinti potencialiam klientui, ir parašyti instrukcijas paskirtam pardavimo atstovui. Po kelių dienų kažkas kitas grįžta prie šio įrašo ir bando užpildyti tuščius laukelius „sektorius“, „darbuotojų skaičius“, „šalis“, „LinkedIn URL“, ieškodamas informacijos apie įmonę „Google“ paieškoje.

Nė vienas iš šių žingsnių savaime nėra sudėtingas. Tačiau, kai per ketvirtį atsiranda šimtai potencialių klientų, išlaidos kaupiasi taip, kad tai tiesiogiai jaučiama pardavimo procese:

• Gauti laiškai laukia eilėje - potencialių klientų laiškai lieka neperskaityti, kol pardavėjas neatlieka susikaupusių užduočių. Intensyviomis savaitėmis tai gali užtrukti net kelias dienas.
• Sprendimas kontaktuoti su klientu yra nenuspėjamas - tas pardavėjas, kuriam atsitiktinai tenka atidaryti laišką, taip pat sprendžia, ar verta siekti sandorio. Du pardavėjai ne visada sutaria dėl geriausio sprendimo.
• Įrašai gaunami tušti ir lieka tušti - asmuo ar organizacija sukuriami tik su vardu ir pavarde, o ne daugiau, tada savaitėmis laukiama, kol kas nors užpildys likusią informaciją. Remiantis šiais duomenimis sudarytos ataskaitos nepastebimai nukrypsta nuo tikslų.
• Paieška atliekama atsitiktinai - vienas atstovas suranda „LinkedIn“ profilį, kitas – ne. Nėra taisyklės, kad kiekvienas įrašas turi turėti tokią pačią struktūrą.
• Negalima patikrinti detalių - kai užpildomas laukas, nėra įrašo, kas įvedė informaciją, kokia yra šaltinio nuoroda ar kiek jie buvo įsitikinę.

Norėjome pašalinti visus šiuos etapus. Reikalavimai buvo konkretūs: gaunamas el. laiškas per kelias sekundes turėtų sukurti visiškai užpildytą „Pipedrive“ įrašą, kiekviename papildytame laukelyje turėtų būti nurodyta nuoroda į šaltinį ir patikimumo balas, o žmogus turėtų įsikišti tik tada, kai tikrai reikia antros nuomonės.

Dvi darbo eigos, vienas procesas

Sistema susideda iš dviejų nepriklausomų „n8n“ darbo eigų, kurios sąveikauja tarpusavyje. Pirmoji nuskaito gaunamus potencialių klientų laiškus ir paverčia juos „Pipedrive“ įrašais. Antrasis stebi naujai sukurtus asmenų ir organizacijų įrašus „Pipedrive“ ir juos papildo viešais interneto duomenimis. Perdavimas tarp jų yra automatiškas: „Pipedrive“ atnaujinimo trigeris paleidžia papildymo darbo eigą, kai tik pirmoji darbo eiga įterpia įrašą. Nei viena darbo eiga nežino apie kitos egzistavimą. Šios funkcijos siekėme, kad bet kas, rankiniu būdu įtraukiantis „Pipedrive“ kontaktą, gautų tą patį informacijos papildymą.

Sistemos darbą sudaro trys dalys:

1. Gaunamas el. laiškas tampa įrašu

Darbo eiga vyksta trimis atskirais etapais. Pirmasis etapas – priėmimas ir patvirtinimas: el. laiškas patenka į nustatytą el. pašto adresą, „webhook“ perduoda pranešimą „n8n“, o darbo eiga patikrina, ar gavėjas iš tiesų atitinka reikalavimus; viskas, kas neatitinka, yra atmesta dar prieš pradedant kurti CRM įrašą. Tada laiško tekstas suformatuojamas, o griežtai apribotas „OpenAI“ modelis (gpt-5-mini su struktūrizuotu išvesties analizatoriumi) išskiria tik tuos identifikacinius signalus, kurie reikalingi laiškui priskirti asmeniui ir organizacijai. Šiame etape apie patį sandorį informacija neapdorojama.

Antrasis etapas – CRM tapatybės nustatymas. Lygiagrečiai ieškoma organizacijos ir asmens duomenų „Pipedrive“ sistemoje, pasirenkamas labiausiai atitinkantis įrašas arba, jei atitikmens nerandama, sukuriamas naujas įrašas. Jei nepavyksta nustatyti tinkamo asmens ar organizacijos įrašo, darbo eiga baigiasi „trūksta identifikatoriaus“ etapu – geriau palikti neapdorotą el. laišką nei sukurti netinkamai suformuotą sandorį.

Trečiasis etapas – galimybių vertinimas ir sandorio sukūrimas. Antrasis „OpenAI“ modelis paima identifikuotą asmenį ir organizaciją bei sukuria struktūrizuotą galimybių vertinimo ataskaitą, kurioje pateikiamas sandorio pavadinimas, poreikių santrauka, skubumas, pirkimo signalai, rizikos, trūkstama informacija, rekomenduojamas kitas žingsnis, siūlomas atsakymo variantas ir įvertinimas balais nuo 0 iki 100. Šis rezultatas paverčiamas HTML formatuota pastaba, sandoris atidaromas „Pipedrive“ sistemoje, kurioje laukeliai „org_id“ ir „person_id“ užpildomi tik tada, kai šie įrašai iš tikrųjų identifikuojami, o pastaba pridedama. Dviejų LLM atskyrimas yra sąmoningas. Pirmajam iškvietimui nurodoma atlikti tik tapatybės išgavimą. Antrajam iškvietimui nurodoma atlikti kvalifikavimą, bet niekada neišgalvoti tapatybės. Viskas, ką vienas modelis padaro neteisingai, lieka susiję tik su jo paties užduotimi.

2. Kiekvienas naujas objektas papildomas savaime

Duomenų papildymo darbo eiga turi du trigerius, tačiau vieną bendrą procesą. Trigeris, susijęs su „Pipedrive“ asmens duomenų atnaujinimu, ir trigeris, susijęs su „Pipedrive“ organizacijos duomenų atnaujinimu, abu perduoda duomenis į tą patį normalizavimo etapą, kuris generuoja bendrą duomenų paketą, susidedantį iš „entityType“, „entityId“, „known_fields“ ir „missing_fields“. Darbo eiga patvirtina įvykį, paima dabartinį objektą iš „Pipedrive“ (todėl ji remiasi naujausia CRM būsena, o ne „webhook“ delta) ir nusprendžia, ar papildymas iš viso reikalingas. Jei visi palaikomi laukai jau užpildyti, vykdymas baigiamas be „OpenAI“ pagalbos.

Palaikomi laukai yra sąmoningai apriboti – mes papildome tik tai, ką žinome, kaip patvirtinti:

| Objektas | Pildomi laukai | | ------------ | -------------------------------------------------------------------------------------------------------- | | Asmuo | first_name, last_name, email, phone_number, position, linkedin_person | | Organizacija | company_name, website, linkedin_company, industry, company_size, hq_country, revenue_funding, email |

Jei trūksta laukų, darbo eiga iššaukia „OpenAI“ atsakymo mazgą su įjungta paieška internete. Modelis gauna tik „known_fields“ duomenis, kad galėtų identifikuoti objektą, ir gali grąžinti vertes tik tiems laukams, kurie nurodyti „missing_fields“ sąraše. Trys organizacijos laukai – „industry“, „company_size“ ir „revenue_funding“ – yra susieti su kontroliuojamais žodynėliais, kurie atitinka „Pipedrive“ enum parinkčių ID. Kiekvienas grąžintas laukas turi tris dalykus: vertę, viešo šaltinio, kuriame jis buvo rastas, nuorodą ir pasitikėjimo balą: aukštą, vidutinį arba žemą.

Po patvirtinimo darbo eiga iš naujo paima objektą iš „Pipedrive“ prieš pat įrašymą, atsižvelgiama į bet kurį lauką, kurį žmogus įvedė darbo eigos viduryje. Atnaujinimo duomenų paketas apima tik tuos laukus, kurie vis dar yra tušti; esamos reikšmės praleidžiamos su „skipped_existing“ būsena. Jei bet kuris atnaujintas laukas grįžo su žemu patikimumo įvertinimu, darbo eiga priskiria žymą „Enrichment: Review Needed“, kitais atvejais – „Enrichment: Enriched“. „Pipedrive“ pastaboje tiksliai aprašoma, kurie laukai buvo atnaujinti ir kuriuos reikia peržiūrėti dar kartą. Tuo pačiu metu į „Baserow“ įrašoma audito eilutė su vienu stulpeliu kiekvienam {field}_value, {field}_source, {field}_confidence, {field}_status, taip pat objekto ID, „Pipedrive“ pavadinimu apdorojimo metu ir praturtinimo žymos veiksmu.

3. Visas procesas nuo pradžios iki pabaigos

Paanalizuokime tikrą laišką, naudotą testavimo metu: trumpą žinutę iš [email protected], kurioje aprašomas „AAI-Labs“ susidomėjimas potencialių klientų pritraukimu ir CRM automatizavimu bei prašoma susitarti dėl pokalbio.

1-asis darbo srautas patikrina gavėją ir išskiria tapatybę: asmuo Andrius Tamulevicius, organizacija „AAI-Labs“. Kadangi nė vieno iš šių įrašų nėra, abu sukuriami. Pardavimo galimybių patikrinimas grąžina 82/100 balų įvertinimą, atitikimą „Stiprus atitikimas“, skubumą „vidutinis“, pirkimo signalų sąrašą ir rizikos sąrašą (nenurodytas biudžetas, nepateikta sprendimų priėmimo teisė, nenurodytas įgyvendinimo terminas). Tada 1-asis darbo srautas atidaro sandorį „AAI-Labs – potencialių klientų pritraukimas ir CRM automatizavimas“, susieja naują asmenį ir organizaciją bei prideda pardavimo galimybių patikrinimo pastabą.

Sukūrus organizaciją „AAI-Labs“ sistemoje „Pipedrive“, paleidžiamas darbo srautas Nr. 2. Organizacija įtraukiama tik su pavadinimu; darbo srautas nustato, kad trūksta septynių iš aštuonių palaikomų laukų, ir išsiunčia užklausą duomenims papildyti. Modelis grąžina svetainės adresą https://www.aai-labs.com/ (didelis patikimumas), LinkedIn https://lt.linkedin.com/company/aai-labs (didelis patikimumas), industrija "Technologijos, informacija ir žiniasklaida" (vidutinis patikimumas), įmonės dydis "51-200" (didelis patikimumas, siejamas su employee_count: 125), šalis "Lietuva" (didelis patikimumas) ir el. pašto adresas [email protected] (didelis patikimumas). Pajamų finansavimas grąžinamas kaip nulinis, nes nėra viešų šaltinių, kurie tai patvirtintų. Darbo eiga iš naujo atsisiunčia organizaciją, patvirtina, kad kiekvienas tikslinis laukas vis dar yra tuščias, įrašo atnaujinimą, pritaiko „Enrichment: Enriched“ žymą, įterpia pastabą ir išsaugo audito eilutę „Baserow“.

Asmens duomenų papildymas yra labiau konservatyvus. Atskirame bandyme buvo sukurtas įrašas su vardu Tadas Šubonis ir organizacija *AAI-Labs, *darbo eiga rado ir papildė Aistis Raudys su el. paštu [email protected] (didelis patikimumas), LinkedIn https://www.linkedin.com/in/aistis-raudys-80497b6 (didelis patikimumas), ir užimama pozicija "CEO" (mažas patikimumas). Kadangi pozicijos patikimumas buvo žemas, buvo pritaikyta žyma Enrichment: Review Needed, o pastaboje pozicija buvo aiškiai pažymėta kaip reikalaujanti patikrinimo.

Nuo to momento, kai laiškas pasiekė el. pašto adresą, iki to momento, kai kiekvienas įrašas buvo papildytas, patikrintas ir susietas, niekas nelietė klaviatūros.

Kaip iš tikrųjų vyksta įrašymo procesas

Sandorio kūrimo darbo eiga apima maždaug dvidešimt mazgų, suskirstytų į tris etapus; duomenų papildymo darbo eiga apima dvidešimt aštuonis mazgus, paskirstytus tarp bendrojo procesų srauto ir konkretiems objektams skirtų įrašymo šakų. Verta atidžiau pažvelgti į keletą šio proceso etapų, nes būtent juose užtikrinama didžioji dalis saugumo savybių.

Tapatybės išgavimas - gpt-5-mini su struktūrizuotu išvesties analizatoriumi iš patvirtinto el. laiško išgauna tik asmens ir organizacijos tapatybę. Sistemos užklausa draudžia sandorio išgavimą šiame etape, reikalauja, kad nežinomi laukai būtų grąžinami kaip tušti ir atmeta bendruosius el. pašto domenus (gmail.com, outlook.com, proton.me) kaip organizacijų domenus, nebent el. laiško tekste tai būtų aiškiai nurodyta.

„Pipedrive“ atpažinimas ir sandorio sukūrimas - lygiagrečios šakos ieško „Pipedrive“ asmens ir organizacijos, pasirenka panašiausią atitikmenį arba sukuria objektą, jei tokio nerandama. Tada antrasis „OpenAI“ modelis atlieka pardavimo galimybių patikrinimą pagal atpažintą CRM kontekstą. Sandoris sukuriamas su „org_id“ ir „person_id“, užpildytais tik tada, kai tie įrašai iš tikrųjų atpažįstami, taip išvengiant neteisingų tuščių CRM ID.

Papildymas internetine paieška- GPT-5.2 atsakymų mazgas, kuriame įjungta internetinė paieška, gali ieškoti tik trūkstamų laukų ir grąžinti fiksuotą JSON struktūrą { entityType, results: { <field>: { value, source, confidence } }, unresolved_fields: [] }. Sistemos užklausos laukelyje nurodytos konkrečios laukų taisyklės užkerta kelią dažniems gedimams: tik įmonės svetainės nuoroda, tik „LinkedIn“ nuoroda, priklausančios atitinkamam subjektui, tik pramonės šakos vertės iš leidžiamų verčių sąrašo.

Patikrinimas, pakartotinis duomenų gavimas, įrašymas - mazgas išanalizuoja atsakymą, pašalina visas „Markdown“ ribas, patikrina, ar rezultate yra visi prašyti laukai, ir atmeta kontroliuojamo žodyno reikšmes, kurios neatitinka leistinų sąrašų. Įrašas iš „Pipedrive“ pakartotinai gaunamas prieš pat atnaujinimo duomenų paketo sudarymą, o įrašomi tik tie laukai, kurie pakartotinai gautame įraše vis dar yra tušti. El. pašto ir telefono atnaujinimai sujungiami su Pipedrive pažymėtais masyvais, o ne perrašomi.

Pakeitimų žurnalas - kiekvieno vykdymo metu sukuriama Baserow eilutė su stulpeliais {field}_value, {field}_source, {field}_confidence, {field}_status. Būsenos reikšmės tiksliai atspindi, kas buvo atlikta su kiekvienu lauku: updated, updated_new, updated_merged, skipped_existing, skipped_no_value, skipped_no_mapping arba unresolved.

Kaip tai atrodo kasdieniame darbe

Abu darbo srautai nuo pat įdiegimo yra numatytasis būdas tvarkyti gaunamas potencialių klientų užklausas.

• Potencialaus kliento laiškas tampa įrašu dar prieš kam nors jį perskaitant - kai pardavimo atstovas ryte atidaro „Pipedrive“, kiekvienas per naktį gautas laiškas jau yra naujas įrašas, susietas su realiu asmeniu ir organizacija.
• Pardavėjai į pokalbius ateina jau susipažinę su informacija - kiekvieno sandorio „Pardavimo galimybės patikrinimo“ pastaboje nurodomas tinkamumas, skubumas, pirkimo signalai, rizika ir siūlomas atsakymo kampas, ir niekam nereikia to rašyti.
• Nebėra pusiau tuščių kontaktų kortelių - asmens ar organizacijos įrašas „Pipedrive“ niekada neegzistuoja tik su vardu; duomenų papildymas prasideda tuo momentu, kai įrašas sukurtas, nesvarbu, ar šaltinis buvo įeinantis laiškas, ar rankinis įvedimas.
• Kiekviena reikšmė yra pagrįsta - šaltinio nuoroda ir patikimumo balas rodomi šalia laukelio, todėl pardavimo atstovas, pastebėjęs kažką neįprasto, iš pirmo žvilgsnio gali suprasti, iš kur tai atsirado.
• Įrašai, kurių patikimumas yra žemas, reikalauja pakartotinio patikrinimo - įrašai, kuriuose yra bent vienas žemo patikimumo laukas, pažymėtas žyma Enrichment: Review Needed žyma; kiti įrašai pažymėti Enrichment: Enriched ir gali būti laikomi teisingais.
• Istorija nesaugoma pačioje „Pipedrive“ sistemoje - saugo nuolatinį kiekvieno apdorojimo įrašą, kuriame nurodoma, kas buvo pakeista, kas praleista ir kodėl, net jei vėliau kas nors rankiniu būdu redaguoja „Pipedrive“ įrašą.

Klausimai, kuriuos vis dar nagrinėjame

Sistema apima pagrindinį procesą, tačiau sąraše jau yra keletas tolesnių veiksmų:

• Pažangesnis asmenų identifikavimas - elektroninio pašto domeno, organizacijos ir vardo derinimas, kai didelės kalbos modelis (LLM) remiasi nepakankamais duomenimis. Kartais pastebime tikslų atitikimą, pagrįstą silpnesniais įrodymais, nei norėtume.
• Griežtesnis „LinkedIn“ šaltinių atrinkimas - „LinkedIn“ nuorodos gaunamos iš internetinės paieškos, o ne iš „LinkedIn“ API, todėl kokybė priklauso nuo to, kas paieškoje užima pirmąją vietą. Dar labiau apribojus šaltinius, sumažėtų mažai patikimų pozicijų rezultatų skaičius.
• Sandorių darbo eigos audito registravimas - duomenų papildymo darbo eiga jau įrašo kiekvieną vykdymą į „Baserow“. Sandorių kūrimo darbo eiga to nedaro, išskyrus sandorį ir pastabą, kurią ji palieka „Pipedrive“. Atitinkama sandorių audito lentelė užbaigtų ciklą.
• Laikinoji saugykla neaiškiems el. laiškams - dabar sandorio tvarkymo procesas saugiai sustabdomas, jei nepavyksta identifikuoti nei asmens, nei organizacijos. Specializuota peržiūra leistų išskirti tokius laiškus, neapkraunant sandorių lentos.
• Nuolatinis užklausų tobulinimas - abi didžiojo kalbos modelio (LLM) užklausos nuolat tobulinamos, stebint, kur modelis klysta analizuodamas tikrus el. laiškus.

Ką darysime toliau

Sudėtingiausia CRM dalis – ne „Pipedrive“. Tai laikas, kuris praeina nuo el. laiško gavimo iki to momento, kai kas nors jį paverčia struktūrizuotu įrašu – tarpas, per kurį potencialūs klientai praranda susidomėjimą, laukeliai lieka tušti, o kvalifikavimas atidedamas į kalendorių. Įprasti CRM įrankiai patys negali užpildyti šios spragos, nes šis darbas – pusiau vertinimas (ar verta skambinti šiam potencialiam klientui?) ir pusiau tyrimas (kur įsikūrusi ši įmonė, kas jai vadovauja, kokio dydžio ji yra?). Anksčiau abiem atvejais reikėjo žmogaus prie klaviatūros.

Keletas dizaino sprendimų padarė skirtumą, ir mes juos taikysime kiekviename projekte, susijusiame su įrašų sistema. Papildyk tik tai, ko trūksta, niekada neliesk laukelio, kurį jau užpildė žmogus. Prieš bet kokį įrašymą iš naujo atsisiųsk tikslų šaltinį, kad darbo eiga nepralaimėtų lenktynių su žmogumi, redaguojančiu tą patį įrašą. Šaltinio nuorodą ir patikimumo balą laikyk šalia kiekvienos vertės, nes skaičius be kilmės yra tik spėjimas duomenų bazėje. Apribokite modelį iki tam tikrų žodžių tuo momentu, kai reikia konkretaus sąrašo. Ir leiskite įvykiams pradėti savo pačių papildymą, kad sistema pati užpildytų save pagal numatytuosius nustatymus, o ne lauktų, kol kas nors prisimins, kad ji turi atlikti darbą.