Bakım talebi portalı: Daha iyi bir kiracı süreci oluşturun

Bakım talepleri neden gözden kaçar veya gecikir?

Telefon görüşmeleri, kısa mesajlar, sesli mesajlar ve dağınık e-postalar sağlıklı bir onarım kaydı oluşturmaz. Kiracı yoğun bir görüşme sırasında sızdıran bir boruyu anlatabilir. Ardından mülk yöneticisinin ayrıntıları hatırlaması, bir yüklenici bulması ve daha sonra kiracıyı bilgilendirmesi gerekir. Tek bir mesajın gözden kaçması, bir sonraki adımın sorumluluğunun kimde olduğunu herkes için belirsiz bırakabilir.

İlk ayrıntılar çoğu zaman kaybolur. Personel, «mutfakta sızıntı var» bilgisini biliyor olabilir ancak birim numarasını, kiracının sorunu ne zaman fark ettiğini, suyun hâlâ akıp akmadığını veya eve birinin girip giremeyeceğini bilmeyebilir. Çatlamış bir borunun, nemli bir tavanın veya bozuk bir cihazın fotoğrafı, sorunu kısa bir metinden daha iyi anlatabilir.

Bakım talebi portalı, kiracılara onarım taleplerini gönderebilecekleri tek bir yer sunar. Formda mülk ve birim bilgileri, sorun türü, açıklama, fotoğraflar, iletişim bilgileri ve giriş tercihleri toplanabilir. Kiracılar kendilerini daha az tekrar eder, personel de kullanabileceği bilgilere ulaşır.

Personelin ortak bir onarım kaydına da ihtiyacı vardır. Bu kayıt, talebi kimin aldığını, kimin ilgileneceğini, mevcut durumu, randevu notlarını ve kiracıya gönderilen mesajları göstermelidir. Böyle bir kayıt yoksa kiralama görevlisi kiracıya bir yüklenicinin ayarlandığını söyleyebilir ancak bakım ekibi henüz kimseyi görevlendirmemiş olabilir.

Acil onarımlar için ayrı bir yol gerekir. Portal, yangın, olası gaz kaçağı veya tıbbi acil durum gibi doğrudan tehlikelerde kiracılara acil servisleri aramalarını söylemelidir. Ayrıca aktif su baskını veya yerel kuralların hızlı müdahale gerektirdiği, ısının tamamen kesilmesi gibi ciddi bina sorunları için mülkün acil durum iletişim bilgisini de vermelidir.

Rutin talepler basit bir sırayı izleyebilir: Kiracı sorunu yeterli ayrıntı ve fotoğrafla gönderir, personel öncelik belirleyip işi atar, görevlendirilen kişi güncellemeleri ve beklenen ziyaret zamanını kaydeder, kiracı da birkaç kişiyi aramak zorunda kalmadan ilerlemeyi kontrol eder.

Anlaşılır durum güncellemeleri önemlidir. «Alındı», «planlandı», «devam ediyor» ve «tamamlandı» gibi ifadeler kiracıya ne olduğunu anlatır. Personel ziyareti zaten ayarlamışken «açık» gibi belirsiz etiketler kullanmayın. Mülk bakım uygulaması her onarımı hızlandıramaz ancak bir talebin gelen kutuları arasında kaybolmasını önleyebilir.

Portalın yapması gerekenleri seçin

İlk günden mümkün olan her özelliği eklemek yerine insanların günlük olarak ihtiyaç duyduğu işlemlerle başlayın. Kiracılar bir sorunu hızlıca bildirebilmeli, fotoğraf ekleyebilmeli, birinin ne zaman eve girebileceğini belirtebilmeli ve daha sonra onarım durumunu kontrol edebilmelidir. Çok fazla ayrıntı isteyen bir form, insanları yeniden telefon görüşmelerine ve eksik bildirimlere yöneltebilir.

Personelin daha kapsamlı bir görünüme ihtiyacı vardır. Her talebi incelemeli, ne kadar acil olduğuna karar vermeli, işi bir bakım çalışanına veya yükleniciye atamalı, güncellemeler eklemeli ve iş tamamlandığında kaydı kapatmalıdır. Her değişikliği kaydedin. Kiracı bir onarımın neden bir hafta sürdüğünü sorarsa personel, talebi kimin aldığını, yükleniciyle ne zaman iletişime geçildiğini ve hangi işlerin yapıldığını görebilmelidir.

