Kendi Ödeme Sistemini Kurmanın 14 Acısı
(arnon.dk)- Ödeme ve gelir sistemleri gelir elde etmek için vazgeçilmezdir, ancak finans, ürün, müşteri desteği, hukuk, uyumluluk ve satış ekiplerine kadar uzanan karmaşık çekirdek sistemler oldukları için küçük bir aksaklık bile büyük operasyonel sorunlara dönüşebilir
- Erken aşama şirketler veya yeni ürün ekipleri ödemeyi basit bir mühendislik problemi olarak görüp bunu kendileri geliştirmeye yatkındır, ancak gerçekte seçenekler şirket içi geliştirme, üçüncü taraf ve hibrit olarak ayrılır
- Gerçek bir ödeme sistemi aynı anda idempotency, tarih işleme, kullanım ölçümü, vergi, iade, müşteri hiyerarşileri, özel sözleşmeler, fiyat değişiklikleri ve gelir muhasebeleştirmesi ile ilgilenmek zorundadır
- Bazı problemler bir kez çözüldüğünde istikrarlı kalır, ancak vergi kuralları, müşteri hataları, manuel düzeltmeler ve ülkeye özgü fatura gereksinimleri büyüme ve küresel genişlemeyle birlikte sürekli artar
- Ürüne özgü kullanım güncellemeleri ve müşteri yaşam döngüsü olaylarına odaklanıp abonelik, faturalama, muhasebe ve gelir muhasebeleştirmesini mümkün olduğunca hazır ödeme sistemleri ve ERP'ye bırakmak daha güvenlidir
Ödeme neden basit bir özellik değildir
- Ödeme ve gelir sistemleri, bir işin gelir elde edebilmesi için mutlaka gereklidir
- Sorunsuz çalıştıklarında fark edilmezler, ancak gerçekte aynı anda birçok organizasyon ve işlevi etkileyen ahtapot gibi bir sistemdirler
- Finans
- Ürün
- Kullanıcı deneyimi
- Müşteri desteği
- Müşteriler
- Hukuk
- Uyumluluk
- Satış
- Bir parçası bozulduğunda, bağlantılı alanlara da sorunlar hızla yayılabilir; nitekim bu sık olur
- Gelirinizi yasal ve doğru şekilde tahsil edemezseniz, işletmeyi yönetenlerin üstlenmesi gereken sorunlar ciddi biçimde artar
Üç geliştirme deseni
- Ödeme sistemlerinde genellikle üç yaklaşım vardır
- Şirket içi geliştirme
- Tam teşekküllü üçüncü taraf sistem
- Şirket içi geliştirme ile üçüncü tarafı birleştiren hibrit model
- Erken aşama şirketler ya da yeni bir ürün başlatan ekipler, ellerinde mühendis olduğu ve sistemi basit tutmak istedikleri için bunu doğrudan kendileri yapma eğilimindedir
- Ödemeyi “fatura dosyasını S3'e koyup bir CRON işi alır ve tahsilatı yapar” gibi bir problem olarak görmek, ödemeyi yalnızca bir mühendislik problemi sanma yanılgısına yol açar
- Güvenliği ya da tarih işlemlerini baştan sona kendiniz yazmadığınız gibi, ödemeyi de en baştan tamamen kendiniz geliştirmeniz genelde iyi bir fikir değildir
- En iyi ödeme sistemi, tamamını kendiniz yazmak zorunda kalmadığınız sistemdir
Kendi ödeme sisteminizin 14 acısı
-
İdempotency
- Tüm faturalandırma ve ödeme tahsilat talepleri benzersiz ve idempotent olmalıdır
- API limitleri nedeniyle yeniden deneme yaptığınızda veya ödeme sistemi örneklerini artırdığınızda bu sorun görünür hale gelir
- Doğru ele alınmazsa mükerrer faturalandırma riski doğar
-
Tarih işleme
- Her 30 günde bir mi, yoksa her ay abonelik başlangıç gününe göre mi faturalandıracağınızı belirlemelisiniz
- Artık günler ve saat dilimleri gibi koşulları da birlikte ele almalısınız
-
Oranlama ve kalan bakiyeler
- Oranlamayı yalnızca yükseltmelerde mi uygulayacağınızı, yoksa düşürmelerde de kullanıp kullanmayacağınızı belirlemelisiniz
- İade, kredi, yok sayma veya yükseltme/düşürmeyi engelleme gibi seçenekler vardır
-
Kullanım ölçümü
- Kullanımın nasıl hesaplanacağına dair onlarca farklı yöntem olabilir
- Bu yöntemler müşteri tipine göre değişebilir ya da sık sık güncellenebilir
-
Fatura biçimi
- Yalnızca tek bir ülkede faaliyet gösterirken kolay görünebilir
- Ölçek büyüdükçe satış vergisinin yanı sıra KDV, GST ve ülkeye özgü ek yükümlülükleri de ele almak gerekir
- Pazara göre ayrı şablonlar gerekebilir
B2B ve küresel genişlemede büyüyen karmaşıklık
-
Karmaşık müşteri hiyerarşileri
- Özellikle B2B müşteriler, iştirakler ve iş ortaklarıyla birlikte faturalama ilişkilerini yönetmek isteyebilir
- Kullanımı gerçek ödeme yapan tarafa göre birleştiren bir yapıya ihtiyaç duyulur
- Bu talepler çoğu zaman ancak büyüme ve ölçeklenmeden sonra ortaya çıkar
- Müşteri tüzel kişiliği ya da kullanım konumu farklıysa vergiler değişebilir
- Yasal olarak hesap özeti ile faturayı ayırmanız gerekebilir
- İlgili kurallar birkaç ayda bir değişebilir
-
Ödeme tahsilatı ve churn önleme
- Ödeme yeniden denemelerinden ne zaman vazgeçeceğinizi belirlemelisiniz
- Chargeback olduğunda hesabı kapatıp kapatmayacağınıza, askıya alıp almayacağınıza ya da iade yapıp yapmayacağınıza karar vermelisiniz
-
Duraklatma ve yeniden başlatma
- Müşteri aboneliğini duraklattığında hangi seviyede erişim izni verileceğini belirlemelisiniz
-
Krediler ve iadeler
- Yalnızca tam iade yapıyorsanız durum görece basittir
- Kısmi hatalar oluştuğunda kısmi iade ya da mağaza kredisi arasında seçim yapmanız gerekebilir
- Kredilerin son kullanma tarihi olup olmayacağına da ayrıca karar vermelisiniz
Vergiler, sözleşmeler ve insan hatası
-
Vergi işleme
- Farklı kalemlere farklı vergi oranları uygulanması bile tek başına karmaşıktır
- Küresel ölçekte vergi oranları ve vergi kuralları sık sık değişir
-
Özel sözleşmeler
- Yalnızca PLG yapıyorsanız bu bir sorun olmayabilir
- Ancak sözleşme yapmaya başladığınızda, mevcut varsayımlarla kolayca yapılamayan istisnalar ve özel koşullar hızla artar
-
İnsan hatası
- Müşteriler hata yapar ve bunun sonucunda düzeltme gerekir
- Şirket içinde de müşteri ayarları yanlış yapılandırılabilir ve sonradan düzeltilmesi gerekebilir
- Kredi düzenleme ve faturayı yeniden kesme zaman alan işlerdir
- Müşterinin yasal bilgilerinin değişmesi de ele alınmalıdır
- Adres
- VAT ID vb.
-
Seçici fiyat değişiklikleri
- Fiyat değişiklikleri çoğu zaman tüm müşterilere uygulanmaz
- Yalnızca yeni müşterilere uygulanıyorsa, mevcut sözleşmeleri korumak için farklı fiyat sürümlerini birlikte sürdürmek gerekir
-
Gelir muhasebeleştirmesi ve tahakkuk eden gelir
- IFRS-15 gelir muhasebeleştirme kurallarına dair 64 sayfalık PDF spesifikasyonu vardır
- Özel ERP entegrasyonunu da kendiniz yaparsanız karmaşıklık daha da artar
Bir kez biten problemler ve sürekli büyüyen problemler
- Bazı problemler beklediğinizden çok daha sık değişir, bazılarına ise bir kez dokunduktan sonra neredeyse bir daha dönmeniz gerekmez
- İdempotency, bir kez çözüldüğünde nadiren yeniden ele alınan mühendislik problemlerine örnektir
- Vergi kuralları dünya genelinde sık sık değişir
- Faaliyet gösterdiğiniz ülke sayısı arttıkça takip etmeniz gereken vergi mevzuatı da artar
- Müşteri hataları nispeten sürekli yaşanır
- Büyüdükçe ölçeği artar
- Daha fazla müşteri desteği ve manuel düzeltme gerektirir
- Ödeme ilk bakışta bir mühendislik problemi gibi görünse de, gerçekte sektör deneyimi olanlar için bile anlaşılması zor karmaşık bir problem alanına dayanır
Kendiniz geliştirmeniz gerekmeyen alanlar
- Mümkün olduğunca çok ödeme problemini dış sistemlere bırakmak daha iyidir
- Mümkün olan en fazla sayıda hazır çözümü satın alma yaklaşımı önerilir
- Abonelik ve faturalama alanının önemli bir kısmını ödeme sistemleri halledebilir
- Gelir muhasebeleştirmesi ve muhasebeyi, zaten kullandığınız ERP'nin ya da başka sistemlerin yerleşik özelliklerine bırakmak daha iyidir
- Ürün ekipleri yalnızca kullanım güncellemeleri ve temel müşteri yaşam döngüsü olayları gibi ürüne özgü kısımlara odaklanmalıdır
1 yorum
Hacker News yorumları
Faturalandırma kararları vermesi gereken ama fazla deneyimi olmayan biri için iyi bir yazı; deneyimli kişiler için de referans olarak faydalı
Yine de “Faturalandırılacak dosyaları S3’e döküp bir CRON işinin ödemeleri toplamasını sağlayamaz mıyız?” cümlesine epey güldüm. Mühendis kafasıyla bakınca hiçbir koşulda iyi bir fikir değil
Benim sevdiğim faturalandırma mimarisi kararı, sistemde faturalandırmayı ve yetkileri mümkün olduğunca ayırmak. Ön ödemeli aboneliklerde, yetki tarafında yalnızca son kullanma tarihi ve aktif dönem boyunca verilen yetkilerin ayrıntıları tutulup, faturalandırma sistemi aboneliği sakladıktan sonra gerektiğinde yetki tarafına senkronize etsin yaklaşımını faydalı buldum. Böyle olunca bir kişinin manuel faturalandırma yapması, geçici bir sorunu debug edip patch etmesi ya da Stripe entegrasyonu eklemesi de kolaylaşıyor
Elbette gelecekteki genişlemeye kapıyı açık bırakmak gerekir, ama bu kararın kendisi sistemi çok fazla kısıtlamaz. Bu benim özgün fikrim değil, fakat başka yöntemleri daha az başarılı şekilde denedikten sonra özellikle sevmeye başladım
Pek çok sorun ödeme ile faturalandırma arasındaki farktan kaynaklanıyor https://www.wingback.com/blog/saas-payment-vs-saas-billing. İlk müşterileri alırken yalnızca birkaç tekrarlı ödeme almak gerektiğinden Stripe ya da manuel fatura ile başlamak kolaydır
Ancak zaman geçtikçe daha karmaşık yetkiler, birden fazla fiyat planı, mevcut müşterileri koruma, özel faturalandırma döngüleri/koşulları/yetki atamaları gerektiren kurumsal müşteriler giderek gelmeye başlar. Faturalandırma çoğu zaman teknik odağın merkezinde yer almadığı için küçük hack’ler ve ek özellikler birikir; sonunda ürün geliştirme kaynaklarını yiyen, satış hızını düşüren ya da satabileceğiniz ürünleri sınırlayan bir karmaşaya dönüşür
Faturalandırmanın karmaşıklığında pek çok gizli tuzak ve istisna var; bugünlerde çoğu fiyat planı birden çok limit ve kullanım bazlı unsur içerdiği, SaaS da tüm dünyaya satıldığı için bu daha da karmaşık hale geldi. Geç aşama şirketlerde yalnızca faturalandırmayla ilgilenen 15+ kişilik mühendis ekipleri bile var. Ürünün çekirdeği değilse kendi faturalandırma sisteminizi yapmamanız gerektiğine katılıyorum. Not olarak, ben SaaS faturalandırma platformu Wingback’in CTO’suyum
Artık böyle bir sistem kurmak istiyorum ve düşündüğümden çok daha nitelikliymişim gibi hissediyorum
https://arnon.dk/why-you-should-separate-your-billing-from-e...
Müşteri yetkileri bizim sistemimizde saklıyor ve gerektiğinde kontrol ediyor; ödeme sağlayıcı tarafında abonelik yenilendiğinde ya da silindiğinde kurallar ve yetkiler ekleniyor. Bu, bir ya da birden fazla ödeme sağlayıcıyla çalışmayı kolaylaştırıyor ve sorumlulukların ayrımını da netleştiriyor. İlgili yazılar da bu bağlama daha uygun olduğu için paylaşıyorum: https://warrant.dev/use-cases/pricing-tiers-and-entitlements..., https://arnon.dk/why-you-should-separate-your-billing-from-e...
İdeal yetki sistemi dinamik olmalı; yani kurallar veritabanında saklanmalı, kurumsal müşteriler gibi tek seferlik senaryoları işleyebilmeli ve bunun üzerinde bir politika katmanı bulunmalı. Örneğin Pro planı en fazla 5 koltuk, Growth planı belirli bir özelliği günde N kez kullanma gibi neredeyse tüm senaryoları destekleyebilmelidir
Teknik olmayan kişilerin mühendislik müdahalesi olmadan müşteriye özel değişiklikler yapabildiği bir UI da büyük avantajdır. Önceki mühendislik rollerimde bu tür işler her zaman geliştirme ekibinin ayağına dolanırdı
Bir yetki kümesi de var, ama arada yetkilerin ne zaman uygulanıp uygulanmayacağına karar veren bir politika mekanizması bulunuyor. Kilit nokta, yetkinin yalnızca faturalandırmanın konusu olmaması. Politika mekanizması, yetkilerle diğer her şeyi birbirine bağlayan yapıştırıcıdır; böylece en büyük müşteri şirketin yöneticisine, faturalandırmaya bağlamadan da yetki verebilirsiniz
Eskiden küçük bir eczane zinciri için faturalandırma ve alacak hesapları sistemi yapmıştım; sigorta şirketleri hiçbir haber vermeden oldukça büyük çekler gönderirdi
Biz hiçbir şey faturalandırmamış olsak bile postayla 150 bin dolarlık çek gelir, birkaç ay sonra da hatayı fark edip geri isterlerdi. Böyle paraları koyduğumuz magic money adlı özel bir hesap vardı. Faturalandırma dünyası gerçekten çılgın bir yer
Sadece magic money deyip kişisel hesaplardaki borcu olduğu gibi bırakmış olmayasınız
Bu konuya yalnızca kendi faturalandırma sistemini yapmanın sancıları üzerinden yaklaşmanın doğru olmadığını düşünüyorum. Birçok şirket bu yoldan gitmek istiyorsa bırakın gitsin.
Faturalandırma sistemlerinin çok karmaşık olduğunu kabul ediyorum. Ancak Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai vb. bu bilgiye sahipse, bu bilgiyi tek bir yerde toplamak da mümkün.
Sonuçta doğru cevap, size uyan yaklaşımdır. Abonelik tabanlı bir SaaS ise ona uygun bir çözüm vardır; kullanım tabanlı bir API ise ona uygun bir faturalandırma çözümü vardır.
Bir uygulamayı caydırmak yerine bilgi, yaklaşımlar, paradigmalar, programlama desenleri, iyi uygulamalar ve en iyi uygulamaları tek bir yerde toplayabilirsiniz. ABD veya Avrupa dışındaki bir şirket olduğu için Stripe gibi faturalandırma çözümlerini kullanamayan istisnalar da var. Örneğin Venezuela’da bir şirketseniz ve Stripe hesabı açamıyorsanız, sonunda kendi faturalandırma çözümünüzü yapıp yerel ödeme ağ geçidinin anlaşılması zor SOAP-XML API’sine bağlanmanız gerekir.
Ayrıca, “kendi faturalandırma sistemini yapmak” bana Elastic + Grafana kurulumuyla “kendi SIEM’ini yapmak” gibi geliyor. Tavsiye etmem ama BT güvenlik departmanlarında neden bu kadar çok tercih edildiğini anlıyorum.
Faturalandırma sistemleri, geliştiricilerin uğraştığı şeylerden daha az karmaşıktır. Yazı, zor hukuki gereklilikleri bir zorluk gibi resmediyor; oysa pratikte bu, spesifikasyonları bulmanın kolay ve iyi belgelenmiş olduğu anlamına da gelir. Sık değişen kısımlar da var, ama bu kısımlar iyi etiketlenmiş ve açıklanmıştır.
Abonelik tabanlı SaaS ile kullanım tabanlı API için uygun faturalandırma yöntemleri olduğu noktasına katılıyorum. Ancak asıl mesele, müşterinin sorumluluk yükünü devretmesine izin verip vermeyeceğiniz, gelirin bunu doğrulayacak kadar önemli olup olmadığı ve ücretleri ya da kayıpları karşılayıp karşılayamayacağınızdır.
Bu yazının ele almadığı şeylerden biri de satış ortaklığı; ne kadar derin uyguladığınıza bağlı olarak epey iş çıkarabilir.
Platform içindeki satışlar için başkalarının komisyon bazlı ödeme almasını sağlayan bir sistemdir.
Satış ortaklığı kodunu satışa ve kullanıcıya kadar izlemek, ödemeleri ortağın belirlediği ödeme sağlayıcısına göndermek ve işi düzgün yapmak istiyorsanız ziyaretçi metrikleri, dönüşüm oranları ve ödeme geçmişini görebileceği bir UI da sunmak gerekir.
Neyse ki çoğu şey kademeli olarak yapılabilir. Benzersiz bir kodu kullanıcıya bağlayıp, o kodu belirli bir komisyon oranına sahip satışa bağlamanız yeter; geri kalanı manuel işleyebilir veya atlayabilirsiniz. Örneğin ben ayda bir kez satış ortaklarına Zelle ya da PayPal ile ödeme yapıyorum ve 10 dakika bile sürmüyor. Dönüşüm takibi için bir frontend yok; bu yüzden satış ortaklığı yapmayacağını söyleyen kimse de olmadı.
Gerçekten etkileyici olan, bu koca Rube Goldberg makinesini tersine çalıştırabilme gerekliliğiydi.
“Sipariş”i olabildiğince statik tutmak istersiniz; “fatura” içinse hukuki yükümlülükler bile vardır.
Örneğin 5 adet alıp indirim kazandığınızı, ama sonra yalnızca 3 adet istediğinizi ve ad ile adreste yazım hatası olduğunu düşünün. Sorun değil dersiniz; faturayı iptal eder, aynı tutarla ad ve adresi düzeltilmiş yeni bir fatura oluşturur, iade gelene ve kontrol edilene kadar bekler, sonra tekrar alacak kaydı işler ve yine yeni bir fatura oluşturursunuz.
İade gönderisi bir süre belirsiz bir durumda kalır; müşteri 5 adet daha sipariş eder, bunlardan biri kırık gelir ve değişim değil iade ister. Teslimat tarihi ikiye bölündüğü için sistem 5 ve üzeri indirimini uygulamaz. Başta basit iki sipariş sandığınız şey, bir anda çok sayıda işlem ve evraka dönüşür. Müşteri şifresini de unutmuş ve başka bir e-posta ile yeni hesap açmıştır. Bir yıl sonra loglara baktığınızda, neden yalnızca 3 adet almasına rağmen indirim aldığını anlamak zor olur.
Bu tavsiyeden pek emin değilim. Yazıda bahsedilen özelliklerin yarısına ihtiyaç duymayabilirsiniz ve iş büyüdükçe bunları yeterince kademeli şekilde inşa edebilirsiniz.
Fatura, kredi, vergilendirme dönemi, oransal hesaplama değişiklikleri gibi kavramları anlamak gerekir. Ama bu bilgi, mutlaka dışarıya yaptırmanız ya da satın almanız gerektiğinin nedeni değil; inşa etme ile satın alma kararını daha iyi vermek için bir girdidir.
SaaS için gereken dış API yalnızca bir kredi kartı işlemcisidir; biraz gösterişli olsun derseniz belki iki tane. Elbette ilk yıl geçtikten sonra çok fazla manuel iş ortaya çıkacak, muhasebeci size aptalca hataları gösterecek ve muhasebeyi de epey öğreneceksiniz.
Yine de bugün yeni bir işe başlasaydım çeşitli çözümleri karşılaştırırdım ama kendim yapmanın o kadar da korkutucu olmadığına dair bir kanaatim var.
Sistem kurmak her zaman kolay görünür ve ilk gün gerçekten de kolaydır. Ama kısa süre sonra finans yöneticisine raporların neden tamamen berbat olduğunu açıklamakla çok zaman harcarsınız; destek ekibine de faturanın neden başarısız olduğunu, abonelik fiyatının neden yanlış tahsil edildiğini ve varlığından bile haberdar olmadığınız birçok uç durumu açıklarsınız.
Sonra değişen düzenlemelere uyum sağlamanız gerekir ya da seçtiğiniz ödeme geçidi büyüdüğünüz bölgeyi desteklemiyor olabilir.
“Sadece daha iyi yaparız” demeden önce, bunun da zaman olduğunu unutmayın. Ürüne harcanmayan zaman, fiyatlandırma modelini iyileştirmeye harcanmayan zaman ve işi büyütmek yerine yerinde saymaya harcanan zamandır.
Bunun dışındakileri görmezden gelebilirsiniz; ama daha sonra vergileri hesaplayamaz ya da müşterini tanı yasalarını ihlal eder hâle gelirseniz gerçekten zorlanırsınız.
Ayrıca bir sistemin beklenenden pahalı olması ve akıllı görünen birçok şirket tarafından kullanılması, amaca uygun olduğu anlamına gelmez. Özellikle sizin istediğiniz amaca uygun olduğunun hiç garantisi yoktur. Satın almak, araştırma yapmanıza gerek olmadığı anlamına gelmez.
Bu tür faturalamayla ilgilenen kişinin hedefi basittir. Satış ekibinin anlaşmaları kapatabilmesi için uygun seçenekler sunmak gerekir. Satış ekibiyle birlikte “uygulaması kolay ve anlaşmayı kapatmaya yeterli” alanın ne olduğunu bulmalısınız.
Bu noktanın ne kadar vurgulansa azdır. Satış ekibi gerçekten gelir yaratıyor. Kusursuz bir faturalama sistemi değil diye sızlanmamak gerekir. Şaşırtıcı gelebilir ama iş ilişkilerinin söz konusu olduğu konularda bazen kolları sıvayıp işi elle yapmak gerekir.
Mümkün olduğunca basit bir yöntemle yapılmalı; ama şirket içindeki diğer ekiplerin okuyup anlayabileceği ve otomasyon çalışsa bile kolayca manuel düzeltme yapılabilecek bir sistem olmalıdır. Stripe’ın kullanımı iyi hissettirmesinin %80’i burada yatar. Manuel düzeltme hayatın bir parçasıdır ve bazı işlerde nadir olsa da eninde sonunda gerekir.
Oransal hesaplama, farklı faturalama takvimleri, deneme sürümleri, yeni fiyat testleri, bölgesel fiyatlar, bölgesel vergiler, paket ürünleri birden fazla para biriminde listeleme ve yeni fiyatları dağıtma bir anda 6 para birimi × X bölge × Y ürün × Z faturalama takvimi × L dil kombinasyonuna dönüşür.
Buna yeni abonelik eklemeyi, abonelik planlarını birleştirmeyi, eski planları sonlandırırken müşterileri sorunsuz biçimde yeni alternatif planlara taşımayı ve müşterilerle iyi iletişim kurmayı ekleyin. SaaS iseniz bunların neredeyse tamamı iyi otomasyonlu, self servis ve test edilmiş olmalıdır; aksi hâlde müşteri desteği ve müşteri kaybı içinde boğulursunuz.
Fiyat değişikliği dağıtımı 3 günden 2 aya kadar sürebiliyor ve başlangıçtaki özel sözleşme izlerini yönetmek kâbus. Kolayca otomatikleştirilemiyorsa yapılamaz. Çok fazla zaman alıyor.
Burada bahsedilen ürünler gibi bir şeyi faturalamanın temeli yapsaydık, müşteri segmentlerine göre özel sözleşmeleri ve fiyat değişikliği dağıtımlarını çok daha iyi yapma ihtimalimiz olurdu.
Burada ele alınmamış ama benim doğrudan uğraştığım 2 sorun var.
Birincisi ay sonu ve çeyrek kapanışı. Yazı hesap defterinden bahsediyor ama rakamları raporlaması gereken halka açık şirketlerle çalışmaya başladığınızda katı kapanış zamanları vardır ve her şeyin sorunsuz ilerlemesini sağlamanız gerekir.
İkincisi hareket hâlindeki nakit muhasebesi. Bu yazı, ödeme işlemcisinin %100 doğru olduğunu ve hiçbir sorun çıkarmadığını varsayıyor. Yeterince büyüdüğünüzde banka hesabına giren her parayı belirli bir fatura ya da faturalama kalemiyle eşleştirebilmeniz gerekir. Karşılık gelen banka ekstresi satırı olmayan faturaları da bulmalı, tersine fatura kalemiyle bağlantılı olmayan para girişlerini de yönetmelisiniz. Faturalama faturalarıyla bağlantılı olmayan banka hesabı kredilerini ele alabilme yeteneği de önemlidir.
Bütün bunların muhasebe departmanının sorunu olduğunu söyleyebilirsiniz; ama sistemle çok sıkı biçimde bağlantılıdır, bu yüzden iki ekibin defterler arasında tutarsızlık olmaması için birlikte çalışması gerekir.
Gerçek muhasebeciler kapanış yüzünden tekrar tekrar gece yarısına kadar kalmak zorunda kalır; teknoloji ve iş tarafındaki insanlar da muhasebe ekibinden bir şey alması gerekirken kapanış döneminde muhasebe ekibi yeryüzünden kaybolmuş gibi görünür. Bunu aile üyesi olarak yaşamak da aynıdır.
İç muhasebe ile banka hesabı yavaş yavaş birbirinden sapar ve muhasebeci sorunu nereden aramaya başlayacağını bilemez.
Herkesin yetki yönetimi için ne kullandığını merak ediyorum. Özellik bayrağı sistemi mi kullanıyorsunuz, Stigg gibi ayrı bir SaaS mı, yoksa ayrı bir iç sisteminiz mi var?
Bu sabah HN’ye gelmemin nedeni de özellik bayraklarını yetki yönetimi için kullanmak üzerine bir yazı yazmış olmam: https://prefab.cloud/blog/modeling-product-entitlements-with.... Arnon’un SKU biçimiyle ilgili yazısından da ilham aldım
Özellik bayrakları yetki yönetimi için kusursuz bir yer gibi görünmüyor; ama deneyimime göre bu tür işleri çözerken eldeki araçlar içinde çoğu zaman en iyisi oluyor. Farklı görüşleri duymak isterim
Bu limitler ve bayraklar bir “tarife”ye bağlanıyor; tarifeler de hesaplara bağlanabiliyor. Tarifeler birleştirildiğinde sayısal değerlerde daha büyük olan değer alınıyor, etiketler ise birleşim kümesi olarak birleştiriliyor. Ayrıca hesap bazında değerleri geçersiz kılmak veya eklemek mümkün; böylece bir müşterinin PlanX’e ihtiyacı var ama özel bir API kotası gerekiyorsa, yalnızca o değeri doğrudan hesap üzerinde override ediyoruz
Eski usul diyebilirsiniz ama böyle bir şeyi neden üçüncü tarafa outsource etmek gerektiğini anlamıyorum
Temel çözüm özellik bayraklarıyla yapılabilir; ancak faturalama ve fiyatlandırmayla ilişkili yetkiler, örneğin tarifelerin ve edisyonların düzenlenmesi ve değişmesi, zamanla etrafındaki gereksinimler arttıkça karmaşıklaşıyor. Özelliklerin, koltukların, kullanıma dayalı ve ölçümlü stratejilerin farklı kombinasyonlarını, takım aboneliklerini, tarife geçişlerini, tek seferlik kurumsal tarifeleri, birden fazla aboneliği olan müşterileri, promosyon dönemlerini ve katmanlı abonelikleri, kullanım toplulaştırmayı, otomatik üst satışları düşünün
Yazıda görüldüğü gibi limitleri sayısal değer taşıyan bayraklarla ifade edebilirsiniz; ancak kullanım takibi altyapısını yine işletmenin kendisi uygulamak zorunda. Bunun yerine bu kullanımı yetki servisine aktardığınızı ve kullanıma dayalı yetkilerin ekipler arasında da gerçek zamanlı güncellendiğini düşünün. Ayrıca bu yetkiye bağlı diğer yetkiler de birlikte güncellenebilir. Limite yaklaşıldığında veya limit aşıldığında kullanmaya devam ettirip satış ekibini bilgilendiren yumuşak bir limit ya da yükseltme uyarısı gösteren sert bir limit seçebilirsiniz
Özgün yazının amacı gibi biz de faturalamayı yeniden yapmak yerine mevcut faturalama çözümleriyle birlikte çalışıyoruz. Önceki başarılı exit’imizle bootstrap ediyoruz ve erken müşterilerle çalışıyoruz; bu konu hakkında sadece konuşmak isteyenler de trent at planship.io üzerinden bana ulaşabilir
Beta dağıtımları, rol tabanlı yetkilendirme, faturalama yetkileri, tek seferlik müşteri talepleri; hepsi özellik bayraklarıyla yapılabilir. En iyi özellik bayraklarına isteğe bağlı olarak değer de eklenebildiğinden API tarife limitleri de bir özellik bayrağı olabilir
Bu en iyi yol mu derseniz, her kullanım senaryosu için muhtemelen değil. Ama bir kez yaptıktan sonra her yerde kullanma cazibesi büyük
Yetkiler, müşterinin gördüğü özelliklerle açıkça bağlantılı olmalı ve kavramsal olarak çok daha büyük özellik bloklarıdır. Bu yaklaşımın zorluğu, hâlâ faturalamayla ilgili pek çok yönü dikkate almak zorunda olmanızdır. Ödemesi geciken müşterileri ele alma, belirli bir limit aşıldığında aşım ücreti, aynı özellik için birden fazla fiyatlandırma modeli, tarife değişikliği veya yükseltme sırasında kullanım sayaçlarını sıfırlama ya da devretme gibi konular zamanla büyük karmaşıklık ekler
Bu yüzden Wingback’te faturalama zinciri ve ölçümlemeyle sıkı biçimde entegre ayrı özellik yetkileri sunmaya karar verdik. Bu arada CTO benim. Sonuçta iki yaklaşımın da, tarife karmaşıklığına ve özellik bayraklarına halihazırda ne kadar yatırım yaptığınıza bağlı olarak iyi çalışabileceğini düşünüyorum. Müşteriye dönük özellik gating’i olduğunda müşteri hesabı provisioning’i ve özel paketler sunmak çok daha kolaylaşıyor
“X sistemi çok karmaşık, bu yüzden kendiniz yapmayın; hazır çözüm kullanın” şeklindeki genel mantığı kabullenmek zor
X’in genel çözümü son derece zor ve karmaşık olabilir; ama benim kullanım senaryomda karmaşıklığın yalnızca belirli bir kısmı gerekir. Bu yüzden yalnızca gereken karmaşıklığı ele alan kendi çözümümü yapabilirim ve bu, hazır araçtan çok daha basit olabilir
Bu tutumu tarih ve saat konusunda tamamen benimsiyorum. Tarih-saat yaklaşımımda kütüphanenin yalnızca iki fonksiyon çağrısı sunması yeterli: epoch zamanını belirli bir saat dilimindeki ISO biçimli zaman dizgesine dönüştüren fonksiyon ve bunun tersi. Kütüphanedeki başka hiçbir koda dokunmuyorum; zamanla ilgili geri kalan tüm işlemleri bu iki fonksiyonu temel alarak kendi kodumda yapıyorum
En baştan kişisel veri işlemenin yapılması ve yapılmaması gerekenlerini, farklı faturalama seçeneklerinin döngülerini ve yaşam sürelerini, iade limitlerini, idempotency desteğini, işe uygun bir modelle makul veritabanı transaction yönetimini, fatura kesmeyi ve bunu müşteriye göstermeyi anlamanız gerekir
Hepsine birden ihtiyaç duyulmaz; ama ilk çalışan implementasyonda bile en az yarısına ihtiyaç vardır
Biraz “Karşıdan karşıya geçmenin 14 acısı ve neden kitabımı satın alıp okumalısınız” gibi hissettiriyor
Pek çok kişi gözlerini kapatıp yürümeye başlamanın iyi fikir olduğunu düşünür ve bu yüzden erken yaralanma ya da ölümle karşılaşır
Ülkeden ülkeye, hatta şehirden şehire karşıdan karşıya geçme kuralları değişir. Henüz bilmiyor olabilirsiniz ama iki tarafa da bakmanız gerekir. Renk körü olduğunu bilmediği için kırmızıyla yeşili ayırt edemeyip ölen veya yaralanan da çoktur. İki tarafa baktınız, peki yukarı da baktınız mı? Şehirde pencerelerden eşyalar düşer; kırsalda kuşlar başınızın üzerinden uçabilir; uzay çöpleri de giderek daha fazla Dünya’ya düşüyor. Nesneler pek çok yönden gelebilir
Bu yazının o kadar kötü olduğunu söylemiyorum; ama bir metodoloji yazısı olarak kurgulansaydı daha iyi olurdu. Olumsuz çerçevelenmiş bir yazıdansa böyle bir yazıyı çok daha fazla okumak isterdim
“Ne kadar zor olabilir ki?” türü şaka projesinin ideal örneği; sorun şu ki hepsi gerçek
Örnekler saymakla bitmez; ama soruna yanlış yaklaşırsanız kısa sürede “Müşteri ne kadar ödemeli?” sorusuna çarparsınız, ardından da “Neden bu tutarı değil de başka bir tutarı faturaladık?” gelir. Bu çok sık olursa finans ekibi gelip şirket operasyon raporlarını, hatta işten çıkarma kararlarını belirleyen raporları bile güvenilmez hâle getirdiğinizi söyleyerek ne yaptığınızı sorar