Asansör Arıza Çağrı Programı Alırken Kaçırılan Özellikler

İÇERİK

Bir Asansör Arıza Çağrı Programı demosunda çağrı açılması, teknisyen atanması ve işin kapatılması genellikle birkaç dakika sürer. Gerçek çalışma gününde ise aynı asansör için üç kişi arar, görevli teknisyen başka bir müdahalede bekler, gerekli parça bulunamaz ve akşam nöbeti farklı bir ekibe geçer. Yazılımın işe yarayıp yaramadığı bu durumlarda anlaşılır. Bu rehber, satın alma görüşmelerinde kolayca atlanan özellikleri ve bunları nasıl sınayabileceğinizi açıklıyor. Amaç, daha uzun bir özellik listesi toplamak değil; firmanızın günlük işleyişinde çağrıların kaybolmasını, yanlış kişiye atanmasını ve erken kapatılmasını önleyen noktaları belirlemek.

1. Çağrının Doğru Asansörle Eşleştirilmesi

Arıza kaydında bina adının yazılması yeterli görünebilir. Ancak aynı sitede dört blok, her blokta iki asansör varsa “Çınar Sitesi asansörü çalışmıyor” bilgisi teknisyeni doğru cihaza götürmez. Yanlış eşleştirme, servis geçmişinin de yanlış asansöre işlenmesine neden olur.

Programda müşteri, bina, blok ve asansör bilgilerinin anlaşılır biçimde ayrılması gerekir. Arayan kişinin söylediği adresle kayıtlı adres farklıysa çağrıyı alan çalışan bunu fark edebilmelidir. Teknik ekip için cihazın konumu, giriş bilgisi ve ilgili bina yetkilisinin iletişim bilgisi erişilebilir olmalıdır.

Demoda nasıl kontrol edilir?

Aynı isimli iki bina ve aynı binada iki farklı asansör üzerinden kayıt açtırın. Ardından yalnızca sokak adı veya bina yetkilisinin telefonuyla doğru kaydı bulmayı deneyin.

Şu soruların cevaplarını gözlemleyin:

• Asansörler arasında ayrım yapacak açık bir tanımlayıcı var mı?
• Arama sonuçlarında adres ve blok bilgisi birlikte görünüyor mu?
• Çağrı yanlış asansöre bağlandığında düzeltilebiliyor mu?
• Düzeltmenin ardından eski ve yeni ilişki izlenebiliyor mu?

Yanlış cihaza bağlanan eksiksiz bir kayıt, doğru cihaza bağlanan kısa bir kayıttan daha az faydalıdır.

2. Mükerrer Çağrı ile Tekrarlayan Arızanın Ayrılması

Aynı olay için apartman yöneticisi, kapıcı ve bir bina sakini ayrı ayrı arayabilir. Bunların üç bağımsız iş emrine dönüşmesi, iki ekibin aynı yere gönderilmesine yol açabilir. Buna karşılık dün tamamlanan bir müdahalenin ardından bugün yeniden gelen çağrıyı eski kayda eklemek de tekrar eden sorunu gizleyebilir.

Bu nedenle mükerrer çağrı ile tekrarlayan arıza birbirinden ayrılmalıdır. Mükerrer çağrı, devam eden aynı olaya ilişkin ek bildirimdir. Tekrarlayan arıza ise önceki müdahaleden sonra yeniden ortaya çıkan ve ayrıca değerlendirilmesi gereken olaydır.

İyi tasarlanmış bir kayıt akışı, açık çağrıyı görünür kılar ve ek bildirimin bu çağrıya bağlanmasına izin verir. Önceki iş kapanmışsa yeni çağrı açılırken geçmiş müdahale kolayca incelenebilmelidir. Benzer şikâyetler her zaman aynı teknik nedene işaret etmediği için programın kullanıcıya bilgi sunması, teknik değerlendirmeyi ekip adına yapmaması önemlidir.

Demoda aynı asansör için art arda iki bildirim oluşturun. Sonra ilk işi kapatıp ertesi güne yeni bir bildirim ekleyin. Programın bu iki durumu nasıl gösterdiğini karşılaştırın.

