Creare magazin online înseamnă proiectarea unui canal comercial digital capabil să prezinte oferta, să preia comenzi, să proceseze plăți, să gestioneze datele și să se integreze cu stocul, logistica, facturarea, serviciul pentru clienți și procesele companiei. Platforma și designul sunt importante, dar reprezintă doar o parte a sistemului.

Un magazin poate arăta bine, se poate încărca repede și poate avea toate funcțiile tehnice cerute, dar să nu fie viabil comercial. Poate vinde produse cu marjă insuficientă, poate depinde de publicitate prea scumpă, poate bloca numerar în stoc, poate genera retururi costisitoare sau poate solicita o capacitate operațională pe care compania nu o are.

De aceea, decizia nu trebuie să înceapă cu întrebarea „ce platformă alegem?”, ci cu întrebări mai dificile: cui vindem, ce problemă rezolvăm, ce produse merită incluse, ce marjă rămâne după toate costurile, cum vom procesa comenzile și cine va administra efectiv canalul după lansare.

Acest ghid tratează crearea magazinului online din perspectivă comercială, managerială, operațională, organizațională și tehnică. Nu recomandă o platformă și nu presupune că orice companie trebuie să investească într-un magazin propriu.

Creare magazin online: ce construiești în realitate

Un magazin online nu este doar un site cu produse și un coș de cumpărături. Este interfața vizibilă a unui sistem mai amplu care trebuie să coordoneze:

cererea și poziționarea ofertei;
produsele, serviciile și informațiile asociate;
prețurile, discounturile și promoțiile;
stocurile și disponibilitatea;
plățile și reconcilierea financiară;
pregătirea, expedierea și livrarea comenzilor;
retururile, reclamațiile și garanțiile;
marketingul și atragerea cererii;
trackingul și raportarea;
rolurile și responsabilitățile interne;
platforma, infrastructura și integrările.

Clientul vede pagina produsului, prețul și butonul de comandă. Compania trebuie să gestioneze însă întregul traseu dintre selectarea produsului și rezultatul economic final.

Dacă un produs este afișat în stoc, dar nu poate fi livrat, problema nu este doar una tehnică. Dacă magazinul acceptă plata, dar rambursarea returului necesită operațiuni manuale și durează prea mult, problema nu este doar una financiară. Dacă platforma raportează venit, dar compania nu scade anulările, retururile, transportul și costul produsului, problema nu este doar una de analytics.

Un magazin online funcționează bine atunci când promisiunea făcută clientului poate fi susținută de procesele, datele și capacitatea organizației.

Este magazinul online alegerea potrivită?

Faptul că oamenii cumpără online nu înseamnă că orice companie va putea construi un canal online profitabil. Piața poate fi atractivă, dar modelul individual poate rămâne neviabil.

Înainte de investiție trebuie verificate cel puțin cinci dimensiuni.

Există cerere relevantă?

Cererea poate fi evaluată prin:

cercetări și statistici de piață;
volume de căutare;
interviuri cu potențiali clienți;
comportamentul clienților actuali;
vânzările competitorilor, unde există date credibile;
marketplace-uri;
teste de ofertă sau precomandă;
campanii pilot;
solicitările primite de companie.

Un volum mare de căutare nu demonstrează automat intenția de cumpărare. Oamenii pot căuta informații, comparații, instrucțiuni sau produse pe care compania nu le poate oferi competitiv.

Cercetarea trebuie să stabilească nu doar dacă produsul este cunoscut, ci și:

ce problemă încearcă să rezolve clientul;
ce alternative folosește;
ce criterii influențează alegerea;
ce riscuri percepe;
ce nivel de preț acceptă;
ce condiții de livrare și retur consideră normale.

Produsul este potrivit pentru vânzare la distanță?

Unele produse sunt ușor de înțeles și comparat online. Altele necesită demonstrații, măsurători, consultanță, configurare sau verificarea compatibilității.

Complexitatea nu exclude vânzarea online, dar poate schimba modelul. În locul unui checkout standard poate fi necesar:

un configurator;
o cerere de ofertă;
o etapă de consultanță;
mostre;
verificarea tehnică a comenzii;
aprobări B2B;
un model hibrid online–offline.

Marja suportă costul canalului?

Prețul minus costul produsului nu reprezintă profitul unei comenzi. Canalul online adaugă costuri care pot include:

discounturi;
procesarea plății;
ambalarea;
transportul suportat de comerciant;
retururile;
frauda și comenzile refuzate;
customer support;
marketingul;
licențele și infrastructura;
personalul;
pierderile din stoc și erorile operaționale.

Un produs cu marjă aparent generoasă poate deveni neprofitabil după costul real al servirii.

Compania poate opera magazinul?

Lansarea este doar începutul. După publicare, cineva trebuie să:

actualizeze produsele;
verifice stocurile;
administreze prețurile;
răspundă clienților;
rezolve comenzile blocate;
proceseze retururile;
verifice integrările;
analizeze rezultatele;
prioritizeze dezvoltările;
coordoneze furnizorii.

Dacă aceste responsabilități nu au proprietar, magazinul va deveni o colecție de probleme transferate între marketing, IT, logistică și financiar.

Există un avantaj față de alternative?

Clientul poate cumpăra de la marketplace-uri, retaileri consacrați, magazine fizice sau direct de la producător.

Avantajul poate proveni din:

