Shipping και Returns στο Agentic Commerce SEO: Πώς Οργανώνονται ως Αξιόπιστα Commerce Data για AI Agents

Η αξιολόγηση μιας προσφοράς δεν περιορίζεται στην τιμή του προϊόντος. Το κόστος αποστολής, η δυνατότητα παράδοσης στη διεύθυνση του πελάτη, ο αναμενόμενος χρόνος παράδοσης και οι όροι επιστροφής μπορούν να αλλάξουν ουσιαστικά την πραγματική αξία μιας αγοράς.

Για αυτό, στο Agentic Commerce SEO, οι πληροφορίες αποστολής και επιστροφών δεν πρέπει να αντιμετωπίζονται μόνο ως κείμενο εξυπηρέτησης πελατών ή ως μία υποχρεωτική σελίδα όρων. Πρέπει να οργανώνονται ως σαφή, ακριβή και συνεπή commerce data, τα οποία μπορούν να διαβαστούν τόσο από τον χρήστη όσο και από τα search engines, τα shopping systems, τα commerce platforms και, όπου υποστηρίζεται, τα AI agents.

Η σωστή οργάνωση των shipping και returns data δεν εγγυάται υψηλότερη κατάταξη, εμφάνιση σε AI αποτελέσματα ή επιλογή ενός προϊόντος από ένα AI agent. Δημιουργεί, όμως, την απαραίτητη βάση ώστε τα συστήματα να μπορούν να κατανοούν πληρέστερα το συνολικό κόστος, τη διαθεσιμότητα παράδοσης, τον χρόνο άφιξης και το ρίσκο επιστροφής μιας προσφοράς.

Γιατί το shipping και τα returns είναι commerce data και όχι μόνο πολιτικές εξυπηρέτησης

Από την τιμή προϊόντος στο πραγματικό κόστος αγοράς

Ένα προϊόν μπορεί να εμφανίζεται φθηνότερο από ένα άλλο, αλλά να καταλήγει ακριβότερο όταν προστεθούν τα μεταφορικά. Αντίστοιχα, μία προσφορά με δωρεάν αποστολή μπορεί να ισχύει μόνο πάνω από συγκεκριμένο όριο παραγγελίας ή να εξαιρεί ογκώδη προϊόντα και απομακρυσμένες περιοχές.

Το πραγματικό κόστος αγοράς μπορεί να περιλαμβάνει:

• την τιμή του προϊόντος,
• το κόστος αποστολής,
• τυχόν ελάχιστη αξία παραγγελίας,
• πιθανές πρόσθετες χρεώσεις για ειδική μεταφορά,
• το πιθανό κόστος επιστροφής,
• σε διεθνείς αγορές, δασμούς ή εισαγωγικούς φόρους που δεν έχουν προπληρωθεί.

Ένα shopping system που γνωρίζει μόνο την τιμή του προϊόντος δεν έχει πλήρη εικόνα της προσφοράς. Για να γίνει ουσιαστική σύγκριση, πρέπει να είναι γνωστό αν η τιμή είναι πραγματικά τελική, αν υπάρχουν προϋποθέσεις δωρεάν αποστολής και αν ο πελάτης μπορεί να επιβαρυνθεί με πρόσθετα κόστη μετά την αγορά.

Παράδοση στον σωστό προορισμό και στον σωστό χρόνο

Η δήλωση «διαθέσιμο για αποστολή» δεν είναι αρκετά συγκεκριμένη. Ένα commerce system πρέπει να μπορεί να καταλάβει:

• αν το προϊόν αποστέλλεται στη συγκεκριμένη χώρα ή περιοχή,
• ποια υπηρεσία αποστολής είναι διαθέσιμη,
• πόσο κοστίζει η αποστολή,
• πόσος χρόνος χρειάζεται για την προετοιμασία της παραγγελίας,
• πόσος χρόνος χρειάζεται για τη μεταφορά,
• αν ισχύει κάποια εξαίρεση για το συγκεκριμένο προϊόν.

Για παράδειγμα, ένα πλυντήριο μπορεί να είναι διαθέσιμο, αλλά να παραδίδεται μόνο στην ηπειρωτική Ελλάδα με ειδική μεταφορική. Ένα μικρό αξεσουάρ μπορεί να αποστέλλεται σε όλη την Ελλάδα με standard delivery. Αν και τα δύο προϊόντα κληρονομούν ακριβώς την ίδια πολιτική, τα shipping data δεν περιγράφουν σωστά την πραγματική λειτουργία του e-shop.

Η πολιτική επιστροφών ως στοιχείο του ρίσκου αγοράς

Η πολιτική επιστροφών επηρεάζει το ρίσκο που αναλαμβάνει ο αγοραστής. Δύο έμποροι μπορεί να διαθέτουν το ίδιο προϊόν στην ίδια τιμή, αλλά ο ένας να προσφέρει δωρεάν επιστροφή εντός 30 ημερών και ο άλλος να χρεώνει τα έξοδα επιστροφής ή να εφαρμόζει ειδικές εξαιρέσεις.

Για να είναι συγκρίσιμες οι προσφορές, πρέπει να αποσαφηνίζονται:

• το χρονικό περιθώριο επιστροφής,
• η κατάσταση στην οποία πρέπει να βρίσκεται το προϊόν,
• οι διαθέσιμες μέθοδοι επιστροφής,
• το κόστος επιστροφής και ποιος το αναλαμβάνει,
• αν προσφέρεται refund, exchange ή store credit,
• τυχόν restocking fee, όπου επιτρέπεται και εφαρμόζεται,
• οι κατηγορίες προϊόντων που εξαιρούνται.

Αυτά τα στοιχεία μπορούν να χρησιμοποιηθούν ως κριτήρια σύγκρισης από shopping systems ή AI agents. Δεν υπάρχει, όμως, δημόσια γνωστή ακριβής στάθμιση που να αποδεικνύει ότι ένα συγκεκριμένο return policy οδηγεί αυτομάτως σε καλύτερη κατάταξη ή επιλογή.

Ποια shipping και returns data πρέπει να μπορεί να καταλάβει ένα commerce system

Τα βασικά shipping data

Τα shipping data πρέπει να περιγράφουν όχι μόνο το κόστος, αλλά και το πού, πώς και πότε παραδίδεται ένα προϊόν. Ανάλογα με το e-shop και το κανάλι, μπορεί να χρειάζονται:

• η χώρα προορισμού,
• η περιφέρεια, το postcode ή το shipping zone,
• οι περιοχές στις οποίες δεν γίνεται αποστολή,
• το shipping service, όπως standard ή express,
• το shipping cost,
• το free shipping threshold,
• το handling time,
• το transit time,
• το order cut-off,
• οι εργάσιμες ημέρες προετοιμασίας και παράδοσης,
• η διαθεσιμότητα pickup,
• το pickup SLA, δηλαδή ο αναμενόμενος χρόνος ετοιμασίας για παραλαβή,
• τα product-level exceptions,
• οι ειδικοί κανόνες international shipping.

Δεν υποστηρίζουν όλα τα data layers τα ίδια fields. Το ζητούμενο δεν είναι να αντιγραφεί η ίδια τεχνική δομή παντού, αλλά να αποτυπώνεται ο ίδιος επιχειρηματικός κανόνας χωρίς αντιφάσεις.

Τα βασικά returns data

Μία γενική φράση όπως «δεχόμαστε επιστροφές» δεν αρκεί για να περιγράψει ένα return policy. Τα βασικά returns data μπορούν να περιλαμβάνουν:

• αν επιτρέπονται επιστροφές,
• τη χώρα στην οποία εφαρμόζεται η πολιτική,
• το return window,
• την αποδεκτή κατάσταση του προϊόντος,
• το return method,
• το return shipping fee,
• το ποιος αναλαμβάνει το κόστος επιστροφής,
• τυχόν σταθερό ή ποσοστιαίο restocking fee,
• αν το αποτέλεσμα είναι refund, exchange ή store credit,
• το URL της πλήρους πολιτικής,
• τα product-specific exceptions,
• τα seasonal exceptions.

Η λεπτομέρεια είναι σημαντική επειδή διαφορετικοί κανόνες μπορεί να ισχύουν ανά προϊόν, κατάσταση, μέθοδο επιστροφής ή αγορά. Για παράδειγμα, ένα προϊόν μπορεί να επιστρέφεται δωρεάν σε φυσικό κατάστημα, αλλά η επιστροφή με courier να επιβαρύνει τον πελάτη.

