Site Yönetim Sözleşmesi Nasıl Hazırlanır? Detayları, Teknik Bilgileri

Site Yönetim Sözleşmesi Nasıl Hazırlanır? Detayları, Teknik Bilgileri

PMC Group Logo
PMC Group Apartman & Site Yönetimi
Çevrimiçi
PMC Group

Merhaba, PMC Group burada! 👋

Apartmanınız veya siteniz için hemen destek almak ister misiniz?

Site Yönetim Sözleşmesi Nasıl Hazırlanır? Detayları, Teknik Bilgileri

Bir site/apartman yönetimini “profesyonel bir firmaya devretmek” iyi bir fikirdir; fakat işin başarıyla yürümesini sağlayan asıl şey sözleşmenin kapsamı ve maddelerin netliğidir. 2026’da maliyetler, hizmet çeşitliliği (7/24 arıza hattı, banka entegrasyonu, dijital raporlama vb.) ve KVKK yükümlülükleri arttığı için; “standart sözleşme” diye imzalanan metinler çoğu zaman yetmez. Sonuç: yönetim kurulu “yetki kimdeydi?”, site sakinleri “rapor neden gelmiyor?”, firma “bu kapsam dışı” tartışması derken süreç yıpranır.

Bu yazıda; yönetim sözleşmesi hazırlarken mutlaka yer alması gereken maddeleri, pratik örneklerle ve kontrol mantığıyla ele alıyorum. İçerik, hem yönetim kurulları hem de profesyonel yönetim firmasıyla çalışmayı planlayan siteler için bir “taslak rehber” gibi kullanılabilir.

PMC Group’un profesyonel yönetim yaklaşımı ve hizmet kapsamlarını incelemek isterseniz:

image 1

Not: Bu içerik genel bilgilendirme amaçlıdır; her sitenin yönetim planı, teknik altyapısı ve mali yapısı farklıdır. Sözleşmenin nihai halini hazırlarken/inceletirken uzman desteğimiz alın.

Yetki sınırları ve temsil: kim neyi onaylar?

Bir yönetim sözleşmesinin en çok uyuşmazlık çıkaran yeri temsil ve yetki maddeleridir. Yönetim firması sahada işi çözmek ister; yönetim kurulu ise kontrolü kaybetmek istemez. Dengeyi kurmanın yolu, “kim neyi onaylar?” sorusunu yazılı bir yetki matrisiyle netleştirmektir.

1) Taraflar ve temsil tanımı net olmalı

Sözleşmede şu tanımlar açık yazılmalı:

  • Yönetim Kurulu” kimlerden oluşur? (isim-soyisim, görev)
  • Yönetim Firması” adına imza yetkilisi kim? (ünvan)
  • Tesis/Saha Sorumlusu” kim? (operasyonel muhatap)
  • Muhasebe/Finans Muhatabı” kim? (rapor ve banka işlemleri)

Bu sayede arıza, ödeme, satın alma, hukuki süreç gibi konularda “muhatap kim?” krizi yaşanmaz.

2) Temsil kapsamı: nerelerde işlem yapılabilir?

Temsil yetkisi genelde şu alanlarda gerekir (sözleşmede tek tek yazılmalı):

  • Banka işlemleri (sadece görüntüleme mi, ödeme talimatı mı, çift imza mı?)
  • Kamu kurumları ve belediye süreçleri (başvuru, dilekçe, evrak takibi)
  • Tedarikçi sözleşmeleri (imza atabilir mi, yoksa kurul onayı + kurul imzası mı?)
  • Avukat/ hukuki temsil koordinasyonu (icra başlatma talimatını kim verir?)

PMC Group’un “şeffaflık ve banka üzerinden takip” yaklaşımını referans almak isterseniz Ankara Profesyonel Site Yönetimi sayfasındaki çalışma prensiplerini inceleyebilirsiniz.

3) Yetki matrisi (RACI) yaklaşımı: sözleşmeye ek yapın

En pratik çözüm: sözleşmeye Ek-1 Yetki ve Onay Matrisi koymak.

Örnek (kısa versiyon):

  • Aylık rutin ödemeler (elektrik-su-doğalgaz): Hazırlayan = Yönetim firması, Onaylayan = Yönetim kurulu, Uygulayan = banka üzerinden çift imza
  • Acil arıza (su patlağı, enerji kesintisi vb.): Karar = yönetim firması (acil limit dahilinde), Bilgilendirme = aynı gün kurul, Kapanış onayı = saha tutanağı + fatura
  • Sözleşme yenileme (asansör bakım vb.): Teklif = yönetim firması, Onay = kurul, İmza = kurul veya yetkili temsilci

