E-pin işine girenlerin çoğu “stok” deyince hâlâ fiziksel ürün mantığıyla düşünmeye devam ediyor. Halbuki e-pin’de stok, raf değil; kod havuzu. Ve bu havuzun yönetimi doğru kurulmazsa iş büyüdükçe şu 3 sorun kaçınılmaz olur:
- Kod bitti → satış kaçtı, müşteri sinirlendi.
- Aynı kod iki kez satıldı → itibar darbesi.
- Tedarikçi gecikti → siparişler beklemede, support yanıyor.
Bu yazıda, e-pin stok (kod) yönetimini “temiz” şekilde nasıl kuracağını ve otomasyonla nasıl verimli hale getireceğini net bir çerçeveyle anlatıyorum.
1) E-pin stok yönetimi neden bu kadar kritik?
Dijital ürünlerde teslimat anlık olduğu için müşteri beklemek istemez. Üstelik kod satıldı mı geri dönüş zor. Yani stok yönetimindeki hata, fiziksel üründeki hatadan daha pahalıya patlar.
Hedefimiz şu: Kod stoğu azalmadan önce haber al, tedariki otomatikleştir, satış akışını asla “kör” bırakma ve her adımı izlenebilir kıl.
2) Kod stok yönetiminin temel modeli
Sağlam bir sistemde her kodun bir “yaşam döngüsü” olur:
- AVAILABLE: Satılabilir
- RESERVED: Siparişe ayrıldı (ödeme doğrulanıyor / teslimat hazırlanıyor)
- SOLD: Satıldı ve teslim edildi
- FAILED/EXPIRED: Ödeme iptal/timeout oldu, kod geri havuza döndü (veya iptal edildi)
Altın kural: “Satış” ile “teslimat” arasında mutlaka reservation (kod ayırma) olmalı. Bu, aynı kodun iki müşteriye gitmesini engeller.
3) Kodlar veritabanında nasıl tutulmalı?
Minimumda şunları izleyebilmelisin:
- Kodun bağlı olduğu ürün (ProductId)
- Kaynak/tedarikçi bilgisi (SupplierId)
- Batch / yükleme paketi (BatchId)
- Durum (available/reserved/sold)
- OrderId (hangi siparişe gitti)
- ReservedAt / SoldAt zamanları
Bu kayıtlar sayesinde şu sorulara anında cevap verirsin:
- “Kod nereden geldi?”
- “Hangi siparişe gitti?”
- “Ne zaman satıldı?”
- “Aynı batch’te sorun var mı?”
4) Düşük stok uyarısı: En basit ama en kârlı otomasyon
Düşük stok uyarısı kurmadan e-pin satmak, benzin göstergesi bozuk arabayla uzun yola çıkmak gibi. Minimum iki seviye öneriyorum:
- Warning threshold (örn. 50 kod altı): “stok azalıyor” uyarısı
- Critical threshold (örn. 10 kod altı): otomatik tedarik + yöneticiyi anında bilgilendir
Uyarı kanalları:
- E-posta
- SMS (kritik ürünlerde çok işe yarar)
- Panel bildirimi
- Slack/Teams webhook (ekip varsa)
5) Tedarik otomasyonu: Kod havuzunu “kendini dolduran” hale getirmek
Burada iki ana yaklaşım var:
5.1 Zaman planlı (Scheduled) tedarik
- Saatlik/günlük tedarikçi API’sinden kod çekersin
- Kodlar havuza eklenir
- Satış anında “hazır stok” teslim edilir
Avantaj: Satış anında tedarikçi yavaşlığıyla uğraşmazsın.
Dezavantaj: Bir miktar “stok taşırsın” (dijitalde bu genelde sorun değil).
5.2 Satış anında (Just-in-time) tedarik
- Müşteri öder
- Sistem tedarikçiden anında kod çekmeye çalışır
- Kodu teslim eder
Avantaj: Stok taşımazsın.
Dezavantaj: Tedarikçi API’si yavaşsa sipariş bekler; support yükü artar.
Benim net önerim: Yeni başlayanlar için scheduled model daha “az kriz” çıkarır. Just-in-time ancak API çok stabilse ve iyi bir kuyruk/retry sistemin varsa mantıklı.
6) CSV ile toplu kod içe aktarma (pratik gerçek)
Her tedarikçi API vermez. Bu durumda CSV/Excel ile toplu kod yükleme hayat kurtarır.
Sağlam bir CSV import süreci şunları yapmalı:
- Tekrarlayan (duplicate) kodu yakalamalı
- Hatalı satırları atlayıp raporlamalı
- Batch mantığıyla import etmeli (hangi dosyadan geldi izlenmeli)
- Import sonrası “kaç kod usable” raporu üretmeli
7) Otomatik teslimatta verimlilik: tek akış, çok kanal
Otomasyon sadece tedarik değildir. Teslimat tarafında da standart bir akış kur:
- Ödeme doğrulandı → kod rezervasyonu kesinleştir
- Kodu ekranda göster
- Hesabım/Siparişler ekranına kaydet
- E-posta (opsiyonel SMS) bilgilendirmesi gönder
Bu yaklaşımın verimlilik faydası şu: “mail gelmedi” gibi gereksiz ticket’lar ciddi azalır çünkü müşteri hesabından kodu görür.
8) Otomasyon senaryoları (doğrudan para kazandıranlar)
- Stok azaldı → tedarikçi API’den otomatik çek → batch oluştur → yöneticiyi bilgilendir
- Batch’te hata oranı arttı → o batch’i satıştan otomatik kaldır → incelemeye al
- Belirli saatte talep artıyor (akşam 20:00 gibi) → o saatten önce stok hedefini yükselt
- En çok satan ürün → stok hedefi otomatik büyüsün (dinamik threshold)
- Ödeme başarılı ama teslimat gecikti → müşteriye otomatik bilgilendirme mesajı gönder
9) Performans ve hataya dayanıklılık (büyüyünce kurtarır)
İş büyüdüğünde “tek hata tüm sistemi durdurmasın” diye şu mantıklar şart:
- Queue (kuyruk): Tedarik/teslimat işlerindeki dalgalanmayı dengeler
- Retry: Geçici hatalarda otomatik tekrar dener
- Timeout: Tedarikçi yavaşsa işlemi sonsuza dek bekletmez
- Idempotency: Aynı olay iki kez gelirse tek kez işlenir
10) BerkiTech ile “temiz” stok otomasyonu nasıl görünür?
- Kod havuzu + batch takibi
- Reservation mantığıyla çift satış engeli
- Düşük stok uyarıları + otomatik tedarik senaryoları
- API/CSV esnek tedarik
- Çok kanallı teslimat akışı
SSS
Düşük stok eşiğini nasıl belirlemeliyim?
Basit başla: “Günlük ortalama satış x tedarik süresi (gün) x güvenlik katsayısı”. Örn: günde 30 satış, tedarik 2 gün sürüyor → 30×2×1.5 = 90 gibi.
Stok bittiğinde satış kapatmak mı, siparişi bekletmek mi?
Yeni başlayanlar için satış kapatmak daha temiz. Bekletme modelini ancak süreçlerin çok oturduğunda ve müşteri iletişimini iyi yönettiğinde öneririm.
En çok hata nerede olur?
Duplicate kod yükleme, reservation eksikliği ve tedarikçi gecikmesi. Üçünü çözersen sistemin %80’i rahatlar.
Özet: E-pin’de verimlilik, “daha çok kod yüklemek” değil; stok → tedarik → teslimat zincirini otomasyonla hatasız akıtmak. Bunu kurduğunda hem satış kaçırmazsın hem de support yükün dramatik şekilde düşer.