Asansör Arıza Yazılımı Alırken Kaçırılan Özellikler

İÇERİK

Bir Asansör Arıza Yazılımı satın alınırken çoğu firma ilk olarak çağrı kaydı açma, teknisyen atama ve arızayı kapatma özelliklerini kontrol eder. Ancak yazılımın gerçek değeri, bu temel işlevlerden çok arıza sürecinin ayrıntılarında ortaya çıkar. İnternetin çekmediği bir makine dairesinde kayıt alınamaması, aynı arızanın geçmişinin görülememesi veya müşteriye yanlış zamanda otomatik mesaj gönderilmesi, iyi görünen bir sistemi sahada verimsiz hâle getirebilir.

Doğru yazılım; yalnızca arızaları listelememeli, ihbarın alınmasından kalıcı çözümün doğrulanmasına kadar bütün süreci ölçülebilir hâle getirmelidir. Bu rehberde firma sahiplerinin, teknisyenlerin ve bina yöneticilerinin satın alma öncesinde sıklıkla gözden kaçırdığı özellikleri ve bunların neden önemli olduğunu ele alacağız.

Arıza Kaydı Açmak Tek Başına Yeterli Değildir

Birçok yazılım demosunda süreç ideal bir senaryo üzerinden anlatılır: Müşteri arar, ofis kaydı açar, teknisyen atanır ve işlem tamamlanır. Gerçek hayatta ise ihbarlar eksik, tekrarlı veya yanlış bilgilerle gelebilir.

İyi bir arıza kayıt ekranında en azından şu bilgiler düzenli biçimde tutulabilmelidir:

• İhbarı yapan kişinin adı ve iletişim bilgisi
• Bina, asansör ve durak bilgileri
• Arızanın bildirildiği tarih ve saat
• Arızanın belirtisi veya ihbar açıklaması
• Kabinde mahsur kalma durumu
• Aciliyet ve öncelik seviyesi
• Atanan teknisyen veya ekip
• Kullanılan parça ve yapılan işlem
• Fotoğraf, imza ve açıklama
• Arızanın geçici mi kalıcı mı giderildiği

Özellikle mahsur kalma ihbarı, sıradan bir kapı ayarı veya aydınlatma probleminden farklı ele alınmalıdır. Yazılımın kritik ihbarları renk, uyarı veya öncelik seviyesiyle ayırabilmesi gerekir. Aksi hâlde acil bir kayıt, yoğun iş listesinin içinde sıradan bir servis talebi gibi görünebilir.

Ayrıca tek bir binada birden fazla asansör varsa kayıt yalnızca müşteriyle değil, doğru cihazla ilişkilendirilmelidir. “A Blok asansörü” gibi genel ifadeler yerine cihaz numarası, konumu veya tanımlayıcı bilgisi kullanılmalıdır.

Çevrimdışı Çalışma ve Sonradan Senkronizasyon

Asansör teknisyenlerinin çalışma alanlarında mobil internet her zaman güçlü değildir. Bodrum katları, kapalı otoparklar ve bazı makine daireleri bağlantı sorunlarının sık yaşandığı alanlardır. Bu nedenle çevrimdışı çalışma, satın alma sırasında mutlaka denenmesi gereken özelliklerden biridir.

Gerçek bir çevrimdışı kullanımda teknisyen:

• Atanmış iş emirlerini görebilmeli,
• Arıza açıklamasını okuyabilmeli,
• İşlem notu ekleyebilmeli,
• Kontrol maddelerini işaretleyebilmeli,
• Fotoğraf ve imza kaydedebilmeli,
• İnternet geldiğinde bilgileri senkronize edebilmelidir.

Bazı sistemler “çevrimdışı destek” ifadesini kullansa da yalnızca önceden açılmış ekranı göstermeye devam eder. Uygulama kapatıldığında kayıt kaybolabilir veya fotoğraflar yüklenmeyebilir. Bu nedenle demo sırasında telefonun interneti kapatılarak gerçek bir servis kaydı oluşturulmalı, uygulama kapatılıp yeniden açılmalı ve sonrasında senkronizasyon kontrol edilmelidir.

Tekrarlayan Arızaları Gösteren Cihaz Geçmişi

En fazla kaçırılan özelliklerden biri, arıza kayıtlarının cihaz bazında anlamlı bir geçmişe dönüştürülmesidir. Yalnızca kapanan işleri sıralamak yeterli değildir. Yazılım, aynı belirtiyle tekrar eden arızaların fark edilmesini kolaylaştırmalıdır.

