E-pin Scriptinde Mesafeli Satış Sözleşmesi Otomasyonu: Siteye PDF Koyup İşi Bitirdiğini Sananların Kaybettiği İspat Zinciri

Çoğu satıcı mesafeli satış sözleşmesini bir dosya işi olarak görür. İnternetten bir şablon bulur, firma adını değiştirir, siteye "Mesafeli Satış Sözleşmesi" başlıklı bir sayfa açar ve ödeme adımına bir onay kutusu koyar. Görünürde her şey tamam. Ama bir gün bir iade talebi ya da bir şikâyet dosyası geldiğinde sorulan soru bu değil: o müşteri, o siparişte, hangi metni, hangi tarihte onayladı? Siteye koyduğun sayfa dün gece güncellendiyse, elindeki cevap yok.

Sözleşme otomasyonu tam olarak bu boşluğu kapatır. Amaç güzel bir metin yayınlamak değil, her sipariş için o anın koşullarıyla üretilmiş, bir daha değişmeyen bir kopya oluşturup onu siparişe bağlamaktır. Doğru kurgulanmış bir e-pin satış scriptinde bu iş tamamen arka planda döner; satıcı hiçbir şey yapmaz, buna karşılık ihtilaf anında elinde kusursuz bir zincir bulunur. Bu yazıda o zinciri dijital ürün satışına özgü koşullarla birlikte kuruyoruz.

Sözleşmeyi siteye asmak neden yetmez?

Statik bir sayfa üç noktada çöker. Birincisi kişiselleştirme: geçerli bir sözleşmede alıcının bilgileri, sipariş konusu ürün, bedel, ödeme şekli ve teslim yöntemi yer alır. Sabit sayfada bunlar yoktur, boş yer tutucular vardır. İkincisi zaman: bugün yayındaki metin, altı ay önceki siparişin metni değildir; sayfayı her güncellediğinde geçmişi de değiştirmiş olursun. Üçüncüsü ispat: onay kutusunun işaretlendiğine dair bir kayıt tutmuyorsan, kutunun varlığı tek başına bir şey anlatmaz.

Otomasyon bu üç sorunu tek hamlede çözer. Sipariş oluşturulduğu anda şablon, o siparişin gerçek verileriyle doldurulur; üretilen belge bir dosya veya kayıt olarak dondurulur; onay anına ait teknik iz belgeye bağlanır. Böylece elinde sayfa değil, siparişe ait bir nüsha olur. Bir dijital ürün satış yazılımında bu mimari, sözleşmeyi yönetim panelinden bağımsız bir varlık haline getirir.

Dijital üründe cayma hakkı neden başka işler?

E-pin, lisans anahtarı, oyun içi kod gibi ürünler fiziksel mallardan farklı bir kategoride durur: elektronik ortamda anında ifa edilen ve tüketiciye anında teslim edilen hizmet ve gayri maddi mallar. Mevzuat bu kategoride cayma hakkının kullanılamayacağını öngörür — ancak bu istisnadan yararlanmanın bir şartı var: tüketiciyi önceden ve açık biçimde bilgilendirmek. Bilgilendirmeyi atlayan satıcı istisnayı da kaybeder.

Pratikte bu şu anlama gelir: ödeme adımında, kodu göstermeden önce, ayrı ve görünür bir ifade bulunmalı. "Kod teslim edildikten sonra cayma hakkının kullanılamayacağını biliyor ve onaylıyorum" gibi bir beyan, genel sözleşme onayının içine gömülmemeli; kendi başına durmalı. Ve en kritik nokta: teslim anı kayıt altına alınmalı. Kodun hangi saniyede görüntülendiği ya da gönderildiği, istisnanın devreye girdiği andır. Otomasyonun bu damgayı atmaması, bütün kurgunun en zayıf halkası olur.

Ön bilgilendirme formu ile sözleşme aynı şey değil

Sık yapılan bir hata, iki belgeyi tek metinde birleştirmektir. Oysa bunlar farklı işlevlere sahiptir. Ön bilgilendirme formu, tüketici daha ödeme yapmadan neyi hangi koşulla satın aldığını anlaması için vardır; bir teklif ve şeffaflık belgesidir. Sözleşme ise siparişin kurulmasıyla doğan karşılıklı yükümlülükleri düzenler. Biri karar öncesi, diğeri karar sonrası.

