Okuma Makbuzlu Dahili Duyurular Web Uygulaması Oluşturun

Kullanım Durumunu ve Başarı Metriklerini Tanımlayın

Dahili bir duyuru web uygulaması basit ama maliyetli bir sorunu çözer: önemli güncellemeler kaçırılıyor ve kimse "Herkes bunu gördü mü?" sorusuna güvenle cevap veremiyor. E-posta dizileri, sohbet kanalları ve intranet gönderileri gürültü yaratır; özellikle politika değişiklikleri, güvenlik bildirimleri, ofis kapanışları ve fayda son tarihleri gibi konularda hesap verebilirlik bulanıklaşır.

Okuma makbuzları yerleşik olduğunda sonuç "gönderdik"ten "okunduğunu doğrulayabiliyoruz"ya kayar. Bu netlik ekiplerin daha hızlı hareket etmesine yardımcı olur, tekrar eden soruları azaltır ve İK ile yöneticilere tahmin yürütmeden takip etme imkânı verir.

Bu uygulama kimler için?

Bu sadece bir İK aracı değildir. Farklı grupların farklı sebeplerle kullandığı bir çalışan iletişim sistemi olabilir:

• İK: politika güncellemeleri, açık kayıt hatırlatmaları, zorunlu eğitim bildirimleri
• BT/Güvenlik: olay iletişimleri, şifre döndürme hatırlatmaları, oltalama uyarıları
• Yöneticiler/Operasyon: vardiya değişiklikleri, ofis erişim güncellemeleri, süreç değişiklikleri
• Tüm çalışanlar: önemli olanı okuyacakları tek, öngörülebilir bir yer ve gerektiğinde bunu onaylama imkânı

Kilitleyici nokta şudur: her hedef kitle fayda sağlar — yayıncılar ne olduğunu bilir, çalışanlar da kritik duyuruları kaçırmamak için nereden bakacaklarını bilir.

Temel çıktı: net erişim + doğrulanmış okumalar

Uygulamanın amacını tek cümlede tanımlayın: doğru çalışanlara ana duyuruları iletmek ve kimlerin okuduğunu doğrulamak.

Bu, daha sonra vereceğiniz birkaç ürün kararını (hedefleme, rol tabanlı erişim kontrolü, denetim izi) ima eder, ancak "neden"i net tutun. Bir okuma makbuzunun kuruluşunuz için neden önemli olduğunu açıklayamıyorsanız, hangi veriyi saklayacağınızı ve ne tür raporlama yapacağınızı belirlemekte zorlanırsınız.

İlk günden takip edilecek başarı metrikleri

Teslim etkinliğini ve çalışan davranışını yansıtan metrikler seçin:

• Reach rate: Hedeflenen kitlenin yüzde kaçı duyuruyu başarılı şekilde aldı (örn. uygulamada gördü, bildirim aldı veya beslemelerinde göründü)?
• Read rate: Hedeflenen kitlenin yüzde kaçı için bir okuma makbuzu kaydı var?
• Time-to-read: Yayınlanmadan ilk okuma ve %80–90 okunma zamanları

Duyuru türüne göre hedefler belirleyin. "Ücretsiz öğle yemeği Cuma" gönderisi ile "yeni güvenlik gereksinimi" gönderisi aynı hedefi paylaşmamalı. Kritik mesajlar için 24–48 saat içinde %95 okuma gibi hedefler koyabilir ve bu hedefi bildirimler ile takip eylemlerini şekillendirmek için kullanabilirsiniz.

Eğer bir kuzey yıldızı metriği seçmek isterseniz: kritik duyuruların belirlenen süre içinde tam hedef kitle tarafından okunma yüzdesi kullanılabilir.

Gereksinimleri Toplayın ve Özellik Kapsamını Belirleyin

Net bir kapsam, duyurular uygulamanızın "her şeyi yapan" bir portale dönüşmesini önler. Kimlerin kullanacağını (iletisim, İK, BT, yöneticiler, her çalışan) ve başarının nasıl göründüğünü (örn. kritik güncellemelerin 24 saat içinde onaylanması) yazın.

Zorunlular ile isteğe bağlıları ayırın

İlk sürümü, temel problemi çözen şekilde tanımlayın: hedeflenmiş duyuruları yayınlama ve okunduğunu doğrulama.

