Site Sakin İletişimi Nasıl Yönetilir? Kanal ve Kayıt Rehberi

Site sakin iletişimi, bütün sakinlere aynı mesajı göndermekten ibaret değildir. Etkili bir sistem; mesajın türünü ve hedef kitlesini belirler, uygun kanalı seçer, gönderim kaydını korur, geri dönüşleri doğru sürece yönlendirir ve iletişimi bir kapanış güncellemesiyle tamamlar. Böylece yönetim yalnızca ‘duyuru yaptım’ demez; kime, ne zaman, hangi içerikle ulaştığını ve sıradaki aksiyonun ne olduğunu gösterebilir.

Bu rehber; rutin duyurular, planlı çalışmalar, acil uyarılar ve bireysel sakin talepleri için uygulanabilir bir iletişim modeli sunar. Acil durum prosedürü, resmî tebligat yöntemi veya hukuki danışmanlık yerine geçmez. Can ve mal güvenliğini etkileyen olaylarda sitenin onaylı acil durum planı ve yetkili kurumların yönlendirmeleri esas alınmalıdır.

Site sakin iletişimi nasıl yönetilir?

İlk adım bir kanal seçmek değil, iletişim kaydının amacını tanımlamaktır. Aynı mobil bildirim altyapısı; bir bakım hatırlatmasını, yönetim kararını ve kişisel talep yanıtını taşıyabilir. Ancak bu üç mesajın hedef kitlesi, ayrıntı seviyesi, kayıt ihtiyacı ve kapanış ölçütü farklıdır.

Pratik bir iletişim kaydında en az şu alanlar bulunmalıdır:

• Mesaj türü ve amacı,
• Hedef kitle ile kapsam dışı bırakılan gruplar,
• İçerik sahibi ve yayın onayını veren kişi,
• Ana kanal ve gerekiyorsa yedek kanal,
• Gönderim zamanı ve içerik sürümü,
• Teslimat veya erişim sonucu,
• Geri dönüş yolu ve sorumlu ekip,
• Bir sonraki güncelleme ya da kapanış zamanı.

Liyova Duyurular, toplu iletişimi kanal seçimi, teslimat kayıtları ve sakin mobil bağlantısıyla aynı çalışma alanında yönetmeye yardımcı olur. Bu yapı, duyurunun yalnızca metnini değil; gönderim kapsamını ve sonrasındaki kontrol ihtiyacını da operasyonun parçası hâline getirir.

1. Mesajı türüne göre sınıflandırın

Her iletişimi ‘duyuru’ etiketi altında toplamak önceliklerin karışmasına yol açar. Sakinler her bildirimi acil zannedebilir veya gerçek bir uyarıyı rutin mesaj gibi geçebilir. Yönetim tarafında ise hangi kaydın yanıt, hangi kaydın saha aksiyonu gerektirdiği belirsizleşir.

Başlangıç için dört iletişim türü yeterlidir:

• Acil uyarı: Doğrulanmış bir risk veya kesinti hakkında kısa ve eyleme yönlendiren mesajdır. Güncelleme sıklığı ve yedek kanal acil durum planında tanımlanmalıdır.
• Planlı çalışma bildirimi: Bakım, geçici erişim değişikliği veya ortak alan çalışmasının tarihini, etkisini ve tamamlanma bilgisini taşır.
• Yönetim duyurusu: Etkinlik, karar, toplantı, genel bilgilendirme veya ortak yaşam düzeniyle ilgili kayıttır.
• Bireysel talep yanıtı: Belirli bir sakinin sorusu, arıza bildirimi veya şikâyetiyle bağlantılı konuşma geçmişidir; toplu duyuru olarak yayımlanmamalıdır.

Mesaj türü, yalnızca konu başlığı değildir. Onaylayan kişiyi, hedef kitleyi, kanal seçimini ve kayıt süresini de etkileyen bir yönlendirme alanıdır. Örneğin planlı bir çalışma için başlangıç bildirimi yeterli olmayabilir; gecikme varsa ara güncelleme, çalışma bittiğinde de kapanış mesajı gerekir.

2. Hedef kitleyi gönderimden önce belirleyin

‘Tüm sakinler’ kolay bir seçim gibi görünse de çoğu mesaj daha dar bir grubu ilgilendirir. B bloktaki asansör bakımı için diğer bloklara tekrar tekrar bildirim göndermek, zamanla bildirim yorgunluğu yaratabilir. Tersine, maliklere yönelik bir yönetim bilgisinin yalnızca o anda dairede yaşayan kiracılara gitmesi de bilgi açığı doğurabilir.

