Şirket Duyuruları ve Onaylamalar İçin Bir Web Uygulaması İnşa Edin

Uygulamanın başarması gerekenler

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

Hedeflediğiniz çıktı

Bir şirket duyuruları uygulaması sadece gönderi yayınlamamalı. V1 için basit, güvenilir ve kanıt üreten bir duyuru iş akışı hedefleyin:

• Yayınla: çalışanların gerçek bilgi kaynağı olarak güvenebileceği tek bir yerde güncellemeler yayınlayın.
• Hedefle: doğru kitleyi seçin (herkes, belirli ekipler, lokasyonlar veya roller).
• Bildirim gönder: insanlara zaten kullandıkları kanallardan ulaşın (e-posta, uygulama içi, daha sonra sohbet entegrasyonları).
• Çalışan onaylarını topla: bir mesaj onay gerektiriyorsa onayı kaydedin.
• Raporla: kim okudu, kim onayladı, kim gecikmiş—manuel kovalamaya gerek kalmadan açıkça gösterin.

Bu okundu bildirimi takibi ile onay kanıtının birleşimi, genellikle gerçek iş gereksinimi olan onaylar için denetim izi olur.

Kim kullanır (ve her birinin ihtiyacı ne)

Gerçek paydaşlar için tasarım, ürünü genel bir iç iletişim yazılımına dönüşmekten korur:

• Çalışanlar: hızlı taranabilen, kolay aranabilen ve hangi öğelerin işlem gerektirdiğini belli eden temiz bir intranet duyuru portalı.
• Yöneticiler: ekiplerinin durumunu (kim onaylamadı) görme ve utandırmadan hatırlatma araçları.
• İK / İletişim: geliştirme yardımına ihtiyaç duymadan taslak oluşturma, gözden geçirme, zamanlama ve erişimi ölçme deneyimi.
• Yöneticiler (BT): erişim, roller ve ayarlar üzerinde kontrol; sistemin güvenli ve yönetilebilir olduğuna güven.
• Denetçiler / Uyumluluk: ne yayınlandığını, ne zaman, kime ve onay sonuçlarıyla oynanamaz bir görünüm.

Kapsam belirleme: v1 ve sonrası

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

• Hedefleme ile duyuru oluşturma ve yayınlama
• Basit bildirim sistemi (en azından e-posta + uygulama içi)
• Zaman damgalı onay takibi
• Yöneticiler/administratörler için raporlama ve dışa aktarma

Sonrası (iyi olur):

• Çeviri ve yerelleştirme iş akışları
• Yerel mobil uygulama (kullanım kalıpları doğrulanınca)
• Entegrasyonlar (Slack/Teams, HRIS, SSO geliştirmeleri)
• Gelişmiş analiz ve içerik testi

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

Temel özellikler ve gereksinimler

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.

Duyurular

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 ve görünürlük

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:

• Tüm personel
• Bölüm(ler)
• Lokasyon(lar)
• Rol(ler)
• Özel gruplar (proje ekipleri, güvenlik komitesi, nöbet rotasyonu)

Kullanıcılar yalnızca kendilerine uygulananları görmeli, ancak yöneticiler farklı kitleler için duyurunun nasıl görüneceğini önizleyebilmelidir.

Onaylar

Her gönderinin okundu bildirimi gerektirmesi gerekmez. Onayları duyuru başına yapılandırılabilir yapın:

• Gerekli vs isteğe bağlı
• Son tarih (uyumluluk veya politika değişiklikleri için)
• İsteğe bağlı yorum alanı (örneğin “okudum ama…” için kullanışlı)

Sistem bireysel ve toplu düzeyde “Onaylandı / Onaylanmadı / Gecikmiş” durumunu net göstermeli.

Yönetici iş akışı gereklilikleri

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.

Kullanıcı yolculukları ve iş akışları

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.

Birincil akış (oluştur → gözden geçir → yayınla → bildirim → onay → raporla)

Çoğu ekip basit, açık bir yaşam döngüsünden fayda görür:

1. Oluştur (Taslak): Yazar duyuruyu yazar, hedef kitleyi seçer (bölüm/lokasyon), önceliği belirler ve isteğe bağlı olarak politika belgeleri ekler.
2. Gözden geçirme (Onay bekliyor): Bir yönetici, İK veya uyumluluk inceleyicisi metni ve hedef kitleyi kontrol eder. Geri bildirimi yorum olarak tutun ki yazar bağlam kaybetmeden düzeltme yapabilsin.
3. Yayınla (Canlı): Duyuru portala görünür hale gelir ve aranabilir olur.
4. Bildirim: Çalışanlara e-posta, push veya sohbet yoluyla uyarılar gider—idealde her kanal için sadece bir kez, sonra akıllı hatırlatmalar.
5. Onayla: Çalışanlar mesajı anladıklarını onaylar (sadece gördüklerini değil).
6. Raporla: Yöneticiler tamamlama oranlarını görür, kimlerin onaylamadığını inceler ve gerektiğinde kanıt dışa aktarır.

