Stok Kod Havuzu Yönetimi: Elde Kalan Son Kodu Fark Edebiliyor musunuz?

Bir e-pin sitesinde en pahalı hata, yanlış fiyat vermek değil; satılan bir kodun aslında elde olmamasıdır. Müşteri ödemeyi yapar, "teslimat" ekranı açılır, ama sistem boş bir havuzdan kod çekmeye çalışır. O saniyede güven de, sipariş de, çoğu zaman müşteri de gider. Stok kod havuzu yönetimi, bu senaryoyu görünmez kılmanın adıdır — ve tam da görünmez olduğu için, çoğu satıcı sorunu ancak büyüdükten sonra fark eder.

Stok kod havuzu tam olarak nedir, neden bu kadar hassastır?

Stok kod havuzu, bir ürünün (örneğin 50 TL'lik bir oyun kartı ya da 60 UC paketi) satışa hazır, henüz kimseye verilmemiş tüm kodlarının tutulduğu listedir. Her satışta bu listeden bir kod çekilir, "kullanıldı" olarak işaretlenir ve bir daha asla verilmez. Kulağa basit gelir ama işin püf noktası tam burada: aynı anda birden fazla müşteri aynı ürünü satın almaya çalıştığında, sistemin iki kişiye aynı kodu vermemesi gerekir.

Bu durum yazılım dilinde "yarış durumu" (race condition) olarak bilinir ve stok havuzu yönetiminin en kritik açığıdır. Kod havuzu şu üç şeyi aynı anda garanti etmelidir:

• Her kod yalnızca bir kez satılabilir, aynı saniyede gelen iki siparişte bile.
• Tükenen ürün anında "stokta yok" durumuna geçmeli, satın alma butonu kapanmalı.
• İade veya iptal edilen bir sipariş varsa, kodun tekrar havuza dönüp dönmeyeceği net kurallara bağlı olmalı.

Bu üç madde birlikte sağlanmadığında ortaya çift satış, hayalet stok ya da sonsuz "tükendi" hatası gibi sorunlar çıkar. Yani stok havuzu sadece bir liste değil, aslında bir trafik kontrol sistemidir.

Elle kod takibi neden er ya da geç patlar?

Küçük ölçekte, günde birkaç sipariş varken, Excel tablosuna kod girip elle "kullanıldı" yazmak işe yarar gibi görünür. Ama bu yöntemin kırılma noktası hacimle değil, eşzamanlılıkla gelir. İki müşteri aynı dakikada sipariş verdiğinde, tabloyu güncelleyen kişi ikisine de aynı kodu göndermiş olabilir — çünkü tablo, aynı anda iki işlemi kilitleyip sıraya sokamaz.

Elle takibin diğer zayıf noktaları şunlardır:

• Kod eklerken kopyala-yapıştır hatası (fazladan boşluk, eksik karakter) müşteriye geçersiz kod gönderilmesine yol açar.
• Hangi tedarikçiden hangi partinin geldiği karışır; bir sorun çıktığında "bu kod hangi API'den geldi" sorusuna cevap vermek saatler alır.
• Gece siparişi gelirse, ekip uyurken stok kontrolü de durur — sabah açılana kadar sistem "var" gibi görünen ama aslında olmayan ürünü satmaya devam eder.
• Bayilere ayrı ayrı kod tahsis etmek, ayrı tablo, ayrı takip, ayrı hata riski demektir.

Kısacası elle takip, düşük hacimde "şimdilik" çalışır ama satış arttıkça riskin büyüme hızı, ekip büyüme hızını fersah fersah geçer.

Tükenen bir stok, kaç müşteriyi birden kaybettirir?

Bir ürünün stoğu tükendiğinde asıl kayıp, o anki satış değildir. Asıl kayıp, müşterinin "bu site bazen yanlış teslimat yapıyor" düşüncesiyle bir daha geri dönmemesidir. E-pin gibi güven odaklı bir sektörde, tek bir kötü deneyim onlarca iyi deneyimi siler. Aşağıdaki tablo, manuel takip ile otomatik havuz yönetiminin pratikte nasıl ayrıştığını gösteriyor:

Buradaki fark sadece teknik değil, ticari bir farktır. Stoğu doğru yöneten bir site, kampanya dönemlerinde ürünü agresif şekilde satabilir; çünkü sistemin "hayır" demesi gerektiğinde gerçekten hayır dediğinden emindir.

Pinova stok havuzunu perde arkasında nasıl işletiyor?

Pinova'da her ürün, kendi kod havuzuna bağlıdır ve bu havuz iki kaynaktan beslenebilir: sizin elle yüklediğiniz statik kodlar (örneğin toplu satın aldığınız bir parti) ya da Turkpin, Pinabi gibi tedarikçi API'lerinden anlık çekilen dinamik stok. İkisi de aynı satış akışına dahil olur, müşteri için fark yoktur — sistem hangisi uygunsa oradan kodu çeker.

Sipariş anında işleyiş şöyledir:

• Ödeme onaylandığı anda ilgili ürünün havuzundan bir kod "rezerve" edilir, aynı kod başka bir işleme açılmaz.
• Statik havuzda kod kalmadıysa, tanımlıysa API kaynağına otomatik geçilir; o da boşsa ürün anında satışa kapanır.
• Teslim edilen her kod, hangi siparişe, hangi kaynağa ve hangi zamana ait olduğu bilgisiyle birlikte loglanır — bir anlaşmazlık çıktığında "bu kodu biz mi verdik" sorusu saniyeler içinde cevaplanır.
• Stok eşiği tanımlanabilir: örneğin bir üründe 5 kod kaldığında panelde uyarı çıkar, siz daha "tükendi" yazısını görmeden yeni parti yükleyebilirsiniz.

Bu yapının asıl değeri, sizin manuel olarak "acaba stok yeterli mi" diye kontrol etme ihtiyacınızı ortadan kaldırmasıdır. Sistem sizin yerinize sürekli sayıyor.

Bayi ağınız aynı havuzdan beslenirken çakışma nasıl önlenir?

Çok seviyeli bayi sistemi olan bir e-pin sitesinde stok yönetimi bir kat daha karmaşıklaşır. Artık sadece son müşteri değil, kendi müşterilerine satış yapan bayiler de aynı havuza erişiyordur. Burada iki ayrı sorun birden ortaya çıkabilir: bayilerden biri havuzu tek başına tüketebilir, ya da iki bayi aynı kodu farklı müşterilerine "satmış" gibi görünebilir.

Pinova'nın bayi sisteminde stok, merkezi havuzdan pay edilir; bayiye özel ayrı bir "gizli stok" tutulmaz, herkes aynı gerçek zamanlı havuzdan kod çeker. Bu sayede:

• Bir bayi büyük hacimli sipariş verse bile, havuzdaki gerçek stok anlık olarak güncellenir; başka bir bayi tükenmiş bir üründen satış yapamaz.
• Bayi bakiyesi ile stok kontrolü aynı işlemde doğrulanır — bakiye yetersizse ya da stok yoksa sipariş hiç oluşmaz, yarım kalmaz.
• Her bayinin kendi satış geçmişi, hangi kodu hangi tarihte kime verdiği ile birlikte ayrı ayrı raporlanır; komisyon hesaplamaları da bu kayıtlara dayanır.

Böylece bayi sayınız artsa da stok tutarlılığı bozulmaz — sistem herkese aynı anda "gerçek" sayıyı gösterir.

Stok tükenmeden önce fark etmenin bir yolu var mı?

İyi bir stok havuzu yönetiminin nihai amacı, tükenmeyi engellemek değil (bu bazen kaçınılmazdır), tükenmenin sizi şaşırtmamasıdır. Bunun için birkaç pratik alışkanlık işe yarar:

• En çok satan 5-10 ürün için düşük stok bildirimini aktif tutun; panel veya e-posta üzerinden anlık uyarı almak, gece yarısı "tükendi" mesajlarından çok daha ucuzdur.
• Tedarikçi API'sine bağlı ürünlerde, API tarafında da bir sorun (bakiye yetersizliği, bağlantı kopması) olabileceğini unutmayın — Pinova bu durumu ayrı bir hata kodu olarak işaretler, "stok yok" ile "tedarikçi erişilemiyor" birbirine karışmaz.
• Kampanya öncesi, o ürünün geçmiş 30 günlük satış ortalamasına bakıp havuzu kampanya süresine göre önden besleyin.
• İptal/iade politikanızı net tanımlayın: bir kod iade edildiğinde otomatik olarak havuza geri mi dönsün, yoksa manuel onay mı gereksin? Bu tercih, hem güvenlik hem stok doğruluğu açısından önemlidir.

Bu alışkanlıklar, sistemin sağladığı otomasyonu tamamlayan insan tarafıdır — yazılım sayıyı doğru tutar, siz de o sayının anlamını doğru okursunuz.