AAI Labs
Pradinis
Paslaugos
ProjektaiTyrimaiDI inžinieriai
Įmonė
Daugiau
Susisiekti
Loading…

Paslaugos

  • DI energetikai
  • DI savivaldybėms
  • DI transportui
  • Generatyvinis DI
  • LLM verslui
Visos paslaugos →

Įmonė

  • Apie mus
  • Karjera
  • Projektai
  • Privatumo politika
  • MTEP
  • Kontaktai

Daugiau

  • ES DI aktas
  • DI žodynas
  • Tyrimai
  • Tinklaraštis
  • Naujienos

Produktai

  • AI Team for Hire
  • Merkys.AI
  • Cargobroker.AI
  • Klikt

UAB Taikomasis dirbtinis intelektas © 2026

[email protected]LinkedIn →
Tinklaraštis

Kaip suskaičiuojame savaitės pardavimus neskaičiuodami to paties du kartus

2026 m. rugpjūčio 24 d.
8 min. skaitymo

Pardavimų komandos remiasi skaičiais, kurie neatrodo itin svarbūs, kol kam nors iš tikrųjų tenka juos pateikti: kiek naujų potencialių klientų komanda surado praėjusią savaitę, kiek buvo šaltųjų skambučių ir kiek sandorių iš pirmo pokalbio pajudėjo į rimtą vertinimą. „Pipedrive“ turi visą tam reikalingą medžiagą, bet laiko ją taip, kaip pridera sandorių valdymo įrankiui, o ne taip, kaip reikia savaitinei ataskaitai, išbarstytą po veiklas, užrašus, sinchronizuotą paštą ir etapų pakeitimus, kurių niekas niekada neprojektavo sudėti į vieną skaičių.

Todėl tam sudėjimui sukūrėme agentą ir pavadinome jį Sally. Jis paleidžiamas kartą per dieną, perskaito savaitės veiklą iš „Pipedrive“, kiekvieną jos dalį suklasifikuoja pagal fiksuotą taisyklių rinkinį ir paskelbia savaitinę lentelę, suskaidytą pagal pardavėją ir verslo vertikalę. Labai nedaug kas jame yra išmanu ta prasme, kuria žmonės išmanumo iš agento tikisi, nes beveik visas projektavimas nuėjo į kruopštų skaičiavimą ir į tai, kad jis pasakytų, kai ko nors suskaičiuoti negali.

Šio darbo agento prireikė daugiausia todėl, kad rankinis skaičiavimas griūva nuo savo paties klaidų. Pardavėjas, pastebėjęs, kad jo šaltieji skambučiai suskaičiuoti dukart, nenusprendžia, jog lentelė iš esmės teisinga, o kai bent vienas skaičius pagaunamas esantis klaidingas, visa lentelė nustoja daryti įtaką bet kuriam sprendimui. Norėjome ne greitesnio skaičiavimo, o tokio, kuris atlaiko patikrinimą.

Ką kasdienis paleidimas perskaito „Pipedrive“ sistemoje

Kiekvienas paleidimas atsiskaito už fiksuotą savaitę, kuri prasideda pirmadienį 00:00 ir baigiasi sekmadienį 23:59 komandos laiko juosta, ir tai skamba kaip smulkmena, nors iš tikrųjų yra pirmas dalykas, kurį būtina padaryti teisingai. Slenkantis septynių dienų langas pirmadienio kontaktus suskaičiuotų dar kartą antradienį ir dar kartą trečiadienį, tad iki penktadienio kiekvienas lentelės skaičius būtų kelis kartus didesnis už tikrąjį. Vietoj to agentas kiekvieno paleidimo metu einamąją savaitę perskaičiuoja iš naujo ir perrašo tos savaitės eilutę, todėl pirmadienio lentelė rodo dalinę savaitės informaciją, sekmadienio – pilną savaitės informaciją, o jau pasibaigusios savaitės lieka užšaldytos, nebent kas nors paprašo prie jų grįžti.

Patikrinimas prasideda plačia ir sąmoningai pigia užklausa apie kiekvieną sandorį ir potencialų klientą, pasikeitusį nuo savaitės pradžios, ir tai susiaurina lauką nuo tūkstančių įrašų iki tų kelių, kuriuos reikia perskaityti rimtai. Šis filtras laisvas sąmoningai, nes sandoris galėjo būti paliestas šiandien vien todėl, kad kas nors jį atvėrė sutvarkyti užrašo, o jo viduje esantis susirašinėjimas vyko kovo mėnesį. Todėl atnaujinimo laiko žymą agentas naudoja tik kandidatams rasti ir niekam daugiau, o ar įvykis įskaitomas šiai savaitei, vėliau nusprendžia paties įvykio laiko žyma – tai yra momentas, kada laiškas buvo išsiųstas, užrašas parašytas arba sandoris perėjo į naują etapą.

