Startuplara ve yazılım çözümleri sunan tüm şirketlerin (SAAS) girişimcilerine, kendilerini melek yatırımcı ya da VC yani risk sermayesi fon yöneticisi gözüyle gözden geçirerek, performans değerlerini izlemelerini ve incelemelerini öneririm. Burada en önemli ölçülmesi ve izlenilmesi gereken değer ise, hep söylendiği gibi MRR (monthly recurring revenue) dedikleri aylık sürekli gelir değeridir. Yatırımcı Şirketin Gelir Performansına Bakar.
Eğer kontratlar yıllık yapılıyorsa (Annual Recurring Revenue – ARR), tabii ki bu yıllık da hesaplanabilir. Her startup’ın büyümesini net ve kesin şekilde ispat eden göstergelerden biri budur ve tüm yatırımcılar da muhakkak bu değere bakarlar.
Bir finansçı olarak, Türkiye’de New York Borsasına girmiş bir teknoloji şirketinin yıllarca gelir kontrolörü olarak çalıştım. İlk kez ARPU, MRR, RETENTION, CHURN, CAC, CMGR değerlerini hesapladım. 2000’li yıllarda henüz ülkemizde bu bilgi olmadığı için yurtdışından danışmanlık almak zorunda kalmıştık.
Aradan geçen neredeyse 20 yıl sonra ne mutluyum ki girişimciler bir kahve molasında bu değerlerini oluşturan verilerin alındığı raporların sorgusunu tartışabiliyorlar. Ben de bir hesap adamı olarak bu pazar sabahı kahvemi yudumlarken bir faydam olsun diyerek bildiklerimi paylaşıp yapılan en büyük hatalardan ikisini burada kaleme almak istedim.
MRR Hesaplarken Nelere Dikkat Etmeli?
Yazının bundan sonraki kısmında kolaylık olsun diye, “aylık sürekli gelir” ifadesini kullanmak yerine İngilizce kısaltması olan MRR’ı tercih edeceğim.
MRR hesaplamasında kullanılan formül: ARPU x Toplam Kullanıcı Adedi = MRR
*ARPU ya da ARPA (kullanıcı veya hesap başına ortalama gelir)
MRR ayrıca toplam aylık gelir olarak da sistemden bir sorgu ile de çekilebilir.
Yapılan ilk hata, İlk önce MRR hesabına dahil edilen kullanıcı adedinin sürekli kullanıcı olmamasıdır. Daha önce yapılan bir hatayı örnek verirsem sanırım daha iyi anlaşılır:
İlk zamanlar, askere gitmek ve benzeri gibi nedenlerle hizmet akdini geçici durduran ya da donduran kullanıcıların de sayısını hesaplara dahil ederek bir yanılgıya girmiştik. Buradaki ARPU ve MRR hesabında toplam kullanıcı adedine, sözleşmesini geçici donduran kullanıcı ya da askıya alınmış kullanıcı adedini eklemekte kanımızca bir mahsur yoktu. Çünkü bu kullanıcılar gelir yaratmasalar da o ay için hala sistemde bulunuyorlardı. Bizim bakış açımızdan bakıldığında, sadece sözleşmesi fesih edilen kullanıcılar sistemden dışarı çıkmış kabul ediliyordu. Ama büyük bir yanılgıdaydık ve rakamlarımızın yanıltıcı olduğu iddiası ile de hayli zor durumda kaldık.
Daha sonra, kullanıcıları aktif ve pasif olarak ayırıp sadece aktif, yani gelir yaratan kullanıcıları bu formüle dahil ettik. Bu ayrım bile aylık net trafikte aktif olanları gösterip pazarlama için ayrı bir aksiyon planı alınmasını sağlamıştı. Unutmayın 20 yıl önce ne internet ne de akıllı telefon vardı. Bunlar hiçbir yerde ne yazılır ne konuşulur konulardı.
İkinci hata ise bir seferlik alınan ücretlerin MRR hesabına dahil edilmesidir. Bir sefere mahsus alınan donanım, kurulum gibi masraflar; -diğer aylara bölünerek alındığı için- sürekli gelir gibi hesaba katılırsa bu durum, hatalı sonuca yol açar.
Burada en büyük görev, veri sağlayan IT birimindeki arkadaşlarımızdadır ve alınan veri raporundaki sorgunun doğru olmasıdır. Bu gelir raporu farklı açılardan çapraz kontrol edilebilir hale getirilebilir. Hatta paralel bir sistemde trafiği tekrar fiyatlandırılarak devamlı bir kontrol yöntemi ile hata payını sıfırlayabilirsiniz. Bu yöntemin çok faydasını görüdüğümüzü, yeni çıkan kampanyalarda hatalı faturalandırmayı da tamamen önlediğini söyleyebilirim.
Geçmişte yapılan hatalardan ders almak gerekir. Bu yüzden sizinle açıkça bu hataları ve bunlardan öğrendiklerimizi paylaştım. Çıkarılması gereken dersi bir cümle ile özetlemem gerekirse, MRR hesabındaki “süreklilik” hem gelir, hem de kullanıcı açısından değerlendirilmelidir. Aksi halde yanıltıcı sonuçlar ortaya çıkaracaktır.