Γιατί το policy page είναι απαραίτητο αλλά όχι επαρκές

Η σελίδα αποστολών και επιστροφών παραμένει απαραίτητη. Εκεί ο χρήστης πρέπει να βρίσκει το πλήρες πλαίσιο, τις προϋποθέσεις, τις διαδικασίες και τις εξαιρέσεις με κατανοητή γλώσσα.

Το policy page, όμως, δεν αντικαθιστά:

• τα shipping και returns fields του product feed,
• τις ρυθμίσεις του Merchant Center,
• τα structured data του e-shop,
• τον δυναμικό υπολογισμό στο checkout,
• τα APIs ή τα commerce protocols που επιστρέφουν τρέχουσες επιλογές και totals.

Αν το policy page δηλώνει δωρεάν μεταφορικά άνω των 50 ευρώ, αλλά το feed δηλώνει 60 ευρώ και το checkout εφαρμόζει 55 ευρώ, το e-shop έχει τρεις διαφορετικές εκδοχές του ίδιου κανόνα. Αυτό δεν είναι απλώς πρόβλημα περιεχομένου. Είναι πρόβλημα commerce data quality.

Ο παρακάτω πίνακας δείχνει πώς μετατρέπονται οι βασικές πολιτικές σε συγκεκριμένες επιχειρηματικές και τεχνικές απαιτήσεις.

Πώς οργανώνονται σωστά τα shipping data

Shipping cost και διαφορετικές υπηρεσίες αποστολής

Το shipping cost μπορεί να υπολογίζεται με διαφορετικούς τρόπους. Ένα e-shop μπορεί να χρησιμοποιεί σταθερή χρέωση, διαφορετικό κόστος ανά περιοχή, τιμολόγηση βάσει βάρους ή διαστάσεων, καθώς και διαφορετικές υπηρεσίες, όπως standard και express delivery.

Το σημαντικό είναι ο κανόνας να είναι σαφής και αναπαραγώγιμος. Αν ένα product feed ή το Merchant Center χρειαστεί να δηλώσει το κόστος ενός προϊόντος για συγκεκριμένο προορισμό, πρέπει να μπορεί να αντλήσει την ίδια λογική που εφαρμόζεται στο site.

Συχνές ειδικές περιπτώσεις είναι:

• προϊόντα μεγάλου όγκου ή βάρους,
• εύθραυστα προϊόντα που χρειάζονται ειδική μεταφορά,
• ευπαθή προϊόντα με περιορισμένη περιοχή παράδοσης,
• παράδοση με ραντεβού,
• express service με διαφορετικό κόστος,
• δωρεάν αποστολή για επιλεγμένα προϊόντα.

Η Google επιτρέπει τη δήλωση shipping cost και speed σε επίπεδο προϊόντος, ώστε να μπορούν να γίνονται overrides των account-level ρυθμίσεων για ειδικές περιπτώσεις, όπως bulky ή fragile products. Η δυνατότητα αυτή πρέπει να χρησιμοποιείται στοχευμένα και όχι ως υποκατάστατο μιας σωστά οργανωμένης βασικής πολιτικής.

Free shipping thresholds με σαφείς προϋποθέσεις

Το μήνυμα «δωρεάν μεταφορικά άνω των 50 ευρώ» φαίνεται απλό, αλλά χρειάζεται περισσότερη ακρίβεια για να γίνει σωστό commerce rule.

Πρέπει να διευκρινίζονται:

• η χώρα στην οποία εφαρμόζεται το threshold,
• το νόμισμα,
• η ελάχιστη αξία παραγγελίας,
• η υπηρεσία αποστολής που καλύπτεται,
• οι κατηγορίες ή τα προϊόντα που εξαιρούνται,
• το κόστος που ισχύει κάτω από το threshold.

Υποθετικό παράδειγμα: ένα ελληνικό e-shop μπορεί να προσφέρει δωρεάν standard delivery στην Ελλάδα για παραγγελίες άνω των 50 ευρώ, αλλά να εξαιρεί έπιπλα και άλλες ογκώδεις κατηγορίες. Για την Κύπρο μπορεί να ισχύει διαφορετικό threshold και διαφορετική υπηρεσία. Οι κανόνες αυτοί δεν πρέπει να συμπτυχθούν σε μία γενική δήλωση που εφαρμόζεται λανθασμένα σε όλες τις αγορές.

Handling time και transit time δεν είναι το ίδιο

Το handling time είναι ο χρόνος από την καταχώριση της παραγγελίας μέχρι την παράδοσή της στον μεταφορέα. Το transit time είναι ο χρόνος από την παραλαβή της παραγγελίας από τον μεταφορέα μέχρι την παράδοσή της στον πελάτη.

Ένα προϊόν με handling time δύο εργάσιμων ημερών και transit time τριών εργάσιμων ημερών δεν έχει παράδοση σε τρεις ημέρες. Η συνολική εκτίμηση πρέπει να λαμβάνει υπόψη:

• το order cut-off,
• τις εργάσιμες ημέρες προετοιμασίας,
• τις εργάσιμες ημέρες του μεταφορέα,
• τυχόν αργίες ή seasonal αλλαγές,
• product-level διαφοροποιήσεις.

Η διάκριση είναι σημαντική και για το testing. Αν το e-shop εμφανίζει «παράδοση σε 2–4 ημέρες», το agency πρέπει να γνωρίζει αν αυτό είναι ενιαία εκτίμηση ή αν προκύπτει από συγκεκριμένο handling και transit range.

Delivery areas και γεωγραφικοί περιορισμοί

Ένα e-shop πρέπει να ορίζει τις περιοχές εξυπηρέτησης με όσο το δυνατόν μεγαλύτερη ακρίβεια. Ανάλογα με το μοντέλο λειτουργίας, οι κανόνες μπορεί να βασίζονται σε:

• χώρα,
• περιφέρεια ή διοικητική περιοχή,
• postcode,
• shipping zone,
• νησιωτική ή δυσπρόσιτη περιοχή,
• τύπο προϊόντος.

Οι περιοχές στις οποίες δεν γίνεται αποστολή πρέπει επίσης να δηλώνονται καθαρά. Η απουσία shipping cost για μία περιοχή δεν πρέπει να χρησιμοποιείται ως ασαφής τρόπος δήλωσης ότι η περιοχή δεν εξυπηρετείται. Η επιχείρηση και το agency πρέπει να γνωρίζουν αν πρόκειται για πραγματικό αποκλεισμό, για άγνωστο κόστος ή για τεχνικό κενό.

Click and collect, pickup και collection points

Το pickup δεν είναι απλώς ένα κείμενο «παραλαβή από το κατάστημα». Για να περιγραφεί σωστά χρειάζονται, όπου υποστηρίζονται:

• τα επιλέξιμα καταστήματα,
• η μέθοδος pickup,
• το pickup SLA,
• ο χρόνος προετοιμασίας,
• το πιθανό pickup cost,
• η διαθεσιμότητα ανά σημείο.

Η υποστήριξη αυτών των fields και η επιλεξιμότητα για local surfaces διαφέρουν ανά χώρα και πρόγραμμα. Για αυτό, ένα ελληνικό e-shop δεν πρέπει να θεωρεί ότι κάθε δυνατότητα pickup του Merchant Center είναι διαθέσιμη με τον ίδιο τρόπο σε όλες τις αγορές.

Product-level shipping exceptions

Μία βασική πολιτική μπορεί να καλύπτει το μεγαλύτερο μέρος του catalog, αλλά ορισμένα προϊόντα χρειάζονται ειδικό κανόνα. Το product-level override είναι χρήσιμο όταν υπάρχει πραγματική απόκλιση, όπως:

• ένα έπιπλο με ειδικό κόστος μεταφοράς,
• ένα προϊόν κατά παραγγελία με μεγαλύτερο handling time,
• ένα ευπαθές προϊόν που παραδίδεται μόνο σε συγκεκριμένες περιοχές,
• ένα προϊόν που δεν υποστηρίζει express delivery,
• ένα προϊόν που δεν αποστέλλεται εκτός Ελλάδας.

Η εξαίρεση πρέπει να καταγράφεται στα product data και να περνά στα σχετικά layers. Αν υπάρχει μόνο σε ένα shipping plugin ή μόνο ως σημείωση στη σελίδα προϊόντος, αυξάνεται ο κίνδυνος να χαθεί στο feed, στα structured data ή στο Merchant Center.

