Talep Yönetimi ve SLA Takibi: Apartman ve Siteler İçin Rehber

Talep yönetimi ve SLA (hizmet süresi) takibi, bir apartman veya sitenin sakinlerinden gelen arıza bildirimleri, şikayetler ve hizmet taleplerinin kayıt altına alınmasını, sorumluya atanmasını ve belirlenen süre içinde kapatılmasını sağlayan sistematik süreçtir. "Ne zaman hallolacak?" sorusunun cevabını hem sakin hem yönetici her an görebiliyorsa, SLA takibi doğru çalışıyor demektir.

Talep Yönetimi Nedir ve Neden Kritiktir?

Bir sitede yaşayan her sakin, zaman zaman ortak alanlarla veya bağımsız bölümleriyle ilgili sorunlar yaşar: asansörün arızalanması, otoparkta aydınlatma eksikliği, havuzda teknik aksaklık ya da kapıcı hizmetlerine dair bir şikayet. Bu taleplerin herhangi bir kayıt mekanizması olmadan yöneticiye iletilmesi — WhatsApp mesajı, telefon araması ya da kapı zili — kaçınılmaz olarak kayıplara, unutmalara ve sakin memnuniyetsizliğine yol açar.

Talep yönetimi, bu dağınıklığı ortadan kaldıran bir yapıdır. Her talep sisteme kaydedilir, benzersiz bir numara alır, ilgili kişiye atanır ve çözüm süreci boyunca izlenebilir hale gelir. Sakin talebini ilettikten sonra "sıraya girdi, işleniyor" bilgisini alır; yönetici ise hangi talebin kime verildiğini, ne zamana kadar tamamlanması gerektiğini tek bir ekrandan takip eder.

Türkiye'deki apartman ve site yönetimlerinin büyük çoğunluğu hâlâ kağıt defteri, telefon notu veya grup sohbetleriyle iş yürütmektedir. Bu yöntemler ölçeklenmez: beş sakinle idare edilebilir, elli sakinle kaotik olur, beş yüz sakinle çöker. Profesyonel bir site yönetim yazılımı üzerinden yürütülen talep yönetimi ise ölçek bağımsız çalışır ve şeffaflık sağlar.

Ayrıca yöneticilerin hukuki sorumluluğu açısından da kritiktir. 634 sayılı Kat Mülkiyeti Kanunu, yöneticinin ortak yerlerin bakımından sorumlu olduğunu açıkça düzenler. "Bildirmedim" iddiasına karşı, sisteme kaydedilmiş ve zaman damgalı talep geçmişi en güçlü savunmadır.

SLA (Hizmet Süresi Anlaşması) Kavramı ve Apartman Yönetimine Uyarlanması

SLA (Service Level Agreement — Hizmet Düzeyi Anlaşması) kavramı özünde bir taahhüttür: "Bu tür bir sorunu en geç şu süre içinde çözeceğim." Kurumsal BT sektöründen gelen bu terim, günümüzde profesyonel mülk yönetimi şirketlerinin ve büyük site yönetimlerinin vazgeçilmez aracı haline gelmiştir.

Apartman yönetimi bağlamında SLA, talepleri öncelik seviyesine göre sınıflandırır ve her seviye için azami çözüm süresi belirler. Örneğin asansör arızası "kritik" kategoridedir ve 4 saat içinde müdahale gerektirir; ortak alan ampulü değişikliği "düşük öncelikli" sayılır ve 72 saat içinde tamamlanması yeterli görülür.

Yönetim planı veya kat malikleri kurulu kararıyla bu süreler yazılı hale getirildiğinde SLA artık yasal bir taahhüt niteliği kazanır. Bir sakin, belirlenen sürede çözülmeyen talebi gerekçe göstererek yönetici aleyhine şikayet başlatabilir. Bu nedenle gerçekçi ama hesap verebilir süreler belirlemek, hem sakin güvenini pekiştirir hem de yöneticiyi korur.

