Egy rendelés nem attól lesz teljesített, hogy a vásárló megkapta a visszaigazoló e-mailt. A munka akkor kezdődik, amikor a webshopból érkező adatok alapján címkét kell nyomtatni, csomagot kell összeállítani, értesítést kell küldeni, majd kezelni kell a sikertelen kézbesítést vagy a visszaküldést. A webshop szállítási integráció beállítása ezért nem egyszerűen egy futárszolgálatos modul bekapcsolása: a rendelési folyamat, a díjszabás és a napi adminisztráció összehangolása.
Egy rosszul kialakított szállítási rendszer könnyen okoz veszteséget. Előfordulhat, hogy a webshop ingyenes szállítást ígér olyan termékre, amelyet a futár felárasan kezel, vagy a vásárló utánvéttel rendelne csomagpontra, miközben ez az adott szolgáltatónál nem elérhető. Az ilyen hibák nemcsak plusz adminisztrációt jelentenek, hanem bizalomvesztést és félbehagyott vásárlásokat is.
Mit kell eldönteni a szállítási modul előtt?
A technikai beállítás előtt érdemes a kereskedelmi szabályokat tisztázni. Mely országokba szállít a webshop? Van eltérő díj súly, rendelési érték, méret vagy termékkategória szerint? Kínálható-e utánvét minden szállítási módnál? Ki viseli a visszaküldés költségét, és milyen folyamat alapján kerül vissza a termék készletre?
A futárszolgálat kiválasztásánál nem kizárólag az egységár számít. Más igénye van egy kis méretű, magas értékű termékeket értékesítő áruháznak, mint egy nehéz csomagokat vagy túlméretes termékeket küldő kereskedőnek. A csomagpont-hálózat sűrűsége, az utánvét kezelése, az automaták elérhetősége, a nemzetközi kézbesítés és a reklamációs ügyintézés is befolyásolja a választást.
A szállítási opciók száma sem feltétlenül érték. Ha a pénztároldalon öt hasonló futáros lehetőség jelenik meg, a vásárló döntése lassul. Általában világosabb egy házhoz szállítási, egy csomagpontos vagy automatás, valamint szükség esetén egy személyes átvételi megoldás. Ettől természetesen el lehet térni, ha a célpiac vagy a terméktípus ezt indokolja.
A webshop szállítási integráció beállítása lépésről lépésre
A jó konfigurációban a webshop és a futárszolgálat között nem csupán adatkapcsolat van. A rendelés állapota, a szállítási díj, a választott átvételi pont és a csomagazonosító is következetesen jelenik meg a megfelelő helyen.
1. Szerződéses és technikai hozzáférések ellenőrzése
A legtöbb szolgáltatói integrációhoz szerződés, ügyfélazonosító és technikai hozzáférés szükséges. Ez lehet API-kulcs, felhasználónév-jelszó páros vagy egyedi partnerazonosító. A beállítást sokszor már itt megakasztja, hogy a webshopban megadott feladói adatok nem azonosak a futárszolgálat szerződésében szereplő adatokkal.
Érdemes előre tisztázni azt is, milyen szolgáltatások aktívak a szerződésben. A címkenyomtatás, utánvét, csomagpontos feladás, értéknyilvánítás vagy nemzetközi kézbesítés nem minden esetben kapcsolódik be automatikusan.
2. Szállítási zónák és díjszabási logika kialakítása
A webshopban látható díjaknak és a tényleges szállítási költségeknek összhangban kell lenniük. A legegyszerűbb megoldás az egységes szállítási díj, de ez csak hasonló méretű és súlyú termékeknél működik jól. Széles termékkínálatnál a súlyalapú, értékhatárhoz kötött vagy kategóriaalapú szabályok pontosabbak lehetnek.
Külön figyelmet igényel az ingyenes szállítási küszöb. Ha túl alacsony, a webshop átvállalja a költség jelentős részét. Ha túl magas, nem ösztönöz többletvásárlásra. A helyes értékhez érdemes a kosárértéket, az átlagos csomagköltséget és az árrést együtt vizsgálni.
Nemzetközi értékesítésnél országonkénti zónákat, díjakat és szállítási időket kell kezelni. Ilyenkor nem elegendő a pénznem átváltása: a címformátum, a telefonszám mező, az utánvét lehetősége és a szolgáltatói termék is eltérhet.
3. Fizetési és szállítási módok összekapcsolása
A pénztárfolyamatban csak olyan kombinációkat szabad felajánlani, amelyek valóban teljesíthetők. Tipikus szabály például, hogy az utánvét elérhető házhoz szállításnál, de nem választható minden automatánál, vagy hogy a személyes átvételhez nincs szállítási díj és futárszolgálati címke.
Ezek a feltételek UNAS rendszerben jellemzően a rendelkezésre álló szállítási és fizetési beállításokhoz, illetve egyes esetekben külső alkalmazásokhoz igazodnak. OpenCart esetében gyakran nagyobb a szabadság, ugyanakkor a modulok közötti kompatibilitást és az egyedi feltételek fejlesztési igényét is ellenőrizni kell. A nagyobb rugalmasság csak akkor előny, ha a rendszer később is átláthatóan karbantartható marad.
4. Csomagpont- és automatatérkép kezelése
A csomagpontos szállításnál a vásárlónak nem elég kiválasztania a szolgáltatót: konkrét átvételi helyet is választania kell. A kiválasztott pont azonosítójának át kell kerülnie a rendelésbe, majd a címkegeneráláskor a futárszolgálat felé is.
Gyakori hiba, hogy a térkép látszólag működik, de mobilon nem tölthető be megfelelően, vagy a választás után nem mentődik a pont adata. Ez különösen érzékeny terület, mert a mobilról vásárlók aránya magas, és egy hibás pontválasztás közvetlenül a fizetés előtt szakíthatja meg a rendelést.
5. Címkék, státuszok és ügyfélértesítések automatizálása
A működő integráció egyik legnagyobb előnye, hogy a rendelési adatokból címke generálható, és nem kell a nevet, címet, telefonszámot újra kézzel rögzíteni a futárszolgálat felületén. Ez gyorsítja a csomagfeladást, és csökkenti az elgépelések esélyét.
A folyamat akkor teljes, ha a csomagszám visszakerül a webshopba, a rendelés státusza frissül, és a vásárló egyértelmű értesítést kap. Fontos azonban, hogy ne minden technikai státuszról küldjön a rendszer e-mailt. Az ügyfél számára a fizetésre vár, feldolgozás alatt, feladva és teljesítve állapotok általában elegendők. A belső munkafolyamat részletesebb jelölései maradhatnak az adminisztrációban.
Mire kell figyelni UNAS és OpenCart rendszerben?
UNAS webshopnál a gyors bevezethetőség és az egységes adminisztráció előny, de a rendelkezésre álló integrációk és szabályok keretet szabnak az egyedi működésnek. Ha egy üzleti igény túlmutat a rendszer alapbeállításain, előbb azt kell megvizsgálni, hogy külső alkalmazás, meglévő kiegészítő vagy munkafolyamat-módosítás ad-e fenntartható megoldást.
OpenCart esetén sok futárszolgálati modul és egyedi fejlesztési lehetőség érhető el. A kockázat az, hogy egy régebbi sablon, eltérő OpenCart-verzió vagy más bővítmény felülírja a pénztárfolyamatot. Ilyenkor nem célszerű éles környezetben kísérletezni. A modul telepítése, a naplófájlok ellenőrzése és a tesztrendelések különösen fontosak, főleg akkor, ha a webshop már aktívan termel rendeléseket.
Költözés során a szállítási beállításokat sem szabad utólagos részletként kezelni. Az új rendszerbe átkerülhetnek a termékek, képek, keresőbarát URL-ek, metaadatok és átirányítások, de a régi szállítási logika nem mindig vihető át változtatás nélkül. A díjszabásokat, fizetési kapcsolatokat és értesítéseket újra kell ellenőrizni, mielőtt a webshop élesedik.
Tesztelés nélkül nincs kész integráció
A szállítási funkció nem attól működik, hogy az adminfelületen megjelent egy modul. Minden olyan helyzetet végig kell próbálni, amellyel a vásárló találkozhat. Minimum ezekre a tesztekre van szükség:
- házhoz szállítás előre fizetéssel és utánvéttel;
- csomagpont vagy automata kiválasztása asztali gépen és mobilon;
- ingyenes szállítási értékhatár alatti és feletti kosár;
- eltérő súlyú, kedvezményes vagy speciális termékeket tartalmazó rendelés;
- címke létrehozása, csomagszám mentése és vásárlói értesítés.
A teszt során nemcsak azt kell nézni, hogy létrejön-e a címke. Ellenőrizni kell a pénztároldalon megjelenő díjat, a rendelésben tárolt átvételi pontot, a csomagra kerülő adatokat és az ügyfélnek küldött e-mail szövegét is. Egy elírt szállítási díj vagy félreérthető értesítés ugyanúgy üzleti probléma, mint egy technikai hiba.
A szállítási integrációt később is felül kell vizsgálni. Futárszolgálati díjak, API-kapcsolatok, automatás szolgáltatások és webshopmodulok változhatnak. Ha új piac, új termékkategória vagy új fizetési mód kerül bevezetésre, a meglévő szabályok könnyen hiányossá válhatnak.
A jól beállított szállítás háttérben marad: a vásárló gyorsan megtalálja a számára megfelelő opciót, a csapat pedig kevesebb kézi adatbevitellel adja fel a csomagokat. Ha viszont napi szinten kivételeket kell kezelni, a rendszer nem a vállalkozás működését támogatja, hanem a vállalkozás alkalmazkodik a rendszer hibáihoz.
