Asansör Arıza Yazılımı Demo Günü Skor Kartı

İÇERİK

Bir asansör arıza yazılımı demosu, ürünün özelliklerini izlediğiniz sıradan bir tanıtım toplantısı olmamalıdır. Demo günü; yazılımın gerçek saha koşullarında arıza kaydını ne kadar hızlı açtığını, doğru teknisyeni nasıl yönlendirdiğini, bina yöneticisini nasıl bilgilendirdiğini ve yönetime hangi ölçülebilir verileri sunduğunu sınadığınız bir değerlendirme sürecidir. Hazırlıklı gitmezseniz etkileyici ekranlara odaklanabilir, işletmeniz açısından kritik eksikleri fark edemeyebilirsiniz. Bu rehberdeki skor kartını kullanarak farklı yazılımları aynı kriterlerle karşılaştırabilir ve satın alma kararınızı kişisel izlenimler yerine somut sonuçlara dayandırabilirsiniz.

Demo Öncesinde İhtiyaçlarınızı Netleştirin

Skor kartı hazırlamanın ilk adımı, firmanızdaki mevcut arıza sürecini açık biçimde ortaya koymaktır. Telefonla gelen çağrının kim tarafından karşılandığını, kaydın nereye yazıldığını, teknisyen atamasının nasıl yapıldığını ve iş tamamlandıktan sonra müşteriye hangi belgenin verildiğini belirleyin.

Örneğin arıza talepleriniz WhatsApp grupları, telefon görüşmeleri ve kâğıt notlar arasında dağılıyorsa temel beklentiniz yalnızca dijital kayıt oluşturmak değildir. Yazılımın bilgi kaybını önlemesi, mükerrer kayıtları azaltması ve ofis ile saha arasında ortak bir iş akışı kurması gerekir.

Demo öncesinde şu verileri hazırlayın:

• Bakım portföyünüzdeki yaklaşık asansör sayısı
• Aylık ortalama arıza kaydı
• Aktif teknisyen ve ofis personeli sayısı
• Şube veya ekip sayısı
• Mesai dışı nöbet düzeni
• Tekrarlayan arızaların yaklaşık oranı
• Müşteriye sunulan servis formu ve rapor türleri
• Kullanılan muhasebe, SMS veya tahsilat sistemleri
• İnternet erişiminin zayıf olduğu hizmet bölgeleri
• İşletmenizde en fazla zaman kaybettiren üç süreç

Bu hazırlık, tanıtımı yapan kişinin genel özellikleri sıralaması yerine sizin çalışma düzeninize uygun bir senaryo göstermesini sağlar.

İyi bir demo, “Yazılımda neler var?” sorusundan çok “Bizim günlük arıza sürecimiz bu yazılımda nasıl yürür?” sorusuna cevap vermelidir.

Demo İçin Gerçek Bir Arıza Senaryosu Belirleyin

Yazılımı boş ve ideal bir örnek üzerinden değerlendirmek yanıltıcı olabilir. Bunun yerine yakın zamanda yaşadığınız, birden fazla aşaması bulunan gerçekçi bir arıza senaryosu seçin.

Örnek senaryo şöyle olabilir:

1. Bir apartman yöneticisi saat 18.20’de asansörün üçüncü katta kaldığını bildirir.
2. Ofis personeli bina ve cihaz bilgilerini bularak arıza kaydı açar.
3. Sistem uygun veya nöbetçi teknisyeni belirler.
4. Teknisyen mobil cihazından görevi kabul eder ve yola çıkar.
5. Bina yöneticisine bilgilendirme yapılır.
6. Teknisyen sahada geçmiş arızaları ve önceki müdahaleleri inceler.
7. Arızanın kapı kilidi temasından kaynaklandığını tespit eder.
8. Kullanılan malzemeyi, açıklamayı ve fotoğrafı kaydeder.
9. Müşteri imzası alınır ve servis formu oluşturulur.
10. Yönetici, arızanın ne kadar sürede karşılandığını rapordan kontrol eder.