Örneğin bir asansörde son iki ay içinde dört kez “katta seviye farkı” kaydı açılmışsa her olaya bağımsız müdahale etmek sorunu çözmez. Önceki işlemlerde yapılan ayarlar, değiştirilen parçalar ve teknisyen açıklamaları birlikte incelenmelidir. Böylece geçici müdahale yerine kök neden araştırmasına geçilebilir.

Kontrol edilen özellik	Yetersiz yaklaşım	Beklenen işlev
Cihaz geçmişi	Sadece kapanan işleri listeler	Tarih, belirti, işlem ve parçaları birlikte gösterir
Tekrar arıza	Manuel olarak fark edilir	Aynı cihazdaki benzer kayıtları öne çıkarır
Teknisyen notu	Serbest ve dağınık metin	Standart arıza nedeni ve çözüm alanları sunar
Parça geçmişi	Cari veya stokta kalır	Kullanılan parçayı ilgili cihazla ilişkilendirir
Fotoğraflar	Telefon galerisinde tutulur	Arıza kaydına tarihli biçimde ekler
Performans	Yalnızca toplam iş sayısı ölçülür	Müdahale ve tekrar arıza oranlarını izler

Bu geçmiş, yeni görevlendirilen teknisyen için de önemlidir. Teknisyen yola çıkmadan önce son müdahaleleri görürse yanında doğru ekipman ve olası yedek parçalarla hareket edebilir. Böylece ikinci ziyaret ihtimali azalabilir.

Zaman Damgaları ve Müdahale Süresinin Ölçülmesi

Bir arızanın ne kadar sürede kapatıldığı tek başına yeterli bir performans göstergesi değildir. Sürecin hangi aşamasında zaman kaybedildiğinin anlaşılması gerekir.

Yazılımın aşağıdaki zamanları ayrı ayrı kaydedebilmesi önemlidir:

1. İhbarın alındığı saat
2. Kaydın teknisyene atandığı saat
3. Teknisyenin işi kabul ettiği saat
4. Ekibin yola çıktığı saat
5. Sahaya varış saati
6. Çalışmaya başlama saati
7. İşlemin tamamlanma saati
8. Müşteri onayı veya imza saati

Bu kayıtlar olmadan “ortalama arıza çözüm süresi” yanıltıcı olabilir. Örneğin teknisyen arızayı 25 dakikada çözmüş olsa bile görev ataması ofiste 50 dakika beklediyse müşteri açısından toplam süre 75 dakikadır.

Konum kaydı da dikkatli değerlendirilmelidir. Amaç çalışanı sürekli izlemek değil, görev kapsamında sahaya varış ve ayrılış bilgisini doğrulamaktır. Firma; hangi konum verisinin, hangi amaçla ve ne kadar süreyle tutulduğunu çalışanlarına açıkça bildirmeli, kişisel verilerin korunmasına ilişkin yükümlülüklerini gözetmelidir.

Fotoğraf, İmza ve Değiştirilemez Servis Geçmişi

Fotoğraf ekleme özelliği birçok sistemde bulunur; fakat uygulama biçimi aynı değildir. Fotoğrafın yalnızca galeriye kaydedilmesi veya mesajlaşma uygulamasıyla ofise gönderilmesi kurumsal kayıt oluşturmaz. Görselin ilgili cihaz, iş emri, tarih ve teknisyenle ilişkilendirilmesi gerekir.

Satın alma öncesinde şu sorular sorulmalıdır:

• Fotoğraf doğrudan arıza kaydına mı ekleniyor?
• İnternet olmadığında çekilen fotoğraf korunuyor mu?
• Fotoğrafa tarih ve işlem bilgisi bağlanıyor mu?
• İş tamamlandıktan sonra kayıt üzerinde yapılan değişiklikler izleniyor mu?
• Müşteri imzası servis formunda gösteriliyor mu?
• Teknisyen ve müşteri için ayrı açıklama alanları bulunuyor mu?
• Eski kayıtlar yetkisiz kullanıcılar tarafından silinebiliyor mu?

Kayıt değişikliklerinin izlenmesi özellikle anlaşmazlıklarda önem kazanır. Kimin, hangi alanı, ne zaman değiştirdiğinin görülebilmesi kayıt güvenilirliğini artırır. Bununla birlikte fotoğraf ve imza alınırken kişisel verilerin korunması, erişim yetkileri ve saklama politikaları da dikkate alınmalıdır.

Bu verileri dağınık mesajlar ve kâğıt formlar yerine Asansorex gibi bir asansör arıza takip yazılımında cihaz bazında toplamak, hem firma içi incelemeyi hem de bina yöneticisine geçmiş kayıtların sunulmasını kolaylaştırır.

Yetkilendirme ve Şube Bazlı İş Dağılımı

