Bir müşteri ürün sayfasına gelir, istediği seçenek tükenmiştir ve alışverişi tamamlayamaz. “Stok gelince haber ver” alanı yardımcı olabilir; ancak bu düğme tek başına ne zaman ve hangi ürün için bildirim gönderileceğini açıklamaz. İşletme, müşterinin yalnızca haber mi istediğini, yoksa ön sipariş ya da stok ayırma mı yaptığını baştan ayırmalıdır. Nişantaşı Eticaret Sitesi başlıklı bu rehber, belirli bir işletmenin stok durumuna dair iddia içermez. E-ticaret projesinde, tükenmiş ürünün tam seçeneği için isteğe bağlı stok bildirimi akışının nasıl tanımlanacağını ele alır.

Stok bildirimi, ön sipariş ve satın alma ayrı durumlar olsun

Önce müşterinin yaptığı işlemi doğru adlandırın. “Stokta olduğunda haber ver” isteği, normalde satın alma, ödeme, ürün ayırma veya teslim tarihi taahhüdü değildir. Ön sipariş ise ürün henüz hazır değilken sipariş kabul edilen farklı bir ticari karardır. Hazır stoktan satın alma da üçüncü bir durumdur. Düğme, açıklama ve sonraki e-posta aynı anlamı taşımalıdır; müşterinin iletişim bilgisi bırakması yanlışlıkla sepet veya sipariş kaydı oluşturmamalıdır.

Bu ayrım, ön sipariş akışıyla stok ve teslim beklentisini anlatan rehberdeki sipariş taahhüdü konusundan farklıdır. Bildirim akışında işletme önce ürünün yeniden satışa açılıp açılmayacağını ve “stok geldi” bilgisinin hangi sorumlu tarafından doğrulanacağını belirler. Ürün satıştan kalkmışsa veya tedarik kararı belirsizse, kesin bir geri dönüş sözü veren düğme koymak doğru beklenti kurmaz.

İstek ürünün adına değil, seçilen varyanta bağlansın

Aynı ürünün farklı rengi, bedeni, kapasitesi veya paketi bulunabilir. “Ürünü haber ver listesine ekle” ifadesi, hangi seçeneğin beklendiğini kaydetmiyorsa müşteri yanlış bildirim alabilir. Önce seçim arayüzünde ürün kimliğiyle varyant kimliğinin nasıl ayrıldığını belirleyin. Müşteri lacivert, orta beden seçeneğini işaretlediyse, bildirim isteği de o varyantı izlemelidir. Tek başına ürün adı veya kategori adı yeterli değildir.

Seçenek henüz seçilmediyse, müşteriden varyant seçmesini isteyin ya da yalnız bütün ürün yeniden satışa açıldığında geçerli olacak bir ürün düzeyi isteği olduğunu açıkça anlatın. İşletme bu iki yaklaşımın hangisini desteklediğini teknik çalışma başlamadan kararlaştırmalıdır. Seçenek adları ürün sayfası, bildirim formu ve e-posta içinde tutarlı kalmalı; varyant yeniden adlandırılır veya kaldırılırsa eski isteğin ne olacağı ayrıca düşünülmelidir.

“Stok geldi” olayının ne zaman oluştuğunu tanımlayın

Depoya bir ürünün ulaşması ile internet mağazasında satışa hazır olması aynı an olmayabilir. Sayım, kalite kontrolü, ürün kaydı, fiyat güncellemesi veya sevkiyat hazırlığı bekleniyor olabilir. Bu nedenle tetikleyici, “bir kutu geldi” gibi belirsiz bir olay yerine işletmenin gerçekten satışa açtığı duruma dayanmalıdır. Hangi envanter kaynağının doğru kabul edildiği, hangi çalışan ya da sistemin yayına alma kararını verdiği ve satılabilir miktar çok düşükse nasıl davranılacağı yazılı olmalıdır.