Πώς οργανώνονται σωστά τα returns data

Αποδοχή επιστροφών, return window και item condition

Το return policy πρέπει να διευκρινίζει αν οι επιστροφές επιτρέπονται και υπό ποιες προϋποθέσεις. Το return window χρειάζεται συγκεκριμένο αριθμό ημερών και σαφή αφετηρία, συνήθως σε σχέση με την παράδοση του προϊόντος.

Πρέπει επίσης να δηλώνεται η αποδεκτή κατάσταση του προϊόντος. Ανάλογα με την κατηγορία, μπορεί να γίνονται δεκτά:

• μόνο νέα και αχρησιμοποίητα προϊόντα,
• προϊόντα σε κατάσταση like new,
• μεταχειρισμένα προϊόντα,
• μόνο ελαττωματικά προϊόντα.

Το Merchant Center υποστηρίζει product-level returns data με διαφορετικά item conditions και window types. Αυτό δεν σημαίνει ότι κάθε συνδυασμός είναι κατάλληλος για κάθε αγορά ή ότι μπορεί να παρακάμπτει την εφαρμοστέα νομοθεσία.

Return methods και κόστος επιστροφής

Η μέθοδος επιστροφής επηρεάζει τόσο την εμπειρία του πελάτη όσο και το κόστος. Ένα e-shop μπορεί να προσφέρει:

• επιστροφή με courier ή ταχυδρομείο,
• επιστροφή σε φυσικό κατάστημα,
• παράδοση σε drop-off point,
• επιστροφή σε kiosk όπου υποστηρίζεται.

Πρέπει να διευκρινίζεται αν η επιστροφή είναι δωρεάν, αν ο πελάτης πληρώνει απευθείας τον μεταφορέα ή αν το κόστος αφαιρείται από το refund. Μία πολιτική μπορεί να συνδυάζει διαφορετικούς κανόνες. Για παράδειγμα, η επιστροφή σε κατάστημα μπορεί να είναι δωρεάν, ενώ η επιστροφή με courier να έχει συγκεκριμένη χρέωση.

Refund, exchange, store credit και restocking fees

Το αποτέλεσμα της επιστροφής δεν είναι πάντοτε το ίδιο. Ανάλογα με την πολιτική και τα νόμιμα δικαιώματα του καταναλωτή, μπορεί να προσφέρεται:

• πλήρες refund,
• μερικό refund,
• exchange,
• store credit.

Αν εφαρμόζεται restocking fee, πρέπει να γνωστοποιείται με σαφήνεια και να έχει ελεγχθεί ότι είναι νόμιμο για τη συγκεκριμένη αγορά και περίπτωση. Δεν πρέπει να χρησιμοποιείται ως γενικός κανόνας για νόμιμες αξιώσεις που αφορούν ελαττωματικά ή μη συμμορφούμενα προϊόντα.

Εξαιρέσεις και μη επιστρεφόμενα προϊόντα

Ορισμένες κατηγορίες μπορεί να εξαιρούνται από το γενικό δικαίωμα υπαναχώρησης, υπό τις προϋποθέσεις της εφαρμοστέας νομοθεσίας. Ενδεικτικά μπορεί να υπάρχουν ειδικοί κανόνες για:

• εξατομικευμένα προϊόντα,
• ευπαθή προϊόντα,
• σφραγισμένα προϊόντα υγιεινής μετά το άνοιγμα,
• digital goods όταν έχει αρχίσει η παροχή με την απαιτούμενη συναίνεση,
• προϊόντα που εμπίπτουν σε συγκεκριμένη νόμιμη εξαίρεση από το δικαίωμα υπαναχώρησης· η απλή επισήμανση ενός προϊόντος ως final sale δεν αρκεί από μόνη της,
• seasonal policies με διαφορετικό return window.

Οι εξαιρέσεις πρέπει να εμφανίζονται πριν από την αγορά και να περνούν, όπου είναι δυνατό, στα product-level returns data. Η γενική δήλωση «δεν γίνονται επιστροφές» είναι επικίνδυνη όταν δεν αντανακλά τα νόμιμα δικαιώματα του καταναλωτή.

Εμπορική πολιτική, υπαναχώρηση και ελαττωματικό προϊόν

Το e-shop πρέπει να διακρίνει τρεις διαφορετικές έννοιες:

• Εμπορική πολιτική επιστροφών: πρόσθετοι ή ευνοϊκότεροι όροι που επιλέγει να προσφέρει η επιχείρηση.
• Δικαίωμα υπαναχώρησης: το δικαίωμα ακύρωσης μιας εξ αποστάσεως σύμβασης εντός της νόμιμης περιόδου, με τις προβλεπόμενες εξαιρέσεις.
• Δικαιώματα για ελαττωματικό ή μη συμμορφούμενο προϊόν: διαφορετικό νομικό πλαίσιο, το οποίο δεν ταυτίζεται με την απλή αλλαγή γνώμης.

Στην Ευρωπαϊκή Ένωση, ο καταναλωτής έχει κατά κανόνα δικαίωμα υπαναχώρησης εντός 14 ημερών για εξ αποστάσεως αγορές, αλλά υπάρχουν εξαιρέσεις. Επίσης, το κόστος επιστροφής μπορεί σε ορισμένες περιπτώσεις υπαναχώρησης να βαρύνει τον καταναλωτή, εφόσον έχει ενημερωθεί σωστά. Τα παραπάνω δεν πρέπει να συγχέονται με τις υποχρεώσεις του εμπόρου για ελαττωματικά προϊόντα.

Το άρθρο δεν αποτελεί νομική συμβουλή. Η επιχείρηση πρέπει να επιβεβαιώνει την πολιτική της με κατάλληλο νομικό σύμβουλο, ιδιαίτερα όταν δραστηριοποιείται σε πολλές αγορές.

Από το policy page στα διαφορετικά commerce data layers

Policy page, product page και checkout

Το policy page πρέπει να παρέχει το πλήρες πλαίσιο. Το product page πρέπει να εμφανίζει τις πληροφορίες που επηρεάζουν το συγκεκριμένο προϊόν. Το checkout πρέπει να υπολογίζει το τελικό κόστος και να παρουσιάζει τις διαθέσιμες επιλογές για τη διεύθυνση του πελάτη.

Αυτά τα τρία σημεία εξυπηρετούν διαφορετικές ανάγκες, αλλά δεν πρέπει να αντιφάσκουν. Αν το policy page αναφέρει παράδοση σε 2–4 εργάσιμες ημέρες, το product page εμφανίζει 5–7 ημέρες και το checkout δεν δίνει καμία εκτίμηση, ο χρήστης και τα commerce systems λαμβάνουν ασυνεπή εικόνα.

Η τεχνική σταθερότητα του τελικού βήματος αγοράς καλύπτεται αναλυτικότερα στον οδηγό για το Checkout Readiness στο Agentic Commerce. Στο παρόν άρθρο το checkout εξετάζεται μόνο ως σημείο εμφάνισης και επιβεβαίωσης των shipping totals και των διαθέσιμων επιλογών.

Product feed και Google Merchant Center

Το product feed και το Merchant Center μπορούν να περιλαμβάνουν account-level και product-level shipping ή returns data. Η γενική προσέγγιση είναι:

• account-level πολιτική για το μεγαλύτερο μέρος του catalog,
• product-level fields ή labels για πραγματικές εξαιρέσεις,
• diagnostics για ελλιπή, ανακριβή ή αντικρουόμενα data.

Το feed λειτουργεί ως distribution layer και όχι ως ανεξάρτητη πηγή που επινοεί κανόνες. Ο αναλυτικός σχεδιασμός των feeds καλύπτεται στον οδηγό Product Feeds για Agentic Commerce SEO.

Structured data στο site

Η Google τεκμηριώνει διαφορετικά επίπεδα shipping και return markup:

• το ShippingService μπορεί να περιγράφει μία βασική πολιτική αποστολής σε επίπεδο επιχείρησης,
• το OfferShippingDetails μπορεί να χρησιμοποιηθεί για shipping πληροφορίες συγκεκριμένης προσφοράς,
• το MerchantReturnPolicy μπορεί να περιγράφει γενική ή offer-level πολιτική επιστροφών.