Hedef kitleyi şu alanlarla tanımlayın:

• Site, blok, kat, ortak alan veya bağımsız bölüm kapsamı,
• Malik, kiracı, yönetim kurulu, personel veya dış servis rolü,
• Çalışmadan doğrudan etkilenen ve yalnızca bilgilendirilecek gruplar,
• Mobil kanala erişemeyenler için alternatif iletişim listesi,
• Güncelliği kontrol edilmiş iletişim bilgileri.

Hedefleme, kişisel ayrıntıları daha fazla kişiye açmak için değil, mesajı gerçekten ilgili kişilere sınırlamak için kullanılmalıdır. Bireysel bakiye, şikâyet içeriği, telefon numarası veya daire içi fotoğraf gibi bilgiler geniş duyuru metnine taşınmamalıdır. Aidat operasyonundaki karar, cari kayıt ve tahsilat bağlamını ayrı tutmak için site aidat takibi rehberindeki kayıt modelinden yararlanabilirsiniz.

3. Kanalı mesajın amacına göre seçin

Tek bir kanal bütün iletişim ihtiyaçlarını karşılamaz. Kanal seçerken hız, erişilebilirlik, içerik uzunluğu, hedef kitlenin erişimi, kayıt ihtiyacı ve yedekleme imkânı birlikte değerlendirilmelidir. Bir uygulama bildirimi kısa uyarıyı taşıyabilir; ayrıntılı açıklama aynı duyurunun gövdesinde veya bağlantılı belgede yer alabilir. Fiziksel pano ise dijital kanala erişemeyenler için destekleyici olabilir, ancak kişisel bilgi içermemelidir.

İletişim ihtiyacı	Ana kayıt	Kanal seçimi	Kapanış ölçütü
Acil uyarı	Doğrulanmış durum, kapsam ve zaman	Acil durum planındaki ana ve yedek kanallar	Güncelleme ve normale dönüş mesajı
Planlı çalışma	Tarih, etkilenen alan, beklenen süre	Uygulama duyurusu; ihtiyaca göre e-posta veya pano desteği	Başladı, değişti veya tamamlandı bilgisi
Genel yönetim duyurusu	Konu, dayanak, yayınlayan ve sürüm	Duyuru kaydı ve mobil okuma kanalı	Sorular için belirtilmiş geri dönüş yolu
Bireysel talep	Talep sahibi, konu ve konuşma geçmişi	Yetkili kişilerin eriştiği talep kanalı	Yanıt, aksiyon ve talep sahibinin bilgilendirilmesi

Liyova Sakin Mobil Uygulaması, sakinlerin duyuru okuma, talep oluşturma, borç görüntüleme ve ziyaretçi akışlarına aynı mobil deneyimden erişmesini sağlar. Bununla birlikte iletişim tasarımının başarısı yalnızca uygulamanın bulunmasına değil, her mesajın doğru kayıt ve geri dönüş yoluyla yayımlanmasına bağlıdır.

4. Duyuru metnini beş zorunlu öğeyle yazın

İyi bir site duyurusu uzun olmak zorunda değildir; eksik bırakılmaması gerekir. Metni yayımlamadan önce şu beş soruya cevap verin:

1. Ne oluyor? Konuyu ilk cümlede açıkça söyleyin.
2. Kim etkileniyor? Blok, alan veya kullanıcı grubunu belirtin.
3. Ne zaman? Başlangıç, beklenen bitiş ve gerekiyorsa güncelleme zamanını yazın.
4. Sakinden ne bekleniyor? Yapılması veya kaçınılması gereken eylemi sade biçimde belirtin.
5. Sonraki bilgi nereden gelecek? Güncelleme kanalı ile geri dönüş yolunu tanımlayın.

Örneğin ‘Bakım yapılacaktır’ yerine şu yapı daha işlevseldir: ‘A Blok giriş kapısında 6 Ağustos Çarşamba 10.00–12.00 arasında planlı bakım yapılacaktır. Bu sürede yan giriş kullanılacaktır. Çalışma tamamlandığında aynı duyuru kaydı güncellenecektir. Erişim sorunu yaşayan sakinler mobil uygulamadaki talep alanından yönetime ulaşabilir.’ Somut tarih, kapsam, eylem ve sonraki güncelleme aynı metinde görünür.

