Asansör Arıza Ticket Programı Alırken Kaçırılan Özellikler

İÇERİK

Bir asansör arıza ticket programı satın alırken ilk bakılan özellik genellikle basittir: Çağrı açılıyor mu, teknisyene iş atanıyor mu, iş kapatılıyor mu? Bunlar gerekli olsa da günlük operasyonun zor kısmını tek başına çözmez. Asıl fark; aynı binadan ikinci telefon geldiğinde, teknisyen değiştiğinde, arıza tekrarladığında veya yönetici “Ne yapıldı?” diye sorduğunda ortaya çıkar. Bu rehber, ürün tanıtımlarında kolayca gözden kaçan özellikleri ve satın almadan önce bunları nasıl sınayabileceğinizi gösterir.

1. Çağrının doğru asansöre bağlanması

Bir apartmanda birden fazla asansör varsa “A Blok arızalı” kaydı çoğu zaman yetersizdir. Yolcu asansörü mü, yük asansörü mü? Aynı bloktaki hangi cihaz? Yanlış eşleştirme, teknisyenin geçmiş servis kayıtlarını yanlış okumasına ve ofisin aynı arıza için mükerrer iş açmasına yol açabilir.

Programda yalnızca bina adı seçilmesini yeterli görmeyin. Bina, asansör ve ilgili kişi ayrı ayrı belirlenebilmeli; çağrıyı alan çalışan da doğru cihazı hızlıca bulabilmelidir. Kayıt sırasında adres, erişim bilgisi ve daha önce bildirilen benzer arızalar görülebiliyorsa telefonda daha iyi sorular sorulur.

Demoda aynı adreste iki asansör oluşturun. Birine arıza kaydı açıp diğerinin geçmişinden bağımsız görünüp görünmediğini kontrol edin. Ardından bina yöneticisinin tekrar aradığını varsayın: Çalışanınız telefon numarası veya bina adıyla açık kayda ulaşabiliyor mu?

2. Serbest metnin yanında düzenli çağrı bilgileri

“Çalışmıyor” açıklaması, teknisyeni hazırlamak için yeterli değildir. Çağrıyı alan kişinin kısa sürede bazı temel bilgileri toplaması gerekir. İyi tasarlanmış bir kayıt akışı, çalışanı gereksiz alanlarla yormadan bu bilgileri hatırlatır:

• Arıza hangi asansörde ve ne zaman fark edildi?
• Kabinde mahsur kalan kişi olduğu bildiriliyor mu?
• Asansör tamamen durdu mu, aralıklı mı çalışıyor?
• Ekranda görülen bir hata veya gözlenen belirti var mı?
• Binada teknisyene kapıyı açabilecek kişi kim?
• Aynı sorun yakın zamanda yaşandı mı?

Bu alanların hepsinin her çağrıda zorunlu olması da doğru değildir. Örneğin acil bir mahsur kalma bildiriminde çalışan önce çağrıyı hızla ilgili ekibe iletebilmelidir. Yazılım, kritik bilgiyi öne çıkarırken eksik ayrıntının daha sonra tamamlanmasına izin vermelidir. Acil durumlarda firmanın güvenlik ve müdahale prosedürleri yazılımdaki form akışından önce gelir.

Satın alma görüşmesinde yalnızca boş bir kayıt ekranına bakmayın. Bir çalışanın gerçekçi bir telefon görüşmesi sürerken kaydı ne kadar sürede ve ne kadar doğru açabildiğini izleyin.

3. Öncelik ile iş sırasının birbirinden ayrılması

Her arıza aynı öncelikte değildir. Bununla birlikte “acil” düğmesi olan her program etkili bir öncelik yönetimi sunmaz. Çağrının niteliği, konumu, ekiplerin müsaitliği ve o anda devam eden işler birlikte değerlendirilmelidir.

Örneğin bir binada düğme aydınlatmasıyla ilgili bildirim varken başka bir binada kabinde kişi kaldığı bildirilebilir. Program, iki işi yalnızca açılış saatine göre sıralıyorsa ofis çalışanı önemli ayrımı kendi hafızasıyla yönetmek zorunda kalır. Öncelik işaretinin görevli teknisyene açıkça iletilmesi, çağrıya ilişkin notlarla birlikte görünmesi ve sonradan kimin ne zaman değişiklik yaptığının anlaşılabilmesi gerekir.