Τα offer-level policies υποστηρίζουν μικρότερο subset properties από τα organization-level policies. Επίσης, το πλήρες λεξιλόγιο του schema.org είναι ευρύτερο από τα properties που τεκμηριώνει ή χρησιμοποιεί η Google.

Τα structured data πρέπει να ελέγχονται στο rendered HTML και με τα σχετικά validation tools. Δεν αρκεί να γνωρίζει το agency ότι ένα plugin «παράγει schema». Χρειάζεται να επιβεβαιώνεται ότι το markup αντιστοιχεί στις πραγματικές πολιτικές και δεν δημιουργεί δεύτερη, ανεξάρτητη εκδοχή των shipping και returns data. Περισσότερες λεπτομέρειες υπάρχουν στον οδηγό για τα structured data σε e-shop και Agentic Commerce SEO.

APIs και commerce protocols

Τα APIs και τα commerce protocols ανήκουν στο dynamic action layer. Μπορούν, ανάλογα με την ενσωμάτωση, να:

• δέχονται τη διεύθυνση του πελάτη,
• επιστρέφουν διαθέσιμα shipping options,
• υπολογίζουν shipping, taxes και totals,
• ενημερώνουν την κατάσταση μιας παραγγελίας,
• μεταφέρουν return ή refund events.

Αυτό το επίπεδο δεν αντικαθιστά τις δημόσιες πολιτικές ή τα catalog data. Χρειάζεται, όμως, να επιστρέφει authoritative και τρέχουσες τιμές. Η τεχνική λειτουργία του action layer αναλύεται στο άρθρο APIs και Commerce Protocols για Agentic Commerce.

Ο παρακάτω πίνακας συνοψίζει τον ρόλο κάθε layer.

Βασική πολιτική, source of truth και product-level εξαιρέσεις

Μία βασική πολιτική για το μεγαλύτερο μέρος του catalog

Η πιο διαχειρίσιμη αρχιτεκτονική ξεκινά συνήθως από μία βασική πολιτική που καλύπτει το μεγαλύτερο μέρος του catalog. Η πολιτική μπορεί να ορίζει:

• τις προεπιλεγμένες χώρες και περιοχές,
• το standard shipping service,
• το default shipping cost,
• το default delivery time,
• το default return window,
• τα βασικά return methods,
• τα βασικά fees.

Η προσέγγιση αυτή μειώνει τα σημεία συντήρησης. Αν το 90% των προϊόντων ακολουθεί τον ίδιο κανόνα, δεν υπάρχει λόγος να δημιουργούνται χιλιάδες ξεχωριστές product-level πολιτικές.

Εξαιρέσεις μόνο όπου υπάρχει πραγματική απόκλιση

Τα product-level overrides, τα shipping labels και τα return policy labels είναι χρήσιμα όταν υπάρχει πραγματική απόκλιση. Μπορούν να χρησιμοποιηθούν για:

• ειδικές κατηγορίες μεγάλου όγκου,
• προϊόντα με μεγαλύτερο handling time,
• seasonal return policies,
• προϊόντα με ειδική εμπορική πολιτική επιστροφών, χωρίς περιορισμό των νόμιμων δικαιωμάτων του καταναλωτή,
• προϊόντα που δεν αποστέλλονται σε συγκεκριμένες αγορές,
• διαφορετική πολιτική επιστροφών για συγκεκριμένη χώρα.

Η υπερβολική χρήση εξαιρέσεων αυξάνει την πολυπλοκότητα, δυσκολεύει το testing και δημιουργεί μεγαλύτερο κίνδυνο να παραμείνει ενεργός ένας παλιός κανόνας σε κάποιο feed ή integration.

Επιλογή operational source of truth

Το source of truth είναι το σύστημα στο οποίο τηρείται ο επίσημος κανόνας ή από το οποίο προκύπτει ο έγκυρος υπολογισμός. Δεν είναι απαραίτητα το ίδιο για κάθε e-shop.

Οι κανόνες μπορεί να τηρούνται στο:

• e-commerce platform,
• ERP,
• shipping app,
• feed manager,
• Merchant Center,
• custom database,
• custom integration.

Η επιχείρηση και το agency πρέπει να καθορίσουν:

• ποιο σύστημα αποθηκεύει τον βασικό κανόνα,
• ποιο σύστημα υπολογίζει τις δυναμικές χρεώσεις,
• ποιο σύστημα διανέμει τα data,
• ποιος εγκρίνει τις αλλαγές,
• ποια είναι η κατεύθυνση συγχρονισμού,
• ποια manual settings μπορούν να αντικατασταθούν από ένα app ή API.

Στο WooCommerce και Agentic Commerce SEO, το source of truth μπορεί να επηρεάζεται από plugins, ERP integrations και feed generators. Στο Shopify και Agentic Commerce SEO, μπορεί να επηρεάζεται από τα shipping profiles, τα Markets, τα apps και το Google & YouTube app. Η σωστή επιλογή εξαρτάται από την πραγματική αρχιτεκτονική του e-shop.

Consistency μεταξύ site, feed, schema και Merchant Center

Ποια στοιχεία πρέπει να συμφωνούν

Τα κοινά στοιχεία που εμφανίζονται σε περισσότερα από ένα layer πρέπει να συμφωνούν. Ιδιαίτερη προσοχή χρειάζονται:

• το shipping cost,
• το free shipping threshold,
• το νόμισμα,
• οι χώρες και οι περιοχές εξυπηρέτησης,
• το handling time,
• το transit time,
• το pickup availability,
• το return window,
• τα return fees,
• τα return methods,
• τα product-level exceptions,
• το policy URL.

Η Google διαθέτει diagnostics για περιπτώσεις στις οποίες το shipping cost του Merchant Center δεν συμφωνεί με το κόστος που εμφανίζεται στο site. Η συνέπεια, επομένως, δεν είναι μόνο editorial best practice. Είναι πρακτική απαίτηση για αξιόπιστα commerce data.

Τι σημαίνει consistency και τι δεν σημαίνει

Consistency δεν σημαίνει ότι όλα τα συστήματα πρέπει να έχουν ακριβώς τα ίδια fields. Ένα checkout μπορεί να υπολογίζει δυναμικά το κόστος βάσει διεύθυνσης, ενώ ένα organization-level schema μπορεί να περιγράφει γενικά shipping conditions.

Consistency σημαίνει ότι:

• οι κοινές πληροφορίες δεν αντιφάσκουν,
• οι εξαιρέσεις μεταφέρονται στα layers που τις υποστηρίζουν,
• το δυναμικό calculation ακολουθεί την εγκεκριμένη πολιτική,
• τα διαφορετικά formats περιγράφουν τον ίδιο επιχειρηματικό κανόνα.

Το πλήρες schema.org vocabulary, για παράδειγμα, είναι ευρύτερο από το Google-supported subset. Η απουσία ενός schema.org property από το Merchant Center δεν αποτελεί από μόνη της ασυνέπεια. Ασυνέπεια υπάρχει όταν το site δηλώνει δωρεάν επιστροφή και το Merchant Center δηλώνει χρέωση ή όταν το feed επιτρέπει αποστολή σε χώρα που το checkout απορρίπτει.

Data precedence και overrides στο οικοσύστημα της Google

Όταν οι ίδιες πολιτικές δηλώνονται σε διαφορετικά σημεία, η Google εφαρμόζει συγκεκριμένη σειρά προτεραιότητας. Σύμφωνα με την τεκμηρίωσή της, η σειρά από το ισχυρότερο προς το ασθενέστερο source είναι:

1. τα account-level settings που παρέχονται μέσω του Content API for Shopping,
2. οι ρυθμίσεις στο Merchant Center ή στο Search Console,
3. το product-level merchant listing markup,
4. το organization-level markup.

Η σειρά αυτή αφορά τις διαφορετικές πηγές policy information που χρησιμοποιεί η Google και δεν πρέπει να γενικεύεται σε όλα τα AI systems.

Ξεχωριστά, μέσα στο Merchant Center, τα product-level shipping data μπορούν να κάνουν override τα account-level shipping settings για τα συγκεκριμένα προϊόντα. Για αυτό, ένα product-level override πρέπει να ελέγχεται ως ολοκληρωμένος κανόνας και όχι μόνο ως αλλαγή του shipping cost.

Change management και υπεύθυνος ενημέρωσης

Τα shipping και return policies αλλάζουν συχνά: νέος τιμοκατάλογος courier, νέο free shipping threshold, νέα αγορά ή διαφορετικό return window. Χωρίς change management, οι αλλαγές εφαρμόζονται μόνο σε ένα σημείο.