Satılabilir miktarın hangi kayıttan hesaplandığını ele alan stok senkronizasyonu rehberi, bu teknik arka planı ayrı bir kapsamda inceler. Buradaki karar ise o miktar değiştiğinde hangi müşteri isteğinin bildirime dönüşeceğidir. Birden fazla depo veya satış kanalı varsa, işletme hangi stok havuzunun bu ürünü hangi müşteriye sunabileceğini netleştirmeden herkese aynı “hazır” mesajını yollamamalıdır.

Bildirim metni satın alma beklentisi yaratmasın

Formun hemen yanında, e-posta adresi verildiğinde ne olacağını sade biçimde açıklayın: hangi ürün veya seçeneğin izleneceği, hangi durumda haber gönderileceği ve bu talebin ürün ayırmadığı. Mesaj, bildirim geldiğinde ürünün hâlâ bulunacağı garantisini vermemelidir; stok değişebilir ve başka bir müşteri satın alabilir. İşletme rezervasyon sunuyorsa bunu ayrı bir işlem, kurallar ve arayüz olarak tasarlamalıdır.

Formu kısa tutun, isteğin ne zaman açıldığını doğrulayın

Akış yalnız gerekli iletişim alanlarını istemeli. E-posta veya tercih edilen başka kanalın kullanılıp kullanılmayacağına işletme karar verir; kanalı desteklemeyen bir altyapı, formda varmış gibi sunulmamalıdır. İstek kaydedildikten sonra müşteriye hangi ürün seçeneğini izlediğini gösteren kısa bir onay verin. Onay mesajı “siparişiniz alındı” dememeli; “stok bildirimi isteğiniz kaydedildi” gibi doğru durumu anlatmalıdır.

İşletme, bu iletişim kaydına kimlerin eriştiğini ve talep artık geçerli olmadığında ne yapılacağını kendi veri yönetimi ve bilgilendirme süreçleriyle birlikte belirlemelidir. Gereksiz adres, telefon veya sipariş detayı toplamaya ihtiyaç olup olmadığını sorgulayın. Hukuki uyum veya saklama süresi hakkında varsayım yapmayın; bu kararlar güncel işletme politikasına ve uygun uzman görüşüne göre doğrulanmalıdır.

İstek yaşam döngüsünü çalışanların anlayacağı biçimde kurun

Bir istek oluşturulduğunda yalnız bir e-posta listesine satır eklenmiş olmaz. Ürün yeniden satışa açılabilir, bekleme süresi boyunca değişebilir, kalıcı olarak kaldırılabilir veya müşteri artık haber istemeyebilir. Her durum için sorumlu bir rol ve anlaşılır bir durum belirleyin: bekliyor, bildirildi, müşteri isteği kapattı ya da ürün artık sunulmuyor. Bu adlar örnek bir iş modelidir; kullanılacak durumlar işletmenin gerçek akışına göre seçilmelidir.

Aynı kişi aynı varyant için birkaç kez form gönderirse sistemin yeni bir kayıt mı açacağı, mevcut isteği mi güncelleyeceği önceden belli olmalıdır. Tekrar gelen tıklamayı sessizce kaybetmek veya aynı kişiye art arda çok sayıda e-posta yollamak da istenmeyen sonuç yaratabilir. Tekrar gönderimde aynı isteğin tanınması, bildirimin bir kez gönderildiğinin kaydı ve başarısız iletişim durumunun izlenmesi kabul testine eklenebilir. E-posta iletildi görünüyorsa bile müşterinin onu gördüğü varsayılmamalıdır.

Az miktar ve eşzamanlı sipariş senaryolarını ayrıca deneyin

Stok bildirimi gönderildiği sırada ürünün tamamı başka siparişlerle tükenebilir. Bu nedenle mesajı hazırlayan akış, satın almayı garanti eden bir rezervasyon gibi sunulmamalıdır. İşletme çok sınırlı miktarda ürünü aynı anda kaç kişiye bildireceğini, bildirimlerin hangi sırayla gönderileceğini ve stok tekrar sıfırlanırsa müşterinin hangi bilgiyi göreceğini kararlaştırabilir. Teknik uygulama, bu iş kararını değiştirmemeli veya sessizce “herkese gönder” varsaymamalıdır.

