Bir e-ticaret mağazasında hediye kartı veya mağaza bakiyesi sunmak, yalnızca ürün listesine yeni bir satır eklemek değildir. Alıcı ile ödeyen kişi farklı olabilir; kodun kime ve ne zaman ulaştığı, bakiyenin nerede görüldüğü, kısmi kullanımda ne olacağı ve müşteri desteğinin hangi sipariş kaydına bakacağı baştan anlaşılmalıdır. Bunlar netleşmediğinde hediye alan kişi kullanacağı bilgiyi bulamaz, mağaza ekibi de ödeme, teslim ve kullanım sorularını birbirinden ayıramaz.

Levent eticaret sitesi planında bu yazının odağı, dijital dosyanın teslimi değil, mağazada harcanmak üzere tanımlanan hediye değerinin satın alma ve kullanım akışıdır. Bu farkı, indirilebilir ürün teslimi rehberindeki dosya erişimi konusuyla karıştırmayın. Fiziksel hediye seti, genel indirim kuponu ve abonelik de ayrı ürün ve operasyon kararlarıdır. Çok alıcılı fiziksel hediye seti rehberi adres, paket ve mesaj hazırlığını ele alır; burada ise dijital değer kodunun işleyişi anlatılır. Önce işletmenin bu ürünü gerçekten sunup sunmayacağını, hangi müşteri ihtiyacına cevap verdiğini ve bu sürecin kim tarafından yönetileceğini tanımlayın.

Hediye kartını indirim kuponundan ayırın

Kupon çoğunlukla ürün veya sepet fiyatını belirli bir kurala göre düşürür. Hediye kartı ise alıcının daha sonra kullanabileceği bir değer ya da ödeme aracı olarak düşünülür. İki mekanizmayı aynı adla duyurmak, müşterinin ne satın aldığını anlamasını zorlaştırır. Ürün kartında “hangi alışverişte kullanılabilir?”, “alıcıya ne teslim edilir?” ve “ödeme sırasında nasıl kullanılır?” sorularını sade biçimde yanıtlayın. Uygulamanızda gerçek bir bakiye tutulmayacaksa “bakiye” sözcüğünü kullanmayın; ürünün sunduğu işlevi doğru adlandırın.

Ödeyen kişiyi ve alıcıyı ayrı alanlarda düşünün

Hediye kartında satın alan kişi ile kartı kullanacak kişi aynı olmayabilir. Sipariş özeti bu iki rolü tek bir “müşteri” alanına sıkıştırırsa hediye mesajı yanlış kişiye gidebilir veya alıcı satın alma bildirimiyle karşılaşabilir. İşletmenin ihtiyaç duyduğu kadar bilgi toplayın: kartı alan kişi, alıcının teslim bilgisi ve isteğe bağlı kısa not. Her alanın neden istendiğini arayüzde açıklayın; alıcı adına hesap açılmasını veya kişisel bilgilerin zorunlu verilmesini varsayılan kural yapmayın.

Alıcı bilgisinin daha sonra değiştirilebilip değiştirilemeyeceğini de işletme kararı olarak yazın. Değişikliğe izin verilecekse kimlik doğrulama ve yanlış adrese gönderim durumlarını ekip belirlemelidir. Bu kararlar hazır değilse ilk sürümde akışı sınırlı tutmak, kontrolsüz bir özellik sunmaktan daha anlaşılır olabilir. Tasarım ve yazılım tesliminde bu tercihin açıkça belirtilmesi gerekir.

Ürün sayfasında satın alınan şeyin kapsamını anlatın

Ürün açıklaması yalnız tasarım rengi ve tutar seçeneğinden oluşmamalı. Kartın hangi mağazada kullanılabileceğini, alıcının ne alacağını, teslimin nasıl yapılacağını ve kullanımın hangi ekranda başlayacağını müşterinin karar vereceği yerde anlatın. Mağaza belirli ürün gruplarını hariç tutuyorsa, birden fazla adrese veya çevrim içi dışı kanallara kullanım düşünülüyorsa, bu koşulları ekip onaylamadan vaat etmeyin.