Κάθε αλλαγή πρέπει να έχει:

• business approval,
• effective date,
• λίστα συστημάτων που πρέπει να ενημερωθούν,
• υπεύθυνο υλοποίησης,
• validation μετά την αλλαγή,
• change log,
• επανέλεγχο μετά το επόμενο feed refresh ή synchronization.

Ο παρακάτω πίνακας παρουσιάζει συνηθισμένες ασυνέπειες.

International shipping και διαφορετικές πολιτικές ανά αγορά

Country-specific και region-specific shipping data

Το international shipping πρέπει να οργανώνεται ανά χώρα ή περιοχή. Η φράση «αποστολές σε όλο τον κόσμο» δεν αρκεί για να περιγράψει:

• ποιες χώρες εξυπηρετούνται,
• ποιες χώρες εξαιρούνται,
• ποια services είναι διαθέσιμα,
• ποιο κόστος και ποιος χρόνος ισχύει,
• ποιο νόμισμα χρησιμοποιείται,
• ποια προϊόντα έχουν περιορισμούς.

Τα country-specific data είναι επίσης σημαντικά για τα feeds. Ένα target country ή μία αγορά του Merchant Center δεν σημαίνει αυτομάτως ότι κάθε προϊόν μπορεί να παραδοθεί σε κάθε διεύθυνση της χώρας.

Free shipping thresholds ανά χώρα και νόμισμα

Το threshold πρέπει να ορίζεται για τη συγκεκριμένη αγορά και το αντίστοιχο νόμισμα. Ένα threshold 50 EUR για την Ελλάδα δεν πρέπει να μεταφέρεται ως 50 GBP στο Ηνωμένο Βασίλειο ή ως κοινός κανόνας σε χώρες με διαφορετικά shipping costs.

Για κάθε αγορά πρέπει να καταγράφονται:

• το threshold,
• το νόμισμα,
• η υπηρεσία αποστολής,
• το κόστος κάτω από το threshold,
• οι εξαιρέσεις ανά προϊόν και περιοχή.

Returns policy ανά αγορά

Το return policy μπορεί να διαφοροποιείται ανά χώρα ως προς:

• το return address,
• το διαθέσιμο method,
• το κόστος,
• τη διαδικασία,
• τη γλώσσα του policy page,
• τις νόμιμες υποχρεώσεις.

Οι διαφορές πρέπει να δηλώνονται με country-specific rules και όχι να κρύβονται σε ένα μακροσκελές γενικό policy page. Αν η ίδια πολιτική ισχύει σε πολλές χώρες, μπορεί να επαναχρησιμοποιείται, αρκεί να είναι πραγματικά κατάλληλη για όλες.

Delivery area και ευρωπαϊκό geo-blocking

Οι ευρωπαϊκοί κανόνες κατά του αδικαιολόγητου geo-blocking περιορίζουν τις διακρίσεις βάσει ιθαγένειας ή τόπου κατοικίας. Δεν σημαίνουν, όμως, ότι κάθε e-shop υποχρεούται να παραδίδει προϊόντα σε κάθε κράτος μέλος.

Το e-shop πρέπει να δηλώνει καθαρά:

• σε ποιες χώρες προσφέρει παράδοση,
• ποια cross-border delivery options είναι διαθέσιμα,
• πόσο κοστίζουν,
• αν ο πελάτης μπορεί να οργανώσει ο ίδιος την παραλαβή όπου επιτρέπεται.

Η ενημέρωση αυτή πρέπει να συμφωνεί με τα shipping zones και τα machine-readable data.

Δασμοί, εισαγωγικοί φόροι και total landed cost

Σε αποστολές από τρίτες χώρες, το shipping cost δεν είναι πάντοτε το τελευταίο κόστος. Μπορεί να υπάρχουν εισαγωγικοί δασμοί, VAT, customs handling charges ή άλλες επιβαρύνσεις.

Το total landed cost είναι το συνολικό κόστος που χρειάζεται να πληρώσει ο αγοραστής για να παραλάβει το προϊόν. Για να χαρακτηριστεί μία τιμή all-inclusive, πρέπει να είναι σαφές ότι περιλαμβάνει τις σχετικές χρεώσεις που αναλαμβάνει ο πωλητής.

Δύο βασικοί όροι είναι:

• DDP — Delivered Duty Paid: ο πωλητής αναλαμβάνει, σύμφωνα με τον συμφωνημένο όρο, τις εξαγωγικές, transit και εισαγωγικές διατυπώσεις και τις σχετικές επιβαρύνσεις μέχρι το συμφωνημένο σημείο παράδοσης.
• DAP — Delivered at Place: ο πωλητής παραδίδει στο συμφωνημένο σημείο, αλλά ο αγοραστής αναλαμβάνει κατά κανόνα τις εισαγωγικές διατυπώσεις και τις σχετικές επιβαρύνσεις.

Το DDU είναι παλαιότερος όρος και δεν πρέπει να χρησιμοποιείται ως ισότιμος σύγχρονος Incoterm. Για τις σημερινές πολιτικές είναι προτιμότερη η σωστή διάκριση DDP και DAP.

Τα Incoterms είναι εμπορικοί όροι που κατανέμουν ευθύνες μεταξύ πωλητή και αγοραστή. Δεν αντικαθιστούν τις υποχρεώσεις ενημέρωσης προς τον καταναλωτή. Αν πρόσθετες χρεώσεις δεν μπορούν να υπολογιστούν εκ των προτέρων, ο πελάτης πρέπει να ενημερώνεται ότι ενδέχεται να προκύψουν.

Η Google αναφέρει ότι government-imposed fees, όπως import duties, δεν πρέπει να υποβάλλονται γενικά ως shipping cost. Το agency πρέπει, επομένως, να αποφεύγει να συμπιέζει διαφορετικές χρεώσεις σε λάθος field μόνο για να εμφανίσει ένα συνολικό ποσό.

International shipping check

Δεν υπάρχει καθολικό schema property που να εγγυάται ότι κάθε AI agent θα καταλάβει τον όρο DDP ή DAP. Η αξιόπιστη λύση είναι ο σαφής κανόνας στο site, η σωστή λογική υπολογισμού και τα authoritative totals που επιστρέφονται στα δυναμικά commerce flows.

Τι λειτουργεί σήμερα και τι ανήκει στο εξελισσόμενο Agentic Commerce

Δυνατότητες που λειτουργούν ήδη

Σήμερα τα e-shops μπορούν ήδη να οργανώσουν shipping και returns data μέσω:

• account-level shipping settings στο Merchant Center,
• account-level return policies,
• product-level shipping fields,
• product-level returns data,
• shipping labels και return policy labels,
• free shipping thresholds,
• pickup data σε υποστηριζόμενες local λειτουργίες,
• shipping και returns structured data,
• diagnostics και validation,
• target-country και policy references σε υποστηριζόμενα feed models.

Αυτά είναι λειτουργικά data layers. Δεν χρειάζεται ένα e-shop να περιμένει την πλήρη ωρίμανση του Agentic Commerce για να διορθώσει τις πολιτικές και τις ασυνέπειές του.

UCP και agentic checkout integrations σε περιορισμένο ή pilot στάδιο

Το Universal Commerce Protocol της Google είναι εξελισσόμενο standard. Η ίδια η Google διευκρινίζει ότι δεν υποστηρίζονται όλες οι δυνατότητες του specification στις επιφάνειές της. Για live χρήση στα σχετικά AI surfaces απαιτούνται διαδικασία ένταξης και έγκριση.

Αντίστοιχα, τα agentic checkout specifications του OpenAI περιγράφουν authoritative cart state με items, shipping, taxes, fees και totals, αλλά η πρόσβαση και η υποστήριξη διαφέρουν ανά merchant, partner και αγορά.

Για αυτό δεν είναι σωστό να παρουσιάζεται το UCP ή οποιοδήποτε agentic checkout ως καθολικά διαθέσιμο σε όλα τα ελληνικά e-shops.

Εύλογες μελλοντικές χρήσεις από AI agents

Με βάση τα διαθέσιμα data models, είναι εύλογο ένα AI agent να μπορεί να χρησιμοποιεί πληροφορίες όπως:

• το total purchase cost,
• το destination eligibility,
• το estimated delivery,
• το pickup availability,
• το return window,
• τα return fees,
• τα product-level exceptions,
• τα πιθανά additional import charges.