Her kişiye doğru görünümü sunun

Kiracılar yalnızca bir sonraki adımı anlamalarına yardımcı olan bilgileri görmelidir. İç notlarda yüklenici iletişim bilgileri, maliyet tahminleri, olası nedenler veya giriş sorunları bulunabilir. Yanlışlıkla paylaşılmalarını önlemek için bu notları kiracı mesajlarından ayrı tutun.

Kiracı portalında az sayıda, anlaşılır durum kullanın:

• Gönderildi: Mülk ekibi talebi aldı.
• İnceleniyor: Personel sorunu kontrol ediyor ve ne yapılacağına karar veriyor.
• Planlandı: Onarım ziyareti için bir tarih veya zaman aralığı belirlendi.
• Devam ediyor: Bir çalışan onarıma başladı.
• Tamamlandı: Personel işin bittiğini kaydetti.

Personel «parça bekleniyor» veya «yüklenici teklifinin gelmesi bekleniyor» gibi ek iç durumları kullanabilir. Kiracıların her operasyonel ayrıntıyı çözmesi gerekmez. Mutfak musluğu için yedek parça gerekiyorsa «Parçayı sipariş ettik, ziyaret tarihini kesinleştirince bildireceğiz» şeklindeki bir güncelleme çok daha yararlıdır.

AppMaster, ayrı kiracı ve personel ekranlarını, bir talep veritabanını ve durum değişikliklerini yöneten görsel iş süreçlerini destekleyebilir. Önce temel talep yolculuğunu oluşturun. Ekip portalı düzenli biçimde kullanmaya başladıktan sonra yüklenici iş akışlarını veya otomatik anımsatıcıları ekleyin.

Talep formunu ve onarım kaydını planlayın

Form, doğru kişiyi görevlendirmek için yeterli ayrıntıyı toplamalı ancak basit bir bildirimi evrak işine çevirmemelidir. Kiracılar sorunu bir kez anlatmalıdır. Ekibiniz temel bilgileri telefon veya e-posta yoluyla tekrar istemek zorunda kalmamalıdır.

Her onarım kaydına kısa ve anlaşılır bir başlıkla açıklamayla başlayın. «Mutfak lavabosunun altında su var» ifadesi, bakım çalışanına «tesisat sorunu» ifadesinden daha fazla bilgi verir. Kiracıdan mutfak, banyo, yatak odası, koridor veya ortak alan gibi bir konum seçmesini isteyin. Kategori de personelin işi yönlendirmesine yardımcı olur: tesisat, ısıtma, elektrik, cihaz, haşere veya genel onarım.

Kiracıların anlayabileceği öncelik soruları kullanın. Teknik aciliyeti değerlendirmelerini istemek yerine aktif su olup olmadığını, ısının kesilip kesilmediğini, güvenlik sorunu bulunup bulunmadığını veya hasarın yayıldığını sorun. Personel, onarım önceliğini bu bilgilere göre belirleyebilir.

Kayıtta kiracının birim numarası, adı, telefon numarası ve e-posta adresi de bulunmalıdır. Kiracı giriş yaptıysa bu bilgileri otomatik doldurun ve gerekirse telefon numarasını düzeltmesine izin verin. Böylece «ışık bozuk» gibi yardımın nereye gönderileceği belli olmayan bildirimlerin önüne geçilir.

Fotoğraf ekleri, boşa giden ilk ziyaretleri çoğu zaman önler. Her talebe birkaç fotoğraf eklenmesine izin verin ve bunları ayrı bir gelen kutusuna göndermek yerine onarım kaydına bağlayın. Kiracılardan kişisel belgeleri veya diğer sakinleri değil, sorunun bulunduğu alanı fotoğraflamalarını isteyin.

Giriş ayrıntılarını taleple birlikte tutun

Onarım ekibi işi planlamadan önce giriş iznini ve zaman bilgilerini bilmelidir. Her talebe basit giriş seçenekleri ekleyin: «Evde olacağım», «Ben yokken girebilirsiniz» ve «Girmeden önce benimle iletişime geçin». Uygun tarihleri veya zaman aralıklarını ve pratik notlar için bir alanı da ekleyin.