Farklı varyantların aynı anda satışa açıldığı bir durumda da bildirimler ayrıştırılmalıdır. Bir bedenin gelmesi diğer bedeni bekleyen kişiye mesaj göndermemelidir. Ürünün fiyatı ya da tanımı değişmişse eski isteğin yeni ürünle otomatik eşleşip eşleşmeyeceği sorulmalıdır. Güvenilir akış, her olayı ürün ve varyant kimliğiyle kaydeder; belirsiz eşleşmede mesaj göndermemeyi veya işletme onayı istemeyi değerlendirir.

Ürün geri gelmezse sessizce açık istek bırakmayın

Tedariki iptal edilen veya satıştan kaldırılan ürün için bekleyen istekler süresiz açık kalmamalıdır. Ürünün artık sunulmayacağı işletme tarafından doğrulanırsa, bildirimin kapanışını ve gerekiyorsa müşteriye gönderilecek açıklamayı planlayın. Mesajda yerine başka bir ürünün otomatik önerilmesi, müşterinin seçtiği ürünün aynı kaldığını varsaymak olur. Alternatif ürün gösterilecekse seçim müşteriye bırakılmalı; beden, teknik uyum veya kullanım farkı açık olmalıdır.

Bekleyen taleplerin ne zaman ve kim tarafından kapatılacağını belirleyin. Sonuç bulunmadığında sonraki adımı sunma rehberi, bulunmayan ürünü keşfetmeyi ayrıca inceler. Arama ve stok bildiriminin durumlarını karıştırmayın.

Yayına çıkmadan önce durum tablosuyla uçtan uca sınayın

Proje ekibi birkaç örnekle beklenen sonucu önceden yazabilir. Örneğin: ürün tükenmiş ve varyant seçilmişken form açılmalı; varyant seçilmemişken yanlış ürün isteği kaydedilmemeli; aynı kişi aynı istek için tekrar tıkladığında belirlenen davranış uygulanmalı; satışa açılan bir varyant için yalnız ilgili kişiler bilgilendirilmeli. Bildirim gönderimi başarısız olursa kayıt kayboluyor mu, tekrar deneme ikinci mesajı oluşturuyor mu, müşteri isteğini kapattığında sistem bunu dikkate alıyor mu diye kontrol edin.

Sonra sipariş yolunu bağımsız deneyin: bildirimi alan kişi bağlantıya tıkladığında stokta olmayan ürün yeniden satışa açılmış gibi görünmemeli. Fiyat, seçili varyant ve sepet özeti o anki ürün verisiyle uyuşmalıdır. Ürün geri gelmezse bekleyen kayıtlar nasıl kapanır? Çok düşük miktarda satışa açılırsa bildirim akışının durumu nedir? Bu sorular teknik teslim listesinde açıkça yanıtlanmalıdır. Bu akışı e-ticaret yazılımı hizmeti görüşmesinde altyapıyla birlikte değerlendirin.

Sık sorulan sorular

Stok bildirimi isteyen müşteri ürünü satın almış sayılır mı?

Hayır. Sadece bir stok bildirimi isteği kaydetmek, kendi başına satın alma, ödeme veya stok rezervasyonu değildir. Arayüz bunu açıkça söylemeli ve sipariş alındı mesajı üretmemelidir. İşletme bir ön sipariş veya rezervasyon sunmak istiyorsa, müşteriden aldığı taahhüt ve sipariş durumları ayrı tasarlanmalıdır. Bildirim e-postası geldiğinde ürün hâlâ satın alınabilir olmayabilir; müşteri güncel ürün sayfasında gerçek durumu yeniden görmelidir.

Bildirim isteği ürünün tamamına mı, seçeneğine mi bağlanmalı?

Ürün farklı beden, renk, kapasite veya paketlerden oluşuyorsa çoğu durumda hangi seçeneğin beklendiğini kaydetmek daha açıklayıcıdır. İşletme tüm ürün tekrar açılınca haber verilecek bir ürün düzeyi listesi sunabilir; fakat bunun seçeneğe özel olmadığı form metninde anlaşılmalıdır. İstek, seçilen ürün ve varyantla eşleşmelidir.