Küçük ekiplerde herkesin bütün kayıtlara ulaşması başlangıçta pratik görünebilir. Firma büyüdükçe bu yapı hem veri güvenliği hem operasyon açısından sorun oluşturur.

Yazılımın rolleri yalnızca “yönetici” ve “teknisyen” şeklinde ayırması yeterli olmayabilir. Ofis çalışanı arıza kaydı açabilmeli ancak fiyatları değiştirememeli; teknisyen kendisine atanan işleri görebilmeli ancak müşteri borç bilgilerine ulaşmamalı; şube sorumlusu yalnızca kendi bölgesindeki ekipleri yönetebilmelidir.

Özellikle birden fazla şubesi veya servis bölgesi bulunan firmalarda şu ayrımlar aranmalıdır:

• Şubeye göre müşteri ve cihaz erişimi
• Bölgeye göre teknisyen atama
• Kullanıcı rolüne göre fiyat ve maliyet görünürlüğü
• Kayıt silme, değiştirme ve onaylama yetkileri
• Şube ve merkez için ayrı performans raporları
• Yetki değişikliklerinin kayıt altına alınması

Yetkilendirme, yalnızca güvenlik meselesi değildir. Teknisyenin karşısına görevini tamamlamak için gerekli alanların çıkması, uygulamanın benimsenmesini de kolaylaştırır.

Müşteri Bilgilendirmesi ve Onay Süreci

Bina yöneticisinin en sık sorduğu sorular basittir: “Teknisyen yola çıktı mı?”, “Arıza giderildi mi?” ve “Hangi işlem yapıldı?” Yazılım bu soruların tamamını ofise yönlendiriyorsa dijitalleşme eksik kalmış demektir.

SMS, mobil bildirim veya müşteri portalı üzerinden bilgilendirme yapılabilmesi ofisin telefon yükünü azaltabilir. Ancak otomatik mesajlar kontrolsüz gönderilmemelidir. Yanlış kişiye teknik detay, ücret veya bina bilgisi iletilmesi müşteri ilişkisini zedeleyebilir.

İyi tasarlanmış bir bilgilendirme akışı şu aşamalardan oluşabilir:

• Arıza kaydının alındığına ilişkin bildirim
• Teknisyenin görevlendirildiği veya yola çıktığı bilgisi
• İşlemin tamamlandığına ilişkin özet
• Kullanılan parça veya önerilen işlemler
• Dijital servis formu bağlantısı
• Gerekliyse müşteri onayı veya geri bildirim talebi

Bina yöneticisi açısından değerli olan, karmaşık teknik ekranlar değil; anlaşılır bir servis geçmişi ve işlemin sonucudur. Bu nedenle müşteri tarafında gösterilen bilgiler sade, tarihli ve cihazla ilişkilendirilmiş olmalıdır.

Stok, Parça ve Ücret Bağlantısının Kurulması

Arıza yönetimi ile stok takibi birbirinden kopuk olduğunda kullanılan parçalar sonradan ofise sözlü olarak bildirilir. Bu yöntem stok farklarına, eksik maliyet hesabına ve geciken faturalandırmaya yol açabilir.

Teknisyenin servis kaydına kullandığı parçayı, miktarı ve gerekiyorsa seri numarasını ekleyebilmesi gerekir. Parça değişiminin müşteri onayına tabi olduğu durumlarda teklif, onay ve uygulama adımları birbirinden ayrılmalıdır.

Burada gözden kaçan önemli ayrım şudur: Arızayı kapatmak ile ticari süreci tamamlamak aynı şey değildir. Teknik işlem tamamlanmış olabilir; fakat parça bedeli henüz onaylanmamış, faturalanmamış veya tahsil edilmemiş olabilir. Yazılım bu durumları ayrı gösterebilmelidir.

Raporlarda Toplam Sayı Değil, Doğru KPI’lar Aranmalı

Ay sonunda “127 arıza kapatıldı” bilgisi tek başına yönetime yeterli fikir vermez. Firma sahibi hangi cihazların sürekli arıza verdiğini, hangi işlerin ikinci ziyarete kaldığını ve hangi bölgelerde müdahale süresinin uzadığını bilmek ister.

Değerlendirilebilecek temel göstergeler şunlardır:

• İlk müdahaleye kadar geçen ortalama süre
• Arızanın tamamen çözülmesine kadar geçen süre
• İlk ziyarette çözüm oranı
• Aynı cihazda belirli dönemde tekrar arıza sayısı
• Teknisyen veya ekip bazında açık iş sayısı
• Bekleyen parça nedeniyle kapanmayan işler
• Müşteri onayı bekleyen işlemler
• Cihaz, bina, bölge ve arıza türü bazında dağılım