produse exclusive;
selecție mai bună;
preț;
livrare;
disponibilitate;
consultanță;
configurare;
servicii asociate;
încredere;
conținut și suport;
experiența post-vânzare.

„Avem și noi magazin online” nu este o propunere de valoare.

Magazin propriu, marketplace sau model mixt

Un magazin propriu nu este singura cale de vânzare digitală. Alegerea canalului trebuie făcută în funcție de control, cost, acces la cerere și capacitatea operațională.

Model	Avantaj principal	Limită principală
Magazin propriu	Control asupra experienței, ofertei și datelor	Compania trebuie să atragă și să convertească cererea
Marketplace	Acces mai rapid la trafic și infrastructură comercială	Comisioane, concurență internă și acces limitat la client
Model mixt	Diversificarea canalelor și testarea pieței	Complexitate operațională și posibil conflict între canale
Portal B2B	Automatizarea comenzilor și condițiilor comerciale	Integrări și reguli complexe de cont, preț și aprobare

Când poate fi util marketplace-ul

Marketplace-ul poate ajuta la:

testarea cererii;
validarea portofoliului;
obținerea primelor vânzări;
accesarea unui public existent;
reducerea investiției inițiale în atragerea traficului.

În schimb, compania poate pierde:

control asupra prezentării;
acces la date complete despre client;
marjă prin comisioane;
diferențiere într-un mediu orientat spre comparația de preț;
independență față de regulile platformei.

Când poate fi justificat magazinul propriu

Magazinul propriu devine mai valoros când compania are nevoie de:

control asupra brandului și experienței;
relație directă cu clientul;
ofertă complexă;
conținut detaliat;
personalizare;
programe de loialitate;
abonamente;
integrare cu servicii;
date comerciale proprii;
dezvoltarea unei baze de clienți recurenți.

Modelul mixt

Pentru multe companii, răspunsul nu este alegerea exclusivă a unui canal. Marketplace-ul poate genera volum și validare, iar magazinul propriu poate construi relația, retenția și oferta extinsă.

Modelul mixt trebuie însă administrat atent. Pot apărea diferențe de:

preț;
stoc;
promoții;
cost de livrare;
politici comerciale;
experiență post-vânzare;
profitabilitate.

O companie trebuie să știe ce rol are fiecare canal, nu doar să copieze același catalog peste tot.

Modelul comercial trebuie definit înaintea platformei

Platforma trebuie să susțină modelul comercial. Nu modelul comercial trebuie forțat să intre în limitările unei platforme alese prea devreme.

Ce vinzi?

Magazinul poate comercializa:

produse proprii;
produse distribuite;
produse digitale;
servicii;
abonamente;
bundle-uri;
produse configurabile;
produse personalizate;
piese și consumabile;
licențe;
produse cu instalare sau mentenanță.

Fiecare model impune cerințe diferite. Un produs standard poate fi cumpărat direct. Un produs configurabil poate necesita reguli de compatibilitate. Un abonament necesită plăți recurente. Un produs personalizat poate avea alte condiții de retur.

Cui vinzi?

Diferențele dintre B2C și B2B sunt substanțiale.

Un magazin B2C poate necesita:

checkout rapid;
preț public;
plată cu cardul și ramburs;
retur simplificat;
promoții și cupoane;
comunicare orientată spre consumator.

Un portal B2B poate necesita:

conturi aprobate;
prețuri negociate;
limite de credit;
comenzi cu aprobare;
cantități minime;
liste de preț diferite;
plată la termen;
roluri multiple în aceeași companie;
integrare cu agenții de vânzări;
documente și condiții contractuale specifice.

Cum produce compania valoare economică?

Modelul poate depinde de:

marja pe produs;
volum;
recurența cumpărării;
cross-sell;
upsell;
abonamente;
servicii complementare;
consumabile;
finanțare;
exclusivitate;
viteză și disponibilitate.

Aceste mecanisme influențează structura magazinului. Dacă profitul vine din consumabile, site-ul trebuie să faciliteze recumpărarea. Dacă valoarea vine din configurare, trebuie investit în ghidare și compatibilitate. Dacă marja depinde de bundle-uri, motorul de ofertare trebuie să le susțină.

Cum verifici viabilitatea economică

Un calcul orientativ pentru o comandă poate arăta astfel:

Preț fără TVA                         250 lei
Cost achiziție produs                110 lei
Discount mediu                        10 lei
Procesare plată                        5 lei
Ambalare și fulfillment               12 lei
Transport suportat de companie        15 lei
Cost estimat al retururilor             8 lei
Cost achiziție client                 45 lei
Cost suport și operațiuni               6 lei
Marjă de contribuție estimată         39 lei

Calculul este ipotetic. Fiecare companie trebuie să folosească propriile costuri și propriile definiții.

Marja brută

O formulă simplificată este:

Marjă brută = venit net – costul produselor vândute

Aceasta nu include întotdeauna costurile specifice canalului.

Marja de contribuție

Marja de contribuție urmărește ce rămâne după costurile variabile asociate vânzării:

Marjă de contribuție = venit net – produs – discount – plată – livrare – fulfillment – retur – achiziție – alte costuri variabile

Această valoare trebuie să contribuie apoi la acoperirea costurilor fixe și la profit.

Valoarea medie a comenzii

O comandă mai mare poate dilua costurile fixe de procesare și transport. Dar o valoare medie ridicată nu este automat bună dacă este obținută prin discounturi care distrug marja.

