CMS po meri: en sistem namesto štirinajstih vtičnikov

Predstavljajte si ponedeljek zjutraj v spletni trgovini, ki na dan odpremi štirideset naročil.

Nekdo odpre seznam naročil in jih po eno prepiše v portal prevoznika. Natisne nalepke. Iz portala prekopira sledilne številke nazaj v naročila in strankam ročno pošlje sporočilo. Nato odpre program za izdajanje računov in tam še enkrat vnese isto naročilo, da nastane račun. Ker je v soboto nekaj kosov prodala tudi fizična trgovina, popravi še zalogo na spletu — na pamet, ker en izdelek ni bil odčitan.

Ob desetih se začnejo vprašanja: »Kje je moj paket?« Odgovori nanje bodo vzeli več časa kot vsa jutranja odprema skupaj.

Nič od naštetega ni prodaja. Vse to je ročno lepilo med sistemi, ki med seboj ne govorijo — in prav to lepilo pri rasti prvo poči.

Kaj sploh je CMS po meri — in kaj ni

CMS po meri ni »boljši WordPress«. Je sistem, v katerem so vaši podatki — izdelki, zaloga, naročila, pošiljke, računi, stranke — en sam podatkovni model, okoli katerega zgradimo natanko tiste zaslone in avtomatizacije, ki jih vaše poslovanje potrebuje.

Pri sestavljanju iz vtičnikov je drugače. Vsak modul prinese svoj del baze, svojo logiko in svojega vzdrževalca. Zaloga živi v enem vtičniku, dostava v drugem, računi v tretjem, jezikovne različice v četrtem. Nihče od njih ni odgovoren za to, da podatek pride iz enega v drugega — ta vloga tiho pripade zaposlenemu.

Pri nas to pomeni Next.js za trgovino in Payload CMS za zaledje — pristop, ki ga podrobneje opisujemo pri razvoju po meri. Vse ostalo — zaloga, dostava, računi, asistent — so moduli istega sistema, ne vtičniki tretjih oseb. Zakaj to sploh počnemo tako, smo razložili v zapisu o tem, kdaj je čas za profesionalno spletno stran.

Konkreten primer: kako izgleda taka trgovina

Da to ne ostane pri načelih, si zamislimo konkretno trgovino. Približno tri tisoč izdelkov. Dve prodajni poti: splet in ena fizična trgovina. Dva zaposlena, ki poleg vsega ostalega pokrivata še podporo. Dostava prek Pošte Slovenije in enega kurirja. Plačila na tri načine: s kartico prek ponudnika plačil, po predračunu na transakcijski račun in po povzetju.

To je povprečna slovenska spletna trgovina, ki je prerasla fazo »nekaj naročil na teden«. Poglejmo, kaj v takem sistemu prevzame program.

Katalog in zaloga: en izdelek, ena številka

Najdražja napaka v spletni trgovini ni počasna stran. Je prodaja izdelka, ki ga nimate.

Zaloga se zato vodi na enem mestu in velja za obe prodajni poti hkrati. Ko stranka odda naročilo, se kos rezervira takoj — ne šele ob plačilu — sicer lahko isti zadnji kos v isti minuti kupita dva. Ko blagajna v fizični trgovini proda kos, se stanje na spletu spremeni v isti sekundi.

Sistem pozna tudi varnostno zalogo: ko izdelek pade pod prag, se pojavi na seznamu za naročilo pri dobavitelju, skupaj s podatkom, kako hitro se prodaja in kdaj je bila zadnja dobava. To ni poročilo, ki ga nekdo mora iskati — je vrstica, ki se sama pojavi na nadzorni plošči.

Dostava in sledenje: kjer se prihrani največ ur

Ko je naročilo potrjeno, sistem sam pripravi pošiljko pri prevozniku prek njegovega vmesnika, natisne nalepko in prevzame sledilno številko. Številko takoj pripne naročilu in jo pošlje stranki — brez prepisovanja.

Tu se zgodba običajno konča, pri sistemu po meri pa se šele začne. Sistem status pošiljke tudi bere. Stranka dobi sporočilo, ko je paket prevzet in ko je dostavljen. Če se pošiljka oseminštirideset ur ne premakne, se pojavi na vašem seznamu, preden stranka napiše prvo sporočilo.

Računi in davčno potrjevanje: del sistema, ne drugi program

Račun ne bi smel nastati z drugim vnosom istega naročila v drug program. Nastane naj iz naročila, ki že obstaja.

Pri slovenski trgovini je tu podrobnost, ki je marsikatera platforma ne obvlada: ali je treba račun davčno potrditi, je odvisno od poti, po kateri denar pride do vas. Nakazilo neposredno na vaš transakcijski račun je negotovinsko plačilo. Če denar pride prek posrednika, ki plačila zbira in jih nato nakazuje naprej — kar velja za marsikatero kartično plačilo in za povzetje — se tako plačilo obravnava kot gotovinsko in račun je treba potrditi pri FURS.

Sistem po meri to odločitev vodi po pravilu, zapisanem enkrat, in ne po presoji zaposlenega ob vsakem naročilu. Račun, ki potrditev potrebuje, jo dobi samodejno, skupaj z EOR in ZOI na izpisu. Račun, ki je ne potrebuje, gre skozi brez nje.

Rok, ki je že zapisan: 1. januar 2028