SLA'nın en önemli işlevi eskalasyon mekanizmasıdır. Süre dolduğunda sistem otomatik uyarı gönderir; uyarıya rağmen tamamlanmayan talepler üst kademeye (yönetici kurulu, denetçi) iletilir. Bu yapı, insan faktörünün neden olduğu gecikmeleri en aza indirir ve "unutuldu" mazeretini ortadan kaldırır.

Talep Kategorileri ve Öncelik Sınıflandırması

Etkili bir talep yönetimi sistemi, gelen her talebi doğru kategoriye ve öncelik seviyesine yerleştirmelidir. Kategorizasyon hem doğru kişiye atamayı hem de uygun SLA süresini belirlemeyi kolaylaştırır. Kategoriler genel olarak şu başlıklar altında toplanabilir:

• Teknik Arıza: Asansör, jeneratör, hidrofor, elektrik panosu, su tesisatı, ısıtma-soğutma sistemleri gibi mekanik/elektrik arızaları. Hayatı doğrudan etkileyen bu kategori genellikle yüksek önceliklidir.
• Bakım ve Onarım: Boya, badana, zemin döşeme, kapı-pencere onarımı gibi planlı veya acil olmayan müdahaleler.
• Temizlik ve Hijyen: Ortak alan temizliği, çöp toplama, haşere ilaçlaması talepleri.
• Güvenlik: Kamera arızası, kapı görevlisi şikayeti, yabancı araç şikayeti, giriş sistemi sorunu.
• İdari ve Belge: Aidat dekontu, yönetim planı kopyası, toplantı davet belgesi gibi evrak talepleri.
• Komşu Şikayeti: Gürültü, koku, ortak alan işgali gibi sakinler arası anlaşmazlık bildirimleri.
• Öneri ve Geri Bildirim: Acil müdahale gerektirmeyen, uzun vadeli iyileştirme önerileri.

Her kategori için öncelik seviyesi (kritik / yüksek / orta / düşük) ve buna karşılık gelen azami çözüm süresi önceden tanımlanmalıdır. Böylece talep sisteme girdiğinde SLA saati otomatik olarak başlar ve ilgili personel ne kadar süresi kaldığını her an görür.

Öncelik belirlemede dikkat edilmesi gereken nokta şudur: aynı teknik arıza mevsime ve saate göre farklı öncelik alabilir. Kışın çalışmayan kalorifer sistemi kritikken yazın orta önceliğe düşebilir. Sisteminizin bu tür bağlamsal kuralları desteklemesi, gereksiz "kritik" alarmlara yol açmadan kaynakları doğru yönlendirmenizi sağlar.

Talep Alma Kanalları: Çok Kanallı Yaklaşım

Sakinlerin farklı teknoloji yetkinlikleri ve tercihleri olduğu göz önüne alındığında, tek bir talep kanalına mahkum olmak hizmet erişilebilirliğini düşürür. Etkili bir talep yönetimi sistemi, farklı kanallardan gelen talepleri merkezi bir havuzda birleştirmelidir.

Mobil uygulama, dijital çağın en tercih edilen kanalıdır. Sakin, telefonuyla birkaç dokunuşta arıza fotoğrafını yükleyerek talebi iletebilir, sonrasında ise aynı ekrandan ilerlemeyi takip edebilir. Bu kanal özellikle genç sakin kitlesi için vazgeçilmezdir. Web portalı ise masaüstü kullanıcılar ve evrak talepleri gibi detaylı açıklama gerektiren durumlar için uygundur.

E-posta entegrasyonu, özellikle yaşlı sakinler veya dijital uygulama kullanmayan bireyler için önemlidir. Sisteme entegre bir e-posta adresi üzerinden gelen mesajlar otomatik olarak talebe dönüştürülür; sakin hiçbir ek işlem yapmadan sistemin içine dahil edilmiş olur. Telefon görüşmeleri ise yönetici tarafından manuel olarak sisteme kaydedilmeli ve talep numarası sakinle paylaşılmalıdır.