V1 zorunlu özellikler:

• Duyuruları oluşturma ve yayınlama
• Temel biçimlendirme (başlık + gövde) ve zamanlama (isteğe bağlı)
• takımlar, lokasyonlar, bölümler veya tüm şirket bazlı hedefleme
• Okuma makbuzları: kullanıcı başına, duyuru başına, zaman damgalarıyla
• Kimlerin yayınlayabileceğine dair basit yönetici kontrolleri
• Arama ve denetime uygun temel etkinlik kaydı (kim yayınladı/düzenledi)

İleride eklenebilecekler:

• Zengin editör (tablolar, gömüler), ekler ve şablonlar
• Onay akışları (taslak → inceleme → yayın)
• Tepkiler/yorumlar
• Çok dilli içerik
• Gelişmiş analizler ve dışa aktarım

Kapsamı hızlı doğrulamak istiyorsanız, hedefleme, makbuz mantığı ve panoların zor kısımlarını riski azaltmak için hızlı bir prototip yapın. Örneğin ekipler genellikle Koder.ai kullanarak sohbet üzerinden bir dahili web uygulamasını hızla oluşturur — sonra akışları (besleme, detay görünümü, onaylama) yineleyip gereksinimler stabil olduğunda kaynak kodunu dışa aktarırlar.

Duyuru türlerini ve kurallarını tanımlayın

Farklı duyurular farklı beklentiler gerektirir. Başlangıçta küçük bir tür setinde anlaşın:

• Genel: bültenler, kültür güncellemeleri. Zorunlu onay yok.
• Acil: güvenlik olayları, ofis kapanışları. Onay gerektirir ve hatırlatmalar yükseltilir.
• Politika: el kitabı güncellemeleri, uyumluluk bildirimleri. Onay gerektirir ve denetim izi tutulur.
• BT bakım: kesintiler, planlı duruşlar. Zaman sınırlı ve genellikle lokasyon/takım bazlı hedeflenir.

Her tür için gerekli alanları (sona erme tarihi, onay gerekliliği, öncelik) ve kimlerin yayınlama yetkisine sahip olduğunu belirleyin.

Okuma makbuzu beklentilerini erken kilitleyin

Mühendislik ve paydaşların hizalanması için net olun:

• "Okundu" sayılan etkinlik nedir: duyuruyu açmak mı, içeriğin altına kadar kaydırmak mı, yoksa "Acknowledge"a tıklamak mı?
• Saklanacak zaman damgaları: ilk görüntüleme, onaylanma ve isteğe bağlı son görüntüleme
• Kenar durumlar: çoklu cihazlar, çevrimdışı görüntüleme ve düzenlenen duyurular (makbuzlar sıfırlanır mı?)

Bu kapsam belgesi, yeni istekler geldiğinde yapım planınız ve değişiklik kontrol referansınız olur.

Kullanıcı Rollerini ve İzinleri Tasarlayın

Net roller ve izinler, duyuruların güvenilir kalmasını sağlar, yanlışlıkla şirket çapında gönderimleri engeller ve makbuzların daha sonra sorgulanabilir olmasını sağlar.

Önerilen roller

Admin: sistemi yönetir — kullanıcı sağlama, organizasyon ayarları, saklama kuralları ve entegrasyonlar. Adminler her gün duyuru yazmak zorunda değildir.

Publisher: duyuruları oluşturur ve yayınlar. Genellikle İletişim, İK veya BT ekipleridir.

Manager: kendi takımı için taslak oluşturabilir veya yayın isteğinde bulunabilir ve kendi sahip olduğu (veya raporlama hattına ait) duyuruların makbuzlarını görebilir.

Employee: duyuruları okur ve (gerekirse) onaylar. Çalışanlar genellikle başkalarının makbuzlarını görmemelidir.

Auditor (opsiyonel): yayınlanmış duyurulara, denetim izine ve dışa aktarımlara salt okunur erişim için kullanılır.

İzin seti (açık tutun)

En azından şu eylemler için izin tanımlayın: create, edit, publish, archive, view receipts ve export. İzinleri rol bazlı değil, eylem düzeyinde uygulamak iyi bir pratiktir; böylece gelecekte mantık yeniden yazmadan uyarlamalar yapabilirsiniz.

