Egy webshopban a rendelés leadása csak a folyamat eleje. Ha a fizetési visszajelzés nem jut el az áruházba, a számla hibás adatokkal készül el, vagy a készlet csak órákkal később frissül, abból gyorsan ügyfélszolgálati teher és elveszett bevétel lesz. Ez a webshop integrációs útmutató abban segít, hogy a kapcsolatok ne különálló modulokként, hanem az értékesítési folyamat egymásra épülő részeiként működjenek.
A jó integráció nem attól jó, hogy sok rendszer kapcsolódik a webshophoz. Attól jó, hogy a rendelési adatok a megfelelő pillanatban, a megfelelő formában kerülnek át a következő rendszerbe, és hiba esetén is visszakövethető, mi történt. UNAS és OpenCart esetén ehhez eltérő technikai lehetőségek állnak rendelkezésre, de az üzleti kérdések ugyanazok: mi legyen automatizált, ki kezelje a kivételeket, és milyen adat legyen az egyetlen hiteles forrás.
Webshop integrációs útmutató: először a folyamatot tervezze meg
Sok webshopnál az integrációk egymás után kerülnek be: előbb online fizetés, később számlázó, majd futármodul, végül készletkezelő vagy vállalatirányítási rendszer. Ez önmagában nem probléma, de ha nincs előtte folyamatábra, könnyen több helyen is ugyanazt az adatot kezdik szerkeszteni.
A kiindulópont a rendelés életútja legyen. A vásárló kiválasztja a terméket, megadja a szállítási és számlázási adatokat, fizet, majd a rendelés átkerül feldolgozásra, számlázásra, csomagolásra és kiszállításra. Minden állomásnál érdemes rögzíteni, melyik rendszer indítja a műveletet, melyik rendszer kap adatot, és mi történik sikertelen adatátadás esetén.
Például az online fizetés státusza nem azonos a rendelés teljesítésével. A sikeres bankkártyás tranzakció alapján a webshop megjelölheti a rendelést fizetettként, de számlát csak akkor célszerű automatikusan kiállítani, ha ehhez a vállalkozás számlázási és teljesítési folyamata is illeszkedik. Utánvétnél pedig jellemzően más logika kell, hiszen a fizetés később, a futárnál történik meg.
Már ebben a tervezési szakaszban tisztázni kell az alábbi négy kérdést: honnan érkeznek a termék- és készletadatok, mikor kap a vásárló automatikus értesítést, melyik rendelési státusz vált ki számlázást vagy szállítási feladást, és ki ellenőrzi a hibás vagy függőben maradt rendeléseket. E kérdésekre adott válaszok többet számítanak, mint maga a választott bővítmény neve.
A legfontosabb webshop-integrációk
Fizetési szolgáltató: ne csak a fizetési gomb működjön
A fizetési integráció első látásra egyszerű feladatnak tűnik. A vásárló átkerül a szolgáltató felületére, fizet, majd visszatér a webshopba. A kritikus rész azonban a háttérben érkező visszaigazolás. Ennek kell megbízhatóan frissítenie a rendelés állapotát akkor is, ha a vásárló bezárja a böngészőt, vagy a visszairányítás megszakad.
Ellenőrizni kell, hogy a sikertelen, megszakított és függő tranzakciók milyen státuszt kapnak. Az is lényeges, hogy egy sikertelen fizetés után a vásárló tud-e újra fizetni anélkül, hogy új rendelést kellene leadnia. Bizonyos üzleti modelleknél a bankkártya, az átutalás és az utánvét más-más kedvezményhez, szállítási módhoz vagy rendelésfeldolgozási szabályhoz kapcsolódhat.
UNAS rendszerben a támogatott fizetési megoldások és a beállítási lehetőségek keretet adnak a megvalósításnak. OpenCartnál nagyobb szabadságot adhat egy egyedi fejlesztés vagy módosított modul, de ezzel együtt a frissíthetőség és a későbbi karbantartás felelőssége is nagyobb. Nem mindig az egyedi megoldás a jobb választás: ha egy bevált integráció lefedi az igényeket, az általában kiszámíthatóbban üzemeltethető.
Számlázás: a státuszlogika itt különösen fontos
A számlázóprogrammal való kapcsolatnál nem elég az adatok átadása. A számlán szereplő vevőadatoknak, tételeknek, kedvezményeknek, szállítási díjnak és fizetési módnak is helyesen kell megjelennie. Egyetlen eltérő áfakulcs, kerekítési szabály vagy hibásan kezelt kupon elegendő ahhoz, hogy a számlázás manuális javítást igényeljen.
Dönteni kell arról is, hogy a számla automatikusan készüljön-e el rendeléskor, fizetés után, csomagfeladáskor vagy kizárólag manuális jóváhagyással. Nincs minden webshopra érvényes válasz. Digitális terméknél más lehet a logika, mint raktárról szállított, részben elérhető vagy előrendelhető termékeknél.
A tesztelés során ne csak egy átlagos rendelést vizsgáljon. Próbáljon ki kedvezményes kosarat, utánvétes vásárlást, többféle áfakulcsot, céges számlázási adatokat, részleges visszatérítést és sikertelen fizetést is. A számlázásnál a ritkább esetek okozzák a legtöbb későbbi adminisztrációt.
Szállítás és futárkapcsolat: a választék legyen valós
A szállítási integráció értéke nem csak a címkeautomatizálásban van. A vásárló számára akkor jó a folyamat, ha valóban azokat az átvételi lehetőségeket látja, amelyek az adott kosárhoz, címhez és fizetési módhoz elérhetők. Egy túlméretes terméknél, ingyenes szállítási értékhatárnál vagy kizárt településnél a szabályoknak már a kosárban megfelelően kell működniük.
A futárszolgálati kapcsolatnak jellemzően rendelési adatokat kell átadnia, címkét vagy fuvarlevelet kell létrehoznia, és lehetőség szerint követési információt kell visszaadnia. A gyakorlatban fontos kérdés, hogy a csomagadat a rendelés leadásakor, adminisztrátori jóváhagyáskor vagy csak a tényleges feladás előtt kerüljön-e át.
Ha a webshop több raktárból dolgozik, külön szállítási díjakat használ, vagy csomagpontra és házhoz szállításra is eltérő feltételeket ad, a szabályrendszert nem célszerű kizárólag egy alapmodulra bízni. Ilyenkor előbb a szállítási üzleti logikát kell pontosítani, utána lehet eldönteni, hogy standard beállítás, kiegészítő modul vagy egyedi fejlesztés szükséges-e.
Készlet, ERP és termékadatok: legyen egy adatgazda
A készletintegráció leggyakoribb hibája, hogy nem egyértelmű, hol kezelik a valós készletet. Ha a termékmennyiséget a webshop adminisztrációjában és egy külső készletkezelőben is kézzel módosítják, előbb-utóbb eltérés lesz. Ennek következménye lehet túladás, késedelmes kiszállítás vagy felesleges lemondás.
Érdemes kijelölni az adatgazdát. Ha az ERP a központi rendszer, a webshop onnan kapja a készletet, árat és termékadatokat. Ha a webshop a központ, akkor a külső rendszer csak meghatározott adatokat vesz át. A kétirányú szinkron nem automatikusan jobb: összetettebb, több hibalehetőséget teremt, és világos ütközéskezelést igényel.
A termékazonosítókra külön figyeljen. A cikkszám, SKU, variánsazonosító és vonalkód rendszerint nem felcserélhető. Egy szín- vagy méretvariáns hibás párosítása úgy is okozhat készletproblémát, hogy a terméknév első ránézésre helyesnek tűnik. Költözés vagy új integráció előtt ezért célszerű a duplikált cikkszámokat, hiányzó azonosítókat és eltérő kategóriastruktúrát is felmérni.
Tesztelés nélkül nincs éles indulás
Az integrációt nem egyetlen sikeres próbarendelés igazolja. Külön tesztelni kell a normál vásárlást, a sikertelen bankkártyás fizetést, az utánvétet, a kuponos rendelést, a raktárhiányos terméket és a rendelésmódosítást. Ha van lehetőség tesztkörnyezetre, az éles adatok és valódi ügyfélértesítések kockáztatása nélkül lehet feltárni a hibákat.
A teszteléshez készítsen ellenőrző listát arról, hogy a rendelés melyik státuszba került, létrejött-e a számla, átmentek-e a helyes szállítási adatok, csökkent-e a készlet, és megkapta-e a vásárló a megfelelő értesítést. Nem elég azt nézni, hogy az adat átment-e. Azt is ellenőrizni kell, hogy az adminisztráció számára érthető, kezelhető állapotban jelent-e meg.
Érdemes naplózást és rendszeres ellenőrzést is bevezetni. Egy külső szolgáltatás API-kulcsa lejárhat, egy modulfrissítés megváltoztathatja a működést, vagy egy szolgáltatói oldal átállása érintheti az adatkapcsolatot. A karbantartás nem különálló kényelmi szolgáltatás, hanem az automatizált folyamatok üzemben tartásának része.
Mikor kell egyedi fejlesztés?
Egyedi fejlesztés akkor indokolt, ha a működési igény valódi üzleti előnyt vagy elengedhetetlen belső folyamatot szolgál. Ilyen lehet a speciális árképzés, egyedi termékkonfigurátor, több rendszer közötti adatátalakítás, partnerenként eltérő termékkatalógus vagy összetett rendelésjóváhagyás.
Nem célszerű viszont egyedi fejlesztést választani csak azért, mert egy meglévő folyamat megszokott. Előfordulhat, hogy az adminisztratív lépés egyszerűsítése, a termékadatok rendezése vagy egy standard modul megfelelő konfigurációja olcsóbban és kisebb kockázattal oldja meg a problémát. UNAS-nál a platform lehetőségei és korlátai határozzák meg a mozgásteret, OpenCartnál pedig az egyedi megoldás kódminőségét, kompatibilitását és dokumentáltságát kell mérlegelni.
A jó integráció nem látványos a vásárló számára. Pont ez a cél: a rendelés természetesen halad végig a folyamaton, az adminisztráció nem kétszer dolgozik, és egy hiba esetén gyorsan látszik, hol kell beavatkozni. Ha ezt a szemléletet már a tervezéskor alkalmazza, a webshop későbbi bővítése is sokkal kevésbé válik kockázatos projektté.
