B2B klientų savitarnos portalas: funkcijos, integracija su ERP ir kada jis atsiperka

DESAmedia · 2026-10-27

Trumpas atsakymas

B2B klientų savitarnos portalas yra uždara svetainės ar sistemos dalis, kurioje jūsų verslo klientai prisijungę mato savo kainas, likučius, užsakymus, sąskaitas ir skolas, o užsakymą pateikia patys, be el. laiško ar skambučio vadybininkui. Didmenininkams, platintojams ir gamintojams jis dažniausiai atsiperka ne dėl „naujo pardavimo kanalo“, o dėl to, kad dingsta rankinis užsakymų perrašinėjimas, klaidos kainose ir nuolatiniai klausimai „kur mano siunta“ ar „kiek esu skolingas“.

Portalas veikia tik tada, kai yra tvirtai sujungtas su jūsų apskaitos ar ERP sistema. Būtent integracija, o ne dizainas, nulemia didžiąją dalį projekto sudėtingumo, kainos ir naudos. Šiame straipsnyje aptariame, kokių funkcijų reikia, kaip portalas jungiamas su ERP, kada jis atsiperka ir kokių klaidų verta išvengti.

Kuo B2B portalas skiriasi nuo įprastos el. parduotuvės

Iš pirmo žvilgsnio tai tas pats katalogas su krepšeliu. Skirtumai išryškėja, kai pažiūrite, kaip perka verslo klientai:

Dar vienas skirtumas yra teisinis. Europos prieinamumo aktas (Direktyva (ES) 2019/882) el. prekybos paslaugomis laiko paslaugas, teikiamas vartotojui siekiant sudaryti vartojimo sutartį, o vartotoju laiko fizinį asmenį, perkantį ne verslo tikslais. Todėl portalas, skirtas tik įmonėms, į šią sritį paprastai nepatenka. Jei per tą pačią parduotuvę perka ir privatūs asmenys, reikalavimai taikomi. Plačiau apie tai rašėme straipsnyje apie WCAG ir Europos prieinamumo aktą. Net kai prieinamumas neprivalomas, aiški ir klaviatūra valdoma sąsaja verslo klientams sutaupo laiko.

Kokių funkcijų reikia iš tikrųjų

Nebūtina visko daryti iš karto. Žemiau funkcijos suskirstytos taip, kaip jas dažniausiai rekomenduojame diegti.

Pirmas etapas: be to portalas neturi prasmės

• Individualios kainos. Prisijungęs klientas mato savo kainą, ne bazinę su prierašu „kaina gali skirtis“. Kainos turi ateiti iš tos pačios vietos, kur jas valdote dabar, dažniausiai iš apskaitos ar ERP.
• Likučiai ir pristatymo terminai. Bent jau „yra / nėra / laukiama“ pagal sandėlį. Jei turite kelis sandėlius, verta rodyti, iš kurio prekė bus išsiųsta.
• Greitas užsakymas. Paieška pagal prekės kodą, kiekių įvedimas sąraše, užsakymo įkėlimas iš CSV ar Excel failo ir „pakartoti ankstesnį užsakymą“. Verslo pirkėjas retai naršo kategorijas, jis žino, ko nori.
• Užsakymų istorija ir būsenos. Kas užsakyta, kas patvirtinta, kas išsiųsta, siuntos sekimo numeris.
• Sąskaitos ir skolos. Sąskaitų archyvas PDF formatu, neapmokėtos sumos ir mokėjimo terminai.

Antras etapas: tai, kas sumažina rankinį darbą

• Kredito limitas ir atidėti mokėjimai. Portalas žino, kiek klientui dar galima parduoti skolon, ir pasiūlo apmokėti iš anksto arba sustabdo užsakymą, kai limitas viršytas.
• Keli naudotojai vienoje įmonėje. Pavyzdžiui, statybos įmonės meistras gali sudaryti krepšelį, o pirkimų vadovas jį patvirtina. Buhalterė mato tik sąskaitas.
• Pristatymo adresai. Įmonė su keliais objektais ar parduotuvėmis renkasi adresą užsakydama, o ne rašo jį komentare.
• Dokumentų biblioteka. Sertifikatai, techniniai lapai, atitikties deklaracijos prie konkrečių prekių.
• Pirkimų sąrašai. Klientas išsisaugo dažnai perkamų prekių sąrašus pagal objektą ar padalinį.