“Okundu” ile “onaylandı”yı ayırın

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.

Onaylar: kullanıcı başına mı yoksa cihaz/oturum başına mı?

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

Erken planlanması gereken kenar durumlar

Geç onaylar ve İK olayları raporları bozabilir; kurallar tanımlayın:

• Geç onay: Zaman damgasını saklayın; hem “onaylandı” hem “son tarihten sonra onaylandı” olarak raporlayın.
• İşten ayrılma: Durumu fesih tarihinde dondurup gelecekteki hatırlatmalardan hariç tutmayı seçin.
• Yeniden işe alım: Sabit bir kişi tanımlayıcısı kullanın ve yeniden işe alımı yeni bir istihdam dönemi olarak kabul edin; kritik politikalar için yeniden onay istenebilir.

Bu yolculuklar belgelenince, ekranlar ve API’ler gerçek davranışa uygun şekilde tasarlanabilir.

Erişim kontrolü, roller ve oturum açma

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.

Kimlik doğrulama: SSO vs e-posta/parola

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.

Roller: basit ama eksiksiz tutun

Duyuruların organizasyon içinde nasıl hareket ettiğine uyan roller tanımlayın:

• Çalışan: duyuruları okur ve onay gönderir.
• Yayıncı: taslak hazırlar ve yayınlar (veya onaya gönderir).
• Onaylayıcı: duyuruları inceler ve onaylar/reddeder.
• Admin: ayarları, rolleri ve entegrasyonları yönetir.
• Denetçi (salt okunur): raporlara ve yalnızca dışa aktarmaya erişir.

İzinler: hassas kenarları belirleyin

Rollerin ötesinde kilit izinleri açıkça belgeleyin:

• Hedefleme: “Tüm şirkete” kim gönderim yapabilir vs belirli ekip/site.
• Yayın sonrası düzenlemeler: düzenlemelere izin verilip verilmeyeceği ve yeni bir sürümün yeniden onay gerektirip gerektirmeyeceği.
• Rapor erişimi: kimlerin kişi ve grup bazında onay durumunu görebileceği.

Grup yönetimi: senkronize vs manuel

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.

Veri modeli ve veritabanı tasarımı

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.

Duyurular

İç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, archived
• created_at, updated_at, ayrıca published_at ve archived_at
• created_by, published_by

"taslak" ile "yayınlandı" arasını kesin tutun. Bir taslak bildirim veya onay üretemez.

Hedef kitle: gruplar, kurallar ve alıcılar

Hedefleme mantığını yalnızca koda gömme. Modelleyin:

• groups (ör. “Depo”, “Yöneticiler”)
• group_members (group_id, user_id, gerekirse geçerlilik tarihleri)
• Lokasyon/bölüm gibi filtreleri destekleyen isteğe bağlı audience_rules

Raporlama 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_at

Bu anlık görüntü, birisi sonradan departman değiştirince raporların değişmesini engeller.

Onaylar (ve okundu bildirimleri)

Bir acknowledgements tablosu kullanın:

• announcement_id, user_id
• status (ör. pending, acknowledged)
• acknowledged_at
• İsteğe bağlı note

Tekrarları önlemek için (announcement_id, user_id) üzerinde benzersiz kısıt ekleyin.

Ek dosya depolama

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_at

Bu, veritabanınızı hafif tutar ve büyük PDF/görsellerin performans sorunlarına yol açmasını engeller.

Backend API ve servisleri

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.

Tasarlamanız gereken temel uç noktalar

Yöneticilerin ve çalışanların gerçek yaptığı işleri karşılayan küçük bir API seti ile başlayın:

• Duyurular CRUD: oluştur, oku, güncelle, arşivle/sil.
• Yayın eylemleri: taslak → zamanlandı → yayınlandı (ve opsiyonel olarak “yayından kaldır”).
• Onay eylemi: çalışanların bir öğeyi onayladığı tek bir uç nokta.

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}/publish
• POST /api/announcements/{id}/acknowledgements

Sayfalama, filtreleme ve akışlar

Duyuru listeleri hızla büyür; sayfalama varsayılan olsun. Yöneticilerin ve çalışanların gerçek sorularına uyan filtreler ekleyin:

• Takım/lokasyon, durum (taslak/zamanlandı/yayınlandı/kapatıldı) ve tarih aralığına göre
• "Onay gerektiriyor" vs “bilgilendirme”

