Asansör Arıza Yazılımı Demo Senaryoları: Gerçek Süreçlerle Test Rehberi

İÇERİK

Bir asansör arıza yazılımı demosu, yalnızca menüleri gezmek veya birkaç ekran görüntüsüne bakmak için yapılmamalıdır. Gerçek değerlendirme; bina yöneticisinin arıza bildirdiği andan teknisyenin görevi tamamlamasına, kullanılan parçanın kaydedilmesinden tahsilatın işlenmesine kadar bütün sürecin uygulanmasıyla yapılır.

Çünkü bir yazılımın özellik listesinde “arıza yönetimi”, “teknisyen atama” veya “bildirim gönderme” yazması, bu işlemlerin firmanızın günlük çalışma düzenine uygun olduğu anlamına gelmez. Önemli olan; yoğun bir iş gününde arıza kaydının kaybolmaması, doğru teknisyenin hızla yönlendirilmesi, yapılan işlemin kanıtlanabilmesi ve müşteriye doğru bilginin sunulabilmesidir.

Bu rehberde, asansör bakım firmalarının bir demo sırasında mutlaka uygulaması gereken gerçekçi arıza senaryolarını, kontrol noktalarını ve sık yapılan değerlendirme hatalarını bulabilirsiniz.

Demo Öncesinde Gerçek Verilerle Hazırlık Yapın

Demo hesabına rastgele bilgiler girmek, yazılımın gerçek kullanım performansını anlamayı zorlaştırır. Teste başlamadan önce firmanızda sık karşılaşılan birkaç arıza türünü ve örnek müşteri bilgilerini hazırlamanız daha doğru sonuç verir.

Örneğin aşağıdaki test verilerini kullanabilirsiniz:

• Biri yakın, biri uzak bölgede bulunan iki farklı bina
• Mesai içinde görev alan iki teknisyen
• Gece nöbetine kalan bir teknisyen
• “Asansör çalışmıyor” şeklinde genel bir arıza kaydı
• “Katta kaldı” gibi acil müdahale gerektiren bir çağrı
• Parça değişimi ve ücretlendirme gerektiren bir arıza
• Aynı binada kısa süre içinde tekrar eden bir arıza
• Telefonla bildirilen ve QR kod üzerinden gönderilen iki farklı kayıt

Bu hazırlık sayesinde sadece yazılımın nasıl göründüğünü değil, firmanızdaki iş akışının sisteme ne kadar kolay aktarılabildiğini ölçebilirsiniz.

Demo sırasında ideal veriler değil, günlük çalışma koşullarında karşılaştığınız karışık ve eksik bilgiler kullanılmalıdır.

Senaryo 1: Telefonla Gelen Arıza Kaydını Oluşturma

İlk senaryo, bakım firmalarının en sık karşılaştığı durumdur. Bina yöneticisi veya apartman görevlisi firmayı arar ve “Asansör çalışmıyor” der. Arızanın teknik nedeni henüz belli değildir.

Demo sırasında aşağıdaki adımları uygulayın:

1. Müşteriyi veya binayı sistemde bulun.
2. İlgili asansörü seçin.
3. Arıza açıklamasını kaydedin.
4. Bildirimi yapan kişinin adını ve iletişim bilgisini ekleyin.
5. Arızanın öncelik seviyesini belirleyin.
6. Kaydı uygun teknisyene atayın.
7. Teknisyenin cihazına bildirimin ulaşıp ulaşmadığını kontrol edin.

Bu testte dikkat edilmesi gereken temel konu, arıza kaydının ne kadar hızlı oluşturulabildiğidir. Personel her kayıt için uzun formlar doldurmak zorunda kalıyorsa yoğun saatlerde kayıtlar eksik bırakılabilir.

Ayrıca aynı bina adına birden fazla asansör kayıtlıysa doğru cihazın kolayca seçilip seçilemediği kontrol edilmelidir. Yanlış asansöre açılan kayıt; bakım geçmişinin, kullanılan parçaların ve tekrar eden arıza analizlerinin hatalı görünmesine neden olabilir.

Senaryo 2: QR Kodla Arıza Bildirimi

QR kodla arıza bildirimi, özellikle mesai dışı saatlerde ve telefon trafiğinin yoğun olduğu dönemlerde faydalı olabilir. Ancak sistemin yalnızca QR kod üretmesi yeterli değildir. Gönderilen bildirimin firmaya nasıl ulaştığı da test edilmelidir.

Demo sırasında bina yöneticisi rolüne geçerek QR kodu okutun ve aşağıdaki işlemleri gerçekleştirin:

• Arıza açıklaması yazın.
• Bildirim yapan kişinin telefonunu ekleyin.
• Gerekliyse fotoğraf yükleyin.
• Kaydı gönderin.
• Firma tarafında bildirimin oluşma süresini kontrol edin.
• İlgili personele bildirim gidip gitmediğini inceleyin.
• Aynı kişinin peş peşe kayıt açması durumunda sistemin davranışını gözlemleyin.

QR kodla gelen kaydın hangi bina ve hangi asansörle ilişkili olduğu otomatik belirlenmelidir. Kullanıcının bina adı, adres veya cihaz bilgisi gibi detayları tekrar tekrar yazması süreci zorlaştırır.

Ayrıca bina yöneticisinin arıza kaydının alındığını anlayabilmesi önemlidir. “Kaydınız oluşturuldu” şeklinde açık bir sonuç mesajı bulunmayan sistemlerde kullanıcı tekrar telefon açabilir veya aynı arızayı yeniden bildirebilir.

Senaryo 3: Acil Arıza ve Mahsur Kalma Çağrısı

Demo sırasında mutlaka yüksek öncelikli bir çağrı oluşturulmalıdır. Bunun için “kabin katta kaldı” veya “asansörde kişi mahsur kaldı” gibi acil bir senaryo kullanılabilir.

Bu senaryoda amaç, yazılımın teknik kurtarma yöntemlerini öğretmesi değil; operasyonel iletişimi ve görevlendirmeyi doğru yönetip yönetmediğini görmek olmalıdır.

Aşağıdaki noktaları kontrol edin:

Kontrol noktası	Demo sırasında beklenen davranış
Öncelik seviyesi	Acil kayıtların diğer arızalardan belirgin şekilde ayrılması
Bildirim	Nöbetçi veya uygun teknisyene hızlı bildirim gönderilmesi
Atama zamanı	Arızanın hangi saatte ve kim tarafından atandığının kaydedilmesi
Kabul bilgisi	Teknisyenin görevi görüp kabul ettiğinin izlenebilmesi
Varış zamanı	Teknisyenin binaya ulaşma saatinin kaydedilebilmesi
Tamamlama	Yapılan işlemin ve sonucun kayıt altına alınması
Müşteri iletişimi	Gerekli aşamalarda müşteriye bilgi aktarılabilmesi

Demo yöneticisine “Teknisyen bildirimi görmezse ne olur?” sorusunu mutlaka yöneltin. İlk atanan personel çağrıya cevap vermediğinde kaydın fark edilmemesi önemli bir operasyon riskidir.

Yazılım otomatik yönlendirme yapmasa bile, geciken veya kabul edilmeyen görevlerin firma tarafından görünür olması gerekir.

Senaryo 4: Teknisyenin Sahadan Arızayı Sonuçlandırması

Bir arıza yazılımının gerçek değeri, saha personelinin sistemi kolay kullanabilmesiyle ortaya çıkar. Ofis tarafındaki ekranlar ne kadar kapsamlı olursa olsun, teknisyen görevi sahadan kapatamıyorsa kayıtlar gün sonunda eksik kalır.

Demo sırasında teknisyen hesabıyla giriş yaparak şu adımları uygulayın:

1. Atanan görevi açın.
2. Müşteri ve bina bilgilerini görüntüleyin.
3. Adrese ulaşmak için konum veya yol tarifi seçeneğini kullanın.
4. Arızanın nedenini kaydedin.
5. Yapılan müdahaleyi açıklayın.
6. Kullanılan parçayı veya malzemeyi ekleyin.
7. Öncesi ve sonrası fotoğrafı yükleyin.
8. Gerekliyse müşteri imzası alın.
9. Görevi tamamlayın.
10. Ofis tarafında kaydın güncellenip güncellenmediğini kontrol edin.

Teknisyenin uzun açıklamalar yazmak zorunda kalması sahadaki kullanım oranını düşürebilir. Sık kullanılan arıza nedenleri ve çözüm türleri hazır seçeneklerden seçilebiliyorsa kayıt kalitesi artar. Ancak yalnızca hazır seçenek kullanılması da yeterli değildir; teknisyenin gerektiğinde açıklama ekleyebilmesi gerekir.

Asansorex gibi saha ve arıza süreçlerini birlikte yöneten yazılımlar değerlendirilirken, teknisyenin arıza kaydını mobil cihazdan kaç adımda tamamladığı özellikle test edilmelidir. Sahadaki işlem ne kadar sade olursa kayıtların zamanında kapatılması o kadar kolaylaşır.

Senaryo 5: Parça Değişimi ve Tahsilat Kaydı