Trečias etapas: kai pagrindai veikia

• Grąžinimai ir pretenzijos su nuotraukomis ir būsenomis.
• Komercinių pasiūlymų užklausos didesniems kiekiams, kuriuos vadybininkas patvirtina portale.
• Prieiga per API ar EDI didžiausiems klientams, kurie nori užsakymus siųsti tiesiai iš savo sistemos.
• Ataskaitos klientui: kiek ir ko pirko per metus, pagal padalinius.

Integracija su ERP: kas sinchronizuojama ir kaip

Daugelyje projektų integracija sudaro didesnę darbų dalį nei pati portalo sąsaja. Pirmiausia reikia nuspręsti, kuri sistema yra „tiesos šaltinis“ kiekvienam duomenų tipui.

Lietuvoje dažniausiai jungiamasi su Rivile, Directo, Agnum, Finvalda, Centas ar platesnėmis ERP sistemomis. Kiekviena turi skirtingas API galimybes ir apribojimus. Kaip tai atrodo praktiškai, aprašėme straipsnyje apie integraciją su Rivile, Directo ir Agnum, o apie siuntų jungtis plačiau rašėme kurjerių integracijos gide.

Keli principai, kurie apsaugo nuo daugumos problemų:

1. Kainą skaičiuokite vienoje vietoje. Jei ta pati nuolaidų logika parašoma ir ERP, ir portale, anksčiau ar vėliau jos išsiskirs. Arba portalas gauna jau apskaičiuotus kainoraščius, arba prašo kainos iš ERP užsakymo metu.
2. Užsakymas negali pasiklysti. Jei ERP tuo metu nepasiekiama, užsakymas laukia eilėje ir išsiunčiamas vėliau, o atsakingas žmogus mato, kas įstrigo.
3. Rodykite duomenų amžių. Jei likučiai atnaujinami kas 15 minučių, verta tai žinoti ir klientui, ir jūsų vadybininkams.
4. Žurnalas. Kas, kada ir ką užsakė, patvirtino ar pakeitė. Verslo klientų ginčuose tai pirmas dalykas, kurio paklausiama.

Sąskaitos, terminai ir mokėjimai

Portalas yra patogi vieta rodyti mokėjimo terminus ir skolas, bet čia galioja įstatymas. Pagal Mokėjimų, atliekamų pagal komercines sutartis, vėlavimo prevencijos įstatymą, mokėjimo laikotarpis tarp įmonių negali būti ilgesnis nei 60 kalendorinių dienų, nebent sutartyje aiškiai susitarta kitaip ir tai nėra nesąžininga kreditoriaus atžvilgiu. Kai pirkėjas yra viešasis subjektas, bendra taisyklė yra 30 kalendorinių dienų nuo sąskaitos gavimo. Tas pats įstatymas nurodo, kad sąskaitos gavimo diena laikoma neaiškia, jei sąskaita išsiųsta nesinaudojant elektroninėmis priemonėmis. Sąskaitų archyvas portale su aiškia paskelbimo data padeda išvengti ginčų dėl to, kada sąskaita buvo gauta.

Jei tarp jūsų klientų yra viešojo sektoriaus įstaigų, sąskaitos joms vis tiek turi keliauti per SABIS. Portalas to nepakeičia, bet gali naudoti tą pačią sąskaitų siuntimo logiką. Apie tai išsamiai rašėme straipsnyje apie e. sąskaitas, SABIS ir Peppol.

Gatavas modulis, platforma ar individualus portalas

Yra trys pagrindiniai keliai, ir nė vienas nėra geriausias visiems.

B2B modulis esamai el. parduotuvei. Jei jau turite WooCommerce, PrestaShop ar panašią parduotuvę, prie jos galima pridėti prisijungimą, kainų grupes ir atidėtą mokėjimą. Tai greičiausias ir pigiausias kelias, kai klientų sąlygos paprastos: kelios kainų grupės, vienas naudotojas įmonėje, nesudėtingas ERP ryšys. Problemos prasideda, kai reikia kelių naudotojų su tvirtinimu, kredito limitų iš ERP ar sudėtingų nuolaidų taisyklių. Tada keli įskiepiai pradeda konfliktuoti tarpusavyje.

