E-poe loomine Eestis: maksed, tarne ja see, mis päriselt aega võtab

Enamik e-poe projekte Eestis ei venita mitte tehnilise arenduse tõttu, vaid tootepiltide ja -andmete pärast. See on ebamugav tõde, sest keegi ei taha kuulda, et pudelikael on tema enda tabelis, mitte arendaja koodis. Aga kui tahad ausat pilti sellest, mis e-poe loomisel aega ja raha võtab, tuleb alustada sealt, mitte platvormivalikust.

Maksed, mida Eesti e-pood tegelikult valib

Kõige levinum lahendus Eesti e-poodides on kas Montonio või Maksekeskus. Mõlemad on kohalikud makseagregaatorid, mis koondavad ühe liidese taha Eesti, Läti ja Leedu pankade pangalingid (SEB, Swedbank, LHV, Luminor ja teised), krediitkaardimaksed ja järelmaksuvõimalused. Nende eelis on lihtne: Eesti ostja tahab maksta oma panga kaudu ja iga panga eraldi liidestamine oleks omaette projekt. Agregaator teeb selle ühe integratsiooniga ära.

Stripe on rahvusvaheliseks müügiks tugev valik, kaardimaksed toimivad hästi ja hinnastruktuur on selge, aga Eesti pangalinke Stripe otse ei toeta. Puhtalt kohaliku kliendibaasiga poele jääb see tavaliselt teiseseks valikuks või lisandiks agregaatori kõrvale. Kui müüd nii Eestisse kui välismaale, on tavaline lahendus need kaks kombineerida: kohalik agregaator eestlastele, Stripe rahvusvaheliste kaartide jaoks.

Praktikas erineb kolm valikut kolmes kohas. Montonio ja Maksekeskus toetavad otse Eesti pankade pangalinke (SEB, Swedbank, LHV, Luminor, Coop Pank ja teised), mis tähendab, et ostja logib sisse oma tavapärase internetipanga kaudu ja ei pea kaardinumbrit üldse sisestama. See on eestlaste jaoks harjumuspärane ja usaldusväärne viis maksta ja mõjutab otseselt, kui palju ostukorve reaalseteks tellimusteks jõuab. Stripe pakub ainult kaardimakseid ja otsest pangalingi integratsiooni Eesti pankadega tal pole, seega poele, kus enamik kliente on harjunud pangalingiga maksma, jätab Stripe üksinda maksevaliku puudulikuks.

Teine erinevus on väljamaksed. Kohalik agregaator kannab raha su Eesti äriarvele eurodes, tavapärase graafiku alusel, samasse panka, kus muidugi juba asju ajad. Stripe'i puhul tuleb väljamaksete valuuta ja graafik seadistada eraldi ja uue konto esimesed väljamaksed võivad käivituda aeglasemalt, sõltuvalt Stripe'i riskihinnangust kontole. See pole takistus, aga on planeerimise koht, mitte midagi, mida avastada alles pärast esimest tellimust. Sellepärast valib pood, mis müüb valdavalt Eestisse, peaaegu alati kohaliku agregaatori esimeseks valikuks, samas kui pood, mis müüb valdavalt väljapoole Eestit, saab Stripe'iga sageli hakkama ka ilma pangalingita, sest välismaised kliendid ei oota seda samamoodi.

Tarne ja pakiautomaadid

Eesti ostja eeldab pakiautomaadi valikut ostu lõpus: Omniva, DPD, Itella SmartPOST, Venipak. See valik pole arenduse mõttes pisiasi. Iga pakiteenus pakub oma automaatide asukohtade nimekirja ja API-t, mis tuleb siduda tellimusprotsessiga nii, et ostja saaks kaardilt oma lähima automaadi valida ja see valik jõuaks õigesti pakiettevõtte süsteemi. See on üks konkreetne koht, kus "lihtne e-pood" muutub päriselt tööks: valesti seadistatud pakiautomaadi liides tähendab hiljem käsitsi tellimuste parandamist iga päev.

Iga kulleriteenus haldab oma automaatide nimekirja eraldi ja see nimekiri muutub pidevalt: automaadid lisanduvad, mõni suletakse hooldusse, mõni kaob päriselt. Kui poe nimekiri ei uuene regulaarselt kulleri API vastu, valib ostja automaadi, mida enam olemas pole, ja pakk jääb kuhugi rippuma, kuni keegi selle käsitsi ümber suunab. Sama tõsine viga on valiku koht: automaadi valik peab toimuma kassaprotsessi sees, enne maksmist, mitte pärast seda kinnituslehel või hilisema e-kirjaga. Kui ostja saab valida alles pärast maksmist, jätab osa kliente valiku üldse tegemata ja poe meeskond peab käsitsi tagasi küsima, kuhu pakk saata.

Ja kuna iga kulleriteenus pakub oma otsingu- ja kaardividinat erinevalt, tähendab mitme teenuse toetamine mitut eraldi liidest, mis kõik peavad ostja jaoks tunduma ühtse kogemusena. Siin muutub "lihtsalt integreeri pakiautomaat" tegelikult mitmeks eraldi tööks, mistõttu on tark otsustada juba projekti alguses, mitu kulleriteenust päriselt vaja on. Kolm paralleelset integratsiooni "igaks juhuks" maksab kolm korda rohkem testimisaega kui üks, mida sinu kliendid tegelikult kasutavad.

