Asansör Arıza Çağrı Programı Demo Günü Skor Kartı

İÇERİK

Asansör bakım firmaları için yapılan yazılım demoları çoğu zaman etkileyici ekranların hızla gösterildiği bir sunuma dönüşür. Ancak güzel görünen bir ekran, arıza çağrısının doğru teknisyene atanacağını, müşterinin zamanında bilgilendirileceğini veya tekrar arızaların analiz edilebileceğini garanti etmez. Bu nedenle Asansör Arıza Çağrı Programı demosuna yalnızca izleyici olarak değil, önceden hazırlanmış bir skor kartıyla katılmak gerekir.

Demo günü skor kartı; firma sahibinin, operasyon sorumlusunun ve teknisyenin aynı yazılımı ortak kriterlerle değerlendirmesini sağlar. Böylece karar, “ekranları beğendik” gibi kişisel bir izlenime değil; hız, kullanım kolaylığı, raporlama, saha uyumu ve müşteri iletişimi gibi ölçülebilir sonuçlara dayanır. Bu rehberde demo öncesinde hazırlanması gereken senaryoyu, sorulacak kritik soruları ve 100 puan üzerinden kullanılabilecek örnek değerlendirme tablosunu bulabilirsiniz.

Demo Öncesinde Gerçek Bir Arıza Senaryosu Hazırlayın

Yazılım firmasının kendi hazırladığı kusursuz örnekleri izlemek yeterli değildir. Demo sırasında sizin günlük operasyonunuza benzeyen bir arıza kaydının baştan sona işletilmesini isteyin. Kullanılacak bina, asansör, müşteri ve teknisyen bilgilerini önceden belirleyin.

Örnek demo senaryosu şöyle olabilir:

Saat 18.20’de bir apartman yöneticisi, asansörün üçüncü katta kaldığını ve kapının açılmadığını bildiriyor. Binada iki asansör var. Arızalı cihazın bakım sözleşmesi devam ediyor. Görevlendirilen teknisyen başka bir arızada çalışıyor ve internet bağlantısının zayıf olduğu bir bölgede bulunuyor.

Programın bu çağrıyı nasıl yönettiğini adım adım izleyin:

1. Müşteri telefon numarasıyla tanınıyor mu?
2. Doğru bina ve asansör kolayca seçilebiliyor mu?
3. Arıza açıklaması, önceliği ve ihbar saati kaydedilebiliyor mu?
4. Uygun teknisyen görülebiliyor ve görevlendirilebiliyor mu?
5. Teknisyene mobil bildirim ulaşıyor mu?
6. Teknisyen “yola çıktı”, “ulaştı” ve “tamamlandı” durumlarını işaretleyebiliyor mu?
7. Kullanılan malzeme, yapılan işlem, fotoğraf ve müşteri imzası kaydedilebiliyor mu?
8. İşlem tamamlandığında müşteri bilgilendiriliyor mu?
9. Servis formu veya arıza raporu oluşturulabiliyor mu?
10. Aynı asansörün önceki arızaları görüntülenebiliyor mu?

Bu senaryo sırasında sunumu yapan kişinin sistemi nasıl kullandığı kadar, işlemlerin kaç adım sürdüğünü de not edin. Basit bir arıza kaydı için çok fazla ekran değiştirmek gerekiyorsa günlük kullanımda çağrı merkezi ve saha ekibi zorlanabilir.

100 Puanlık Demo Günü Skor Kartı

Her kriterin operasyon üzerindeki etkisi aynı değildir. Örneğin ekran renkleri veya görsel tercihler önemli olsa da teknisyene çevrim dışı erişim, arıza geçmişi ve işlem zamanlarının kaydedilmesi kadar kritik değildir. Bu nedenle puanlamada ağırlıklı bir yöntem kullanılmalıdır.

Her kriteri 1 ile 5 arasında puanlayabilirsiniz:

• 1 puan: Özellik yok veya kullanılamayacak kadar yetersiz
• 2 puan: Kısmen var, önemli geliştirme ya da ek işlem gerekiyor
• 3 puan: Temel ihtiyacı karşılıyor
• 4 puan: İhtiyacı iyi karşılıyor ve kullanımı kolay
• 5 puan: İhtiyacı eksiksiz karşılıyor, sahada uygulanabilir