4) “Acil durum yetkisi” mutlaka tanımlanmalı

Acil durumlarda (can güvenliği/tesis güvenliği riski, su baskını, elektrik panosu arızası vb.) “kuruldan onay beklemek” pratik değildir. Bu yüzden:

  • Acilin tanımı,
  • Acilde kullanılacak maksimum limit,
  • Bilgilendirme süresi (ör. 2 saat içinde),
  • Kanıt yükümlülüğü (fotoğraf, servis formu, tutanak)
    maddeleri yazılmalıdır.

5) İletişim kanalları ve karar ispatı (2026 standardı)

“WhatsApp’tan konuştuk” veya “telefonla onay verdim” tartışması büyümesin diye:

  • Resmî karar kanalı: e-posta + portal + yazılı tutanak
  • Acil onay kanalı: telefon/WhatsApp olabilir ama sonradan e-posta ile teyit şartı
  • Tüm talepler için “kayıt numarası” (ticket) mantığı
    eklenmelidir.

Harcama limiti, teklif toplama ve satın alma prosedürü

Sözleşmenin mali disiplinini belirleyen bölüm burasıdır. Yönetim firmasıyla çalışmanın en önemli avantajlarından biri, satın alma süreçlerinin “kişiye göre değil, prosedüre göre” işlemesidir. 2026’da özellikle şu iki riski yönetmek şart:

  1. Kontrolsüz harcama (kurul fark etmeden artan maliyet)
  2. Şeffaf olmayan satın alma (piyasa üstü fiyat, aynı tedarikçiye bağımlılık)

1) Harcama limitleri: tek bir rakam yetmez

Sözleşmede limitleri şu şekilde kurgulamak daha sağlıklı:

  • Rutin işletme giderleri (bütçede kalem kalem tanımlı)
  • Bütçe dışı giderler (ek onay şartı)
  • Acil giderler (acil limit + raporlama)
  • Yatırım/Capex (ör. çatı izolasyonu, peyzaj revizyonu, kamera sistemi yenileme) için ayrı prosedür

Örnek madde mantığı:

  • “X TL’ye kadar: yönetim firması teklif alır, kurul bilgilendirilir”
  • “X–Y TL arası: en az 2 teklif + kurul onayı”
  • “Y üzeri: en az 3 teklif + kurul kararı + sözleşme imzası”

2) Teklif toplama standardı: “aynı kapsam” şartı

Teklif karşılaştırma hatalarının büyük kısmı, tekliflerin farklı kapsamda gelmesinden kaynaklanır. Bu yüzden sözleşmede şu zorunlulukları koymak iyi sonuç verir:

  • Teklifler aynı teknik şartnameye göre istenecek
  • İş kalemleri ve metraj net olacak
  • KDV, nakliye, montaj, garanti, servis dahil/hariç açık olacak
  • Teslim süresi ve ödeme planı standart sorulacak

3) Satın alma adımları (prosedürü sözleşmeye yazın)

Basit ama etkili bir 7 adımlı prosedür:

  1. İhtiyaç bildirimi (arıza kaydı / periyodik bakım / kurul talebi)
  2. Teknik şartname veya iş tanımı
  3. Teklif toplama (min. 2–3)
  4. Teknik + mali değerlendirme (puanlama varsa ek)
  5. Kurul onayı
  6. İş emri ve uygulama
  7. Kabul-teslim + fatura kontrol + rapor kapanışı

Bakım/onarım süreçleri ile ilgili ayrıca şu sayfayı da iç link olarak kullanabilirsiniz: Ankara Site Bakım ve Onarım Hizmetleri

4) Çıkar çatışması ve komisyon yasağı maddesi (mutlaka)

2026’da iyi yönetim sözleşmelerinde şu tarz maddeler açıkça bulunur:

  • Yönetim firması veya çalışanları, tedarikçiden komisyon/prim/hediye kabul edemez.
  • Akraba/ilişkili şirketlerle işlem varsa yazılı beyan ve kurul onayı gerekir.
  • Aynı tedarikçiye “otomatik bağımlılık” oluşmaması için periyodik piyasa araştırması yapılır.

5) Malzeme–demirbaş alımlarında envanter şartı