Aşağıdaki tabloyu demo sırasında kısa bir kontrol listesi olarak kullanabilirsiniz:

Kontrol noktası	Demoda uygulanacak senaryo	Aranacak sonuç
Doğru cihaz	Aynı binada iki asansörden birine çağrı açın	Kayıt yalnızca ilgili asansöre bağlanır
Öncelik	Acil bir bildirim ekleyin	Görevli kişi önceliği ve çağrı notunu görür
Tekrar arama	Aynı kişi aynı sorun için yeniden arasın	Açık iş kolayca bulunur, mükerrer kayıt önlenir
Ekip değişimi	Atanan teknisyeni değiştirin	Yeni teknisyen önceki notları görür
İşin kapanışı	İşlem ve fotoğraf ekleyerek kapatın	Yapılan iş sonradan anlaşılır
Tekrar arıza	Aynı cihazda benzer yeni çağrı açın	Önceki müdahale kolayca incelenir

4. Teknisyene gönderilen işin saha için yeterli olması

Ofiste ayrıntılı görünen bir kayıt, teknisyenin telefonunda yalnızca adres ve “arıza var” açıklamasına dönüşüyorsa bilgi aktarımı kopar. Teknisyen yola çıkmadan önce hangi asansöre gideceğini, şikâyetin ne olduğunu, kiminle görüşeceğini ve daha önce hangi müdahalelerin yapıldığını görebilmelidir.

Sahadaki kullanım koşullarını da deneyin. Bodrum katında bağlantı zayıfken teknisyen not alabiliyor mu? Fotoğraf eklediğinde yükleme tamamlanana kadar kayıt kaybolmadan saklanıyor mu? Uygulama çevrim dışı çalıştığını söylüyorsa hangi işlemlerin çevrim dışı yapılabildiğini ve bağlantı gelince nasıl eşitlendiğini açıkça sorun.

Asansorex gibi saha ve ofis kayıtlarını bir arada tutan bir yazılım, çağrı bilgisinin teknisyene aktarılmasına ve yapılan müdahalenin fotoğraf ile servis kaydına bağlanmasına yardımcı olabilir. Ancak satın alma kararını verirken bu akışı kendi ekibinizin kullandığı telefonlarla denemek daha değerlidir.

5. İşin kapanması ile sorunun çözülmesinin ayrı izlenmesi

Bazı arızalar ilk ziyarette giderilemez. Parça beklenir, farklı bir uzman gerekir veya binaya yeniden erişim sağlanmalıdır. Program yalnızca “açık” ve “kapalı” seçenekleri sunuyorsa teknisyen işi kapatıp ayrıca telefonla takip etmek zorunda kalabilir. Bu durumda ofis ekranındaki tamamlanmış iş, bina yöneticisinin gözünde hâlâ devam eden bir sorundur.

İş durumlarının günlük çalışmaya uyması gerekir. “Teknisyen atandı”, “yerinde inceleme yapıldı”, “parça bekleniyor” ve “işlem tamamlandı” gibi aşamalar kullanılabiliyorsa herkes aynı durumu görebilir. Durum sayısını gereksiz yere artırmak ise kayıt disiplinini zorlaştırır. Demoda ekibinizin sık karşılaştığı bir parça bekleme örneğini uygulayın: İş kaybolmadan takip ediliyor mu ve yeniden ziyaret için hatırlatma oluşturulabiliyor mu?

Kapanış kaydında da yalnızca “yapıldı” yazması yeterli değildir. Gözlenen belirti, yapılan kontrol, kullanılan parça, sonuç ve gerekiyorsa önerilen sonraki işlem anlaşılır biçimde yazılmalıdır. Bu bilgiler, hem bir sonraki teknisyene hem de bina yöneticisine açıklama yapacak ofis çalışanına yardımcı olur.

6. Tekrar arızayı geçmiş kayıtlardan fark edebilme

