Rinkodaros įrankiai ir CRM: kaip sujungti svetainės lankytojų srautą su pardavimais

1. Nematoma B2B biudžeto skylė: kodėl lankytojai netampa pajamomis Rivilėje

Lietuvos B2B sektoriuje kas mėnesį sudeginama dešimtys tūkstančių eurų „Google Ads“ ir „LinkedIn Ads“ kampanijoms, kurių galutinis rezultatas vadovų ataskaitose tėra abstraktus paspaudimų ir kontaktų formų skaičius. Rinkodaros vadovas džiūgauja dėl 1,80 € kainuojančio paspaudimo ir 120 gautų užklausų, tuo tarpu finansų direktorius (CFO) ir pardavimų vadovas mėnesio pabaigoje mato nepakitusį apyvartos grafiką apskaitos sistemoje „Rivilė ERP“ arba „Directo“. Ši praraja tarp pritraukto srauto ir realių banko išrašų atsiranda dėl vienos priežasties – analitika, svetainės formos, CRM ir buhalterinė apskaita funkcionuoja kaip izoliuotos duomenų salos.

Tradicinis modelis remiasi iliuzija: lankytojas užpildo formą, administratorė rankiniu būdu nukopijuoja el. paštą į CRM arba „Excel“ lentelę, o pardavėjas po trijų dienų paskambina klientui, neturėdamas jokio supratimo, kokias paslaugų skiltis žmogus skaitė, kokią Google paieškos užklausą suvedė ar kiek kartų lankėsi kainoraštyje. Kai po trijų mėnesių derybų pasirašoma 45 000 € vertės sutartis, informacija apie pradinį reklamos šaltinį jau seniai būna palaidota. Rezultatas – CFO reikalauja mažinti rinkodaros biudžetą tiems kanalams, kurie iš tiesų atveda pelningiausius kontraktus, nes niekas nesugeba įrodyti priežastinio ryšio tarp konkrečios „Google Ads“ kampanijos ir sąskaitos-faktūros i.SAF registre.

2. Rinkodaros automatizavimas ir duomenų kelias: nuo GA4 Client ID iki galutinės sąskaitos

Tikrasis rinkodaros automatizavimas B2B segmente prasideda ne nuo automatinių naujienlaiškių siuntimo, o nuo griežto duomenų trasavimo (end-to-end attribution). Kiekvienas svetainės lankytojas privalo turėti skaitmeninį pėdsaką, kuris be nuostolių perduodamas per visą pardavimų grandinę iki pat juridinio dokumento patvirtinimo.

Sisteminė integracija susideda iš keturių kritinių mazgų:

Svetainės lygmuo ir serverinis sekimas: Lankytojui apsilankius svetainėje, „Server-Side Google Tag Manager“ (sGTM) sugeneruoja arba nuskaito client_id, sesijos ID bei UTM parametrus. Užpildžius formą, šie parametrai per paslėptus laukus (angl. hidden fields) arba tiesioginį API iškvietimą kartu su įmonės rekvizitais perduodami į apdorojimo sluoksnį.
Praturtinimas juridiniais duomenimis: Gavus potencialaus kliento įmonės kodą, sistema realiuoju laiku kreipiasi į atviruosius Registrų centro bei VMI / Sodros duomenų šaltinius. Prieš įkeliant užklausą pardavėjui, CRM jau žino įmonės darbuotojų skaičių, apyvartos rėžį, transporto parko dydį bei kredito rizikos rodiklius.
CRM pardavimo stadijos ir konversijų grįžtamasis ryšys: Vadybininkui pakeitus sandorio būseną į „Kvalifikuotas“ arba „Pasiūlymas išsiųstas“, CRM per „Measurement Protocol“ išsiunčia neprisijungusio režimo (angl. offline) konversiją atgal į „Google Ads“ ir „GA4“. Taip reklamos algoritmai optimizuojami ne pagal tuščius formos užpildymus, o pagal realią perkamąją galią turinčius sandorius.
ERP ir el. parašo grandis: Sandoriui pasiekus laimėjimo stadiją, sistema automatiškai generuoja sutartį, nukreipia ją į „Dokobit“ / „Smart-ID“ pasirašymui, o pasirašytą dokumentą kartu su užsakymu per REST API sinchronizuoja su „Rivilė GAMA“, „Directo“ ar „B1.lt“. Sąskaita automatiškai paruošiama i.MAS (i.SAF) teikimui be jokio rankinio duomenų perrašymo.