Pratik bir varsayılan:

• Yayıncılar: create/edit/publish/archive; view receipts; export.
• Yöneticiler: kendi taslaklarını oluşturup düzenleyebilir; sadece önceden onaylanmış kategoriler için yayınlayabilir (veya hiç yayınlamayabilir); kapsamları için makbuzları görebilir.
• Adminler: kullanıcı/ayarları yönetir; acil durumlarda yayın yapabilir (kayıtlı).
• Denetçiler: makbuzları görür + dışa aktarır; create/edit/publish yok.

Görev ayrımı

Eğer onaylar önemliyse, taslak oluşturma ile yayınlamayı ayırın:

• Yöneticiler taslak oluşturur; Yayıncılar onaylar ve yayınlar.
• Hassas konularda (politika, güvenlik) yayın öncesi ikinci bir onay gerektirin.

Erken karar verilmesi gereken kenar durumlar

• Yükleniciler: görünürlüğü sınırlayın; dışa aktarmaları kısıtlayın.
• İşten ayrılanlar: erişimi hemen kaldırın, ancak raporlama için makbuz geçmişlerini saklayın.
• Misafir hesaplar: süreli erişim ve kısıtlı kategoriler.

Bu kuralları kısa bir “erişim politikası” sayfasında belgeleyin ve kurum içi olarak gösterin (örneğin /help/access-policy).

Kullanıcı Deneyimini ve Temel Ekranları Haritalandırın

Özellikleri çizmeye başlamadan önce anları çizin: bir çalışanın 10 saniye içinde ne yapması gerektiğini ve bir yöneticinin eğitim olmadan ne yapması gerektiğini düşünün. Net bir UX, makbuzlar eklendiğinde "Görmedim" anlaşmazlıklarını azaltır.

Temel ekranlar (ilk sürümü küçük tutun)

Giriş sürtünmesiz olmalı: tek tıklamalı oturum açma (varsa), net hata durumları ve kullanıcının kaldığı yere doğrudan dönüş.

Besleme (Feed) ana merkezdir. Taramayı önceliklendirin: başlık, kısa önizleme, kategori/etiket, hedefleme rozeti (isteğe bağlı) ve durum (Okunmadı/Okundu/Onay gerekli). Basit bir "Okunmadı" filtresi ve bir arama çubuğu ekleyin.

Duyuru detayı makbuzların kazanıldığı yerdir. Tam içeriği, ekleri/bağlantıları ve belirgin bir okuma durumunu gösterin. Otomatik "açınca okundu" cazip olabilir, ama kazara açılmaları da düşünün. Onay gerekiyorsa, "Okundu" ile "Onayla"yı ayırın ve net ifadeler kullanın.

Yazma (Compose) hafif bir editör gibi hissettirmeli: başlık, gövde, hedef kitle seçici, yayın zamanlaması ve önizleme. Gelişmiş seçenekleri çökertilmiş tutun.

Admin ilk etapta tek sayfada başlayabilir: kullanıcıları/rolleri yönet, gruplar oluştur ve duyuru performansını görüntüle.

Erken test edilmesi gereken kritik akışlar

• Yayınlama: taslak → önizleme → yayınla (veya zamanla) → onay
• Okuma: beslemeden/bildirimden aç → okuma durumu güncellenir → isteğe bağlı onaylama
• Arama: başlık ve gövde içinde anahtar kelime araması, net "sonuç yok" mesajı

Erişilebilirlik ve mobil öncelikli temel kurallar

Okunabilir tipografi, güçlü kontrast ve görünür odak çerçeveleri kullanın. Tüm eylemlerin klavye ile çalıştığından emin olun.

Mobilde hızlı okumalar için tasarlayın: büyük dokunma hedefleri, (gerektiğinde) yapışkan bir "Onayla" düğmesi ve içeriği engellemeyen yükleme durumları.

Veri Modelini Planlayın (Hedef Kitleyi Dahil Et)

Net bir veri modeli okuma makbuzlarını güvenilir kılar, hedeflemeyi öngörülebilir kılar ve raporlamayı hızlı yapar. Çok sayıda tabloya gerek yok—sadece birkaç iyi seçilmiş varlık ve bunların ilişkileri için kurallar yeterlidir.