Her arıza yalnızca teknik müdahaleyle bitmez. Bazı durumlarda kontaktör, buton, fotosel, kilit parçası veya farklı bir malzeme değiştirilebilir. Bu işlem müşteriye ücretli sunuluyorsa teknik kayıt ile finansal kayıt arasında bağlantı kurulmalıdır.

Demo için örnek olarak ücretli bir fotosel değişimi senaryosu oluşturabilirsiniz.

Kontrol edilmesi gereken noktalar şunlardır:

• Kullanılan parça arıza kaydına eklenebiliyor mu?
• Parçanın miktarı ve satış bedeli yazılabiliyor mu?
• Kullanılan ürün stoktan düşüyor mu?
• Teknisyen tahsilat aldıysa bunu kaydedebiliyor mu?
• Nakit, kredi kartı veya banka transferi gibi ödeme türleri ayrılabiliyor mu?
• Müşteri bakiyesi güncelleniyor mu?
• İşlem sonrasında servis formu veya belge oluşturulabiliyor mu?

Burada amaç yalnızca muhasebe işlemi yapmak değildir. Arızada kullanılan parçanın kaydedilmesi, aynı cihazın maliyetini ve arıza geçmişini değerlendirmek açısından da önemlidir.

Örneğin bir asansörde altı ay içinde üç kez aynı parçanın değiştirildiği görülüyorsa sorun yalnızca parçadan kaynaklanmıyor olabilir. Montaj, ayar, elektrik kalitesi veya farklı bir bileşen ayrıca incelenebilir.

Senaryo 6: Tekrar Eden Arızanın Tespit Edilmesi

Asansör bakım firmalarının müşteri memnuniyetini en fazla etkileyen konulardan biri tekrar eden arızalardır. Aynı binadan kısa aralıklarla çağrı gelmesi, müşteride “Arıza tam çözülmedi” algısı oluşturabilir.

Demo sırasında aynı asansör için önceki kayda benzer ikinci bir arıza oluşturun. Ardından şu soruların cevaplarını arayın:

• Teknisyen önceki arıza kayıtlarını görebiliyor mu?
• Daha önce hangi işlemlerin yapıldığı görülebiliyor mu?
• Kullanılan parçalar listeleniyor mu?
• Önceki fotoğraflara erişilebiliyor mu?
• Aynı arıza türünün tekrarlandığı raporlanabiliyor mu?
• İlk müdahaleyi yapan teknisyen bilgisi bulunabiliyor mu?

Geçmiş kayıtların yalnızca ofis çalışanları tarafından görülebilmesi yeterli olmayabilir. Yetki sınırları korunarak teknisyenin de cihaz geçmişine ulaşabilmesi, aynı kontrollerin tekrar yapılmasını önler.

Ayrıca arızaların sadece “açık” ve “kapalı” olarak tutulması analiz için yetersizdir. Arıza nedeni, yapılan işlem, kullanılan parça ve sonuç bilgileri düzenli tutulmalıdır.

Senaryo 7: İnternet Bağlantısının Zayıf Olduğu Bina

Makine dairesi, bodrum kat veya asansör kuyusuna yakın alanlarda internet bağlantısı zayıf olabilir. Bu nedenle demo yalnızca güçlü ofis internetiyle yapılmamalıdır.

Telefonun mobil verisini kısa süreli kapatarak veya zayıf bağlantı koşulu oluşturarak aşağıdaki işlemleri deneyin:

• Arıza kaydını açma
• Görev detaylarını görüntüleme
• Açıklama ekleme
• Fotoğraf yükleme
• İmza alma
• Görevi tamamlama

Yazılım tamamen çevrim dışı çalışmak zorunda olmayabilir. Ancak bağlantı kesildiğinde girilen bilgilerin kaybolup kaybolmadığı açıkça öğrenilmelidir. Fotoğraf yüklenemediğinde sistem kullanıcıyı uyarmalı, işlemi tamamlanmış gibi göstermemelidir.

Demo sırasında şu soruyu sorun: “Teknisyen formu doldurduktan sonra internet kesilirse bilgiler cihazda korunuyor mu?”

Demo Sonunda Ölçülmesi Gereken Sonuçlar

Senaryolar tamamlandıktan sonra yalnızca “özellik var mı?” değerlendirmesi yapmayın. İşlemlerin ne kadar kolay ve izlenebilir olduğunu puanlayın.

Her başlığa 1 ile 5 arasında puan verebilirsiniz:

• Arıza kaydı oluşturma hızı
• Bina ve asansör seçme kolaylığı
• Teknisyen atama süresi
• Bildirimlerin anlaşılır olması
• Mobil kullanım kolaylığı
• Fotoğraf ve imza ekleme
• Parça ve tahsilat kaydı
• Geçmiş arızalara erişim
• Raporların anlaşılabilirliği
• Yetki ve veri güvenliği
• İnternet kesintisindeki davranış
• Destek ekibinin sorulara verdiği cevaplar

