Küçük ekipler için stok doğruluğu: kullanılabilir, rezerve, satıldı

Küçük ekiplerin stok doğruluğunda neden zorlandığı

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:

• Sipariş verirler, sonra iptal e-postası alırlar.
• Öderler, sonra gönderemediğinizi fark edince iade için beklerler.
• Ne olduğunu ve paralarının ne zaman geri geleceğini sormak için destekle iletişime geçerler.
• Güvenlerini kaybederler ve geri gelmeyebilirler.

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.

Kullanılabilir vs rezerve vs satıldı: basit tanımlar

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:

• Eldeki stok: 5
• Rezerve: 2 (iki müşteri kasada)
• Satıldı: 1 (bir ödeme tamamlandı)
• Kullanılabilir: 2 (5 eksi 2 eksi 1)

Üç 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 nasıl hareket eder: temel yaşam döngüsü

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:

• Kullanılabilir -> Rezerve: müşteri kasaya başladığında (veya "Öde"ye tıkladığında) ve ürünü onlar için tutmaya karar verdiğinizde oluşturulur.
• Rezerve -> Satıldı: yalnızca ödeme onaylandığında (veya offline ödemeyi kabul ettiğinizde) gerçekleşir.
• Rezerve -> Kullanılabilir: checkout terk edildiğinde, ödeme zaman aşımına uğradığında veya müşteri ödeme yapmadan önce iptal ettiğinde olur.

"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:

• Kasaya giriş sistemi rezervasyon oluşturabilir ve sınırlı süreyle uzatabilir.
• Ödeme onayı rezerveyi satıla dönüştürebilir.
• Yönetici (admin) rezervasyonu iptal edebilir, iade yapabilir (bu gerçekten stok iadesi değilse: satıldı -> kullanılabilir ancak gerçek stok restock edilirse), veya yeni birimler geldiğinde stoğu düzeltebilir.

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.

Kasada rezervasyonu ne zaman oluşturmalı

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:

• Kasaya başlarken ("Kasaya Git"e tıklandığında): hızlı satan ürünler için en iyisidir, ama kısa süreli sona erme süreleri gerekir.
• Adres adımından sonra: sahte tutmaları azaltır ve ödemeden önce korunmayı sağlar.
• Ödeme başlarken (ödeme intent'i oluşturduğunuzda veya sağlayıcıya yönlendirdiğinizde): genellikle en temiz noktadır çünkü "ödeme sürüyor" gerçek bir taahhüttür.
• Ödeme başarılı olduktan sonra: alışveriş deneyimi için en güvenli, ama fazla satış riski en yüksek olanıdır.

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.

Adım adım: stok rezervasyonu ve fazla satışı önleme

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ış:

1. Sayım için gerçeğinizi seçin. "Eldeki stok"u gerçek fiziksel stok olarak takip edin. Ardından "kullanılabilir"i ya saklanan bir sayı olarak güncelleyin ya da hesaplanan bir sayı olarak tanımlayın: eldeki stok eksi rezerve.
2. Alışveriş yapan taahhüt ettiğinde rezervasyon oluşturun. Bunu "Öde"ye tıkladıkları noktada (veya ödeme intent'i oluşturduğunuzda) yapın; sepete ekleme anında değil. Çok erken yapılan rezervasyonlar asla satın almayan tarayıcılar için stok kilitler.
3. Rezervasyon oluştururken kullanılabilirliği hemen azaltın. "Kullanılabilir"i saklıyorsanız, rezervasyon oluşturma işlemiyle birlikte onu eksiltin. Hesaplıyorsanız, bir rezerve kaydı ekleyin ve matematik işi yapsın.
4. Ödeme onaylandığında rezerveyi satıla dönüştürün. Rezervasyonu "satıldı" olarak işaretleyin (veya bir sipariş satırı oluşturun) ve eldeki stoku azaltın. Bu, öğeyi geri döndürülemez olarak kabul ettiğiniz andır.
5. Hata veya zaman aşımında rezervasyonu serbest bırakın. Ödeme başarısız olursa, süresi dolarsa veya alışveriş yapan sayfayı kapatırsa, rezervasyonu "serbest" yapın ve birimleri tekrar kullanılabilir hale getirin.

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ını temizce yönetmek

Ö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:

• Rezervasyonu açıkça expires_at zaman damgası ile saklayın
• Her 1–5 dakikada bir zaman aşımına uğramış rezervasyonları bulacak zamanlanmış bir iş çalıştırın
• "Rezerve"den "kullanılabilir"e miktarları taşıyarak stoğu serbest bırakın
• Kasayı/siparişi "süresi doldu" olarak işaretleyin ki daha sonra müşterilere destek verebilesiniz
• Zaman aşımı sayımlarını kaydedin ki süreyi ayarlayabilesiniz

Ö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 ve envanteri senkronize tutmak

Ö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:

• Envanter güncellemelerini idempotent yapın: aynı "ödeme onaylandı" olayı iki kez işlenirse, ikinci seferde hiçbir değişiklik olmasın.
• Rezervasyonu bir kez ve sadece bir kez "satışa dönüştürüldü" olarak işaretleyin, o sipariş kimliği için.
• Müşteri yeni kartla yeniden denese bile her ödeme denemesini aynı sipariş kimliği altında kaydedin.
• Rezerve edilenin satıla taşınması sadece net, nihai bir ödeme sonucu aldığınızda olsun (yetkilendirildi ve yakalandı gibi, ya da sizin işiniz için "nihai" ne ise o tanım).

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.

Fazla satışa neden olan yaygın hatalar

Ç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:

• Checkout'tan önce stok rezerve etmek, böylece stok tarayıcılar tarafından kilitlenir, alıcılar tarafından değil.
• Süre sonu eksikliği, eski rezervasyonların birikmesi ve kullanılabilirliğin küçülmesi.
• Birden fazla sistemin sayımları değiştirmesine izin vermek (admin düzenlemeleri, toplu içe aktarımlar, iadeler) ve durumların nasıl hareket ettiğine dair tek bir kural olmaması.
• Bir yerde "satıldı"yı "ödendi", başka bir yerde "gönderildi" anlamında karıştırmak.
• Bir rezervasyonu neden serbest bıraktığınızı kaydetmemek; bu destek sorunlarını zorlaştırır.

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.

Değişiklikleri yaymadan önce hızlı kontrol listesi

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:

• Checkout sadece rezerve edilmiş öğeleri vaat ettiğinden emin olun, sadece sepette oturanları değil.
• Rezervasyon oluşturmanın atomik olduğundan emin olun (iki kişi aynı anda son ürünü rezerve edemesin).
• Ödeme onayı rezerveyi tam olarak bir kez satıla dönüştürsün (retry ve webhooklar için idempotent işleme).
• Rezervasyon süresi dolduktan sonra ödeme geç gelirse ne olacağını tanımlayın: onaylayacak mısınız, iptal mi edecek, yoksa backorder mı olarak mı işaretleyeceksiniz? Bir kural seçin ve her zaman uygulayın.
• Zaman aşımı yolunu uçtan uca test edin: rezervasyon süresi doluyor, envanter kullanılabilir hale dönüyor ve müşteri net bir mesaj görüyor.

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.

Destek zaman çizelgesi üç soruyu yanıtlamalı

• Rezervasyon ne zaman oluşturuldu ve ne zaman sona erdi?
• Ödeme ne zaman başarılı veya başarısız oldu, ve bu süre sonundan önce mi sonra mı?
• Stok ne zaman serbest bırakıldı veya satıldı olarak kaydedildi, ve bu hangi sistem olayıyla yapıldı?

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.

Örnek: iki müşteri, bir son ürün

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.

• Alışveriş yapan B'nin gördüğü: "Stokta yok" veya "Şu an kullanılamıyor."
• Destek/yönetim gördüğü: Kullanılabilir 0, Rezerve 1 (A için tutuluyor), Satıldı 0.

12:03:10 - Alışveriş yapan A'nın ödemesi başarılı olur.

Rezervasyonu satışa dönüştürürsünüz:

• Satıldı 1 olur.
• Rezerve 0 olur.
• Kullanılabilir 0 olarak kalır çünkü fiziksel stok kalmadı.

Ş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.

• Sayılar Kullanılabilir: 1, Rezerve: 0, Satıldı: 0 olur.
• Alışveriş yapan B şimdi kasaya gidebilir ve B için yeni bir rezervasyon oluşturabilirsiniz.

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:

• Rezervasyon süresi dolduysa öğeyi satıldı olarak işaretlemeyin. Siparişi "inceleme gerektiriyor" olarak koyun ve müşteriye iade yapın veya tekrar sipariş vermesini isteyin.
• Eğer B için yeni bir rezervasyon varsa, öncelik B'dedir çünkü aktif tutma B üzerindedir.

Bu tek kural fazla satışları önler ve destek kararlarını öngörülebilir kılar.

Sonraki adımlar: kuralları basit bir sisteme dönüştürün

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.

Basit, pratik bir temel

Çoğu ekip aşağıdaki beş işlemi omurga olarak kullanarak idare eder:

• Rezerve et: belirli bir sepet veya sipariş için tutma oluştur
• Serbest bırak: müşteri iptal ettiğinde veya zaman aşımı geldiğinde tutmayı kaldır
• Satışa dönüştür: ödeme onaylandığında rezervasyonu kesinleştir
• Güvenli başarısızlık: emin değilseniz satıldı olarak işaretlemeyin
• Uzlaştır: nadir uyumsuzlukları manuel veya zamanlanmış kontrollerle düzelt

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.

Hızlı kurun, sonra güçlendirin

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.