Bir Startup'ın Web Sitesine Şeffaflık Sayfası Nasıl Oluşturulur (Adım Adım)

Şeffaflık Sayfası Nedir (ve Neden Startuplar Kullanır)

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.

Ne işe yarar (ve ne değildir)

İyi bir şeffaflık sayfası:

• Spesifik: somut politikalar, zaman çizelgeleri ve tanımlar (anahtar kelimeler yerine)\n- Okunabilir: teknik olmayan kişiler için yazılmış\n- Bakımı yapılıyor: gerçeklik değiştiğinde güncellenir

Bir şeffaflık sayfası değildir:

• Yasal koşullarınız (/terms) veya gizlilik politikanızın (/privacy) yerine geçen bir belge
• Gerçek zamanlı bir durum sayfası (ama birine bağlanabilir)
• Hassas ayrıntıları yayınlama yeri (güvenlik yapılandırmaları, gizli sözleşmeler, kişisel veriler)

Startupların neden yayınladığı

Startuplar şeffaflık sayfalarını şu amaçlarla kullanır:

• Markayı yeni tanıyan müşterilerle güveni hızla inşa etmek\n- Satış öncesi sürtüşmeyi azaltmak; sık sorulan soruları (fiyatlandırma, destek saatleri, yol haritası yaklaşımı) önceden yanıtlayarak\n- İç hizalanma yaratmak—işleyiş ilkelerini yazıya dökmek netlik gerektirir\n- İşe alım ve yatırım süreçlerini desteklemek; nasıl düşündüğünüzü ve işi nasıl yürüttüğünüzü göstererek

Ne zaman yardımcı olur—ve ne zaman zararlı olabilir

Açık, yerine getirilebilir taahhütler yapıp düzenli güncelleyebiliyorsanız faydalıdır.

Zararlı olabilir eğer şunları yayımlarsanız:

• Güvenilir şekilde karşılayamayacağınız aşırı iddialar (ör. bu sistemi destekleyecek altyapı olmadan “%99.99 erişilebilirlik” gibi)\n- Güncellemeyeceğiniz bir yol haritası, bu açıklık yerine kaos sinyali verir\n- Bağlamı olmayan sayılar, yanlış yorumlanmaya açık

Başlangıçta beklentileri ayarlayın

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.

Hedef Kitlenizi ve Şeffaflık Düzeyinizi Seçin

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.

Önce bir birincil kitleyle başlayın

Şu anda en çok rahatlatmanız gereken tek grubu seçin ve önce onlar için yazın:

• Müşteriler: fiyat, güvenilirlik, güvenlik ve bir sorun çıktığında ne olacağı hakkında netlik isterler.\n- Adaylar: nasıl çalıştığınızı, değerlerinizi ve “normal bir hafta”nın nasıl göründüğünü anlamak isterler.\n- Yatırımcılar: yürütme, karar alma ve sağlıklı yönetişim sinyalleri ister.\n- Topluluk/kullanıcılar: açıklık, yanıt verilebilirlik ve bir yön hissi isterler.

Diğer kitleler için bölümler ekleyebilirsiniz ama birincil kitle ton, ayrıntı ve vurguyu belirlemeli.

3–5 güven sorusu tanımlayın

Sayfanız, hedef kitlenizin zaten sorduğu küçük bir soru setine net yanıtlar vermeli, örneğin:

• “Bunun maliyetini tahmin edebilir miyim?” (bkz. /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?”

Bir şeffaflık düzeyi seçin (ve ona bağlı kalın)

• Temel: ilkeler, iletişim yolları ve basit bir taahhüt.\n- Standart: fiyat beklentileri, destek/SLA temelleri ve hafif ürün güncellemeleri ekler.\n- Yüksek: herkese açık yol haritası, düzenli değişiklik günlüğü ve bağlamla seçilmiş metrikler ekler.

Hangi bilgilerin özel kalacağını belirleyin

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.

Bir cümlelik taahhüdünüzü yazın

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.”

Sayfa Yapısını ve Navigasyonu Planlayın

Ş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ı.

Kısa bir URL seçin ve insanların baktığı yerlere koyun

/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).

Okuyucu-öncelikli bölüm sıralaması seçin

Çoğu startup için iyi okunan pratik bir sıra:

1. Bu sayfa neleri kapsıyor (bir paragraflık giriş)\n
2. Hikaye + işletme ilkeleri (neden var olduğunuz, nasıl karar verdiğiniz)\n
3. Ekip + nasıl çalıştığınız (kim neyi yapıyor, nasıl inşa ediyorsunuz)\n
4. Fiyatlandırma + faturalama beklentileri (ücretlerin nasıl işlediği, uç durumlar)\n
5. Metrikler (dikkatle seçilmiş) (ne ölçtüğünüz ve neden)\n
6. Yol haritası + değişiklik günlüğü (sırada ne var, ne değişti)\n
7. Gizlilik + güvenlik (düz İngilizce) (veri işleme, temel kontroller)\n
8. Destek + güvenilirlik beklentileri (saatler, varsa SLA'lar, durum sayfası bağlantısı)

İşi satılan sektöre göre yeniden sıralayabilirsiniz (ör. düzenlemeye tabi müşterileriniz varsa güvenliği daha yukarı koyun).

Uzun sayfalar için hızlı bağlantılar ekleyin

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.

Güncelliği görünür kılın (ve sahipliği belirtin)

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.

Sorular için net bir yol sağlayı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.

Hikayenizi, Misyonunuzu ve İşletme İlkelerinizi Anlatın

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 vs. ilkeler: spesifik tutun

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.

Kısa bir kuruluş hikayesi (aşırı paylaşmadan)

Ş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.

İşletme ilkeleriniz (yazmanız için sorular)

Açık İngilizce birkaç ilke yazmak için şu soruları kullanın:

• Kararları nasıl alırsınız: Ticaret‑off ortaya çıktığında en çok ne önemlidir? (müşteri etkisi, uzun vadeli güvenilirlik, gizlilik, sadelik). Kim karar verir ve girdiyi nasıl toplarsınız?\n- Müşterilere nasıl davranırsınız: Kullanıcılarla sözleşmeden öte ne borçlusunuz? (açık iletişim, sürpriz yeniden ücretlendirme yok, dürüst süreler, yardımcı destek)\n- Hataları nasıl ele alırsınız: Olay notlarını yayınlıyor musunuz? Nasıl özür diliyorsunuz, kök nedeni düzeltiyorsunuz ve tekrarı nasıl önlüyorsunuz?

İnsanların sizi tutabileceği somut örnekler

3–5 taahhüt ekleyin, örneğin:

• Yanıt süreleri: “Destek taleplerine hafta içi 24 saat içinde yanıt veririz.”\n- Destek ilkeleri: “Hazır cevap yok; çözemiyorsak söyler ve alternatif öneririz.”\n- İade felsefesi: “İlk 14 gün memnun kalmazsanız, koşulsuz iade ederiz.” (varsa)

Gerekli yerlerde destekleyen detaylara (örn. /careers) bağlayın.

Ekibi Tanıtın ve Nasıl Çalıştığınızı Anlatı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.

Ekibin kim olduğu (ve neden önemli olduğu)

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:

• Her kişinin neyi sahipleniyor olduğu (örn. “Faturalama ve yenilemeler”, “Olay iletişimi”, “Veri talepleri”)\n- Doğru fonksiyona nasıl ulaşılacağı (paylaşılan bir posta kutusu genellikle kişisel e‑postadan iyidir)

Kişisel konum, kişisel telefon numarası gibi istenmeyen temaslara yol açacak detaylardan kaçının. Amaç hesap verebilirlik, maruz kalma değil.

Nasıl çalıştığınız (müşterilerin ne bekleyeceğini bilmesi için)

Günlük iş birliğinin nasıl olduğunu açıklayan kısa bir “çalışma ilkeleri” bölümü ekleyin:

• Uzaktan, ofiste veya hibrit mi—ve bunun yanıt süreleri için ne anlama geldiği\n- İletişim normları (önce asenkron iletişim, haftalık planlama, müşteri geri bildirim döngüleri)\n- Kararlar nasıl alınıyor (kim karar veriyor, ne zaman girdiyi toplarsınız, değişiklikler nasıl belgelenir)

Bu, neden bazı taleplerin hızlı ilerlediğini diğerlerinin incelenmesi gerektiğini anlamaya yardımcı olur.

İşe alım: aşırı detay vermeden beklentileri ayarlayın

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 ve Faturalama Beklentilerini Netleştirin

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.

Planları bir arkadaşınıza anlatır gibi açıklayın

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:

• Starter: ürünü hafif kullanım için deneyen bireyler için\n- Team: birlikte çalışan küçük ekipler için\n- Business: daha fazla kontrol, raporlama veya öncelikli destek isteyen büyük organizasyonlar için

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).

İnsanları genellikle şaşırtan faturalama koşullarını belirtin

Şu temel konuları tek yerde açıklayın:

• Faturalama aylık ve/veya yıllık mi\n- Deneme veriyor musunuz (bitince ne oluyor)\n- İptaller nasıl işliyor (dönem sonuna kadar vs. anında)\n- Vergiler (KDV/GST) uygulanabilir mi