3. Önceliklendirme ve Geciken Çağrının Görünürlüğü

Her arıza aynı öncelikte değildir. Kabinde mahsur kalma bildirimiyle, asansör çalışırken duyulan alışılmadık sesin kaydı aynı sırada değerlendirilmemelidir. Bununla birlikte çağrıyı alan çalışan, belirsiz bir açıklamadan teknik teşhis üretmeye zorlanmamalıdır.

Önceliklendirme alanları, bildirimin niteliğini doğru aktarmaya yardımcı olmalıdır. Mahsur kalma bilgisi, bildirilen tehlike, cihazın çalışıp çalışmadığı ve ulaşılabilecek kişinin bilgileri ayrı şekilde kaydedilebilir. Güvenlikle ilgili kararlar firmanın yetkili ekipleri tarafından değerlendirilmelidir.

Kaçırılan diğer özellik, gecikmenin görünür olmasıdır. Çağrı saatinin kaydedilmesi tek başına yeterli değildir. Atanmamış, kabul edilmemiş veya uzun süredir güncellenmemiş işler sorumlu kişinin dikkatine gelmelidir.

Örneğin firmanız kendi hizmet hedefi olarak belirli bir süre içinde ilk geri dönüş yapılmasını istiyorsa, bu hedefi aşan kayıtların nasıl görüleceğini sorun. Burada kullanılan süre, firmanızın belirlediği operasyon hedefidir; genel bir yasal müdahale süresi gibi sunulmamalıdır.

4. Ekip Atama, Görev Kabulü ve Nöbet Devri

“Teknisyen atama var” ifadesi, işin gerçekten teslim alındığını göstermez. Çalışan telefonunu kullanamıyor olabilir, başka bir müdahalede bulunabilir veya vardiyasını tamamlamış olabilir. Ofiste görev atanmış görünürken sahada kimse çağrıdan haberdar olmayabilir.

Bu boşluğu kapatmak için atama, görev kabulü ve müdahale aşamaları ayrı izlenebilmelidir. Firma sorumlusu, işin hangi ekipte olduğunu ve ekibin görevi görüp görmediğini anlayabilmelidir.

Nöbet devrinde ise açık işlerin yeni ekibe aktarılması kadar, önceki notların korunması da önemlidir. “Parça bekleniyor” açıklamasının hangi parça için yazıldığı belli değilse gece ekibi yeniden bilgi toplamaya başlar.

Demoda şu akışı uygulayın:

1. Bir çağrıyı gündüz ekibine atayın.
2. Ekip görevi kabul etsin ve müdahale notu eklesin.
3. İş tamamlanmadan nöbet ekibine devredilsin.
4. Yeni ekip, önceki notları ve bekleyen işlemi görüntülesin.
5. Firma sorumlusu, devir zamanını ve mevcut sorumluyu kontrol etsin.

Bu senaryo, basit bir görev atama gösteriminden daha fazla bilgi verir.

5. “Bekliyor” Durumunun Nedenini Açıklayabilmesi

Arıza yönetiminde en fazla belirsizlik, kapanmayan fakat aktif müdahale de yapılmayan işlerde oluşur. Parça bekleyen, müşteriden onay bekleyen ve binaya erişilemediği için ertelenen işler aynı “bekliyor” durumuna konulduğunda sorumluluk kaybolur.

Her bekleyen iş için en azından bekleme nedeni, sonraki adım ve sorumlu kişi anlaşılmalıdır. Uygunsa tekrar değerlendirme tarihi de belirlenmelidir.

Aşağıdaki tabloyu demo sırasında kullanabilirsiniz:

Gözden kaçan özellik	Sahadaki sorun	Demoda uygulanacak kontrol
Açık çağrı uyarısı	Aynı olay için birden fazla ekip gönderilmesi	Aynı asansöre ikinci çağrıyı açın
Görev kabulünün izlenmesi	Atanan işin ekip tarafından görülmemesi	Kabul edilmemiş görevi listede bulun
Bekleme nedenleri	Açık işlerin neden ilerlemediğinin anlaşılmaması	Parça ve erişim bekleyen iki kayıt oluşturun
Sonraki işlem tarihi	Ertelenen işin unutulması	Yeniden değerlendirme tarihi belirleyin
Nöbet devri	Önceki müdahale bilgisinin kaybolması	Açık işi başka ekibe aktarın
Yeniden açma geçmişi	Tamamlandı görünen sorunun tekrar yaşanması	Kapanan işi gerekçesiyle yeniden açın

Örneğin “kart bekleniyor” notuyla birlikte tedariki takip edecek kişi ve kontrol tarihi belirlenirse ofis ertesi gün ne yapacağını bilir. Serbest metin alanı faydalıdır; ancak tek başına düzenli takip sağlamayabilir.

6. Servis Geçmişinin Sahada Kullanılabilir Olması

Servis geçmişinin sistemde bulunmasıyla teknisyenin bu geçmişi müdahale sırasında kullanabilmesi farklı şeylerdir. Çok sayıda kayıt arasında arama yapmak, özellikle küçük telefon ekranında zaman alabilir.

Teknisyen, ilgili asansörün son müdahalelerini, şikâyetlerini ve değişen parçalarını kolayca görebilmelidir. Notların tarih, işlemi yapan ekip ve sonuç bilgisiyle birlikte sunulması gerekir. “Ayar yapıldı” gibi kısa ifadeler gelecekteki müdahaleye sınırlı katkı sağlar.

Bir örnek üzerinden düşünün: Aynı asansörde son iki çağrı kapı kapanmaması şikâyetiyle açılmış olsun. Üçüncü çağrıya giden ekip, önceki kontrolleri okuyabilirse aynı soruları yeniden sormadan ilerleyebilir. Bununla birlikte geçmişte benzer şikâyet bulunması, yeni olayın nedeninin kesinleştiği anlamına gelmez.

Asansorex gibi bir bakım ve arıza takip yazılımında ilgili asansörün bakım ve müdahale kayıtlarını birlikte tutmak, ekibin geçmişe erişmesini kolaylaştırabilir. Demoda bu erişimi teknisyenin kullanacağı telefon üzerinden denemek gerekir.

Bağlantının zayıf olduğu yerler için de hangi bilgilerin erişilebilir kaldığını ve sonradan girilen kayıtların nasıl eşitlendiğini ayrıca sorun.

7. İş Kapatma, Yeniden Açma ve Değişiklik Geçmişi

“Tamamlandı” düğmesi, işin sonucunu açıklamaz. Teknisyen müdahaleyi tamamlamış olabilir; ancak cihazın mevcut durumu, yapılan işlem veya ilave ziyaret ihtiyacı kayda geçmemiş olabilir.

Kapanışta aşağıdaki bilgiler değerlendirilebilir:

• Bildirilen şikâyet ve gözlenen durum
• Yapılan kontrol ve müdahale
• Kullanılan veya değiştirilen parça
• Müdahale sonundaki cihaz durumu
• Gerekli takip işlemi ve ilgili notlar

Zorunlu alanlar gereksiz veri girişine dönüşmemelidir. Ama her işin yalnızca “giderildi” yazılarak kapanması da servis geçmişini zayıflatır. Firmanın ihtiyaç duyduğu temel kapanış bilgilerinin uygulanabilir olması önemlidir.

Diğer kontrol noktası, yanlış kapanan işin yeniden açılmasıdır. Kayıt silinerek baştan oluşturuluyorsa önceki zamanlar ve işlem geçmişi kaybolabilir. Yeniden açma gerekçesiyle birlikte eski bilgiler korunmalıdır.

Değişiklik geçmişi özellikle müşteri itirazlarında işe yarar. Kimin hangi bilgiyi ne zaman değiştirdiğinin izlenmesi, farklı anlatımlar arasında kayıt üzerinden değerlendirme yapılmasını sağlar.

8. Raporların Anlamı ve Veriyi Dışarı Alma

