Kısa cevap: Yatırımcı güncellemesi ayda bir gönderilen, tek ekranı geçmeyen, en önemli sayıyla başlayan ve metrikleri saklamayan kısa bir e-postadır. Sıkıcı ama düzenli bir güncelleme, parlak ama düzensiz bir sunumdan çok daha fazla güven kazandırır. Yapı nettir: TL;DR, metrikler, kazanımlar, kötü haberler ve somut talepler.
Yatırımcı güncellemesi neden bu kadar önemli?
Yatırımcı güncellemesi, kurucunun şirketi kontrol altında tuttuğunu gösteren en ucuz araçtır. Her ay aynı saatte, aynı formatta gelen bir e-posta, yatırımcıya "bu ekip düzenli çalışıyor" mesajı verir; ay ay değişen, bazen hiç gelmeyen güncellemeler ise tam tersini işaret eder.
Buradaki asıl fayda içerik değil, tutarlılıktır. Bir yatırımcı, art arda altı ay boyunca aynı formatta gelen bir güncellemeyi okuduğunda, yedinci ayda kötü bir sayı görse bile paniğe kapılmaz — çünkü kurucunun düzenli raporladığını, saklamadığını bilir. Ağustos 2026 itibarıyla erken aşama SaaS yatırımcılarının büyük kısmı, düzenli güncelleme göndermeyen kurucuları takip portföyünde "riskli iletişim" olarak işaretliyor.
Yatırımcı güncellemesi ne sıklıkla gönderilmeli?
Erken aşamadaki şirketler için doğru sıklık aydadır. Şirket büyüyüp daha az operasyonel dalgalanma yaşadıkça, çeyreklik bir kadans daha yaygın hale gelir. Bootstrap mı VC mi, 2026'da doğru seçim sorusuna hangi cevabı verdiyseniz, dış yatırımcınız varsa aylık güncelleme varsayılan olmalı.
Araç seçimi basit tutulmalı: düz metin bir e-posta, Notion sayfası ya da Visible/Carta gibi özel bir yatırımcı güncelleme aracı — hepsi işe yarar. Önemli olan format değil, her ay aynı gün (örneğin ayın ilk haftası) gönderilmesidir. Takvime sabitlenmiş bir hatırlatıcı, bu tutarlılığı korumanın en pratik yoludur.
Bir yatırımcı güncellemesinin standart yapısı nedir?
Standart yapı altı bölümden oluşur ve her bölümün kendi işlevi vardır. Roundfunded'in 2026 şablonu ve Capitaly.vc'nin aylık şablonu da aynı iskeleti öneriyor:
Bölüm | Yaklaşık Uzunluk | Amaç |
|---|---|---|
Konu satırı | 1 satır | Şirket adı + ay, örn. "Woyable — Ağustos 2026" |
TL;DR | 1-2 cümle | Ayın en önemli sayısıyla (artı ya da eksi) başlar |
Metrikler | 4-6 madde | MRR, büyüme oranı, nakit, runway, burn, north star |
Kazanımlar | 3-5 madde | Tarihli, somut başarılar |
Kötü haberler | 1-3 madde | Kazanımlardan ayrı bir başlıkta, gizlenmeden |
Talepler | 1-3 madde | Spesifik, aksiyona dönüşebilir |
Tüm güncelleme 500 kelimeyi geçmemeli. Yatırımcı sadece TL;DR'ı okusa bile ayın özetini almış olmalı; geri kalanı sadece detay ekler.
Bir yatırımcı güncellemesinde hangi metrikler olmalı?
Dört ila altı çekirdek metrik yeterlidir; sayı bombardımanı okunmaz. En yaygın set şudur: aylık yinelenen gelir (MRR), aya göre büyüme oranı, kasadaki nakit, runway (ay cinsinden), aylık burn ve işinize özgü bir north star metrik. İlk SaaS metrikleri rehberimizde bu metriklerin nasıl hesaplandığını ve hangi hatalardan kaçınmanız gerektiğini anlatıyoruz.
Runway hesaplarken en yaygın hata, mevcut nakdi mevcut burn'e bölüp durmaktır — oysa yatırımcı, önümüzdeki üç ayda burn artacaksa (örneğin yeni işe alımlar varsa) bunu görmek ister. Qubit Capital'in yazdığı gibi, tek bir north star metrik seçmek ve onu her ay aynı tanımla raporlamak, tanımı ay ay değiştirmekten çok daha güvenilir görünür.
Kötü bir ay nasıl anlatılır, spin'e kaçmadan nasıl yazılır?
Kötü haberi kazanımların arasına gizlemek, en çok güven kıran hatadır. Kazanımlar ve kötü haberler ayrı başlıklar altında, birbirine karışmadan yazılmalı; kötü haber varsa ne yapıldığı ya da yapılacağı tek cümleyle eklenmeli.
Açık konuşayım: churn arttığında ya da bir hedef kaçırıldığında bunu "öğrenme fırsatı" gibi süslemek, yatırımcıyı aptal yerine koymaktır ve genelde tam tersi etki yapar — yatırımcı, sunulmayan detayı merak edip soru sormaya başlar. Valu.vc'nin belirttiği gibi, düz bir cümleyle "MRR bu ay %8 düştü, sebebi şu, aksiyonumuz şu" demek, aynı bilgiyi övgü cümleleriyle sarmalamaktan daha az zaman kaybettirir ve daha çok güven kazandırır. Fiyatlandırma değişikliği kötü bir aya yol açtıysa, SaaS fiyatlandırmasında yaygın yanlışlar yazımızdaki hatalardan hangisine düştüğünüzü açıkça yazmak, sorunu gizlemekten daha iyi bir izlenim bırakır.
Yatırımcılardan somut olarak ne istenmeli?
Talepler bölümü, kurucuların en çok atladığı ama yatırımcıların en çok görmek istediği kısımdır. Belirsiz bir talep hiçbir aksiyon doğurmaz; isim, unvan ve bağlam içeren spesifik bir talep genelde bir haftada karşılık bulur.
Belirsiz Talep | İyi Talep |
|---|---|
"Yardımcı olabilirseniz haber verin" | "Series B SaaS şirketlerinde bir Satış VP'siyle tanışmak istiyoruz" |
"Yeni müşteriler arıyoruz" | "50+ kişilik İK ekibi olan şirketlerde karar vericilere ihtiyacımız var" |
"Yatırım turu için destek lazım" | "Ekimde açacağımız 2 milyon dolarlık tur için 2 melek yatırımcı tanıtımı arıyoruz" |
Ayda en fazla üç talep yeterli. Daha fazlası, hiçbirinin ciddiye alınmama riskini artırır.
AI ile yatırımcı güncellemesi taslağı nasıl hazırlanır?
Kısa cevap: kendi metriklerinizi bir AI asistanına verip hızlı bir ilk taslak çıkarabilirsiniz, ama kazanımlar, kötü haberler ve talepler bölümlerini siz yazmalı ya da ağır şekilde düzenlemelisiniz. Bu bölümler, sadece sizin bildiğiniz ilişki bağlamını ve gerçek tonunuzu taşır; bir şablon bunu üretemez.
AI'ya asla paylaşmamanız gerekenler nettir: hisse tablosu (cap table) detayları, henüz açıklanmamış yatırım turu koşulları ve NDA'lı müşteri isimleri. Genel amaçlı bir AI aracına bu tür bilgileri yapıştırmadan önce o aracın veri kullanım koşullarını okumadıysanız hiç yapıştırmayın. Bu konu, kurucu ortak hisse ve vesting rehberimizde ele aldığımız hassas bilgi türleriyle aynı kategoriye giriyor — cap table detayı, tanım gereği şirket dışına çıkmaması gereken bir veridir.
Pratik akış şudur: metriklerinizi (MRR, büyüme, runway, burn) ve o ayki 3-4 olayı madde madde AI'ya verin, TL;DR ve metrik bölümünü taslak olarak ürettirin, sonra kazanımlar-kötü haberler-talepler kısmını kendi elinizle yazın veya baştan sona düzenleyin.
Doldur-boşluk yatırımcı güncellemesi şablonu
Aşağıdaki şablonu kopyalayıp köşeli parantezleri kendi rakamlarınızla doldurabilirsiniz:
Konu: [Şirket Adı] — [Ay Yıl] Güncellemesi
TL;DR: Bu ay [en önemli sayı/gelişme]. [1 cümlelik bağlam].
Metrikler:
- MRR: [X]$ ([+/-%Y] aya göre)
- Nakit: [X]$
- Runway: [X] ay
- Burn: [X]$/ay
- [North star metrik adı]: [X]
Kazanımlar:
- [Kazanım 1, tarihli]
- [Kazanım 2, tarihli]
- [Kazanım 3, tarihli]
Kötü Haberler:
- [Zorluk ve ne yaptığınız/yapacağınız]
Talepler:
- [Spesifik, aksiyona dönüşebilir talep 1]
- [Spesifik talep 2]Göndermeden önce aylık kontrol listesi nedir?
Güncellemeyi göndermeden önce şu maddeleri kontrol edin:
Yeni ekip üyesi ekliyorsanız, ilk işe alım freelancer mı çalışan mı sorusuna verdiğiniz cevabı da kazanımlar bölümüne tek cümlelik bir bağlamla eklemek, yatırımcının ekip büyümesini takip etmesini kolaylaştırır.
Sıkça Sorulan Sorular
Yatırımcı güncellemesi kaç kelime olmalı?
Yatırımcı güncellemesi 500 kelimeyi geçmemeli ve düz metin olarak yaklaşık tek bir ekrana sığmalı. Amaç, meşgul bir yatırımcının sadece TL;DR'ı okuyarak ayın özetini alabilmesidir; geri kalan bölümler detay ekler ama zorunlu okuma değildir.
Yatırımcı güncellemesini ayda bir mi, çeyrekte bir mi göndermeliyim?
Erken aşamadaki şirketler için doğru kadans aydadır, çünkü metrikler ve öncelikler hızlı değişir. Şirket büyüdükçe ve operasyonel dalgalanma azaldıkça çeyreklik bir kadans daha uygun hale gelir; ikisi arasındaki geçiş genelde Series B civarında olur.
Kötü bir ayı yatırımcılara nasıl anlatmalıyım?
Kötü bir ayı, kazanımlardan ayrı bir "Kötü Haberler" başlığı altında, süslemeden ve nedenini açıklayarak yazmalısınız. Düşüşün sebebini ve alınan aksiyonu tek-iki cümleyle belirtmek, durumu övgü cümleleriyle sarmalamaktan çok daha fazla güven kazandırır.
AI araçlarına yatırımcı güncellemesi için hangi bilgileri asla yazmamalıyım?
Cap table (hisse tablosu) detaylarını, henüz kamuya açıklanmamış yatırım turu koşullarını ve NDA'lı müşteri isimlerini genel amaçlı bir AI aracına asla yapıştırmamalısınız. Bu bilgileri paylaşmadan önce aracın veri kullanım koşullarını kontrol etmediyseniz, hiç paylaşmayın; AI'yı sadece metrik ve olay listesini taslağa dönüştürmek için kullanın.