Bunlar plan veya bölgeye göre değişiyorsa, baştan söyleyin.

Eklentiler, limitler ve yükseltmeler

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.

Fiyat değişikliklerini nasıl ele alırsınız

İ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.

Metrikleri Dikkatle Paylaşın (Neleri Yayınlamalı ve Nasıl)

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.

Güvenli ve yanlış yorumlanması zor metrikleri seçin

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:

• Aralıklar (örn. “destek kapsaması: 10–20 saat/hafta”)\n- Yönsel eğilimler (örn. “çeyrekten çeyreğe churn iyileşti”)\n- Kilometre taşları (örn. “1.000 haftalık aktif ekip eşiğini geçtik”)

Okuyucuların gerçekten önem verdiği örnekler

Küçük bir operasyonel metrik seti genelde işe yarar:

• Erişilebilirlik hedefi (örn. “aylık hedef %99.9”) ve nerede takip edildiği\n- Destek yanıt süresi (hafta içi/hafta sonu için ilk yanıt hedefleri)\n- Ürün kullanım kilometre taşları (haftalık aktif ekipler, oluşturulan projeler—tek bir metriğe odaklanın)\n- Churn yönü (iyileşiyor/durağan/kötüleşiyor), her zaman kesin oran vermek zorunda değilsiniz

Bağlam ekleyin: ne anlama geldiği ve nasıl ölçüldüğü

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.

Ölçüm sınırlamaları ve değişiklikleri ekleyin

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 Basit Bir Değişiklik Günlüğü Yayınlayın

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.

Hızınıza uyan bir yol haritası formatı seçin

Hafif tutun. Üç yaygın seçenek:

• Now / Next / Later: basit, dost canlısı ve güncel tutması kolay.\n- Herkese açık yol haritası sayfası: temalar ve birkaç ana madde ile özel bir sayfa.\n- Çeyreklik hedefler: özellik listeleri yerine daha yüksek seviyeli çıktılar (örn. “Onboarding tamamlanma oranını iyileştirmek”).

Ayrı sayfalar tutuyorsanız, bunları şeffaflık sayfasından net şekilde bağlayın (örn. /roadmap).

Yol haritası maddelerinin ne anlama geldiğini açıklayın

Yol haritası öğeleri niyet olarak çerçevelenmeli, vaat olarak değil. En üstte kısa bir not ekleyin:

• Öğeler müşteri öğrenimleri, güvenilirlik ihtiyaçları veya teknik kısıtlar nedeniyle değişebilir.\n- Tarihler varsa “hedef” veya “amaçlanan” olarak tanımlanmalı, garanti değil.\n- Bir öğe artık doğru problemi çözmüyorsa kaldırılabilir.

Bu paragraf hayal kırıklığını önler ve öncelikler değiştiğinde güveni korur.

Müşterinin gerçekten okuyacağı bir değişiklik günlüğü ekleyin

Değişiklik günlüğü her küçük düzeltmeyi içermek zorunda değil. Şunlara odaklanın:

• Büyük sürümler ve anlamlı iyileştirmeler\n- Kullanıcı deneyimini etkileyen önemli düzeltmeler\n- Kaldırılmalar (ne değişiyor, ne zaman ve müşterinin ne yapması gerekiyor)

Girişleri kısa tutun ve derinlemesine belge varsa ona bağlayın. Başka yerde yaşıyorsa /changelog sayfasına bağlayın.

Özellik isteklerini talep etmeyi kolaylaştırın (ama aşırı söz verme)

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.

Veri, Gizlilik ve Güvenliği Düz İngilizceyle Açıklayın

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.

Kısa bir özetle başlayın

Ü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:

• Ne topluyoruz: hesap bilgileri (e‑posta), ürün kullanım olayları ve faturalama bilgileri (ödeme sağlayıcısı tarafından işlenir)\n- Ne toplamayız: ürününüzde sakladığınız içerik (doğruysa) veya hassas kişisel veriler (doğruysa)\n- Neden topluyoruz: servisi çalıştırmak, kötüye kullanımı önlemek ve özellikleri geliştirmek

Sonra tam versiyon için doğrudan /privacy ve /terms sayfalarına yönlendirin.

Kullanıcıların önem verdiği detayları kapsayın

Aşağı konularda spesifik olun:

• Saklama: loglar, yedekler ve silinmiş hesap verilerinin ne kadar süre saklandığı\n- Alt işlemciler: hizmeti çalıştırmanıza yardımcı olan satıcılar (barındırma, analitik, e‑posta) ve ne yaptıkları\n- Erişim kontrolleri: şirket içinde kimlerin müşteri verilerine erişebildiği ve hangi koşullarda (destek talepleri, hata ayıklama)

