Kurumsal kritik bildirim platformu için RFP/RFI değerlendirme checklist’i.
Kurumsal bildirim, kritik iletişim, SLA, eskalasyon, audit trail, on-premise ve AI karar destek ihtiyaçları için RFP/RFI teknik şartname kontrol listesi.
Güncellendi: 2026-06-25
RFP/RFI veya teknik şartname hazırlığında yalnızca "bildirim gönderme" yeteneğini değerlendirmek, kurumsal bir kritik iletişim platformunu eksik tanımlar; doğru değerlendirme için hedefleme, okudum/onayladım kaydı, SLA, eskalasyon, audit trail, entegrasyon, on-premise kurulum, veri gizliliği ve raporlama kriterleri de ayrı başlıklar olarak ele alınmalıdır. Notivex bu başlıkları somut maddelere dönüştürebileceğiniz bir kurumsal değerlendirme çerçevesi olarak sunar; böylece teknik komite, gönderim hacmi gibi yüzeysel metrikler yerine kanıtlanabilir okudu/onay oranı, eskalasyon yolu ve denetlenebilir operasyon kaydı gibi ölçütlerle tedarikçileri karşılaştırabilir.
Bu sayfa kimler için?
- **Satın alma müdürleri ve teknik komiteler** — bir kritik bildirim/kurumsal iletişim platformu için teknik şartname maddelerini sıfırdan çıkaran veya mevcut taslağı gözden geçirenler.
- **Bilgi işlem ve sistem yöneticileri** — LDAP/SSO, SMS fallback, on-premise/hibrit kurulum ve entegrasyon kriterlerini şartnameye doğru ifadelerle yazmak isteyenler.
- **Kamu ve enterprise ihale/satın alma ekipleri** — çok sayıda tedarikçiyi objektif, ölçülebilir ve karşılaştırılabilir kriterlerle değerlendirmesi gereken karar komiteleri.
- **Pilot ve POC sorumluları** — satın alma öncesi başarı metriklerini ve kabul kriterlerini önceden tanımlamak isteyen proje liderleri.
RFP/RFI ve teknik şartname neden farklı bir gözle ele alınmalı?
Kurumsal bildirim ihtiyacı çoğu zaman "personele toplu mesaj atalım" cümlesiyle başlar; ancak gerçek ihtiyaç ortaya çıktığında soru farklılaşır: Mesaj gerçekten okundu mu? Okumayan kişiye ne oldu? Kritik bir vardiya değişikliği, sistem kesintisi veya saha güvenlik uyarısında doğru kişiye, doğru kanaldan, kanıtlanabilir biçimde ulaşıldı mı?
Bu sorular bir RFP/RFI sürecinde yanıtlanmazsa, satın alınan ürün "mesaj gönderebilen" ama "kim okudu, kim onayladı, kim sorumlu kaldı" sorularını yanıtlayamayan bir araç olur. İyi yazılmış bir şartname tam da bu noktada koruyucu işlev görür; gönderim yeteneği yerine görünürlük, onay, SLA, eskalasyon ve denetlenebilirlik ekseninde ölçer ve satın alma kararını tek bir özellik listesinden çıkarıp gerçek kritik iletişim senaryolarına dayanan bir karşılaştırmaya dönüştürür.
Klasik yöntemler neden yetersiz kalır?
Birçok kurum, bildirim ihtiyacını mevcut araçlarla çözmeye çalışır ve şartnameyi de bu alışkanlık üzerine kurar. Pratikte sık görülen eksikler şunlardır:
- E-posta ve genel mesajlaşma uygulamaları gönderim yapar ama "okundu/onaylandı" kaydını operasyonel kanıt seviyesinde tutmaz; bir bildirimin kim tarafından, ne zaman görüldüğü çoğu zaman izlenemez.
- Duyuru panosu mantığı pasif görünürlüğe dayanır; kritik mesaj görmezden gelindiğinde bunu yakalayan bir mekanizma yoktur.
- Şartnamede sadece "SMS/e-posta gönderebilmeli" maddesi olması, eskalasyon, SLA ve audit trail gibi kurumsal gereksinimleri dışarıda bırakır.
- Entegrasyon ve kimlik yönetimi (LDAP/SSO) atlanırsa, sistem kullanıcı yönetimi açısından sürdürülemez hâle gelir.
- On-premise/veri gizliliği kriterleri yazılmazsa, regülasyona tabi kurumlar satın alma sonrası uyum sorunlarıyla karşılaşır.
Bu eksiklerin ortak noktası, değerlendirmenin "gönderim" üzerine kurulup "sonuç ile sorumluluk" üzerine kurulmamasıdır.
Notivex yaklaşımı
Notivex, kritik iletişimi yalnızca bir mesaj gönderme işlevi olarak değil; hedefleme → zorunlu görünürlük → onay kaydı → SLA → eskalasyon → audit trail → raporlama zinciri olarak ele alan AI-native bir operasyonel karar destek ve kritik iletişim platformudur. RFP/RFI bağlamında bunun pratik karşılığı, soyut isteklerin ölçülebilir şartname maddelerine dönüştürülebilmesidir.
Örneğin "mesaj iletilsin" isteği, Notivex çerçevesinde "tanımlı kişi/rol grubuna iletilen bildirim için okundu ve onaylandı kaydı tutulabilmeli, belirlenen SLA süresinde yanıt alınmazsa otomatik eskalasyon tetiklenebilmeli ve tüm bu adımlar denetlenebilir operasyon kaydında saklanabilmeli" şeklinde somutlaşır. SMS fallback, LDAP/SSO, on-premise/hibrit kurulum ve local LLM ile çalışan AI karar destek seçenekleri de aynı çerçevede ayrı kriterler olarak konumlanır.
Burada önemli bir dürüstlük notu: Notivex bir kritik iletişim ve operasyonel karar destek platformudur; tam kapsamlı bir İSG, EBYS, ITSM, SIEM veya SOAR sistemi değildir ve tüm kriz/afet süreçlerini tek başına çözdüğünü iddia etmez. Veri gizliliği başlıkları KVKK gereksinimlerine göre yapılandırılabilir; tuttuğu kayıtlar denetlenebilir operasyon kaydı niteliğindedir. Şartnamenizde Notivex'i, mevcut sistemlerin yerine geçen değil, kritik iletişimi tamamlayan bir katman olarak konumlandırmak en doğru yaklaşımdır.
Örnek senaryo
Bir enerji dağıtım şirketinin satın alma müdürü, saha ekipleri için kritik bildirim platformu RFI'si hazırlıyor. İlk taslakta yalnızca "toplu SMS ve e-posta gönderebilmeli" maddesi var. Teknik komite incelemesinde, geçen kış yaşanan bir trafo arızasında bazı saha personelinin uyarıyı görmediği, ancak bunun belgelenemediği hatırlatılıyor.
Komite, RFI'yi bu çerçeveyle güncelliyor ve tedarikçilere şu kriteri içeren bir talep iletiyor:
> "Sistem; bölge bazlı hedefleme ile gönderilen kritik bildirimde, personelin okudu/onayladı kaydını zaman damgasıyla tutabilmeli; 15 dakika içinde onaylamayan personel için bir üst amire otomatik eskalasyon yapabilmeli ve tüm bildirim, okuma, onay ve eskalasyon adımları denetlenebilir operasyon kaydı olarak raporlanabilmelidir. Çözüm, kurum veri politikası gereği on-premise veya hibrit kurulumla sunulabilmelidir."
Bu tek madde sayesinde değerlendirme, "kim daha çok kanaldan mesaj atıyor" sorusundan "kim sonucu kanıtlayabiliyor ve sorumluluğu izlenebilir kılıyor" sorusuna kayıyor; tedarikçi karşılaştırması da bu somut kriter üzerinden objektifleşiyor.
Değerlendirme checklist başlıkları
Aşağıdaki başlıklar, kurumsal bir kritik bildirim platformu için RFP/RFI veya teknik şartnamede madde madde sorulması önerilen değerlendirme noktalarıdır:
- Kritik bildirim — rol/grup/bölge bazlı hedefleme, öncelik seviyeleri ve çok kanallı gönderim yapılabiliyor mu?
- Zorunlu görünürlük — kritik mesaj, pasif duyuru yerine kullanıcının görmesini gerektiren bir akışla iletilebiliyor mu?
- Onay kaydı (okudum/onayladım) — bildirimin kim tarafından, ne zaman okunup onaylandığı zaman damgasıyla tutuluyor mu?
- SLA — bildirim ve yanıt süreleri için hedef tanımlanabiliyor ve ihlaller izlenebiliyor mu?
- Eskalasyon — tanımlı sürede onaylanmayan bildirim, otomatik olarak bir üst seviyeye yönlendirilebiliyor mu?
- Audit trail — gönderim, okuma, onay ve eskalasyon adımları denetlenebilir operasyon kaydı olarak saklanıyor mu?
- Raporlama — okudu/onay oranları, SLA performansı ve eskalasyon istatistikleri raporlanabiliyor mu?
- LDAP/SSO — kurumsal kimlik yönetimiyle entegre kullanıcı oturum açma desteği var mı?
- SMS fallback — birincil kanal ulaşmazsa alternatif kanala (ör. SMS) geçiş tanımlanabiliyor mu?
- On-premise/hibrit — çözüm, kurum veri politikasına göre on-premise veya hibrit kurulabiliyor mu?
- Local LLM / AI karar destek — yapay zekâ destekli özellikler kurum içi (local) çalışacak şekilde sağlanabiliyor mu?
- Destek SLA — tedarikçinin destek yanıt ve çözüm süreleri sözleşmeyle tanımlı mı?
- Lisans ve bakım — lisanslama modeli, bakım kapsamı ve yıllık maliyetler şeffaf mı?
- Pilot metrikleri — POC/pilot için kabul kriterleri (örn. hedef okudu/onay oranı, eskalasyon doğruluğu) önceden tanımlanabiliyor mu?
Bu checklist'i tedarikçi sunumlarının üzerine bir filtre olarak uygulamak, değerlendirmeyi öznel izlenimden çıkarıp ölçülebilir bir tabloya taşır.
Kullanılabilecek modüller
- Kritik Bildirim — rol, grup ve bölge bazlı hedefleme ile öncelikli kritik mesajların iletilmesi.
- SLA — bildirim ve yanıt süreleri için hedef tanımlama ve ihlal takibi.
- Audit Trail — gönderim, okuma, onay ve eskalasyon adımlarının denetlenebilir operasyon kaydı olarak saklanması.
- On-Premise — kurum veri politikasına göre on-premise veya hibrit kurulum seçeneği.
- Entegrasyonlar — LDAP/SSO ve mevcut kurumsal sistemlerle bağlantı kurma yeteneği.
Sık sorulan sorular
RFP/RFI nedir?
RFI (Request for Information / Bilgi Talebi), bir kurumun ihtiyacını netleştirmek ve piyasadaki çözümler hakkında bilgi toplamak için tedarikçilere gönderdiği ön bilgi talebidir. RFP (Request for Proposal / Teklif Talebi) ise, ihtiyaç netleştikten sonra tedarikçilerden detaylı teknik ve ticari teklif istenen, çoğu zaman teknik şartnameye dayanan resmi süreçtir. Kritik bildirim platformu seçiminde RFI genellikle "hangi yetenekler mümkün" sorusunu, RFP ise "bu somut kriterleri nasıl ve hangi maliyetle karşılıyorsunuz" sorusunu yanıtlar.
Kurumsal bildirim sistemi şartnamesinde neler olmalı?
Şartname yalnızca "SMS/e-posta gönderebilmeli" maddesiyle sınırlı kalmamalıdır. İçeriğinde hedefleme (rol/grup/bölge), zorunlu görünürlük, okudum/onayladım kaydı, SLA tanımı, otomatik eskalasyon, audit trail, raporlama, LDAP/SSO entegrasyonu, SMS fallback, on-premise/hibrit kurulum, veri gizliliği yapılandırması, destek SLA, lisans/bakım modeli ve pilot kabul metrikleri yer almalıdır. Bu başlıklar, gönderim yeteneğini değil sonuç ve sorumluluk izlenebilirliğini ölçer.
SLA ve audit trail şartnameye yazılmalı mı?
Evet, kurumsal bir kritik iletişim ihtiyacında bu iki başlık genellikle ayrı ve net maddeler olarak yazılmalıdır. SLA, bildirim ve yanıt sürelerine hedef koyarak performansın ölçülebilir olmasını sağlar. Audit trail ise gönderim, okuma, onay ve eskalasyon adımlarını denetlenebilir operasyon kaydı olarak saklayarak, "ne oldu, kim sorumluydu, ne zaman gerçekleşti" sorularının sonradan yanıtlanabilmesini mümkün kılar. Bu maddeler olmadan, sistem mesaj gönderir ama operasyonel hesap verebilirliği desteklemez.
On-premise ihtiyaçlar nasıl değerlendirilir?
On-premise ihtiyacı, kurumun veri politikası, regülasyon yükümlülükleri ve mevcut altyapısı dikkate alınarak değerlendirilir. Şartnamede; verinin nerede tutulacağı, kurulumun on-premise mi hibrit mi olacağı, yapay zekâ destekli özelliklerin kurum içi (local LLM) çalışıp çalışamayacağı ve bakım/güncelleme sürecinin nasıl yürütüleceği ayrı maddeler olarak sorulmalıdır. Veri gizliliği başlıkları KVKK gereksinimlerine göre yapılandırılabilir biçimde ele alınmalı; tedarikçinin bu kurulum modelini hangi koşullarda sağladığı netleştirilmelidir.
Notivex teknik değerlendirme süreci bu aşamada nasıl yardımcı olur?
Notivex, RFP/RFI ve teknik şartname hazırlığında soyut ihtiyaçları somut, ölçülebilir maddelere dönüştürmeniz için bir değerlendirme çerçevesi sunar; checklist başlıklarını sizin senaryolarınıza uyarlamanıza ve tedarikçileri aynı kriterlerle karşılaştırmanıza yardımcı olur. Ücretsiz Demo görüşmesinde (ücretsiz ön-satış görüşmesi), kritik iletişim, SLA, eskalasyon, audit trail, entegrasyon ve on-premise başlıklarının kurumunuzdaki karşılığını birlikte gözden geçirebilir, pilot için ölçülebilir kabul metrikleri belirleyebilirsiniz. Notivex bu süreçte mevcut sistemlerinizin yerine geçen değil, kritik iletişimi görünürlük, onay, SLA ve audit ile tamamlayan bir katman olarak konumlanır.
Kurumunuz için Notivex’i değerlendirmek ister misiniz?
Kritik iletişim, okudum/onayladım kayıtları, SLA takibi, eskalasyon ve denetlenebilir raporlama ihtiyacınızı ücretsiz demo görüşmesinde birlikte değerlendirebiliriz.