ERP gamintojo portalas. Kai kurios apskaitos ir ERP sistemos siūlo savo klientų portalą ar el. parduotuvės modulį. Integracijos problema čia išspręsta iš karto, bet ribotos dizaino ir funkcijų galimybės, o portalas atrodo kaip apskaitos programa. Tinka, kai portalas skirtas daugiausia sąskaitoms ir skoloms peržiūrėti.

Individualus portalas. Kuriamas pagal jūsų užsakymo eigą, kainodarą ir ERP. Brangesnis pradžioje, bet lankstesnis, kai jūsų prekyba turi savitą logiką: konfigūruojamos prekės, užsakymai pagal objektus, tvirtinimo grandinės, integracija su keliomis sistemomis. Tokiu atveju svarbu iš anksto aprašyti reikalavimus, kad tiekėjų pasiūlymai būtų palyginami. Tam padės mūsų techninės specifikacijos gidas.

Panašią logiką, kaip rinktis tarp gatavo ir individualaus sprendimo per penkerių metų laikotarpį, taikėme ir straipsnyje apie CRM sistemas.

Kada portalas atsiperka

Konkretaus skaičiaus be jūsų duomenų pasakyti neįmanoma, bet atsipirkimą galima pasiskaičiuoti patiems. Surinkite kelis skaičius už pastaruosius 3 mėnesius:

• kiek užsakymų gaunate el. paštu, telefonu ar žinutėmis ir kiek vidutiniškai laiko užtrunka vieną suvesti į sistemą;
• kiek užsakymų tenka taisyti dėl neteisingos kainos, kodo ar kiekio;
• kiek užklausų vadybininkai gauna apie likučius, siuntas, sąskaitų kopijas ir skolas;
• kiek kartų pardavėte tai, ko sandėlyje jau nebuvo.

Padauginkite valandas iš darbo valandos kainos ir pridėkite klaidų kainą. Jei gaunate tik keliolika užsakymų per mėnesį iš tų pačių klientų, portalas greičiausiai neatsipirks, ir užteks geresnio užsakymų šablono. Jei užsakymų šimtai, o klientų dešimtys ar daugiau, portalas dažnai tampa pigiausiu būdu augti nedidinant pardavimų administravimo komandos.

Nepamirškite ir išlaidų po paleidimo: priežiūra, serveriai, atnaujinimai ir integracijos pakeitimai, kai keičiasi ERP. Kaip skaičiuojama individualios sistemos kaina ir iš ko ji susideda, aptarėme straipsnyje Kiek kainuoja individualios sistemos kūrimas.

Pavyzdys: platintojas, kuris užsakymus gaudavo el. paštu

Įmonė toliau yra išgalvota, skaičiai pateikti tik iliustracijai.

UAB „Šiaurės tiekimas“ platina santechnikos ir šildymo prekes montuotojams ir statybos įmonėms. Klientų yra apie 300, prekių kodų apie 8 000, kainos skiriasi pagal penkias klientų grupes ir individualias nuolaidas didžiausiems klientams. Apskaita vedama Rivilėje.

Užsakymai ateidavo el. paštu kaip Excel failai, nuotraukos ar tiesiog sąrašai laiško tekste. Trys vadybininkai didelę dienos dalį perrašinėjo užsakymus ir atsakinėjo į klausimus apie likučius. Kas savaitę pasitaikydavo užsakymų su sena kaina.

Portalas buvo paleistas dviem etapais:

1. Pirmas etapas (apie 3 mėnesius). Prisijungimas klientams, individualios kainos ir likučiai iš Rivilės, greitas užsakymas pagal prekės kodą, užsakymo įkėlimas iš Excel, užsakymų istorija ir sąskaitų archyvas. Užsakymai keliauja į Rivilę automatiškai.
2. Antras etapas. Kredito limitai, keli naudotojai įmonėje su tvirtinimu, siuntų sekimas ir sertifikatų biblioteka.

Pirmus mėnesius dalis klientų vis tiek siuntė el. laiškus. Padėjo paprastas sprendimas: vadybininkai užsakymą suvesdavo portale kliento vardu ir siųsdavo nuorodą, kad klientas pamatytų, kaip tai atrodo. Svarbiausia nauda buvo ne mažiau darbuotojų, o tai, kad ta pati komanda aptarnavo daugiau klientų, o klaidų dėl kainų beveik neliko.