Tutarlı sorgu parametreleri kullanın (ör. ?page=2&pageSize=20&team=Sales&status=published&from=2025-01-01).

Gerçek zamanlı güncellemeler (veya değil)

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.

Çift onayları önleme

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.
• Ağ sorunları için her gönderimde bir Idempotency-Key başlığı kullanmak.

Böylece raporlama doğru kalır ve kafa karıştırıcı çift kayıtlar olmaz.

Kullanıcı arayüzü (frontend) — çalışanların gerçekten kullanacağı deneyim

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.

Çalışan akışı: taramaya öncelik verin, sonsuz kaydırmaya değil

Akışı en önemli öğelerin hemen öne çıkmasını sağlayacak şekilde tasarlayın:

• Net önceliklendirme: kritik gönderileri sabitleyin, “İşlem gerekli” görsel etiketi ve son tarihleri önde gösterin.
• Arama + filtreler: lokasyon/takım, kategori (İK, BT, Güvenlik) ve durum (yeni/onaylandı) ile filtreleme.
• Akıllı önizlemeler: ilk 1–2 satırı, ek sayısını ve onay gerekip gerekmediğini gösterin.

“Okunmamış” durumu belirgin ama rahatsız edici olmamalı. Basit bir rozet ve kalın başlık genelde ağır bantlardan iyidir.

Duyuru detay sayfası: işlem yapmak için gereken her şey

Detay sayfasında gerekli bilgileri katlama olmadan gösterin:

• Başlık, yazar/takım, yayın tarihi ve son tarih (varsa)
• Dosya ekleri; isim ve boyutları net gösterin
• Tek ve belirgin bir Onay çağrı-düğmesi

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.

Erişilebilirlik: herkes için kullanılabilir kılı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önetici arayüzü: hızlı yayınlama, sürprizsiz

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 ve hatırlatmalar

Bildirimler “duyuru gönderildi”yi “duyuru okundu ve onaylandı”ya çevirir. Amaç: insanları gerçekten kontrol ettikleri kanallarda rahatsız etmeden ulaşmak.

Doğru kanalları seçin (ve yapılandırılabilir olsun)

Kaynak olarak uygulama içi bildirimlerle başlayın, sonra iş gücünüze göre teslim kanallarını ekleyin:

• E-posta: masa başı çalışanlar için ve denetlenebilir teslim günlükleri için en iyi varsayılan.
• SMS: düzenli e-posta erişimi olmayan saha ekipleri için faydalı (maliyet yüksek; seçici kullanın).
• Push bildirimleri: mobil uygulama veya güvenilir PWA desteğiniz varsa.

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.

Rahatsız etmeyen hatırlatma kuralları

Hatırlatmaları onay son tarihine bağlayın:

• Son tarihten önce (ör. 48 saat önce) bekleyenlere ön-hatırlatma gönderin.
• Son tarihten sonra (ör. günlük 3 gün) sadece onaylamayanlara hatırlatma gönderin.
• Onay alındığında derhal durdurun—istisna yok.

Yayın oluşturucuda planlanan hatırlatma takvimini gösterin ki yayıncılar ne gönderileceğini bilsin.

Sessizlik saatleri, zaman dilimleri ve hızlandırma

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

Teslim durumu ve bounce işleme

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.

Onay takibi ve denetim izi

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.

Riske uygun onay türleri seçin

Her mesaj aynı kesinlik düzeyini gerektirmez. Yöneticilerin seçmesi için birkaç onay modu destekleyin:

• Basit onay kutusu ("Okudum ve anladım") düşük riskli güncellemeler için.
• E-imza tarzı onay (tam ad girme, isteğe bağlı parola yeniden doğrulama) politika değişiklikleri ve güvenlik prosedürleri için.
• Kısa sınav / doğrulama metni (kritik talimatların anlaşıldığını doğrulamak için soru yanıtı veya gerekli ifadeyi yazma).

Arayüzü net tutun: onay gereksinimi ve son tarih duyurunun hemen yanında görünmeli.

Oynanamaz denetim kaydı oluşturun (kanıt gibi davranın)

Denetimler ve iç soruşturmalar için eklenebilir kayıtları saklayın:

• Kim: kullanıcı kimliği, o zamanki isim, rol/bölüm anlık görüntüsü gerekirse.
• Ne: duyuru kimliği + sürüm numarası.
• Ne zaman: UTC zaman damgası (yerel gösterimle birlikte).
• Nereden: IP adresi, user agent/cihaz ve oturum açma yöntemi.

Onay satırlarını yerinde güncellemek yerine yeni olaylar ekleyin ve geçerli durumu en son geçerli olaydan hesaplayın.