Satın alma görüşmesinde renkli grafikler dikkat çeker. Ancak “ortalama çözüm süresi” ifadesinin nasıl hesaplandığı bilinmiyorsa rapor yanlış yorumlanabilir. Çağrının açılmasından ilk müdahaleye kadar geçen süreyle, işin tamamen kapanmasına kadar geçen süre farklı ölçümlerdir.

Parça bekleyen işlerin hesaplamaya dahil edilip edilmediğini sorun. Yeniden açılan kayıtların nasıl sayıldığını kontrol edin. Teknisyenleri yalnızca kapattıkları çağrı sayısıyla karşılaştırmak da yanıltıcı olabilir; işlerin zorluğu ve bölgesel koşulları farklıdır.

Raporlardan önce şu tanımları netleştirin:

1. İlk geri dönüş hangi olayla başlıyor?
2. Müdahale başlangıcı nasıl kaydediliyor?
3. Tamamlanma hangi durumu ifade ediyor?
4. Bekleme süreleri ayrıca gösteriliyor mu?
5. Tekrarlayan arıza hangi ölçüte göre belirleniyor?

Veriyi dışarı alma özelliği de ertelenmemelidir. Örnek bir arıza listesini ve tek bir işin ayrıntılı geçmişini dışarı aktarın. Tarihlerin, asansör bilgilerinin ve müdahale notlarının korunup korunmadığını inceleyin. Erişim yetkilerinde ise teknisyenin görev bilgilerine ulaşabilmesiyle, firmanın bütün müşteri verilerini görmesi ayrı değerlendirilmelidir.

Sıkça Sorulan Sorular

Arıza kaydı ve teknisyen atama özellikleri tek başına yeterli mi?

Küçük bir ekipte başlangıç için yeterli görünebilir. Ancak mükerrer çağrılar, görev kabulü, bekleyen işler ve nöbet devri ortaya çıktığında eksikler belirginleşir. Satın alma kararını normal bir çağrıyla birlikte tamamlanamayan bir iş üzerinden de değerlendirin.

Mükerrer çağrıların otomatik birleştirilmesi gerekli mi?

Her durumda otomatik birleştirme doğru olmayabilir. Aynı asansör için farklı bir sorun bildirilmiş olabilir. Açık çağrının görünmesi ve çalışanın ek bildirimi uygun kayda bağlayabilmesi daha kontrollü bir yöntemdir.

Çevrimdışı çalışma nasıl sınanmalı?

Telefonun bağlantısını keserek ilgili geçmişi görüntülemeyi ve müdahale notu kaydetmeyi deneyin. Bağlantı geri geldiğinde kaydın doğru işe işlendiğini kontrol edin. Çevrimdışı erişimin hangi bilgiler ve işlemler için geçerli olduğunu ayrıca öğrenin.

Program arızanın teknik nedenini belirleyebilir mi?

Geçmiş kayıtlar ve düzenli şikâyet bilgileri teknik değerlendirmeye yardımcı olabilir. Ancak kayıt benzerliği teşhis değildir. Arızanın nedeni, gerekli kontrolleri yapan yetkin teknik ekip tarafından değerlendirilmelidir.

Demo için kaç senaryo hazırlamak gerekir?

Doğru asansöre kayıt açma, mükerrer bildirim, görev kabulü, parça bekleme, nöbet devri ve yeniden açma olmak üzere altı senaryo pratik bir başlangıçtır. Firmanızın sık yaşadığı özel bir sorun varsa listeye onu da ekleyin.

Özet

Asansör Arıza Çağrı Programı seçerken temel mesele, çağrının açılabilmesi kadar işin bütün aşamalarının takip edilebilmesidir. Doğru asansör eşleştirmesi, mükerrer bildirimlerin yönetimi, görev kabulü, bekleme nedenleri ve kapanış geçmişi günlük hizmet kalitesini doğrudan etkiler.

Asansorex’i değerlendirirken de kendi firmanızdan seçtiğiniz gerçek çağrı senaryolarını demo akışına taşıyın. Kararınızı özellik isimlerinden çok, ekibin bir sonraki adımı açıkça görebildiği ve açık işlerin sorumlusunun belli olduğu bir çalışma düzenine göre verin.