Gelir Hunisinin Görünmez Aşaması: Ödemeler Nerede Kaybolur?

Bir müşteri ödeme yapmak isteyebilir, ancak bu niyet henüz kesinleşmiş gelir değildir. Ürün bu ara adımları izlemiyorsa gerçek müşteri operasyon ekranından kaybolur.

Gelir hunisi yalnızca ziyaret ve satın almadan ibaret değildir

Birçok SaaS panosu huniyi ziyaret, kayıt, ödeme başlangıcı ve gelir olarak gösterir. Oysa ödeme başlangıcı ile gelir arasında kimlik doğrulama, banka transferi, dekont gönderimi, manuel inceleme veya geçici hata gibi önemli durumlar vardır.

Bu durumlar veri modelinde yoksa satış ekibi müşteriyi potansiyel görür, muhasebe henüz gelir sayamaz ve destek ekibi hangi işlemin gerektiğini bilemez.

Sayaç yerine açık bir durum makinesi kurun

Çözüm yeni bir sayaç eklemek değil, ödeme yolculuğunu açık durumlara ayırmaktır. Stripe PaymentIntent yaşam döngüsünde requires_payment_method, requires_confirmation, requires_action ve succeeded gibi durumları ayrı tutar. Siz de ürününüz için bunların iş karşılıklarını tanımlamalısınız.

Manuel ödeme için örnek akış:

intent_created → instructions_shown → proof_received → awaiting_review → approved → revenue_recorded

rejected, expired ve needs_customer_action yolları da açıkça tanımlanmalıdır. Her kayıt tek bir güncel duruma ve değişiklik geçmişine sahip olmalıdır.

Görünürlük yetmez; kayıt eyleme dönüşmelidir

"Payment pending" satırlarıyla dolu bir tablo sorunu çözmez. Her ara durumda owner, next_action, due_at ve reason alanları bulunmalıdır. Pano "yedi ödeme bekliyor" demek yerine "üç dekont muhasebe incelemesi bekliyor, iki müşterinin banka bilgisine ihtiyacı var ve iki deneme süresi doldu" diyebilmelidir.

"Bugün senden ne bekleniyor?" görünümü de bu mantıktan doğar. Sistem süresi gelen, bir durumda fazla kalan veya yeni kanıt alan kayıtları öne çıkarmalıdır.

Ayrı tutulması gereken metrikler

Payment intent sayısı, alınan dekont sayısı, onaylanan ödeme sayısı ve kayda alınmış gelir dört farklı metriktir. Dönüşüm oranını da aşama aşama ölçün. Bunları birleştirmek görünürdeki büyümeyi gerçek gelirle karıştırır.

İki zamanı saklayın: event_time, yani olayın gerçekten gerçekleştiği an; observed_at ise sistemin olayı gördüğü an. Banka transferi ve geçmiş veri ekleme işlemlerinde bu ayrım kritiktir.

Güvenmeden önce senaryoları test edin

En az şu yolları sahte verilerle çalıştırın: anında başarı, müşteri işlemi gerektiren ödeme, dekont ve manuel onay, dekont reddi, süre aşımı ve hatadan geri dönüş. Hiçbir yolun owner veya next_action olmadan kalmadığını ve gelirin yalnızca nihai durumda arttığını doğrulayın.

Her gün sonunda mutabakat yapın: sağlayıcı veya banka durumu, ödeme kaydı ve gelir defteri birbiriyle uyuşmalıdır. Fark varsa varsayılan bir değerle gizlenmemeli, uyarı üretmelidir.

Kısa cevaplar

Her payment created gelir sayılmalı mı?

Hayır. Ödeme niyeti sürecin başlangıcıdır. Gelir yalnızca nihai durum ve muhasebe politikanız işlemi kesinleştirdiğinde kaydedilmelidir.

Manuel ödeme için en iyi ara durum nedir?

awaiting_review veya proof_received gibi; sahibi, son tarihi ve sonraki adımı olan açık bir durum. Belirsiz ve sahipsiz pending değil.

Sonuç

Görünmez aşama, sistem yalnızca ödemenin başlangıcını ve sonunu gördüğünde oluşur. Durum makinesi, eylem kuyruğu ve günlük mutabakat sayesinde her müşteri ödeme sonucu kesinleşene kadar izlenebilir kalır.

Resmî kaynak

Stripe: PaymentIntent yaşam döngüsü https://docs.stripe.com/payments/paymentintents/lifecycle