Ha a terméket nem a saját polcodról, hanem a beszállítótól rendeled meg, akkor a termékoldalon ne azt írd ki, hogy „raktáron”, hanem azt, hogy beszállítói készleten van, mellé pedig egy munkanapban megadott szállítási sávot, például „várható kézbesítés 4-7 munkanap”. Ez a cikk végigveszi, miért félreérthető a „raktáron” szó, miért kockázatos a napra pontos ígéret, hogyan számolj felelős sávot, és mit tegyél, ha a készletadat rendszeresen elcsúszik a valóságtól.
A cikkben háromféle állítás szerepel, ezeket külön jelöljük. Hivatalosan igazolt az, ami egy szabványban, platform-dokumentációban vagy jogszabályban le van írva. Saját tapasztalat az, amit webshopok üzemeltetése közben rendszeresen látunk. Szakmai feltételezés az, ami logikus következtetés, de nincs mögötte mérés vagy hivatalos forrás.
Miért félreérthető a „raktáron” felirat beszállítói rendelésnél?
A vásárló a „raktáron” szót úgy olvassa, hogy a termék fizikailag nálad van, és a rendelés után azonnal csomagolható. Ha valójában a beszállító raktárában van, akkor a te oldaladon még egy rendelési, átvételi és bevételezési kör is hátravan, ami napokat vehet igénybe.
A gond abból adódik, hogy a webshopmotorok többsége egyetlen „készleten” mezőt ismer. A beszállítói feedből érkező darabszám ugyanabba a mezőbe kerül, mint a saját raktári készlet, és a sablon mindkettőre ugyanazt a zöld „raktáron” címkét teszi ki. A rendszer szemszögéből ez igaz, a vásárló szemszögéből viszont nem.
Saját tapasztalat. A „hol a csomagom” típusú megkeresések jelentős része olyan termékekre jön, amelyek „raktáron” felirattal mentek el, de beszállítói rendeléssel teljesültek. A vásárló nem a lassúságot kifogásolja, hanem azt, hogy mást vártak, mint amit kapott.
Hivatalosan igazolt. A Schema.org az InStock és a BackOrder értéket külön elérhetőségi állapotként kezeli, a Google Merchant Center pedig szintén megkülönbözteti az in_stock, backorder és preorder értéket. A szabványok tehát maguk is szétválasztják azt, ami a webshopok sablonjaiban gyakran összemosódik.
Mit írj ki a készletjelzés helyére, ha a termék a beszállítónál van?
Írd ki pontosan, hol van a termék, és mennyi idő alatt ér a vásárlóhoz. A jó felirat két részből áll, egy állapotból és egy időből, és egyik sem állít többet annál, amit tudsz.
A négy állapot, amit érdemes szétválasztani
- Saját raktáron. A termék nálad van, a csomagolás a te kezedben van. Itt adhatsz rövid sávot, például „1-2 munkanap”.
- Beszállítói készleten. A beszállító jelzi, hogy van belőle, de neked még meg kell rendelned. Felirat például „Beszállítói készleten, várható kézbesítés 4-7 munkanap”.
- Rendelésre, ismert utánpótlással. Jelenleg sehol nincs, de a beszállító megadott egy beérkezési időt. Itt a sáv hosszabb, és jelezd, hogy ez a beszállító becslésén alapul.
- Jelenleg nem rendelhető. Nincs készlet és nincs megbízható utánpótlási adat. Ilyenkor a kosárba tétel helyett értesítőkérést érdemes felajánlani.
A szöveg legyen rövid és egyértelmű. A „hamarosan”, „gyorsan” és „pár nap” típusú szavak semmit nem mondanak, a vásárló a legrövidebb értelmezést fogja elfogadni. A számmal megadott sáv viszont visszakérhető és ellenőrizhető.
Miért kockázatos a napra pontos szállítási ígéret?
A napra pontos ígéret, például „csütörtökön nálad”, csak akkor tartható, ha a teljes lánc a te ellenőrzésed alatt áll. Beszállítói rendelésnél legalább három szereplőn múlik az időpont (beszállító, futár, te), és bármelyik egynapos csúszása megdönti az ígéretet.
Hivatalosan igazolt. A Polgári Törvénykönyv fogyasztói adásvételre vonatkozó szabálya szerint, ha a felek másként nem állapodnak meg, a vállalkozásnak késedelem nélkül, de legfeljebb a szerződéskötéstől számított 30 napon belül kell teljesítenie. Ha viszont te magad írsz ki konkrét napot, akkor jó eséllyel az lesz a megállapodás része, és a vásárló ahhoz méri a teljesítést. A tisztességtelen kereskedelmi gyakorlatot tiltó törvény pedig a termék elérhetőségére és a szállítás idejére vonatkozó megtévesztő tájékoztatást is tiltja.
Szakmai feltételezés. A pontos dátum rövid távon emelheti a konverziót, mert konkrétabbnak hat. Ez az előny azonban csak addig él, amíg az ígéret teljesül. Az első csúszás után a vásárló a következő pontos dátumot is kétkedve olvassa.
Hogyan adj sávos becslést felelősen?
A felelős sáv alsó határa a reálisan elérhető leggyorsabb kézbesítés, a felső határa pedig az, amit a rendelések túlnyomó többségénél tartani tudsz. A felső határt mindig mért adatból számold, ne a beszállító ígéretéből.
- Gyűjts adatot. Exportáld az elmúlt három hónap beszállítói rendeléssel teljesített tételeit, a rendelés idejével és a tényleges kézbesítés idejével együtt.
- Számolj munkanapban. Hétvégét és munkaszüneti napot ne számolj bele, és a feliratban is írd ki, hogy munkanapról van szó.
- Bontsd szét beszállítónként. Két beszállító átlagát összevonni félrevezető. Ha az egyik két, a másik hat munkanap alatt szállít, a négynapos átlag egyikre sem igaz.
- Válaszd ki a sáv felső határát. Nézd meg, hány munkanapon belül teljesült a rendelések nagy része, például kilenc a tízből. Ez legyen a felső határ, ne az átlag.
- Számold bele a saját átfutásodat. A beszállítótól beérkező árut be kell vételezni, csomagolni és feladni. Ha ez nálad egy munkanap, add hozzá.
- Kezeld a rendelési határidőt. Ha a beszállító felé csak délelőtt adsz le rendelést, akkor a délután beérkező vásárlói rendelés egy nappal később indul. Ezt vagy a sávba építsd be, vagy írd ki külön.
- Nézd át negyedévente. A beszállítói teljesítés változik, a sávnak követnie kell.
Egy jól megfogalmazott felirat például így néz ki. „Beszállítói készleten. Várható kézbesítés 4-7 munkanap. A rendelésed leadása után e-mailben jelezzük, amikor a termék beérkezett hozzánk.” Ez a szöveg nem ígér napot, de ad egy ellenőrizhető keretet, és előre jelzi a következő lépést.
Saját tapasztalat. A közbenső értesítés (a termék beérkezett, csomagoljuk) sok megkeresést megelőz, mert a vásárló látja, hogy a rendelés halad, akkor is, ha a sáv vége közelebb van, mint az eleje.
Hogyan jelenjen meg ez a strukturált adatban és a termékfeedben?
A termékoldal szövegének, a strukturált adatnak és a Merchant Center feednek ugyanazt az állapotot kell mutatnia. Ha a szöveg beszállítói készletet ír, a strukturált adat pedig InStock értéket, az ellentmondás.
Hivatalosan igazolt. A Google Merchant Center irányelvei szerint a feedben megadott elérhetőségnek egyeznie kell a céloldalon látható elérhetőséggel, az eltérés a termék elutasításához vezethet. A backorder és preorder értékhez a Google az availability_date mező megadását is kéri. A Schema.org OfferShippingDetails típusa pedig külön mezőt ad a kezelési időnek (handlingTime) és a szállítási időnek (transitTime), mindkettőt minimum-maximum értékkel.
Egy beszállítói készletes termék ajánlatának egyszerűsített JSON-LD részlete így nézhet ki.
{ "@type": "Offer", "availability": "https://schema.org/BackOrder", "shippingDetails": { "@type": "OfferShippingDetails", "deliveryTime": { "@type": "ShippingDeliveryTime", "handlingTime": { "@type": "QuantitativeValue", "minValue": 3, "maxValue": 5, "unitCode": "DAY" }, "transitTime": { "@type": "QuantitativeValue", "minValue": 1, "maxValue": 2, "unitCode": "DAY" } } } }
Itt a kezelési idő tartalmazza a beszállítói rendelést és a saját bevételezést, a szállítási idő pedig a futár átfutását. A kettő összege adja a termékoldalon kiírt 4-7 munkanapos sávot. A BackOrder használata vitatható ott, ahol a beszállítónál fizikailag van áru. Ilyenkor egyes kereskedők InStock értéket adnak hosszabb kezelési idővel. Szakmai feltételezés, hogy a hosszabb handlingTime és az InStock együtt elfogadható, ha a látható szöveg is egyértelműen jelzi a beszállítói készletet. A lényeg az összhang, a három helyen ne mondj háromfélét.
Hogyan vesd össze a készletadatot a valós kiszolgálással?
Havonta egyszer nézd meg, hogy amit kiírtál, az megtörtént-e. Az összevetéshez nem kell külön rendszer, egy rendelésexport és egy táblázat elég.
- Hány rendelés ment ki „raktáron” felirattal, és ebből hányat kellett végül beszállítótól rendelni?
- A beszállítói rendeléseknél hány esetben lépte túl a kézbesítés a kiírt sáv felső határát?
- Hány rendelést kellett lemondani azért, mert a beszállító közben elfogyott?
- Mennyi idő telik el a beszállítói készletváltozás és a webshopban megjelenő új érték között?
- Egyezik-e a termékoldal szövege, a JSON-LD
availabilityértéke és a feed elérhetőségi mezője? - Van-e olyan termék, amely hetek óta változatlan darabszámot mutat? Az ilyen gyakran befagyott szinkront jelez, nem stabil készletet.
- Hány ügyfélszolgálati megkeresés érkezett szállítási idő miatt, és ezek mely beszállítók termékeire vonatkoztak?
Saját tapasztalat. Az utolsó előtti pont a leggyakrabban kimaradó, pedig a befagyott darabszám az egyik legbiztosabb jele annak, hogy a feed nem frissül, és a webshop egy régi állapotot árul.
Mit tegyél, ha a készletszinkron rendszeresen késik?
Ha a beszállítói készletadat rendszeresen órákkal vagy napokkal később ér be, akkor előbb a kiírt ígéretet igazítsd a késéshez, és csak utána javítsd a technikát. Fordított sorrendben a javítás ideje alatt is túlígérsz.
- Mérd meg a késést. Naplózd, mikor módosult a készlet a beszállítónál, és mikor jelent meg nálad. Ha a beszállító nem ad időbélyeget, legalább a saját importod futási idejét rögzítsd.
- Lazítsd a feliratot. Az érintett beszállító termékeinél a „beszállítói készleten” helyett írj olyat, hogy „rendelésre, elérhetőségét a rendelés után visszaigazoljuk”, és a sáv felső határát emeld meg.
- Vezess be biztonsági küszöböt. Ha a beszállító két darabot jelez, kezeld nullának, ha a szinkron régebbi egy beállított időnél. Így a kevés darabszámú, gyorsan elfogyó tételeken nem adsz el olyat, ami már nincs.
- Növeld a szinkron gyakoriságát. Ha a beszállító ad API-t, kérdezd le gyakrabban a gyorsan fogyó termékeket, a ritkán változókat ritkábban.
- Építs be elavulási jelzést. Ha egy termék készletadata adott időn túl nem frissült, az állapot automatikusan váltson „rendelésre” értékre, és erről kapj értesítést.
- Beszélj a beszállítóval. Kérj tőle frissítési gyakoriságot és időbélyeget a feedbe. Ha nem tudja vállalni, ez a beszállítóválasztásnál is szempont.
- Ellenőrizd újra a feedet. A javítás után nézd meg a Merchant Center diagnosztikáját, hogy eltűntek-e az elérhetőségi eltérések.
Miért drágább a túlígért határidő, mint az elveszett rendelés?
Az elveszett rendelés egy elmaradt bevétel. A túlígért határidő ezzel szemben ügyfélszolgálati munkát, lemondást, visszatérítést, rossz értékelést és elveszett visszatérő vásárlót jelent, és ezek egy része akkor is megmarad, ha a csomag végül megérkezik.
Ez a cikk saját nézőpontja, és nem mért összefüggés. A logika az, hogy aki a hosszabb, de őszinte sáv miatt nem rendel, az legfeljebb máshol vásárol. Aki viszont a rövid ígéret miatt rendel, és csalódik, az jó eséllyel értékelésben is elmondja, és azt a következő tíz látogató is olvassa. Az értékelés hosszabb ideig él, mint egy rendelés.
Szakmai feltételezés. A túlígérés költsége nem lineáris. Az első néhány csúszás még elnyelhető, de ha egy termékcsoportnál rendszeressé válik, az ügyfélszolgálati terhelés és a negatív értékelések aránya gyorsabban nő, mint a rendelésszám.
Hogyan hat ez az AI-alapú keresésre és a válaszmotorokra?
Az AI-asszisztensek és a vásárlást támogató ügynökök egyre gyakrabban olvassák ki a termékoldalakról az elérhetőséget és a szállítási időt. Ha a látható szöveg, a strukturált adat és a feed ellentmond egymásnak, a gép vagy a kedvezőbb értéket veszi át, vagy bizonytalannak ítéli az oldalt.
Szakmai feltételezés. Az egyértelmű, géppel is olvasható állapot (például BackOrder és megadott kezelési idő) segítheti, hogy egy válaszmotor pontosan idézze a szállítási feltételeidet. Ez nem jelent jobb helyezést, de csökkenti annak esélyét, hogy egy AI-válasz a te nevedben ígérjen olyat, amit nem tudsz tartani.
Források és további olvasnivalók
- Schema.org, Offer, ItemAvailability, OfferShippingDetails és ShippingDeliveryTime típusleírások
- Google Search Central, Termék és kereskedői listázás strukturált adat dokumentáció
- Google Merchant Center súgó, Elérhetőség (availability) és elérhetőségi dátum (availability_date) attribútum
- Google Merchant Center súgó, A céloldal és a termékadatok egyezésére vonatkozó irányelvek
- 2013. évi V. törvény a Polgári Törvénykönyvről, fogyasztói adásvételre vonatkozó rendelkezések
- 2008. évi XLVII. törvény a fogyasztókkal szembeni tisztességtelen kereskedelmi gyakorlat tilalmáról
- 45/2014. (II. 26.) Korm. rendelet a fogyasztó és a vállalkozás közötti szerződések részletes szabályairól
- A „raktáron” felirat a vásárlónak azt jelenti, hogy a termék nálad van és azonnal indul, ezért beszállítói készletnél félrevezető.
- A napra pontos szállítási ígéret egyetlen beszállítói csúszástól megdől, a munkanapban megadott sáv viszont a valós szórást is lefedi.
- A sáv felső határát a mért kiszolgálási időkből számold, ne a beszállító legjobb napjából.
- A termékoldalon, a strukturált adatban és a termékfeedben ugyanannak az elérhetőségi állapotnak kell szerepelnie.
- Ha a készletszinkron rendszeresen késik, előbb a kiírt ígéretet lazítsd, csak utána a technikát javítsd.
Gyakori kérdések
Kiírhatom, hogy „raktáron”, ha a beszállítónál van készlet?
Nem érdemes, mert a vásárló ezt úgy érti, hogy a termék nálad van és azonnal indul. Írd ki inkább, hogy beszállítói készleten van, mellé pedig egy munkanapban megadott szállítási sávot.
Miért jobb a sáv, mint a pontos szállítási nap?
Beszállítói rendelésnél több szereplőn múlik az időpont, és bármelyik csúszása megdönti a pontos dátumot. A mért adatokból számolt sáv a valós szórást is lefedi, így ritkábban kell magyarázkodnod.
Hogyan számoljam ki a sáv felső határát?
Nézd meg az elmúlt hónapok beszállítói rendeléseit beszállítónként, és válaszd azt a munkanapszámot, amelyen belül a rendelések nagy része, például kilenc a tízből, teljesült. Ehhez add hozzá a saját bevételezési és csomagolási idődet.
Milyen elérhetőségi értéket adjak a strukturált adatban beszállítói készletnél?
A Schema.org erre a BackOrder értéket kínálja, amelyet a shippingDetails mezőben megadott kezelési és szállítási idővel érdemes kiegészíteni. A legfontosabb, hogy a termékoldal szövege, a strukturált adat és a Merchant Center feed ugyanazt az állapotot mutassa.
Mit tegyek, ha a beszállítói feed csak naponta egyszer frissül?
Az érintett termékeknél lazítsd a feliratot és emeld meg a sáv felső határát, a kevés darabszámú tételeknél pedig vezess be biztonsági küszöböt. Ezzel párhuzamosan kérj a beszállítótól gyakoribb frissítést vagy időbélyeget a feedbe.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.