Temel varlıklar (sakladıklarınız)

En azından şu varlıkları modelleyin:

• User: bir çalışan hesabı (id, isim, e-posta, durum)
• Group/Team: departman veya lokasyon temelli grup (id, isim)
• Announcement: mesajın kendisi
• Audience: kimin alacağı (hedef tanımı)
• Receipt: teslim/okuma durumunu izlemek için kullanıcı başına bir satır
• Attachment: isteğe bağlı dosyalar

İlan/Soru alanları: gerçek iş akışlarını destekleyecek alanlar

Announcement için şunları dahil edin:

• title ve body (gövdeyi zengin metin veya Markdown olarak saklayın; tutarlılığı koruyun)
• priority (normal/önemli/acıL) — UI ve bildirim davranışı buna göre değişir
• publish_at (zamanlanmış yayın)
• expire_at (bitiş tarihi)

Ayrıca ileride isteyebileceğiniz metadata: created_by, updated_by, status (draft/scheduled/published) ve zaman damgaları. Bu, denetim için ekstra tablolar olmadan destek sağlar.

Hedefleme: üç pratik yaklaşım

Hedefleme birçok dahili araçta karışıklık yaratır. Erken bir strateji seçin:

1. Açık kullanıcı listesi: duyuru için kesin kullanıcı ID setini saklayın.

   Küçük, kesin kitleler için iyidir. Büyük organizasyonlarda yönetimi zordur.

2. Grup filtreleri: "Team = Support" veya "Location = Berlin" gibi kuralları saklayın.

   Tekrarlayan desenler için iyidir, ama insanlar takımdan ayrıldıkça kitle değişir.

3. Snapshotlar (makbuzlar için önerilen): yazımda filtreleri saklayın, sonra yayın zamanında bunları sabit bir alıcı listesine çözün.

   Bu, raporlamayı ve makbuzları stabil tutar: hedeflenen kişiler yayın anında kimseyse onlardır; birisi daha sonra takımdan ayrılırsa rapor değişmez.

Okuma makbuzları doğru indekslere bağlıdır

Makbuzlar hızla büyüyebilir. Sorgulamayı kolaylaştırın:

• receipts tablosunda (announcement_id, user_id) üzerinde benzersiz bir indeks ekleyin.

Bu, yinelenmeleri önler ve yaygın ekranları hızlı hale getirir (örn. "Alex bunu okudu mu?" veya "Duyuru #42 kaç okunma aldı?").

Okuma Makbuzlarını Doğru Uygulayın

Okuma makbuzları basit görünür ("okudu mu?"), ama ayrıntılar raporlamanın güvenilir olup olmayacağını belirler. Önce "okundu"nun ne olduğunu tanımlayın—sonra bu tanımı tutarlı şekilde uygulayın.

"Okundu" ne anlama gelir diye tanımlayın

Birincil bir sinyal seçin ve ona sadık kalın:

• Duyuru detay görünümünü açmak (en yaygın; ölçmesi kolay)
• İçeriği kaydırmak (uzun gönderiler için daha doğru sinyal ama uygulaması zor)
• “Acknowledge” düğmesine tıklamak (en güçlü sinyal çünkü kasıtlıdır)

Birçok ekip hem read hem de acknowledged izler: “read” pasif, “acknowledged” kasıtlı bir onaydır.

Makbuzları birincil kayıtlar olarak saklayın

Kullanıcı başına duyuru başına ayrı bir makbuz kaydı oluşturun. Tipik alanlar:

• user_id
• announcement_id
• read_at (zaman damgası, nullable)
• acknowledged_at (zaman damgası, nullable)

device_type, app_version veya ip_hash gibi isteğe bağlı tanılama bilgilerini yalnızca gerçekten ihtiyaç varsa ve politika onayı varsa ekleyin.

Çift sayımdan kaçınmak için (user_id, announcement_id) üzerinde benzersiz bir kısıtlama uygulayın ve makbuz güncellemelerini upsert şeklinde ele alın. Bu, tekrarlı açılmalar, yenilemeler veya bildirim tıklamalarından kaynaklanan hatalı "okunma" sayılarını önler.

Düzenlemelerle kafa karışıklığını yönetin

