Küçük ekipler için stok doğruluğu, net stok durumlarıyla başlar. Kullanılabilir, rezerve ve satıldı arasındaki farkı öğrenin ve fazla satışları önlemek için ödeme zaman aşımı temizliği uygulayın.

Küçük bir mağaza işletiyorsanız veya sınırlı ürünler gönderiyorsanız, stokun basit olması gerekir gibi gelir: rafta ne varsa sayarsınız ve onu satarsınız. Yine de fazla satışlar (oversell) olur, hatta sayılarınız doğru olsa bile.
Ana neden zamanlamadır. "Sayımınız" 10:00:00'da doğru olabilir, ama 10:00:05'te yanlış olabilir; çünkü aynı son birim için iki kişi satın almaya çalıştı, ödeme yavaştı ya da kasada ödeme sürerken bir çalışan stokta değişiklik yaptı. Küçük ekiplerde bu anlar kolayca kaçırılır çünkü tüm gün kenar durumları izleyen özel bir operasyon personeliniz yoktur.
Stok yanlış olduğunda müşteriler bunu hemen hisseder:
Sizden tarafta ise özür dilemek, iade yapmak, sayımları tekrar kontrol etmek ve destek taleplerini cevaplamak gibi yoğun işler yaratır. Bu yüzden küçük ekipler için stok doğruluğu mükemmel sayımdan çok "stokta" ne ifade ettiğine dair açık kurallarla ilgilidir.
Temel fikir, stoku tek bir sayı olarak görmek yerine birkaç açık durum olarak ele almaktır. "Kullanılabilir" şu anda neyi vadedeceğinizi gösterir. "Rezerve" biri ödemeyi bitirmemiş ama tutulan bir ürünü gösterir. "Satıldı" ise ödemenin yapıldığını ve fulfillment yapılması gerektiğini gösterir.
Bu rehber basit, pratik kurallara bağlı kalır: maddelerin bu durumlar arasında nasıl hareket ettiği, ne zaman rezerve edileceği ve ödeme zaman aşımı durumunda stokun takılı kalmaması veya çift satılmaması için ne yapılacağı. Karmaşık tahminleme, depo düzenleri veya çok lokasyonlu planlama ele alınmaz.
Bu üç kelime basit etiketler gibi görünür ama müşteriye verdiğiniz üç farklı sözü temsil eder. Karıştırırsanız ya fazla satış yaparsınız (iki kişi aynı ürünü öder) ya da gereğinden az satarsınız (satılabilecek stoku gizlersiniz).
Kullanılabilir demek "bir müşteri şu anda bu ürün için kasaya başlayabilir" demektir. Bu, eldeki stokunuzun başkası için taahhüt edilmemiş kısmıdır. Bunu halka açık sayınız gibi düşünün.
Rezerve demek "bu ürünü kısa bir süre için belirli bir müşteri için tutuyoruz" demektir. Bir rezervasyon genellikle alışveriş yapanın niyetini gösterdiği anda (örneğin kasaya başladığında) oluşturulur. Rezerve edilen stok henüz satılmış değildir, ama çifte satışı önlemek için geçici olarak diğerlerine kapalı tutulur.
Satıldı demek "satın alma doğrulandı" demektir. Bu noktada ürünü güvenle artık satışa sunulamaz sayabilirsiniz. Birçok mağazada "satıldı", ödeme başarılı olduğunda (veya güvendiğiniz bir sonradan ödemeye izin verdiğinizde) başlar ve gönderim gerçekleşene kadar devam eder.
Bir önemli nokta: kullanılabilir, eldeki stokla aynı değildir. Eldeki stok fiziksel olarak sahip olduğunuz şeydir. Kullanılabilir ise yeni alıcılara vaat etmeye istekli olduğunuz miktardır.
Küçük bir örnek, eldeki stok 5 birim:
Üç sayının da aynı anda doğru olabileceğine dikkat edin. Sadece "eldeki stok"u takip ederseniz, siteniz 5 gösterebilir ve beş kişi satın almaya çalışabilir, oysa güvenle sadece iki daha gönderebilirsiniz.
Stok, "sayım" tek bir sayı olarak ele alındığında karışır. Küçük ekipler için stok doğruluğunu sağlamak adına, basit bir yol izleyen durumlar düşünün. Her durum farklı bir soruyu cevaplar: biri hala satın alabilir mi, bir checkout için mi tutuluyor yoksa satış kesinleşti mi.
Tipik yaşam döngüsü şu şekildedir:
"Satıldı", gerçek bir taahhüt yaptığınız an olmalıdır. Birçok kurulumda bu, fiziksel stok sayısını azaltacağınız andır, çünkü ürün artık sizin satabileceğiniz bir ürün değildir. Daha sonra gönderiyorsanız (küçük ekiplerde yaygın), yine de "satıldı"yı nihai kabul edebilir ve gönderimi ayrı takip edebilirsiniz. Anahtar: bir müşteri sadece ödeme sayfasına ulaştığı için bir ürünü satıldı olarak işaretlemeyin.
Her durum değişikliğini kim yapabileceği konusunda katı olun:
Son olarak, durum değişiklikleri her yerde aynı görünmelidir. Mağaza ön yüzü, yönetici paneli ve müşteri destek görüntüsü aynı envanter durum kurallarını okumalı; aksi halde bir yerde fazla satışı düzelttiğinizde başka bir yerde yeniden yaratabilirsiniz.
Rezervasyonu ne zaman oluşturduğunuz, ne sıklıkla fazla satış yapacağınızı ve ne sıklıkla müşterileri hayal kırıklığına uğratacağınızı belirler. Çok erken bir rezervasyon, sadece göz atanlar için öğeleri "tutar". Çok geç bir rezervasyon ise aynı son ürünü iki kez satma riskini artırır.
Çoğu küçük ekip için işe yarayan basit bir kural: müşteri kasaya girişle taahhüt verdiğinde rezerve edin; ürün sayfasını açtıklarında değil.
Yaygın seçenekler, en erken olandan en geç olana:
Ne seçerseniz seçin, her rezervasyon yalnızca onu uygulamak için gereken bilgileri saklamalıdır: ürün (SKU), miktar, bir sepet veya sipariş kimliği, kimin yaptığı (oturum/kullanıcı) ve bir sona erme zamanı. Ayrıca neden veya aşama (checkout, ödeme) bilgisini saklayın ki destek daha sonra ne olduğunu anlayabilsin.
Çok maddeli sepetler ekstra bir karar gerektirir: her şeyi aynı anda mı rezerve edeceksiniz yoksa öğe başına mı? Öğesine göre rezerve etmek genellikle daha güvenlidir. Bir öğe stok dışı olursa yalnızca o öğenin tutarını serbest bırakabilirsiniz; tüm sepeti engellemek zorunda kalmazsınız.
Tutarı basit bir dille görünür kılın. "Bu ürünleri kasayı tamamlarken 10 dakika tutuyoruz" gibi küçük bir not yeterlidir. Son üründe doğrudan olun: "Sadece 1 kaldı. 15:42'ye kadar sizin için tutuluyor." Bir sayaç yardımcı olabilir ama mesajınız netse zorunlu değildir.
Eğer akışı Koder.ai içinde kuruyorsanız, "rezerve"yi birinci sınıf bir adım (API çağrısı + veritabanı satırı) olarak ele alın ki UI ve backend her zaman neyin tutulduğunda anlaşsın.
Küçük ekipler için stok doğruluğu istiyorsanız, sistemi sıkıcı ve öngörülebilir yapın. Anahtar hangi sayının ne anlama geldiğine karar vermek ve bunu yalnızca bir yerde değiştirmektir.
Başlarken tek bir gerçek kaynağı seçin. Bu bir veritabanı tablosu veya tüm kasaların çağırması gereken tek bir servis olabilir. Tablolar, yönetici düzenlemeleri ve iki sistemde yapılan "hızlı düzeltmeler" fazla satışların doğduğu yerlerdir.
Çoğu mağaza için işe yarayan basit akış:
Son olarak, her durum değişikliğini zaman, neden ve kimliklerle (sepet, ödeme, sipariş) kaydedin. Müşteri "neden stokta yoktu?" diye sorduğunda, destek ekibinin tahmin değil net bir zaman çizelgesi göstermesi gerekir. Bu akışı bir uygulamada (örneğin Koder.ai ile) oluşturuyorsanız, bu durumları ve günlükleri birinci sınıf veri olarak ele alın, sadece UI etiketleri olarak değil.
Ödeme zaman aşımı, bir checkout'ın tamamlanmasını ne zaman beklemeyi bırakacağınız ve rezerve edilen stoğu tekrar "kullanılabilir"e geri vereceğiniz noktadır. Bazı alışveriş yapanlar ödemeyi tamamlamaz; zaman aşımı olmazsa rezerve edilen stok büyür ve gerçek alıcılar engellenir veya manuel düzeltmeler gerekir.
Zaman aşımını, ödeme sağlayıcınızla gerçekte neler olduğuna göre seçin. Kart ödemeleri genellikle hızlı onaylanır, ama 3D Secure, banka yönlendirmeleri ve cüzdan işlemleri daha uzun sürebilir. Çok kısa bir zaman aşımı stoğu müşterinin hâlâ ödeme yaparken serbest bırakmanıza, çok uzun bir zaman aşımı ise ayrılmış stoğu mağazayı terk edenler için tutmanıza neden olur. Birçok küçük mağaza için 10–20 dakika makul bir başlangıçtır; günlüklerinize göre ayarlayın.
Bir müşteri sekmeyi kapatmış veya bağlantıyı kaybetmişse hiçbir şey varsaymayın. Ödeme arka planda yine de gerçekleşebilir veya hiç başlamamış olabilir. Bu yüzden envanter sistemi tarayıcıya bağlanıp "ne oldu" dememelidir.
Temizliği otomatik hale getirin ki siparişleri elle takip etmeyin. Basit bir yaklaşım, eski rezervasyonları sona erdiren periyodik bir temizleme işi çalıştırmaktır:
Ödeme zaman aşımından sonra ödeme geç gelirse ne yapacağınızı önceden kararlaştırın. Mükemmel bir cevap yoktur, ama tutarlı bir kuralınız olmalı. Yaygın seçenekler: ödeme sadece stok hâlâ varsa kabul edilir (aksi halde otomatik iade), veya sağlayıcınız ilerlemede olduğunu kanıtlayabiliyorsa rezerveyi uzatmak.
Küçük ekiplerde anahtar, zaman aşımlarını öngörülebilir, otomatik ve görünür kılmaktır, böylece "rezerve" kara delik olmaz.
Ödeme sistemleri her zaman tek ve temiz bir "ödendi" mesajı göndermez. Aynı onayı iki kez alabilir, gecikmeli bir webhook görebilir veya müşterinin bitirdiğini düşündüğü anda yakalanan bir capture birkaç dakika sonra gelebilir. Envanter güncellemeleriniz buna hazırlıklı değilse, aynı birimi iki kez satabilirsiniz.
En basit dayanak, tüm hikayeyi takip eden tek bir sipariş kimliğidir: rezervasyon, her ödeme denemesi ve nihai satış. Herhangi bir şey olduğunda önce sipariş kimliğine bakın, sonra ne yapılacağına karar verin.
Stok doğruluğunu karmaşıklaştırmadan koruyan birkaç kural:
Idempotent kelimesi tekrar etmek güvenlidir demektir. Bunu bir bilete damga vurmak gibi düşünün: ilk damga önemli, ikinci damga bir şey değiştirmez.
İadeler ve chargeback'ler otomatik olarak öğeyi tekrar kullanılabilir hâle getirmemelidir. Ürün zaten gönderildiyse, envanter satıldı olarak kalmalıdır; muhasebe kısmınız iade gösterir. Sadece ürün gerçekten iade edilip kontrol edildiğinde yeniden stoklayın.
Kısmi yakalamalar ve bölünmüş ödemeler için basit bir politika gerekir. Örneğin: toplam yakalanan miktar sipariş toplamına ulaşana kadar öğeyi rezerve edin, sonra satıldı olarak işaretleyin. Müşteri sadece kısmi ödeme yapıp zaman aşımına uğrarsa, rezervasyonu diğer başarısız check-out'lar gibi serbest bırakın.
Çoğu fazla satış kötü matematikten kaynaklanmaz. Aynı kelimeleri farklı anlamlarda kullanmak veya checkout akışının bir bölümünün envanteri diğerinden farklı şekilde güncellemesiyle oluşur. Küçük ekipler için düzeltmeler genellikle basittir, ama tutarlı olmalıdır.
Yaygın bir hata çok erken rezerve etmektir. Bir ürün sayfasını açtıklarında veya sepete eklediklerinde rezerve ederseniz, gerçekten satın almak isteyenleri, sadece göz atanları veya kesintiye uğrayanları engellersiniz. Rezervasyonlar kasaya başlama veya ödeme oturumu oluşturma gibi net niyetlere bağlanmalıdır.
Bir diğer sızma rezervasyonların hiç süresi olmamasıdır. Günlük birkaç terkedilmiş checkout, satılabilir stokunuzu sessizce tüketebilir. Bir süre sınırı ve bu sınır dolduğunda otomatik serbest bırakma gerekir.
En sık görülen hatalar:
Son madde göründüğünden daha önemlidir. Bir müşteri "ödedim ama stokta yok diyor" dediğinde, ekibinizin bir denetim izine ihtiyacı vardır: ne zaman rezerve edildi, ne zaman serbest bırakıldı ve bunun nedeni ödeme zaman aşımı mı, manuel iptal mi yoksa iade mi?
Basit bir alışkanlık yardımcı olur: stok her değiştiğinde nedeni ve kaynağı (checkout, admin, içe aktarım, destek) kaydedin. Eğer bu akışı Koder.ai içinde kuruyorsanız, bu nedenleri veri modelinize gömün ve tek bir yerde zorlayın ki her özellik aynı kuralları takip etsin.
Yeni checkout veya envanter mantığını yaymadan önce, ekipte herkes her durumun ne anlama geldiğini ekstra kurallar eklemeden söyleyebilmeli. "Kullanılabilir", hâlâ rezerve edilebilecek olan; "rezerve", belirli bir checkout için süresi dolana kadar vaat edilmiş olan; "satıldı" ise ödemesi yapılmış ve kesin olan demektir.
Basit bir stok rezervasyon sistemi zaman ve temizliğe bağlıdır. Rezervasyonların açık bir sona erme zamanı olmalı (örneğin 10–15 dakika) ve süresi dolan tutarı serbest bırakacak bir iş veya tetik olmalı.
Yayın öncesi kontrol listesi:
Destek ekibinin tahmin değil görünürlük ihtiyacı var. Herhangi bir sipariş için durum değişikliklerinin zaman damgalarıyla bir zaman çizelgesini görebilmelisiniz ki anlaşmazlıklar kolayca çözülsün.
Eğer bu mantığı bir kod üreteci veya Koder.ai gibi bir platformda uyguluyorsanız, bu kuralları önce yazın, sonra bunları açık durumlar ve olaylar olarak uygulayın. Bu kenar durumların sonradan sızmasını engeller.
Popüler bir ürünün 1 birimi kaldı. İki müşteri neredeyse aynı anda kasaya giriyor.
12:00:00 - Mağaza Kullanılabilir: 1, Rezerve: 0, Satıldı: 0 gösterir.
12:00:05 - Alışveriş yapan A "Öde"ye tıklar. Sisteminiz 10 dakika süren 1 birimlik bir rezervasyon oluşturur. Ürün sayfası artık pratikte Kullanılabilir: 0 gösterir (çünkü son birim tutuldu), yönetim paneli ise Rezerve: 1 gösterir.
12:00:20 - Alışveriş yapan B aynı ürünü sepete ekler ve kasaya gider.
12:03:10 - Alışveriş yapan A'nın ödemesi başarılı olur.
Rezervasyonu satışa dönüştürürsünüz:
Şimdi sayılar Kullanılabilir: 0, Rezerve: 0, Satıldı: 1 olur. A alıcıya sipariş onayı gider. B hâlâ satın alamaz.
Alternatif son: ödeme zaman aşımı
Aynı başlangıç, ama A ödemeyi tamamlamaz.
12:10:05 - Rezervasyon sona erer (zaman aşımı). Stoku serbest bırakırsınız.
Varyant: ödeme zaman aşımından sonra başarılı gelmesi
Bazen ödeme sağlayıcısı başarıyı gecikmeli bildirir (ağ gecikmesi, gecikmiş onay). Kuralınız basit olmalı: bir rezervasyon sona erdikten sonra onu canlandırmayın. Geç gelen bir "başarılı" raporu A için gelirse şu yapılır:
Bu tek kural fazla satışları önler ve destek kararlarını öngörülebilir kılar.
Küçük ekipler için stok doğruluğu, herkesin aynı kelimeleri aynı anlama gelecek şekilde kullanmasıyla çok daha kolay olur. Kullanılabilir, rezerve ve satıldı tanımlarınızı bir yerde yazın ve mağazanızın müşteriye gösterdiğiyle, destek ekibinin anlattığıyla ve yönetim panelinin gösterdiğiyle uyumlu olduğundan emin olun.
Politikanızı kısa tutun: rezervasyonun ne zaman oluşturulduğuna (örneğin, kasaya başlandığında veya ödeme başladığında) ve stokun ne kadar süre tutulabileceğine karar verin. Zaman aşımı kuralını açık bir dille yazın; müşterinin süresi dolduktan sonra geri gelmesi durumunda ne olacağını belirtin.
Checkout'ta bir şeyi değiştirmeden önce durumları ve geçişleri taslak halinde çizin. Her olaya işaret edebilmeli ve stok üzerinde ne yaptığını söyleyebilmelisiniz.
Çoğu ekip aşağıdaki beş işlemi omurga olarak kullanarak idare eder:
Nadir kenar durumlarını tahmin etmeye yardımcı olması için temel bir gözlemlenebilirlik ekleyin. Her rezerve, serbest bırakma ve satıla dönüştürme olayını sipariş kimliği, neden (zaman aşımı, iptal, ödeme başarı), zaman damgası ve öncesi/sonrası miktarla kaydedin.
Bu akışı hızlıca prototiplemeniz veya ayarlamanız gerekiyorsa, Koder.ai durumları sohbette haritalamanıza, rezervasyon ve zaman aşımı mantığını oluşturmanıza ve dağıtıma hazır kodu dışa aktarmanıza yardımcı olabilir. Önemli olan gösterişli araçlar değil; kuralları net ve tutarlı hale getirip bunları checkout'ın dokunduğu her yerde zorlamaktır.