Bakıda əmlak idarəetmə proqramının hazırlanması yalnız mənzil və ya obyekt siyahısını rəqəmsallaşdırmaq deyil. Məqsəd bina, blok, obyekt, vahid, icarə müqaviləsi, ödəniş, texniki nasazlıq, sənəd və sahibkar hesabatı üzrə bir-birinə bağlı əməliyyat qeydləri yaratmaqdır. Düzgün qurulmuş platforma hər şöbəyə eyni sualın eyni cavabını verir: hansı vahid boşdur, hansı müqavilə bitir, hansı ödəniş gecikir, hansı təmir kimdə gözləyir və sahibkara hansı dövr üçün hansı nəticə göstərilməlidir.

Bu, ümumi CRM, rezervasiya sistemi və ya sadə mühasibat ekranı deyil. Əmlak əməliyyatları platforması aktivin özünü, həmin aktivin dəyişən vəziyyətini və onunla bağlı maliyyə və xidmət hadisələrini idarə edir. POLADO bu tip məhsulları veb platformaların hazırlanması yanaşması ilə layihələndirir: əvvəl əməliyyat qaydaları və məlumat modeli, sonra istifadəçi axınları, inteqrasiyalar və mərhələli tətbiq.

Spreadsheets və mesajlaşma nə vaxt riskə çevrilir?

Kiçik portfel üçün cədvəl və telefon zəngləri başlanğıcda praktik görünə bilər. Lakin eyni vahid üzrə müqavilə, sayğac göstəricisi, təmir xərci və ödəniş statusu müxtəlif fayl və çatlarda saxlanıldıqda, komanda artıq faktları deyil, son versiyanı axtarır. Bu, xüsusilə bir neçə bina, müxtəlif idarəedici, podratçı və ya sahibkar olduqda problem yaradır.

  • Müqavilənin başlanğıc və bitmə tarixləri fərqli cədvəllərdə uyğunsuz görünür.
  • Kirayəçi təmir tələbi göndərir, lakin icraçı, prioritet və son tarix aydın deyil.
  • Ödəniş bankda və ya payment gateway-də görünür, amma platformada avtomatik və ya nəzarətli şəkildə bağlanmır.
  • Sahibkar xalis gəlir hesabatını istəyir, lakin gəlir, xidmət haqqı, təmir və düzəlişlər eyni dövrə düzgün aid edilmir.
  • Komanda “kim dəyişdi, nə vaxt dəyişdi və nə üçün?” sualına etibarlı cavab verə bilmir.

Burada həll daha çox forma yaratmaq deyil. Həll odur ki, sistemdə hər əhəmiyyətli hadisənin sahibi, vəziyyəti, vaxtı, əlaqəli vahidi və tarixçəsi olsun.

Əvvəl əməliyyat modelini qurun, sonra funksiyaları seçin

1. Əmlak, bina və vahid reyestri

Əsas model adətən portfel, əmlak, bina, mərtəbə və vahid iyerarxiyasından başlayır. Lakin hər biznes üçün struktur eyni olmur: yaşayış kompleksi, biznes mərkəzi, anbar sahəsi və qarışıq istifadəli obyektlər fərqli atributlar tələb edir. Vahid kartında sahə, tip, status, sahibkar payı, sayğaclar, fotoşəkillər və əlaqəli sənədlər kimi məlumatlar saxlanıla bilər.

Vacib prinsip budur: “boş”, “rezervdə”, “aktiv icarədə”, “çıxış yoxlanışında”, “təmirə bağlı” kimi vəziyyətlər sadəcə sərbəst mətn olmamalıdır. Onlar müəyyən keçid qaydaları olan idarə edilən statuslar olmalıdır. Məsələn, aktiv icarə ilə bağlı vahidi yeni müqaviləyə keçirmək üçün mövcud müqavilənin çıxış və ya bağlanış mərhələsi tamamlanmalıdır.

2. İcarə müqaviləsi həyat dövrü

Yaxşı property management system Baku üçün müqavilə PDF əlavəsi deyil, əməliyyat obyektidir. O, layihə, yoxlama, təsdiq, imzalanma, aktivləşmə, uzadılma, xəbərdarlıq, çıxış və bağlanış kimi vəziyyətlərdən keçməlidir. Müqavilədə tərəflər, vahidlər, tarixlər, dövri ödənişlər, depozit, indeksləşmə və xüsusi şərtlər strukturlaşdırılmış məlumat kimi saxlanmalıdır.

Bu yanaşma müqavilə bitməsinə yaxın bildirişlər, növbəti dövr üzrə gözlənilən ödənişlər və boşalma proqnozu yaratmağa imkan verir. Həmçinin bir müqavilənin bir neçə vahidi, bir vahidin isə zaman üzrə ardıcıl müqavilələri ola biləcəyini məlumat modelində əvvəlcədən nəzərə almaq lazımdır.

3. Kirayəçi və sahibkar portalları