Kopyalanabilir bakım, kesinti, otopark, ara güncelleme ve kapanış metinlerini görmek için site duyurusu örnekleri ve yayın kontrol listesini kullanabilirsiniz.

Başlık ile gövde aynı aciliyet seviyesini taşımalı

Başlığa ‘Acil’ yazıp gövdede rutin bir hatırlatma vermek, uyarı seviyesini aşındırır. Tersine, gerçek bir risk bilgisini genel bir başlığın içine saklamak da mesajın fark edilmesini zorlaştırır. Başlık; konu, yer ve gerekirse zaman bilgisini kısa biçimde taşımalıdır.

5. Teslim edildi, okundu ve anlaşıldı kavramlarını ayırın

Gönderim kaydı iletişimin başlangıcıdır; sonucu değildir. Bir kanal mesajın teknik olarak teslim edildiğini gösterebilir, ancak bu durum mesajın okunduğunu veya sakinin gereken eylemi anladığını tek başına kanıtlamaz. Bu nedenle ölçümü dört ayrı düzeyde ele alın:

• Yayınlandı: Onaylı içerik belirlenen kitleye gönderildi.
• Teslim edildi: Kanal teknik teslim sonucunu döndürdü.
• Erişildi veya okundu: Kanal bu bilgiyi güvenilir biçimde sunuyorsa ayrı kaydedildi.
• Aksiyon tamamlandı: Sakin gerekli formu doldurdu, teyit verdi veya talep açtı.

Her duyuruda okuma onayı istemek gerekmez. Rutin bilgilendirmede yayın ve teslimat sonucu yeterli olabilir. Kritik bir erişim değişikliği ya da belirli bir gruptan işlem beklenen durumda ise erişilemeyen kişiler için istisna listesi oluşturmak ve alternatif kanal kullanmak gerekir.

6. Geri dönüşleri duyuru yorumlarında kaybetmeyin

Toplu mesaj, ortak bilgiyi dağıtmak içindir. Sakinlerden gelen kişisel sorular, arıza bildirimleri ve şikâyetler ise sahip, öncelik ve durum geçmişi gerektirir. Bu nedenle duyuruda ‘yanıt için yönetimi arayın’ gibi sınırsız bir çağrı yerine, hangi konunun hangi talep kanalına iletileceğini belirtin.

Liyova Talep Yönetimi, geri dönüşleri kategori, öncelik, durum, konuşma geçmişi ve görsel kayıtlarla izlemeye yardımcı olur. Saha işi gereken bildirimlerin nasıl iş emrine dönüştürüleceğini ve doğrulanmış kapanışla tamamlanacağını site arıza ve iş emri yönetimi rehberinde ayrıntılı olarak inceleyebilirsiniz.

Bir duyurudan çok sayıda benzer soru geliyorsa aynı cevabı tek tek yazmak yerine ana duyuruyu güncelleyin veya kısa bir soru-cevap bölümü ekleyin. Kişiye özel durumları ise toplu metinde paylaşmadan ilgili talep kaydında çözün.

7. İletişim verisini amaçla sınırlı tutun

Ağustos 2026 itibarıyla Kişisel Verileri Koruma Kurumunun kişisel verilerin işlenme şartlarına ilişkin açıklaması, hukuki dayanakların Kanunda sınırlı sayıldığını ve her işleme faaliyetinin somut dayanağının ayrıca değerlendirilmesi gerektiğini belirtiyor. Kurumun genel ilkeleri; verinin doğru ve gerektiğinde güncel, belirli ve meşru amaçlarla bağlantılı, sınırlı ve ölçülü işlenmesini ve gerekli süre kadar saklanmasını öngörüyor.

Bu ilkeleri iletişim operasyonuna şu kontrollerle uyarlayın:

• İletişim listesine yalnızca amaç için gereken bilgileri alın.
• Taşınan sakinleri ve değişen iletişim bilgilerini belirli bir süreçle güncelleyin.
• Toplu gönderimde alıcıların birbirinin iletişim bilgisini görmesini önleyin.
• Malik, kiracı, personel ve dış servis erişimlerini görev kapsamına göre ayırın.
• Eski listelerin kişisel cihazlarda ve farklı dosya kopyalarında dolaşmasını engelleyin.
• Saklama ve silme uygulamasını yönetimin veri işleme envanteriyle uyumlu yürütün.