“Güvenliği ciddiye alıyoruz” gibi belirsiz ifadelerden kaçının—pratik temel uygulamaları anlatın.

Risk artırmadan güvenlik duruşunu paylaşı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.

Güvenlik sorunlarını bildirmek için net bir yol ekleyin

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.

Destek ve Güvenilirlik İçin Beklentileri Belirleyin

Ş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.

Destek kanalları (ve ne zaman kullanılacağı)

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 ve acil durumlar

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.

Olay iletişimi ve erişilebilirlik

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.

İadeler ve şikayetler

İ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.

Güncel Tutun: Güncelleme Sıklığı ve Sahiplik

Ş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.

Bir sahibi (ve bir yedeği) atayın

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ışı:

• Sahip: girdileri toplar, değişiklikleri taslaklar ve güncelleme takvimini tutar.\n- İnceleyen: doğruluk ve tonu kontrol eder (genelde kurucu veya fonksiyon lideri).\n- Yayınlayan: değişiklikleri yayına alır (küçükseniz sahibi bu kişi olabilir) ve sayfanın güncelleme kaydına not düşer.

Sahibi sayfada (veya iç dokümanda) rol bazında adlandırın ki “herkesin işi” olup kimsenin işi haline gelmesin.

İnsanların güvenebileceği bir güncelleme ritmi belirleyin

Gerçekçi bir takvim seçin:

• Aylık güncelleme: fiyat/ yol haritası sık değişen erken aşama ekipler için iyi.\n- Çeyreklik özet: metriklerin stabil ve karşılaştırılabilir olması gereken sayfalar için uygun.

En üste görünür bir “Last updated” satırı ekleyin.

Küçük bir sayfa güncelleme kaydı 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.

Hafif sürümlendirme kullanın

Sayılar değiştiğinde kafa karışıklığını önlemek için güncellemeleri ya:

• Aylık roll‑forward: “Her ayın 1'inde güncellenir.”\n- Çeyreklik sürüm: “Q3 2026 snapshot” ve önceki çeyreğe link verin.

Bu, okuyucuların neye baktıklarını anlamasına ve “neden değişti?” tartışmalarını azaltmaya yardımcı olur.

Yayınlamadan önce doğrulayın

Kısa bir yayın öncesi kontrol listesi tutun:

• Rakamlar doğruluk kaynağıyla eşleşiyor (faturalama sistemi, analitik, finans tablosu)\n- Tarihler doğru (fiyat geçerlilik tarihi, politika revizyon tarihi)\n- İddialar hâlâ doğru (“7/24 destek”, “SOC 2 yapılıyor” vb.)\n- Linkler çalışıyor ve doğru iç sayfalara işaret ediyor (örn. /pricing, /security)

Hassas güncellemeleri yönetme

Her şey hemen veya tam detayla paylaşılmamalı. Gerekirse birini seçin:

• Erteleme: düzeltme veya yasal inceleme sonrasına yayınlamak\n- Toplama: tam rakamlar yerine aralıklar veya yüzdeler paylaşmak\n- Atlama: yayınlamak risk oluşturuyorsa, neden paylaşmadığınızı açıklayın

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.

Yazma, Tasarım ve Yayınlama: Pratik Bir Kontrol Listesi

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.

CMS‑dostu biçimlendirme (güncellemeler acı vermesin diye)

• Bölümleri kısa tutun (3–6 cümle) ve net H3 alt başlıkları kullanın.\n- Tekrarlanabilir modüller kullanın: callout, tablolar ve SSS.

Erişilebilirlik temelleri (hızlı kazanımlar)

• Mantıklı başlık sırası kullanın: H2 → H3 (seviyeleri atlamayın).\n- Metin kontrastının okunabilir olduğundan ve font boyutunun rahat olduğundan emin olun.\n- Açıklayıcı link metni yazın (“bkz. /pricing” yerine “fiyatlandırma sayfasına bakın” yerine açıklayıcı metin kullanın).

SEO temel kuralları (aşırı optimize etmeden)

• Title tag: “Transparency | {Company Name}”\n- Meta açıklama (1–2 cümle): ne bulacakları (fiyat beklentileri, yol haritası, güvenlik, destek)\n- Destekleyici sayfalara dahili linkler ekleyin: /pricing, /security, /privacy, /status, /blog\n- Eğer SSS eklediyseniz, Organization ve FAQPage şeması düşünebilirsiniz.

Sayfayı hızlıca uygulayın (bakımı zorlaştırmadan)

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.

CMS için kopyala‑yapıştır şablonu

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ın öncesi kontrol listesi

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.