Duyurular sıklıkla güncellenir. Düzenlemelerin makbuzları sıfırlayıp sıfırlamayacağına önceden karar verin:

• Küçük düzenlemeler (yazım, format): makbuzları koruyun.
• Önemli değişiklikler (politika güncellemeleri): versiyonlama düşünün.

Basit bir yaklaşım, makbuz üzerinde announcement_version (veya content_hash) saklamaktır. Versiyon değişirse ve değişiklik "yeniden onay gerektirir" olarak işaretlendiyse acknowledged_at(ve isteğe bağlı read_at) temizlenebilir; geçmiş versiyonların denetim izi tutulur.

Doğru yapıldığında, makbuzlar güvenilir bir ölçü haline gelir — izleme veya tutarsız veriye dönüşmeden.

Basit, Bakımı Kolay Bir Teknoloji Yığını Seçin

Sürdürülebilir bir dahili duyuru uygulaması, en yeni araçları kovalamaktan çok, ekibinizin yıllarca çalıştırabileceği iyi belgelenmiş, geniş bir yetenek havuzu olan ve barındırması basit parçalardan seçim yapmaktır.

Önerilen temel: web framework + ilişkisel veritabanı

Kanıtlanmış bir temel, yaygın bir web framework'ü ile ilişkisel veritabanıdır:

• Framework seçenekleri: Django, Ruby on Rails, Laravel, ASP.NET veya Express/NestJS.
• Veritabanı seçenekleri: PostgreSQL (varsayılan için harika) veya MySQL.

İlişkisel veritabanları, duyuruları, hedef kitleleri ve makbuz kayıtlarını açık ilişkiler, kısıtlar ve raporlamaya uygun sorgularla modellemeyi kolaylaştırır.

Daha hızlı hareket etmek isterseniz, modern bir default stack olarak Koder.ai genellikle React ön uç, Go arka uç ve PostgreSQL oluşturur — el ile her CRUD ekranı ve izin kontrolünü sıfırdan yazmak istemediğinizde sürdürülebilir bir başlangıç sağlar.

API tarzı: duyurular ve makbuzlar için REST uç noktaları

Sunucu tarafı render edilmiş bir uygulama bile inşa ediyor olsanız, UI ve gelecekteki entegrasyonlar için temiz REST uç noktaları tanımlayın:

• GET /announcements (liste + filtreler)
• POST /announcements (oluştur)
• POST /announcements/{id}/publish (yayın akışı)
• POST /announcements/{id}/receipts (okundu olarak işaretle)
• GET /announcements/{id}/receipts (raporlama görünümleri)

Bu, sorumlulukları net tutar ve ileride denetimi kolaylaştırır.

Gerçek zamanlı ihtiyaçlar: websocket veya polling (isteğe bağlı)

Gerçek zamanlı güzel ama zorunlu değil. Anında "yeni duyuru" rozetleri gerekiyorsa düşünün:

• Basit polling her 30–60 saniye (genellikle yeterli)
• WebSockets/SSE daha büyük organizasyonlar veya yüksek aciliyet için

Kullanıcılar gecikmeyi fark etmedikçe önce polling ile başlayın; yükseltin.

Ekler için dosya depolama

Büyük dosyaları veritabanında saklamaktan kaçının. Nesne depolama (S3 uyumlu) tercih edin ve sadece metadata (dosya adı, boyut, URL, izinler) veritabanında tutun. Ekler nadir ve küçükse yerel depolama ile başlayıp sonra taşıyabilirsiniz.

Kimlik Doğrulama ve Güvenli Erişim Kurun

Kimlik doğrulama uygulamanın kapı girişidir — bunu erken doğru kurun ki tüm diğer özellikler (hedefleme, makbuzlar, analiz) aynı güven modelini miras alsın.

Kimlik yöntemi seçimi: SSO vs e-posta/parola

Çoğu işyeri için SSO varsayılantır çünkü parola riskini azaltır ve çalışanların zaten kullandığı oturum açma modeliyle eşleşir.