3. Techninė duomenų srautų architektūra: integracijos magistralė

Norint užtikrinti atsparumą klaidoms ir nepriklausomybę nuo trečiųjų šalių paslaugų trikdžių, architektūroje naudojama asinchroninė pranešimų eilė (angl. message broker) ir centralizuotas API sietuvas. Žemiau pateikta loginė duomenų srautų schema, jungianti lankytojų srautą su buhalterine apskaita.

[Lankytojas: Google Ads / Direct]
       │
       ▼ (HTTPS / Cookies / First-Party)
[Svetainė: Server-Side GTM] ──► Generuoja: Client_ID, Session_ID, UTM
       │
       ▼ (Webhook JSON Payload)
┌─────────────────────────────────────────────────────────────┐
│ Suderinta.lt Integracijos Magistralė (Node.js / Go Engine)   │
│  ├─ 1. Validavimas & Apsauga nuo spamo                      │
│  ├─ 2. Duomenų praturtinimas (VMI / Sodra / Rekvizitai API) │
│  └─ 3. Pranešimų eilė (Redis / RabbitMQ buferis)            │
└──────────────────────┬──────────────────────────────────────┘
                       │
       ┌───────────────┴───────────────┐
       ▼                               ▼
[CRM Sistema]                    [GA4 / Google Ads API]
 ├─ Sandorio sukūrimas            └─ Offline konversijų grąžinimas
 ├─ Kliento istorija                 (GCLID / Value Match)
 └─ Pardavimo kvalifikavimas
       │
       ▼ (Smart-ID / Dokobit API)
[Pasirašyta B2B Sutartis]
       │
       ▼ (REST API / OAuth2)
[ERP Apskaitos Sistema: Rivilė / Directo / B1]
 ├─ Kliento kortelė ir užsakymas
 ├─ PVM Sąskaita-faktūra
 └─ Automatinis eksportas į VMI i.MAS (i.SAF)

Ši architektūra garantuoja, kad net jei buhalterinė sistema vykdo naktinę duomenų bazės archyvaciją arba „Rivilė“ API laikinai nepasiekiamas, užklausos nepradingsta: jos lieka saugioje eilėje ir automatiškai apdorojamos atkūrus ryšį.

4. Procesų palyginimas: rankinis darbas prieš automatizuotą ekosistemą

Daugelis vadovų neįvertina, kiek lėtų, smulkių rankinių operacijų suryja darbuotojų laiką ir sukelia trintį tarp pardavimų bei rinkodaros padalinių. Štai kaip keičiasi įmonės kasdienybė sujungus srauto valdymą su CRM ir apskaitos sistemomis:

Procesas	Tradicinis būdas (Excel / rankinis)	Suderinta.lt individualus sprendimas	Finansinis efektas / sutaupymas
Užklausos fiksavimas	El. laiškas administratorės pašto dėžutėje, vėliau perkeliamas ranka į lentelę. Vėlavimas 2–6 val.	Momentinis Webhook perkėlimas į CRM per <1 s. su praturtinta lankytojo elgsenos istorija.	Nulė vėlavimo rizika; +28% greitesnis pirmasis kontaktas.
Įmonės patikra ir rekvizitai	Pardavėjas rankiniu būdu tikrina Rekvizitai.vz.lt, skaičiuoja apyvartą ir skolas VMI/Sodrai.	Automatinis API užklausimas: apyvarta, darbuotojai, skolos pateikiamos sandorio kortelėje iškart.	Sutaupoma 15 min. kiekvienai užklausai (~45 val./mėn. komandai).
Reklamos atsiperkamumo vertinimas	Subjektyvūs klausimai klientui („iš kur apie mus sužinojote?“); netikslūs duomenys.	GA4 Client ID ir GCLID lydi sandorį iki apmokėtos sąskaitos; offline konversijų sinchronizavimas.	Optimizuojamas ad spend: 20–35% mažiau neefektyvių paspaudimų.
Sutarčių rengimas ir pasirašymas	Word šablono redagavimas, eksportas į PDF, siuntimas el. paštu, skenavimas arba rankinis Dokobit įkėlimas.	Automatinis sutarties sugeneravimas iš CRM laukų ir tiesioginis Smart-ID pasirašymo kvietimas per API.	Sandorio ciklas sutrumpėja nuo 4 dienų iki 4 valandų.
Užsakymo perkėlimas į ERP	Vadybininkas arba buhalteris perrašo užsakymo eilutes į Rivilę/Directo; rankinių klaidų tikimybė.	Dvikryptė REST integracija: užsakymas ir sąskaita sukuriama Rivilėje automatiškai.	0 klaidų sąskaitose; sutaupoma 0,5 buhalterio etato kaštų.
PVM sąskaitų deklaravimas i.MAS	Rankinis duomenų sutikrinimas prieš eksportuojant i.SAF XML failą mėnesio gale.	Standartizuoti ir automatiškai validuoti duomenys be neatitikimų VMI registre.	Eliminuojamos baudos ir delspinigiai dėl vėluojančio teikimo.