Değerlendirme alanı	Ağırlık	Kontrol edilecek temel konu
Arıza kaydı oluşturma hızı	15	Müşteri, bina ve cihazın hızlı bulunması
Teknisyen atama ve durum takibi	15	Atama, bildirim ve iş durumu değişiklikleri
Mobil saha kullanımı	15	Fotoğraf, imza, açıklama ve internet kesintisinde çalışma
Arıza geçmişi ve tekrar arıza analizi	15	Aynı cihazdaki arızaların karşılaştırılması
Müşteri bilgilendirme	10	Bildirim, servis durumu ve rapor paylaşımı
Raporlama ve performans ölçümü	10	Müdahale süresi, kapanma süresi ve teknisyen iş yükü
Form ve çıktı yönetimi	8	Servis formu, PDF ve termal çıktı seçenekleri
Kullanım kolaylığı	7	Eğitim ihtiyacı, menü sadeliği ve işlem adımı
Veri güvenliği ve yetkilendirme	5	Kullanıcı rolleri, kayıt geçmişi ve erişim kontrolü
Toplam	100	Genel uygunluk puanı

Ağırlıklı puanı hesaplamak için verilen 1–5 puanı beşe bölüp kriter ağırlığıyla çarpabilirsiniz. Örneğin mobil saha kullanımı 4 puan aldıysa sonuç 4 / 5 x 15 = 12 olur.

Genel değerlendirmede aşağıdaki aralıklar kullanılabilir:

• 85–100 puan: Operasyon ihtiyacını güçlü biçimde karşılıyor.
• 70–84 puan: Kullanılabilir; eksik kalan maddeler yazılı olarak netleştirilmeli.
• 55–69 puan: Önemli operasyonel boşluklar bulunuyor.
• 54 puan ve altı: Günlük işleyişe uyum sağlamama riski yüksek.

Toplam puan tek başına yeterli değildir. Çevrim dışı çalışma veya arıza geçmişi gibi sizin için vazgeçilmez bir özellik bulunmuyorsa yazılım yüksek toplam puan alsa bile uygun olmayabilir.

Arıza Kaydı ve Çağrı Yönetiminde Neler Ölçülmeli?

Bir Asansör Arıza Çağrı Programı, çağrıyı yalnızca dijital bir forma kaydetmemelidir. Arızanın alınmasından kapatılmasına kadar bütün süreci izlenebilir hâle getirmelidir.

Demo sırasında süre tutarak yeni bir çağrı oluşturun. Müşteri daha önce kayıtlıysa telefon numarası veya ünvanla bulunabilmeli; müşteriye bağlı bina ve asansör bilgileri yeniden yazılmamalıdır. Binada birden fazla cihaz varsa yanlış asansör seçilmesini önleyecek açık tanımlamalar bulunmalıdır.

Şu alanların kaydedilip kaydedilemediğini kontrol edin:

• Arıza ihbar tarihi ve saati
• İhbarı yapan kişinin adı ve iletişim bilgisi
• Bina ve asansör bilgisi
• Arıza açıklaması
• Aciliyet veya öncelik seviyesi
• Atanan teknisyen ya da ekip
• Atama, yola çıkış, varış ve tamamlanma saatleri
• Yapılan işlem ve kullanılan malzemeler
• Fotoğraf, belge ve müşteri imzası
• Arızanın açık, beklemede veya tamamlandı durumu
• Tekrar ziyaret ya da parça bekleme bilgisi

Arızayı kapatmadan önce zorunlu alanların kontrol edilmesi de önemlidir. Teknisyen hiçbir açıklama yazmadan işi tamamlayabiliyorsa ileride müşteri itirazı veya tekrar arıza yaşandığında yeterli kayıt bulunamayabilir.

Mobil Uygulamayı Teknisyenin Kendisi Denesin

Masaüstünde başarılı görünen bir program, sahada aynı kolaylığı sunmayabilir. Bu nedenle demoya en az bir teknisyen katılmalı ve mobil uygulamayı sunumu yapan kişi yerine teknisyen kullanmalıdır.

Teknisyenden aşağıdaki işlemleri yardım almadan yapmasını isteyin:

1. Kendisine atanan arızayı açması
2. Adrese yol tarifi başlatması
3. “Yola çıktı” veya benzeri durumu seçmesi
4. Arıza açıklamasını ve geçmiş kayıtları incelemesi
5. Fotoğraf eklemesi
6. Kullanılan parçayı kaydetmesi
7. Müşteri imzası alması
8. Servis formunu tamamlaması
9. Arızayı kapatması

Her adımın kaç dokunuş gerektirdiğini ve teknisyenin nerede zorlandığını not edin. Eldivenle çalışma, küçük telefon ekranı, güneş altında görünürlük ve zayıf internet bağlantısı gibi gerçek saha koşulları dikkate alınmalıdır.