Če danes načrtujete novo trgovino, je en datum vreden vaše pozornosti bolj kot vsi ostali. Državni zbor je sprejel Zakon o izmenjavi elektronskih računov in drugih elektronskih dokumentov (ZIERDED). Od 1. januarja 2028 bo izmenjava e-računov med poslovnimi subjekti obvezna — za vse subjekte, vpisane v Poslovni register Slovenije, in za samostojne podjetnike, brez izjem glede velikosti podjetja in brez napovedanega prehodnega obdobja.

Kaj to pomeni v praksi. PDF ni e-račun. E-račun je strukturiran zapis v obliki e-SLOG oziroma skladen z evropskim standardom EN 16931, pošiljanje računov med podjetji po elektronski pošti pa ne bo več dovoljeno. Izmenjava poteka prek ponudnika e-poti, prek omrežja PEPPOL, z neposredno povezavo med sistemoma ali prek brezplačne aplikacije miniBlagajna. Pri poslovanju s potrošniki se za zdaj ne spreminja nič — račun kupcu lahko še naprej pošljete kot doslej.

Bistvo ni v tem, da bi kdo moral januarja 2028 na hitro kupiti novo rešitev. Bistvo je, da je trgovina, ki jo gradite danes, tedaj pripravljena — da je prehod sprememba nastavitve in ne nov projekt. Trgovina, sestavljena iz vtičnikov, bo takrat čakala, da bo vsak od štirinajstih ponudnikov izdal svojo posodobitev. Sistem po meri je vaš in ga posodobite, ko se odločite vi.

AI asistent, ki pozna vašo zalogo

Klepetalni robot, ki odgovarja iz seznama pogostih vprašanj, ni asistent. Je iskalnik z drugačnim ovojem.

Asistent postane uporaben šele, ko ima dostop do vaših podatkov in jasne meje. Ko stranka vpraša, kje je njeno naročilo, ne ponovi splošnega odgovora — pogleda dejansko pošiljko in pove, kje je. Ko vpraša za priporočilo, upošteva, kaj je na zalogi in kaj se s tem izdelkom običajno kupi skupaj. Ko naletite na izdelek brez opisa, iz specifikacij pripravi osnutek v vašem tonu, ki ga potrdite ali popravite — ne objavi ga sam.

Enak asistent služi tudi vam. »Koliko kosov tega izdelka nam ostane in kdaj je bila zadnja dobava?« je vprašanje, na katerega mora sistem odgovoriti hitreje, kot bi odprli poročilo.

Ključno pri tem ni model. Ključno je, da asistent ve, česa ne sme: ne obljublja rokov dostave, ki jih ne more preveriti, si ne izmišlja lastnosti izdelkov in ne odgovarja na vprašanja, ki sodijo k človeku. Te meje so del razvoja, ne nastavitev v vtičniku.

Nadzorna plošča, ki pove, kaj narediti

Večina nadzornih plošč prikazuje, kaj se je zgodilo. Uporabna nadzorna plošča prikazuje, kaj je treba narediti. Katera naročila čakajo na odpremo. Kateri izdelki so pod varnostno zalogo. Katere pošiljke se dva dni niso premaknile. Kateri izdelki so bili stokrat ogledani in nikoli kupljeni — ker je to običajno napaka v ceni, opisu ali fotografiji, ne v povpraševanju.

Vsebina, jeziki in SEO v istem sistemu

Kategorije, opisi, blog in jezikovne različice živijo v istem zaledju kot izdelki. Strukturirani podatki za Google nastanejo iz podatkov o izdelku, ne iz posebnega vtičnika, ki jih zna narediti narobe. Ko dodate nemško različico, ne dodate nove trgovine — dodate jezik. Kako to vpliva na vidnost v iskalnikih, pišemo pri SEO optimizaciji.

Poštena računica

Štirideset naročil na dan, približno sto deset sekund ročnega dela na naročilo. To je ena ura na dan in približno dvajset ur na mesec, preden štejemo podporo. Dvajset ur je pol delovnega tedna, vsak mesec, za nekaj, kar ne prinese niti enega novega kupca.

Zraven pride tisto, česar se ne da izmeriti tako lepo: naročilo, ki ga ni mogoče izpolniti, ker je bil zadnji kos prodan dvakrat.

Kdaj tega ne potrebujete

Sistem po meri ni pravi odgovor za vsako trgovino. Če prodajate petdeset izdelkov, imate eno pot dostave in pet naročil na teden, boste s standardno platformo hitreje in ceneje na trgu — in to je povsem legitimna odločitev.

Razvoj po meri se začne izplačevati na dveh mestih. Prvo je, ko ročno delo med sistemi preseže nekaj ur na teden. Drugo je, ko obstaja proces, ki je za vaše podjetje značilen in ga standardna platforma ne zna — svojevrsten izračun cene, povezava s programom v skladišču, prodaja, ki teče drugače kot pri vseh drugih.

Kako to zgradimo in kaj stane

Trgovino po meri gradimo po istem postopku kot ostale projekte: pogovor, načrt in struktura, oblikovanje, razvoj, objava in predaja. Razlika je v tem, da se pri trgovini v koraku načrtovanja določi tudi, s katerimi sistemi se mora povezati — prevoznik, program za račune, blagajna v trgovini, dobaviteljev cenik.

Cena izdelave spletne trgovine se začne pri 1.290 €, s fiksno ponudbo pred začetkom in gostovanjem za prvo leto ter tehnično podporo. Po prvem letu trgovino lahko prevzame skrbništvo od 39 € na mesec. Celoten razrez je na ceniku, ponudbo s fiksno ceno pa pripravimo v štiriindvajsetih urah.