Asansör Arıza Takip Programı alırken kaçırılan özellikler

İÇERİK

Bir asansör arıza takip programı satın alırken ilk bakılan özellikler genellikle arıza kaydı oluşturma, teknisyen atama ve arızayı kapatma olur. Bunlar elbette gereklidir; ancak günlük operasyonda asıl farkı çoğu zaman ürün demosunda birkaç dakikada fark edilmeyen ayrıntılar yaratır. Arızanın kimin üzerinde kaldığı, teknisyenin olay yerine ne zaman ulaştığı, hangi işlemi yaptığı, müşteriye bilgi verilip verilmediği, aynı asansörde benzer arızanın kaç kez tekrarlandığı veya kaydın eksik kapatılıp kapatılamadığı gibi konular birkaç ay sonra ciddi operasyon sorunlarına dönüşebilir.

Bu nedenle yazılım seçerken yalnızca "arıza kaydı açılıyor mu?" sorusuna değil, arızanın ilk çağrıdan kesin çözüme kadar nasıl yönetildiğine bakmak gerekir. Aşağıdaki noktalar, özellikle büyüyen asansör bakım firmalarının yazılım satın alma sürecinde sıkça ikinci planda bıraktığı özellikleri gösterir.

1. Arızanın Sahiplenilmesi ve Sorumluluğun Net Olması

Bir müşteriden arıza çağrısı geldiğinde kayıt açılması tek başına yeterli değildir. Asıl önemli soru, o kaydın o andan itibaren kimin sorumluluğunda olduğunun açıkça görülebilmesidir.

Örneğin bir bina yöneticisi saat 10.15'te "asansör çalışmıyor" diyerek firmayı aradı. Ofis personeli kaydı oluşturdu fakat teknisyen henüz atanmadı. Birkaç farklı personelin aynı ekranı gördüğü bir yapıda herkes diğer kişinin ilgilendiğini düşünebilir. Sonuçta iki saat boyunca kimsenin müdahale etmediği bir kayıt ortaya çıkabilir.

İyi bir arıza takip sisteminde şu aşamalar birbirinden ayrılabilmelidir:

1. Arıza çağrısı alındı.
2. Kayıt oluşturuldu.
3. Sorumlu kişi veya ekip belirlendi.
4. Teknisyen görevlendirildi.
5. Teknisyen görevi kabul etti.
6. Müdahale başladı.
7. İşlem tamamlandı veya parça beklemeye alındı.
8. Arıza tamamen kapatıldı.

Bu ayrım özellikle aynı anda onlarca açık arızanın bulunduğu firmalarda önemlidir. "Açık" şeklindeki tek bir durum etiketi, operasyon yöneticisine yeterli bilgi vermez. Kaydın neden açık olduğunu görebilmek gerekir.

2. Arıza Kapatılırken Zorunlu Bilgi Toplanması

Satın alma sırasında en çok gözden kaçan konulardan biri arıza kapatma disiplinidir. Birçok sistemde teknisyen yalnızca "tamamlandı" butonuna basarak kaydı kapatabilir. İlk bakışta hız kazandıran bu yapı, birkaç ay sonra şirketin arıza geçmişini kullanılamaz hale getirebilir.

Teknisyen arıza kapatırken en azından yapılan işlem, arıza nedeni ve gerekiyorsa kullanılan parça gibi bilgileri girmelidir. Firmanın çalışma şekline göre fotoğraf, müşteri onayı, açıklama veya tahsilat bilgisi de sürece eklenebilir.

Örneğin geçmiş kayıtlarda yalnızca şu açıklamalar bulunuyorsa:

arıza giderildi

çalışıyor

tamamlandı

bu kayıtların yönetim açısından değeri çok düşüktür. Buna karşılık "kapı kilidi temassızlığı giderildi, kilit ayarı yapıldı, üç kez test edildi" şeklindeki bir kayıt hem teknik geçmiş oluşturur hem de sonraki teknisyene bilgi verir.

Arıza takip programı demosunda bu nedenle şu soruyu mutlaka sorun: Teknisyen gerekli bilgileri girmeden arızayı kapatabiliyor mu?

3. Tekrar Eden Arızaların Otomatik Olarak Görülebilmesi