Özellikle site malı haline gelecek alımlarda (pompa, kamera cihazı, UPS, el aleti, temizlik makinesi vb.) şu ek zorunluluklar koyun:

  • Seri numarasıyla envantere kayıt
  • Garanti belgesi ve servis bilgileri
  • Teslim alan imzası + fotoğraf

Bu, devir sırasında “ne alındı, nerede?” sorusunu çözer.


Şeffaflık maddeleri: banka hesabı, belge paylaşımı, rapor periyodu

Şeffaflık maddeleri, hem site sakinlerine karşı güveni artırır hem de yönetim kurulunu “hesap verilebilir” hale getirir. Profesyonel yönetim, çoğu zaman en çok burada değer üretir: düzenli rapor, düzenli belge akışı, net banka takibi.

1) Banka hesabı: altın kural “site adına” ve “elden değil”

Sözleşmede şu ilkeler açık yazılmalı:

  • Gelirlerin (aidat vb.) elden toplanmaması
  • Tüm gelir-giderin site/apartman adına açılan banka hesabı üzerinden yürütülmesi
  • Yönetim firmasının kendi hesabına tahsilat almaması
  • Banka erişim yetkileri: görüntüleme, işlem yapma, çift imza kuralları

Bu yaklaşımı anlatan kurumsal çerçeve için Ankara Profesyonel Site Yönetimi sayfası sitenizde doğal bir iç link noktasıdır.

2) Belge paylaşımı: “İsteyince göndeririz” değil, periyodik akış

İyi bir sözleşmede belge paylaşımı proaktif tasarlanır:

  • Her ay kapanışta: banka ekstresi, gelir-gider raporu, borçluluk özeti, büyük faturalar listesi
  • Her satın almada: teklif dosyası + kurul onayı + iş kabul tutanağı
  • Her bakımda: servis formu + periyodik kontrol kayıtları

Belge paylaşım yöntemi de net olmalı:

  • Portal/dijital klasör, e-posta, fizikî dosya
  • Yetkilendirme: kim hangi belgeyi görür?
  • Saklama: kaç yıl saklanır?

3) Rapor periyodu: tarih ve içerik standartları

Sözleşmeye raporların:

  • Hangi tarihe kadar paylaşılacağı (ör. ayın 10’una kadar)
  • Hangi formatta olacağı (PDF + Excel/CSV gibi)
  • Hangi içerik başlıklarıyla hazırlanacağı
    yazılmalıdır.

Örnek aylık rapor seti:

  • Gelir-gider tablosu (bütçe vs gerçekleşen)
  • Banka hareketleri özeti
  • Aidat tahsilat oranı + borç yaşlandırma
  • Devam eden işler/arıza listesi
  • Büyük harcamalar ve gerekçeleri
  • Bir sonraki ay planı

Muhasebe tarafındaki süreçleri destekleyen iç link için: Ankara Site Muhasebe

4) Denetim hakkı ve “açıklanabilirlik”

Yönetim kurulu/denetim kurulu için:

  • İstendiğinde evrak inceleme hakkı
  • Sistem kayıtlarına erişim (rol bazlı)
  • Yıl sonu denetim/bağımsız kontrol ihtimali
    maddeleri eklemek, yönetimi kurumsallaştırır.

Hizmet seviyesi (SLA): arıza müdahale süreleri ve yaptırımlar

SLA (Service Level Agreement) kısmı, profesyonel yönetimi “niyet beyanı” olmaktan çıkarıp ölçülebilir hale getirir. 2026’da iyi bir site yönetim sözleşmesinde SLA; sadece “7/24 ulaşılabilirlik” cümlesi değildir. Yanıt süresi, müdahale süresi, çözüm süresi, raporlama ve yaptırım birlikte yazılır.

1) Terimleri ayırın: yanıt vs müdahale vs çözüm

  • Yanıt süresi: çağrı/kayıt geldiğinde ne kadar sürede geri dönüş?
  • Müdahale süresi: sahada/uzaktan aksiyon başlatma süresi
  • Çözüm süresi: arızanın kalıcı şekilde giderilmesi

Birçok sözleşme bunları karıştırdığı için anlaşmazlık çıkar.

2) Arıza öncelik seviyeleri (P1–P4) tanımlayın

Örnek sınıflandırma:

  • P1 Kritik: can güvenliği riski, su basması, ana enerji kesintisi, yangın alarmı
  • P2 Yüksek: asansör arızası (çoklu blok), hidrofor arızası, ana giriş güvenlik sistemi
  • P3 Orta: ortak alan aydınlatma arızası, kapı otomatiği, küçük tesisat sorunları
  • P4 Düşük: estetik/konfor işleri, planlı bakım talepleri