Bu notta evcil hayvan, uyuyan çocuk, kapı kodu veya zil yerine kapının çalınması isteği bulunabilir. Bu ayrıntıları kimlerin görebileceğini sınırlayın ve görevlendirilen çalışanın en güncel talimatları görebilmesi için taleple birlikte tutun.

AppMaster'da bu alanları Data Designer'da modelleyebilir ve kiracı formunu görsel iş süreçleriyle bir onarım kaydına bağlayabilirsiniz. Durum güncellemelerini ilk bildirimden ayrı tutun. Böylece yöneticiler ve kiracılar işi başlatan ayrıntıları her zaman inceleyebilir.

Kiracılar için bildirim göndermeyi kolaylaştırın

Bakım talebi portalı, kişinin yorgun, meşgul olduğu veya sızdıran bir boruyla uğraştığı bir anda bile kullanabileceği kadar basit olmalıdır. Tesisat, ısıtma, cihaz, elektrik, haşere ve güvenlik gibi anlaşılır kategoriler kullanın. Kiracıların binanın nasıl çalıştığını bildiğini varsayan etiketlerden kaçının.

Formun başlarında oda veya alanı sorun. Mutfak, banyo, yatak odası, koridor veya dış alan gibi kısa bir liste, bakım ekibinin talepleri ayırmasına yardımcı olur. Ortak çamaşır odaları, park alanları ve daha az kullanılan konumlar için «diğer» seçeneği ekleyin.

Açıklama kutusu yalnızca boş bir alan olmamalı, yönlendirici bir soruyla birlikte gelmelidir. Kiracıya sorunun ne zaman başladığını, ne gördüğünü veya duyduğunu, her zaman olup olmadığını ve su, elektrik, ısı veya giriş durumunda değişiklik bulunup bulunmadığını sorun. Örneğin: «Musluğu her açtığımda mutfak lavabosunun altındaki borudan su sızıyor. Bu sabah başladı.»

Kiracıların görüntüleri doğrudan telefondan veya bilgisayardan eklemesine izin verin ve yükleme kontrolünü kolay bulunur bir yere koyun. Cihaz etiketi, tavan lekesi veya bir tesisat parçasının çevresindeki su fotoğrafı, ziyaret öncesinde onarım ekibine yararlı bilgiler verir.

Standart formu sıradan onarım taleplerine odaklayın. Acil durum yönlendirmesini formun üzerinde, ayrı bir bildirim olarak gösterin. Kiracılara yangın, gaz kokusu veya ciddi yaralanma gibi doğrudan tehlikelerde acil servisleri aramalarını söyleyin. Büyük bir aktif sızıntı veya ısının tamamen kesilmesi gibi acil mülk sorunları için ayrı bir acil bakım iletişim bilgisi verin.

Pratik bir form kısa kalabilir:

• Sorun kategorisi ve oda veya alan
• Sorunun açıklaması ve ne zaman başladığı
• Varsa fotoğraf ekleri
• Giriş tercihi ve iletişim bilgileri

AppMaster, görsel formlar, dosya yüklemeleri ve personelin inceleyebileceği bir talep kaydıyla bu tür bir mülk bakım uygulaması oluşturmanıza yardımcı olabilir. İsteğe bağlı alanları zorunlu tutmayın. Kiracılar fotoğrafı olmasa veya bozulan parçanın adını bilmese bile birkaç dakika içinde yararlı bir bildirim gönderebilmelidir.

Giriş tercihlerini güvenli biçimde toplayın

Onarım ekibi, kiracının evine girip giremeyeceğini asla tahmin etmek zorunda kalmamalıdır. Her talebe bir giriş seçeneği ekleyin ve özellikle acil sorunlarda ifadeleri anlaşılır tutun.

Normal durumları kapsayan az sayıda seçenek sunun: Kiracı yokken giriş izni, girişten önce randevu, önce kiracıyla iletişim veya acil bir sorun için acil giriş. Kiracının telefon, mesaj veya e-posta gibi hangi iletişim yöntemini istediğini sorun ve birkaç uygunluk aralığı toplayın. Kiracı hafta içi 17.30'dan sonra ziyarete izin verip çalışma saatlerinde izin vermeyebilir. Bu bilgiler kaçırılan randevuları ve tekrarlanan aramaları azaltır.