Τα data αυτά μπορούν να βοηθούν τη σύγκριση και το filtering. Δεν υπάρχει, όμως, δημόσια γνωστή ακριβής στάθμιση που να δείχνει ποιο κριτήριο υπερισχύει ή αν χρησιμοποιείται σε κάθε AI shopping experience.

Ο παρακάτω πίνακας διαχωρίζει τις τρεις κατηγορίες.

Συχνά λάθη στα shipping και returns data ενός e-shop

Διαφορετικό shipping cost στο site και στο Merchant Center

Το e-shop μπορεί να υπολογίζει νέο τιμοκατάλογο, ενώ το Merchant Center εξακολουθεί να χρησιμοποιεί παλιό account-level service ή product-level override. Το agency πρέπει να ελέγξει τα shipping settings, το feed mapping, τα apps και τα APIs που μπορούν να αντικαθιστούν manual ρυθμίσεις.

Ασαφές delivery time

Διατυπώσεις όπως «άμεση αποστολή» ή «παράδοση σύντομα» δεν περιγράφουν επαρκώς το delivery promise. Χρειάζονται σαφή handling και transit ranges, εργάσιμες ημέρες και order cut-off. Αν δεν μπορούν να υπολογιστούν αξιόπιστα, πρέπει να εμφανίζεται σαφής εναλλακτική ενημέρωση, η οποία εξηγεί πότε και πώς θα επιβεβαιωθεί ο τελικός χρόνος παράδοσης.

Δωρεάν μεταφορικά χωρίς σαφείς όρους

Το marketing banner μπορεί να αναφέρει δωρεάν μεταφορικά χωρίς χώρα, threshold ή εξαιρέσεις. Ο πελάτης ανακαλύπτει τη χρέωση αργότερα στο checkout, ενώ το feed μπορεί να έχει διαφορετικό κανόνα. Η λύση είναι ένα ενιαίο, εγκεκριμένο free-shipping rule ανά αγορά.

International shipping χωρίς συγκεκριμένους προορισμούς

Η δήλωση «στέλνουμε στο εξωτερικό» δεν εξηγεί ποιες χώρες, ποια products, ποιο κόστος και ποιος χρόνος υποστηρίζονται. Πρέπει να ελέγχονται τα country rules, τα shipping zones και τα product restrictions.

Μη σαφές total landed cost

Ένα DAP order μπορεί να εμφανίζεται ως «τελική τιμή» παρότι ο πελάτης μπορεί να πληρώσει δασμούς ή import VAT κατά την εισαγωγή. Η επιχείρηση πρέπει να διορθώσει το messaging και το checkout logic ή να ενημερώνει ρητά ότι μπορεί να ισχύσουν πρόσθετες χρεώσεις.

Product exception που δεν περνά στα υπόλοιπα συστήματα

Ένα oversized προϊόν μπορεί να έχει ειδική χρέωση μόνο στο shipping app, ενώ το feed και το Merchant Center κληρονομούν standard κόστος. Η εξαίρεση πρέπει να υπάρχει στο rules matrix και να χαρτογραφείται σε κάθε σχετικό layer.

Pickup που εμφανίζεται μόνο ως κείμενο

Το site μπορεί να αναφέρει pickup χωρίς store eligibility, pickup SLA ή local availability. Έτσι, η πληροφορία είναι χρήσιμη για τον χρήστη, αλλά δεν μπορεί να αξιοποιηθεί σωστά στα υποστηριζόμενα local data layers.

Return policy που είναι κρυμμένη ή ελλιπής

Το return policy δεν πρέπει να υπάρχει μόνο μέσα στους γενικούς όρους, να απαιτεί login ή να παραλείπει το return window, τα methods, τα fees και τις εξαιρέσεις. Χρειάζεται ξεχωριστό, δημόσιο και συνεπές policy page.

Missing fields και σιωπηρά fallbacks

Ένα shipping record μπορεί να περιλαμβάνει το κόστος αποστολής, αλλά να μην διαθέτει όλα τα sub-fields που απαιτούνται για τον υπολογισμό του estimated delivery, όπως το handling time ή το transit time. Σε αυτή την περίπτωση, το shipping cost μπορεί να εξακολουθήσει να χρησιμοποιείται, ενώ οι πληροφορίες για τον χρόνο παράδοσης μπορεί να αγνοηθούν ή να θεωρηθούν άκυρες. Το πρόβλημα ενδέχεται να μην είναι ορατό στη σελίδα του προϊόντος και να εντοπίζεται μόνο μέσω των diagnostics του αντίστοιχου συστήματος.

Το agency δεν πρέπει να θεωρεί ότι το σύστημα θα συμπληρώσει αυτόματα ένα ασφαλές default ή ότι θα χρησιμοποιήσει τις γενικές account-level ρυθμίσεις. Πρέπει να ελέγχει την τεκμηριωμένη συμπεριφορά του συγκεκριμένου data layer και, όταν δεν μπορεί να υπολογιστεί αξιόπιστα ο χρόνος παράδοσης, να προβλέπει σαφή εναλλακτική ενημέρωση προς τον χρήστη.

Workflow υλοποίησης για digital agencies και κατασκευαστές e-shops

Στάδιο 1 — Requirements gathering

Το agency πρέπει να ξεκινήσει από τις πραγματικές επιχειρηματικές αποφάσεις και όχι από τα διαθέσιμα fields ενός plugin. Η αρχική καταγραφή πρέπει να περιλαμβάνει:

• shipping countries και zones,
• excluded destinations,
• shipping services,
• costs και thresholds,
• handling και transit times,
• order cut-offs και εργάσιμες ημέρες,
• pickup rules,
• category και product exceptions,
• return windows,
• return methods και fees,
• refund outcomes,
• non-returnable categories,
• international duties και tax responsibility,
• DDP ή DAP rule όπου εφαρμόζεται.

Στάδιο 2 — Δημιουργία shipping και returns rules matrix

Το rules matrix μετατρέπει τις προφορικές οδηγίες σε ελέγξιμους κανόνες. Για κάθε κανόνα πρέπει να καταγράφονται:

• το baseline policy,
• η χώρα και η περιοχή,
• το shipping service,
• το κόστος και το threshold,
• τα handling και transit ranges,
• τα category και product exceptions,
• το returns policy,
• τυχόν seasonal override,
• η ευθύνη για duties και taxes,
• ο υπεύθυνος του κανόνα,
• το effective date.

Το matrix πρέπει να είναι αρκετά απλό ώστε να ενημερώνεται, αλλά αρκετά αναλυτικό ώστε ένα άλλο agency ή developer να καταλαβαίνει τι πρέπει να υλοποιηθεί.

Στάδιο 3 — Επιλογή source of truth και data ownership

Για κάθε rule family πρέπει να οριστεί:

• πού αποθηκεύεται ο κανόνας,
• πού γίνεται το calculation,
• ποιο σύστημα δημιουργεί το feed,
• ποιο σύστημα δημιουργεί τα structured data,
• ποιος ενημερώνει το Merchant Center,
• ποιος εγκρίνει τα business changes,
• ποια integrations μπορούν να κάνουν overwrite τις ρυθμίσεις.

Η φράση «το plugin το κάνει αυτόματα» δεν αποτελεί documentation. Το agency πρέπει να γνωρίζει ποια data διαβάζει το plugin, πότε συγχρονίζονται και ποια manual changes μπορεί να χαθούν.

Στάδιο 4 — Mapping στα διαφορετικά data layers

Οι εγκεκριμένοι κανόνες πρέπει να χαρτογραφηθούν σε:

• policy pages,
• product pages,
• checkout,
• e-commerce platform,
• ERP,
• product feed,
• Merchant Center,
• structured data,
• API ή commerce protocol όπου υπάρχει.

Το mapping πρέπει να δείχνει ποια fields υπάρχουν σε κάθε layer και πώς εκφράζεται ο ίδιος κανόνας. Δεν είναι απαραίτητο κάθε layer να αποθηκεύει όλη την πολιτική.

Στάδιο 5 — Validation και testing

Το testing πρέπει να χρησιμοποιεί πραγματικά σενάρια και όχι μόνο μία παραγγελία από την Αθήνα. Ενδεικτικά πρέπει να ελέγχονται:

• standard και excluded destinations,
• postcode boundaries,
• παραγγελία ακριβώς κάτω και πάνω από το free shipping threshold,
• διαφορετικά νομίσματα,
• oversized και custom-made προϊόντα,
• pickup scenarios,
• return-policy exceptions,
• rendered structured data,
• feed validation και Merchant Center diagnostics,
• checkout totals,
• international DDP και DAP scenarios,
• total landed cost disclosure.

Missing fields, overrides και fallback behaviour

Required και recommended fields

Το agency πρέπει να γνωρίζει ποια fields είναι required για το συγκεκριμένο layer και ποια είναι recommended. Πρέπει επίσης να γνωρίζει ποια sub-fields λειτουργούν ως ομάδα.

Για παράδειγμα, η Google αναφέρει ότι, για να εμφανιστεί estimated delivery date από product-level shipping sub-attributes, χρειάζονται:

• το max_transit_time,
• το max_handling_time,
• το price.

Αν λείπει ένα από αυτά, οι χρόνοι μπορεί να ακυρωθούν, ενώ το shipping price μπορεί να εξακολουθήσει να χρησιμοποιείται. Δεν πρέπει να θεωρείται ότι υπάρχει πάντοτε ένα default transit time.

Product-level override behaviour

Όταν υποβάλλονται product-level shipping data με price για συγκεκριμένη τοποθεσία, τα data αυτά μπορούν να υπερισχύσουν των account-level settings, συμπεριλαμβανομένων των delivery times και του minimum order value.

Υποθετικό παράδειγμα: το agency προσθέτει product-level shipping price 25 ευρώ για ένα έπιπλο, αλλά δεν προσθέτει handling και transit data. Το κόστος μπορεί να χρησιμοποιηθεί, ενώ οι χρόνοι σε account level δεν εφαρμόζονται όπως ανέμενε η ομάδα. Το product page συνεχίζει να εμφανίζει standard delivery 2–4 ημερών, παρότι το έπιπλο χρειάζεται 10 ημέρες.

Missing transit ή handling time

Αν λείπει το transit time ή το handling time, πρέπει να ελεγχθεί:

• αν το record παραμένει μερικώς έγκυρο,
• αν χρησιμοποιείται μόνο το shipping price,
• αν ακυρώνονται τα delivery sub-fields,
• αν χάνεται το estimated delivery annotation,
• αν υπάρχει carrier-calculated εναλλακτική στα υποστηριζόμενα flows.

Το fallback πρέπει να βασίζεται στην επίσημη συμπεριφορά του layer και όχι σε υπόθεση του developer.

Partial record validity

Ένα partially completed record δεν έχει καθολικά την ίδια συμπεριφορά. Ανάλογα με το specification:

• μπορεί να χρησιμοποιείται μόνο το κόστος,
• μπορεί να αγνοούνται οι χρόνοι,
• μπορεί να εμφανίζεται warning,
• μπορεί να απορρίπτεται το record ή το προϊόν,
• το πρόβλημα μπορεί να εμφανίζεται μόνο στα diagnostics.

Conflicting sources

Τα test cases πρέπει να καλύπτουν συγκρούσεις μεταξύ:

• Merchant Center και feed,
• account-level και product-level data,
• structured data και landing page,
• checkout και policy page,
• ERP και shipping plugin,
• inventory data και product-level pickup data.

Safe user-facing fallback

Όταν δεν μπορεί να υπολογιστεί αξιόπιστα το shipping cost, ο χρόνος παράδοσης ή το total landed cost, το e-shop δεν πρέπει να εμφανίζει αυθαίρετη ακρίβεια.

Ασφαλείς διατυπώσεις, ανάλογα με την περίπτωση, είναι:

• «Υπολογίζεται βάσει διεύθυνσης».
• «Ενδέχεται να ισχύσουν πρόσθετες εισαγωγικές επιβαρύνσεις».
• «Ο τελικός χρόνος επιβεβαιώνεται πριν από την ολοκλήρωση».

Οι διατυπώσεις αυτές δεν πρέπει να χρησιμοποιούνται ως μόνιμη λύση για data που θα μπορούσαν να υπολογίζονται. Είναι fallback για περιπτώσεις πραγματικής αβεβαιότητας.

Ο παρακάτω πίνακας μπορεί να χρησιμοποιηθεί ως βάση για τα agency test cases.

Στάδιο 6 — Launch και monitoring

Μετά το launch πρέπει να ελέγχονται:

• τα Merchant Center diagnostics,
• τα feed errors και warnings,
• τα structured data errors,
• δοκιμαστικές παραγγελίες από διαφορετικές περιοχές,
• international test orders,
• οι επιδράσεις του επόμενου feed refresh,
• οι αλλαγές μετά από update ενός app ή plugin,
• η συμπεριφορά μετά από αλλαγή courier ή policy.

Στάδιο 7 — Documentation και handover

Το agency πρέπει να παραδώσει:

• το shipping και returns rules matrix,
• το source-of-truth documentation,
• το mapping των data layers,
• την καταγραφή των plugins, apps και integrations,
• τα test cases,
• τα fallback rules,
• τα known limitations,
• τη διαδικασία change management,
• τα duty και tax disclosure rules,
• τους υπεύθυνους ενημέρωσης.

Checklist για digital agencies

• Discovery: Έχουν καταγραφεί όλες οι χώρες, zones, services, thresholds, returns και international charges;
• Business rules: Έχει εγκριθεί baseline policy και έχουν εντοπιστεί οι πραγματικές εξαιρέσεις;
• Source of truth: Είναι σαφές ποιο σύστημα αποθηκεύει και ποιο υπολογίζει κάθε κανόνα;
• Implementation: Έχουν χαρτογραφηθεί οι κανόνες σε site, checkout, feed, Merchant Center και structured data;
• Validation: Έχουν ελεγχθεί rendered markup, feed diagnostics και πραγματικά checkout totals;
• Fallback testing: Έχουν δοκιμαστεί missing fields, partial records και conflicting sources;
• Launch: Έχουν εκτελεστεί test orders για standard, excluded και international destinations;
• Monitoring: Υπάρχει υπεύθυνος για diagnostics και επανέλεγχο μετά από changes;
• Handover: Έχουν παραδοθεί rules matrix, ownership, test cases και change process;

Τι πρέπει να αποφασίσει και να εγκρίνει ο ιδιοκτήτης του e-shop

Οι επιχειρηματικές αποφάσεις πριν από την υλοποίηση

Η τεχνική ομάδα δεν πρέπει να επινοεί τις πολιτικές. Ο ιδιοκτήτης ή ο αρμόδιος e-commerce manager πρέπει να αποφασίσει:

• σε ποιες χώρες και περιοχές παραδίδει το e-shop,
• ποιες υπηρεσίες αποστολής προσφέρει,
• πώς υπολογίζεται το shipping cost,
• πότε ισχύει free shipping,
• ποια products εξαιρούνται,
• ποιο delivery promise μπορεί να τηρηθεί,
• αν και πού προσφέρεται pickup,
• ποιο είναι το return window,
• ποιος πληρώνει το return shipping,
• αν προσφέρεται refund, exchange ή store credit,
• πώς αντιμετωπίζονται duties και taxes,
• αν η διεθνής τιμή είναι πραγματικά all-inclusive.

Έγκριση δημόσιας πολιτικής και εξαιρέσεων

Το policy page πρέπει να εγκρίνεται πριν γίνει το τεχνικό mapping. Η έγκριση πρέπει να καλύπτει:

• τη συμφωνία με την πραγματική λειτουργία,
• τη σαφήνεια των χρεώσεων,
• τα product και market exceptions,
• τον νομικό έλεγχο όπου απαιτείται,
• τη συνέπεια των promotional claims.

Όροι όπως «δωρεάν επιστροφές», «παράδοση παντού» ή «τελική τιμή» δεν πρέπει να χρησιμοποιούνται όταν υπάρχουν ουσιώδεις εξαιρέσεις που αποκαλύπτονται μόνο αργότερα.

Κατανομή αρμοδιοτήτων

Η διαχείριση των shipping και returns data συνήθως μοιράζεται μεταξύ:

• του ιδιοκτήτη, που εγκρίνει την πολιτική,
• του e-commerce manager, που διαχειρίζεται τις καθημερινές αλλαγές,
• του agency, που υλοποιεί και ελέγχει το mapping,
• του ERP provider, που διαχειρίζεται operational data,
• του feed provider, που δημιουργεί τα channel-specific exports,
• του shipping integration provider, που επιστρέφει rates και services,
• του courier, που παρέχει τα πραγματικά services και transit estimates,
• του legal adviser, που ελέγχει τους όρους και τις εξαιρέσεις.