5. Finansinis ROI modelis: atsiperkamumo skaičiavimas Lietuvos įmonei

Paimkime realistišką Lietuvos B2B didmeninės prekybos ar inžinerinių paslaugų įmonės pavyzdį: komandoje dirba 5 aktyvūs pardavimų projektų vadovai, 1 rinkodaros specialistas ir 1 apskaitininkas. Įmonė generuoja apie 180 užklausų per mėnesį, vidutinė sandorio vertė – 6 500 €, o vidutinis darbuotojo valandinis kaštas įmonei (su mokesčiais Sodrai) sudaro 20 €/val.

Laiko ir darbo užmokesčio sutaupymas:

Duomenų įvedimas ir tikrinimas: 180 užklausų × 20 min. rankinio darbo = 60 valandų per mėnesį. Finansinė išraiška: 1 200 € / mėn.
Sutarčių ruošimas ir derinimas: Vidutiniškai pasirašoma 30 sutarčių per mėnesį. Rankinis procesas trunka 45 min. vs. automatizuotas 5 min. Sutaupoma 20 valandų per mėnesį. Finansinė išraiška: 400 € / mėn.
Užsakymų perkėlimas į Rivilė GAMA / Directo: 30 patvirtintų užsakymų perkėlimas ir sąskaitų generavimas = 15 valandų buhalterijos darbo. Finansinė išraiška: 300 € / mėn.

Rinkodaros biudžeto efektyvumo didinimas:

Mėnesinis Google ir LinkedIn Ads biudžetas – 3 500 €. Dėl tikslaus offline konversijų grąžinimo į Google Ads algoritmą (atmetant netikslinius paspaudimus ir orientuojantis į sandorius, atnešusius realias pajamas), kampanijų konversijos kaina sumažėja 22%. Tai generuoja mažiausiai 770 € / mėn. vertės grynąjį reklamos efektyvumą arba atveda 4–5 papildomus kvalifikuotus kontaktus be papildomų investicijų.

Bendra mėnesinė ekonominė nauda:

1 200 € + 400 € + 300 € + 770 € = 2 670 € per mėnesį.

Investicija į individualią integraciją ir automatizavimo architektūrą vidutiniškai siekia 5 500 – 7 500 € vienkartinių kaštų. Skaičiuojant konservatyviai, pilnas projekto atsipirkimas (ROI) pasiekiamas per 68–85 dienas nuo sistemos paleidimo dienos.

6. Architektūriniai spąstai ir rizikos: ITP, API ribojimai ir duomenų dubliavimas

Dauguma universalių „no-code“ integratorių (pvz., Zapier ar Make) patiria nesėkmę Lietuvos rinkoje, kai susiduriama su vietine specifika ir griežtais duomenų apsaugos reikalavimais. Štai esminiai spąstai, kuriuos privaloma numatyti architektūros projektavimo etape:

1. Safari ITP ir slapukų galiojimo apribojimai

Nuo „Apple Safari Intelligent Tracking Prevention“ (ITP) įvedimo, kliento pusėje sukurti trečiųjų šalių slapukai ištrinami po 1–7 dienų. B2B pardavimų ciklas dažnai trunka nuo 30 iki 90 dienų. Jei naudojamas įprastas naršyklės Google Analytics kodas, sandorio uždarymo metu pradinis gclid parametras jau būna prarastas. Sprendimas: būtina diegti serverinį žymų valdymą (Server-Side GTM) savo subdomene (pvz., data.jusuimone.lt), kad slapukai taptų pirmosios šalies (angl. first-party) ir išliktų aktyvūs iki 400 dienų.

2. „Rivilė GAMA“ API v2 limitai ir sesijų valdymas