Bu bölüm genel bir operasyon çerçevesidir; belirli bir iletişim faaliyetinin hukuki dayanağı, aydınlatma yükümlülüğü, resmî tebligat niteliği veya saklama süresi için somut olaya göre hukuk ve veri koruma uzmanı görüşü alınmalıdır.

8. Dijital kanala erişemeyenler için yedek plan kurun

İletişim sisteminin kapsamı yalnızca uygulamayı aktif kullanan kişilerden oluşmamalıdır. Akıllı telefonu olmayan, bildirim izni kapalı bulunan, görme veya işitme desteğine ihtiyaç duyan ya da geçici olarak çevrimdışı kalan sakinler için alternatif plan tanımlayın.

Yedek plan; fiziksel pano, telefon zinciri, kat görevlisi, e-posta veya site yapısına uygun başka bir kanaldan oluşabilir. Buradaki amaç her mesajı bütün kanallardan tekrar göndermek değil, ana kanaldan erişilemeyen kişileri belirleyip gerekli kapsamda tamamlayıcı iletişim kurmaktır. Acil durumlarda yedek kanal seçimi bu genel rehbere göre değil, sitenin onaylı acil durum planına göre yapılmalıdır.

9. Hazırlama, onay, yayın, izleme ve kapanış rollerini ayırın

Küçük bir apartmanda bu rollerin tamamını aynı yönetici üstlenebilir; büyük bir sitede farklı ekipler çalışabilir. Her iki durumda da sorumlulukların adlandırılması hata ve gecikmeyi azaltır:

1. Hazırlayan: Konuyu, hedef kitleyi, zamanı ve beklenen eylemi toplar.
2. Onaylayan: İçeriğin doğruluğunu, kapsamını ve uygun kanalını kontrol eder.
3. Yayınlayan: Onaylı sürümü belirlenen zamanda gönderir.
4. İzleyen: Teslimat hatalarını, tekrar eden soruları ve açılan talepleri takip eder.
5. Kapatan: Sonuç bilgisini paylaşır, kaydı arşivler ve gerekli iyileştirme notunu ekler.

Özellikle değişen çalışma saatleri veya ertelenen bakım gibi durumlarda eski mesajın sessizce değiştirilmesi yerine yeni sürümün zamanı ve değişen bilgi görünür olmalıdır. Sakin hangi bilginin güncel olduğunu tek kayıtta anlayabilmelidir.

10. İletişim performansını doğru sorularla ölçün

Yalnızca gönderilen mesaj sayısını artırmak iyi iletişim anlamına gelmez. Aylık değerlendirmede şu sorular daha işlevseldir:

• Kaç duyuru doğru hedef kitleyle eşleşti?
• Hangi kanallarda teslimat hatası veya güncel olmayan iletişim bilgisi görüldü?
• Hangi duyurular aynı sorunun tekrar tekrar sorulmasına yol açtı?
• Kaç geri dönüş tanımlı talep kanalına aktarıldı ve sorumlusu belirlendi?
• Planlı çalışma ve kesintilerde kapanış güncellemesi yapıldı mı?
• Dijital kanala erişemeyen kişiler için yedek plan çalıştı mı?

Bu soruların amacı sakin davranışını puanlamak değil, iletişim sistemindeki eksik alanları bulmaktır. Teslimat hatası eski telefon numarasından, fazla soru belirsiz metinden, geciken yanıt ise sahipliği tanımlanmamış talepten kaynaklanabilir.

Sık yapılan sakin iletişimi hataları

• Her mesajı herkese göndermek: İlgisiz bildirimler zamanla dikkati azaltır.
• Duyuruyu kapanış mesajı olmadan bırakmak: Sakinler çalışmanın bitip bitmediğini anlayamaz.
• Teslimatı okunma sanmak: Teknik gönderim sonucu ile kullanıcı eylemi karıştırılır.
• Kişisel ayrıntıyı toplu kanala taşımak: Gereksiz erişim ve gizlilik riski oluşur.
• Geri dönüş yolunu belirtmemek: Aynı konu telefon, mesaj ve yüz yüze kanallara dağılır.
• Eski sakin listesini kullanmak: Mesaj yanlış kişiye gider veya yeni sakin atlanır.
• Her bildirimi acil işaretlemek: Gerçek uyarılar rutin mesajların arasında kaybolabilir.