Bir cihaz için ay içinde üç ayrı çağrı açılması, üç bağımsız sorun anlamına gelmeyebilir. Kayıtlar yalnızca tarih sırasıyla listeleniyorsa tekrar eden belirtiyi fark etmek çalışanların dikkatine kalır. Oysa aynı asansörün önceki arızalarına, kullanılan parçalara ve müdahale notlarına kolayca ulaşmak teknik değerlendirmeyi güçlendirir.

Burada beklenti, yazılımın arızanın nedenini kendiliğinden teşhis etmesi değildir. Beklenti, karar verecek teknisyene düzenli ve erişilebilir bir geçmiş sunmasıdır. Örneğin “kapı kapanmıyor” şikâyetiyle yeni iş açıldığında yakın tarihli benzer çağrılar görülebilmeli; önceki sefer ne yapıldığı incelenebilmelidir.

Şu soruyu özellikle sorun: Bir arıza kapatıldıktan üç gün sonra aynı belirti yeniden bildirildiğinde, çalışanınız iki kaydın ilişkisini nasıl görecek? Satış sunumundaki genel rapor yerine bu somut örneğin gösterilmesini isteyin.

7. Bina yöneticisine verilecek bilginin izlenebilir olması

Bina yöneticisi çoğu zaman teknik ayrıntıdan önce üç şey öğrenmek ister: Bildirim alındı mı, ekip ne durumda, işlem sonucunda ne yapıldı? Bu soruların cevabı için ofisin sürekli teknisyeni araması gerekiyorsa ticket programı iletişim yükünü yeterince azaltmıyor olabilir.

Yöneticiye gösterilen bilgi ile firmanın iç notları birbirinden ayrılabilmelidir. Örneğin teknisyenin parça tedariki hakkındaki iç değerlendirmesi ayrı kalırken ziyaret zamanı ve yapılan işlem yöneticiyle paylaşılabilir. Paylaşılacak kayıtların anlaşılır dilde olması da önemlidir; yalnızca teknik kısaltmalar içeren bir servis notu, açıklama ihtiyacını ortadan kaldırmaz.

Demoda bir arızanın açılışından kapanışına kadar bina yöneticisine hangi bilginin, hangi yolla ve ne zaman iletilebildiğini görün. Otomatik bildirim varsa gönderim başarısız olduğunda çalışanın bunu fark edip edemediğini de kontrol edin.

8. Raporların iş kararına dönüşmesi

“Gelişmiş raporlama” ifadesi satın alma görüşmelerinde sık duyulur. Daha yararlı soru şudur: Bu rapora bakarak gelecek ay hangi kararı vereceğiz? Arıza sayısını gösteren bir grafik tek başına yeterli olmayabilir. Firma sahibi, iş yükünü ve tekrarlayan sorunları ayırt etmek ister.

Önce ihtiyacınız olan birkaç soruyu belirleyin:

• Hangi asansörlerden sık arıza çağrısı geliyor?
• Hangi işler ilk ziyarette sonuçlanıyor, hangileri yeniden ziyaret gerektiriyor?
• Açık işler hangi aşamada bekliyor?
• Teknisyenlerin iş yükü bölgeler arasında nasıl dağılıyor?
• Hangi arızalarda parça bekleme süresi uzuyor?

Raporlardaki sürelerin başlangıç ve bitiş noktalarını da sorun. “Müdahale süresi” çağrının açılmasından görevlendirmeye kadar mı, teknisyenin varışına kadar mı ölçülüyor? Aynı adla sunulan iki rapor farklı şeyleri gösterebilir. Asansorex’in arıza ve iş emri kayıtlarını raporlarla birlikte değerlendirmek, bu soruları tek tek telefon kayıtlarından çıkarmaya göre daha düzenli bir çalışma sağlayabilir; yine de ölçümlerin firmanızın iş akışına uyduğunu demoda doğrulayın.

9. Yetki, değişiklik geçmişi ve veri aktarımı

Ticket kayıtlarında telefon numaraları, adresler, arıza açıklamaları ve servis fotoğrafları bulunabilir. Bu yüzden “her çalışan her şeyi görsün” yaklaşımı küçük bir ekipte bile sorun yaratabilir. Çağrıyı alan kişi, teknisyen ve firma yöneticisi için uygun erişim sınırlarını inceleyin. Ayrılan bir çalışanın erişimini kapatmanın nasıl yapıldığını da görün.