Costul achiziției clientului

Costul de achiziție trebuie calculat pe baza cheltuielilor relevante, nu doar a conversiilor atribuite de o platformă de publicitate.

Pentru un client nou:

CAC = costurile de marketing și vânzare asociate achiziției / numărul clienților noi

Compania trebuie să separe, unde este posibil:

client nou;
client recurent;
comandă organică;
comandă asistată de campanii;
venit atribuit de platformă;
venit net confirmat.

Retururile

Rata de retur nu este doar un indicator operațional. Ea modifică venitul, costul transportului, munca echipei, disponibilitatea stocului și capacitatea de reintegrare a produselor.

Un produs cu marjă bună și retur ridicat poate fi mai slab decât un produs cu marjă nominală mai mică, dar cerere stabilă și cost redus de servire.

Capitalul de lucru

Un magazin poate crește în vânzări și să rămână fără lichiditate. Compania poate plăti furnizorii înainte de a încasa comenzile, poate păstra stoc pentru perioade lungi sau poate aștepta rambursarea sumelor de către procesatori și curieri.

Trebuie analizate:

termenele furnizorilor;
viteza de rotație a stocului;
timpul de încasare;
rambursurile;
retururile;
sezonalitatea;
necesarul de stoc pentru promoții.

Portofoliul inițial

Încărcarea întregului catalog din ERP nu este neapărat strategia corectă. Fiecare produs adăugat creează muncă de conținut, actualizare, stoc, suport, promovare și analiză.

Portofoliul inițial poate fi selectat după:

cerere;
marjă;
disponibilitate;
diferențiere;
rotație;
dimensiune și greutate;
fragilitate;
rata de retur;
sezonalitate;
complexitatea explicației;
potențialul de recumpărare;
posibilitatea de cross-sell;
restricții legale;
nevoia de suport.

Rolurile comerciale ale produselor

Produsele nu trebuie evaluate doar după venit. Ele pot avea roluri diferite:

Generator de trafic: atrage căutări și vizite;
Generator de conversii: este ușor de cumpărat;
Generator de marjă: contribuie disproporționat la profitabilitate;
Generator de recurență: aduce clientul înapoi;
Produs de intrare: facilitează prima comandă;
Produs complementar: crește valoarea coșului;
Produs de imagine: susține poziționarea;
Produs problematic: consumă stoc, suport sau retururi.

Un catalog sănătos are nevoie de o combinație deliberată, nu doar de multe SKU-uri.

Structura catalogului și datele de produs

Taxonomia catalogului influențează simultan experiența utilizatorului, operațiunile, căutarea internă, SEO, feedurile și raportarea.

Categoriile și subcategoriile

Categoriile trebuie să reflecte modul în care cumpărătorii înțeleg oferta, nu doar structura internă a furnizorului.

O categorie utilă:

are un sens clar;
conține suficiente produse;
răspunde unei nevoi sau intenții;
poate fi administrată în timp;
nu dublează aproape identic altă categorie.

Atributele

Atributele pot include:

dimensiune;
culoare;
material;
capacitate;
compatibilitate;
putere;
brand;
utilizare;
certificări.

Atributele trebuie definite controlat. „Negru”, „black”, „negru mat” și „NGR” nu ar trebui să reprezinte aceeași valoare fără o logică de normalizare.

Variantele

Trebuie decis dacă mărimile, culorile sau configurațiile sunt:

variante ale aceluiași produs;
produse separate;
opțiuni configurabile;
bundle-uri.

Această decizie influențează:

URL-urile;
stocurile;
identificatorii;
imaginile;
feedurile;
recenziile;
raportarea;
datele structurate.

Identificatorii

Catalogul trebuie să administreze coerent:

SKU;
GTIN/EAN;
MPN;
brand;
coduri furnizor;
unități de măsură;
identificatori de variantă.

Datele incorecte se propagă către stoc, feeduri, facturare, marketplace-uri și analytics.

Conținutul produsului

O fișă de produs poate necesita:

nume clar;
descriere;
beneficii;
specificații;
imagini;
video;
compatibilitate;
instrucțiuni;
garanție;
livrare;
retur;
documente;
întrebări frecvente.

Responsabilitatea pentru aceste informații trebuie stabilită. Platforma poate stoca datele, dar nu le poate inventa și valida singură.

Procesele trebuie proiectate înainte de lansare

O demonstrație reușită a storefrontului nu dovedește că magazinul poate fi operat.

Crearea și actualizarea produselor

Trebuie stabilit:

cine creează produsul;
cine aprobă informațiile;
care este sursa principală a datelor;
cum sunt actualizate prețurile;
cum sunt retrase produsele;
cum sunt gestionate traducerile;
cum sunt corectate erorile.

Stocurile

Întrebările esențiale sunt:

care sistem deține stocul oficial;
cât de des se sincronizează;
există stoc rezervat;
ce se întâmplă când două canale vând ultima unitate;
cum sunt tratate produsele la furnizor;
poate fi acceptată precomanda;
ce mesaj vede clientul.

Prețurile și promoțiile

Platforma trebuie să susțină regulile comerciale reale:

preț standard;
preț promoțional;
liste de preț;
preț B2B;
discount pe volum;
bundle;
voucher;
transport gratuit;
campanii temporare;
restricții de combinare.