• SSO (SAML veya OIDC): Okta, Azure AD, Google Workspace gibi bir kimlik sağlayıcınız varsa en iyisidir. Genellikle doğrulanmış öznitelikler alırsınız (e-posta, isim) ve bazen grup/bölüm claimleri rol eşleştirmesi için kullanılabilir.
• E-posta/parola (yalnızca gerekliyse): Başlangıçta daha basit olabilir ama güvenlik sorumluluğunu artırır (parola depolama, sıfırlamalar, MFA beklentileri). Desteklemek zorundaysanız, kanıtlanmış bir kütüphane kullanın ve güçlü parolalar + isteğe bağlı MFA zorunlu tutun.

Oturumlar, tokenlar ve süreler

Tek bir yaklaşım seçin ve uygulama genelinde tutarlı olun:

• Sunucu oturumları (cookie-based): Mantık kurması kolay. HttpOnly, Secure ve SameSite=Lax/Strict çerezleri kullanın. Oturum ID'lerini giriş ve yetki değişimlerinde döndürün.
• JWT/OIDC erişim tokenları: API'ler ve SPA'lar için kullanışlı. Erişim tokenlarını kısa ömürlü tutun (örn. 15 dakika) ve yenileme tokenlarını döndürme ve iptal ile yönetin.

Ayrıca hem hareketsizlik zaman aşımı hem de mutlak oturum ömrü tanımlayın ki paylaşılan cihazlarda oturumlar sonsuza kadar açık kalmasın.

Her uç noktayı yetkilendirin (özellikle makbuzları)

Kimlik doğrulama kimliği ispat eder; yetkilendirme yetkiyi kanıtlar. Şunlarda yetki kontrolleri uygulayın:

• Her create/edit/publish duyuru uç noktası
• Her receipt write uç noktası (bir kullanıcı yalnızca kendi okuma durumunu işaretleyebilmeli)
• Her receipt report/export uç noktası (politikaya göre adminler/yöneticiler ile sınırlayın)

Bu kontrolleri UI ipucundan ziyade sunucu tarafında zorunlu kurallar olarak ele alın.

Oran sınırlama ve temel kötüye kullanım koruması

İç uygulamalar bile korumaya ihtiyaç duyar:

• Giriş denemelerini ve makbuz yazma uç noktalarını oranla sınırlandırın ki kaba kuvvet veya gürültülü istemciler engellensin.
• Cookie tabanlı oturumlar için CSRF koruması ekleyin.
• Güvenlikle ilgili olayları (başarısız girişler, token yenileme hataları, izin reddleri) kaydedin ki denetim mümkün olsun.

Duyuru Oluşturucu ve Yayın Akışını Oluşturun

İyi bir oluşturucu şatafatlı biçimlendirmeden çok hataları önlemeye odaklanır. Her duyuruyu küçük bir yayın süreci gibi ele alın: net sahiplik, öngörülebilir durumlar ve tarihçe karışıklığı olmadan sorunları düzeltme yolu.

Taslak → İnceleme → Yayın → Arşiv

Basit, görünür bir durum modeli kullanın:

• Draft: yazar serbestçe düzenler; çalışanlara görünmez.
• Review: İK/Hukuk/BT için isteğe bağlı kontrol noktası; gözden geçirenler yorum yapabilir veya değişiklik isteyebilir.
• Published: içerik kilitlenir (veya düzenlemeler yeni bir versiyon gerektirir); teslim kurallarına uygun hale gelir.
• Archived: ana görünümlerden gizlenir ama arama ve denetim için saklanır.

Hesap verebilirlik için kimlerin hangi duruma ne zaman taşıdığı bilgilerini saklayın (okuması kolay bir denetim izi).

Zamanlama ve sona erme

Zamanlama "şimdi gönder" baskısını azaltır ve küresel ekipleri destekler.

• publish_at: bu zaman geldiğinde duyuru görünür olur; öncesinde yetkisi olan adminler dışında taslak gibi davranır.
• expire_at: bu zamandan sonra ana beslemede gösterilmez ve bildirim tetiklemez. Referans için arşivde erişilebilir kalır.

UI'de geçerli zaman dilimini açık gösterin ve expire_at < publish_at ise uyarı verin.

Biçimlendirmeyi basit tutun

Bir içerik formatı seçin ve ona sadık kalın:

• Düz metin en güvenli ama sınırlı.
• Markdown hafif yapı sunar ve karmaşıklığı düşük tutar.
• Zengin metin dostça görünür ama tutarsız stil ve kopyala-yapıştır sorunları yaratabilir.