Bir yazılım çok sayıda özellik sunabilir ancak teknisyenlerin kullanamadığı, ofisin takip edemediği veya müşteriye kanıt sunamadığı bir sistem operasyonu iyileştirmez.

Demo Sırasında Yapılan Yaygın Hatalar

En sık yapılan hata, yalnızca yazılımı sunan kişinin hazırladığı örnek akışı izlemektir. Bu durumda genellikle ideal koşullar gösterilir ve sorun çıkabilecek noktalar test edilmez.

Kaçınılması gereken diğer hatalar şunlardır:

• Gerçek teknisyeni demoya dahil etmemek
• Mobil uygulamayı denemeden karar vermek
• Aynı arızayı iki farklı kullanıcıyla test etmemek
• Acil çağrı senaryosu oluşturmamak
• Parça ve tahsilat sürecini atlamak
• Tekrar eden arıza geçmişini incelememek
• Fotoğraf yükleme hızını test etmemek
• Müşteriye giden bildirimleri kontrol etmemek
• İnternet kesintisini denememek
• Destek ve eğitim sürecini sormamak

En doğru değerlendirme için demo oturumuna firma sahibi veya operasyon sorumlusuyla birlikte en az bir saha teknisyeninin katılması faydalıdır. Firma sahibi raporlama ve kontrol tarafına, teknisyen ise günlük kullanım kolaylığına odaklanır.

Sıkça Sorulan Sorular

Asansör arıza yazılımı demosu ne kadar sürmelidir?

Sadece genel tanıtım için 30–45 dakika yeterli olabilir. Ancak gerçek arıza senaryoları, mobil kullanım, fotoğraf, tahsilat ve raporlama birlikte test edilecekse daha kapsamlı bir çalışma yapılmalıdır. Süreden çok, kritik iş akışlarının tamamlanması önemlidir.

Demo sırasında kendi müşteri bilgilerimizi kullanmalı mıyız?

Gerçek kişisel verileri paylaşmak yerine temsili bina, müşteri ve teknisyen bilgileri kullanmak daha güvenlidir. Ancak örnekler firmanızın gerçek çalışma düzenine, bina sayısına ve arıza türlerine benzemelidir.

Mobil uygulamayı teknisyenlerin denemesi gerekli mi?

Evet. Arıza yönetiminin büyük bölümü sahada gerçekleştiği için uygulamayı sadece ofis personelinin incelemesi yeterli değildir. En az bir teknisyen görevi kabul etmeli, fotoğraf eklemeli ve arıza kaydını tamamlamalıdır.

Demo hesabına toplu veri yüklemek gerekir mi?

İlk değerlendirmede birkaç bina ve asansör kaydı yeterlidir. Ancak satın alma kararı yaklaşmışsa mevcut müşteri, cihaz ve bakım bilgilerinin sisteme nasıl aktarılacağı mutlaka sorulmalıdır.

Demo sonunda hangi raporlar kontrol edilmelidir?

Açık arızalar, teknisyen bazlı görevler, müdahale süreleri, tekrar eden arızalar, kullanılan parçalar ve tamamlanan işler kontrol edilmelidir. Firmanın ihtiyacına göre tahsilat ve müşteri bakiyesi raporları da incelenebilir.

En fazla özelliğe sahip yazılım en iyi seçim midir?

Hayır. En iyi yazılım, firmanızın temel süreçlerini kolaylaştıran ve ekibin düzenli kullanabildiği yazılımdır. Kullanılmayan çok sayıda özellik yerine doğru çalışan arıza, bakım, saha ve finans akışları daha değerlidir.

Özet

Bir asansör arıza yazılımı demosu, hazır ekranların izlendiği bir ürün sunumu olarak görülmemelidir. Telefonla gelen bildirim, QR kod kaydı, acil çağrı, teknisyen atama, saha müdahalesi, fotoğraflı kapanış, parça değişimi, tahsilat ve tekrar eden arıza gibi gerçek senaryolar uygulanmalıdır.

Demo sonunda şu soruya net cevap verebilmelisiniz: “Bu sistem, arıza bildirildiği andan işlem tamamlanana kadar hiçbir bilginin kaybolmadan ilerlemesini sağlıyor mu?”

Asansorex değerlendirilirken de aynı yöntem izlenebilir. Firmanızda sık yaşanan birkaç arıza örneğini sisteme girerek ofis, teknisyen ve müşteri tarafındaki süreci baştan sona test etmek, satın alma kararını yalnızca özellik listesine göre vermekten daha sağlıklı sonuç sağlar.