Giderek yaygınlaşan bir diğer kanal ise bina içi kiosk ekranlardır. Lobi veya asansör önüne yerleştirilen dokunmatik ekranlar, internetle ilişkisi zayıf sakinlerin bile dijital talep oluşturmasına imkan tanır. Hangi kanal kullanılırsa kullanılsın, talebin mutlaka bir numara alması ve sakinle paylaşılması gerekir; bu, sistemin güvenilirliğinin temelidir.

SLA Süreleri Nasıl Belirlenmeli?

SLA sürelerini belirlemek hem teknik gerçekçilik hem de sakin beklentisi yönetimi gerektiren stratejik bir karardır. Çok kısa süreler kaynak yetersizliği nedeniyle sürekli ihlale yol açar ve güven zedeler; çok uzun süreler ise sakin memnuniyetini düşürür.

Aşağıdaki tablo, Türkiye'deki büyük ölçekli site yönetimlerinde yaygın olarak benimsenen SLA sürelerini göstermektedir:

Bu süreler sabit değildir; sitenin büyüklüğüne, teknik ekip kapasitesine ve anlaşmalı servis şirketlerinin garantilerine göre uyarlanmalıdır. Önemli olan, kat malikleri kurulunun bu süreleri bilerek onaylamış olmasıdır. Böylece hem yönetici standartlara bağlı kalır hem de sakinler gerçekçi beklentilerle talep iletir.

SLA sürelerinin taahhüt edilmesinin yanı sıra bu sürelerin tutarlı biçimde karşılanıp karşılanmadığı da ölçülmelidir. Aylık raporlarda "SLA uyum oranı" metriği görünür kılınmalıdır. Örneğin "geçen ay 87 talebin 79'u SLA süresi içinde kapatıldı (%91 uyum)" şeklinde şeffaf bir veri sunmak, kat maliklerinin yöneticiye güvenini pekiştirir.

Dijital Talep Yönetimi Sisteminin Temel Özellikleri

Kağıt veya mesajlaşma uygulamaları üzerinden yürütülen talep yönetiminin sınırlarını aşmak için dijital bir platforma geçiş kaçınılmazdır. Peki etkili bir apartman yönetim programının talep modülünde hangi özellikler bulunmalıdır?

Otomatik numara ve zaman damgası: Her talep sisteme girildiği anda benzersiz bir referans numarası alır ve açılış zamanı kaydedilir. Bu kayıt hukuki uyuşmazlıklarda delil niteliği taşır. Sakin, talep numarasıyla istediği zaman durumu sorgulayabilir.

Akıllı atama: Sistem, kategori ve konum bilgisine göre talebi ilgili personele veya servis firmasına otomatik olarak yönlendirmelidir. Manuel atama zorunluluğu hem gecikmeye hem de unutmaya yol açar.

SLA sayacı ve uyarı mekanizması: Talep açıldığı anda SLA saati başlar. Sürenin %75'i dolduğunda atanan kişi, %100'ünde ise yönetici uyarı alır. Bu eskalasyon zinciri, sorunu sahipsiz kalarak çözümsüz kalmaktan korur.

Fotoğraf ve dosya ekleme: Sakin, arızanın fotoğrafını ekleyebilmeli; teknisyen ise tamamlanan iş için "tamamlandı" fotoğrafı yüklemelidir. Bu görsel belgeleme, özellikle müteahhit veya servis firmasıyla anlaşmazlık durumunda kritik öneme sahiptir.

Sakin bildirimleri: Talep açıldığında, sorumluya atandığında ve kapatıldığında otomatik bildirim gönderilmesi, sakin güvenini doğrudan artırır. "Haberdar değilim" şikayeti ortadan kalkar.

Raporlama ve analitik: Aylık, çeyreklik ve yıllık bazda kaç talep açıldığı, kategorilere göre dağılım, ortalama çözüm süresi ve SLA uyum oranı gibi metrikler yöneticiye hem performans değerlendirme hem de bütçe planlaması için veri sağlar.