Bir diğer konu değişiklik geçmişidir. Arıza açıklaması, önceliği veya kapanış notu sonradan değiştirildiğinde neyin güncellendiğini anlamak, ekip içi yanlış anlaşılmaları azaltır. Ayrıca programdan ayrılmanız gerekirse bina, asansör ve arıza kayıtlarınızı hangi biçimde alabileceğinizi satın almadan önce yazılı olarak öğrenin.

10. Satın almadan önce gerçek çağrılarla pilot yapmak

En iyi demo, firmanızın yaşadığı birkaç zor vakayı baştan sona işletir. Satıcıdan örnek ekranları göstermesini istemek yerine kendi iş akışınızla kısa bir pilot yapın. Aynı binadaki iki asansör, acil çağrı, teknisyen değişimi, parça bekleme ve tekrar arıza senaryolarını kullanın.

Pilotta çağrıyı alan çalışanla birlikte en az bir saha teknisyeni yer alsın. Her ikisine de işlemi nerede durup düşünerek yaptığını sorun. Bir alanın eksikliği kadar, doğru bilgiyi girmek için fazla adım gerekmesi de günlük kullanımı etkiler. Sonunda şu kararı verebilmelisiniz: Program, çağrıdan kapanışa kadar işi takip etmeyi ekibiniz için gerçekten kolaylaştırıyor mu?

Sıkça Sorulan Sorular

Asansör arıza ticket programı ile sıradan iş takip programı arasındaki fark nedir?

Asansör işinde arızayı belirli bir binaya ve belirli bir cihaza bağlamak, cihazın servis geçmişini görmek ve sahadaki müdahaleyi aynı kayıt altında izlemek önemlidir. Genel bir iş takip programı bu akışı destekleyebilir; satın almadan önce kendi asansör kayıtlarınızla deneyerek uygunluğunu değerlendirmelisiniz.

Küçük bir bakım firması için tekrar arıza takibi gerekli mi?

Evet. Az sayıda çağrı alan bir firmada bile aynı asansöre yapılan önceki müdahaleyi hızlıca görmek teknisyenin hazırlığını kolaylaştırır. Ayrıca firma sahibinin sık arıza çıkaran cihazları fark etmesine yardımcı olur.

Her arıza kaydında fotoğraf zorunlu olmalı mı?

Her durumda zorunlu olması pratik olmayabilir. Fotoğraf, gözlenen durumun veya yapılan işlemin açıklanmasına katkı sağladığında değerlidir. Hangi işlerde fotoğraf isteneceğini firmanızın çalışma usulüne göre belirlemek daha uygulanabilir olur.

Çevrim dışı kullanım satın alma kararında ne kadar önemli?

Teknisyenlerinizin çalıştığı binalarda bağlantı sık kesiliyorsa önemlidir. Yalnızca “çevrim dışı çalışır” ifadesine güvenmeyin; kayıt açma, not ekleme, fotoğraf saklama ve sonradan eşitleme adımlarını sahada veya gerçekçi bir testte deneyin.

Program seçerken ilk hangi rapora bakılmalı?

Tekrar arızalarla açık işlerin bekleme durumunu gösteren raporlar iyi bir başlangıçtır. Bunlar hem teknik sorunları hem de takipte aksayan işleri görmenizi sağlar. Raporun hangi kayıtlardan ve hangi tarih aralığından üretildiğini kontrol edin.

Özet

Asansör arıza ticket programı seçerken kayıt açma ve teknisyen atama ekranlarının ötesine bakın. Doğru asansörü bulma, acil çağrıyı ayırt etme, saha bilgisini aktarma, bekleyen işleri izleme ve tekrar arızayı görme özelliklerini gerçek senaryolarla sınayın. Satın alma kararında en güvenilir ölçüt, programın bir arızayı ilk telefon görüşmesinden açıklanabilir bir kapanış kaydına kadar ekibinizle birlikte taşıyabilmesidir.