Tenant portal development Baku dedikdə yalnız parol ilə daxil olunan səhifə nəzərdə tutulmamalıdır. Kirayəçi yalnız öz müqavilələrini, öz hesablamalarını, öz sənədlərini və öz texniki müraciətlərini görə bilməlidir. Sahibkar isə yalnız ona aid əmlak, gəlir-xərc hərəkətləri, idarəetmə haqları və təsdiqlənmiş hesabatlara çıxış əldə etməlidir.

Bu sərhədlər interfeysdə gizlədilən düymələrə yox, server tərəfdə icra olunan icazə qaydalarına əsaslanmalıdır. OWASP minimum səlahiyyət və “default olaraq qadağan et” yanaşmasını tövsiyə edir; bu, xüsusilə fərqli sahibkarların və kirayəçilərin məlumatlarının eyni platformada saxlandığı hallarda vacibdir.

Portal təcrübəsini mühasib, menecer, kirayəçi və sahibkar üçün aydın etmək üçün UI/UX və məhsul dizaynı mərhələsində rol əsaslı menyular, mobil uyğun müraciət axınları və oxunaqlı hesab çıxarışları ayrıca layihələndirilməlidir.

4. Texniki xidmət tələbləri iş axınıdır

Maintenance request management software sadəcə “şikayət qutusu” olmamalıdır. Kirayəçi müraciət yaradır, kateqoriya seçir, foto əlavə edir və giriş üçün uyğun vaxtı qeyd edir. Dispetçer prioriteti yoxlayır, zərurət olduqda təsdiq alır, işi podratçıya və ya daxili texnikə təyin edir. İcraçı gəlişi, görülən işi, istifadə olunan materialı və xərci qeydə alır. Menecer işi qəbul edir və müraciəti bağlayır.

Əsas dizayn sualları bunlardır:

  • Hansı kateqoriyalar təcili sayılır və cavab müddəti necə ölçülür?
  • Hansı xərc həddindən sonra sahibkar və ya maliyyə təsdiqi tələb olunur?
  • Podratçı özünə aid işlərdən başqa məlumatı görə bilərmi?
  • Eyni nasazlıq təkrarlananda əvvəlki müraciətlər və avadanlıq tarixçəsi görünürmü?
  • İşin bağlanması üçün kirayəçi, menecer, yoxsa hər iki tərəfin təsdiqi lazımdır?

Ödəniş statusu maliyyə həqiqəti ilə eyni deyil

İcarə haqqı, depozit, kommunal düzəliş və təmirin kirayəçiyə yenidən hesablanması üçün sistemdə gözlənilən borc ayrıca, daxil olan ödəniş ayrıca, tətbiq edilmiş bölgü isə ayrıca saxlanmalıdır. Məsələn, bir bank köçürməsi iki fakturanı qismən bağlaya bilər; geri qaytarma, komissiya və ya uğursuz ödəniş də ilkin əməliyyatı “silərək” yox, yeni hadisə kimi qeydə alınmalıdır.

Ödəniş provayderi və ya bank inteqrasiyası istifadə olunursa, vebhook hadisələrinə kor-koranə etibar etmək olmaz. Hadisənin mənbəsi yoxlanmalı, təkrarlanan bildirişlər təhlükəsiz emal edilməli və “gözlənilir”, “uğurlu”, “uğursuz”, “geri qaytarılıb” kimi statuslar aydın xəritələnməlidir. Əməliyyatlar və istisnalar üçün uzlaşdırma ekranı yaratmaq, xüsusilə dövr sonu hesabatlarında, vacibdir.

Hesabatlar sahibkar sualından başlamalıdır

“Dashboard istəyirik” kifayət qədər tələb deyil. Əvvəlcə sahibkarın və idarəetmə komandasının qərar suallarını yazın: Bu ay hansı vahidlər gəlir yaratdı? Hansı müqavilələr 60 gün içində bitir? Hansı təmir xərcləri təsdiq gözləyir? Yığılmamış borc nə qədərdir? Hesabatdakı xalis gəlir hansı gəlir və xərclərdən formalaşır?

Hesabatlar dövr, əmlak, bina, vahid, sahibkar və müqavilə üzrə süzülə bilməlidir. Lakin hər rəqəmin detal səviyyəsində izahı da olmalıdır: sahibkar ümumi təmir xərcindən konkret müraciətə, fakturaya və təsdiqə keçə bilməlidir. Bu, PDF ixracından daha dəyərlidir, çünki rəqəmin mənbəyini yoxlamağa imkan verir.

Sənəd icazələri və audit tarixi sonradan əlavə ediləcək funksiya deyil

Müqavilələr, şəxsiyyət sənədləri, təhvil-təslim aktları, fotoşəkillər və maliyyə əlavələri eyni səviyyədə açıq olmamalıdır. Sənədin hansı əmlaka, vahidə və ya müqaviləyə aid olduğu; hansı rolun baxa, yükləyə və ya yenisini əlavə edə biləcəyi müəyyən edilməlidir. İstifadə müddəti bitən paylaşım keçidləri və yükləmələrə nəzarət də həssas sənədlər üçün nəzərdən keçirilməlidir.