Her seviyeye ayrı hedef süre ekleyin (site yapınıza göre uyarlayın).

3) Yaptırımlar: ceza değil “hizmet kredisi / fesih hakkı” mantığı

SLA yaptırımı iki şekilde akıllıca yazılır:

  • SLA ihlali belirli sayıda tekrar ederse hizmet bedelinde indirim/kredi
  • Kritik ihlallerde (P1’in sürekli aksamaması gibi) haklı fesih veya yönetim kuruluna ekstra haklar

Bu bölümün dengeli olması önemli: firma için uygulanabilir, site için koruyucu olmalı.

4) Arıza yönetiminde kayıt zorunluluğu

Sözleşmede şu netlikler olsun:

  • Her arıza kaydı bir numara alır (ticket)
  • Kapanış kriteri: servis formu + fotoğraf + tarih/saat
  • Aylık arıza raporu: adet, ortalama çözüm süresi, tekrar eden arızalar

Teknik operasyon ve bakım kurgusunu destekleyen iç link: Ankara Site Bakım ve Onarım Hizmetleri

5) “Planlı bakım SLA”yı unutmayın

Sadece arızaya koşmak yetmez. Sözleşmeye:

  • Periyodik bakım planı (aylık/3 aylık/6 aylık)
  • Kritik ekipman listesi (jeneratör, hidrofor, yangın sistemi vb.)
  • Uygunsuzlukların raporlanması ve aksiyon planı
    maddelerini ekleyin. Bu, uzun vadede hem maliyeti düşürür hem de arıza sayısını azaltır.

Fesih/devir süreci: dosya teslimi, borç-alacak kapatma

Sözleşme hazırlanırken en az konuşulan ama en çok problem çıkaran bölüm: fesih ve devir. Çünkü işler iyi giderken kimse “ayrılırsak ne olacak?” diye düşünmek istemez. Oysa profesyonel bir sözleşme, ayrılığı da medenî ve kontrollü hale getirir.

1) Fesih türleri ve ihbar süreleri net olmalı

  • Olağan fesih: kaç gün/ay önceden bildirim?
  • Haklı fesih: hangi durumlar haklı sayılır? (SLA ihlali, şeffaflık ihlali, belge paylaşmama vb.)
  • Fesihte son ödeme: hangi kalemler ödenir, hangi kalemler mahsuplaşır?

PMC Group tarafında “taahhüt/cayma bedeli bulunmaması” yaklaşımını sitenizde anlatan bölümlere iç link vermek isterseniz genel çerçeve için Hizmet Paketleri ve Ankara Profesyonel Site Yönetimi sayfaları uygun olur.

2) Devir teslim listesi: sözleşmeye ek yapın (Ek-2 Devir Dosyası)

Devir teslim “klasör verip çıkmak” değildir. İdeal devir dosyası şunları kapsar:

A) Mali dosya

  • Banka hesap bilgileri ve yetki durumları
  • Son 12 ay gelir-gider raporları
  • Borç-alacak listesi + yaşlandırma
  • Devam eden icra/hukuk süreç özeti (varsa)
  • Depozito/teminatlar

B) Sözleşmeler ve tedarikçiler

  • Aktif tedarikçi sözleşmeleri (bitiş tarihi, fesih şartları)
  • Bakım periyotları
  • Garanti belgeleri
  • İletişim listesi

C) Teknik dosya

  • Demirbaş envanteri
  • Periyodik bakım kayıtları
  • Arıza kayıt geçmişi ve kronik sorunlar listesi
  • Planlar/projeler (varsa)

D) Erişimler ve anahtarlar

  • Kartlar, kumandalar, pano anahtarları
  • Sistem şifreleri (kamera sistemi, bariyer, portal)
  • Yetkilendirme listesi (kimlerde hangi erişim var?)

3) Borç-alacak kapatma ve mutabakat (en kritik madde)

Fesihte en çok tartışılan konu: “Şu fatura kime ait?” Bu yüzden sözleşmede:

  • Kesim tarihi itibarıyla mutabakat yapılacağı
  • Fatura tarihine göre mi, hizmet dönemine göre mi ayrım yapılacağı
  • Devam eden işlerin (ör. bakım sözleşmesi) geçiş planı
    yazılmalı.