Giriş talimatlarını hassas bilgi olarak değerlendirin. Kapı kodu, bina giriş kodu, anahtar kutusu bilgisi veya evcil hayvan uyarısını yalnızca onarım gerektiriyorsa toplayın. Bu alanları her talep için zorunlu tutmayın. Erişimi sınırlayın ve kiracı bilgilerini güncellediğinde veya onarım kapandığında eski talimatları kaldırın.

En güncel giriş tercihini, bakım personelinin ziyareti planlamadan veya başlatmadan önce görebileceği şekilde iş emri durumunun yanında gösterin. Kiracı «giriş izni» seçeneğini «randevu gerekli» olarak değiştirirse eski talimatı yenisiyle değiştirin, ikisini birden göstermeyin.

Örneğin bir kiracı mutfaktaki sızdıran boruyu bildirir ve «önce iletişime geçin» seçeneğini seçer. Mülk yöneticisi arar, salı sabahı için bir ziyaret üzerinde anlaşır ve randevuyu kaydeder. Tesisatçı gelmeden önce kesinleşmiş saati ve güncel giriş notunu görür. Bu basit aktarım, kilitli bir kapıya yapılan gereksiz bir ziyareti önler.

AppMaster ile oluşturulan bir mülk bakım uygulaması, giriş seçeneklerini onarım kaydıyla birlikte saklayabilir ve güncel ayrıntıları yalnızca yetkili personele gösterebilir. Bir durum değişikliği, ziyaret planlandı olarak işaretlenmeden önce ekibin girişi doğrulamasını da sağlayabilir.

Kiracıların kafasını karıştırmadan onarım ilerlemesini gösterin

Kiracı portalı, yaygın bir soruya yanıt vermelidir: «Onarımım ne durumda?» Kısa bir durum, daha fazla soru doğuran ayrıntılı bir iş günlüğünden daha iyidir.

Her talepte aynı ifadeleri kullanın. Genellikle beş aşama yeterlidir:

• Alındı: Mülk ekibi talebi aldı ve inceleyecek.
• Planlandı: Onarım ziyareti için bir tarih belirlendi veya ekip tarih ayarlıyor.
• Devam ediyor: Teknisyen işe başladı veya sorunu teşhis ediyor.
• Beklemede: Onarım için bir parça, onay veya başka bir ziyaret gerekiyor.
• Tamamlandı: Ekip onarımı bitmiş olarak işaretledi.

«Açık», «beklemede» veya «atandı» gibi etiketlerden kaçının. Bunlar iç çalışmayı anlatır ancak kiracıya birinin gelip gelmeyeceğini veya kendisinin bir şey yapması gerekip gerekmediğini söylemez.

Her talep, en son güncellemenin tarihini ve tek bir sonraki adımı göstermelidir. Sızdıran musluğu bildiren bir kiracı şunu görebilir: «Planlandı. 12 Mayıs'ta güncellendi. Tesisatçı 14 Mayıs'ta 09.00 ile 12.00 arasında ziyaret edecek.» Gerekli vana stokta yoksa mesaj şöyle olabilir: «Beklemede. 14 Mayıs'ta güncellendi. Yedek parçayı sipariş ettik. Parça geldiğinde sizinle iletişime geçeceğiz.»

Kiracı güncellemelerini personel notlarından ayırın

Mülk personeli, yöneticiler ve hizmet sağlayıcılar; hizmet sağlayıcı teklifi, hesap geçmişi, bina giriş notu veya sorumlulukla ilgili iç görüşme gibi özel ayrıntılara ihtiyaç duyabilir. Bu notları kiracı görünümüne koymayın.

İç notlar ve kiracıya yönelik güncellemeler için ayrı alanlar oluşturun. Personel tüm onarım geçmişini kaydedebilir, kiracılar ise sakin bir özeti, sonraki adımı ve randevu ayrıntılarını görür. AppMaster, rol tabanlı ekranlarla bu ayrımı destekler. Personel onarım kaydını yönetirken kiracılar yalnızca kendilerine yönelik güncellemeleri görür.

