Egy webshop adminfelülete akkor válik problémává, amikor már érkeznek a rendelések. A webshop adminisztrációs rendszer beállítása ezért nem egy egyszeri technikai feladat, hanem a napi kereskedelmi folyamatok megtervezése: ki rögzíti a terméket, ki kezeli a rendelést, honnan jön a készletinformáció, mikor készül számla, és hogyan kap pontos tájékoztatást a vásárló. Ha ezek a lépések nincsenek összerakva, a növekedés több manuális munkát és több hibalehetőséget hoz, nem több kontrollt.
A webshop adminisztrációs rendszer beállítása üzleti folyamatként
A jó adminisztráció nem attól jó, hogy sok menüpontot tartalmaz, hanem attól, hogy a munkatársak következetesen tudnak benne dolgozni. Egy kisebb webáruháznál lehet, hogy ugyanaz a személy tölti fel a termékeket, kezeli a rendeléseket és válaszol az ügyfélszolgálati kérdésekre. Néhány száz vagy ezer rendelésnél azonban ezek a feladatok gyorsan különválnak. A rendszernek ezt kell lekövetnie, nem pedig egy elképzelt, túl bonyolult vállalati modellt.
Érdemes még az éles indulás előtt végigvenni egy rendelés útját. A vásárló leadja a rendelést, a fizetés visszaigazolása megérkezik, a készlet csökken, a kolléga összekészíti a csomagot, elkészül a számla, a futár átveszi a küldeményt, majd a vevő értesítést kap. Minden pontnál legyen világos, hogy melyik rendszer végzi a feladatot, mi történik sikertelen fizetés esetén, és ki avatkozik be, ha az automatikus folyamat megakad.
UNAS és OpenCart környezetben is alapelv, hogy csak olyan funkciót kapcsoljunk be, amelyhez valós üzleti folyamat tartozik. Egy rosszul paraméterezett rendelési státusz, egy felesleges értesítő e-mail vagy egy félkész számlázó kapcsolat napi szinten lassítja az ügyintézést.
Termékek, kategóriák és készlet: az admin alapadatai
Az adminisztráció megbízhatósága a termékadatoknál kezdődik. A terméknév, cikkszám, ár, áfakulcs, készlet, súly, szállítási tulajdonságok és a kategóriabesorolás nem csak a termékoldal tartalma. Ezekből dolgozik a számlázás, a szállítási díjszámítás, a raktár, a termékfeed és sok esetben a hirdetési rendszer is.
Különösen figyelni kell a változatos termékekre. Méret, szín, kiszerelés vagy kompatibilitás esetén nem elegendő annyit beállítani, hogy a vásárló választhasson egy opciót. El kell dönteni, hogy változatonként eltér-e a készlet, az ár, a cikkszám vagy a szállítási idő. Ha igen, ezt az adminban is külön kezelhető módon kell felépíteni. Ellenkező esetben a webshop olyan terméket is eladhat, amely valójában nincs raktáron.
Importtal induló vagy költöző áruháznál az adatforrás ellenőrzése ugyanilyen fontos. A táblázatban szereplő elnevezések, kategóriák és készletértékek gyakran nem illeszkednek egy az egyben az új rendszer logikájához. Az import-export folyamatot érdemes mintaadatokkal tesztelni, mielőtt több ezer termék kerül be az éles adminba. A hibás tömeges import javítása rendszerint sokkal költségesebb, mint az előzetes adatellenőrzés.
Készletkezelésnél a valós raktári helyzet számít
A készletkezelés beállítása attól függ, saját raktárból, beszállítói készletből vagy több forrásból teljesítik-e a rendeléseket. Saját készletnél fontos a készletcsökkentés pontos időpontja. Bankkártyás fizetésnél más lehet a logika, mint utánvétnél vagy banki átutalásnál. Nem célszerű például minden függőben lévő rendelésnél véglegesen lefoglalni a készletet, ha a fizetés nem érkezik meg automatikusan.
Beszállítói készlet esetén a frissítés gyakorisága és a hibakezelés a kritikus pont. A napi egyszeri adatkapcsolat elég lehet lassan forgó termékeknél, de kevés az olyan kategóriákban, ahol a készlet órák alatt elfogy. Ilyenkor a termékoldalon ígért elérhetőségnek, az import ütemezésének és a rendelési folyamatnak együtt kell működnie.
Rendelési státuszok és ügyfélkommunikáció
A rendelési státuszok sok webshopban kaotikusak: „új”, „feldolgozás alatt”, „fizetve”, „szállítás alatt”, „lezárt”, valamint több, hasonló jelentésű egyedi állapot szerepel egymás mellett. A cél nem a lehető legtöbb státusz létrehozása, hanem az, hogy a kolléga egy pillantással lássa a következő teendőt.
A státuszokat kapcsoljuk konkrét eseményekhez. Például a „fizetésre vár” azt jelentse, hogy az utalás ellenőrzése még hátra van, a „csomagolásra vár” azt, hogy a rendelés teljesíthető, a „feladva” pedig azt, hogy a fuvarlevél elkészült vagy a csomagot a futár átvette. A vásárlónak küldött e-maileknek sem kell minden belső állapotváltozást követniük. A túl sok automatikus üzenet bizonytalanságot okozhat, a túl kevés pedig ügyfélszolgálati terhelést növel.
A beállítás során ellenőrizni kell az e-mail sablonokat, a feladónevet, a válaszcímet és az értesítések nyelvezetét is. A rendelési visszaigazolásban a vevő azt keresi, hogy sikeres volt-e a vásárlás, mit rendelt, mennyit fizetett, hogyan kapja meg a csomagot, és kitől kérhet segítséget. Ez nem látványos fejlesztés, mégis közvetlenül hat a bizalomra.
Fizetés, számlázás és szállítás egy rendszerben
A fizetési és szállítási modulok konfigurációja nem választható el az adminisztrációtól. A bankkártyás szolgáltató visszajelzéseinek, a számlázóprogramnak és a futárszolgálat adatainak ugyanahhoz a rendeléshez kell kapcsolódniuk. Ha a rendelésazonosító, a fizetési státusz vagy az ügyféladatok eltérnek a rendszerek között, manuális javításra lesz szükség.
Számlázásnál dönteni kell arról, mikor jöjjön létre a bizonylat. Előre fizetett rendelésnél sok esetben a sikeres tranzakció után készülhet számla, utánvétnél azonban más lehet a helyes üzleti és könyvelési folyamat. A konkrét beállítást érdemes a könyvelési gyakorlathoz igazítani, nem pusztán a modul alapértelmezett működését elfogadni.
Szállításnál a díjtáblák, az ingyenes szállítási határ, az utánvét díja, a csomagpontok és a súlyhatárok külön tesztelést igényelnek. Egy 0 forintos vagy indokolatlanul magas szállítási költség a pénztárban könnyen félbehagyott rendelést eredményez. Nem elég azt ellenőrizni, hogy a szállítási mód megjelenik-e: végig kell próbálni a tipikus kosárértékeket, fizetési módokat és földrajzi célterületeket.
Jogosultságok és napi kontroll
Nem minden adminfelhasználónak van szüksége teljes hozzáférésre. A termékfeltöltőnek például nem feltétlenül kell a fizetési beállításokat vagy a felhasználói jogosultságokat módosítania, az ügyfélszolgálatosnak pedig nem kell rendszerbeállításokat látnia. A szerepkörök kialakítása csökkenti a véletlen hibák esélyét, és egyértelműbbé teszi a felelősséget is.
Különösen OpenCart esetén érdemes figyelni arra, hogy a bővítmények és egyedi fejlesztések milyen jogosultságokat kérnek, illetve egy frissítés után minden adminfunkció változatlanul elérhető-e. UNAS-nál a rendszer keretei adottabbak, ezért a beépített funkciók és külső integrációk lehetőségeit kell előre felmérni. Az egyik rendszer nagyobb szabadságot adhat, a másik gyorsabb, standardizáltabb üzemeltetést – a jó választás a webshop folyamatain múlik.
A napi kontrollhoz elegendő néhány következetesen használt ellenőrzési pont: vannak-e új, feldolgozatlan rendelések; történt-e sikertelen fizetés; van-e negatív vagy bizonytalan készlet; elkészültek-e a számlák és fuvarlevelek; érkezett-e rendszerhiba-jelzés. Ezeket nem kell feltétlenül kézzel keresni, de tudni kell, hol és milyen jelzéssel jelennek meg.
Tesztelés élesítés előtt és költözés után
Egy adminrendszer beállítása csak akkor tekinthető késznek, ha tesztrendelések is igazolják a működését. Próbálni kell bankkártyás és utánvétes vásárlást, kuponos rendelést, eltérő szállítási módot, készlethiányos terméket, rendelésmódosítást és törlést. A teszt célja nem kizárólag a hibakeresés: ebből derül ki, hogy a munkatársak számára érthető-e a rendeléskezelés.
Webshopköltözéskor további kockázatot jelent az adatátvitel. A termékek és ügyfelek importja mellett ellenőrizni kell a rendelési előzményeket, képeket, keresőbarát URL-eket, metaadatokat és átirányításokat is. Az adminisztrációs beállításoknak az új rendszerben kell támogatniuk a régi üzletmenetet, miközben nem vihetik tovább automatikusan a korábbi hibás folyamatokat.
A jól beállított adminfelület nem feltűnő: a rendelés halad, a készlet követhető, az ügyfél információt kap, a kolléga pedig tudja a következő lépést. Ha egy folyamat kivétel nélkül kézi ellenőrzést vagy táblázatjavítást igényel, azt érdemes még a forgalom növekedése előtt átalakítani.