Yasal Çerçeve: Kat Mülkiyeti Kanunu ve Yönetim Sorumluluğu

634 sayılı Kat Mülkiyeti Kanunu, yöneticinin görev ve sorumluluklarını kapsamlı biçimde düzenler. Kanunun ilgili hükümlerine göre yönetici, ortak yerlerin bakım ve onarımını yapmakla yükümlüdür; bu yükümlülüğü yerine getirmemesi halinde kat maliklerinden birinin başvurusu üzerine mahkeme yöneticiyi görevden alabilir.

Talep yönetimi sistemi bu bağlamda yöneticinin aleyhine değil, lehine çalışır. Sisteme kayıtlı bir talep, yöneticinin ilgili şikayetten haberdar olduğunun kanıtıdır. Eğer talep kaydedilmiş, sorumluya atanmış ve çözümü için makul adımlar atılmışsa yönetici, meydana gelen zarardan bireysel olarak sorumlu tutulamaz. Aksine, kayıt dışı kalan bir şikayet yüzünden ortaya çıkan zarar, yöneticinin ihmalini ispatlama açısından kat malikine avantaj sağlar.

Öte yandan 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) da talep yönetimi sürecinde göz önünde bulundurulmalıdır. Sakinlerin ilettiği şikayetler ve fotoğraflar kişisel veri niteliği taşıyabilir. Bu verilerin yalnızca yetkili personel tarafından erişilebilir olması, makul bir süre sonra arşivlenmesi veya imha edilmesi ve sakinlerin açık rızasıyla sisteme kaydedilmesi, KVKK uyumluluğu açısından zorunludur. Profesyonel bir yönetim yazılımı bu gereksinimleri veri işleme altyapısında karşılamalıdır.

Yönetim planında SLA sürelerinin ve talep yönetimi prosedürlerinin açıkça yer alması, kat malikleri kurulunun bu konuyu gündemde tutmasını sağlar. Böylece ortak bir beklenti standardı oluşturulur ve her türlü uyuşmazlık bu standart üzerinden değerlendirilebilir. Bu konulara ilişkin herhangi bir karar almadan önce hukuki danışmanlık alınması tavsiye edilir; bu makale genel bilgi amaçlıdır.

Uygulama Süreci: Sıfırdan SLA Sistemine Geçiş

Talep yönetimi ve SLA sistemine geçişi planlarken temkinli ama kararlı bir yaklaşım benimsemek gerekir. Ani geçişler personel ve sakin tarafından dirençle karşılanabilir; kademeli bir uygulama ise benimsemeyi kolaylaştırır.

1. Mevcut durumu haritalandırın: Şu anda taleplerin nasıl alındığını, kime iletildiğini ve nasıl çözüldüğünü belgeleyin. Bu haritalama, yeni sistemde hangi adımların otomasyona taşınacağını belirler.

2. Kategori ve SLA sürelerini tanımlayın: Yukarıda önerilen öncelik tablosunu sitenize özgü koşullara göre uyarlayın. Kapasite gerçeklerinizle örtüşmeyen süreler başarısızlığa davetiye çıkarır.

3. Yazılım seçin ve yapılandırın: Site yönetim yazılımı seçiminde talep yönetimi ve SLA özellikleri öncelikli kriter olmalıdır. Demo sürecinde gerçek senaryolarla test edin; özellikle eskalasyon ve bildirim mekanizmalarını denetleyin.

4. Personeli eğitin: Kapıcı, güvenlik görevlisi ve yönetici yardımcısı dahil tüm sürece dahil olan kişiler sistemi kullanabilmeli ve talep kayıt sürecini bilmelidir. Eğitim olmadan en iyi sistem bile işlevsiz kalır.

5. Sakinleri bilgilendirin: Sisteme geçişi duyurduğunuz bir iletişim yazısı hazırlayın. Sakinlere talep iletme kanallarını, numarayı nasıl takip edeceklerini ve hangi sürelerde çözüm bekleyebileceklerini açıklayın.