Audit jurnalı isə ən azı “kim, nəyi, nə vaxt, hansı əvvəlki və yeni dəyərlə dəyişdi” sualına cavab verməlidir. OWASP tətbiq səviyyəsində audit hadisələrinin, dəyişikliklərin və ixracların qeydini vacib sayır; həmçinin həssas məlumatların jurnallara artıq həcmdə yazılmamasını vurğulayır. Audit izi ilə texniki xəta jurnallarını eyni məqsədli məlumat kimi qəbul etməmək daha düzgündür.

CRM, rezervasiya sistemi və əmlak platforması arasındakı fərq

CRM potensial müştərini, satış əlaqəsini və kommunikasiya mərhələsini idarə etmək üçün uyğundur. Rezervasiya sistemi tarix, mövcudluq və bron yaratmaq üçün güclüdür. Əmlak idarəetmə platformasının əsas vahidi isə aktiv, müqavilə və davamlı əməliyyat hadisəsidir. O, vahidin zaman üzrə vəziyyətini, icarə borclarını, texniki xərcləri, sənəd hüquqlarını və sahibkar üçün hesabat izini birlikdə saxlamalıdır.

Mövcud CRM satış hissəsində faydalı ola bilər. Mühasibat sistemi isə mühasibat uçotu üçün sistem olaraq qala bilər. Amma yeni platforma bu alətlərdəki məlumatı təkrarlayan ikinci mənbə olmamalıdır. İnteqrasiyanın məsuliyyət xəritəsi əvvəlcədən razılaşdırılmalıdır: hansı sistem kirayəçi məlumatının, hesab-fakturanın, ödənişin və ya baş kitab qeydlərinin əsas mənbəyidir?

MVP üçün düzgün sərhəd

İlk buraxılış bütün prosesləri avtomatlaşdırmağa çalışmamalıdır. Praktik MVP adətən aşağıdakıları əhatə edir:

  1. Əmlak, bina, vahid, kirayəçi və sahibkar reyestri;
  2. İcarə müqavilələrinin vəziyyətləri, tarixləri və əsas maliyyə cədvəli;
  3. Rol əsaslı admin və kirayəçi portalı;
  4. Texniki müraciət, təyinat, prioritet və status tarixçəsi;
  5. Gözlənilən ödəniş və daxilolma statusları, əl ilə uzlaşdırma imkanı;
  6. Əsas sahibkar hesabatları və ixraclar;
  7. Sənəd icazələri və audit hadisələri.

Daha sonra mobil tətbiq, podratçı portalı, sayğac inteqrasiyası, avtomatik sənəd yaratma və nəzarətli AI köməkçisi əlavə edilə bilər. Məsələn, AI müraciətləri kateqoriyalaşdırmaq və ya sənəddən strukturlaşdırılmış sahələri layihə kimi çıxarmaq üçün istifadə oluna bilər; lakin müqavilə, məbləğ və ya maliyyə statusu üzrə yekun dəyişiklik insan təsdiqi olmadan edilməməlidir.

Layihəyə başlamazdan əvvəl yoxlama siyahısı

  • İdarə etdiyiniz əmlak və vahid növlərini, həmçinin xüsusi atributları siyahılaşdırın.
  • Hər rol üçün görmək, dəyişmək, təsdiqləmək və ixrac etmək səlahiyyətlərini yazın.
  • Müqavilə, ödəniş və texniki müraciət statuslarını, o cümlədən qadağan olunmuş keçidləri müəyyən edin.
  • Bank, payment gateway, mühasibat, e-poçt və SMS kimi mövcud sistemləri, API imkanlarını və əsas məlumat mənbəyini qeyd edin.
  • Hesabat nümunələrini toplayın və hər göstəricinin hansı mənbədən hesablandığını izah edin.
  • Miqrasiya üçün mövcud Excel fayllarını yoxlayın: təkrarlanan vahidlər, natamam müqavilələr və tarix formatları çox vaxt ilk riskdir.

POLADO ilə işləyərkən bu kəşf mərhələsi əvvəlcə prosesi və riskləri aydınlaşdırmağa, sonra təhlükəsiz və genişlənə bilən məhsul sərhədini müəyyən etməyə kömək edir. Platforma istifadəyə verildikdən sonra monitorinq, təhlükəsiz yeniləmələr və dəyişikliklərin planlı idarə olunması üçün texniki dəstək və konsaltinq davamlı əməliyyat modelinin tərkib hissəsi ola bilər. Portfelinizdə məlumatın harada parçalandığını və hansı iş axınının əvvəlcə mərkəzləşdirilməli olduğunu qiymətləndirmək üçün POLADO ilə konsultasiya planlaşdırın.