Demo sırasında bu adımların tamamını mümkünse sizin ekip üyeleriniz gerçekleştirmelidir. Hazır sunumdaki ekran görüntüleri yerine canlı kayıt açılmasını isteyin. Bir işlemin masaüstünde çalışması yeterli değildir; saha teknisyeninin mobil uygulamada aynı süreci ne kadar rahat tamamladığı da görülmelidir.

Özellikle acil durumlarda gereksiz alanlar ciddi zaman kaybettirir. Arıza kaydı açılırken 20 alan doldurulması gerekiyorsa yazılım kapsamlı görünse bile günlük kullanımda ekibin direnciyle karşılaşabilir. Zorunlu alanların ihtiyaca göre düzenlenip düzenlenemediğini mutlaka sorun.

Asansör Arıza Yazılımı Demo Skor Kartı

Aşağıdaki kart, toplam 100 puan üzerinden hazırlanmıştır. Her kriteri 1 ile 5 arasında puanlayın. Ardından verdiğiniz puanı kriter ağırlığıyla ilişkilendirin. Basit hesaplama için alınan puan ÷ 5 × ağırlık formülünü kullanabilirsiniz.

Değerlendirme alanı	Ağırlık	Demo sırasında kontrol edilecek konu
Arıza kaydı ve cihaz eşleştirme	15	Kaydın hızlı açılması, bina ve asansör geçmişine erişim
Mobil saha kullanımı	15	Görev kabulü, fotoğraf, imza, açıklama ve çevrimdışı çalışma
Atama ve bildirim süreci	10	Uygun teknisyene yönlendirme, durum güncellemesi, müşteri bildirimi
Arıza geçmişi ve tekrar analizi	15	Aynı cihazdaki önceki arızaların ve müdahalelerin görülebilmesi
Servis formu ve belge üretimi	10	Firma logolu PDF, imza, kullanılan malzeme ve paylaşım seçenekleri
Raporlama ve KPI takibi	10	Müdahale süresi, kapanış süresi, teknisyen ve cihaz bazlı analiz
Kullanım kolaylığı	10	Eğitim ihtiyacı, ekran sadeliği, işlem sayısı ve mobil okunabilirlik
Yetkilendirme ve veri güvenliği	5	Kullanıcı rolleri, kayıt geçmişi, yedekleme ve erişim kontrolleri
Entegrasyon ve veri aktarımı	5	Mevcut müşteri-cihaz verisi, SMS, muhasebe veya API olanakları
Eğitim ve teknik destek	5	Kurulum, eğitim, destek kanalı ve geri dönüş süreleri
Toplam	100	Satın alma kararında kullanılacak genel sonuç

Her kriter için yalnızca puan vermeyin; kısa bir kanıt notu da yazın. Örneğin “mobil kullanım: 4/5” ifadesinin yanına “Teknisyen üç dakikada formu tamamladı, ancak internet yokken fotoğraf yükleme ayrıca test edilmeli” notunu ekleyin.

Bu yöntem, toplantıdan birkaç gün sonra ayrıntıların unutulmasını önler. Birden fazla sağlayıcıyla görüşüyorsanız bütün demoları aynı senaryo ve ağırlıklarla değerlendirin.

Sonuç Puanı Nasıl Yorumlanmalı?

Genel bir karar çerçevesi olarak şu aralıklar kullanılabilir:

• 85–100 puan: İhtiyaçlarla yüksek düzeyde uyumlu; referans ve sözleşme kontrolüne geçilebilir.
• 70–84 puan: Kullanılabilir; düşük puan alan kritik konular için ek demo veya yazılı taahhüt istenmelidir.
• 55–69 puan: Önemli iş akışı boşlukları bulunabilir; pilot uygulama yapılmadan karar verilmemelidir.
• 55 puanın altı: Mevcut ihtiyaçlara uyum zayıftır veya demo yeterli kanıt sunmamıştır.