Raamatupidamine ja laoseis

Kui tooteid on rohkem kui mõnikümmend, tasub e-pood siduda raamatupidamis- või laohaldustarkvaraga (Merit, SmartAccounts ja sarnased) juba algusest peale, mitte hiljem käsitsi ümber tippides. See integratsioon on tavaliselt üks projekti odavamaid osi, aga selle puudumine muutub kalliks kiiresti, sest keegi peab siis käsitsi laoseisu jälgima.

Tegelik probleem, mida laoseisu sünkroonimine peab lahendama, on see, et kaks süsteemi, e-pood ja raamatupidamis- või laotarkvara, peavad kokku leppima, kumb "omab" laoseisu tõde hetkel, kui kaks ostjat proovivad osta viimast tooteühikut sama minuti jooksul. Kui sünkroonimine käib kord tunnis, mitte reaalajas, võib pood müüa toote, mis on vahepeal juba otsas, ja keegi peab kliendile hiljem helistama ja vabandama. Hea lahendus lukustab laoseisu tellimuse hetkel ja annab selge vastuse, kumb süsteem on iga toote koguse jaoks lõplik allikas.

Käibemaks ja piiriülene müük

Kui müüd ainult Eestisse, on käibemaksu pool suhteliselt lihtne: Eesti käibemaksumäär kehtib ja e-pood peab selle korrektselt tellimusele lisama ja arvele märkima. Kui hakkad müüma teistesse ELi liikmesriikidesse, tuleb mängu OSS-süsteem (One Stop Shop), mis lubab piiriülest käibemaksu deklareerida ühe koondaruande kaudu, selle asemel et registreeruda käibemaksukohuslaseks igas sihtriigis eraldi. See on tehniliselt e-poe seadistuse küsimus, õiged käibemaksumäärad sihtriikide kaupa, aga otsus, kas ja millal OSS-iga liituda, on raamatupidamise ja maksunõustamise küsimus, mitte arendaja pädevus. Ära usalda seda otsust veebiarendajale: küsi oma raamatupidajalt või maksunõustajalt, enne kui hakkad piiriüleselt müüma.

Aus ajakava

Makse- ja tarneintegratsioonid ise võtavad kogenud arendajal tavaliselt nädala kuni paar, need on korduvad, hästi dokumenteeritud tööd. Disain ja põhifunktsionaalsus (tootekataloog, ostukorv, kasutajakontod) mahub tavaliselt kuu kuni pooleteise sisse, kui sisu on valmis. See viimane tingimus on määrav: tootekirjeldused, korrektsed pildid ja kategooriate struktuur on peaaegu alati see, mis projekti venitab, sest need eeldavad otsuseid, mida keegi peab tegema, tihti kliendi enda meeskonnas, ja neid otsuseid lükatakse edasi kergemini kui arendustööd.

Konkreetsemalt: korraliku tootekirjelduse kirjutamine, pildistamine korralikus valguses ja kõigi väljade (hind, mõõdud, kategooria, laoseis) täitmine võtab kogenud inimesel tavaliselt kümmekond lihtsat toodet päevas ja tunduvalt vähem, kui tooted vajavad eraldi stuudiopildistust või tehnilisi spetsifikatsioone. Kolmesaja tootega poe puhul tähendab see nädalate tööd, mitte päevi, ja see aeg tuleb ajakavasse arvestada eraldi arendustööst, sest keegi peab selle tegema paralleelselt või enne, mitte lansseerimisele eelneval nädalal.

Kui sul on sada toodet ilma korralike piltide ja kirjeldusteta, arvuta see töö oma ajakavasse enne, kui küsid arendajalt, millal pood valmis saab.

Millal Shopify või WooCommerce võidab kohandatud lahenduse

Kui tootevalik on väike ja standardne, mõnikümmend toodet, tavapärane ostuprotsess, ei mingeid ebatavalisi äriregleid, on Shopify aus ja kiire valik. Kuutasu katab hostingu, turvalisuse ja enamiku vajalikke tarne- ja makseintegratsioone valmis pistikprogrammidena ja käivitusaeg on nädalate, mitte kuude küsimus. WooCommerce on sarnane tee WordPressi peal, kui pood on juba WordPressil või kui sisuturundus (blogi, artiklid) on ärile sama oluline kui pood ise.

Kohandatud e-poe arendus tasub end ära, kui äriloogika on ebastandardne: keeruline hinnastamine, B2B ja B2C kliendid samal platvormil eri tingimustel, tihe integratsioon olemasoleva ERP-ga, mida ükski pistikprogramm ei toeta. Kui vastus neile kolmele on "ei", on kohandatud lahendus tõenäoliselt kallim tee samale tulemusele.

Ja kui pood on valmis, ei lõpe töö sinna. Laadimiskiirus mõjutab otseselt seda, kui palju ostukorvidest reaalseteks tellimusteks jõuab, ning sellest, mida Google ja kasutajad kiiruse juures tegelikult mõõdavad, kirjutasin eraldi kiiruse ja Core Web Vitalsi postituses.