Trebuie stabilit și cine poate modifica prețurile și cine aprobă promoțiile.

Procesarea comenzii

O comandă poate parcurge:

înregistrare;
validarea plății;
verificarea fraudei;
rezervarea stocului;
emiterea documentelor;
picking;
packing;
generarea AWB;
expedierea;
livrarea;
confirmarea;
eventual returul și rambursarea.

Pentru fiecare etapă trebuie definit:

sistemul responsabil;
statutul comenzii;
persoana responsabilă;
mesajul către client;
procedura de excepție.

Retururile și rambursările

Returul nu trebuie tratat doar ca o pagină juridică. Este un proces care implică:

inițierea cererii;
validarea eligibilității;
transportul;
recepția produsului;
evaluarea stării;
reintegrarea în stoc;
emiterea documentelor;
rambursarea;
actualizarea raportării.

Pentru vânzările către consumatori există obligații legale de informare, retragere și garanție care trebuie transpuse în interfață și procese, nu doar în termeni și condiții. Regula generală europeană oferă consumatorului un termen de 14 zile pentru retragerea din majoritatea contractelor la distanță, cu excepțiile prevăzute de lege.

Acest articol nu înlocuiește consultanța juridică. Cerințele aplicabile trebuie validate pentru tipul de produse, clienți și piețe vizate.

Structura organizațională

Un magazin online nu trebuie lăsat exclusiv în responsabilitatea „omului de marketing” sau a furnizorului tehnic.

Sponsorul executiv

Sponsorul:

aprobă obiectivele;
alocă resurse;
rezolvă conflictele între departamente;
susține schimbarea proceselor;
urmărește rezultatele comerciale.

Ownerul comercial

Ownerul comercial răspunde de:

ofertă;
portofoliu;
prețuri;
promoții;
obiectivele de vânzare și marjă;
relația cu celelalte canale.

Product ownerul sau managerul e-commerce

Acest rol coordonează:

roadmapul;
cerințele;
furnizorii;
testarea;
prioritizarea dezvoltărilor;
incidentele;
îmbunătățirea continuă.

Operațiunile

Operațiunile administrează:

comenzile;
stocul;
livrarea;
retururile;
excepțiile;
relația cu depozitul și curierii.

Marketingul

Marketingul trebuie să gestioneze cererea și comunicarea, dar nu poate compensa un model comercial neviabil sau un proces de livrare defect.

Financiarul

Rolul financiar include:

reconcilierea plăților;
facturarea;
tratamentul retururilor;
marja;
cash-flow;
raportarea profitabilității.

IT și dezvoltarea

Echipa tehnică trebuie să susțină:

arhitectura;
securitatea;
integrările;
performanța;
testarea;
monitorizarea;
recuperarea după incidente.

Matrice RACI orientativă

Decizie	Responsabil principal	Funcții consultate
Portofoliu	Comercial	Marketing, logistică, financiar
Prețuri	Comercial/management	Financiar, marketing
Platformă	Product owner	IT, comercial, operațiuni
Tracking	Analytics/marketing	IT, financiar
Retururi	Operațiuni	Juridic, financiar, support
Roadmap	Sponsor și product owner	Toate funcțiile relevante

Furnizorul platformei poate implementa, dar nu poate prelua responsabilitatea managerială pentru modelul comercial al companiei.

Cerințele funcționale

Cerințele trebuie derivate din clienți și procese, nu copiate din prezentarea unei platforme.

Magazinul poate necesita:

catalog simplu sau complex;
variante;
bundle-uri;
configuratoare;
produse personalizate;
prețuri B2B;
liste de preț;
abonamente;
multi-currency;
multi-language;
multi-store;
marketplace integration;
loyalty;
click and collect;
POS;
retur online;
cont client;
aprobări B2B;
cereri de ofertă;
programări;
finanțare;
reguli de compatibilitate.

Must have, should have și later

Nu toate cerințele trebuie implementate înainte de prima lansare.

O clasificare utilă:

Critic pentru lansare: fără funcție, procesul nu poate funcționa sau nu este conform;
Important: crește eficiența ori experiența, dar există alternativă temporară;
Ulterior: poate fi dezvoltat după validarea canalului;
Nejustificat: costul și complexitatea depășesc valoarea așteptată.

Această prioritizare reduce riscul unui proiect prea mare, prea scump și lansat prea târziu.

Integrările

O integrare nu este doar existența unui plugin. Este un flux de date care trebuie să funcționeze corect, repetabil și observabil.

Integrările pot include:

ERP;
WMS;
CRM;
facturare;
e-Factura;
procesator de plăți;
curieri;
marketplace-uri;
Google Merchant Center;
email marketing;
customer support;
PIM;
business intelligence;
analytics;
fraud prevention;
loyalty;
POS.

Întrebările care trebuie puse pentru fiecare integrare

Ce date circulă?
Care este direcția?
Care sistem este sursa oficială?
Cât de des se sincronizează?
Ce se întâmplă când datele lipsesc?
Cum sunt identificate duplicatele?
Cine primește alerta de eroare?
Cum este reluat procesul?
Ce se întâmplă când unul dintre sisteme este indisponibil?
Cum sunt reconciliate diferențele?

Exemplu: integrarea stocului

O specificație superficială spune:

Magazinul se integrează cu ERP-ul.

O specificație utilă trebuie să clarifice:

stocul disponibil sau stocul fizic;
rezervările;
stocul pe depozit;
frecvența actualizării;
produsele fără stoc;
precomenzile;
anulările;
comenzile din alte canale;
comportamentul în cazul erorilor.

SaaS versus open-source versus custom

Nu există o platformă universal optimă. Alegerea corectă depinde de modelul comercial, complexitatea proceselor, timpul de lansare, buget, competențele interne și toleranța la dependență.

Ce este o platformă SaaS

În modelul Software as a Service, infrastructura și produsul principal sunt administrate de furnizor. Comerciantul plătește, de regulă, un abonament și folosește funcțiile și extensiile disponibile.

Avantaje posibile

lansare mai rapidă;
infrastructură administrată;
actualizări centralizate;
suport oferit de furnizor;
cost inițial mai previzibil;
mai puțină responsabilitate tehnică internă;
integrări locale disponibile în anumite ecosisteme.

Limite posibile

control redus asupra codului;
dependență de roadmapul furnizorului;
costuri recurente;
limitări de personalizare;
costuri pentru aplicații și extensii;
migrare mai dificilă;
acces diferit la date;
vendor lock-in.

Exemple întâlnite în România

În categoria SaaS sunt întâlnite platforme locale și internaționale precum:

Gomag;
MerchantPro;
Shopify;
VTEX;
Wix eCommerce;
alte soluții găzduite.

Enumerarea nu reprezintă recomandare și nu indică o ordine valorică. Funcțiile, costurile și condițiile se pot modifica, iar adecvarea trebuie evaluată pe cerințele companiei.

Ce este o platformă open-source

În modelul open-source, codul de bază este disponibil pentru instalare și modificare. Compania sau integratorul administrează găzduirea, extensiile, securitatea și actualizările.

Avantaje posibile

control mai mare;
acces la cod;
libertate de găzduire;
ecosisteme extinse;
posibilitatea dezvoltărilor profunde;
portabilitate teoretic mai bună;
control mai mare asupra arhitecturii și datelor.

Limite posibile

responsabilitate pentru hosting și securitate;
mentenanță continuă;
actualizări și compatibilități;
dependență de integrator;
costuri dificil de anticipat;
datorie tehnică;
riscuri generate de extensii de calitate diferită.

Exemple întâlnite în România

WooCommerce;
PrestaShop;
OpenCart;
Magento Open Source;
Shopware;
alte frameworkuri și soluții headless.

Sursele care detectează tehnologiile folosite de magazinele românești raportează metodologii și cote diferite. Ele indică însă în mod repetat o prezență importantă a WooCommerce, Shopify, PrestaShop, OpenCart, Gomag, MerchantPro, Magento și soluțiilor custom. Aceste date trebuie tratate ca estimări tehnologice, nu ca dovadă că una dintre platforme este mai potrivită pentru un proiect.

Ce înseamnă custom

O soluție custom este dezvoltată integral sau substanțial în jurul proceselor și arhitecturii companiei.

Avantaje posibile

potrivire profundă cu procesele;
control asupra roadmapului;
diferențiere;
integrare cu sisteme proprietare;
flexibilitate arhitecturală;
posibilitatea susținerii unor modele neobișnuite.

Limite posibile

cost inițial ridicat;
timp mai mare de lansare;
risc de proiect;
dependență de echipa de dezvoltare;
mentenanță continuă;
nevoia de documentație și testare;
riscul reconstruirii unor funcții deja rezolvate;
dificultatea estimării costului total.

Custom nu înseamnă automat mai bun sau mai scalabil. O soluție custom prost documentată și dependentă de câțiva dezvoltatori poate fi mai rigidă decât o platformă standard.

Comparație orientativă

Criteriu	SaaS	Open-source	Custom
Viteză de lansare	De regulă ridicată	Medie	De regulă redusă
Control tehnic	Redus–mediu	Ridicat	Foarte ridicat
Efort intern IT	Redus–mediu	Mediu–ridicat	Ridicat
Predictibilitatea costului inițial	Mai bună	Variabilă	Redusă
Flexibilitate	Limitată de platformă	Ridicată	Foarte ridicată
Dependență	Furnizorul platformei	Integrator, hosting și extensii	Echipă și arhitectură
Mentenanță	În principal furnizor	Companie sau integrator	Companie sau echipă dedicată
Procese foarte specifice	Pot necesita compromisuri	Pot fi dezvoltate	Pot fi proiectate direct

Tabelul exprimă tendințe generale, nu verdicte.

Criteriul corect de alegere

Întrebarea greșită este:

Care este cea mai bună platformă?

Întrebarea utilă este:

Care opțiune oferă cea mai bună combinație între potrivirea cu procesele, timpul de lansare, riscul de implementare, costul total și capacitatea internă de administrare?

Când poate fi potrivit SaaS

compania dorește lansare rapidă;
procesele sunt relativ standard;
echipa tehnică internă este limitată;
integrările necesare există;
personalizarea profundă nu este critică;
costurile recurente sunt acceptabile.

Când poate fi potrivit open-source

este nevoie de control tehnic;
există integrator competent;
compania poate administra mentenanța;
cerințele depășesc configurarea standard;
este importantă libertatea de hosting și extensie.

Când poate fi justificat custom

modelul comercial este dificil de susținut prin produse standard;
procesele reprezintă un avantaj competitiv;
volumele justifică investiția;
compania are competențe și guvernanță tehnică;
riscul și costul sunt acceptate;
roadmapul pe termen lung este clar.