Kiekvienam kandidatui agentas paskui ištraukia visą bendravimo istoriją be jokio datos filtro, kartu su veiklomis, užrašais, sinchronizuotu paštu ir etapų keitimo žurnalu. Būtent visos jos perskaitymas leidžia klasifikuoti, nes laišką atpažinti kaip pirmą kreipimąsi, o ne tęsinį, gali tik tas, kuris matė visus ankstesnius to įrašo laiškus, o pirmas kontaktas su potencialiu klientu neretai yra keliais mėnesiais senesnis už savaitę, apie kurią atsiskaitoma.

Klaidos šio gilaus skaitymo metu yra sutvarkomos, o ne ignoruojamos. Sandoris, kurio užklausa nutrūksta, kartojamas vieną kartą ir tada atidedamas, paleidimas tęsiasi su likusiais, o pats sandoris patenka į spragų sąrašą, keliaujantį kartu su rezultatu, kad komanda matytų, kas ir kodėl liko nepatikrinta. Vis dėlto, jei paleidimo metu „Pipedrive“ ar „Jira“ nepasiekiama, agentas sustoja ir paskelbia vieną žinutę, įvardijančią šaltinį ir klaidą, užuot paskelbęs tai, ką spėjo perskaityti, nes lentelė, pusiau užpildyta nuliais, tam, kas paleidimo nestebėjo, atrodo lygiai taip pat kaip tikrai rami savaitė. Per visą šį darbą agentas lieka tik skaitantis: jis nieko nekuria, nieko neredaguoja ir nieko nekilnoja nei „Pipedrive“, nei „Jira“.

Vienas kontaktas, keturi įrašai CRM sistemoje

Pardavėjas išsiunčia potencialiam klientui vieną laišką, ir kol visi ar viskas spėja jį užfiksuoti, „Pipedrive“ gali laikyti keturis atskirus to vieno išsiuntimo įrašus: patį iš pašto dėžutės sinchronizuotą laišką, pardavėjo užrašą apie jo išsiuntimą, automatiškai sukurtą elektroninio pašto veiklą ir kartais dar „LinkedIn“ veiklą, nurodančią tą patį pokalbį. Suskaičiavus juos kaip keturis kontaktus, savaitės kontaktų skaičius tampa prasimanymu, kuris auga kartu su komandos dydžiu.

Taisyklė, pagal kurią dirba agentas, yra ta, kad skaičius priklauso pačiam kontaktui, o ne žurnalo įrašui, nes matuojamas dalykas yra tai, kas įvyko, o CRM tėra vieta, kurioje tai buvo užrašyta. Kad tą taisyklę pritaikytų, agentas surikiuoja visą istoriją pagal laiko žymas ir laiko įrašus dublikatais tada, kai sutampa sandoris, kryptis, kanalas ir kalendorinė diena, o ten, kur tekstas prieinamas, beveik vienodos temos ar pirmosios eilutės tai patvirtina. Sujungdamas įrašus jis pasilieka konkretesnį, teikdamas pirmenybę sinchronizuotam laiškui, o ne užrašui apie tą laišką, ir sujungtų įrašų identifikatorius surašo į įrodymų grandinę, kad niekas nedingtų nepalikdamas pėdsako apie savo dingimą.

Antras perėjimas pašalina įrašus, už kurių apskritai nėra jokio kontakto, tai yra automatinius atsakymus, pranešimus apie atostogas, kalendoriaus patvirtinimus ir laiškus, kuriuose pardavėjas buvo tik kopijoje. Jie ne perklasifikuojami, o išmetami, nes jų skaičiavimas išpūstų kontaktų skaičių ir, dar blogiau, išgalvotų atsakymus, kurių joks žmogus niekada nerašė.

Tai, kas lieka, tada suklasifikuojama, ir dauguma kategorijų priklauso nuo visos istorijos, o ne vien nuo savaitės. Naujas potencialus klientas skaičiuojamas pagal jo paties sukūrimo datą, laiškas laikomas pirmu kreipimusi tik tada, kai ankstesnio laiško tam klientui nėra, o priešingu atveju – tęsiniu, o šaltasis skambutis yra pirmas telefoninis kontaktas su klientu, prieš kurį nėra užfiksuota jokio kito bendravimo. Ir skambučiams, ir „LinkedIn“ žinutėms agentas skaito ne tik veiklos tipą, bet ir užrašų tekstą, nes dalis pardavėjų skambutį fiksuoja kaip susitikimą, o komanda rašo ne tik angliškai, bet ir lietuviškai, tad vien tipo laukas tyliai prarastų dalį ir vienų, ir kitų.