Bir asansörün ay içinde beş kez arızalanması ile beş farklı asansörün birer kez arızalanması aynı şey değildir. Toplam arıza sayısı aynı görünse bile teknik ve ticari anlamı tamamen farklıdır.

İyi bir asansör arıza programı, bina ve asansör bazında geçmiş kayıtları kolayca göstermelidir. Böylece teknisyen yeni bir çağrıya giderken önceki müdahaleleri görebilir.

Örneğin aynı asansörde sürekli şu kayıtlar oluşuyorsa:

• Kapı açılmıyor.
• Kat kapısı kilit hatası.
• Kapı devresi kesiliyor.
• Kapı kapanmadan cihaz hareket etmiyor.

Sorunlar farklı açıklamalarla kaydedilmiş olsa bile aynı teknik bölgeye işaret ediyor olabilir. Bu veri görünür hale geldiğinde firma geçici müdahaleler yerine kalıcı çözüm üzerinde çalışabilir.

Tekrar eden arıza analizi ayrıca müşteri görüşmelerinde de önemlidir. Bina yöneticisi "bu asansör sürekli arızalanıyor" dediğinde tahmine dayalı cevap vermek yerine son üç veya altı aylık kayıtlar üzerinden konuşabilirsiniz.

4. Bildirimler ve Müşteri Bilgilendirme Süreci

Asansör arızasında müşterinin en sık sorduğu soru genellikle "Teknisyen geliyor mu?" olur. Arızanın teknik olarak birkaç saat içinde çözülmesi önemli olsa da bu süre boyunca müşterinin hiçbir bilgi almaması memnuniyetsizliği artırabilir.

Bu nedenle yazılım seçiminde yalnızca iç ekip bildirimlerine değil, müşteriye gönderilebilecek durum bilgilendirmelerine de bakılmalıdır.

Örneğin sistem şu aşamalarda bilgilendirme yapılmasını destekleyebilir:

• Arıza kaydı oluşturulduğunda,
• Teknisyen görevlendirildiğinde,
• Müdahale tamamlandığında,
• Arıza parça beklemeye alındığında,
• İşlem tamamen kapatıldığında.

Burada amaç müşteriye gereksiz mesaj göndermek değildir. Ama kritik aşamaları otomatik veya kontrollü biçimde bildirmek, ofisin "Teknisyen çıktı mı?", "Arıza yapıldı mı?" gibi telefonlarla sürekli meşgul olmasını azaltabilir.

Asansorex gibi saha ve arıza süreçlerini aynı sistemde yöneten çözümlerde arıza kaydı, teknisyen görevlendirmesi ve müşteri bilgilendirmesinin birbirinden kopuk tutulmaması bu nedenle önemlidir.

5. Konum, Zaman Damgası ve Gerçek Müdahale Süresinin Ölçülmesi

Bir arıza takip programının raporunda "arıza 45 dakikada çözüldü" yazması tek başına yeterli değildir. Bu sürenin hangi zamanlar arasındaki farktan hesaplandığını bilmek gerekir.

Örneğin aşağıdaki zamanların ayrı ayrı kayıt altına alınması oldukça değerlidir:

Kayıt noktası	Neyi gösterir?	Yönetim açısından faydası
Çağrının alınma saati	Müşterinin ilk bildirim zamanı	Gerçek bekleme süresini ölçer
Teknisyen atama zamanı	Ofisin reaksiyon süresi	Planlama performansını gösterir
Görevin kabul zamanı	Teknisyenin işi gördüğü an	İletişim gecikmelerini ortaya çıkarır
Sahaya varış zamanı	Gerçek müdahale başlangıcı	Müdahale süresini ölçmeye yardımcı olur
Arıza kapanış zamanı	İşin tamamlandığı an	Toplam çözüm süresini gösterir

Konum bilgisinin kullanıldığı sistemlerde ise firmanın bunu çalışan bilgilendirmesi, yetkilendirme ve ilgili veri koruma yükümlülükleri çerçevesinde yönetmesi gerekir. Ama operasyon tarafında bakıldığında, teknisyenin hangi bölgede bulunduğunu görebilmek özellikle acil arızalarda daha doğru görevlendirme yapılmasına yardımcı olabilir.

Burada önemli nokta çalışanları sürekli izlemek değil, servis operasyonunu ölçülebilir hale getirmektir.

