BT Servis Yönetimi, Hazır ve Entegre
Talep, arıza ve değişiklik yönetimi süreçleri kurulu gelir — üzerine kurumunuza özgü alanları eklemeniz yeterli.
Her Talebin Bir Sahibi, Bir SLA'sı Var
Kullanıcılar bir portal üzerinden talep/arıza kaydı açar. Kayıt açılır açılmaz sistem boş bırakmaz: girilen başlık ve açıklamaya bakarak kategori ve öncelik önerir — kullanıcı sıfırdan bir sınıflandırma listesiyle uğraşmaz, öneriyi onaylar ya da gerekirse değiştirir. Doğru kategoriye düşen kayıt da otomatik olarak ilgili ekibe yönlendirilir; talep önce bir yönlendirme kuyruğunda beklemez.
Her kaydın, kritiklik seviyesine göre tanımlı bir SLA (hizmet seviyesi) hedefi vardır: kritik bir sunucu arızası ile küçük bir yazıcı sorunu aynı yanıt/çözüm süresi hedefine bağlanmaz. Sistem bu süreyi arka planda takip eder ve hedef dolmadan önce ilgili teknisyene, süre iyice daralırsa yöneticisine de otomatik bir uyarı gönderir — sorun, süresi geçtikten sonra fark edilen bir şey olmaktan çıkar.
Örneğin "e-posta sunucusuna bağlanamıyorum" başlığıyla açılan bir kayıt otomatik olarak "Altyapı / Kritik" kategorisine düşer, 1 saatlik yanıt hedefiyle ilgili ekibe düşer; 45. dakikada hâlâ atanmamışsa teknisyenin yöneticisine uyarı gider. Aynı anda açılan "yazıcıda kağıt sıkışması" kaydı ise "Donanım / Düşük" olarak işaretlenir ve günlük hedefle bekler — iki kayıt aynı kuyrukta birbirini geciktirmez.
Değişiklik Onaysız Uygulanmaz
Bir üretim sistemine dokunan her değişiklik — bir sunucu güncellemesi, bir konfigürasyon değişikliği, bir entegrasyon güncellemesi — önce tanımlı bir onay sürecinden geçer. Değişikliği talep eden kişi neyi, neden değiştirmek istediğini ve hangi sistemlerin bundan etkileneceğini kayıt altına alır; onaylayan taraf riski görerek karar verir. Onaysız bir değişiklik üretime yansımaz, ve kimin ne zaman neyi değiştirdiği kalıcı olarak izlenir — bir sorun çıktığında "son ne değişti" sorusunun cevabı aranmaz, kayıtta zaten durur.
Bilgi tabanı (knowledge base) ise tekrar eden arızaların çözümünü kurumsal hafızaya dönüştürür: bir teknisyen bir sorunu çözdüğünde bunu bir makale olarak kaydedebilir. Bir sonraki talep açıldığında sistem, kaydın başlık ve açıklamasına bakarak benzer geçmiş çözümleri otomatik önerir — teknisyen aynı sorunu sıfırdan araştırmak zorunda kalmaz, tekrar eden arızalarda çözüm süresi kısalır.
Örneğin VPN bağlantı sorunu daha önce üç kez yaşanmış ve çözümü bilgi tabanına yazılmışsa, dördüncü talep açıldığı anda bu çözüm teknisyene önerilir; teknisyen makaleyi uygulayıp kaydı kapatır. Aynı şekilde bir e-posta sunucusu güncellemesi değişiklik yönetiminden geçerken, hangi entegrasyonların (örneğin toplu bildirim gönderen bir süreç adımının) bundan etkilenebileceği talep formunda belirtilir — onaylayan kişi riski görmeden "evet" demez.
- Otomatik Sınıflandırma: talep açılır açılmaz başlık/açıklamaya bakarak kategori ve öncelik önerir, doğru ekibe otomatik yönlendirir.
- SLA ve Eskalasyon: kritiklik seviyesine göre yanıt/çözüm süresi hedefi takip edilir, hedef dolmadan önce teknisyene, gerekirse yöneticisine uyarı gider.
- Değişiklik Onayı: üretim sistemine dokunan her değişiklik onay sürecinden geçmeden uygulanmaz; kim ne zaman neyi değiştirdi kalıcı olarak izlenir.
- Bilgi Tabanı Önerisi: yeni bir talep açıldığında sistem başlık/açıklamaya bakarak benzer geçmiş çözümleri otomatik önerir.
- Ortak Denetim İzi: aynı süreç motoru, aynı kullanıcı dizini ve aynı denetim izi kullanılır — ayrı bir lisans/kimlik doğrulama kurulumu gerekmez.
Süreç Motoruyla Aynı Denetim İzi
SLA Takibi
Öncelik bazlı hedef süre + otomatik eskalasyon.
Değişiklik Onayı
No-code onay zinciriyle kontrollü değişiklik.
Bilgi Tabanı
Geçmiş çözümlerin aranabilir arşivi.
Servis Raporları
Dashboard modülüyle entegre performans metrikleri.
BT Servis Sürecinizi Birlikte Kuralım
15 dakikalık bir demo ile, mevcut bir talep sürecinizi RiverAI'da canlandıralım.
Demo Talep Et