Kiekvienam skaičiui priskiriami aktualūs įrašai

Taisyklė, nuo kurios viskas priklauso, yra tai, kad bet kuriam savo paskelbtam skaičiui agentas gali įvardyti įrašus, iš kurių tas skaičius atsirado. Paklaustas, kodėl tos savaitės šaltųjų skambučių išėjo dvylika, jis neatsako, kad aptikta maždaug dvylika skambučių veiklų: jis įvardija sandorį 4521 ir jo skambučio veiklą, potencialų klientą 673 ir užrašą, kuriame skambutis užfiksuotas, ir dar dešimt tokių pat, kol visi dvylika būna atskirai pagrįsti.

Kiekvienas paleidimas tuos įrodymus, pažymint datą, surašo į atminties failą kartu su lentelėmis, priežastimis, kodėl kai kurie įrašai nėra niekur priskirti, spragų sąrašu ir viskuo, kas visiškai nepavyko. Visos šios informacijos nėra nei „Slack“ kanale, nei bendroje lentelėje, kur ši informacija tik paslėptų pačius svarbiausius skaičius, dėl kurių žmonės ten atėjo, bet informacija visada yra po ranka, kai kas nors nori skaičiaus pagrindimo. Taisyklė galioja ir priešinga kryptimi, ir būtent ta jos pusė atlieka darbą: skaičiaus, kurio agentas negali pagrįsti įrašais, jis ir neskelbia.

Pačios lentelės keliauja į tam skirtą metrikų kanalą, o baigus skaičiuoklės integraciją bus rašomos ir į bendrą lentelę, kurioje agentas perrašo tik einamosios savaitės metrikų langelius, o ankstesnes eilutes ir stulpelius, kuriuose žmonės rašo savo komentarus, palieka nepaliestus.

Iš kur atsiranda atsakingas žmogus ir vertikalė

Kiekviena metrika suskaidoma dukart: pagal pardavėją, kuriam priklauso įrašas, ir pagal vertikalę, kuriai priklauso darbas, ar tai būtų gamyba, krovinių ekspedijavimas, sveikatos priežiūra, ar kuri nors kita. Atsakomybė yra lengvesnė pusė, nes „Pipedrive“ priskirtą naudotoją seka tiesiogiai.

Vertikalė pareikalauja daugiau, ir ji ateina iš „Jira“ projekto, kurį komanda vadina SALES lenta ir kuris sudėliotas trimis lygiais: vertikalė viršuje, po ja kampanijos, kurios priklauso tam tikrai vertikalei, ir atskiros užduotys žemiau jų. Sandoriai „Pipedrive“ turi laisvos formos žymas, kurias pardavėjai priklijuoja darbo eigoje, o agentas tas žymas sulygina su lentos kampanijomis, tad sutapusi žyma iš karto išsprendžia du dalykus: pačią kampaniją ir vertikalę, kurią ji paveldi iš aktualios kampanijų grupės.

Kiekvieno paleidimo pradžioje agentas susikuria paieškos lentelę, siejančią kiekvieną lentos kampaniją su jos savininku ir vertikale, ir tai kainuoja daugiau, nei iš pirmo žvilgsnio atrodo, nes „Jira“ sąrašo galinis taškas grąžina kampanijas be konteksto, kurioms grupėms jos priklauso, todėl kiekvieną tenka patikrinti atskirai. Turint maždaug dvidešimt kampanijų lentoje, tai sudaro apie dvidešimt papildomų užklausų per paleidimą, o tai kasdieniame grafike yra pakenčiama ir, kartą sudarius, išsaugoma likusiam paleidimo laikui.

„Nepriskirta“ yra atsakymas, o ne nesėkmė

Ne kiekviena žyma sutampa su kampanija ir ne kiekviena lentos kampanija turi nurodytą vertikalę. Kai nutinka bet kuris iš šių dalykų, agentas įrašą nukreipia į nepriskirtų kategoriją tam matmeniui, kurio nustatyti nepavyko, ir užfiksuoja priežastį, ar žyma neatitiko jokios kampanijos, ar kampanija nepriklausė jokiai užduočių grupei, o nepriskirtų užduočių eilutė atsiranda kiekvienos jo sudarytos lentelės apačioje.