6. İlk üç ayı pilot dönem olarak değerlendirin: Bu dönemde SLA ihlallerini yakından izleyin; kronik gecikmelerin arkasındaki sistematik sorunları (yetersiz personel, anlaşmalı firmanın yavaşlığı vb.) tespit edin ve düzeltin. İlk sonuçları kat malikleri toplantısında şeffaf biçimde paylaşmak güven tesis eder.

SLA Performansını Ölçme ve Raporlama

Ölçülmeyen şey geliştirilemez. Talep yönetimi ve SLA sisteminin sağlıklı işlediğini doğrulamanın tek yolu, düzenli performans ölçümü ve raporlamadır. Bu raporlar hem yöneticiye operasyonel görünürlük sağlar hem de kat maliklerine hesap verebilirlik sunar.

İzlenmesi gereken temel metrikler şunlardır: Toplam talep sayısı ve kategorilere göre dağılımı; ortalama ilk yanıt süresi; ortalama çözüm süresi; SLA uyum oranı (zamanında kapatılan talepler / toplam talepler); yeniden açılan talepler (çözüm kalitesini ölçer); sakin memnuniyet puanı (talep kapatıldıktan sonra anket göndererek elde edilir).

Bu metriklerin aylık bazda raporlanması ve kat malikleri toplantısında paylaşılması, yöneticinin performansını somut veriye dayandırır. "İyi yönetiyorum" iddiasını kanıtlamak için artık rakamlar konuşur. Öte yandan kronik gecikmeler yaşanan kategoriler bu raporlarda netleşir; çözüm olarak ek personel alımı, farklı bir servis firmasıyla sözleşme ya da bütçe artışı talep edilebilir.

Yıllık raporlarda ise trend analizi yapılabilir. Kış aylarında teknik arızalar mı artıyor? Belirli bir bloktan gelen talepler mi yoğunlaşıyor? Bu örüntüler proaktif bakım planlamasına ve bütçe öngörüsüne rehberlik eder. Reaktif tamir yerine önleyici bakım, hem maliyeti düşürür hem de sakin deneyimini iyileştirir.

Mülk Yönetim Şirketleri İçin Çok Siteli SLA Yönetimi

Birden fazla siteyi yöneten profesyonel mülk yönetim şirketleri için talep yönetimi ve SLA takibi çok daha karmaşık bir boyut kazanır. Her sitenin kendi sakinleri, kendi teknik ekibi ve farklı altyapı koşulları bulunmaktadır. Bu çeşitlilik içinde tutarlı hizmet kalitesini korumak ancak merkezi bir platformla mümkündür.

Çok siteli yapılarda rezidans yönetim sistemi veya geniş kapsamlı bir yönetim platformu, her sitenin taleplerini kendi bağlamında tutarken şirket genelinde birleşik raporlamaya imkan tanımalıdır. Yönetici şirketin genel müdürü, hangi sitenin SLA performansının en zayıf olduğunu tek bir ekrandan görebilmelidir.

Çok siteli yapıların avantajı, paylaşılan kaynaklar oluşturmaktır. Örneğin elektriki veya sıhhi tesisatçı gibi uzmanlar tüm siteler için ortak anlaşmayla tutulabilir; birinin doluluk durumuna bakılarak talep en uygun kişiye yönlendirilebilir. Bu kaynak optimizasyonu hem maliyeti düşürür hem de SLA sürelerine uyumu artırır.

Büyük ölçekli ticari mülklerde — AVM'ler, ofis kompleksleri — SLA yönetimi daha da kritik bir hal alır. Kiracı sözleşmelerinde hizmet süresi taahhütleri yer alır ve ihlal tazminat yükümlülüğü doğurabilir. Bu nedenle AVM yönetim yazılımı seçiminde talep modülünün güçlü ve özelleştirilebilir olması öncelikli bir kriter olmalıdır.

Sık Sorulan Sorular