Stok sayısı değişince hemen bildirim göndermek doğru mudur?

Bu, ürünün hangi aşamada gerçekten satışa açıldığına bağlıdır. Fiziksel ürün depoya gelmiş olsa da sayım, kalite kontrolü veya ürün kaydı tamamlanmamış olabilir. İşletme hangi durumu “satılabilir” kabul ettiğini belirlemeli ve tetiklemeyi o kayda bağlamalıdır. Stok senkronizasyonu farklı sistemlerde miktarın nereden geldiğini etkileyebilir; envanter kaynağını doğrulamadan gelen her artışı müşteriye haber olarak sunmayın.

Bildirim müşteriye ürün ayırır mı?

Stok uyarısı yalnızca haber verme işlevindeyse ürün ayırmaz. E-postada bunu net belirtin; müşterinin ürünü satın alabilmesi için ürün sayfası ve sepet güncel stokla yeniden kontrol edilmelidir. Rezervasyon isteniyorsa bu farklı bir iş kuralı, süre ve sistem davranışı gerektirir. Mevcut mağaza bu özelliği doğrulamadan bildirim mesajına “sizin için ayrıldı” ya da benzeri bir söz eklemeyin.

Ürün geri gelmeyecekse açık istekle ne yapılmalı?

Ürün artık sunulmayacaksa işletme, bekleyen isteğin kapanma durumunu ve müşteriye açıklama yapılıp yapılmayacağını belirlemelidir. Sessizce başka bir ürüne yönlendirme veya aylarca beklemede bırakma, müşterinin seçtiği ürünle ilgili beklentiyi açık bırakır. Alternatif önerilecekse müşterinin bunu seçmesine izin verin ve ürünler arasındaki farkı doğru anlatın. Kapanış sorumlusu ve durum değişikliğinin kaydı da proje planında yer almalıdır.

Aynı kişi aynı ürün için birkaç kez başvuru yaparsa ne olmalı?

Tekrar gönderim geldiğinde sistemin aynı isteği güncellemesi mi yoksa yeni istek açması mı gerektiğine işletme karar vermelidir. Karar varyantı, iletişim kanalını ve bildirim sıklığını dikkate almalıdır. Aynı olay iki kez işlendiğinde mükerrer e-posta veya hatalı liste oluşuyor mu diye test edin. Gönderim hatasında yeniden deneme yapılacaksa, denemenin önceki gönderimle ilişkisi kayıtlı olmalıdır. Bu işlem bir satın alma ya da rezervasyon yaratmamalıdır.

Bildirim kaydı için hangi bilgileri istemek gerekir?

Önce bildirimi göndermek için hangi iletişim bilgisinin gerçekten gerekli olduğunu belirleyin. Ürün ve varyant kimliği, istek zamanı ve talebin durumunu takip etmek iş akışında yararlı olabilir; adres veya telefon gibi başka bilgiler gerekmeyebilir. Hangi bilginin ne kadar süre tutulacağı ve kimlerin göreceği işletmenin bilgi yönetimi ve güncel bilgilendirme politikasına göre belirlenmelidir. Hukuki saklama süresi veya uyum garantisi varsaymayın.

Stok bildirimi çalışıyor diye bütün e-ticaret akışı test edilmiş olur mu?

Hayır. Bildirim isteğinin kaydedilmesi, e-posta akışı, varyantın satışa açılması ve gerçek sipariş/ödeme işlemi birbirinden ayrı senaryolardır. Bildirim bağlantısından sonra ürün fiyatı, varyantı, stok durumu ve sepet özetini ayrıca deneyin. Ayrıca stok tekrar tükenirken eşzamanlı sipariş, ürünün satıştan kaldırılması ve gönderim hatası gibi durumları kabul tablosuna ekleyin. Bir testte başarılı görünmesi diğer ödeme, kargo veya iade akışlarını doğrulamaz.