4) Geçiş desteği: 15–30 gün “devir destek süresi”

Özellikle büyük sitelerde, devir sonrası birkaç hafta:

  • yeni firmaya sistem anlatımı,
  • şifre/erişim aktarımı,
  • tedarikçi iletişim köprüsü
    gerekebilir. Bunu sözleşmede “ücretsiz/ücretli” net tanımlayın.

Veri güvenliği ve KVKK: erişimler, kayıtlar, saklama süreleri

2026’da site yönetimi; sadece aidat ve arıza yönetimi değildir. Aynı zamanda ciddi bir kişisel veri işidir: isim, telefon, araç plakası, ödeme bilgileri, kamera kayıtları, çağrı kayıtları, hatta bazı durumlarda sağlık/engellilik bilgisi gibi hassas veriler bile süreçlere girebilir. Bu nedenle sözleşmede KVKK ve bilgi güvenliği maddeleri “kopyala-yapıştır” olmamalı; işletilebilir olmalı.

Kat mülkiyeti ve süreç danışmanlığı tarafındaki çerçeveyi sitenizde desteklemek için: Ankara Site Kat Mülkiyeti Hizmeti

1) Rolleri tanımlayın: veri sorumlusu/işleyen kim?

Sözleşmede şu ayrım açık olmalı:

  • Site/apartman yönetimi (kurul) hangi rolde?
  • Yönetim firması hangi rolde?
  • Kullanılan yazılım/portal ve çağrı merkezi üçüncü tarafsa rolleri ne?

Bu, olası bir veri ihlali veya şikâyette sorumluluk karmaşasını azaltır.

2) Erişim yönetimi: “kim, hangi veriye, ne kadar süre erişir?”

Sözleşmeye yazılması gerekenler:

  • Rol bazlı erişim (muhasebe ayrı, saha ayrı)
  • Minimum yetki prensibi (herkese her şey yok)
  • Personel ayrılınca erişimin kapatılması için süre (ör. 24 saat)
  • Çok faktörlü doğrulama (mümkünse)
  • Yönetim kuruluna “görüntüleme” erişimi kurgusu

3) Kayıtlar (loglar) ve saklama süreleri

Şu başlıklar netleşmeli:

  • Banka hareketleri ve muhasebe kayıtları saklama yaklaşımı
  • Arıza kayıtları ve çağrı kayıtları saklama süresi
  • Kamera kayıtları saklama süresi (site politikasına göre)
  • Saklama bitince imha/silme prosedürü
  • Yedekleme ve geri yükleme politikası

4) Veri ihlali yönetimi: bildirim ve aksiyon planı

İyi bir sözleşme, “ihlalde ne yapılacağını” da yazar:

  • İhlal tespitinden sonra iç bildirim süresi
  • Etki analizi ve aksiyon planı
  • Üçüncü taraf kaynaklı ihlallerde koordinasyon
  • Kayıtların delil niteliğinde korunması

5) Üçüncü taraf tedarikçiler: en zayıf halka

Çağrı merkezi, yazılım sağlayıcı, güvenlik şirketi, kamera bakım firması gibi üçüncü taraflar varsa:

  • Yetkilendirme sınırı
  • Veri işleme amacı
  • Gizlilik yükümlülüğü
  • Alt tedarikçi kullanımı (onay şartı)
    maddeleri sözleşmede yer almalı.

2026’da iyi bir yönetim sözleşmesi “netlik + ölçülebilirlik + devir planı” demektir

Özetle; iyi bir site yönetim sözleşmesi 6 temel soruyu tartışmasız cevaplar:

  1. Kim neyi onaylar? (yetki ve temsil)
  2. Para nasıl harcanır? (limit ve satın alma)
  3. Her şey nasıl görünür olur? (şeffaflık ve raporlama)
  4. Hizmet nasıl ölçülür? (SLA ve yaptırımlar)
  5. Ayrılırsak ne olur? (devir dosyası ve mutabakat)
  6. Veri nasıl korunur? (KVKK ve güvenlik)

Eğer isterseniz, bir sonraki adım olarak:

  • elinizdeki mevcut sözleşme taslağını (kişisel/veri içermeyecek şekilde) buraya yapıştırın,
  • ben de bu 6 başlığa göre madde madde “eksik/riskli alanları” işaretleyip “daha net yazım önerileri” paylaşayım.

Teklif ve hizmet kapsamlarını görmek için:


Blog
Menü Görüntüle