Çoğu ekip için temel Markdown (başlıklar, maddeler, bağlantılar) pratik bir orta yoldur.

Ekler: açık kurallar, az sürpriz

Ek destekliyorsanız beklentileri baştan belirleyin:

• İzin verilen dosya türleri (örn. PDF, PNG/JPG, DOCX)
• Boyut sınırları (dosya başına ve duyuru başına)
• Dosya adı temizleme ve indirme izinleri

Depolama sağlayıcınızda virüs tarama varsa etkinleştirin; yoksa çalıştırılabilir türleri kısıtlayın ve yüklemeleri takibe alın.

Teslimat ve Bildirim Seçenekleri Ekleyin

Teslimat "yayınladık" ile "çalışanlar gerçekten gördü" arasındaki köprüdür. Birkaç net kanal, tutarlı kurallar ve kolay anlaşılır tercihlerle başlayın.

İnsanlar yeni duyuruları nasıl keşfeder

Önce uygulama içi deneyimle başlayın: başlıkta "Yeni" rozeti, okunmamış sayısı ve okunmamış öğeleri öne çıkaran bir besleme. Bu sistemi kendi içinde tutmak, gelen kutulara bağımlılığı azaltır.

Sonra uygulamada aktif olmayan kullanıcılar için e-posta bildirimleri ekleyin. E-postaları kısa tutun: başlık, ilk satır ve duyuru detayına giden tek bir düğme.

Push bildirimleri opsiyonel olmalı (daha sonra); cihazlar arasında karmaşıklık ekler. Eğer eklerseniz, push'ı ek kanal olarak değerlendirin — tek kanal olarak değil.

Mantıklı bildirim tercihleri

Kullanıcılara kontrol verin ama ayarları aşırı karmaşık yapmayın:

• Kullanıcı başına tercihler: "Sadece uygulama içi", "E-posta", (ve varsa "Push")
• Kategori bazlı tercihler: örn. İK, BT, Operasyon

Basit bir kural işe yarar: herkes için varsayılan olarak uygulama içi + önemli kategoriler için e-posta açık olsun; kullanıcılar isteğe bağlı olarak azaltabilsin (yasal olarak zorunlu bildirimler hariç).

Acil duyurular ve onaylar

Acil gönderiler görsel olarak farklılaştırılmalı ve okunana kadar üstte sabitlenebilir. Politika gerektiriyorsa, normal okuma makbuzundan ayrı bir "Acknowledge" düğmesi ekleyin ki açık onayı raporlayabilesiniz.

Spam ve bildirim yorgunluğunu önleme

Koruyucu önlemler ekleyin: kitlesel e-postaları hız sınırlayın, acil gönderimler için yükseltilmiş izin isteyin ve yöneticilere "haftada limitli acil gönderim" veya "göndermeden önce alıcı sayısını önizle" gibi kontroller sağlayın. Bu, bildirim sisteminin güvenilir kalmasını sağlar.

Okuma Makbuzları için Raporlama ve Analiz

Okuma makbuzları, pratik soruları yanıtladığında işe yarar: "Doğru kişilere ulaştı mı?" ve "Hâlâ kimlere hatırlatma gitmeli?" Yayıncıların gerçekten ihtiyaç duyduğu bilgileri sade, hızlı anlaşılır tutun.

Yayıncı panosu: temel sayımlar

Başlangıç için duyuru başına tek bir pano görünümüyle üç sayı gösterin:

• Delivered (teslimi denenmiş uygun kullanıcılar)
• Read (tanımınıza göre açanlar/onaylayanlar)
• Unread (delivered - read)

Eğer olayları saklıyorsanız, bu sayımları receipt tablosundan hesaplayın; mantığı UI'ye karıştırmayın. Ayrıca yayıncıların güvenmesi için küçük bir "son güncelleme" zaman damgası gösterin.

Organizasyonların nasıl çalıştığını yansıtan filtreler

Gerçek operasyonel dilde filtreler ekleyin ama uygulamayı BI aracına dönüştürmeyin:

• Takım/bölüm
• Lokasyon/şantiye
• Rol
• Tarih aralığı (duyurular ve okumalar için)

