Bir startup şeffaflık sayfasını nasıl planlayacağınızı, yazacağınızı ve yayınlayacağınızı öğrenin: ne paylaşılmalı, nelerden kaçınılmalı, sayfa yapısı, güncellemeler ve pratik şablonlar.
Bir şeffaflık sayfası, şirketinizin nasıl çalıştığını tek bir herkese açık yerde açıkladığınız sayfadır—ne inşa ettiğiniz, fiyatlandırmayı nasıl yaptığınız, müşteri verilerini nasıl ele aldığınız ve işler ters gittiğinde insanların ne bekleyebileceği gibi konular.
Bu pazarlama amaçlı, belirsiz iddialarla dolu bir sayfa değildir. Aynı zamanda "her şeyi dünyaya anlatma" belgesi de değildir. Amaç pratik açıklık: müşterilere, adaylara ve ortaklara kararlarınıza güvenmeleri ve ürününüzü daha az sürprizle kullanabilmeleri için yeterli bağlam sağlamaktır.
İyi bir şeffaflık sayfası:
Bir şeffaflık sayfası değildir:
/terms) veya gizlilik politikanızın (/privacy) yerine geçen bir belgeStartuplar şeffaflık sayfalarını şu amaçlarla kullanır:
Açık, yerine getirilebilir taahhütler yapıp düzenli güncelleyebiliyorsanız faydalıdır.
Zararlı olabilir eğer şunları yayımlarsanız:
Sadece gerçek sahipliği olan ve düzenli güncelleme alışkanlığı olan şeyleri paylaşın. Eğer herkese açık bir yol haritasını güncel tutamıyorsanız, bunun yerine önceliklendirme ilkelerini yayımlayın.
Uzunluk ve yapı için, bir sayfa (veya küçük bir sayfa seti) toplamı yaklaşık 3.000 kelime hedefleyin—gerçekten faydalı olacak kadar uzun, okunabilir kalacak kadar kısa. Basit bir içindekiler ve ankrajlar ile açık bölümlere ayırın ki insanlar ihtiyaç duyduklarına doğrudan atlayabilsin.
Bir şeffaflık sayfası herkesin sorularını eşit şekilde yanıtlayamaz. Hepsini cevaplamaya çalışırsanız, metin duvarına dönüşür—veya daha kötüsü, güven oluşturmayan belirsiz ifadeler setine.
Şu anda en çok rahatlatmanız gereken tek grubu seçin ve önce onlar için yazın:
Diğer kitleler için bölümler ekleyebilirsiniz ama birincil kitle ton, ayrıntı ve vurguyu belirlemeli.
Sayfanız, hedef kitlenizin zaten sorduğu küçük bir soru setine net yanıtlar vermeli, örneğin:
/pricing)\n- “Kesintiler ve destek nasıl ele alınıyor?”\n- “Benim hakkımda ne topluyorsunuz ve neden?”\n- “Ürün kararlarını nasıl veriyorsunuz—ve dinliyor musunuz?”Sınırları açıkça belirtin. Yaygın “paylaşılmayan” alanlar arasında ticari sırlar, kişisel çalışan/müşteri verileri ve operasyonel güvenlik detayları (örneğin, tam iç yapılandırmalar) bulunur.
Bu adımı aşağıdaki tek cümleyi taslak haline getirerek bitirin:
“Burada ne paylaşıyoruz, neden paylaşıyoruz ve ne sıklıkla güncelliyoruz.”
Şeffaflık sayfası, insanlar hızlıca bulamazsa veya güvenle tarayamazsa işe yaramaz. Onu ürün dokümantasyonu gibi düşünün: kolay bulunur, kolay taranır ve her ziyarette ne bekleyeceğiniz öngörülebilir olmalı.
/transparency gibi kısa, açık bir yol kullanın. Linki footer'a koyun (Privacy, Terms, Security yanında) ve About menünüz varsa ikinci bir giriş noktası eklemeyi düşünün. Tutarlılık önemlidir: URL'yi yayımladıktan sonra sabit tutun.
Zaten ilgili sayfalarınız varsa, okuyucuların ayrıntıları doğrulayabilmesi için bunları net, göreli yollarla bağlayın (ör. /pricing, /security, /privacy).
Çoğu startup için iyi okunan pratik bir sıra:
İşi satılan sektöre göre yeniden sıralayabilirsiniz (ör. düzenlemeye tabi müşterileriniz varsa güvenliği daha yukarı koyun).
Sayfa birkaç ekranı geçiyorsa, üst tarafa kısa bir içindekiler ekleyin ve her bölüme atlama linkleri verin. Etiketleri basit tutun (“Pricing”, “Roadmap”, “Security”) ki tarama zahmetsiz olsun.
En üste “Last updated” satırı ekleyin ve aylık olarak gözden geçirildiğini veya “büyük değişiklikten sonraki 7 gün içinde güncellenir” gibi bir zamanlamayı belirtin. Güncellemelerin durmaması için iç bir sahip (rol veya ekip) atayın.
Sayfayı şu eylemle bitirin: “Sorular? Bize [email protected] üzerinden e‑posta gönderin” veya hafif bir form (/contact) gösterin. Okuyucuların nereden açıklama isteyeceklerini merak etmemesi gerekli.
Bir şeffaflık sayfası sadece neye inandığınızı değil, nasıl gerçekten çalıştığınızı da açıklamalıdır.
Misyon bir veya iki cümlede “neden”inizdir: kimlere hizmet ettiğiniz ve neyi değiştirmek istediğiniz.
Değerler inandığınız şeylerdir (örn. “saygı”, “hız”, “işçilik”). Davranışlar ise bu değerleri kanıtlayan gözlemlenebilir eylemlerdir (örn. “tüm destek taleplerine 1 iş günü içinde yanıt veririz”). Okuyucular sloganlardan ziyade davranışlara güvenir.
Şirketi başlatan basit anı paylaşın: karşılaştığınız problem, neden mevcut seçeneklerin yetersiz olduğu ve gönderdiğiniz ilk sürüm. Somut ve müşteri odaklı tutun.
Daha uzun versiyon varsa, ona link verin: bkz. /about.
Açık İngilizce birkaç ilke yazmak için şu soruları kullanın:
3–5 taahhüt ekleyin, örneğin:
Gerekli yerlerde destekleyen detaylara (örn. /careers) bağlayın.
İnsanlar insanlara güvenir. Şeffaflık sayfası soğuk bir politika belgesi gibi değil—üründen kimin sorumlu olduğunu ve kararların nasıl alındığını göstermeli.
Liderlik ve kilit rollerin basit bir özetini yapın: kurucular, ürün sorumlusu, mühendislik lideri, müşteri destek lideri, güvenlik/gizlilik sahibi ve anlaşmayı kabul etmişse danışmanlar.
Rol odaklı tutun:
Kişisel konum, kişisel telefon numarası gibi istenmeyen temaslara yol açacak detaylardan kaçının. Amaç hesap verebilirlik, maruz kalma değil.
Günlük iş birliğinin nasıl olduğunu açıklayan kısa bir “çalışma ilkeleri” bölümü ekleyin:
Bu, neden bazı taleplerin hızlı ilerlediğini diğerlerinin incelenmesi gerektiğini anlamaya yardımcı olur.
Eğer işe alıyorsanız (veya yakında alacaksanız), süreç hakkında temel bilgileri paylaşın: tipik aşamalar, yaklaşık zaman çizelgeleri ve neyi değerlendirdiğiniz (portfolyo, problem çözme, iletişim). Açık pozisyonlar ve detaylar için /careers sayfasına bağlayın.
Zaten başka yerde arka plan bilgisi varsa, kopyalamak yerine oraya bağlayın.
Fiyatlandırma genelde şeffaflık sayfalarının güven inşa ettiği veya hayal kırıklığına sebep olduğu alandır. Buradaki amaç fiyat tablonuzu kopyalamak değil; insanların kendini nitelendirmesini sağlamak ve sürprizleri önlemektir.
Basit plan isimleri kullanın ve her planın kimin için olduğunu açıklayın. Hangi özelliklerin yüksek seviyede dahil olduğunu söyleyin (her ayrıntıyı değil).
Örnek:
Kullanıma dayalı fiyatlandırmanız varsa, bunu açıkça belirtin (örn. “kisi başı fiyatlandırma”, “kullanıma göre fiyatlandırma” veya her ikisi).
Şu temel konuları tek yerde açıklayın:
Bunlar plan veya bölgeye göre değişiyorsa, baştan söyleyin.
Yaygın eklentiler (ek koltuklar, ek çalışma alanları, daha yüksek kullanım limitleri) varsa, yükseltmelerin nasıl işlendiğini (anında mı yoksa sonraki fatura dönemiyle mi) ve düşürmelerin ne zaman yürürlüğe girdiğini açıklayın.
İnsanlar fiyat değişikliklerinden çok sürprizlerden hoşlanmaz. İlkelerinizi paylaşın (örn. “mevcut müşterileri X ay süreyle koruyoruz” veya “değişikliklerden en az Y gün önce e‑posta ve uygulama içi bildirim göndeririz”). Sadece sürekli karşılayabileceğiniz zamanlamalara bağlı kalın.
Detaylı döküm için fiyatlandırma sayfanızda kalın: /pricing.
Metrikler güveni hızlıca inşa edebilir—ama yalnızca anlaşılabilir, zaman içinde karşılaştırılabilir ve işinize ya da müşterilerinize zararlı olmayacaklarsa. Amaç “her şeyi göstermek” değil; güvenilirlik, ivme ve uygunluk hakkında yardımcı olacak birkaç sinyal göstermektir.
Hassas stratejiyi açığa çıkaracak (kesin gelir, nakit burnu, müşteri listeleri) veya kolayca yanlış yorumlanacak (bağlamı olmayan gösteriş sayıları) metriklerden kaçının. Eğer bir metrik spekülasyona yol açabilir, paylaşıma uygun değildir.
Kesin değerler uygun değilse, şu formatları kullanın:
Küçük bir operasyonel metrik seti genelde işe yarar:
Her metrik için bir cümleyle neden önemli olduğu, bir cümleyle de nasıl ölçüldüğü (zaman penceresi, veri kaynağı, tanım) yazın. “Yanıt süresi”nin ilk yanıt mı yoksa çözüm süresi mi olduğunu belirtin.
Kısa bir not ekleyin: “Metrikler enstrümantasyon iyileştikçe revize edilebilir.” Tanımları değiştirdiğinizde (örn. yeni bir analiz aracı) tarihi belirtilmiş olarak ne değiştiğini açıklayın ki okuyucular bunu bir saklanma olarak görmesin.
Yol haritası ve değişiklik günlüğü, “biz inşa ediyoruz”u müşterilerin gerçekten takip edebileceği bir şeye çevirir. Tekrarlayan destek sorularını azaltır (“X planlanıyor mu?” “Y yayınlandı mı?”) ve neyin olmasının muhtemel olduğunu daha sağlıklı biçimde belirtir.
Hafif tutun. Üç yaygın seçenek:
Ayrı sayfalar tutuyorsanız, bunları şeffaflık sayfasından net şekilde bağlayın (örn. /roadmap).
Yol haritası öğeleri niyet olarak çerçevelenmeli, vaat olarak değil. En üstte kısa bir not ekleyin:
Bu paragraf hayal kırıklığını önler ve öncelikler değiştiğinde güveni korur.
Değişiklik günlüğü her küçük düzeltmeyi içermek zorunda değil. Şunlara odaklanın:
Girişleri kısa tutun ve derinlemesine belge varsa ona bağlayın. Başka yerde yaşıyorsa /changelog sayfasına bağlayın.
Müşterilerin geri bildirimini tam olarak nasıl paylaşacağını açıkça söyleyin—e‑posta, uygulama içi form veya forum. Oylama destekliyorsanız, oyların önceliklendirmeyi nasıl etkilediğini açıklayın (sinyal, garanti değil) ve istekleri ne zaman gözden geçirdiğinizi belirtin.
Bir şeffaflık sayfası insanların kaydolmadan önce zaten sorduğu soruları yanıtlamalı: “Ne veri topluyorsunuz?”, “Kim görebilir?” ve “Ne kadar süre saklıyorsunuz?” Eğer kullanıcılar net cevap bulamazsa, en kötüsünü varsayarlar.
Üstte kısa bir “bir bakışta” bölümüyle başlayın, sonra tam yasal metin için resmi politikalara yönlendirin. Örnek:
Sonra tam versiyon için doğrudan /privacy ve /terms sayfalarına yönlendirin.
Aşağı konularda spesifik olun:
“Güvenliği ciddiye alıyoruz” gibi belirsiz ifadelerden kaçının—pratik temel uygulamaları anlatın.
Korumaları yüksek seviyede açıklayın (iletimde şifreleme, en az ayrıcalık erişimi, düzenli güncellemeler), ancak saldırganlara yardımcı olabilecek ayrıntıları (tam firewall kuralları, iç mimari diyagramları, yönetici URL'leri) yayınlamayın.
Basit bir bildirim yolu ekleyin, örn. [email protected], ve bildirimcilerin ne bekleyebileceğini (onay süresi, açıklamaları nasıl ele aldığınız). Eğer varsa kısa bir zafiyet bildirim politikası sayfasına (/security) bağlayın.
Şeffaflık sadece sayıları paylaşmak değildir—günlük müşteri deneyimini öngörülebilir kılmaktır. İyi bir şeffaflık sayfası insanların nasıl yardım alacağını, ne kadar çabuk yanıt almayı bekleyebileceklerini ve ürününüz için “güvenilir” ifadesinin ne anlama geldiğini söyler.
Gerçek olarak izlediğiniz destek yollarını ve her birinin ne için uygun olduğunu listeleyin: e‑posta, uygulama içi sohbet, yardım merkezi, topluluk forumu veya telefon (sunuyorsanız). Ücretli planlara özel destek varsa, bunu net belirtin.
Kararlı şekilde karşılayabileceğiniz yanıt pencerelerini ekleyin. Örneğin: “1 iş günü içinde yanıt hedefliyoruz” gibi gerçekçi bir ifade, “1 saat içinde” demekten iyidir eğer bu tutarlı değilse.
Eskalasyon yolu varsa basitçe açıklayın: acil sayılan durumlar, müşterilerin nasıl etiketlemesi gerektiği ve ne zaman uygundur. Eğer hizmet kapsamında özel bir olay yöneticisi vermiyorsanız bunu vaat etmeyin.
Kullanıcıların hizmet güncellemelerini nerede göreceklerini ve bir olay sırasında ne bekleyeceklerini açıklayın: güncellemelerin sıklığı, hangi bilgileri paylaşacağınız (etki, etkilenen sistemler, geçici çözümler) ve ne zaman olay sonrası özet yayınlayacağınız.
Erişilebilirlik ve olay geçmişi yayımlıyorsanız doğrudan bağlayın: bkz. /status.
İade politikası veya şikayet ele alma süreciniz kamuya açıksa, kısa bir özet verin ve tam politikaya bağlayın. Müşterilerin önemsediği ana noktaları kapsayın: uygunluk, süre sınırları ve nasıl inceleme talep edileceği.
Şeffaflık sayfası yalnızca doğru kaldığında güven inşa eder. Bunu sağlamak için sayfayı yaşayan bir belge olarak görün ve net sahiplik ve öngörülebilir bir güncelleme ritmi belirleyin.
Sayfanın uçtan uca sahibini seçin (genelde Operasyon, Ürün veya Pazarlama içinde biri). Görevi her şeyi yazmak değil—güncellemelerin yapılmasını sağlamaktır.
Küçük ekipler için basit bir iş akışı:
Sahibi sayfada (veya iç dokümanda) rol bazında adlandırın ki “herkesin işi” olup kimsenin işi haline gelmesin.
Gerçekçi bir takvim seçin:
En üste görünür bir “Last updated” satırı ekleyin.
Kısa bir "Sayfa güncelleme kaydı" ile her değişiklik için 1–2 satır not tutun (ör. “2026-03-01 — Fiyat bildirim süresini güncelledik; veri saklamayı netleştirdik”). Bu, ürün değişiklik günlüğünden farklı olarak sayfa kendisindeki değişikliklerin kaydıdır.
Sayılar değiştiğinde kafa karışıklığını önlemek için güncellemeleri ya:
Bu, okuyucuların neye baktıklarını anlamasına ve “neden değişti?” tartışmalarını azaltmaya yardımcı olur.
Kısa bir yayın öncesi kontrol listesi tutun:
/pricing, /security)Her şey hemen veya tam detayla paylaşılmamalı. Gerekirse birini seçin:
Tutarlılık mükemmellikten daha etkilidir: güvenilir bir ritim ve net sahiplik, arada bir büyük güncellemeden daha fazla iş görür.
Bu sayfa kısa sürede güncellenebilecek şekilde inşa edildiğinde bakım kolaylaşır. Hızlı tarama ve hızlı güncelleme için CMS‑dostu bloklar, tutarlı başlıklar ve yeniden kullanılabilir bileşenler hedefleyin.
| Bileşen | En iyi kullanım | İpucu |
|---|---|---|
| Tablo | Fiyat notları, erişilebilirlik hedefleri, veri saklama | Etiketleri ilk sütunda tutun |
| Callout | “Last updated” + sahiplik + ritim | Üst kısma yerleştirin |
| SSS | Yaygın sorular (faturalama, güvenlik, yol haritası) | Yanıtları sade tutun |
/pricing” yerine “fiyatlandırma sayfasına bakın” yerine açıklayıcı metin kullanın)./pricing, /security, /privacy, /status, /blog\n- Eğer SSS eklediyseniz, Organization ve FAQPage şeması düşünebilirsiniz.Eğer darboğaz sayfayı yayımlamaksa—ne söyleyeceğinizi kararlaştırmak değil—şeffaflık sayfasını küçük bir ürün işi gibi ele alın: bölümleri taslaklayın, yayınlayın ve bir ritimde tekrarlayın.
Pratik bir yaklaşım, başlangıç sayfa yapısını Koder.ai gibi bir araçta oluşturup (fiyat beklentileri, destek hedefleri, veri işleme özeti, yol haritası bağlantıları) hızla çalışan bir web sayfası elde etmektir. Koder.ai dağıtım/barındırma, özel alan adları ve anlık görüntü/geri alma desteği sağladığı için erken yayınlayıp politikalar gelişirken güvenle güncelleme yapabilirsiniz—ve "site değişiklikleri" haftalar süren mühendislik işine dönüşmez.
Giriş (2–3 satır): Bu sayfayı neden yayınladığınızı açıklayın.
Last updated: ____ • Sahip: ____ • Ritim: ____
Nasıl çalışıyoruz: (değerler + karar ilkeleri)
Fiyatlandırma & faturalama beklentileri: (özet + bkz. /pricing)
Yol haritası & değişiklik günlüğü: (bkz. /roadmap ve /changelog)
Gizlilik & güvenlik: (kısa özet + bkz. /security ve /privacy)
Destek & güvenilirlik: (saatler, kanallar, yanıt hedefleri + bkz. /status)
SSS: (3–6 soru)
Sorular nasıl sorulur: (destek e‑postası veya /contact)
Yayına almadan önce mobilde test edin, yazım denetimi yapın ve takım dışından bir arkadaşınıza 60 saniyede cevap bulup bulamayacağını sorun.
Açıklık veya yapı hakkında geri bildirim isterseniz, okuyucuları iletişim formu veya basit bir e‑posta bağlantısı yoluyla öneri göndermeye davet edin; isterseniz değişiklik günlüğü veya haber bülteni ile güncelleme aboneliği sunun.
Bir şeffaflık sayfası, şirketinizin nasıl çalıştığını pratik terimlerle açıkladığınız herkese açık bir sayfadır (genellikle /transparency). Fiyatlandırma beklentileri, destek/güvenilirlik, yol haritası yaklaşımı ve veriyi nasıl ele aldığınız gibi konuları içerir.
Amaç sürprizleri azaltmak ve güveni hızlandırmaktır; /terms veya /privacy gibi yasal belgelerin yerine geçmez.
Birkaç net taahhütte bulunabileceğiniz ve sayfayı güncel tutacak birine sahip olduğunuzda yayınlayın.
Eğer herkese açık bir yol haritasını veya metrikleri güvenilir şekilde güncelleyemiyorsanız, bunun yerine karar verme ilkelerinizi ve güncelleme takviminizi yayınlayın; detayları sonra ekleyin.
Önce birincil hedef kitlenizi seçin ve ona göre yazın:
İkincil bölümler ekleyebilirsiniz ancak sayfanın yapısını ve ayrıntı düzeyini birincil kitle belirlemeli.
Kısa bir “güven soruları” listesi hazırlayın ve doğrudan yanıtlayın (genelde 3–5 soru):
Risk oluşturan veya güveni zedeleyecek şu tür şeylerden kaçının:
Paylaşamıyorsanız, kısa bir cümleyle sınırı açıklayın ve neden paylaşmadığınızı söyleyin.
Kısa ve sabit bir URL kullanın (çoğunlukla /transparency) ve insanların baktığı yerlere bağlayın:
/privacy, /terms, /security yanındaSayfa birkaç ekranı geçiyorsa, atlama linkleri içeren basit bir içindekiler bölümü ekleyin.
Fiyatlandırma sayfasını kopyalamak yerine faturalama beklentilerini sade bir dille özetleyin ve detaylar için /pricing sayfasına yönlendirin.
Sık karışıklığa yol açan konuları belirtin:
Doğru rakamlar için sayfasına bakın.
Kolayca yanlış yorumlanmayacak ve paylaşılması güvenli metrikleri seçin.
İyi seçenekler:
Her metriğin yanında neden önemli olduğu ve nasıl ölçüldüğüne dair bir cümle ekleyin.
Sürdürmesi kolay bir format seçin, örneğin:
Yol haritası öğelerini niyet olarak çerçeveleyin, vaat olarak değil; öncelikler müşteri öğrenimi, güvenilirlik ihtiyaçları veya teknik kısıtlar nedeniyle değişebilir. Eğer varsa /roadmap ve /changelog sayfalarına bağlayın.
“Tazelik” görünür olsun ve sahiplik atayın.
Basit bir düzen:
Güncellenemeyecek şeyler için kısa bir yer tutucu yayınlayın ve incelemeden sonra detay ekleyin.
"Bu bana ne kadara mal olacak?" (bakınız /pricing)"Arızalarda ne oluyor ve nasıl yardım alırım?" (varsa /status sayfasına bakın)"Hangi verileri topluyorsunuz ve neden?" (bakınız /privacy)"Sırada ne var, nasıl karar veriyorsunuz?" (bakınız /roadmap veya ilkelere bakın)Destek veya satışta sıkça sorulan bir soru varsa, burada olmalıdır.
/pricing