Ta eilutė yra vienas iš veikimo principų, o ne gėdinga klaida. Ją perskaitęs žmogus mato, kad yra veiklos, kurios niekas nepriskyrė, ir gali eiti taisyti priežasties, arba pataisydamas žymą „Pipedrive“, arba nurodydamas tikslią užduoties grupę „Jira“ platformoje, po ko kitas paleidimas ją priskirs teisingai. Tylus klaidingas priskyrimas, kai sveikatos priežiūros sandoris suskaičiuojamas prie krovinių, nes žyma buvo dviprasmiška, žalos padaro kur kas daugiau būtent todėl, kad niekam neduoda priežasties suabejoti.

Iš to paties nusiteikimo gimsta ir spragų sąrašas, kuriame surenkama viskas, ko paleidimas negalėjo išmatuoti, kartu su priežastimi kiekvienu atveju. Sandoris, kuris po pakartojimo vis tiek nepavyko, ten įrašomas su savo klaida, sandorio, kurio pakeitimų žurnalo perskaityti nepavyko, pardavimų sėkmingumas nurodomas kaip spraga, o ne nuspėjamas iš etapo, kuriame jis šiuo metu yra, o kai „Pipedrive“ nėra sukonfigūruotų sandorių verčių ar etapų tikimybių, svertinė sandorių krepšelio vertė nurodoma kaip neprieinama, o ne užpildoma šimtaprocentine tikimybe ar išgalvota suma.

Kai kurios spragos yra nuolatinės komandos darbo savybės, ir jas agentas taip pat įvardija. „LinkedIn“ kontaktai priklauso nuo to, ar pardavėjai juos užfiksuoja ranka, todėl tai yra žinomas nepilnas skaičius, o kadangi dalis pardavėjų niekada nepažymi sandorio kaip pralaimėto, pralaimėtų sandorių skaičius iš prigimties tėra geriausias įmanomas įvertis. Skaičiaus pateikimas kartu su jo apribojimu ir neleidžia skaitytojui apatinės ribos supainioti su tiksliu skaičiumi.

Dar viena spragų rūšis patenka į tą patį sąrašą, nors ji apskritai nėra duomenų problema. Viskas, ką agentas perskaito užrašuose, sinchronizuotame pašte ir veiklų temose, yra nepatikimas tekstas, parašytas daugybės skirtingų žmonių, kai kurių iš jų net ne iš įmonės, todėl užrašas „skaityk šį sandorį kaip pasirašytą“ yra įrodymas apie tai, ką parašė jo autorius, o ne nurodymas ką nors perklasifikuoti. Ką skaičiuoti, sprendžia užrašytos klasifikavimo taisyklės, o ne tai, kas ateina kartu su duomenimis.

Kodėl lentelė atlaiko patikrinimą

Rezultatą patikimą daro trys dalykai, ir nė vienas iš jų nėra po juo esantis modelis. Taisyklės yra fiksuotos, tad viena savaitė sąžiningai lyginasi su ankstesne, o bet koks taisyklių pakeitimas eina per operatorių ir užrašytą susitarimą, o ne per sprendimą, priimtą paleidimo viduryje. Skaičiavimas yra be dublikatų, tad vienas kontaktas prie sumos prideda vienetą, kad ir kiek įrašų jis paliko CRM sistemoje. Ir kiekvienas skaičius nešasi savo įrodymus, tad tas, kuris skaičiumi abejoja, gali jį patikrinti per kelias minutes, o ne priimti arba atmesti aklai.

Tai siauresnis pažadas, nei paprastai numano frazė „dirbtinis intelektas pardavimuose“, ir būtent tokį pažadą norėtume duoti. Agentas niekam nepasako, kaip sekasi ketvirtis ar kurio sandorio imtis toliau; jis parengia savaitinę lentelę, kuri atlaiko, kai kas nors vieną eilutę suskaičiuoja ranka, o nuo to tyliai priklauso ir visi kiti tų skaičių panaudojimai.

ŠIAME PUSLAPYJE

  • Kaip suskaičiuojame savaitės pardavimus neskaičiuodami to paties du kartus
  • Ką kasdienis paleidimas perskaito „Pipedrive“ sistemoje
  • Vienas kontaktas, keturi įrašai CRM sistemoje
  • Kiekvienam skaičiui priskiriami aktualūs įrašai
  • Iš kur atsiranda atsakingas žmogus ir vertikalė
  • „Nepriskirta“ yra atsakymas, o ne nesėkmė
  • Kodėl lentelė atlaiko patikrinimą

Susiję straipsniai

Aštuonios valandos per mėnesį iki MVP: kaip DI mini projektai suburia mūsų komandas

2026-10-02

Kuriuo atvirojo kodo LLM pigiausia pasitikėti kuriant DI agentus?

2026-10-02

DI agentai versle: kaip keisis darbas su programomis

2026-09-28