Kodun üretilmesi ve teslim durumunu görünür kılın

Satın alma tamamlandığında siparişin ödeme durumu ile hediye kartının hazırlanma ve alıcıya gönderilme durumu aynı şey değildir. İşletme bu adımları kendi operasyonuna uygun adlarla izlemelidir: sipariş alındı, ödeme kontrol ediliyor, kart hazırlandı, teslim bildirimi gönderildi gibi. Bu örnek adlar zorunlu bir teknik akış değildir; önemli olan ekibin hangi kaydı hangi aşamada güncelleyeceğini kararlaştırmasıdır.

Kod veya bağlantı, ödeme onayından önce kullanıma açılmamalı; fakat onaydan sonra da sessizce kaybolmamalıdır. Müşterinin sipariş detayında, alıcının iletisinde ve destek ekibinin görünümünde aynı ürün referansı bulunabilir. Kodun e-posta ile gönderilmesi seçilmişse teslimat başarısızlığı için yeniden gönderim yolu düşünülmelidir. Sistemin mesaj gönderdiğini varsaymak yerine, mağazanın görebildiği teslim sonucunu tanımlayın.

Ödeme ekranında kart kullanımını anlaşılır yapın

Alıcı alışveriş sırasında kodu nerede gireceğini, kullanımın hangi toplamı etkilediğini ve işlem sonunda ne kadar değer kaldığını anlayabilmelidir. Kod alanı yalnız sepetin en altına saklanırsa müşteri kartın desteklenip desteklenmediğini ödeme adımına kadar öğrenemeyebilir. Ürün, sepet ve ödeme ekranındaki açıklamalar aynı kullanım sınırlarını anlatmalıdır. Kod kabul edilmediğinde “hata oluştu” gibi genel bir ifade yerine, müşteriye bir sonraki kontrol adımını söyleyen bir mesaj tasarlayın.

Kısmi kullanım önemli bir ürün kararıdır. Kartın tek alışverişte tamamen harcanması mı, kalan değerin sonraki siparişe taşınması mı isteniyor? Bakiye takibi işletmenin sorumluluğuna girecekse, kalan tutarın müşteri tarafından nasıl görüleceği ve destek ekibinin hangi kayıttan doğrulayacağı belirlenmelidir. Böyle bir özellik sunulmayacaksa ürün açıklaması bunu örtük bırakmamalıdır. İşletme kararı olmadan kartın süresi, kullanım sayısı veya başka koşulları hakkında kesin vaat eklemeyin.

İade ve iptal senaryolarını karttan ayrı değerlendirin

Hediye kartı satışı, kullanılmış kartla alınan sipariş ve henüz kullanılmamış sipariş birbirinden farklı durumlar yaratır. İşletme; ödeme iptali, teslim gerçekleşmeden vazgeçme, kartın kısmen kullanılması ve kartla ödenen ürünün iadesi için nasıl işlem yapacağını önceden incelemelidir. Burada tek bir doğru politika varsaymak yerine, mağazanın koşullarını ilgili uzmanlarla doğrulayıp arayüzde anlaşılır biçimde sunması gerekir. Bu yazı hukuki veya muhasebesel görüş yerine geçmez.

Kişisel mesajı operasyonel bilgiden ayırın

Hediye notu, alıcının kullanacağı kod veya sipariş durumu değildir. Mesaj alanı isteğe bağlı tutulabilir; uzunluk sınırı ve gönderim önizlemesi belirlenebilir. Notta hassas bilgi istenmemesi gerektiği sade biçimde açıklanmalı, ekip mesajı değiştirecekse bunun kapsamı önceden kararlaştırılmalıdır. Kartı satın alan kişinin yazdığı metni işletme adına verilmiş resmi bir açıklama gibi göstermeyin.

Alıcıya giden e-posta veya bildirimde ürünün ne olduğu, nasıl kullanılacağı ve sorun halinde hangi kanala başvurulacağı yer almalıdır. Gönderici adı, konu satırı ve destek adresi satın alma teyidinden ayırt edilebilir olsun. Alıcı hesabı açılmamışsa, kullanım bilgisi sadece oturum açmış kullanıcıya gösterilemeyecek şekilde planlanmalıdır. İşletmenin teslim edeceği metinler, yazılım tamamlandıktan sonra sonradan doldurulacak boşluklar gibi bırakılmamalıdır.