Toplam puanın tek başına yeterli olmadığını unutmayın. Örneğin yazılım 82 puan almış olabilir; ancak firmanız için vazgeçilmez olan çevrimdışı çalışma özelliği yoksa yüksek toplam puan satın alma kararını haklı çıkarmayabilir. Kritik kriterler için ayrıca bir “olmazsa olmaz” işareti koyun.

Mobil Saha Kullanımını Gerçek Koşullarda Test Edin

Asansör arıza yönetiminin önemli bölümü makine dairesinde, kuyu çevresinde veya binanın internet bağlantısının zayıf olduğu alanlarda yürütülür. Bu nedenle masaüstü ekranlarının düzenli görünmesi, saha performansının iyi olduğu anlamına gelmez.

Demo sırasında mobil uygulamayı kendi teknisyeninizin kullanmasını isteyin. Teknisyene uzun bir eğitim vermeden şu görevleri tamamlatın:

• Kendisine atanan arızayı bulma
• Bina ve asansör bilgilerine ulaşma
• “Yola çıktı” veya benzeri durum güncellemesi yapma
• Önceki arıza kayıtlarını inceleme
• Fotoğraf ve açıklama ekleme
• Kullanılan parçayı kaydetme
• Müşteri imzası alma
• Servis formunu tamamlama
• İnternet kesildiğinde kaydı saklama ve daha sonra eşitleme

İşlem sırasında kaç dokunuş gerektiğini ve teknisyenin nerelerde yardıma ihtiyaç duyduğunu not edin. Bir işlevin mevcut olması kadar kolay bulunması da önemlidir. Sık kullanılan bir işlem, karmaşık menülerin arkasında kalıyorsa ekip bir süre sonra kayıt girmeyi erteleyebilir.

Arıza sırasında kullanılan mobil ekranlarda yazıların okunabilirliği, butonların eldivenle kullanım kolaylığı ve yanlışlıkla kaydı kapatma riski de değerlendirilmelidir. Özellikle kıdemli teknisyenlerin ve teknoloji kullanımı sınırlı personelin görüşleri satın alma kararına dahil edilmelidir.

Tekrar Arıza ve Müdahale Kalitesini Ölçün

Arıza yazılımının gerçek değeri yalnızca kayıtların dijital ortamda tutulması değildir. Sistem, aynı asansörde tekrarlanan sorunların fark edilmesini ve geçici müdahalelerin kalıcı çözümlerden ayrılmasını sağlamalıdır.

Demo sırasında belirli bir asansöre üç benzer arıza kaydı girin. Ardından sistemin şu sorulara cevap verip vermediğini kontrol edin:

• Aynı cihaz son 30, 60 veya 90 günde kaç kez arızalandı?
• Arızalar aynı hata türüyle mi kapatıldı?
• Hangi teknisyenler müdahale etti?
• Hangi parçalar kullanıldı?
• İlk bildirim ile teknisyenin varışı arasında ne kadar süre geçti?
• Arıza tekrar oranı teknisyen, model veya bina bazında görülebiliyor mu?
• Kronik arızalı cihazlar kolayca listelenebiliyor mu?
• Önceki fotoğraflara ve servis açıklamalarına sahadan erişilebiliyor mu?

Bu veriler, firma sahibi açısından işçilik ve yol maliyetini; teknisyen açısından teşhis süresini; bina yöneticisi açısından ise hizmet kalitesini doğrudan etkiler. Aynı cihaza kısa aralıklarla yapılan ziyaretler raporlanamıyorsa dijital kayıt tutulsa bile operasyonel öğrenme sınırlı kalır.

Asansorex gibi arıza ve bakım süreçlerini birlikte izleyen bir yazılım, cihazın geçmiş müdahalelerini tek yerde tutarak teknisyenin sahaya daha hazırlıklı gitmesine yardımcı olabilir. Demo sırasında bu geçmişin hem ofisten hem mobil uygulamadan nasıl görüntülendiği canlı olarak denenmelidir.

Raporlama ve Müşteri İletişimini Sınayın