Costul total de proprietate

Prețul abonamentului sau al implementării inițiale nu reprezintă costul total.

Costuri inițiale

cercetare și analiză;
definirea modelului comercial;
arhitectură;
design;
configurare;
dezvoltare;
integrări;
migrare de date;
conținut;
fotografie;
QA;
training;
consultare juridică;
tracking și raportare.

Costuri recurente

abonament;
hosting;
licențe;
extensii;
mentenanță;
suport;
dezvoltări;
CDN;
monitorizare;
backup;
securitate;
procesare plăți;
personal;
servicii externe.

Costuri ascunse

operațiuni manuale;
date incorecte;
erori de stoc;
downtime;
incompatibilități;
întârzieri;
schimbări legislative;
dependența de furnizor;
migrarea ulterioară;
oportunități ratate;
datoria tehnică.

Evaluarea pe trei ani

O comparație corectă trebuie să includă:

TCO = cost inițial + costuri recurente + mentenanță + dezvoltări + operare + risc estimat + migrare probabilă

Formula nu produce singură decizia, dar obligă compania să privească dincolo de prețul de intrare.

Cum scrii brief-ul

Fără un brief suficient de clar, ofertele furnizorilor nu pot fi comparate.

Brief-ul trebuie să includă:

obiective comerciale;
segmente de clienți;
model B2C, B2B sau mixt;
catalog și volum de produse;
țări și limbi;
procesele actuale;
volumele de trafic și comenzi;
integrările;
regulile de preț;
promoțiile;
rolurile interne;
raportarea;
securitatea;
performanța;
SEO;
accesibilitatea;
cerințele legale;
criteriile de acceptanță;
roadmapul;
bugetul;
restricțiile.

Obiectivele trebuie să fie măsurabile

„Vrem un magazin modern” nu este obiectiv.

Exemple mai utile:

reducerea comenzilor procesate manual;
lansarea unei categorii în maximum două zile;
sincronizarea stocului în mai puțin de cinci minute;
acceptarea comenzilor B2B cu prețuri negociate;
reconcilierea automată a plăților;
măsurarea marjei pe comandă;
reducerea erorilor de stoc;
lansarea într-o nouă țară.

Criteriile de acceptanță

Pentru fiecare funcție trebuie definit ce înseamnă „funcționează”.

Exemplu:

Când plata este confirmată, comanda primește automat statutul „plătită”, stocul este rezervat, factura poate fi emisă, iar clientul primește confirmarea o singură dată.

Cum compari ofertele

Prețul trebuie analizat împreună cu:

potrivirea funcțională;
integrările;
costul total pe trei ani;
timpul de lansare;
limitările;
securitatea;
ownershipul datelor;
posibilitatea de export;
SLA-ul;
roadmapul;
suportul;
referințele;
dependențele;
capacitatea echipei;
planul de migrare.

Întrebări pentru furnizor

Cine deține codul și datele?
Putem exporta catalogul, clienții și comenzile?
Ce se întâmplă la încetarea contractului?
Cine răspunde pentru securitate?
Cum sunt gestionate actualizările?
Cum sunt testate integrările?
Ce nu poate face soluția?
Ce costuri nu sunt incluse?
Cum sunt tratate incidentele?
Ce resurse trebuie să asigure clientul?

Un furnizor credibil trebuie să poată explica limitele soluției, nu doar avantajele.

Conținutul necesar înainte de lansare

Conținutul este adesea subestimat în planificarea proiectului.

Magazinul poate necesita:

descrieri de produs;
specificații;
imagini;
video;
categorii;
ghiduri de alegere;
întrebări frecvente;
informații despre livrare;
politici de retur;
garanții;
informații despre companie;
pagini de suport;
documente tehnice;
traduceri.

Cine deține informația?

Echipa de content poate redacta, dar informația poate proveni de la:

product management;
furnizori;
tehnic;
juridic;
logistică;
customer support;
comercial.

Trebuie stabilite fluxurile de furnizare, verificare și actualizare.

Arhitectura, SEO și datele comerciale

Cerințele SEO importante trebuie introduse în proiect de la început. Repararea ulterioară a catalogului, URL-urilor și filtrelor poate fi costisitoare.

Proiectul trebuie să acopere:

structura categoriilor;
URL-uri stabile;
variante;
filtre;
paginare;
canonicalizare;
sitemapuri;
date structurate;
imagini;
performanță;
linking intern;
migrare.

Google recomandă ca produsele să poată fi descoperite prin linkuri de la categorie la subcategorie și produs. Produsele accesibile numai prin căutarea internă pot fi mai greu de descoperit de crawlere.

Datele produselor pot fi transmise și prin structured data și Google Merchant Center. Aceste sisteme nu înlocuiesc pagina produsului, ci o completează.

Analytics și tracking

Magazinul trebuie să poată măsura rezultatele relevante, nu doar vizitele.

Definițiile trebuie stabilite înainte de implementare

Ce înseamnă o comandă?
Ce înseamnă o comandă validă?
Venitul include TVA?
Include transportul?
Discountul este transmis?
Cum sunt tratate anulările?
Cum sunt tratate retururile?
Care este identificatorul unic?
Cum este transmisă marja?
Cum sunt reconciliate sistemele?

Evenimentele importante