Destek ekibi için kayıp kod ve bakiye başvurusu hazırlayın

Kod silinmiş, e-posta yanlış klasöre düşmüş veya ekranda kalan değer beklenenden farklı görünmüş olabilir. Destek ekibinin başvuruyu doğrulamak için isteyeceği bilgiler ile paylaşmaması gereken kod parçalarını işletme belirlemelidir. Tam kodu herkese açık yazışmada istemek yerine sipariş numarası, alıcı veya ödeme referansı gibi işletmenin güvenli bulduğu verilerle kayıt arama yöntemi tasarlanabilir. Hangi bilginin doğrulama için yeterli olduğuna işletme karar vermelidir.

Yeniden gönderim, kartı devre dışı bırakma veya yeni kod üretme gibi işlemler varsa, bunların kim tarafından ve hangi koşulda yapılacağı tanımlanmalıdır. İki farklı çalışan aynı başvuruyu incelerken kartın durumunu yanlışlıkla değiştirmemelidir. Bu nedenle teknik taslakta sadece ön yüz değil, müşteri hizmetleri ekranı ve işlem kaydı da değerlendirilir. Önce operasyonu tanımlama yaklaşımı için e-ticaret yazılımı seçimi rehberine bakabilirsiniz. Kullanıcıya verilen yanıt, kartın mevcut durumuyla tutarlı olmalıdır.

Yayından önce farklı alıcı ve kullanım durumlarını deneyin

Kabul provası tek bir başarılı ödeme ile bitmemeli. İşletme önce kartı kendine alan kişiyi, başka alıcıya gönderen kişiyi, teslim mesajı ulaşmayan alıcıyı ve satın alma öncesi kullanım koşullarını arayan kişiyi ayrı ayrı canlandırabilir. Sonra tam ve kısmi kullanım, geçersiz kod, yetersiz tutar, iptal başvurusu ve iade edilen alışveriş durumlarını test listesine ekleyin. Her senaryoda ürün sayfası, sepet, ödeme, e-posta, sipariş kaydı ve destek ekranında hangi bilginin görünmesi gerektiğini yazın.

Test verileri gerçek müşteriye mesaj göndermemeli ve canlı kartları kullanmamalıdır. Örnek kartlar işletmenin kontrolünde tutulmalı, deneme bittiğinde durumları açıkça işaretlenmelidir. Kabulde bir kişinin deneyimi değil, görev listesi kullanılabilir: doğru alıcı, doğru mesaj, beklenen teslim, anlaşılır hata açıklaması ve ekipçe görülebilen işlem durumu. Eksik senaryolar varsa canlıya çıkış kararını ertelemek veya ürün kapsamını daraltmak işletmenin tercihidir. Benzer son kabul kontrolünü e-ticaret yayın testi rehberindeki sipariş senaryolarıyla birlikte düşünebilirsiniz.

Hizmet görüşmesinde sınırları ve sorumluları netleştirin

Levent eticaret sitesi projesinde ürün tanımı, tutarlar, kullanım koşulları, teslim metinleri, iade kararı ve destek sorumlusu hazır mı diye sorun. E-ticaret yazılımı hizmetinin kapsamını bu akışa göre inceleyin. Hizmet kapsamı tasarım, ürün sayfası, sepet ve ödeme akışının geliştirilmesini içerebilir; hediye ürünün işletme adına hangi ticari koşullarla sunulacağı ise ayrıca kararlaştırılır. Kullanılacak altyapının hazır özellikleri doğrulanmadan özellik varmış gibi teklif verilmemelidir.

İlk teslim için gerçekçi bir örnek akış seçin: işletme kontrollü bir hediye kartı satın alınır, alıcıya gönderilir, alıcı test sepetinde kodu kullanır ve ekibin sipariş kaydında sonucu görülür. Bu örnekte bulunmayan bir işlevi paket içinde varsaymayın. Kapsamın sahibi, içerik onayı veren kişi ve teknik kabulü yapan kişi baştan belirlenirse revizyon isteği ile yeni özellik talebi birbirinden ayrılır.

