23 May 2025·8 dk
Okuma Makbuzlu Dahili Duyurular Web Uygulaması Oluşturun
Okuma makbuzları, roller, hedefleme ve basit analizlerle dahili duyurular için bir web uygulaması nasıl planlanır, inşa edilir ve yayımlanır öğrenin.
Okuma makbuzları, roller, hedefleme ve basit analizlerle dahili duyurular için bir web uygulaması nasıl planlanır, inşa edilir ve yayımlanır öğrenin.
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 sadece bir İK aracı değildir. Farklı grupların farklı sebeplerle kullandığı bir çalışan iletişim sistemi olabilir:
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.
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.
Teslim etkinliğini ve çalışan davranışını yansıtan metrikler seçin:
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.
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.
İlk sürümü, temel problemi çözen şekilde tanımlayın: hedeflenmiş duyuruları yayınlama ve okunduğunu doğrulama.
V1 zorunlu özellikler:
İleride eklenebilecekler:
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.
Farklı duyurular farklı beklentiler gerektirir. Başlangıçta küçük bir tür setinde anlaşın:
Her tür için gerekli alanları (sona erme tarihi, onay gerekliliği, öncelik) ve kimlerin yayınlama yetkisine sahip olduğunu belirleyin.
Mühendislik ve paydaşların hizalanması için net olun:
Bu kapsam belgesi, yeni istekler geldiğinde yapım planınız ve değişiklik kontrol referansınız olur.
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.
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.
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:
Eğer onaylar önemliyse, taslak oluşturma ile yayınlamayı ayırın:
Bu kuralları kısa bir “erişim politikası” sayfasında belgeleyin ve kurum içi olarak gösterin (örneğin /help/access-policy).
Ö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.
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.
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ı.
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.
En azından şu varlıkları modelleyin:
Announcement için şunları dahil edin:
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 birçok dahili araçta karışıklık yaratır. Erken bir strateji seçin:
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.
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.
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.
Makbuzlar hızla büyüyebilir. Sorgulamayı kolaylaştırın:
Bu, yinelenmeleri önler ve yaygın ekranları hızlı hale getirir (örn. "Alex bunu okudu mu?" veya "Duyuru #42 kaç okunma aldı?").
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.
Birincil bir sinyal seçin ve ona sadık kalın:
Birçok ekip hem read hem de acknowledged izler: “read” pasif, “acknowledged” kasıtlı bir onaydır.
Kullanıcı başına duyuru başına ayrı bir makbuz kaydı oluşturun. Tipik alanlar:
user_idannouncement_idread_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.
Duyurular sıklıkla güncellenir. Düzenlemelerin makbuzları sıfırlayıp sıfırlamayacağına önceden karar verin:
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.
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.
Kanıtlanmış bir temel, yaygın bir web framework'ü ile ilişkisel veritabanıdır:
İ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.
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ı güzel ama zorunlu değil. Anında "yeni duyuru" rozetleri gerekiyorsa düşünün:
Kullanıcılar gecikmeyi fark etmedikçe önce polling ile başlayın; yükseltin.
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 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.
Ç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.
Tek bir yaklaşım seçin ve uygulama genelinde tutarlı olun:
HttpOnly, Secure ve SameSite=Lax/Strict çerezleri kullanın. Oturum ID'lerini giriş ve yetki değişimlerinde döndürün.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.
Kimlik doğrulama kimliği ispat eder; yetkilendirme yetkiyi kanıtlar. Şunlarda yetki kontrolleri uygulayın:
Bu kontrolleri UI ipucundan ziyade sunucu tarafında zorunlu kurallar olarak ele alın.
İç uygulamalar bile korumaya ihtiyaç duyar:
İ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.
Basit, görünür bir durum modeli kullanın:
Hesap verebilirlik için kimlerin hangi duruma ne zaman taşıdığı bilgilerini saklayın (okuması kolay bir denetim izi).
Zamanlama "şimdi gönder" baskısını azaltır ve küresel ekipleri destekler.
UI'de geçerli zaman dilimini açık gösterin ve expire_at < publish_at ise uyarı verin.
Bir içerik formatı seçin ve ona sadık kalın:
Çoğu ekip için temel Markdown (başlıklar, maddeler, bağlantılar) pratik bir orta yoldur.
Ek destekliyorsanız beklentileri baştan belirleyin:
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 "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.
Ö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.
Kullanıcılara kontrol verin ama ayarları aşırı karmaşık yapmayın:
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 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.
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ı, 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.
Başlangıç için duyuru başına tek bir pano görünümüyle üç sayı gösterin:
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.
Gerçek operasyonel dilde filtreler ekleyin ama uygulamayı BI aracına dönüştürmeyin:
Filtre uygulandığında aynı delivered/read/unread özetini tutun ki segmentleri karşılaştırmak kolay olsun.
CSV dışa aktarımı denetimler ve takipler için yararlı ama en az veriyi içermeli. İyi bir varsayılan:
Cihaz detayları, IP adresleri veya tam kullanıcı profillerini dışa aktarmayı yalnızca açık politika ve onay varsa yapın.
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 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.
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:
Bunu uygulama içinde kısa, anlaşılır bir gizlilik notunda belgeleyin (ayarlar içinde gösterin veya /settings).
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.
En yüksek riskli yolları test edin:
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.)
Yaygın yükseltmeler: çok dilli duyurular, yeniden kullanılabilir şablonlar ve entegrasyonlar (Slack/Teams, e-posta, İK dizini senkronizasyonu).
Bir okuma makbuzu operasyonel soruyu yanıtlar: kritik bir mesajı kimlerin gerçekten gördüğünü (ve gerekirse onayladığını). Bu, politika değişiklikleri, güvenlik bildirimleri, ofis kapanışları ve fayda son tarihleri gibi konularda takip etme belirsizliğini azaltır ve “gönderdik”i “okundu olarak doğrulayabiliyoruz” hâline getirir.
İyi bir v1 için uygun metrikler şunlardır:
read_at (veya acknowledged_at) kaydı olanların yüzdesi.Duyuru türüne göre farklı hedefler belirleyin (örn. acil/güvenlik vs. kültür/haber).
Sağlam bir v1 kapsamı genellikle şunları içerir:
Onay akışları, şablonlar, reaksiyonlar ve gelişmiş analizler gibi işlevleri daha sonra ekleyin, önceliğiniz çekirdek problemi çözmek olmalı.
Hataları önlemek için net roller ve izinler ile başlayın:
Birincil bir tanım seçin ve tutarlı uygulayın:
Birçok ekip hem read_at (pasif okuma) hem de (gerekli onay) tutar.
Raporlamanın güvenilir kalması için özel bir receipts tablosu kullanın; amacı her duyuru için kullanıcı başına bir satır saklamaktır:
user_id, announcement_idread_at (nullable)acknowledged_at (nullable)Düzenlemelerin makbuzları nasıl etkilediğine önceden karar verin:
Pratik bir yol, (veya ) saklamak ve yayıncı “yeniden onay gerektirir” olarak işaretlediğinde (ve isteğe bağlı olarak ) değerlerini temizlemektir; geçmişi de denetim iziyle tutun.
Hedefleme genelde şu seçeneklere ayrılır:
Snapshot kullanmak, makbuzların ve raporlamanın istikrarını korur: hedeflenen kitle, yayın anında kimseydi, bugün kim olduğuna göre değişmez.
Mümkünse SSO (SAML/OIDC) kullanın; parola riskini azaltır ve mevcut kimlik yönetimi ile uyumlu olur. Yöntem ne olursa olsun:
Makbuzları yararlı kılarken gözetim algısını önleyin:
İzinleri yalnızca rol isimleriyle değil, eylem düzeyinde (create/edit/publish/archive/view receipts/export) tanımlayın.
acknowledged_at(announcement_id, user_id) üzerinde benzersiz bir kısıtlama/indeks uygulayın ve tekrarları önlemek için receipt yazımlarını upsert şeklinde yapın.
announcement_versioncontent_hashacknowledged_atread_atYetkilendirmeyi UI ipucundan ziyade zorunlu bir backend kuralı olarak ele alın.
Uygulama içinde kısa, anlaşılır bir gizlilik notu gösterin (ör. Settings veya /settings).