6. Arıza ile Parça, Tahsilat ve Müşteri Geçmişinin Bağlantısı

Bir diğer sık hata, arıza takip yazılımını şirketin geri kalan operasyonundan tamamen ayrı değerlendirmektir. Oysa sahadaki bir arızanın çoğu zaman finansal ve teknik devamı vardır.

Örneğin teknisyen arızaya gittiğinde kontaktör değiştirdi. Bu durumda şirket açısından yalnızca "arıza çözüldü" bilgisinin tutulması yeterli olmayabilir. Hangi parçanın kullanıldığı, müşteriden ücret alınacaksa tutarın ne olduğu ve işlemin müşterinin hesabına nasıl yansıdığı da önemlidir.

Bu bağlantı kurulmazsa birkaç farklı problem oluşabilir. Depodan çıkan parçalar gerçek tüketimle eşleşmeyebilir, ücretli servis işlemleri unutulabilir veya müşteri geçmişindeki maliyet doğru görülemez.

Özellikle yüksek arıza hacmine sahip firmalarda küçük tutarlı fakat sık tekrarlanan ücretli işlemlerin kayıt dışı kalması yıl sonunda önemli gelir kaybına dönüşebilir.

Bu nedenle demo sırasında yalnızca arıza ekranını değil, arıza sonrasında oluşan iş akışını da incelemek gerekir.

Program Demosunda Mutlaka Test Edilmesi Gereken Noktalar

Bir yazılım sunumunda onlarca özellik anlatılabilir. Ancak satın alma kararını özellik listesinden değil, gerçek bir senaryoyu sistem üzerinde uygulayarak vermek daha sağlıklıdır.

Örneğin demo sırasında hayali bir müşteriden arıza çağrısı geldiğini düşünün. Bir bina ve asansör seçin, arıza kaydı açın, teknisyen görevlendirin ve kaydı sahadan kapatmaya çalışın.

Özellikle şu kontrolleri yapın:

• Aynı arızaya birden fazla kişinin müdahale etmesi nasıl engelleniyor?
• Teknisyen görevi mobil cihazdan görebiliyor mu?
• Önceki arıza geçmişine ulaşabiliyor mu?
• Fotoğraf veya servis açıklaması ekleyebiliyor mu?
• Eksik bilgiyle arızayı kapatabiliyor mu?
• Kullanılan parçalar kayıt altına alınabiliyor mu?
• Müşteriye durum bilgisi gönderilebiliyor mu?
• Açık ve geciken arızalar kolayca filtrelenebiliyor mu?
• Tekrar eden arızalar asansör bazında görülebiliyor mu?
• Arıza sonrasında rapor alınabiliyor mu?

Bu test, yüz maddelik özellik listesinden daha açıklayıcı olabilir. Çünkü yazılımın günlük operasyonunuza gerçekten uyup uymadığını görmenizi sağlar.

Ucuz Yazılım ile Eksik Yazılım Arasındaki Fark

Asansör firmaları yazılım fiyatlarını karşılaştırırken genellikle yıllık lisans bedeline odaklanır. Fakat düşük fiyatlı görünen bir ürün, kritik süreçleri manuel bırakıyorsa toplam maliyet düşündüğünüzden daha yüksek olabilir.

Örneğin arıza programı müşteriye otomatik bilgilendirme göndermiyorsa ofis personeli her gün onlarca telefon görüşmesi yapmak zorunda kalabilir. Tekrar eden arızaları göstermiyorsa teknik ekip aynı soruna tekrar tekrar müdahale edebilir. Servis formu ile arıza kaydı bağlantılı değilse personel aynı bilgiyi iki farklı yerde girebilir.

Dolayısıyla satın alma kararında sorulması gereken soru sadece "Yıllık fiyatı ne kadar?" değildir. Daha doğru soru şudur:

Bu yazılım, bugün personelin manuel yaptığı hangi işleri ortadan kaldırıyor ve hangi operasyon hatalarını önlüyor?

Yazılımın gerçek değeri genellikle burada ortaya çıkar.

Küçük Firmalar İçin Bu Özellikler Fazla mı?

10–20 kişilik büyük bir servis organizasyonunda detaylı takip ihtiyacı açıktır. Ancak birkaç teknisyenle çalışan küçük firmalarda "Bize bu kadar detay lazım değil" düşüncesi oluşabilir.