Sık Sorulan Sorular

Hediye kartı ile indirim kuponu aynı şey midir?

Hayır. Kupon genellikle fiyatı bir kampanya kuralına göre düşürür; hediye kartı ise alıcının daha sonra kullanacağı bir değer olarak tasarlanabilir. Mağazanızın sunduğu işlev farklıysa, ürün adını ve açıklamasını bu işlevi doğru anlatacak şekilde seçin. İki akışı aynı indirim alanına bağlamadan önce ekip ve yazılım kapsamını doğrulayın.

Hediye kartını alan ve satın alan kişi farklı olabilir mi?

Bu, mağazanın ürün kuralına bağlıdır. Farklı olacaksa sipariş formunda alıcı teslim bilgisi ile ödeyen kişinin bilgisini ayırın ve her alanın neden istendiğini açıklayın. Alıcı adına hesap açmayı otomatik zorunluluk yapmayın; teslim ve kullanım biçiminin hesap gerektirip gerektirmediğini teknik tasarım sırasında netleştirin.

Kartın tutar seçeneklerini kim belirlemeli?

İşletme belirlemelidir. Sabit tutarlar, özel tutar girişi veya tek seçenek kullanımı satış modeline bağlıdır. Özel giriş sunulacaksa kabul edilecek alt ve üst sınır, para birimi, hatalı giriş mesajı ve muhasebe takibi önceden kararlaştırılmalıdır. Bu bilgiler ürün kartı, sepet ve sipariş özetinde aynı görünmelidir.

Alıcı kartı kısmen kullanabilir mi?

Kısmi kullanım ancak mağaza bunu destekleyecek bakiye takibi ve sonraki siparişte gösterim yolunu hazırlarsa sunulmalıdır. Kalan tutarın hangi kayıtta tutulacağı, müşterinin bunu nasıl göreceği ve destek ekibinin nasıl doğrulayacağı tanımlanır. Bu akış yoksa ürün açıklamasında kısmi kullanım sözü vermeyin.

Kartın geçerlilik süresi veya kullanım koşulu nasıl yazılmalı?

İşletme kendi ürün ve politika kararını ilgili uzmanlarla doğruladıktan sonra koşulları satın alma öncesinde açıkça belirtmelidir. Hazır bir şablondan süre veya istisna kopyalamak yerine mağazanın gerçekten uygulayacağı kuralı yazın. Kesinleşmemiş koşullar yayın metninde vaat gibi görünmemelidir.

Kod müşteriye ulaşmazsa mağaza ne yapmalı?

Önce siparişin ödeme ve teslim durumları birbirinden ayrılmış mı kontrol edin. Destek ekibi sipariş referansıyla gönderim kaydını bulabilmeli; yeniden gönderimin kim tarafından yapılacağını işletme belirlemelidir. Müşteriden tam kodu herkese açık mesajda istemek yerine, işletmenin güvenli doğrulama yöntemini kullanın.

İade edilen üründe hediye kartı kullanılmışsa ne olur?

Bu durum mağazanın iade politikası, ödeme kayıtları ve kartın kullanım modeline göre değerlendirilmelidir. Kullanılmamış kart, kısmen harcanmış kart ve kartla alınmış ürün için ayrı senaryo yazın; mağaza koşullarını hukuki veya muhasebesel uzmanla doğrulayın. Tek ve genelleyici bir yanıtı bütün siparişlere uygulamayın.

Yayından önce hangi testler yapılmalı?

En azından farklı alıcı bilgisi, başarılı teslim, ulaşmayan bildirim, tam ve kısmi kullanım kararı, geçersiz kod, iptal ve destek başvurusu senaryolarını kontrol edin. Her adımda müşterinin gördüğü mesajla ekip panelindeki kayıt eşleşmeli. Testler gerçek müşteriye e-posta göndermeyen kontrollü örnek kartlarla yapılmalıdır.