Tamamlandı durumu «Tesisatçı 16 Mayıs'ta musluk contasını değiştirdi» gibi kısa bir kapanış mesajı içermelidir. Kiracılara sorunun devam ettiğini bildirebilecekleri bir yol sunun. Böylece ilk ziyaret sorunu çözmediğinde onarım görünür kalır.

Portalı adım adım oluşturun

İlk sürümü tek bir eksiksiz yol etrafında kurun: Kiracı sorun bildirir, personel inceler, bir onarım çalışanı görevlendirilir ve kiracı güncellemeleri görür. AppMaster, aynı görsel projeden arka uç hizmetleri, web portalı ve mobil uygulamalar oluşturabilir; kayıtları da bağlantılı tutar.

1. Kiracı hesapları oluşturun ve her hesabı doğru mülk ile birime bağlayın. Kiracılar yalnızca kendi birimleriyle ilgili talepleri görmelidir. Personelin erişimini mülk yöneticisi veya bakım koordinatörü gibi rollerine göre belirleyin.

2. Kategori, kısa başlık, açıklama, fotoğraf yükleme, tercih edilen ziyaret zamanı ve giriş tercihini içeren bir talep formu oluşturun. Kategori ve açıklamayı zorunlu tutun. Aktif sızıntı gibi acil sorunlarda acil durum numarasını arama talimatını da gösterin.

3. Yeni talepleri üstte listeleyen ve mülke, duruma, kategoriye ve tarihe göre filtreleyen bir personel çalışma alanı ekleyin. Ekibiniz takip ediyorsa görevlendirilen yüklenici, randevu tarihi, iç notlar ve onarım maliyeti alanlarını da ekleyin.

4. Yeni, İncelendi, Planlandı, Devam ediyor ve Tamamlandı gibi durumlar oluşturun. Personel durumu değiştirdiğinde değişikliği yapan kişinin adını ve zamanı kaydedin. Böylece kiracı aradığında personelin kontrol edebileceği bir onarım geçmişi oluşur.

5. Yeni talep, randevu ve kiracıya yönelik durum güncellemeleri için bildirim gönderin. E-posta veya SMS kullanılabilir ancak kiracıları her iç düzenleme hakkında bilgilendirmeyin. Çok fazla uyarı, insanların yararlı bildirimleri gözden kaçırmasına neden olur.

Kiracıları davet etmeden önce örnek bir hesapla portalın tamamını test edin. Mutfak sızıntısının fotoğrafını gönderin, giriş tercihi seçin, talebi bir personele atayın ve tamamlandı olarak işaretleyin. Kiracının doğru güncellemeyi gördüğünü ve iç ayrıntıların gizli kaldığını doğrulayın.

AppMaster'ın Data Designer'ı birimleri, kiracıları, talepleri, fotoğrafları ve durum geçmişini modelleyebilir. Business Process Editor, yeni bir talebi doğru personele yönlendirebilir ve iş akışını elle kod yazmadan bildirimleri tetikleyebilir.

Örnek: Kiracı mutfak sızıntısını bildiriyor

Maya, bulaşık yıkadıktan sonra mutfak lavabosunun altında su biriktiğini fark eder. Telefonundan portalı açar, «Tesisat» seçeneğini seçer ve şunu yazar: «Musluk açıkken lavabonun altındaki borudan su damlıyor. Dolabın tabanı ıslak.»

Biri sızdıran boruyu, diğeri ıslak dolabı gösteren iki fotoğraf ekler. Suyun dolaba ve zemine zarar verebileceği için sorunun hızlı ilgilenilmesi gerektiğini seçer. Form, personelin ne zaman girebileceğini sorar. Maya «Randevu gerekli» seçeneğini seçer, hafta içi 16.00'dan sonra uygun olduğunu belirtir ve planlama güncellemeleri için bir telefon numarası girer. Portal 1842 numaralı talebi oluşturur ve «Alındı» durumunu gösterir.

Bir mülk yöneticisi talebi aynı sabah inceler. Fotoğraflar, patlamış bir borudan çok gevşek bir gider bağlantısına işaret eder. Yönetici bir tesisatçı görevlendirir ve durumu «Planlandı» olarak değiştirir. Maya, salı günü 16.30 ile 18.00 arasındaki randevu aralığını portalda görür.