vizualizare produs;
selectare variantă;
adăugare în coș;
începere checkout;
selectare livrare;
selectare plată;
purchase;
refund;
lead sau cerere de ofertă;
căutare internă;
erori de plată.

Reconcilierea

Analytics nu trebuie tratat ca sistem contabil. Datele trebuie comparate cu:

platforma e-commerce;
ERP;
procesatorul de plăți;
facturarea;
retururile;
contabilitatea.

Diferențele trebuie explicate, nu ascunse prin ajustarea arbitrară a raportului.

Conformitatea nu este doar o colecție de documente

Un magazin trebuie să prezinte informațiile obligatorii și să implementeze procese conforme pentru comandă, plată, livrare, retragere, retur, garanții și protecția datelor.

Trebuie analizate:

identitatea comerciantului;
datele de contact;
caracteristicile produselor;
prețul total;
costurile de livrare;
metodele de plată;
termenul de livrare;
dreptul de retragere;
excepțiile;
garanțiile;
reclamațiile;
datele personale;
cookie-urile;
consimțământul;
comunicările comerciale.

Conformitatea trebuie verificată de un specialist juridic. O temă cumpărată sau un plugin nu garantează respectarea obligațiilor.

Planul de lansare

O lansare controlată reduce riscul. Un proiect nu trebuie publicat pentru întregul public imediat ce dezvoltarea pare finalizată.

QA funcțional

produse;
variante;
căutare;
filtre;
coș;
checkout;
cont client;
emailuri;
documente;
retur.

QA comercial

prețuri;
discounturi;
marje;
stoc;
livrare;
promoții;
condiții B2B;
bundle-uri.

QA operațional

comanda ajunge unde trebuie;
stocul este rezervat;
AWB-ul este generat;
depozitul primește informațiile;
statuturile se actualizează;
excepțiile pot fi gestionate;
returul poate fi procesat.

QA financiar

plata este confirmată;
factura este corectă;
rambursarea funcționează;
tranzacțiile pot fi reconciliate;
TVA-ul și moneda sunt corecte;
discounturile sunt înregistrate.

QA tracking

evenimentele se transmit o singură dată;
transaction ID este unic;
valoarea este corectă;
produsele sunt corecte;
consimțământul este respectat;
sursele sunt păstrate;
cross-domain tracking funcționează.

QA tehnic

performanță mobilă;
securitate;
backup;
monitorizare;
redirecturi;
indexare;
structured data;
erori de server.

Ordinea recomandată

testare internă;
comenzi reale controlate;
pilot cu utilizatori limitați;
soft launch;
monitorizarea incidentelor;
corectarea problemelor;
lansarea extinsă;
optimizarea continuă.

Pentru descoperirea în Google, compania trebuie să verifice proprietatea site-ului, să trimită sitemapul, să monitorizeze indexarea și, unde este relevant, să configureze Google Merchant Center.

Ce măsori după lansare

Traficul și venitul nu sunt suficiente.

Indicatori comerciali

venit net;
marjă brută;
marjă de contribuție;
valoarea medie a comenzii;
produse per comandă;
profitabilitate pe categorie;
profitabilitate pe canal;
clienți noi și recurenți.

Indicatori de marketing

cost de achiziție;
MER;
ROAS, interpretat cu limitele sale;
trafic pe surse;
conversie;
brand versus non-brand;
venit incremental, unde poate fi estimat.

Indicatori operaționali

timp de procesare;
timp de livrare;
rata anulărilor;
rata retururilor;
comenzi refuzate;
erori de stoc;
contacte în suport;
cost per comandă procesată.

Indicatori de experiență

rata de finalizare a checkoutului;
erori de plată;
căutări fără rezultate;
filtre utilizate;
produse comparate;
reclamații;
motive de retur;
recomandări și satisfacție, unde sunt măsurate corect.

Indicatori tehnici

uptime;
timp de răspuns;
Core Web Vitals;
erori de integrare;
comenzi blocate;
produse neactualizate;
pagini neindexate;
incidente de securitate.

Greșeli frecvente

Alegerea platformei înaintea modelului

Compania selectează o platformă după preț sau popularitate și descoperă ulterior că procesele importante necesită compromisuri sau dezvoltări costisitoare.

Confundarea lansării cu succesul

Publicarea site-ului este un rezultat de proiect, nu un rezultat comercial.

Ignorarea marjei

Se urmăresc venitul și ROAS-ul, dar nu costul produsului, retururile, transportul și costul servirii.

Catalog prea mare

Mii de produse sunt importate fără imagini, atribute, conținut și o strategie de stoc.

Lipsa ownerului intern

Furnizorul primește decizii contradictorii de la mai multe departamente, iar nimeni nu deține rezultatul final.

Integrarea tratată superficial

Proiectul presupune că „pluginul rezolvă” fără definirea surselor de date, erorilor și reconcilierii.

Subestimarea conținutului

Platforma este gata, dar produsele nu au informații suficiente pentru publicare.

Subestimarea retururilor

Procesul este proiectat pentru vânzare, nu și pentru situațiile în care produsul se întoarce.

Dependența de publicitate

Modelul presupune că traficul plătit va fi disponibil permanent la același cost.

Open-source confundat cu gratuit

Lipsa unei licențe nu elimină costurile de hosting, dezvoltare, actualizare, securitate și suport.

SaaS presupus automat limitat