İçerik güncellendiğinde yeniden onaylama

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:

• Etkilenen kullanıcılar için gerekli durumu sıfırlayın.
• Eski onayları önceki sürüme bağlayın.
• "Son onayınızdan sonra güncellendi" şeklinde net bir afiş gösterin.

Denetimleri kolaylaştırın: dışa aktarımlar ve yazdırılabilir özetler

Yöneticiler ve denetçiler sık sık uygulama dışında kanıt ister. Şunları sağlayın:

• Filtrelere göre CSV dışa aktarımı (tarih aralığı, bölüm, durum, sürüm)
• Toplamlar, istisnalar (onaylamayanlar) ve gerekirse kullanıcı bazlı izleyen bir yazdırılabilir özet görünümü

Güvenlik, gizlilik ve uyumluluk temelleri

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.

Veriyi varsayılan olarak koruyun

Riskleri azaltan temel uygulamalarla başlayın:

• Aktarımda şifreleme: API çağruları ve dosya indirmeleri dahil her şeyi HTTPS/TLS ile sunun.
• En az ayrıcalık veritabanı erişimi: her servis hesabına sadece gereken izinleri verin.
• Ortam ayrımı: üretim verilerini test/staging’den ayırın ve üretim günlüklerine/veritabanına erişimi kısıtlayın.

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

“İç” 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:

• sıkı girdi doğrulama
• imza doğrulama (varsa)
• makul istek boyutu limitleri uygulayın

Ek güvenliği

Ekler zayıf noktadır. Onları güvensiz girdi olarak ele alın:

• Yüklemede kötü amaçlı yazılım taraması
• Dosyaları nesne depolamada saklayın ve süreli imzalı URL’ler ile teslim edin
• Retention (saklama) sınırları uygulayın ki eski dosyalar birikmesin

Gizlilik ve saklama politikası

Onaylar istihdam detaylarını açığa çıkarabilir. Başlangıçta karar verin:

• Onaylar ve denetim günlükleri ne kadar süre saklanacak (ör. 12–24 ay veya İK politikası ile uyumlu)
• Onay raporlarına kim hangi gerekçeyle erişebilir
• Silme istekleri ve hukuki tutuklamalar nasıl ele alınır

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 ve otomasyon

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.

Sohbet araçları: Slack ve Microsoft Teams

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.

HR sistemlerinden dizin senkronizasyonu

Workday, BambooHR, HiBob gibi HRIS kullanan şirketler için çalışan dizinini senkronize etmek iş kurtarır. Başlangıç için şunları eşleyin:

• Kullanıcılar (isim, e-posta, durum)
• Takımlar/bölümler/lokasyonlar
• Yönetici ilişkileri (opsiyonel, ama yararlı)

Günlük bir senkron bile MVP için genelde yeterlidir; gerçek zamanlı senkron daha sonra gelir.

Webhooklar ve otomasyon tetikleyicileri

Webhooklar diğer sistemlerin anında tepki vermesini sağlar. Yararlı olaylar:

• announcement.published
• announcement.acknowledged
• announcement.overdue

Bunlar Zapier/Make veya dahili scriptlerle iş akışları tetikleyebilir—ör. gecikmiş onaylar belli bir eşiği aşınca ticket oluşturan otomasyon.

Başlangıç için import/export

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.

Dağıtım, operasyon ve MVP kontrol listesi

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.

Ortamlar ve yapılandırma yönetimi

Üç 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.

Erken ihtiyaç duyacağınız arka plan işler

MVP için bile bazı işler web isteğinde çalışmamalı:

• Hatırlatmalar: onay bekleyenlere zamanlanmış bildirimler
• Rapor oluşturma: yöneticiler/İK için onay durumunu dışa aktarma
• Dosya işleme: virüs tarama, küçük resim oluşturma, PDF önizleme

Bir iş kuyruğu kullanın ve işlerin idempotent olmasını sağlayın ki yeniden denemeler insanları rahatsız etmesin.

İzleme ve operasyon görünürlüğü

İlk günden itibaren izleme kurun:

• Ana uygulama ve API için uptime kontrolleri
• Frontend ve backend istisnaları için hata takibi
• Kuyruk sağlığı: iş gecikmesi, hatalar ve yeniden deneme sayıları
• E-posta teslimi: bounce’lar, spam blokları ve webhook hataları

Ayrıca “duyuru yayınlandı”, “hatırlatma gönderildi” ve “onaylandı” gibi ana olayları kaydedin ki destek tahmin yürütmeden sorulara cevap verebilsin.

Pratik MVP kontrol listesi (ve v2 yol haritası)

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