Tesisatçı aşınmış bir contayı değiştirir, bağlantıyı sıkılaştırır ve lavaboyu test eder. Kısa bir iş notu ekler: «Gider contası değiştirildi ve lavabo beş dakika boyunca test edildi. Başka sızıntı görülmedi.» Personel daha sonra talebi tamamlandı olarak işaretler.

Maya, seçtiği bildirim yöntemine göre e-posta veya mesaj yoluyla tamamlanma bildirimi alır. Onarım notunu okuyabilir ve dolabın kuru kaldığını doğrulayabilir. Su yeniden sızarsa yeni bir talep oluşturmak yerine aynı talebi yeniden açabilir.

Ortak onarım kaydı burada yarar sağlar. AppMaster, kiracının açıklamasını, fotoğraflarını, giriş tercihini, randevuyu, personel notlarını ve son onayı tek yerde tutabilir. Böylece aramalar, kayıp mesajlar ve belirsiz onarım durumları azalır.

Kiracıları rahatsız eden yaygın hatalar

Bakım talebi portalı bildirim sürecini kolaylaştırmalı, mülk yönetimi işini kiracıların üzerine bırakmamalıdır. Form veya durum sistemindeki küçük tercihler, insanların ciddi bir sorunun okunup okunmadığından emin olamamasına neden olabilir.

Kiracılardan «acil», «rutin» veya «önleyici» gibi teknik etiketleri seçmelerini istemeyin. Çoğu kişi nemli bir alanın küçük bir sorun mu yoksa büyüyen bir sızıntı mı olduğunu değerlendiremez. Aktif su, ısı kaybı, güvenlik sorunu veya yayılan hasar hakkında anlaşılır sorular sorun, ardından önceliği personelin belirlemesini sağlayın.

İç bilgileri kiracı görünümünden uzak tutun. Personel notlarında tedarikçi fiyatları, planlama ayrıntıları veya kiracıların görmesine gerek olmayan görüşmeler bulunabilir. Yüklenici kiracıların kendisiyle iletişime geçmesini kabul etmedikçe doğrudan telefon numarasını paylaşmayın.

Her durumu açıklayın

«Beklemede» çok az şey anlatır. Onay, parça, randevu veya kiracıdan yanıt bekleniyor olabilir. Her durum, kiracıya ne olduğunu ve mümkünse bundan sonra ne yapması gerektiğini söylemelidir.

Şu tür güncellemeler kullanın:

• «Talebinizi aldık ve salı gününe kadar inceleyeceğiz.»
• «Tesisatçı perşembe günü 09.00 ile 12.00 arasında ziyaret edecek.»
• «Yedek parçayı sipariş ettik. Geldiğinde sizi bilgilendireceğiz.»
• «Onarımı planlayabilmemiz için uygun olduğunuz giriş zamanını belirtmeniz gerekiyor.»

Bir talebi yalnızca personel yapılan işi kaydettikten sonra kapatın. «Arızalı lavabo sifonu değiştirildi ve sızıntı testi yapıldı» gibi bir not, kiracıya yararlı bir kayıt sunar ve sorun tekrarlarsa personele yardımcı olur. Uygun olduğunda tamamlanan talebi görünür bırakın ve kiracının sorunun devam ettiğini bildirmesine izin verin.

Fotoğraflar personelin arızayı anlamasına yardımcı olur ancak güvenlik sorunlarında doğrudan iletişimin yerini tutamaz. Duman hasarı, açıkta kalan kablolar, gaz kokusu veya büyük bir su baskını fotoğrafı yavaş yüklenebilir ya da mesai saatleri dışında görülmeyebilir. Formun yanında belirgin bir acil durum talimatı bulundurun. Portal daha sonra bildirimi kaydedebilir ancak güvenlik müdahalesini geciktirmemelidir.

Kiracıları davet etmeden önce portalı kontrol edin

Portalınızı bir binayla paylaşmadan önce kiracılar gibi test edin. Ofis dizüstü bilgisayarında iyi görünen bir form, birçok sakinin sorun bildireceği telefonda kullanışsız olabilir.