Standartinė Rivilės REST API sąsaja turi užklausų skaičiaus ribojimus ir griežtus autentifikacijos tokeno galiojimo terminus. Tiesioginis svetainės formos kreipimasis į Rivilę be tarpinės eilės (message queue) piko metu gali sukelti klaidą „429 Too Many Requests“, dėl ko prarandamas užsakymas. Duomenų architektūroje privaloma įterpti buferinį sluoksnį (Redis/PostgreSQL), kuris valdo užklausų srautą ir automatiškai atnaujina autorizacijos sesijas.

3. Įmonių duomenų dubliavimas ir PVM kodo validacija

Lietuvos verslo praktikoje vadybininkai dažnai sukuria naujas korteles tai pačiai įmonei, jei skiriasi pavadinimo rašyba (pvz., UAB „Statyba“ vs Statyba, UAB). Integracijoje privaloma naudoti griežtą unikalų raktą – Juridinio asmens kodą (JAR kodą), o PVM kodą prieš perduodant į ERP realiuoju laiku patikrinti ES VIES registre. Jei kodas negaliojantis, sistema automatiškai pažymi įspėjimą CRM kortelėje.

4. BDAR (GDPR) ir duomenų saugyklų lokalizacija

Perduodant fizinių asmenų (vadovų, pirkimo vadybininkų) duomenis, serveriai privalo būti ES jurisdikcijoje. Duomenų srauto negalima nukreipti per nepatvirtintus JAV serverius be atitinkamų SCC sutarčių. Visi IP adresai ir jautrūs identifikatoriai prieš saugojimą turi būti anonimizuojami arba kriptuojami.

7. 4 savaičių diegimo planas: nuo duomenų audito iki pilno konvejerio

Inžinerinis diegimas privalo vykti etapais, nestabdant esamų pardavimų komandos procesų. Štai standartizuotas planas, kaip per vieną mėnesį įgyvendinamas pilnas rinkodaros ir pardavimų sujungimas:

1 savaitė: Architektūros auditas ir duomenų modeliavimas

Esamų svetainės formų, analitikos (GA4) ir UTM žymėjimo struktūros inventorizacija.
CRM duomenų bazės laukų sutikrinimas su buhalterinės programos (Rivilė, Directo ar B1) duomenų schema.
Reikalavimų specifikacija: API prieigos raktų, webhooks palaikymo ir saugumo sertifikatų parengimas.

2 savaitė: Serverinio sekimo ir CRM integravimo sluoksnis

Server-Side GTM konteinerio konfigūravimas įmonės subdomene.
First-party slapukų ir lankytojų elgsenos parametrų fiksavimo skriptų diegimas.
Webhooks sukūrimas: formos užpildymas realiuoju laiku sukuria sandorį CRM sistemoje su pilna UTM ir sesijos atributika.
Registrų centro ir Rekvizitai API prijungimas įmonės duomenų praturtinimui.

3 savaitė: ERP, el. parašo ir grįžtamosios analitikos integracija

Dvikryptės sąsajos tarp CRM ir ERP kūrimas: laimėtas sandoris automatiškai sukuria kliento kortelę ir užsakymo juodraštį Rivilėje.
Dokobit / Smart-ID API integracija automatiniam sutarčių pasirašymo procesui.
Offline konversijų perdavimo konfigūravimas per Google Ads API (Measurement Protocol), siejant laimėtus sandorius su pradiniais GCLID.

4 savaitė: Testavimas ribotoje aplinkoje ir perdavimas komandai

Galutinis duomenų srautų testavimas (Edge-case scenarijai: dubliai, klaidingi PVM kodai, API atsakymų vėlavimai).
Pardavimų komandos ir buhalterijos apmokymas dirbti su automatizuotais statusais.
Sistemos paleidimas į produkcinę aplinką (Go-Live) ir 14 dienų techninė stebėsena.

8. Veikiantis prototipas per 48 valandas

Jei jūsų įmonėje rinkodaros ataskaitos nesutampa su buhalteriniais skaičiais Rivilėje, o vadybininkai vis dar gaišta laiką rankiniu būdu kopijuodami rekvizitus ir pildydami sutartis, nelaukite kito finansinio ketvirčio.

Atsiųskite mums savo esamą pardavimų procesų aprašą, naudojamos svetainės formos pavyzdį arba „Excel“ failą, kuriuo šiandien dalinasi jūsų vadybininkai. Mūsų IT architektai per 48 valandas nemokamai paruoš veikiantį jūsų duomenų integracijos prototipą ir parodys, kaip sujungti lankytojų srautą su realiais pardavimais jūsų esamoje infrastruktūroje.

Turinio rodyklė