Bir bakım duyurusunu uçtan uca örnekleyin

Ortak alan girişinde planlı bir çalışma yapılacağını varsayalım. Yönetim önce çalışmanın doğrulanmış tarihini, etkilenen alanı, kullanılacak alternatif girişi ve sorumlu kişiyi kaydeder. Hedef kitleyi yalnızca ilgili blok olarak belirler. Duyuruyu mobil kanalda yayımlar; dijital kanala erişemeyenler için bina panosunda kişisel veri içermeyen kısa bir destek mesajı kullanır.

Çalışma başladığında kayıt ‘başladı’ bilgisiyle güncellenir. Beklenmeyen bir gecikme varsa yeni bitiş zamanı ve nedeni aynı kayıt üzerinden paylaşılır. Tamamlandığında kapanış mesajı yayımlanır; erişim sorunu bildiren kişilerin geri dönüşleri talep kaydına yönlendirilir. Böylece tek bir duyuru, hazırlık–onay–gönderim–izleme–kapanış zincirine dönüşür.

Sakin iletişimi yazılımını gerçek senaryoyla değerlendirin

Bir ürün demosunda yalnızca ‘duyuru gönder’ düğmesini görmek yeterli değildir. A blok için planlı çalışma kaydı açın, malik ve kiracı kapsamını kontrol edin, mobil duyuruyu yayımlayın, teslimat sonucunu inceleyin, bir sakinin sorusunu talebe dönüştürün ve kapanış güncellemesi yapın. Ardından bütün adımların aynı geçmişte görünür olup olmadığını kontrol edin.

Finans, operasyon, sakin deneyimi, raporlama ve yetkilendirmeyi birlikte sınamak için site yönetim programı seçme rehberindeki demo kontrol listesini kullanabilirsiniz.

Site sakin iletişimi hakkında sık sorulan sorular

WhatsApp grubu site iletişimi için yeterli midir?

Mesajlaşma grubu hızlı bir yardımcı kanal olabilir; ancak hedef kitle, yetki, sürüm, teslimat, talep sahipliği ve arşiv ihtiyacı büyüdükçe tek kayıt noktası olarak yetersiz kalabilir. Resmî ve operasyonel ana kayıt ayrı bir yönetim sisteminde korunmalı, yardımcı kanallar bu kayda yönlendirmelidir.

Mobil bildirim gönderilmesi mesajın okunduğunu gösterir mi?

Her zaman göstermez. Teknik teslim, uygulama açılışı, okuma bilgisi ve beklenen eylemin tamamlanması farklı sonuçlardır. Kullanılan kanal hangi veriyi güvenilir biçimde sunuyorsa yalnızca o düzey raporlanmalıdır.

Bireysel bir sakin sorunu duyuru olarak paylaşılabilir mi?

Kişisel ayrıntı içeren sorunlar toplu duyuruya taşınmamalıdır. Ortak alanı etkileyen genel durum ayrı ve anonim bir duyuruyla paylaşılabilir; kişinin talebi ve yanıt geçmişi ise yalnızca yetkili kişilerin eriştiği talep kaydında tutulmalıdır.

Site duyuruları ne sıklıkla gönderilmeli?

Sabit bir sayı yerine mesajın gerekliliği ve hedef kitlesi esas alınmalıdır. Rutin konular bir özet içinde birleştirilebilir; planlı çalışma ve değişiklikler ihtiyaç anında, acil uyarılar ise sitenin acil durum planına göre gönderilmelidir.

Mobil uygulama kullanmayan sakinler nasıl bilgilendirilmeli?

Yönetim alternatif iletişim listesini önceden belirlemeli ve ana kanaldan erişilemeyen kişiler için uygun yedek yöntemi çalıştırmalıdır. Fiziksel veya kişisel destek kanallarında gereksiz kişisel veri paylaşılmamalıdır.

İletişimi gönderimden kapanışa kadar yönetin

Liyova ile duyuruları doğru kitle ve kanal bağlamında yönetebilir, teslimat kayıtlarını izleyebilir, sakinlerin mobil deneyimini ortak sisteme bağlayabilir ve bireysel geri dönüşleri talep akışına aktarabilirsiniz. Kendi sitenizdeki iletişim modelini gerçek bir senaryoyla değerlendirmek için demo talebi oluşturun.