Bir test talebini telefondan, diğerini masaüstü tarayıcıdan gönderin. Formun kolay okunduğunu, düğmelerin görünür kaldığını ve kiracının bir hata sonrası ayrıntıları yakınlaştırmadan veya yeniden yazmadan bildirim gönderebildiğini kontrol edin.

Testte gerçek bir fotoğraf kullanın. Örnek bir sorunun görüntüsünü yükleyin ve ardından talebi personel görünümünde açın. Personel görüntüyü net biçimde görmeli ve hangi talebe ait olduğunu anlamalıdır. Fotoğraf büyük olduğunda veya yükleme sırasında kiracının bağlantısı kesildiğinde ne olduğunu kontrol edin.

Giriş ayrıntılarını da test edin. Kiracının saat 17.00'den sonra evde olduğu bir talep, bildirimle girişe izin verdiği başka bir talep ve personelin önce araması gereken üçüncü bir talep oluşturun. Her talebi bir çalışana atayın ve kişinin tercihi talep ayrıntılarıyla birlikte aldığını doğrulayın. Ayrı bir mesaja veya hatırlamaya güvenmeyin.

Bir talebi gönderildi, planlandı, devam ediyor ve tamamlandı dahil planlanan tüm durumlardan geçirin. Her kiracı bildirimini inceleyin. Her mesaj, yalnızca personele açık ayrıntıları göstermeden değişikliği anlaşılır biçimde açıklamalıdır.

Son olarak iki kiracı hesabıyla gizliliği test edin. Her kişi yalnızca kendi onarım taleplerini görmelidir. İç notları, özel çalışan iletişim bilgilerini veya diğer sakinlerin taleplerini görmemelidir. AppMaster portalında aynı izin kurallarını oluşturulan web ve mobil arayüzlerde de test edin. Erişim kurallarını kullanıma açılmadan önce düzeltmek, daha sonra bir gizlilik hatasını açıklamaktan çok daha kolaydır.

Bakım talebi portalınız için sonraki adımlar

Birkaç hafta boyunca tek bir mülkle veya sınırlı sayıda birimle başlayın. Gerçek talepler, formun nerede anlaşılmadığını, insanların hangi kategorileri yanlış seçtiğini ve personelin ek mesajlara ihtiyaç duymadan onarımları ilerletip ilerletemediğini gösterecektir.

Kiracılardan ve personelden belirli konularda geri bildirim isteyin. Bir kiracı «tesisat» ile «su sızıntısı» arasında seçim yapmakta zorlanabilir. Bakım koordinatörü ise randevuyu veya sipariş edilen parçayı kaydetmek için daha iyi bir yönteme ihtiyaç duyabilir. Daha fazla seçenek eklemeden önce insanları yavaşlatan noktaları düzeltin.

İlk sürümü günlük işe odaklayın: fotoğraf yükleme ve giriş tercihleri içeren basit bir onarım formu, yaygın sorun kategorileri, işi açıklayan durumlar, ortak bir onarım geçmişi ve personelin daha fazla bilgiye ihtiyaç duyduğunda veya durumu değiştirdiğinde gönderilen bildirimler.

İlk aydan sonra talepleri inceleyin. Birçok kişi «diğer» seçeneğini seçiyorsa gerçek sorunlara uyan kategoriler ekleyin. Kiracılar «devam ediyor» durumundaki talepler hakkında güncelleme istemeye devam ediyorsa «randevu planlandı» veya «parça bekleniyor» gibi daha özel ifadeler kullanın. Anlaşılır dil gereksiz aramaları azaltır.

AppMaster ile onarım kayıtları, formlar, yönlendirme süreçleri ve kiracılarla personel için web veya mobil ekranlar içeren kodsuz bir portal oluşturabilirsiniz. Tek bir talep türü ve tek bir personel inceleme süreciyle başlayın. Temel süreç iyi çalıştıktan sonra otomatik atama veya daha ayrıntılı iş akışları ekleyin.

İlk test basit olmalıdır: Kiracı sızdıran mutfak lavabosunun fotoğrafını gönderir, evde olmadığında personelin giriş yapıp yapamayacağını seçer ve onarım tamamlanana kadar güncellemeleri alır. Bu yol herkes için anlaşılırsa portal daha geniş kullanıma hazırdır.