Egy működő webshopnál nem mindig a termék, az ár vagy a hirdetés teljesít gyengén. Gyakran a pénztár az a pont, ahol a vásárló bizonytalanná válik, túl sok adatot kérünk tőle, vagy egyszerűen nem érti, mi lesz a következő lépés. Ez az OpenCart checkout átalakítás esettanulmány azt mutatja be, hogyan lehet egy meglévő rendelési folyamatot üzleti szempontból átvizsgálni és célzottan javítani – anélkül, hogy feleslegesen kellene új webáruházat építeni.
A példában szereplő webshop magyar piacra értékesített, több száz aktív termékkel. A látogatottság és a kosárba helyezések száma elfogadható volt, mégis feltűnően sok rendelés szakadt meg a fizetés előtti lépéseknél. A feladat nem egy látványos sabloncsere volt, hanem a vásárlási útvonal akadályainak feltárása.
A kiinduló probléma nem a kosárnál kezdődött
Az áruházban a látogató a termékoldalról gond nélkül jutott a kosárig. A gond a checkout oldalon jelentkezett: a rendelés leadásához kötelező regisztráció, több egymás utáni blokk, ismétlődő címmezők és nehezen értelmezhető szállítási opciók várták.
Mobilon ez különösen problémás volt. A vásárlónak sokat kellett görgetnie, az űrlapmezők kitöltése közben nem látta a rendelési összesítőt, és csak későn derült ki számára, mennyibe kerül pontosan a kiválasztott szállítási mód. A bankkártyás fizetés elérhető volt, de a fizetési mód megnevezése nem adott elegendő bizalmi támpontot.
A probléma tehát nem az volt, hogy az OpenCart rendszer alkalmatlan lett volna a feladatra. A korábbi fejlesztések, a telepített modulok és az alapértelmezett checkout-logika együtt olyan folyamatot eredményeztek, amely adminisztratív szempontból működött, vásárlói szempontból viszont felesleges súrlódást okozott.
Mit vizsgáltunk az átalakítás előtt?
A checkout módosítását nem célszerű kizárólag dizájnkérdésként kezelni. Először azt kell látni, hogy a vásárló hol akad el, és az adott lépésnek valóban van-e üzleti vagy jogi indoka.
Az elemzés során átnéztük a rendelési folyamatot asztali és mobilnézetben, a rendelési statisztikákat, a fizetési és szállítási modulok működését, valamint az adminisztrációban szükséges adatokat. Külön ellenőriztük, hogy a számlázáshoz, a futárszolgálathoz és az automatikus rendelés-visszaigazolásokhoz pontosan milyen mezők szükségesek.
Ez azért lényeges, mert egy mező elhagyása csak akkor jó döntés, ha később sem okoz hibát a rendelésfeldolgozásban. A kevesebb adatbekérés célja nem az, hogy hiányos rendeléseket kapjon az ügyfélszolgálat, hanem az, hogy a vásárló csak akkor és csak azt az információt adja meg, amelyre az adott rendelési módnál valóban szükség van.
OpenCart checkout átalakítás: a döntések logikája
Az első fontos változtatás a kötelező regisztráció megszüntetése volt. A vendégként történő vásárlás alapelvárás sok hazai webshopnál, különösen akkor, ha a vásárlás alkalmi vagy sürgős. Fiókot továbbra is lehetett létrehozni, de ezt már nem a fizetés feltételeként kezeltük.
A második lépés az űrlap egyszerűsítése volt. A szállítási és számlázási cím alaphelyzetben megegyezett, ezért nem kértük be ugyanazokat az adatokat kétszer. Eltérő számlázási cím megadására továbbra is volt lehetőség, de csak akkor nyílt meg a szükséges mezőcsoport, ha a vásárló ezt külön jelezte.
A harmadik terület a szállítási módok kezelése volt. Korábban minden opció hasonló megjelenést kapott, függetlenül attól, hogy házhoz szállításról, csomagpontról vagy személyes átvételről volt szó. Az átalakított folyamatban a választás után azonnal látszott a díj, az átvétel jellege és az adott módhoz szükséges további információ.
Ez nem csak kényelmi fejlesztés. Ha például csomagpontos átvételnél a vásárló nem választ ki konkrét átvevőhelyet, a rendelés teljesítése később manuális egyeztetést igényel. A checkoutnak ezért úgy kell egyszerűnek lennie, hogy közben a rendelési adatok feldolgozhatók maradjanak.
A fizetésnél a bizonytalanságot kellett csökkenteni
A bankkártyás fizetés technikailag megfelelően működött, de a felület nem jelezte kellően világosan, hogy a vásárló biztonságos fizetési szolgáltató oldalára kerül át. Emellett az utánvétes és az előre utalásos opciók leírása sem volt elég egyértelmű.
A fizetési módok elnevezését és rövid tájékoztatóit ezért egységesítettük. A cél nem marketinges szövegírás volt, hanem a félreértések megelőzése: a vásárló már a megrendelés leadása előtt értse, mikor, kinek és milyen módon fizet.
A rendelés véglegesítése előtt egy jól látható összesítő blokk is helyet kapott. Ebben a termékek, a mennyiségek, a szállítási költség, a választott fizetés és a végösszeg egy helyen szerepelt. Mobilon ez különösen hasznos, mert a vásárlónak nem kell visszalépnie egy korábbi oldalrészhez az ellenőrzéshez.
Technikai megvalósítás: nem mindenhez kell egyedi modult írni
Egy OpenCart checkout átalakításnál gyakori hiba, hogy egy új modul telepítésétől várják a teljes megoldást. Egy kész bővítmény gyorsabb kiindulópont lehet, de csak akkor, ha kompatibilis az OpenCart verziójával, a sablonnal, a fizetési modulokkal és a meglévő egyedi módosításokkal.
Ebben az esetben nem egyetlen nagy checkout-modul bevezetése történt. A meglévő logikát térképeztük fel, és célzott sablon-, nyelvi-, valamint vezérlőszintű módosításokkal alakítottuk át a folyamatot. Így kisebb maradt a kompatibilitási kockázat, és nem került be olyan funkciócsomag a rendszerbe, amelynek nagy részére az áruháznak nem volt szüksége.
A fejlesztés tesztkörnyezetben zajlott. Ellenőrizni kellett többek között a kuponok, a szállítási díjhatárok, az eltérő áfakulcsok, a készletkezelés és a rendelési státuszok működését is. Egy checkout módosítás akkor tekinthető késznek, ha nemcsak a felület néz ki jobban, hanem a rendelés az adminisztrációban, a fizetési szolgáltatónál és a logisztikai folyamatban is hibamentesen halad tovább.
Az eredmény: kevesebb lépés, jobb minőségű rendelések
Az élesítés utáni időszakban a kosárból a rendelésig eljutó vásárlók aránya javult, miközben az ügyfélszolgálathoz érkező, fizetéssel és szállítással kapcsolatos kérdések száma csökkent. Ez utóbbi legalább olyan értékes eredmény, mint a konverziós arány változása: ha kevesebb a manuális egyeztetés, gyorsabbá és kiszámíthatóbbá válik a rendelésfeldolgozás.
Fontos azonban, hogy egy ilyen fejlesztés eredményét ne kizárólag egyetlen százalékos mutató alapján értékeljük. A szezonális kereslet, a kampányok, a termékkínálat vagy akár a szállítási díjak változása is befolyásolhatja a számokat. Érdemes a rendelési arány mellett figyelni a mobilos teljesítményt, a fizetési módok megoszlását, a sikertelen tranzakciókat és az ügyfélszolgálati visszajelzéseket is.
Mikor indokolt a checkout teljes újragondolása?
Nem minden webshopnál kell teljesen új rendelési folyamatot kialakítani. Ha a kosárelhagyás elsősorban magas szállítási díjból, hosszú szállítási határidőből vagy versenyképtelen árból ered, a checkout felületének átrajzolása önmagában nem fogja megoldani a problémát.
Akkor érdemes mélyebben foglalkozni vele, ha a mobilos rendelési arány feltűnően gyenge, a vásárlók rendszeresen ugyanazokat a kérdéseket teszik fel, sok a hibásan leadott rendelés, vagy egy új fizetési, számlázási és szállítási folyamatot kell bevezetni. Ugyanez igaz akkor is, amikor egy régi OpenCart-verzió, elavult sablon vagy össze nem illő modulok miatt a rendszer nehezen módosítható.
A checkout nem különálló képernyő, hanem a webshop működésének sűrített változata. Itt találkozik a termékinformáció, az árképzés, a logisztika, a fizetés és az ügyfélszolgálat. Ha ezen a ponton tiszta a folyamat, a vásárló könnyebben dönt, a csapat pedig kevesebb kivételt és hibát kezel.
Egy jól előkészített átalakítás ezért nem attól jó, hogy több animációt vagy látványosabb gombokat kap a pénztár. Attól jó, hogy a vásárló számára magától értetődővé teszi a rendelést, miközben a webshop mögötti működés hosszú távon is kezelhető marad.