Otomasyonu kurarken bu ayrımı akışa yansıtmak gerekir: ön bilgilendirme, ödeme butonunun üstünde erişilebilir olmalı ve içeriği sepetteki gerçek ürünlerle dolmalı; sözleşme ise onay anında üretilip kilitlenmeli. İkisini tek dosyada birleştirdiğinde, tüketicinin ödeme öncesi bilgilendirildiğini gösteremezsin — çünkü belgenin doğum anı ödemeden sonradır. Bu ince ayrıntı, denetimlerde sık sık ayırt edici olur.

Otomasyon ne demek: her siparişe donmuş bir nüsha

Teknik olarak kurulum sade. Şablonu veritabanında sürüm numarasıyla tut. Sipariş oluşurken şablonu al, yer tutucuları gerçek verilerle doldur, çıkan metni siparişin kendi kaydına yaz ya da dosya olarak üret ve yolunu sipariş satırına bağla. Şablonu sonradan değiştirdiğinde eski siparişler etkilenmez, çünkü onların nüshası bağımsızdır. Bu tek karar, sözleşme tarafındaki risklerin büyük bölümünü kapatır.

Onay tarafında ise üç alan yeterlidir: hangi şablon sürümü onaylandı, hangi tarih-saatte onaylandı, hangi oturumdan onaylandı. Bunlara ek olarak kullanıcının hangi beyanları ayrı ayrı işaretlediğini de sakla — sözleşme, ön bilgilendirme ve cayma istisnası ayrı kalemler olsun. Bir e-pin yazılımında bu yapı kurulduğunda satıcının yapacağı tek iş kalır: şablonu güncel tutmak. Metnin son halini bir hukukçuya doğrulatmak yine gerekir; otomasyon içeriğin doğruluğunu değil, tesliminin ve ispatının kusursuzluğunu sağlar.

İhtilaf anında hangi kanıtı masaya koyarsın?

Bir talep geldiğinde ideal senaryo şudur: sipariş numarasını panele yazarsın, karşına o siparişe ait dört şey çıkar — imzalanmış nüsha, onay izi, teslim damgası, gönderim kaydı. Bu dördü bir arada olduğunda anlatılacak hikâye tamdır: müşteri neyi onayladı, ne zaman onayladı, ürün ne zaman teslim edildi, bilgilendirme ne zaman gönderildi. Eksik halka varsa boşluğu doldurmak için tahmine ve ekran görüntüsüne kalırsın.

Bu zincirin en çok atlanan parçası gönderim kaydıdır. E-postanın gönderildiğine dair bir iz tutmuyorsan, "bilgilendirme yapıldı" savunması havada kalır. Panelinde her siparişin altında gönderim zamanı ve alıcı adresi görünsün; teslim edilemeyen e-postalar ayrı bir listeye düşsün. Bu liste aynı zamanda iyi bir müşteri hizmetleri aracıdır: adresi yanlış yazan müşteriyi sen fark eder, o şikâyet yazmadan çözersin.

Kurulum sırası ve kontrol listesi

Otomasyonu kurarken sıralama önemli: önce şablonları sürümlü hale getir, sonra sipariş akışına bağla, sonra onay izini yaz, en son teslim ve gönderim damgalarını ekle. Tersten başlayıp damgalarla uğraşmak, nüsha üretimi olmadığı için bir işe yaramaz. Aşağıdaki liste, bir e-pin satış yazılımında sözleşme tarafını uçtan uca kapatmak için maddeleri sırasıyla veriyor.

Listenin sonuna geldiğinde elinde sadece hukuki bir zırh değil, operasyonel bir rahatlık da olur: iade tartışmaları kısalır, ödeme itirazlarında sunacak belgen olur, yeni bir çalışanı işe alırken "bu kısımda hiçbir şey yapmıyorsun" diyebilirsin. Otomasyonun gerçek değeri, sana düşünmen gereken bir konuyu daha bir daha düşünmemek üzere kapatmasıdır.

Sözleşme otomasyonu, kurulduktan sonra varlığını hiç hissettirmeyen ama ihtiyaç anında her şeyi değiştiren sistemlerden biridir. Nüsha üretiminin, onay izinin ve teslim damgasının gerçek bir sipariş akışında nasıl göründüğünü adım adım izlemek istersen canlı demo üzerinden bir test siparişi oluşturabilir, sonra özellik listesine ve paketlere bakabilirsin.