Çevrim dışı kullanım iddiası varsa yalnızca sözlü açıklamayla yetinmeyin. Telefonun internet bağlantısını kapatın, örnek bir kayıt oluşturun ve bağlantı geri geldiğinde verilerin doğru biçimde eşitlenip eşitlenmediğini kontrol edin. Fotoğraf veya imza kaybı yaşanması, sahadaki hizmet kanıtını doğrudan etkiler.

Tekrar Arıza ve Müdahale Süresi Raporlarını İnceleyin

Arıza yazılımının asıl değeri, biriken kayıtları karar vermek için kullanılabilir bilgiye dönüştürmesidir. Demo sırasında yalnızca “raporlama modülümüz var” ifadesini kabul etmeyin. Belirli sorular sorun ve yanıtın ekrandan gösterilmesini isteyin.

Program şu sorulara yanıt verebilmelidir:

• Bu ay en fazla arıza veren asansörler hangileri?
• Aynı arıza türü belirli bir cihazda kaç defa tekrarlandı?
• Ortalama ilk müdahale süresi nedir?
• Arızaların ortalama kapanma süresi ne kadardır?
• Hangi arızalar parça beklediği için açık kalmıştır?
• Teknisyenlerin açık iş sayıları nedir?
• Mesai dışındaki arıza yoğunluğu hangi gün ve saatlerde artmaktadır?
• Belirli bir müşteri veya bina için geçmiş servis kayıtları nelerdir?

Tekrar arıza analizi yapılırken yalnızca toplam arıza sayısına bakılmamalıdır. Kapı kilidi, fotosel, kontaktör, seviyeleme veya kullanıcı kaynaklı çağrı gibi arıza nedenlerinin sınıflandırılabilmesi gerekir. Serbest metinle yazılan dağınık açıklamalar sağlıklı rapor üretmeyi zorlaştırır.

Bu kayıtları kâğıt formlar veya farklı mesajlaşma grupları yerine Asansorex gibi merkezi bir bakım ve arıza takip yazılımında tutmak, cihaz geçmişinin incelenmesini ve tekrar eden problemlerin daha erken fark edilmesini kolaylaştırır.

Müşteri İletişimi ve Servis Kanıtını Test Edin

Apartman veya bina yöneticisi açısından önemli olan yalnızca arızanın kayda alınması değildir. Çağrının firmaya ulaşıp ulaşmadığını, teknisyenin ne zaman geleceğini ve hangi işlemin yapıldığını bilmek ister.

Demo sırasında müşteri bilgilendirme adımlarını kontrol edin. Arıza kaydı açıldığında, teknisyen yola çıktığında veya işlem tamamlandığında bildirim gönderilebiliyor mu? Hangi bildirimlerin otomatik, hangilerinin isteğe bağlı olduğu anlaşılmalıdır. SMS gibi ücretli servislerin lisans fiyatına dahil olup olmadığını ayrıca sorun.

Tamamlanan işin sonunda oluşan servis raporunda şu bilgilerin bulunması faydalıdır:

• Firma ve müşteri bilgileri
• Bina ve asansör tanımı
• İhbar ve müdahale zamanları
• Bildirilen arıza
• Yapılan işlem
• Değiştirilen veya kullanılan parçalar
• Öncesi ve sonrası fotoğraflar
• Teknisyen bilgisi
• Müşteri adı ve imzası
• Varsa takip önerisi

Oluşturulan PDF’nin hem telefonda hem bilgisayarda okunabilirliğini inceleyin. Firma logosu, iletişim bilgileri ve açıklama alanları düzgün görünmelidir. Termal yazıcı kullanılıyorsa demo sırasında gerçek cihazdan örnek çıktı alınması en doğru kontroldür.

Demo Sonunda Sorulması Gereken Ticari Sorular

Teknik yeterlilik kadar satın alma koşulları da skor kartına yazılmalıdır. İlk teklif uygun görünse bile kullanıcı, cihaz, şube veya SMS sınırları toplam maliyeti değiştirebilir.

Demo bitmeden şu sorulara yazılı yanıt alın:

• Lisans hangi kullanıcı, asansör veya şube sınırlarını içeriyor?
• Mobil uygulama için ayrıca ücret alınıyor mu?
• Kurulum, eğitim ve veri aktarımı fiyata dahil mi?
• SMS, e-posta ve diğer bildirimlerin maliyeti nedir?
• Mevcut müşteri ve cihaz kayıtları nasıl aktarılacak?
• Güncellemeler ve teknik destek hangi kapsamda sunuluyor?
• Yeni özellikler için ek ücret isteniyor mu?
• Sözleşme sona erdiğinde veriler hangi formatta alınabiliyor?
• Yedekleme ve veri saklama yöntemi nedir?
• İptal ve yenileme koşulları nelerdir?