Demo sunumlarında renkli grafikler etkileyici görünebilir. Ancak önemli olan, bu grafiklerin günlük kararlarınızda kullanabileceğiniz verilere dayanmasıdır. Hazır raporlara bakmak yerine kendi sorularınızı sorun ve cevabın sistemden ne kadar sürede çıkarıldığını ölçün.

Firma sahibi veya operasyon sorumlusu için yararlı olabilecek göstergeler şunlardır:

• Aylık toplam arıza sayısı
• Ortalama ilk müdahale süresi
• Ortalama çözüm ve kapanış süresi
• Tekrar arıza oranı
• Teknisyen başına açık ve tamamlanan iş sayısı
• Cihaz başına arıza sıklığı
• Mesai dışı gelen çağrı sayısı
• En sık kullanılan yedek parçalar
• Açık kalan veya geciken işler
• Müşteri, bina ve bölge bazlı arıza dağılımı

Bina yöneticisi tarafında ise teknik ayrıntıların tamamından çok sürecin şeffaflığı önemlidir. Arıza alındığında, teknisyen yola çıktığında ve iş tamamlandığında otomatik bilgilendirme yapılabiliyor mu? Yönetici servis formuna veya geçmiş kayıtlara erişebiliyor mu? Bildirim içeriği firmanın kurumsal diline göre düzenlenebiliyor mu?

Servis formunun PDF çıktısını da mutlaka inceleyin. Firma unvanı, logo, bina bilgisi, asansör kimliği, arıza nedeni, yapılan işlem, kullanılan malzeme, teknisyen bilgisi ve müşteri imzası doğru alanlara yerleşmelidir. PDF’nin telefonda okunabilir ve gerektiğinde yazdırılabilir olması gerekir.

Veri Aktarımı, Güvenlik ve Destek Sorularını Sorun

Demo günü yalnızca özellikleri değil, yazılıma geçiş sürecini de değerlendirin. Yüzlerce bina ve asansör kaydını elle yeniden girmek önemli bir zaman ve hata maliyeti doğurabilir. Mevcut Excel dosyalarının hangi formatta aktarılabildiğini, örnek veri aktarımının kim tarafından yapılacağını ve hatalı kayıtların nasıl düzeltileceğini sorun.

Veri güvenliği konusunda genel ifadeler yerine açık cevaplar isteyin:

• Kullanıcılar görevlerine göre yetkilendirilebiliyor mu?
• Silinen veya değiştirilen kayıtların geçmişi görülebiliyor mu?
• Veriler hangi sıklıkta yedekleniyor?
• Personel işten ayrıldığında erişimi hemen kapatılabiliyor mu?
• Firma kendi verilerini dışarı aktarabiliyor mu?
• Abonelik sona erdiğinde verilerin teslim ve saklama süreci nasıl işliyor?
• Mobil cihaz kaybolduğunda yetkisiz erişime karşı hangi önlemler bulunuyor?
• Planlı bakım ve kesintiler nasıl duyuruluyor?

Teknik destek için “Destek veriyoruz” cevabı yeterli değildir. Destek kanalını, çalışma saatlerini, ortalama dönüş süresini ve acil sorunların nasıl önceliklendirildiğini öğrenin. Kurulum eğitiminin kimlere, kaç oturum halinde verileceğini de netleştirin.

Demo Sonrasında Karar Toplantısı Yapın

Demo bittikten hemen sonra firma sahibi, ofis sorumlusu ve en az bir saha teknisyeni ayrı ayrı skor kartını doldurmalıdır. Puanların toplantı sırasında ortak verilmesi, kıdemli kişinin görüşünün diğer katılımcıları etkilemesine neden olabilir.

Daha sonra sonuçları karşılaştırın. Örneğin firma sahibi raporlamaya 5 puan verirken teknisyen mobil kullanıma 2 puan verdiyse bu fark önemlidir. Yazılım yönetim açısından güçlü görünse de sahada benimsenmeme riski taşıyabilir.

Karar toplantısında şu adımları uygulayın:

1. Her katılımcının puanlarını ayrı ayrı kaydedin.
2. Kriter bazında ortalama puanları hesaplayın.
3. Üç puanın altında kalan alanları listeleyin.
4. Olmazsa olmaz kriterlerdeki eksikleri belirleyin.
5. Demo sırasında cevaplanmayan soruları yazılı olarak sağlayıcıya gönderin.
6. Gerekirse sınırlı kullanıcı veya belirli bir ekip ile pilot çalışma isteyin.
7. Teklif, eğitim, veri aktarımı ve destek kapsamını sözleşmeyle karşılaştırın.
8. Son kararı yalnızca fiyat üzerinden değil, toplam operasyon maliyeti üzerinden verin.

Pilot kullanım yapılabiliyorsa ideal olarak gerçek arıza kayıtlarıyla test gerçekleştirin. Üç günlük kontrollü bir deneme bile teknisyenin kayıt girme alışkanlığını, bildirimlerin doğruluğunu ve raporların kullanılabilirliğini ortaya çıkarabilir.

Sıkça Sorulan Sorular

Asansör arıza yazılımı demosuna kimler katılmalı?

Firma sahibi veya karar vericiyle birlikte arıza çağrılarını karşılayan ofis personeli, operasyon sorumlusu ve en az bir saha teknisyeni katılmalıdır. Çok şubeli firmalarda bir şube temsilcisinin bulunması da farklı çalışma ihtiyaçlarının görülmesini sağlar.

Demo için kaç dakika ayırmak gerekir?

Genel uygulamada 60–90 dakika yeterli olabilir. Ancak veri aktarımı, mobil uygulama, raporlama ve entegrasyonlar ayrıntılı incelenecekse ikinci bir teknik oturum planlamak daha sağlıklıdır. Hızlı bir tanıtım, gerçek kullanım sorunlarını ortaya çıkarmayabilir.

En yüksek puanı alan yazılım mutlaka seçilmeli mi?

Hayır. Toplam puanın yanında firmanızın olmazsa olmaz kriterleri değerlendirilmelidir. Çevrimdışı kullanım, çoklu şube yönetimi veya belirli bir entegrasyon kritikse bu alandaki eksiklik yüksek toplam puandan daha belirleyici olabilir.

Demo sırasında fiyat konuşulmalı mı?

Evet, ancak yalnızca yıllık veya aylık abonelik bedeli sorulmamalıdır. Kurulum, eğitim, veri aktarımı, ilave kullanıcı, SMS, özel rapor, entegrasyon ve destek gibi ek maliyetler de yazılı biçimde istenmelidir.

Hazır sunum izlemek demo için yeterli midir?

Hayır. Gerçek bir arıza kaydı açılmalı, teknisyen atanmalı, mobil uygulamadan işlem yapılmalı ve servis formu oluşturulmalıdır. Canlı senaryo, önceden hazırlanmış ekranlarda görünmeyen kullanım sorunlarını ortaya çıkarır.

Asansorex demosunda hangi süreçler test edilebilir?

Arıza kaydı, teknisyen atama, mobil saha işlemleri, fotoğraf ve imza ekleme, servis formu oluşturma, müşteri bilgilendirme ve cihaz geçmişi gibi günlük süreçler test edilebilir. En sağlıklı sonuç için kendi iş akışınıza benzeyen bir senaryo kullanılmalıdır.

Özet

Asansör arıza yazılımı seçerken demo gününü pasif bir ürün tanıtımı olarak değil, kontrollü bir saha testi olarak planlayın. Gerçek arıza senaryosu kullanın; ofis, teknisyen ve bina yöneticisi açısından bütün adımları inceleyin. Mobil kullanım, tekrar arıza analizi, raporlama, veri aktarımı, güvenlik ve destek kriterlerini 100 puanlık skor kartıyla değerlendirin. Asansorex dahil görüştüğünüz bütün çözümlere aynı soruları yöneltmeniz, etkileyici sunumlarla günlük operasyonunuza gerçekten değer katacak özellikleri birbirinden ayırmanızı sağlar.