Χωρίς σαφή ownership, μία αλλαγή μπορεί να θεωρείται ευθύνη όλων και τελικά να μην εφαρμόζεται πουθενά σωστά.

Πότε πρέπει να γίνεται επανέλεγχος

Ο επανέλεγχος είναι απαραίτητος όταν υπάρχει:

• νέο courier agreement,
• αλλαγή shipping cost,
• νέα χώρα ή αγορά,
• αλλαγή free shipping threshold,
• νέο pickup location,
• αλλαγή return window ή fee,
• νέο product category με ειδικές ανάγκες,
• αλλαγή duty ή tax handling,
• αλλαγή από DAP σε DDP ή αντίστροφα,
• αλλαγή platform, app, plugin ή feed provider.

Checklist για ιδιοκτήτες e-shops

• Έχουν οριστεί οι χώρες, οι περιοχές και τα excluded destinations;
• Είναι σαφή τα shipping services, τα costs και τα thresholds;
• Μπορεί το e-shop να τηρήσει τα εμφανιζόμενα delivery times;
• Έχουν εγκριθεί τα product-level exceptions;
• Το return policy εξηγεί window, methods, fees και outcomes;
• Έχει ελεγχθεί η διάκριση υπαναχώρησης και ελαττωματικού προϊόντος;
• Είναι σαφές ποιος πληρώνει duties και import taxes;
• Χρησιμοποιείται ο όρος all-inclusive μόνο όταν είναι ακριβής;
• Έχουν οριστεί οι owners για site, feed, Merchant Center και structured data;
• Υπάρχει διαδικασία επανελέγχου μετά από αλλαγές;

Πρακτικό Shipping και Returns Readiness Checklist

Το παρακάτω checklist εστιάζει αποκλειστικά στις αποστολές και τις επιστροφές. Για έναν συνολικό έλεγχο του e-shop, χρησιμοποιήστε το Agentic Commerce Readiness Audit για e-shop.

Συχνές ερωτήσεις

Γιατί δεν αρκεί μία σελίδα αποστολών και επιστροφών;

Το policy page είναι απαραίτητο για τον χρήστη, αλλά δεν αντικαθιστά τα machine-readable fields που χρειάζονται τα product feeds, το Merchant Center και τα structured data. Οι ίδιοι επιχειρηματικοί κανόνες πρέπει να αποτυπώνονται χωρίς αντιφάσεις στα σχετικά data layers.

Ποια είναι η διαφορά μεταξύ handling time και transit time;

Το handling time είναι ο χρόνος από την καταχώριση της παραγγελίας μέχρι την παράδοσή της στον μεταφορέα. Το transit time είναι ο χρόνος από την παραλαβή από τον μεταφορέα μέχρι την παράδοση στον πελάτη. Μαζί συμβάλλουν στον υπολογισμό του estimated delivery.

Πότε χρειάζεται product-level shipping exception;

Χρειάζεται όταν ένα προϊόν αποκλίνει πραγματικά από τη βασική πολιτική, για παράδειγμα επειδή είναι oversized, εύθραυστο, made-to-order, έχει διαφορετικό handling time ή δεν αποστέλλεται σε συγκεκριμένες περιοχές.

Πώς πρέπει να δηλώνεται ένα free shipping threshold;

Πρέπει να δηλώνεται η ελάχιστη αξία παραγγελίας, το νόμισμα, η χώρα, το shipping service και οι εξαιρέσεις. Πρέπει επίσης να είναι σαφές ποιο κόστος ισχύει κάτω από το threshold.

Τι πρέπει να περιλαμβάνει ένα ολοκληρωμένο return policy;

Πρέπει να περιλαμβάνει το return window, την αποδεκτή κατάσταση προϊόντος, τα διαθέσιμα methods, το κόστος και ποιος το αναλαμβάνει, το πιθανό refund, exchange ή store credit και τα product ή seasonal exceptions.

Επιστρέφονται όλα τα online προϊόντα εντός 14 ημερών;

Όχι. Στην Ευρωπαϊκή Ένωση ισχύει κατά κανόνα δικαίωμα υπαναχώρησης 14 ημερών για εξ αποστάσεως αγορές, αλλά υπάρχουν νόμιμες εξαιρέσεις, όπως σε ορισμένα εξατομικευμένα, ευπαθή ή αποσφραγισμένα προϊόντα. Τα δικαιώματα για τα ελαττωματικά προϊόντα αποτελούν διαφορετικό ζήτημα.

Τα shipping structured data αποτελούν ranking factor;

Δεν υπάρχει επίσημη τεκμηρίωση ότι αποτελούν αυτόνομο ranking factor. Βοηθούν τη Google να κατανοήσει τα shipping policies και μπορεί να χρησιμοποιηθούν σε υποστηριζόμενες εμφανίσεις, αλλά δεν εγγυώνται ranking ή rich result.

Τι συμβαίνει όταν λείπει το transit time;

Δεν εφαρμόζεται αυτόματα η ίδια προεπιλεγμένη τιμή σε όλα τα συστήματα. Ανάλογα με το data layer, τα delivery-time fields μπορεί να αγνοηθούν ή να θεωρηθούν άκυρα, ενώ το shipping cost μπορεί να εξακολουθήσει να χρησιμοποιείται. Το agency πρέπει να ελέγχει τα diagnostics και την τεκμηριωμένη συμπεριφορά του συγκεκριμένου συστήματος.

Τι σημαίνουν DDP και DAP στο international shipping;

Στο DDP ο πωλητής αναλαμβάνει, σύμφωνα με τον συμφωνημένο όρο, τις εισαγωγικές διατυπώσεις και τις σχετικές επιβαρύνσεις. Στο DAP ο αγοραστής αναλαμβάνει κατά κανόνα τις εισαγωγικές διατυπώσεις και τα σχετικά costs. Η διάκριση επηρεάζει το αν η εμφανιζόμενη τιμή είναι πραγματικά all-inclusive.

Γνωρίζει πάντοτε ένα AI agent το total landed cost;

Όχι. Το total landed cost μπορεί να υπολογιστεί μόνο όταν το commerce system διαθέτει αξιόπιστα shipping, tax, duty και address data. Αν λείπουν κρίσιμες πληροφορίες, πρέπει να δηλώνεται η πιθανότητα πρόσθετων χρεώσεων και να αποφεύγεται η αυθαίρετη ακρίβεια.

Ποιος πρέπει να ενημερώνει τα shipping και returns data;

Ο ιδιοκτήτης ή το e-commerce team εγκρίνει τους επιχειρηματικούς κανόνες. Το agency, ο ERP provider, ο feed provider και οι πάροχοι integrations ενημερώνουν τα αντίστοιχα layers. Οι ρόλοι πρέπει να καταγράφονται ρητά στο documentation και στο handover.

Πηγές

• Merchant Shipping Policy Structured Data (ShippingService)
• Merchant Return Policy Structured Data (MerchantReturnPolicy)
• How To Add Merchant Listing Structured Data
• ShippingService – Schema.org Type
• OfferShippingDetails – Schema.org Type
• MerchantReturnPolicy – Schema.org Type
• Shipping [shipping]
• Set up shipping settings for an entire account
• Set up estimated delivery time
• Free shipping threshold [free_shipping_threshold]
• Shipping label [shipping_label]
• Returns [returns]
• Return policy label [return_policy_label]
• Product data specification
• How to fix: Inaccurate shipping costs (due to inconsistent shipping costs between your feed and the checkout pages on your website)
• How to fix: Missing shipping sub-attribute
• Local product data specification
• Pickup method [pickup_method]
• Pickup SLA [pickup_SLA]
• Google Universal Commerce Protocol (UCP) Guide
• Prepare your Merchant Center account
• Agentic Checkout Spec – Agentic Commerce
• Product Feed Spec – Agentic Commerce
• Directive 2011/83/EU on Consumer Rights
• Returns and the Right of Withdrawal
• Shipping and Delivery
• B2C E-commerce, Distance and Off-premises Selling
• Δικαιώματα Καταναλωτών
• Geo-blocking: Unlocking E-commerce in the EU
• Incoterms® 2020
• Incoterms® 2020: DAP or DDP?