18 May 2025·8 dk
Şirket Duyuruları ve Onaylamalar İçin Bir Web Uygulaması İnşa Edin
Şirket genelinde duyurular, hedefli gönderim, onaylar, hatırlatmalar ve raporlama için bir web uygulamasını adım adım nasıl tasarlayıp inşa edeceğinizi öğrenin.
Şirket genelinde duyurular, hedefli gönderim, onaylar, hatırlatmalar ve raporlama için bir web uygulamasını adım adım nasıl tasarlayıp inşa edeceğinizi öğrenin.
Şirket güncellemeleri insanların ilgilenmemesinden değil—mesajın gömülmesinden başarısız olur. Bir politika değişikliği müşteri e-postalarının yanında gelir, tüm eldiven notu çok hızlı akan bir sohbet kanalına atılır ve güvenlik güncellemesi sözlü olarak geçilir ama hiç belgelendirilmez. Gerçekten önemli olduğunda “gönderdik” ile “insanlar gördü” aynı şey değildir ve bu boşluk uyumluluğu, takipleri ve hesap verebilirliği kanıtlamayı zorlaştırır.
Bir şirket duyuruları uygulaması sadece gönderi yayınlamamalı. V1 için basit, güvenilir ve kanıt üreten bir duyuru iş akışı hedefleyin:
Bu okundu bildirimi takibi ile onay kanıtının birleşimi, genellikle gerçek iş gereksinimi olan onaylar için denetim izi olur.
Gerçek paydaşlar için tasarım, ürünü genel bir iç iletişim yazılımına dönüşmekten korur:
Odaklanmış bir MVP yayınlamayı ve benimsenmeyi kolaylaştırır. V1 için çekirdek duyuru iş akışı, rol tabanlı erişim kontrolü, bildirimler, onaylar ve temel raporlamayı önceliklendirin. Henüz değer kanıtlamayan karmaşıklıkları erteleyin.
V1 (zorunlu):
Sonrası (iyi olur):
“Bu uygulama kritik güncellemelerin teslim edilmesini, onaylanmasını ve kanıtlanmasını sağlar” diyebiliyorsanız, geri kalan yapı için net bir başarı tanımınız olur.
Bu tür bir uygulama, önemli mesajları gözden kaçırmayı zor, anlamayı kolay ve görüldüğünü kanıtlamayı mümkün kıldığında başarılı olur. Temel yayınlama, hassas hedefleme ve güvenilir onay kayıtlarını destekleyen minimum özellik setini tanımlayarak başlayın.
Her duyuru net bir yapıyı desteklemeli: başlık, biçimlendirilmiş gövde ve ekler (PDF, görseller, politikalar). Yayın pencereleri (başlangıç/bitiş) ekleyin ki gönderiler zamanlanabilsin ve otomatik olarak süresi dolsun; ayrıca öğenin ne kadar öne çıkarılacağını belirleyen aciliyet seviyeleri (Normal, Önemli, Kritik) ekleyin.
Pratik bir gereksinim: yazarların yazım hatalarını düzeltmesi gerekir ama güveni bozmamalı; yöneticilerin bilgi değiştiğinde duyuruyu geri çekme (görünür “geri çekildi” durumu) yeteneği olmalı.
Hedefleme, bir duyuru aracını kullanılabilir iç iletişim yazılımına dönüştürendir. Kutudan çıktığı gibi yaygın kapsamları destekleyin:
Kullanıcılar yalnızca kendilerine uygulananları görmeli, ancak yöneticiler farklı kitleler için duyurunun nasıl görüneceğini önizleyebilmelidir.
Her gönderinin okundu bildirimi gerektirmesi gerekmez. Onayları duyuru başına yapılandırılabilir yapın:
Sistem bireysel ve toplu düzeyde “Onaylandı / Onaylanmadı / Gecikmiş” durumunu net göstermeli.
Yöneticiler genellikle tekrarlayan gönderiler için şablonlar, hassas duyurular için onay akışları ve zamanlama ister. Bunları erken birinci sınıf gereksinimler olarak ele alın—sonradan onayları sonradan eklemek iş akışını ve veri modelini bozabilir.
Açık bir iş akışı, duyuruların “sadece bir gönderi daha” olmasını engeller ve onay raporlamasını güvenilir kılar. Her rol için uçtan uca yolu haritalayın ve duyurunun olabileceği durumları tanımlayın.
Çoğu ekip basit, açık bir yaşam döngüsünden fayda görür:
Okundu pasif bir olay (açıldı/görüldü) olarak ele alın ve Onaylandı açık bir eylem ("Anladım" düğmesine tıklandı veya gerekli istemi tamamladı) olarak kabul edin. Bu, bir bildirim açıldığında fakat uyumluluğa bağlayıcı bir taahhüt verilmediğinde karışıklığı önler.
Şirket politikası ve denetim ihtiyaçları için onaylar neredeyse her zaman kullanıcı bazında olmalı, cihaz veya oturum bazlı değil. Arayüz için oturum düzeyinde “görüldü” bayrağı (ör. aynı bandı bir gün içinde tekrar göstermeme) faydalı olabilir ama kanıt yerine geçmemelidir.
Geç onaylar ve İK olayları raporları bozabilir; kurallar tanımlayın:
Bu yolculuklar belgelenince, ekranlar ve API’ler gerçek davranışa uygun şekilde tasarlanabilir.
Erişim kontrolü, bir duyurular uygulamasını güvenilir kılan yerdir. İnsanların sadece doğru kişilerin şirket geneline yayın yapabileceğini ve onay raporlarının herkes tarafından görülemeyeceğini bilmeleri gerekir.
Orta ve büyük şirketler için SAML veya OIDC ile Single Sign-On (SSO) ile başlamayı düşünün. Parola destek taleplerini azaltır, işten ayrılma sürecini güvenli kılar (kurumsal hesabı devre dışı bırakmak) ve genellikle koşullu erişim sağlar (ör. bilinmeyen cihazlarda MFA gerektirme).
Küçük takımlar veya erken MVP için e-posta/parola kabul edilebilir—sadece isteğe bağlı yapın ve kullanıcı kimliklerini yeniden yazmadan SSO ekleyebilecek şekilde tasarlayın. Yaygın bir yaklaşım, kullanıcıları stabil bir dahili kimlikle saklamak ve bir veya daha fazla “oturum açma yöntemi” (parola, OIDC sağlayıcısı vb.) iliştirmektir.
Duyuruların organizasyon içinde nasıl hareket ettiğine uyan roller tanımlayın:
Rollerin ötesinde kilit izinleri açıkça belgeleyin:
Gruplar HR dizininden senkronize edilebilir (doğruluk için en iyisi) veya manuel yönetilebilir (hızlıca yayın için). Senkronize ediyorsanız bölüm, lokasyon ve yönetici gibi öznitelikleri destekleyin. Manuel yönetim varsa, net sahiplik (hangi kullanıcının grubu düzenleyebileceği) ve değişiklik geçmişi ekleyin ki hedefleme kararları sonradan denetlenebilir olsun.
Net bir veri modeli geri kalan uygulamayı kolaylaştırır: yayın akışları öngörülebilir olur, raporlama güvenilir olur ve kim ne zaman ne gördüğünü dağınık spreadsheetler olmadan kanıtlayabilirsiniz.
İçeriği ve yaşam döngüsü durumunu tutan bir announcements tablosu ile başlayın:
id, title, body (veya body_html)status: draft, published, archivedcreated_at, updated_at, ayrıca published_at ve archived_atcreated_by, published_by"taslak" ile "yayınlandı" arasını kesin tutun. Bir taslak bildirim veya onay üretemez.
Hedefleme mantığını yalnızca koda gömme. Modelleyin:
groups (ör. “Depo”, “Yöneticiler”)group_members (group_id, user_id, gerekirse geçerlilik tarihleri)audience_rulesRaporlama için yayımlandığında oluşturulan materialize edilmiş bir announcement_recipients tablosu ("alıcı listesi") oluşturun:
announcement_id, user_id, source (group/rule/manual)recipient_created_atBu anlık görüntü, birisi sonradan departman değiştirince raporların değişmesini engeller.
Bir acknowledgements tablosu kullanın:
announcement_id, user_idstatus (ör. pending, acknowledged)acknowledged_atnoteTekrarları önlemek için (announcement_id, user_id) üzerinde benzersiz kısıt ekleyin.
Dosya meta verilerini veritabanında, gerçek blobları ise nesne depolamada saklayın:
attachments: id, announcement_id, file_name, content_type, size, storage_key, uploaded_atBu, veritabanınızı hafif tutar ve büyük PDF/görsellerin performans sorunlarına yol açmasını engeller.
Backend, duyurular, kimlerin görebileceği ve kimlerin onayladığı konusunda tek gerçek kaynaktır. Sade ve öngörülebilir tutun: net uç noktalar, tutarlı yanıtlar ve sıkı izin kontrolleri.
Yöneticilerin ve çalışanların gerçek yaptığı işleri karşılayan küçük bir API seti ile başlayın:
Basit bir şekil şu olabilir:
GET /api/announcements (akış)POST /api/announcements (oluştur)GET /api/announcements/{id} (detay)PATCH /api/announcements/{id} (düzenle)POST /api/announcements/{id}/publishPOST /api/announcements/{id}/acknowledgementsDuyuru listeleri hızla büyür; sayfalama varsayılan olsun. Yöneticilerin ve çalışanların gerçek sorularına uyan filtreler ekleyin:
Tutarlı sorgu parametreleri kullanın (ör. ?page=2&pageSize=20&team=Sales&status=published&from=2025-01-01).
Anında “yeni duyuru” bildirimleri gerekiyorsa WebSockets veya Server-Sent Events düşünün. Gerekli değilse basit polling (ör. her 60–120 saniyede) işletmesi daha kolaydır ve genelde yeterlidir.
Onaylar idempotent olmalı: iki kere gönderilmesi iki kayıt yaratmamalı.
Bu yaklaşımlardan birini uygulayın:
(announcement_id, user_id) gibi benzersiz kısıt ve çoğaltmaları başarı gibi ele almak.Idempotency-Key başlığı kullanmak.Böylece raporlama doğru kalır ve kafa karıştırıcı çift kayıtlar olmaz.
Bir duyurular uygulaması, çalışanların hızlıca tarayabilmesi, gördüklerine güvenmesi ve onayları sürtünmesiz tamamlayabilmesi halinde işler. “Güzel” arayüz yerine açıklığa öncelik verin—çoğu kullanıcı bir dizüstü veya telefonda toplantılar arasında açar.
Akışı en önemli öğelerin hemen öne çıkmasını sağlayacak şekilde tasarlayın:
“Okunmamış” durumu belirgin ama rahatsız edici olmamalı. Basit bir rozet ve kalın başlık genelde ağır bantlardan iyidir.
Detay sayfasında gerekli bilgileri katlama olmadan gösterin:
Onay bir politika beyanı içeriyorsa, onu düğmenin hemen yanına koyun (başka bir tıklamanın arkasına saklamayın). Onaylandıktan sonra CTA’yı bir onay ve zaman damgasıyla değiştirin ki kullanıcı işlem başarılı olduğunu görsün.
Gerçek kullanım için inşa edin: tam klavye gezintisi, görünür fokus durumları, okunabilir tipografi ve yeterli kontrast. Öncelik veya durumu sadece renkle göstermeyin; ikon ve metinle destekleyin.
Yöneticiler iş akışına odaklı bir arayüze ihtiyaç duyar: taslaklar, onay kuyruğu, zamanlama ve "kimin gerçekten göreceğini" yanıtlayan bir kitle önizlemesi. Ayrıca biçimlendirmeyi ve ekleri doğrulamak için "çalışan olarak görüntüle" modu ekleyin.
Bildirimler “duyuru gönderildi”yi “duyuru okundu ve onaylandı”ya çevirir. Amaç: insanları gerçekten kontrol ettikleri kanallarda rahatsız etmeden ulaşmak.
Kaynak olarak uygulama içi bildirimlerle başlayın, sonra iş gücünüze göre teslim kanallarını ekleyin:
Yöneticilerin her duyuru için hangi kanalların kullanılacağını seçmesine izin verin; kullanıcıların da (politika izin veriyorsa) tercihlerini ayarlamalarına olanak tanıyın.
Hatırlatmaları onay son tarihine bağlayın:
Yayın oluşturucuda planlanan hatırlatma takvimini gösterin ki yayıncılar ne gönderileceğini bilsin.
"Rahatsız etmeyin" pencerelerine saygı gösterin. Her kullanıcının zaman dilimini saklayın ve sessizlik saatlerini yerel olarak uygulayın (ör. 20:00–08:00). Bir hatırlatma sessizlik saatine denk gelirse, bir sonraki izin verilen pencereye kuyruğa alın.
E-posta her zaman ulaşmayabilir. Sağlayıcı olaylarını (teslim edildi, bounce, bloklandı) yakalayın ve yöneticilere basit bir “Teslim edildi” veya “Başarısız” durumu gösterin. Tekrarlayan bounce veya geçersiz e-posta adresleri için adresi otomatik olarak bastırın ve güncelleme isteyin.
Duyurular, görüldüklerini ve anlaşıldıklarını kanıtlayabildiğinizde gerçekten işe yarar. İyi bir onay sistemi “gönderdik”i “kim onayladığını ve ne zaman onayladığını gösterebiliyoruz” haline getirir.
Her mesaj aynı kesinlik düzeyini gerektirmez. Yöneticilerin seçmesi için birkaç onay modu destekleyin:
Arayüzü net tutun: onay gereksinimi ve son tarih duyurunun hemen yanında görünmeli.
Denetimler ve iç soruşturmalar için eklenebilir kayıtları saklayın:
Onay satırlarını yerinde güncellemek yerine yeni olaylar ekleyin ve geçerli durumu en son geçerli olaydan hesaplayın.
Bir duyuru anlamlı şekilde değiştiyse önceki onaylar otomatik geçerli sayılmamalıdır. İçeriği sürümlendirin ve yeni sürümü yeniden onay gerektirir olarak işaretleyin:
Yöneticiler ve denetçiler sık sık uygulama dışında kanıt ister. Şunları sağlayın:
Bir duyurular ve onaylar uygulaması güvenliği yalnızca ihlalleri önlemekle ilgili değildir. Doğru kişilerin doğru mesajları görebildiğini, sonradan ne olduğunu kanıtlayabildiğinizi ve verileri gerçekten yalnızca gerektiği kadar tuttuğunuzu garanti etmekle ilgilidir.
Riskleri azaltan temel uygulamalarla başlayın:
“İç” uygulamalar bile yanlış kullanılabilir. (Günlük hatalar veya kötü niyetli istekler). Giriş noktalarını sınırlayın (oturum açma, arama, onay gönderimi). Herhangi bir açık uçlu uç nokta (SSO callback veya webhook alıcıları gibi) için:
Ekler zayıf noktadır. Onları güvensiz girdi olarak ele alın:
Onaylar istihdam detaylarını açığa çıkarabilir. Başlangıçta karar verin:
Kuruluşunuz SOC 2, ISO 27001, GDPR veya HIPAA gibi gereksinimler varsa erişim kontrolü, günlük koruma ve saklama uygulamalarını belgelendirin ve tutarlı şekilde uygulayın.
Entegrasyonlar "güzel bir portal"ı insanların gerçekten fark edeceği bir şeye dönüştürür. Amaç: çalışanların zaten çalıştığı yere gitmek ve yönetici adımlarını otomatikleştirerek benimsemeyi hızlandırmak.
Yaygın bir desen: duyuruyu uygulamanızda yayınlayın, sonra ilgili kanala kısa bir bildirim gönderin ve duyuruya derin bağlantı verin.
Sohbet mesajını kısa ve eyleme çağırıcı tutun: başlık, kimlere uygulandığı ve “Oku & onayla” linki. Tam metni sohbete dökmeyin—insanlar orada tarar ve unutur.
Workday, BambooHR, HiBob gibi HRIS kullanan şirketler için çalışan dizinini senkronize etmek iş kurtarır. Başlangıç için şunları eşleyin:
Günlük bir senkron bile MVP için genelde yeterlidir; gerçek zamanlı senkron daha sonra gelir.
Webhooklar diğer sistemlerin anında tepki vermesini sağlar. Yararlı olaylar:
announcement.publishedannouncement.acknowledgedannouncement.overdueBunlar Zapier/Make veya dahili scriptlerle iş akışları tetikleyebilir—ör. gecikmiş onaylar belli bir eşiği aşınca ticket oluşturan otomasyon.
Erken aşamada dizin entegrasyonlarınız olmayabilir. Yöneticilerin hızlı başlaması için CSV import/export sunun; sonra senkronizasyona geçiş yapın.
Daha fazla rollout ipucu için /blog/employee-comms-checklist. Ürünü paketliyorsanız entegrasyonları hızlıca doğrulamaları için /pricing üzerinde açıkça açıklayın.
Bir duyurular uygulamasını yayınlamak sadece “production’a push” değildir. Günlük başarı öngörülebilir dağıtımlar, kullanıcıyı engellemeyen arka plan işlemleri ve bir şey bozulduğunda hızlı görünürlük gerektirir.
Bir spekten çalışan bir MVP’ye hızlı geçmek istiyorsanız, Koder.ai gibi bir vibe-coding platformu React frontend, Go backend, PostgreSQL ile çekirdek iş akışını yapılandırılmış bir sohbet isteminden ayağa kaldırmanıza yardımcı olabilir—sonra planlama modu, snapshotlar ve rollback ile hedeflemeyi, bildirimleri ve onay raporlamasını iyileştirebilirsiniz. Hazır olduğunuzda kaynak kodunu dışa aktarabilir ve özel alan adlarıyla dağıtabilirsiniz.
Üç ortam planlayın: dev, staging, prod. Staging, üretime mümkün olduğunca yakın olmalı (aynı veritabanı motoru, benzer e-posta sağlayıcısı, aynı dosya depolama türü) ki hataları çalışanlar görmeden yakalayın.
Yapılandırmayı kod tabanından ayrı tutun; ortam değişkenleri veya bir secrets manager kullanın. Tipik yapılandırma öğeleri e-posta/SMS kimlik bilgileri, base URL, veritabanı bağlantı dizileri, dosya depolama anahtarları ve özellik bayraklarıdır.
MVP için bile bazı işler web isteğinde çalışmamalı:
Bir iş kuyruğu kullanın ve işlerin idempotent olmasını sağlayın ki yeniden denemeler insanları rahatsız etmesin.
İlk günden itibaren izleme kurun:
Ayrıca “duyuru yayınlandı”, “hatırlatma gönderildi” ve “onaylandı” gibi ana olayları kaydedin ki destek tahmin yürütmeden sorulara cevap verebilsin.
MVP: CI/CD ile dağıtım, staging onay adımı, veritabanı migrasyonları, admin kullanıcı başlangıcı, günlük yedekler, temel izleme ve manuel “hatırlatmayı yeniden gönder” aracı.
V2 fikirleri: self-serve analitik panolar, gelişmiş zamanlama (zaman dilimleri, sessizlik saatleri), şablonlanmış duyuru tipleri ve otomatik yükseltme (geç kalanlar için yönetici bildirimleri).
Çoğu şirkette gerçek gereksinim “güncelleme yayınlamak” değil—teslimatın kanıtlanması ve takip etmektir. İyi bir v1 şunları yapmalı:
Raporlamanın güvenilir olması için yaşam döngüsünü açık tut:
Treat Read as a passive event (opened/viewed) and Acknowledged as an explicit action (“I understand”). Use read events for UX (e.g., unread badges), but use acknowledgements for compliance and audit.
If you only track reads, you’ll struggle to prove policy confirmation or completion by a due date.
Çoğu durumda onaylamaları kullanıcı bazında tutun, cihaz veya oturum bazlı değil. Kullanıcı bazlı kayıtlar HR/uyumluluk ihtiyaçlarına uyar ve paylaşılan kiosk gibi açık alanlardaki boşlukları kapatır.
Arayüz için oturum düzeyinde “görüldü” bayrakları kullanabilirsiniz (örneğin aynı bantı bir gün içinde tekrar göstermemek için), ama bunları kanıt yerine koymayın.
Organizasyonların gerçekte nasıl çalıştığına uygun hedefleme sunun:
Ayrıca yayınlamadan önce yöneticilerin “bu ilan kimlere görünecek” sorusuna cevap veren bir önizleme modu ekleyin.
Yayın anında bir alıcı anlık görüntüsü (announcement_recipients gibi) oluşturun. Böylece biri departmanını değiştirdiğinde raporlar sonradan değişmez.
Bu, denetlenebilirlik için hayati: uygulama “yayınlandığında kim hedeflenmişti?” sorusuna aylar sonra bile cevap verebilmelidir.
Onay gönderimini idempotent yapın ki yeniden denemeler çoğaltma yaratmasın:
(announcement_id, user_id) üzerinde benzersizlik kısıtı uygulayın ve çoğaltmaları başarı olarak ele alın, ve/veyaIdempotency-Key desteği sağlayınBu, denetim izlerini temiz tutar ve “çift onaylandı” gibi kafa karıştırıcı durumları önler.
İş gücünüze göre kanalları seçin ve hatırlatmaları son tarihle ilişkilendirin:
Yayınlayıcıların ne gönderileceğini bilmesi için planlanan hatırlatma takvimini yayın oluşturucuda gösterin.
Metinsel anlamda değişiklikler yapıldıysa eski onaylar otomatik taşınmamalı. Duyuruları sürümlendirin ve anlamlı değişikliklerde yeniden onay gerektirin:
Yayınlandıktan sonra içeriği iz bırakmadan sessizce değiştirmekten kaçının—güven ve uyumluluk zarar görür.
Yayın ve onay olaylarının eklenebilir (append-only) bir kaydını tutun; kayıtlar şunları içermeli:
Ayrıca CSV dışa aktarımları ve yazdırılabilir özet görünümler sunun. Rollout için daha fazla ipucu: /blog/employee-comms-checklist.