Raporların Excel veya PDF biçiminde dışarı alınabilmesi de önemlidir. Ancak satın alma kararında yalnızca “raporlama var” ifadesi kabul edilmemeli; firmanın gerçekten takip edeceği iki veya üç rapor demo verileriyle oluşturulmalıdır.

Satın Alma Öncesi Gerçek Senaryo Testi

Özellik listesini okumak yerine yazılımı gerçek bir arıza senaryosuyla denemek daha doğru sonuç verir. Pilot test için sık karşılaşılan bir ihbar seçilebilir.

Örneğin süreç şöyle uygulanabilir:

1. Bina yöneticisi rolündeki kişi arıza ihbarı versin.
2. Ofis çalışanı cihazı seçerek öncelikli kayıt oluştursun.
3. Teknisyen görevi telefondan kabul etsin.
4. Telefon interneti kapatılarak sahaya varış ve işlem bilgisi girilsin.
5. Fotoğraf, kullanılan parça ve müşteri imzası eklensin.
6. Bağlantı açıldıktan sonra bilgiler senkronize edilsin.
7. Servis formu oluşturulsun ve müşteriye gönderilsin.
8. Aynı cihazın geçmişinde kayıt kontrol edilsin.
9. Müdahale süresi raporda görüntülensin.
10. Yetkisiz bir kullanıcının fiyat veya kayıt silemediği doğrulansın.

Bu test, sunum sırasında fark edilmeyen kullanım problemlerini birkaç saat içinde ortaya çıkarabilir.

Sıkça Sorulan Sorular

Asansör Arıza Yazılımı için en önemli özellik nedir?

Tek bir özellik yerine uçtan uca kayıt bütünlüğü aranmalıdır. İhbarın alınması, teknisyen ataması, sahaya varış, yapılan işlem, kullanılan parça, fotoğraf, imza ve kapanış aynı cihaz geçmişinde birleşmelidir.

Çevrimdışı çalışma gerçekten gerekli mi?

Evet. Bodrum katları, otoparklar ve makine dairelerinde bağlantı zayıf olabilir. Teknisyen internet olmadığı için işi kaydedemiyorsa saha süreci yeniden kâğıt ve mesajlaşma uygulamalarına döner.

GPS ile teknisyen takibi zorunlu mudur?

Hayır. Her firma sürekli konum takibine ihtiyaç duymaz. Görev kapsamında sahaya varışın doğrulanması yeterli olabilir. Konum verisi kullanılırken çalışanların bilgilendirilmesi, erişim sınırları ve kişisel verilerin korunması dikkate alınmalıdır.

Yazılım tekrar arızaları nasıl azaltır?

Aynı cihazın arıza belirtilerini, önceki müdahalelerini ve değiştirilen parçalarını bir arada göstererek kök neden analizini kolaylaştırır. Yazılım teknik sorunu kendi başına çözmez; fakat doğru kararı verecek geçmişi erişilebilir hâle getirir.

Bina yöneticisine hangi bilgiler gösterilmelidir?

İhbar tarihi, işlem durumu, teknisyenin gelişi, yapılan işlemin özeti ve servis formu gösterilebilir. Maliyet, iç notlar veya personel bilgileri ise firmanın belirlediği yetkilere göre sınırlandırılmalıdır.

Demo sürecinde kaç gün test yapılmalıdır?

Süre kadar senaryo çeşitliliği önemlidir. Pilot dönemde en az bir acil ihbar, bir parça değişimi, bir çevrimdışı kayıt ve bir tekrar arıza senaryosu tamamlanmalıdır. Birkaç farklı teknisyenin sistemi kullanması da gerçek kullanım zorluklarını gösterir.

Özet

Asansör Arıza Yazılımı seçerken yalnızca çağrı açma ve teknisyen atama özelliklerine bakmak yeterli değildir. Çevrimdışı kullanım, cihaz geçmişi, tekrar arıza analizi, zaman damgaları, yetkilendirme, fotoğraflı kayıt, müşteri bilgilendirmesi ve parça bağlantısı sistemin günlük faydasını belirler.

Satın alma öncesinde kendi ekibinizden gerçek kullanıcılarla uçtan uca bir arıza senaryosu deneyin. Asansorex, arıza kayıtlarının cihaz geçmişiyle ilişkilendirilmesi ve saha-ofis sürecinin tek noktadan izlenmesi konusunda firmalara yardımcı olabilir. Nihai kararınızı ise özellik listesinden çok pilot kullanım sonuçlarına, veri güvenliğine ve ekibin sistemi sahada ne kadar kolay kullandığına göre verin.