Filtre uygulandığında aynı delivered/read/unread özetini tutun ki segmentleri karşılaştırmak kolay olsun.

Dışa aktarma: paylaşılabilir, minimal ve güvenli

CSV dışa aktarımı denetimler ve takipler için yararlı ama en az veriyi içermeli. İyi bir varsayılan:

• Announcement ID/başlık
• Hedef segment (saklandığı şekliyle)
• Kullanıcı tanımlayıcısı (çoğunlukla çalışan ID'si, e-posta değil)
• Okuma durumu ve zaman damgası (varsa)

Cihaz detayları, IP adresleri veya tam kullanıcı profillerini dışa aktarmayı yalnızca açık politika ve onay varsa yapın.

Aşırıya kaçmamak: operasyonel destek, gözetim değil

Makbuzları, üretkenlik izleme için değil kritik mesajları doğrulamak (politika değişiklikleri, güvenlik bildirimleri, kesintiler) amacıyla konumlandırın. Yönetici görünümünü varsayılan olarak toplu istatistiklerle sınırlayın; kullanıcı düzeyine inmek için yükseltilmiş izin gerektirin ve erişimlerin denetim izini saklayın.

Gizlilik, Test, Dağıtım ve Sonraki Adımlar

Gizlilik ve güvenilirlik, insanların uygulamanıza güvenip kullanıp kullanmayacağını belirler. Okuma makbuzları özellikle hassastır: ihtiyaç olandan fazlasını toplarsanız veya süresiz saklarsanız "izleniyorum" hissi yaratır.

Gizlilik: azaltın ve açıklayın

Veri minimizasyonu ile başlayın: bir makbuzun olduğunu ispatlamak için yalnızca gerekli olanı saklayın. Birçok ekip için bu user ID, announcement ID, zaman damgası ve istemci kaynağı (web/mobil) ile sınırlıdır — IP adresleri, GPS verisi veya ayrıntılı cihaz parmak izleri değil.

Önceden saklama politikası seçenekleri belirleyin:

• Makbuzları sabit bir süre saklayın (örn. 90/180/365 gün), sonra otomatik silme.
• Makbuzları yalnızca duyuru aktifken saklayın, sonra sona erdiğinde temizleyin.
• Hassas departmanlar için daha sıkı saklama politikaları uygulayın.

Bunu uygulama içinde kısa, anlaşılır bir gizlilik notunda belgeleyin (ayarlar içinde gösterin veya /settings).

Denetim izi: gürültü olmadan hesap verebilirlik

Kim yayınladı, düzenledi, arşivledi veya geri yükledi gibi ana eylemler için bir denetim izi tutun ve zaman damgası ekleyin. Bu, anlaşmazlıkları çözmeye ve kurum içi uyumu desteklemeye yardımcı olur.

Test kontrol listesi (genelde bozulanlar)

En yüksek riskli yolları test edin:

• İzinler: yazar vs admin vs görüntüleyici; düzenleme ve raporlamada rol tabanlı erişimi doğrulayın.
• Hedefleme doğruluğu: yalnızca hedeflenen kitle görüntüleyebiliyor ve bildirim alabiliyor mu?
• Makbuz doğruluğu: açma bir kere yazıyor mu (çoğaltma yok), cihazlar ve tarayıcılar arasında tutarlı mı?

Dağıtım temelleri

Ayrı ortamlar (dev/staging/prod) kullanın, veritabanı migration'larını güvenli çalıştırın ve izleme ile yedeklemeler kurun. Bildirimler, makbuz yazımları gibi işler başarısız olduğunda hataların görünmesini sağlayın.

Platform yaklaşımlarını kullanıyorsanız, pratikte ihtiyaç duyacağınız operasyonel özelliklere (tekrarlanabilir dağıtımlar, ortam ayrımı, rollback) öncelik verin. (Örneğin Koder.ai dağıtım/barındırma, snapshot ve rollback desteği sunar; bu, dahili iş akışlarında hedefleme ve makbuz mantığını denerken riski azaltabilir.)

Sonraki iyileştirmeler

Yaygın yükseltmeler: çok dilli duyurular, yeniden kullanılabilir şablonlar ve entegrasyonlar (Slack/Teams, e-posta, İK dizini senkronizasyonu).