Liyova

Blog

  • Sakin Talebinden İş Emrine: Site Arıza Yönetimi Akışı

    Sakin Talebinden İş Emrine: Site Arıza Yönetimi Akışı

    Site arıza talep yönetimi, bir sakinin bildirimini yalnızca mesaj olarak saklamak değil; talebi sınıflandırılmış, sorumlusu belirlenmiş, sahada uygulanabilir ve sonucu doğrulanabilir bir iş akışına dönüştürmektir. Sağlıklı süreçte talep ile iş emri ayrı kayıtlardır: Talep ihtiyacı ve bağlamı anlatır; iş emri ise kimin, nerede, hangi kapsamda ve hangi kapanış ölçütüyle çalışacağını belirler.

    Bu rehber, ortak alan arızaları ve operasyon talepleri için uygulanabilir bir yönetim modeli sunar. Teknik teşhis, iş güvenliği talimatı veya acil durum prosedürü yerine geçmez. Can ve mal güvenliğini etkileyen durumlar standart talep kuyruğunda bekletilmemeli; sitenin acil durum planı ve yetkili servis kanalı kullanılmalıdır.

    Site arıza talep yönetimi nedir?

    Arıza talep yönetimi; bildirimin alındığı andan çözüme ilişkin kaydın kapatılmasına kadar geçen sürecin tek bir iz üzerinde yönetilmesidir. Bu iz üzerinde en az talebin kaynağı, konumu, kategorisi, önceliği, sorumlusu, durum geçmişi, yapılan işlem, kontrol sonucu ve kapanış zamanı görünmelidir.

    Liyova Talep Yönetimi, sakinlerden gelen talepleri kategori, öncelik, durum, konuşma geçmişi ve görsel kayıtlarla ortak bir çalışma alanında izlemeye yardımcı olur. Saha çalışması gereken kayıtlar iş emrine dönüştürülebilir; yalnızca bilgi veya yönetim yanıtı gerektiren talepler ise gereksiz teknik görev üretmeden kendi akışında sonuçlandırılabilir.

    Talep ile iş emri arasındaki farkı baştan belirleyin

    Talep ile iş emrini aynı kayıt gibi kullanmak iki soruna yol açar. Birincisi, her sakin mesajı teknik görev olarak algılanır ve ekip kuyruğu gereksiz kayıtlarla dolar. İkincisi, sahaya aktarılması gereken gerçek işlerde görev kapsamı, sorumlu ve kapanış ölçütü belirsiz kalır. Sahip, girdi, çıktı, durum ve kapanış ölçütlerini yan yana değerlendirmek için talep ile iş emri arasındaki fark rehberini kullanabilirsiniz.

    Alan Talep kaydı İş emri
    Amaç İhtiyacı, sorunu veya bildirimi kaydetmek Yapılacak saha işini tanımlamak ve yürütmek
    Sahibi Talebi karşılayan yönetim veya destek sorumlusu Atanan personel, ekip ya da dış servis
    Temel bilgi Konum, açıklama, kategori, etki ve görsel Kapsam, sorumlu, hedef zaman, uygulama ve kontrol
    Kapanış Talep sahibine sonuç bildirildiğinde ve kayıt doğrulandığında Tanımlanan iş tamamlanıp kanıt ve kontrol sonucu işlendiğinde

    Örneğin “havuz kullanım saatleri nedir?” sorusu bir bilgi talebidir ve iş emri gerektirmez. “B blok girişindeki sensörlü aydınlatma çalışmıyor” bildirimi ise konum, etki ve teknik müdahale ihtiyacı doğrulandıktan sonra iş emrine dönüşebilir.

    1. Arıza bildirimini standart alanlarla alın

    Sözlü bildirim, telefon notu ve mesajlaşma grubu ilk temas için kullanılabilir; ancak nihai kayıt tek bir ana sisteme aktarılmadığında hangi sürümün güncel olduğu belirsizleşir. Her talepte şu bilgiler bulunmalıdır:

    • Blok, kat, ortak alan veya ekipman gibi açık konum bilgisi,
    • Gözlenen sorun ve ne zamandır sürdüğüne ilişkin kısa açıklama,
    • Teknik arıza, temizlik, güvenlik, peyzaj veya idari talep gibi kategori,
    • Kaç kişi veya alanın etkilendiği,
    • Durumu açıklayan, gereksiz kişisel veri içermeyen görsel veya belge,
    • Geri dönüş yapılacak kanal ve erişim için gerekli operasyon notu.

    Talep formu kullanıcıdan teknik teşhis istememelidir. “Motor kondansatörü arızalı” demek yerine “otopark kapısı açılırken duruyor ve ses çıkarıyor” gibi gözlenebilir durumu kaydetmek, teknik ekibin ön yargısız inceleme yapmasını kolaylaştırır. Fotoğrafta yüz, daire içi veya özel belge gibi gereksiz kişisel verilerin görünmemesine dikkat edilmelidir.

    Aynı sorun için gelen tekrar bildirimleri birleştirin

    Bir su kesintisi için on farklı talep açıldığında on ayrı iş emri üretmek yerine, ana kaydı belirleyip diğer bildirimleri bu kayda bağlayın. Böylece etkilenen kişi sayısı görünür kalır; ekip aynı işi tekrar tekrar incelemez. İletişim güncellemeleri de ana kayıt üzerinden tutarlı biçimde paylaşılabilir. Ortak duyuru ile kişisel talep yanıtını doğru hedef kitle, kanal ve kayıtla ayırmak için site sakin iletişimi rehberine bakabilirsiniz.

    2. Önceliği yalnızca “acil” etiketine bırakmayın

    Öncelik, talebi yazan kişinin seçtiği bir sıfat değil; etki ve aciliyetin birlikte değerlendirildiği yönetim kararıdır. Her site kendi yapısına uygun bir matris tanımlamalıdır. Aşağıdaki örnek evrensel süre taahhüdü değil, sınıflandırma başlangıcıdır:

    • Kritik: Can veya mal güvenliği riski ya da temel hizmette ciddi kesinti şüphesi vardır. Standart kuyruk yerine acil prosedür çalıştırılır.
    • Yüksek: Birden fazla bağımsız bölüm veya ortak alanın kullanımı belirgin biçimde etkilenir.
    • Normal: Sorun sınırlı bir alanı etkiler; geçici kullanım veya alternatif mümkündür.
    • Düşük: Kozmetik iyileştirme, öneri veya planlı değerlendirme niteliğindedir.

    Önceliğin yanında hedeflenen ilk değerlendirme zamanı ve gecikme halinde kime aktarılacağı da tanımlanmalıdır. Sabit bir süreyi bütün talep türlerine uygulamak yerine kategori, risk, erişim ve dış servis bağımlılığı birlikte değerlendirilmelidir.

    3. Talebi inceleyin ve doğru sonraki aksiyona yönlendirin

    Her yeni kayıt kısa bir ön incelemeden geçmelidir. Bu aşamada talebin kapsamı netleştirilir ve aşağıdaki yollardan biri seçilir:

    1. Bilgi veya idari yanıt: Saha işi gerektirmeyen talep yönetim tarafından yanıtlanır.
    2. Mükerrer kayıt: Mevcut ana taleple ilişkilendirilir.
    3. Kapsam dışı veya başka sorumlu: Gerekçesi ve doğru başvuru kanalı kayda eklenir.
    4. Teknik inceleme gerekli: Saha kontrolü için iş emri oluşturulur.
    5. Planlı iş: Acil olmayan ancak bakım takvimine alınması gereken kayıt uygun döneme planlanır.

    Bu ayrım “reddedildi” gibi açıklamasız bir durumdan daha değerlidir. Talep sahibinin ne olacağını anlayabilmesi için seçilen yol, gerekçe ve bir sonraki kontrol tarihi görünür olmalıdır.

    4. İş emrini sahada uygulanabilir hale getirin

    İş emri, talep metninin kopyası değildir. Atanan kişinin ek görüşme yapmadan nerede başlayacağını ve işin ne zaman tamamlanmış sayılacağını anlayabileceği kadar açık olmalıdır. İyi bir iş emrinde şu alanlar bulunur:

    • Sorumlu personel, ekip veya dış servis,
    • İşin konumu ve kapsam sınırı,
    • Öncelik ile hedef ilk işlem zamanı,
    • Erişim, güvenlik veya eşlik gereksinimi,
    • Beklenen uygulama notu ve kontrol yöntemi,
    • Dış servis, malzeme veya onay gibi bağımlılıklar,
    • İşin kapanması için gerekli kanıt.

    Liyova İş Emirleri, talep veya planlı bakım kaynaklı işleri personele atama, durumla takip etme ve operasyon raporuna taşıma akışı sunar. Talep kaydının iş emriyle bağlantısı korunursa yönetim, sakinin bildirdiği ihtiyaç ile sahada yapılan işi aynı bağlamda inceleyebilir.

    5. Beklemeyi görünür bir durum olarak yönetin

    Bir işin aktif olarak yürütülmesi ile parça, dış servis, erişim veya onay beklemesi aynı durum değildir. “İşlemde” etiketi haftalarca değişmeden kalırsa kuyruk gerçeği yansıtmaz. Bekleyen kayıtta en az bekleme nedeni, sorumlu taraf, beklenen tarih ve yeniden kontrol zamanı bulunmalıdır.

    Örnek bir durum modeli şöyle kurulabilir:

    Durum Anlamı Zorunlu sonraki bilgi
    Yeni Kayıt alındı, henüz incelenmedi İnceleme sorumlusu
    İncelemede Kategori, kapsam ve öncelik değerlendiriliyor Karar veya ek bilgi isteği
    Atandı Sorumlu belirlendi Hedef başlangıç zamanı
    Çalışılıyor Sahada aktif işlem var Son işlem notu
    Beklemede Bir bağımlılık nedeniyle ilerleyemiyor Neden ve yeniden kontrol tarihi
    Doğrulamada Uygulama bitti, sonuç kontrol ediliyor Kontrol sonucu
    Kapalı Kapanış ölçütleri karşılandı Sonuç kodu ve bildirim kaydı

    6. Müdahale notunu ve kapanış kanıtını kaydedin

    “Yapıldı” veya “çözüldü” tek başına yeterli bir kapanış kaydı değildir. Müdahale notunda gözlenen durum, uygulanan işlem, kullanılan malzeme veya dış servis bilgisi, başlangıç ve bitiş zamanı ile varsa sonraki bakım önerisi bulunmalıdır. Kanıt, işin niteliğine göre fotoğraf, test sonucu, kontrol listesi veya yönetici doğrulaması olabilir.

    Kapanıştan önce şu dört soruyu yanıtlayın:

    1. İş emrinde tanımlanan kapsam tamamlandı mı?
    2. Sonuç güvenli ve uygun yöntemle kontrol edildi mi?
    3. Talep kaydı ile iş emri aynı sonuç bilgisini gösteriyor mu?
    4. Talep sahibine veya ilgili gruba anlaşılır bir durum güncellemesi yapıldı mı?

    Kontrol başarısızsa kaydı kapatıp yeni bir talep açmak yerine iş emrini yeniden çalışmaya almak, sorunun geçmişini korur. Farklı bir kök neden ortaya çıktıysa bağlantılı yeni iş emri oluşturulabilir.

    Sakin talebinden kapanışa site arıza ve iş emri kontrol akışı
    Talep, öncelik ve atamadan sonra iş emrine dönüşür; kapanış ise uygulama kanıtı ve kontrol sonucu birlikte kaydedildiğinde tamamlanır.

    Arıza yönetiminde rol ve sorumlulukları ayırın

    Küçük bir apartmanda aynı kişi birkaç rolü üstlenebilir; büyük bir sitede görevler farklı ekiplerde olabilir. Ölçek ne olursa olsun her adımın sahibi görünür olmalıdır.

    • Sakin veya bildirimi yapan kişi: Gözlenebilir sorunu, konumu ve gerekli bağlamı iletir.
    • Talep sorumlusu: Kaydı temizler, mükerrerleri birleştirir ve eksik bilgiyi tamamlar.
    • Yönetici veya operasyon sorumlusu: Öncelik verir, kapsamı belirler ve iş emrini atar.
    • Personel veya dış servis: Uygulamayı, süreyi ve sonucu kaydeder.
    • Kontrol sorumlusu: Kapanış ölçütünü doğrular ve gerekli bildirimi tamamlar.

    Aynı kişinin hem uygulayıcı hem kontrol eden olması küçük yapılarda kaçınılmaz olabilir. Bu durumda kapanış notu, zaman ve kanıt alanlarının eksiksiz tutulması sonradan inceleme yapılabilmesini sağlar.

    Raporlarda yalnızca kapanan iş sayısına bakmayın

    Yüksek kapanış sayısı tek başına iyi operasyon anlamına gelmez. Yeniden açılan işler, uzun süre bekleyen kayıtlar veya aynı kategori ve konumda tekrarlayan arızalar görünmüyorsa sorun yalnızca raporun dışına taşınmış olabilir. Yönetim görünümünde şu sorulara yanıt arayın:

    • Önceliğe göre kaç açık talep ve iş emri var?
    • Hangi kayıtlar dış servis, malzeme, erişim veya onay bekliyor?
    • En uzun süredir açık kayıtların sonraki aksiyonu belli mi?
    • Kaç iş doğrulama sonrası yeniden açıldı?
    • Aynı konum veya kategoride tekrar eden arıza var mı?
    • Talep ile iş emri arasında sahipsiz kalan kayıt bulunuyor mu?

    Liyova Raporlar, talep ve iş emri verisini finans ve diğer yönetim verileriyle ortak bir raporlama standardına yaklaştırır. Raporlamanın amacı yalnızca ay sonu sayısı üretmek değil, bekleyen işin nedenini ve alınacak sonraki kararı görünür kılmaktır.

    Sorumlu, kontrol noktası, kanıt ve sonraki adım yaklaşımı farklı yönetim süreçlerinde de kullanılabilir. Finans operasyonu için aynı çerçevenin uygulamasını site aidat takibi rehberinde inceleyebilirsiniz.

    Sık yapılan arıza ve talep yönetimi hataları

    • Her bildirimi iş emrine çevirmek: Bilgi talepleri teknik kuyruğu gereksiz yere büyütür.
    • Önceliği açıklamasız vermek: Benzer talepler arasında tutarsızlık oluşur.
    • Sorumluyu ekip adıyla bırakmak: Kaydın gerçek sahibi belirsiz kalır.
    • Bekleme nedenini kaydetmemek: Gecikme ile aktif çalışma birbirine karışır.
    • Kanıtsız kapatmak: Yapılan iş ve kontrol sonucu sonradan açıklanamaz.
    • Mükerrer talepleri ayrı ayrı yürütmek: Ekip aynı soruna birden fazla kez atanabilir.
    • Talep sahibine sonuç bildirmemek: Teknik iş bitse bile kullanıcı açısından süreç açık kalır.

    Arıza yönetimi yazılımını gerçek senaryoyla değerlendirin

    Bir ürünü değerlendirirken yalnızca “talep modülü var mı?” sorusu yeterli değildir. Demoda aynı sorun için mükerrer iki bildirim açın, önceliği değiştirin, birini iş emrine dönüştürün, sorumlu atayın, bekleme nedeni ekleyin, uygulama kanıtı girin ve sonucu doğrulayarak kapatın. Ardından talep ile iş emri geçmişinin ve raporun aynı sonucu gösterip göstermediğini kontrol edin.

    Finans, operasyon, sakin deneyimi, raporlama ve yetkilendirmeyi birlikte değerlendirmenize yardımcı olacak daha geniş kontrol listesi için site yönetim programı seçme rehberini kullanabilirsiniz.

    Site arıza talep yönetimi hakkında sık sorulan sorular

    Her sakin talebi iş emrine dönüşmeli mi?

    Hayır. Bilgi isteği, öneri, mükerrer bildirim veya başka bir sorumluluk alanına ait kayıt doğrudan teknik iş emri olmamalıdır. Saha uygulaması gereken ve kapsamı doğrulanan talepler iş emrine dönüştürülmelidir.

    İş emrini kim kapatmalı?

    Uygulamayı yapan kişi işi tamamlandı olarak işaretleyebilir; nihai kapanış yetkisi ise sitenin kontrol modeline göre belirlenmelidir. Önemli olan uygulama notu, kontrol sonucu, kanıt ve bildirim kaydının kapanıştan önce tamamlanmasıdır.

    Dış servis veya malzeme bekleyen iş nasıl izlenir?

    Kayıt “beklemede” durumuna alınmalı; bekleme nedeni, sorumlu taraf, beklenen tarih ve yeniden kontrol zamanı yazılmalıdır. Böylece aktif çalışma süresi ile dış bağımlılık nedeniyle geçen süre birbirinden ayrılır.

    Tekrarlayan arızalar nasıl fark edilir?

    Kategori, konum, ekipman ve sonuç kodları tutarlı kullanılırsa aynı alan veya ekipmandaki tekrarlar raporda gruplanabilir. Sadece serbest metinle kayıt tutulması, benzer sorunların farklı adlarla dağılmasına yol açar.

    Arıza kaydında fotoğraf zorunlu mu?

    Her talep için zorunlu değildir. Görsel, konumu veya sorunu açıklamaya gerçekten yardımcı olduğunda istenmelidir. Gereksiz kişisel veri, özel alan veya güvenlik bilgisi içeren görüntüler kayda eklenmemelidir.

    Talebi kapanışa kadar tek bağlamda yönetin

    Liyova ile sakin talebini kategori ve öncelikle kaydedebilir, saha işi gerektiğinde iş emrine dönüştürebilir, atama ve durum adımlarını izleyebilir ve operasyon sonucunu raporlayabilirsiniz. Kendi sitenizdeki arıza akışını birlikte değerlendirmek için demo talebi oluşturun.

  • Site Yönetiminde Aidat Takibi Nasıl Yapılır? Uçtan Uca Rehber

    Site Yönetiminde Aidat Takibi Nasıl Yapılır? Uçtan Uca Rehber

    Site aidat takibi, yalnızca kimin ödeme yaptığını gösteren bir çizelge tutmak değildir. Sağlıklı bir süreç; dayanak kararın kayda alınması, borcun doğru döneme tahakkuk ettirilmesi, tahsilatın belge ve referansıyla işlenmesi, banka hareketiyle eşleştirilmesi ve açık bakiyenin düzenli raporlanması adımlarından oluşur. En pratik yöntem, her adım için bir sorumlu, kontrol noktası, kanıt ve sonraki aksiyon tanımlamaktır.

    Bu rehber, apartman ve site yöneticilerinin aidat sürecini uçtan uca kurmasına yardımcı olan operasyonel bir çerçeve sunar. Hukuki veya mali danışmanlık yerine geçmez; yönetim planı, kurul kararları ve somut uyuşmazlıklar için güncel mevzuatın ve gerektiğinde uzman görüşünün ayrıca değerlendirilmesi gerekir.

    Site aidat takibi hangi adımları kapsar?

    İyi tasarlanmış bir aidat takip sistemi beş bağlantılı halkadan oluşur:

    1. Karar ve plan: Gider bütçesi, dönem, dağıtım yöntemi, tutar ve son ödeme tarihi belirlenir.
    2. Tahakkuk: Ödenecek tutar doğru bağımsız bölüm, kişi veya cari hesapla ilişkilendirilir.
    3. Tahsilat: Ödeme tarihi, kanalı, tutarı, açıklaması ve mahsup edildiği borç kaydedilir.
    4. Mutabakat: Tahsilat kayıtları banka hareketleri ve belgelerle karşılaştırılır; istisnalar ayrılır.
    5. Raporlama: Açık borçlar, kısmi ödemeler, geciken kayıtlar ve dönem sonucu izlenir.

    Temmuz 2026 itibarıyla 634 sayılı Kat Mülkiyeti Kanunu’nun 20. maddesi ortak gider ve avans paylarına katılma esaslarını düzenliyor. Ayrıca 22 Mayıs 2026 tarihli Resmî Gazete’de yayımlanan 7579 sayılı Kanun, 37. maddeyi değiştirerek işletme projesinin kat malikleri genel kurulunda onaylanmasını; kabul edilmiş proje yoksa yöneticinin, en geç üç ay içinde kurulda onaylanıncaya kadar geçici bir işletme projesi hazırlamasını öngörüyor. Süreci kurarken 634 sayılı Kanun metnini ve 7579 sayılı güncel değişikliği birlikte kontrol etmek önemlidir.

    1. Karar ve işletme projesini tek referans noktası yapın

    Aidat borcu oluşturmadan önce yönetimin dayandığı kayıt net olmalıdır. Aynı dönem için farklı tablolar, mesajlaşma gruplarındaki tutarlar ve sözlü bilgiler kullanılırsa sonraki bütün kontroller zayıflar. Bu nedenle karar veya işletme projesinden aşağıdaki alanları standart bir forma aktarın:

    • Yönetim dönemi ve tahakkuk ayı,
    • Gider kalemleri ve bütçe toplamı,
    • Uygulanan dağıtım esası,
    • Bağımsız bölüm başına düşen tutar,
    • Son ödeme tarihi ve açıklama standardı,
    • Karar tarihi, karar numarası ve varsa ek belge,
    • Kaydı hazırlayan ve kontrol eden kişi.

    Buradaki amaç kararın hukuki geçerliliğini yazılımla üretmek değil, doğrulanmış dayanağı değişmeden operasyonel kayda taşımaktır. Dağıtım yöntemi veya sorumluluk konusunda tereddüt varsa tahakkuk açmadan önce yönetim planı ve güncel mevzuat incelenmelidir.

    Karar, işletme projesi ve gider belgelerini tek bir kayıt sorumluluğu düzeninde sınıflandırmak için apartman ve site yöneticisinin tutması gereken kayıtlar rehberindeki yasal çekirdek–operasyonel kayıt ayrımını kullanabilirsiniz.

    2. Tahakkuku dönem ve bağımsız bölüm bazında oluşturun

    Tahakkuk, belirlenen aidatın ilgili dönemde borç olarak kaydedilmesidir. Karar, borç kaydı, cari hesap ve tahsilat kavramlarının farkını uygulamadan önce aidat tahakkuku rehberindeki adımlarla netleştirin. Düzenli takip için her kayıtta en az bağımsız bölüm, dönem, borç türü, açıklama, tutar, vade ve dayanak bilgisi bulunmalıdır. Toplu oluşturma yapılacaksa toplam kayıt sayısı ile beklenen bağımsız bölüm sayısını karşılaştıran ikinci bir kontrol ekleyin.

    Liyova Aidat ve Tahakkuk Yönetimi, tekrarlayan tahakkuk planları oluşturma, toplu borçlandırma, bağımsız bölüm bazında bakiyeleri izleme ve kayıt geçmişini takip etme için tek bir çalışma alanı sunar. Bu yapı, ayrı aidat çizelgeleri arasında kopyalama yapma ihtiyacını azaltırken hangi borcun ne zaman ve hangi açıklamayla oluşturulduğunu görünür kılar.

    Tahakkuk kontrol listesi

    • Dönem adı ve vade tarihi bütün kayıtlarda aynı mı?
    • Boş, kapalı veya farklı statüdeki bağımsız bölümler ayrıca kontrol edildi mi?
    • Tutarların toplamı onaylı bütçe veya karar kaydıyla uyuşuyor mu?
    • Mükerrer tahakkuk oluşmadığı doğrulandı mı?
    • Kayıt tamamlandıktan sonra değişiklik geçmişi korunuyor mu?

    3. Tahsilatı “ödendi” işaretinden daha ayrıntılı kaydedin

    Bir borcu yalnızca ödendi olarak işaretlemek, daha sonra yapılacak mutabakat için yeterli değildir. Tahsilat kaydında ödeme tarihi, tutar, ödeme kanalı, açıklama veya referans, varsa belge ve ödemenin hangi borca mahsup edildiği bulunmalıdır. Böylece aynı tutardaki iki ödemenin karışması, kısmi ödemenin borcu yanlış kapatması veya farklı döneme ait ödemenin yanlış aya yazılması önlenebilir.

    Liyova Tahsilat ve Ödeme Takibi üzerinden işlenen tahsilatlar; ödeme adedi, tahsilat oranı, cari hesap tutarlılığı ve dönem raporları için düzenli bir veri kaynağı oluşturur. Kısmi ödeme varsa kalan bakiye açık tutulmalı; fazla veya açıklamasız ödeme ise otomatik olarak bir borcu kapatmak yerine incelenecek kayıt olarak ayrılmalıdır.

    4. Banka hareketleri ile tahsilat kayıtlarını mutabık hale getirin

    Bir dekontun bulunması ile banka hareketinin doğru borçla eşleşmesi aynı şey değildir. Eşleşen, belirsiz, kısmi ve ters hareketler için site yönetiminde banka mutabakatı karar akışını kullanın. Günlük veya en geç haftalık kontrolde sisteme girilen tahsilatlar banka hesabındaki hareketlerle karşılaştırılmalıdır. Liyova Banka Hareketleri, hareket listesini ve kaynak izlerini inceleyerek eşleştirme hazırlığı yapmak ve ilgili rapora geçmek için kullanılabilir.

    Özellikle şu kayıtları ayrı bir istisna listesinde izleyin:

    • Açıklamasında bağımsız bölüm veya ödeme yapan bilgisi bulunmayan transferler,
    • Aynı referansla iki kez girilmiş olabilecek tahsilatlar,
    • Borçtan düşük ya da yüksek tutarlı ödemeler,
    • Yanlış site veya hesap için yapılmış transferler,
    • İade ya da ters kayıt gerektiren banka hareketleri.

    İstisna çözülmeden borcu tamamen kapatmak, o ayın tahsilat oranını doğru gösterse bile sonraki dönemde cari hesap farkı üretir. Bu nedenle her istisnaya sorumlu kişi, inceleme notu ve kapanış tarihi eklemek daha güvenli bir kontroldür.

    Karardan raporlamaya site aidat takibi kontrol akışı şeması
    Karar ve plandan raporlamaya kadar her adım bir sonraki kaydın doğruluğunu etkiler.

    5. Cari hesapta açık bakiyeyi ve kayıt geçmişini koruyun

    Tahakkuk ve tahsilat aynı cari akışta görülmediğinde, “Bu bakiye hangi aydan kaldı?” sorusu uzun bir belge aramasına dönüşür. Liyova Cari Hesaplar kişi veya kurum kartlarını, işlem geçmişini, açık bakiyeyi ve iletişim bilgilerini birlikte takip etmeye yardımcı olur.

    Burada iki ayrı görünüm kullanmak yararlıdır: Birincisi bağımsız bölümün dönemsel borç ve tahsilat geçmişi, ikincisi yönetim için toplu açık bakiye listesidir. Toplu liste aksiyon önceliğini gösterirken ayrıntılı hareket dökümü, tutarın nasıl oluştuğunu açıklamalıdır. Kişisel verileri yalnızca görev için gerekli kapsamda işleyin ve erişim yetkilerini rol bazında sınırlayın.

    6. Günlük, haftalık ve aylık kontrol ritmi kurun

    Aidat takibi yalnızca ay sonunda yapılan bir kontrol olursa hatalar birikir. Küçük bir apartmanda aynı kişi birkaç adımı yürütebilir; büyük sitede görevler farklı çalışanlara dağılabilir. Her iki durumda da kontrol sıklığını önceden belirlemek gerekir.

    Sıklık Kontrol Beklenen çıktı
    Günlük Yeni tahsilatlar, banka hareketleri ve açıklamasız ödemeler Eşleşen kayıtlar ve istisna listesi
    Haftalık Açık bakiyeler, kısmi ödemeler ve mükerrer kayıt şüphesi Sorumlusu belirlenmiş aksiyon listesi
    Aylık Tahakkuk toplamı, tahsilat toplamı, banka mutabakatı ve dönem kapanışı Yönetim özeti ve doğrulanmış devir bakiyesi

    Rapor yalnızca toplam borcu değil, neden aksiyon alınamadığını da göstermelidir. Örneğin “ödeme bekleniyor”, “açıklama teyidi gerekli”, “kısmi ödeme”, “itiraz inceleniyor” gibi durum kodları, aynı kayıt üzerinde tekrar tekrar çalışılmasını önler.

    Aidat çizelgesinde hangi bilgiler bulunmalı?

    Excel veya başka bir geçiş tablosu kullanılıyorsa satır başına şu alanlar yeterli bir başlangıç sağlar: bağımsız bölüm, ilgili kişi veya cari hesap, dönem, borç türü, tahakkuk tutarı, vade, tahsil edilen tutar, tahsilat tarihi, ödeme referansı, kalan bakiye, durum ve son işlem notu. Ancak tek bir hücrede aylarca not biriktirmek yerine hareket geçmişinin ayrı kayıtlarla korunması gerekir.

    Tablonun dosya adı ve sürümü de standart olmalıdır. “Son”, “yeni son” veya kişisel bilgisayarlardaki farklı kopyalar yerine tek bir ana kayıt ve yetkili erişim modeli kullanın. Dijital bir sisteme geçerken yalnızca özellik listesini değil veri aktarımı, yetkilendirme, raporlama ve destek süreçlerini de değerlendirmek için site yönetim programı seçerken dikkat edilmesi gerekenler rehberine bakabilirsiniz.

    Sık yapılan aidat takip hataları

    • Karar ile tahakkuk arasında bağ kurmamak: Tutarın kaynağı sonradan açıklanamaz.
    • Tahsilatı açıklamasız kaydetmek: Banka mutabakatında aynı tutarlar karışır.
    • Kısmi ödemeyi tam ödeme gibi kapatmak: Açık bakiye raporu eksik çıkar.
    • Geçmiş kaydı silerek düzeltmek: Değişikliğin kim tarafından ve neden yapıldığı kaybolur.
    • Sadece toplam tahsilata bakmak: Hangi dönem ve bağımsız bölümde sorun olduğu görünmez.
    • Kontrolü tek kişiye ve hafızaya bırakmak: Görev devrinde süreç kesintiye uğrar.

    Site aidat takibi için uygulanabilir başlangıç planı

    1. Mevcut karar, işletme projesi, bağımsız bölüm listesi ve açık bakiyeleri toplayın.
    2. Tekil bağımsız bölüm ve cari hesap kayıtlarını temizleyin; mükerrerleri ayırın.
    3. Yeni dönem tahakkukunu önce kontrol listesiyle hazırlayın, ardından toplu oluşturun.
    4. Tahsilat giriş standardını ve banka mutabakat sorumlusunu belirleyin.
    5. İstisna durumlarını ve kapanış kanıtını tanımlayın.
    6. Günlük, haftalık ve aylık rapor sahiplerini takvime bağlayın.
    7. İlk ayın sonunda farkları inceleyip süreci sadeleştirin.

    Bu planın başarısı daha fazla tablo üretmekten değil, aynı bilginin karar, tahakkuk, tahsilat, banka ve cari hesap boyunca izlenebilir kalmasından gelir.

    Site aidat takibi hakkında sık sorulan sorular

    Aidat takibi ne sıklıkla yapılmalı?

    Yeni tahsilatlar ve banka hareketleri mümkünse günlük, açık bakiyeler haftalık, dönem kapanışı ise aylık kontrol edilmelidir. İşlem hacmi düşük yapılarda sıklık uyarlanabilir; önemli olan kontrolün belirli bir kişiye ve tarihe bağlanmasıdır.

    Banka dekontu aidat kaydı için yeterli midir?

    Dekont önemli bir kanıttır ancak tek başına doğru döneme ve borca mahsup yapıldığını göstermez. Dekont veya banka hareketi, tahsilat kaydı ve cari hesap hareketiyle eşleştirilmelidir.

    Kısmi ödeme nasıl izlenmeli?

    Tahsil edilen tutar ilgili borca kısmen mahsup edilmeli, kalan tutar açık bakiye olarak görünmeye devam etmelidir. Ödemenin hangi döneme uygulandığı ve kalan bakiyenin nasıl oluştuğu hareket geçmişinden anlaşılabilmelidir.

    Aidat takibi Excel ile yapılabilir mi?

    Az sayıda bağımsız bölüm ve düşük işlem hacminde standart bir tablo başlangıç için kullanılabilir. Kayıt sayısı, kullanıcı sayısı ve mutabakat ihtiyacı arttığında sürüm karmaşası, yetkilendirme ve geçmiş izleme zorlaşır; bu noktada merkezi bir yönetim sistemi daha sürdürülebilir olur.

    Aidat sürecinizi tek akışta görün

    Liyova ile tahakkuk, tahsilat, banka hareketleri ve cari hesap adımlarını birbirinden kopuk dosyalar yerine izlenebilir bir süreçte yönetebilirsiniz. Mevcut yapınıza uygun akışı görmek için demo talebi oluşturun.

  • Site Yönetim Programı Seçerken Nelere Dikkat Edilmeli?

    Site Yönetim Programı Seçerken Nelere Dikkat Edilmeli?

    Doğru site yönetim programını seçmek, uzun bir özellik listesindeki kutuları işaretlemekten ibaret değildir. Asıl soru şudur: Yazılım, yönetimin her gün tekrar eden işlerini baştan sona tutarlı bir akışa dönüştürebiliyor mu? Aidatın oluşturulmasından ödemenin eşleşmesine, sakin talebinden iş emrinin kapanmasına kadar kritik süreçleri gerçek senaryolarla sınamadan verilen kararlar, daha sonra yeni tablolar ve manuel kontroller doğurabilir.

    Bu rehber, apartman ve site yöneticilerinin bir yazılım demosunu somut kriterlerle değerlendirmesine yardımcı olur. Amaç, en fazla özelliği sunan ürünü değil; yönetim modelinize, ekip yapınıza ve sakinlerin beklentilerine gerçekten uyan sistemi belirlemektir.

    Önce yönetim ihtiyaçlarınızı haritalayın

    Demo talep etmeden önce mevcut çalışma biçiminizi yazılı hale getirin. Kaç bağımsız bölüm yönetiliyor? Kaç blok ve banka hesabı var? Tahakkuklar nasıl hazırlanıyor, ödemeler nasıl kontrol ediliyor, talepler kime yönlendiriliyor ve yönetim kurulu hangi raporları bekliyor? Bu sorular, genel bir ürün sunumunu kendi operasyonunuza ait bir teste çevirir.

    İhtiyaçları üç gruba ayırmak seçim sürecini kolaylaştırır: her gün kullanılan zorunlu akışlar, belirli dönemlerde gereken rapor ve karar süreçleri, gelecekte devreye alınabilecek ek yetenekler. Böylece etkileyici görünen fakat günlük işinize katkısı sınırlı özelliklerle temel ihtiyaçları birbirinden ayırabilirsiniz.

    1. Finansal akışı uçtan uca test edin

    Site yönetiminde finans modülü yalnızca borç ve alacak satırlarını göstermekle kalmamalı; tahakkuk, tahsilat, banka hareketi ve cari hesap arasında izlenebilir bir bağ kurmalıdır. Demoda örnek bir dönem açılmasını, farklı borç türlerinin tanımlanmasını, kısmi bir ödemenin işlenmesini ve sonucun sakin hesabı ile yönetim raporuna nasıl yansıdığının gösterilmesini isteyin.

    Aidat ve tahakkuk yönetimi için düzenli planların nasıl kurulduğunu; tahsilat ve ödeme tarafında ise ödemenin doğru borca nasıl kapatıldığını inceleyin. Banka kayıtlarının elle aktarılması gerekiyorsa iş yükünü, olası hata noktalarını ve kontrol sorumluluğunu ayrıca değerlendirin. Bu senaryoyu hazırlarken karar, tahakkuk, tahsilat, mutabakat ve raporlama kontrollerini içeren site aidat takibi rehberini kullanabilirsiniz.

    2. Talebin iş emrine dönüşmesini izleyin

    Sakinlerden gelen arıza ve hizmet talepleri yalnızca bir mesaj kutusunda kalmamalıdır. İyi tasarlanmış bir operasyon akışında talep sınıflandırılır, sorumlu kişi veya ekibe atanır, önceliklendirilir, yapılan işlem kaydedilir ve sonuç ilgili kişiye bildirilir. Demoda örnek bir teknik arıza açarak bu adımların tamamını izleyin.

    Talep yönetimi ile iş emirleri arasındaki bağlantı, yönetimin hem hizmet seviyesini hem de ekip performansını değerlendirebilmesi açısından önemlidir. Durum geçmişinin korunup korunmadığını, geciken işlerin nasıl fark edildiğini ve kapanış kanıtlarının nasıl kaydedildiğini sorun. Talebin sınıflandırmadan atama, saha kanıtı ve doğrulanmış kapanışa kadar nasıl yürütüleceğini görmek için site arıza yönetimi akışını kullanabilirsiniz.

    Site yönetim yazılımını birlikte değerlendiren profesyonel yönetim ekibi
    Demo sırasında tek tek ekranlar yerine finans, bakım, iletişim, raporlama ve yetkilendirme akışlarını baştan sona sınayın.

    3. Sakin deneyimini ayrı bir ürün gibi değerlendirin

    Yönetim ekibinin kullandığı panel güçlü olsa bile sakin tarafı karmaşıksa benimseme düşük kalabilir. Borç görüntüleme, ödeme geçmişi, duyuru okuma, talep oluşturma ve bildirim tercihleri gibi sık kullanılan işlemleri mobil ekranda deneyin. Sakinlerin yönetimi aramadan hangi bilgilere ulaşabildiğini ve kişisel verilerin yalnızca ilgili kullanıcıya gösterildiğini kontrol edin.

    Sakin mobil uygulaması, yönetim panelinin küçük bir kopyası olmamalı; sakinin en sık ihtiyaç duyduğu işlemleri kısa ve anlaşılır adımlarla sunmalıdır. Bildirimlerin hedef kitleye göre gönderilebilmesi ve geçmiş duyuruların bulunabilmesi de iletişim yükünü azaltabilecek önemli değerlendirme başlıklarıdır. Bu akışı mesaj türü, kanal, teslimat ve geri dönüş ölçütleriyle sınamak için site sakin iletişimi rehberini kullanabilirsiniz.

    4. Raporun kaynağına geri dönebildiğinizi doğrulayın

    Toplamları gösteren renkli grafikler tek başına yeterli değildir. Bir rapordaki tutardan ilgili tahsilata, gider kaydına veya cari hareketine erişilebilmesi; yönetim kurulu ve denetim süreçlerinde açıklanabilirlik sağlar. Demoda bir dönem raporu açın, toplamların hangi kayıtlardan oluştuğunu sorun ve çıktı seçeneklerini inceleyin.

    Site yönetimi raporları farklı kullanıcıların aynı veriyi kendi sorumluluklarına göre okuyabilmesine yardımcı olmalıdır. Yönetici özet görünüm isterken muhasebe ekibi hareket ayrıntısına ihtiyaç duyabilir. Bu nedenle yalnızca rapor sayısını değil, filtreleme, detaylandırma ve dışa aktarma yeteneklerini değerlendirin.

    5. Yetki ve işlem geçmişini senaryoyla sınayın

    Her çalışanın bütün verilere ve işlemlere erişmesi doğru değildir. Rol bazlı yetkilendirme; finans, operasyon, güvenlik ve yönetim kurulu gibi farklı sorumlulukların sınırlarını belirlemelidir. Örnek bir kullanıcı oluşturup hangi menüleri görebildiğini, hangi kayıtları değiştirebildiğini ve kritik işlemler için ek kontrol bulunup bulunmadığını test edin.

    Bir kayıt değiştirildiğinde kimin, ne zaman ve hangi alanı güncellediğinin izlenebilmesi de önemlidir. Yetki ve rol yönetimi ile işlem kayıtları birlikte değerlendirildiğinde, hem günlük sorumluluklar netleşir hem de geçmiş işlemler daha kolay incelenebilir.

    Karar, işletme projesi, gider belgesi ve işlem izi arasındaki sorumluluğu birlikte değerlendirmek için apartman ve site yöneticisinin tutması gereken kayıtlar rehberini demo senaryosuna ekleyin. Böylece yazılımın resmî belge usulünün yerine geçmediğini, günlük kayıtları karara ve denetime bağlayıp bağlamadığını da sınayabilirsiniz.

    6. Kurulum ve veri geçişi planını sorun

    Bir yazılımın uygunluğu yalnızca demo günündeki görünümüyle ölçülmez. Mevcut daire, sakin, bakiye ve geçmiş kayıtların nasıl taşınacağını; başlangıç kontrollerini kimin yapacağını; ekip eğitimini ve destek kanalını önceden netleştirin. Veri geçişinde hangi formatların kabul edildiğini ve canlı kullanıma geçmeden önce bir doğrulama raporu sunulup sunulmadığını öğrenin.

    Sistem seçimi tamamlandıktan sonra veri temizliği, pilot aktarım, kayıt ve bakiye mutabakatı, rol testi ile geri dönüş koşullarını takvime bağlamak için 30 günlük site yönetim yazılımına geçiş planını uygulama ekibiyle birlikte kullanın.

    Ayrıca fiyatlandırmanın hangi değişkenlere bağlı olduğunu sorun: bağımsız bölüm sayısı, kullanıcı sayısı, modüller, işlem hacmi veya ek hizmetler toplam maliyeti değiştirebilir. Teklifleri karşılaştırırken yalnızca aylık bedeli değil, kurulum, eğitim, entegrasyon ve olası geçiş maliyetlerini aynı tabloda değerlendirin.

    Demo sırasında kullanabileceğiniz kısa kontrol listesi

    • Bir tahakkuk oluşturun, ödeme girin ve cari hesaptaki sonucu doğrulayın.
    • Bir sakin talebi açın, iş emrine dönüştürün ve kapatın.
    • Sakin mobil deneyiminde borç, duyuru ve talep adımlarını tamamlayın.
    • Bir rapor toplamından kaynak işlemin ayrıntısına ilerleyin.
    • Farklı rollerde iki kullanıcıyla erişim sınırlarını test edin.
    • Değiştirilen bir kaydın işlem geçmişini görüntüleyin.
    • Veri geçişi, eğitim, destek ve toplam maliyet planını yazılı olarak alın.

    Site yönetim programı hakkında sık sorulan sorular

    Küçük apartmanlar da site yönetim programı kullanmalı mı?

    Karar yalnızca bağımsız bölüm sayısına bağlı değildir. Tahsilat takibi, kayıt düzeni, yönetim değişiminde bilgi devri ve sakin iletişimi zorlaşıyorsa küçük bir yapı da merkezi bir sistemden yararlanabilir. Seçilecek çözümün gereksiz karmaşıklık yaratmaması önemlidir.

    Ürün demosunda en önemli test nedir?

    Tek bir ekran yerine gerçek bir süreci baştan sona tamamlamaktır. Örneğin tahakkuktan ödemeye veya sakin talebinden kapanan iş emrine kadar bütün adımları izlemek, modüllerin gerçekten birlikte çalışıp çalışmadığını gösterir.

    Yazılım seçimini kimler değerlendirmeli?

    Yönetici veya yönetim kurulu yanında finans kayıtlarını tutan kişi, operasyon sorumlusu ve mümkünse sakin deneyimini temsil eden bir kullanıcı sürece katılmalıdır. Böylece seçim yalnızca tek bir rolün ihtiyaçlarına göre yapılmaz.

    Kararı özellik sayısıyla değil, çalışan süreçlerle verin

    Site yönetim programı seçerken en sağlıklı yöntem, kendi operasyonunuzdan alınmış birkaç kritik senaryoyu aday sistemlerde tamamlamaktır. Finans, talep, iletişim, raporlama ve yetkilendirme aynı veri düzeni içinde çalışıyorsa yazılım günlük yükü azaltan sürdürülebilir bir altyapıya dönüşebilir.

    Liyova’nın bu süreçleri nasıl bir araya getirdiğini kendi yönetim modeliniz üzerinden görmek için demo talebi oluşturabilir, ekibinizle birlikte gerçek iş akışlarınızı değerlendirebilirsiniz.