Satın alma kararını demo günü vermek zorunda değilsiniz. Skor kartlarını toplantıdan sonra karşılaştırın. Eksik görülen özelliklerin mevcut olup olmadığını, geliştirme planında mı bulunduğunu veya ek ücretle mi sunulduğunu yazılı olarak doğrulayın. “Yakında yapılacak” şeklindeki sözlü vaatleri mevcut özellik gibi puanlamayın.

Kırmızı Çizgiler ve Eleme Kriterleri Belirleyin

Bazı eksikler düşük puanla geçiştirilemeyecek kadar önemlidir. Firma, demo öncesinde kendi eleme kriterlerini belirlemelidir.

Genel uygulamada şu durumlar ciddi risk işaretidir:

• Arıza atamalarının teknisyene anlık ulaşmaması
• İşlem zamanlarının sonradan değiştirildiğinin izlenememesi
• Aynı asansörün geçmiş arızalarının görülememesi
• Mobil uygulamanın zayıf bağlantıda kullanılamaması
• Yetkisiz kullanıcıların tüm müşteri ve finans bilgilerine erişebilmesi
• Kapanan arızada açıklama veya servis kanıtı bulunmaması
• Verilerin dışarı aktarılamaması
• Yedekleme ve destek süreçlerinin net açıklanmaması
• Demo verisi dışında gerçek bir senaryonun çalıştırılamaması

Bir program 100 üzerinden 80 puan alabilir; ancak firmanın faaliyet gösterdiği bölgede internet sık sık kesiliyorsa ve çevrim dışı çalışma bulunmuyorsa bu toplam puan yanıltıcıdır. Skor kartı, operasyonun gerçek öncelikleriyle birlikte yorumlanmalıdır.

Sıkça Sorulan Sorular

Demo günü kaç kişi katılmalıdır?

En az firma sahibi veya karar verici, arıza çağrılarını yöneten ofis çalışanı ve bir saha teknisyeni katılmalıdır. Böylece ticari, operasyonel ve saha ihtiyaçları aynı toplantıda değerlendirilebilir.

Tek bir demo satın alma kararı için yeterli midir?

Genellikle hayır. İlk demo genel uygunluğu anlamak için kullanılabilir. Ardından gerçek firma verilerine benzeyen örneklerle ikinci bir uygulamalı görüşme veya deneme süreci yapılması daha sağlıklı sonuç verir.

Demo sırasında en önemli performans ölçütü nedir?

Tek bir ölçüt seçilecekse arızanın ihbar alınmasından tamamlanmasına kadar bütün sürecin kesintisiz izlenebilmesi öne çıkar. Bunun yanında ilk müdahale süresi ve tekrar arıza oranı mutlaka raporlanabilmelidir.

Deneme hesabında hangi veriler kullanılmalıdır?

Gerçek kişisel veriler yerine temsili müşteri, bina, asansör ve teknisyen kayıtları kullanılabilir. Ancak örneklerin firmanın gerçek operasyon yapısına, şube sayısına ve iş yoğunluğuna benzemesi gerekir.

En yüksek puanı alan program mutlaka seçilmeli mi?

Hayır. Toplam puanın yanında kırmızı çizgiler, kullanım maliyeti, veri aktarımı, destek kalitesi ve firmanın büyüme planı değerlendirilmelidir. Kritik bir özellik yoksa yüksek puan tek başına yeterli olmaz.

Asansorex demo sırasında nasıl değerlendirilebilir?

Asansorex demosunda örnek bir arıza çağrısının oluşturulması, teknisyene atanması, sahada tamamlanması ve raporlanması istenebilir. Aynı skor kartının tüm aday yazılımlara uygulanması, karşılaştırmanın daha tarafsız yapılmasını sağlar.

Özet

Asansör Arıza Çağrı Programı seçimi, ekran tasarımına veya sunumdaki anlatıma göre yapılmamalıdır. Demo günü; gerçek bir arıza senaryosu, teknisyen katılımı, süre ölçümü ve ağırlıklı skor kartıyla yürütülmelidir. Arıza kaydı, saha kullanımı, tekrar arıza analizi, müşteri bilgilendirme, raporlama ve veri güvenliği ayrı ayrı test edilmelidir.

En doğru yazılım, en fazla özelliği gösteren değil; çağrının alınmasından servis kanıtının oluşturulmasına kadar firmanın günlük işleyişini en az ek yükle yöneten çözümdür. Hazırlanan skor kartını Asansorex dahil değerlendirdiğiniz bütün seçeneklerde aynı biçimde kullanmak, satın alma kararını kişisel izlenimlerden çıkarıp ölçülebilir bir iş kararına dönüştürür.