Aslında küçük ekiplerde kayıt disiplini daha da kritik olabilir. Çünkü firma sahibinin operasyon bilgisi çoğu zaman telefon görüşmeleri, WhatsApp mesajları ve personelin hafızası üzerinde dağılmış durumdadır.

Portföy 50 asansörden 150 asansöre çıktığında daha önce sorun yaratmayan yöntemler yetersiz kalabilir. Bu nedenle program seçerken yalnızca bugünkü ihtiyacı değil, önümüzdeki birkaç yıl içinde oluşabilecek operasyon hacmini de düşünmek gerekir.

Asansorex gibi asansör bakım ve arıza süreçlerini tek yerde toplamaya odaklanan yazılımlar da bu noktada, çağrıdan saha müdahalesine kadar oluşan geçmişi merkezi biçimde tutarak büyüyen firmaların operasyon takibini kolaylaştırabilir.

Sıkça Sorulan Sorular

Asansör arıza takip programında en önemli özellik nedir?

Tek bir özellik söylemek doğru olmaz. Ancak arızanın açılmasından kapanmasına kadar sorumlunun, durumun ve yapılan işlemin net biçimde kayıt altında olması temel gereksinimdir. Bunun üzerine mobil kullanım, bildirim, raporlama ve geçmiş arıza analizi eklenmelidir.

Mobil uygulama mutlaka gerekli mi?

Saha teknisyenlerinin arıza bilgilerine ofisten bağımsız ulaşması gereken firmalarda mobil kullanım büyük avantaj sağlar. Teknisyenin ofisi arayıp adres, telefon veya arıza açıklaması sorması yerine gerekli bilgileri doğrudan görebilmesi operasyonu hızlandırır.

Arıza takip programında fotoğraf zorunlu olmalı mı?

Her arıza için zorunlu olması şart değildir. Ancak firma belirli arıza türlerinde veya parça değişimlerinde fotoğraf talep edebilir. Yazılımın bu tür kuralları desteklemesi kayıt kalitesini artırır.

Arıza geçmişi neden önemlidir?

Geçmiş kayıtlar tekrar eden teknik sorunların belirlenmesini sağlar. Ayrıca teknisyen değiştiğinde yeni teknisyenin önceki müdahaleleri görmesine ve müşteriye daha sağlıklı bilgi verilmesine yardımcı olur.

WhatsApp üzerinden arıza takibi yeterli değil mi?

WhatsApp hızlı iletişim için faydalıdır ancak tek başına yapılandırılmış bir arıza takip sistemi değildir. Mesajlar arasında arama yapmak, sorumluluk takibi yapmak, geciken işleri görmek ve aylık performans raporu oluşturmak zorlaşabilir. Mesajlaşma aracı iletişim kanalı olarak kullanılabilir; asıl kayıtların merkezi sistemde tutulması daha sağlıklıdır.

Program almadan önce en iyi test yöntemi nedir?

Demo sırasında gerçek çalışma düzeninize benzeyen bir arıza senaryosu oluşturun. Kaydı açın, teknisyen atayın, sahadan işlem yapın, müşteriyi bilgilendirin ve arızayı kapatın. Böylece yalnızca özelliklerin varlığını değil, kullanım kolaylığını da test etmiş olursunuz.

Özet

Bir asansör arıza takip programı seçerken arıza kaydı oluşturma ve teknisyen atama özelliklerinin bulunması artık tek başına yeterli değildir. Arızanın sahiplenilmesi, zaman damgaları, zorunlu servis kayıtları, müşteri bilgilendirmesi, geçmiş arıza analizi, parça kullanımı ve raporlama gibi ayrıntılar günlük operasyonun kalitesini belirler.

Özellikle yazılım satın almadan önce bir özellik listesini işaretlemek yerine gerçek bir arıza senaryosunu baştan sona sistem üzerinde çalıştırmak gerekir. Böylece birkaç aylık kullanım sonrasında ortaya çıkabilecek eksikleri daha satın alma aşamasında görebilirsiniz.

Doğru sistem, yalnızca arızaları dijital ortamda saklayan sistem değildir. Arızanın unutulmasını önleyen, sorumluluğu netleştiren, sahadan doğru veri toplayan ve geçmiş kayıtları yönetim kararlarında kullanılabilir hale getiren sistemdir.