Dažniausios klaidos

• Pradėti nuo dizaino, ne nuo duomenų. Jei kainų taisyklės ir klientų sąlygos ERP neužvestos tvarkingai, portalas jų nepataisys.
• Kopijuoti B2C parduotuvę. Didelės nuotraukos ir kategorijų naršymas verslo klientui mažiau svarbūs nei greitas užsakymas pagal kodą.
• Nepakviesti klientų. Portalas, apie kurį klientai nežino, nieko nesutaupo. Reikia aiškaus pristatymo, pagalbos pirmiems užsakymams ir vadybininkų, kurie patys juo naudojasi.
• Viską kurti iš karto. Geriau paleisti pagrindą per kelis mėnesius ir plėsti pagal tai, ką klientai iš tikrųjų naudoja.
• Pamiršti teises. Kas įmonėje mato kainas, kas gali užsakyti ir kas tvirtina. Klaidingai sukonfigūruotos teisės reiškia, kad vieno kliento darbuotojas mato kito kliento sąlygas.
• Nesutarti dėl duomenų nuosavybės. Sutartyje su kūrėju aiškiai įrašykite, kam priklauso kodas ir duomenys. Daugiau klausimų, kuriuos verta užduoti prieš pasirašant, rasite straipsnyje Kaip išsirinkti programavimo partnerį.

DUK

Ar B2B portalas ir el. parduotuvė gali būti viena sistema?

Gali. Dažnas sprendimas yra viena platforma su dviem režimais: viešas katalogas ar parduotuvė privatiems pirkėjams ir uždara dalis verslo klientams su jų kainomis ir sąlygomis. Svarbu, kad abiem režimams būtų bendri prekių ir likučių duomenys.

Kiek laiko trunka sukurti B2B portalą?

Priklauso nuo funkcijų ir ERP integracijos sudėtingumo. Pirmą veikiantį etapą su kainomis, likučiais ir užsakymais dažniausiai įmanoma paleisti per kelis mėnesius, o ne per metus, jei apimtis aiškiai apribota ir ERP turi tinkamą API.

Ar portalas pakeičia CRM?

Ne. CRM skirta jūsų komandai valdyti santykius su klientais, o portalas skirtas patiems klientams. Geriausiai jie veikia kartu: vadybininkas CRM mato, ką klientas užsakė portale ir ar jam kilo problemų.

Ar reikia kurti mobiliąją programėlę?

Dažniausiai ne. Gerai pritaikyto mobiliesiems portalo pakanka. Programėlė verta svarstyti tik tada, kai klientai užsako dažnai ir iš objekto, pavyzdžiui, skenuodami prekių brūkšninius kodus.

Ar galima pradėti nuo sąskaitų ir skolų peržiūros?

Taip, ir tai dažnai geras pirmas žingsnis. Klientai pripranta prisijungti, jūs sumažinate skambučių dėl sąskaitų kopijų, o užsakymus galima pridėti antrame etape.

Ką daryti toliau

Pradėkite nuo trijų klausimų: kiek užsakymų ir užklausų dabar apdorojama rankiniu būdu, kur gyvena jūsų kainos ir klientų sąlygos, ir kokią API turi jūsų apskaitos ar ERP sistema. Atsakymai parodys, ar užtenka modulio esamai parduotuvei, ar verta kurti individualų portalą.

DESAmedia kuria B2B el. parduotuves ir klientų savitarnos portalus su integracijomis į apskaitą, sandėlį ir kurjerius. Daugiau apie tai rasite puslapiuose Elektroninių parduotuvių kūrimas, Web aplikacijų kūrimas ir Sistemų integracijos ir automatizavimas. Jei norite aptarti savo situaciją, parašykite per kontaktų puslapį.

Šaltiniai

• Direktyva (ES) 2019/882 dėl gaminių ir paslaugų prieinamumo reikalavimų (EUR-Lex)
• Lietuvos Respublikos mokėjimų, atliekamų pagal komercines sutartis, vėlavimo prevencijos įstatymas Nr. IX-1873 (e-TAR)