Unele companii resping SaaS fără să compare timpul de lansare, costul de operare și cerințele reale.

Custom fără justificare

Se reconstruiesc funcții standard doar pentru a obține „control total”, fără un avantaj comercial care să justifice investiția.

Lansare fără QA complet

Se testează designul și checkoutul, dar nu stocul, returul, reconcilierea, emailurile și trackingul.

Lipsa capitalului de lucru

Magazinul generează comenzi, dar compania nu poate finanța stocul, promoțiile și ciclul de încasare.

Checklist managerial înainte de decizie

Piață și client

Există cerere verificată?
Ce problemă rezolvăm?
Cine este clientul prioritar?
Ce alternative folosește?
De ce ar cumpăra de la noi?
Ce riscuri percepe?

Model economic

Cunoaștem marja pe produs?
Am inclus costul livrării și returului?
Ce CAC poate susține modelul?
Care este valoarea medie necesară?
Există recurență?
Avem capitalul de lucru necesar?

Portofoliu

Ce produse lansăm prima dată?
Ce rol are fiecare categorie?
Ce produse aduc marjă?
Ce produse generează retururi?
Datele sunt complete?
Stocurile sunt fiabile?

Procese

Cum intră comanda?
Cine o validează?
Cum este rezervat stocul?
Cum se emite factura?
Cum se livrează?
Cum se procesează returul?
Cum se rambursează plata?
Cum sunt gestionate excepțiile?

Organizație

Cine este sponsorul?
Cine este ownerul comercial?
Cine deține roadmapul?
Cine administrează catalogul?
Cine răspunde pentru operațiuni?
Cine verifică datele?
Ce responsabilități au furnizorii?

Tehnologie

Ce cerințe sunt critice?
Ce integrări sunt necesare?
Care este sistemul sursă pentru fiecare tip de date?
Ce opțiune reduce riscul total?
Putem exporta datele?
Cine administrează securitatea?
Cum arată planul de migrare?

Date și măsurare

Ce înseamnă o comandă validă?
Cum definim venitul?
Cum tratăm retururile?
Avem transaction ID unic?
Putem calcula marja pe comandă?
Putem reconcilia analytics cu sistemele comerciale?

Conformitate

Sunt prezentate informațiile obligatorii?
Procesul de comandă este clar?
Returul poate fi exercitat și procesat?
Garanțiile sunt administrate?
Datele personale sunt protejate?
Consimțământul este gestionat?
Documentele au fost validate juridic?

Lansare

Au fost testate comenzi reale?
Au fost testate plățile și rambursările?
Au fost testate stocurile?
Au fost testate retururile?
Trackingul a fost auditat?
Există monitorizare și alerte?
Există plan de revenire?

Creare magazin online nu înseamnă alegerea unei teme, instalarea unui coș și încărcarea produselor. Înseamnă proiectarea unui canal comercial care trebuie să funcționeze economic, operațional, organizațional și tehnic.

Ordinea corectă începe cu piața, clientul, oferta și modelul economic. Continuă cu portofoliul, procesele, responsabilitățile, datele și cerințele funcționale. Alegerea dintre SaaS, open-source și custom vine abia după ce compania știe ce trebuie să susțină tehnologia.

Niciuna dintre cele trei opțiuni nu este automat superioară. SaaS poate reduce timpul și responsabilitatea tehnică. Open-source poate oferi control și flexibilitate. Custom poate susține procese unice. Fiecare aduce însă costuri, dependențe și riscuri diferite.

Un magazin online bun nu este cel cu cele mai multe funcții. Este cel care susține o ofertă viabilă, promite ceea ce organizația poate livra, produce date suficient de corecte și contribuie la vânzări, marjă și relații comerciale sustenabile.

Dacă pregătești lansarea sau refacerea unui magazin online, analiza ar trebui să înceapă cu modelul comercial, procesele, datele și cerințele organizației. Serviciul Semantik de strategie și dezvoltare e-commerce poate ajuta la definirea acestor decizii înainte de selectarea platformei sau a furnizorului.

Surse și lecturi suplimentare

Google Search Central: bune practici pentru site-uri e-commerce — structură, lansare, date de produs și vizibilitate în Search.
Google Search Central: structura unui site e-commerce — linking între categorii, subcategorii și produse.
Google Search Central: structura URL-urilor pentru e-commerce — parametri, paginare și variante.
Google Search Central: transmiterea datelor de produs — structured data și Google Merchant Center.
Google Search Central: lansarea unui magazin online — indexare, sitemap și monitorizare.
Directiva 2011/83/UE privind drepturile consumatorilor — informare, contracte la distanță și dreptul de retragere.
Consiliul Uniunii Europene: drepturile cumpărătorilor — garanții, retragere, siguranța produselor și informații clare.
WMTips: tehnologii e-commerce detectate în România — estimare tehnologică bazată pe site-uri analizate.
ShopRank: magazine și platforme e-commerce din România — estimare bazată pe magazine detectate și verificate de furnizor.

Continuă analiza

Obligațiile legale ale unui magazin online — pentru informare, comandă, livrare, retragere, retur și garanții.
Produse care vând versus produse care aduc profit — pentru selecția și rolul comercial al portofoliului.
Diferențe între veniturile GA4 și comenzile magazinului — pentru reconcilierea datelor comerciale.
Audit de tracking — pentru verificarea datelor înainte ca acestea să fie folosite în decizii.