Asansör Arıza Çağrı Programı ile Müşteri Portalından Arıza Bildirimi

İÇERİK

Bir asansör arızası yaşandığında bina yöneticisinin ilk beklentisi, bakım firmasına hızlıca ulaşmak ve çağrının gerçekten kayda alındığını bilmektir. Bakım firmasının ihtiyacı ise arızanın hangi binada, hangi cihazda ve hangi belirtilerle oluştuğunu eksiksiz öğrenmektir. Telefon ve mesajlaşma uygulamalarıyla yürütülen süreçlerde bu iki beklenti çoğu zaman aynı anda karşılanamaz. Asansör Arıza Çağrı Programı ile müşteri portalından arıza bildirimi, çağrının standart bilgilerle açılmasını, doğru ekibe yönlendirilmesini ve müdahale sürecinin taraflarca izlenmesini sağlar.

Bu rehberde müşteri portalının nasıl yapılandırılması gerektiğini, bildirim formunda hangi alanların bulunacağını, acil çağrıların nasıl ayrıştırılacağını ve sistemin müşteri memnuniyetine nasıl katkı sağlayacağını adım adım ele alacağız.

Telefonla Arıza Bildiriminin Yarattığı Sorunlar

Telefon, asansör sektöründe hâlâ en yaygın arıza bildirim kanallarından biridir. Ancak çağrı sayısı arttıkça sözlü iletişim önemli operasyonel riskler doğurur. Arayan kişinin bina adını farklı söylemesi, cihaz numarasını bilmemesi veya arızayı yalnızca “asansör çalışmıyor” şeklinde anlatması teknisyenin hazırlıksız gitmesine neden olabilir.

Yoğun saatlerde firma telefonu başka bir görüşmeyle meşgul olabilir. Gece gelen çağrı nöbetçi personele geç ulaşabilir veya mesajlaşma grubunda gözden kaçabilir. Ayrıca telefon görüşmesinde verilen bilgilerin daha sonra farklı bir sisteme elle girilmesi gerekir. Bu ikinci kayıt işlemi zaman kaybettirir ve hata ihtimalini artırır.

Sık karşılaşılan sorunlar şunlardır:

• Arıza saatinin yaklaşık olarak hatırlanması
• Hangi asansörde sorun olduğunun belirtilmemesi
• Kapıda kalma ile kabinde mahsur kalmanın karıştırılması
• Aynı arıza için birden fazla kişinin ayrı çağrı açması
• Çağrının hangi personele aktarıldığının bilinmemesi
• Teknisyen müdahalesinin müşteriye bildirilmemesi
• Kullanılan parçaların ve yapılan işlemin çağrıyla eşleşmemesi
• Arıza kapatıldıktan sonra aynı sorunun tekrar edip etmediğinin izlenememesi

Müşteri portalı telefonu tamamen ortadan kaldırmak zorunda değildir. Özellikle kabinde mahsur kalma gibi acil durumlarda, doğrudan iletişim kanalı her zaman görünür olmalıdır. Portalın asıl görevi, normal arıza çağrılarını düzenli ve izlenebilir bir akışa dönüştürmektir.

Müşteri Portalından Arıza Bildirimi Nasıl Çalışır?

Müşteri portalı, bakım firmasının hizmet verdiği bina yöneticilerine veya yetkilendirilmiş kişilere açtığı dijital hizmet alanıdır. Yetkili kişi kendi binasına ait asansörleri görür, ilgili cihazı seçer ve arıza kaydı oluşturur. Böylece adres, sözleşme ve cihaz bilgileri her bildirimde yeniden yazılmaz.

Temel işleyiş şu şekilde kurulabilir:

1. Bina yöneticisi kendisine tanımlanan kullanıcı bilgileriyle portala giriş yapar.
2. Arıza bulunan bina ve asansörü seçer.
3. Arıza türünü ve gözlemlediği belirtileri işaretler.
4. Gerekli açıklamayı yazar; sistem destekliyorsa fotoğraf veya video ekler.
5. Telefon numarasını ve sahada iletişim kurulacak kişiyi doğrular.
6. Bildirimi göndererek kayıt numarası alır.
7. Bakım firması çağrıyı değerlendirir ve uygun teknisyeni görevlendirir.
8. Müşteri; kaydın alındığını, teknisyenin atandığını ve çağrının sonuçlandığını portal üzerinden takip eder.

Bu yapı sayesinde müşteri “Arıza kaydım açıldı mı?” sorusuna cevap aramak için tekrar telefon etmek zorunda kalmaz. Bakım firması da çağrıyı kimin, ne zaman ve hangi cihaz için oluşturduğunu net biçimde görür.

Arıza Bildirim Formunda Hangi Bilgiler Bulunmalı?

İyi bir bildirim formu, müşteriyi uzun sorularla yormadan teknisyene yeterli ön bilgiyi sağlamalıdır. Çok kısa form eksik bilgi üretir; gereğinden uzun form ise müşterinin işlemi yarıda bırakmasına yol açar.

Form alanı	Zorunluluk	Sağladığı fayda
Bina ve asansör seçimi	Zorunlu	Çağrının doğru cihazla eşleşmesini sağlar
Arıza türü	Zorunlu	İlk sınıflandırmayı ve önceliklendirmeyi kolaylaştırır
Arıza açıklaması	Zorunlu	Teknisyene sahadaki belirtiyi aktarır
Kabinde mahsur kalma bilgisi	Zorunlu	Acil durumun normal çağrıdan ayrılmasını sağlar
İletişim kurulacak kişi	Zorunlu	Teknisyenin binaya erişimini kolaylaştırır
Fotoğraf veya video	İsteğe bağlı	Ekran kodu ve fiziksel hasar gibi belirtileri gösterir
Arızanın başladığı zaman	İsteğe bağlı	Kesintinin süresini ve tekrar durumunu anlamaya yardım eder
Ses veya koku bilgisi	Koşullu	Mekanik ya da elektriksel belirti hakkında ön fikir verir
Ek not	İsteğe bağlı	Kapı anahtarı, görevli saatleri gibi saha ayrıntılarını aktarır

Arıza türleri anlaşılır olmalı

Müşteriye teknik parça isimleri içeren karmaşık bir liste sunulmamalıdır. Bina yöneticisinin gözlemleyebileceği ifadeler kullanılmalıdır:

• Asansör hiç çalışmıyor
• Kapı açılmıyor veya kapanmıyor
• Kat seviyesinde durmuyor
• Kabinden olağan dışı ses geliyor
• Gösterge veya aydınlatma çalışmıyor
• Asansör belirli bir katta kalıyor
• Kabinde kişi mahsur kaldı
• Diğer

Arıza formu teşhis koymak için değil, doğru ilk bilgiyi toplamak için tasarlanmalıdır. Kesin teknik teşhis, yetkili personelin saha kontrolünden sonra oluşturulmalıdır.

Çağrılar Nasıl Önceliklendirilmelidir?

Her arıza aynı hız ve yöntemle ele alınamaz. Kabinde mahsur kalan bir kişiyle gösterge lambası arızası aynı sıraya konulmamalıdır. Program içerisinde açık bir öncelik mantığı oluşturulması, teknik ekibin zamanını daha doğru yönetmesini sağlar.

Acil çağrılar

Kabinde mahsur kalma, duman veya yanık kokusu, kontrolsüz hareket şüphesi, kapı açıkken hareket gibi can güvenliğini ilgilendirebilecek bildirimler acil olarak değerlendirilmelidir. Böyle bir kayıt geldiğinde yalnızca standart portal bildirimiyle yetinilmemeli; görevli personele anlık bildirim ve gerekiyorsa telefon uyarısı gönderilmelidir.

Müşteriye de net bir uyarı gösterilmelidir:

Kabinde mahsur kalma veya can güvenliğini ilgilendiren durumlarda bildirimi gönderdikten sonra firmanın acil çağrı hattıyla doğrudan iletişim kurun. Asansöre yetkisiz müdahalede bulunmayın.

Yüksek öncelikli çağrılar

Asansörün tamamen hizmet dışı kalması, binada tek asansör bulunması veya hastane ve yoğun kullanımlı yapı gibi özel koşullar yüksek öncelik gerektirebilir. Sözleşme kapsamı ve binanın kullanım biçimi de değerlendirmeye alınmalıdır.

Normal çağrılar

Aydınlatma sorunu, gösterge hatası veya kullanımı tamamen engellemeyen bazı şikâyetler normal iş planına alınabilir. Ancak “normal” sınıfı, kaydın süresiz bekletileceği anlamına gelmez. Her çağrı için hedeflenen dönüş ve müdahale süresi tanımlanmalıdır.

Portal Üzerinden Şeffaf Bir Arıza Süreci Kurma

Müşterinin yalnızca çağrı açabilmesi yeterli değildir. Bildirimin hangi aşamada olduğunu anlayabilmesi de gerekir. Çok fazla teknik ayrıntı göstermek kafa karışıklığı yaratabilir; bunun yerine sade durum ifadeleri tercih edilmelidir.

Örnek durum akışı şöyledir:

• Kayıt alındı: Bildirim bakım firmasına ulaştı.
• İnceleniyor: Çağrının önceliği ve uygun ekip değerlendiriliyor.
• Teknisyen atandı: Sorumlu saha personeli belirlendi.
• Yola çıktı: Teknisyen binaya hareket etti.
• Müdahale başladı: Ekip sahada çalışmaya başladı.
• Parça bekleniyor: İşlem için gerekli parça veya ek çalışma bekleniyor.
• Tamamlandı: Müdahale sonucu sisteme işlendi.
• Kontrol gerekiyor: Tekrar ziyaret veya ek teknik inceleme planlandı.

Durum değişikliklerinde müşteriye SMS, mobil bildirim veya e-posta gönderilebilir. Ancak her küçük işlem için bildirim üretmek yerine müşteri açısından anlamlı aşamalar seçilmelidir. Aşırı bildirim, kısa sürede uyarıların dikkate alınmamasına yol açar.

Asansorex gibi bir bakım ve arıza takip yazılımında müşteri portalından gelen çağrının cihaz kaydı, bakım geçmişi ve görevlendirilen teknisyenle aynı süreçte tutulması; ofis ile saha arasındaki bilgi kopukluğunu azaltır. Böylece yeni çağrı, bağımsız bir mesaj olarak değil, asansörün servis geçmişinin devamı olarak değerlendirilir.

Teknisyen Müdahalesi ve Çağrının Kapatılması

Teknisyen binaya ulaştığında portalda girilen açıklamayı, varsa görselleri ve cihazın önceki arıza geçmişini inceleyebilmelidir. Bu hazırlık, olası nedenleri daha hızlı değerlendirmesine ve gerekli ekipmanla sahaya gitmesine yardımcı olur.

Müdahale sırasında aşağıdaki bilgiler kaydedilmelidir:

• Binaya varış ve çalışmaya başlama zamanı
• Yapılan kontroller
• Tespit edilen arıza nedeni
• Gerçekleştirilen işlem
• Değiştirilen veya kullanılan parçalar
• Asansörün çalışır durumda bırakılıp bırakılmadığı
• Ek kontrol veya parça ihtiyacı
• Teknisyenin açıklaması
• Müşteri yetkilisinin onayı veya imzası
• Gerekliyse işlem öncesi ve sonrası fotoğraflar

Çağrı, yalnızca teknisyen “tamamlandı” düğmesine bastığı için kapatılmamalıdır. Yapılan işlem ve sonuç bilgisi eksikse ofis personeli kaydı kontrol etmelidir. Özellikle geçici çözüm uygulandıysa kayıt “tamamlandı” yerine “takip gerekiyor” gibi uygun bir durumda tutulmalıdır.

Müşteriye gönderilen sonuç metni de anlaşılır olmalıdır. “Kontaktör kontrol edildi” gibi tek satırlık teknik ifade yerine, hangi şikâyetin giderildiği ve cihazın mevcut durumu belirtilmelidir. Teknik detaylar servis formunda ayrıca yer alabilir.

Arıza Geçmişi Neden Önemlidir?

Dijital kayıtların en büyük faydası, yalnızca bugünkü çağrıyı yönetmek değil, tekrar eden sorunları görünür hâle getirmektir. Aynı asansörde bir ay içinde üç kez kapı arızası yaşanıyorsa her çağrıyı bağımsız biçimde kapatmak yeterli değildir. Kayıtlar birlikte incelendiğinde ayar sorunu, yıpranan parça veya kullanım koşulu gibi ortak nedenler değerlendirilebilir.

Düzenli arıza geçmişi aşağıdaki sorulara cevap verir:

• Hangi cihazlar diğerlerine göre daha sık arıza yapıyor?
• Aynı arıza türü ne kadar sürede tekrarlanıyor?
• Ortalama ilk dönüş ve müdahale süresi nedir?
• Arızaların ne kadarı ilk ziyarette sonuçlandırılıyor?
• En fazla parça değişimi hangi cihazlarda gerçekleşiyor?
• Belirli saatlerde veya mevsimlerde çağrı yoğunluğu artıyor mu?
• Hangi binalarda kullanım kaynaklı şikâyetler öne çıkıyor?

Bu analizler bakım planının güncellenmesine, kritik parçaların stokta tutulmasına ve müşteriye daha somut bilgi verilmesine yardımcı olur. Bununla birlikte arıza sayısı tek başına teknisyen performansı olarak yorumlanmamalıdır. Cihazın yaşı, trafik yoğunluğu, yapılan modernizasyonlar ve kullanıcı davranışları birlikte değerlendirilmelidir.

Başarılı Bir Müşteri Portalı İçin Kontrol Listesi

Müşteri portalını tüm binalara açmadan önce küçük bir pilot grupla denemek faydalıdır. Farklı yaş gruplarından ve farklı dijital deneyim seviyelerinden bina yöneticileri seçilerek formun anlaşılabilirliği ölçülebilir.

Uygulama öncesinde şu kontroller yapılmalıdır:

• Portal mobil telefonda rahat kullanılabiliyor mu?
• Kullanıcı yalnızca yetkili olduğu bina ve cihazları görebiliyor mu?
• Şifre yenileme işlemi kolay ve güvenli mi?
• Kabinde mahsur kalma seçeneği belirgin mi?
• Acil çağrı telefon numarası kolayca görülebiliyor mu?
• Aynı arıza için yinelenen kayıtlar fark edilebiliyor mu?
• Kayıt numarası müşteriye anında iletiliyor mu?
• Teknisyen ataması sonrasında durum güncelleniyor mu?
• Tamamlanan işlem müşterinin anlayacağı dille açıklanıyor mu?
• Kişisel veriler yalnızca gerekli amaç ve süre kapsamında işleniyor mu?
• Yetkisi sona eren bina yöneticisinin erişimi kapatılabiliyor mu?
• Portal dışında telefonla gelen çağrılar da aynı sisteme kaydediliyor mu?

Son madde özellikle önemlidir. Portal, telefon, e-posta ve mesajlaşma uygulaması üzerinden gelen kayıtlar farklı yerlerde tutulursa bütüncül arıza geçmişi oluşmaz. Kanal ne olursa olsun her çağrı aynı cihaz kaydı altında toplanmalıdır.

Sıkça Sorulan Sorular

Müşteri portalı telefonla arıza bildirimini tamamen kaldırır mı?

Hayır. Portal, standart arıza kayıtlarını düzenlemek için güçlü bir kanaldır; ancak acil durumlarda doğrudan telefon iletişimi korunmalıdır. Bakım firması hangi durumlarda portalın, hangi durumlarda acil hattın kullanılacağını müşterilerine açıkça anlatmalıdır.

Bina yöneticisi teknik arıza türünü doğru seçemezse ne olur?

Arıza seçenekleri teknik teşhis yerine gözlemlenebilir belirtilerden oluşturulmalıdır. Müşteri yanlış seçenek işaretlese bile ofis personeli veya teknisyen kaydı inceleyerek sınıflandırmayı düzeltebilmelidir.

Kiracılar veya bina sakinleri doğrudan çağrı açabilir mi?

Bu karar bakım firmasının ve bina yönetiminin çalışma modeline bağlıdır. Kontrolsüz erişim yinelenen çağrılar oluşturabilir. Genel uygulamada bina yöneticisi, görevli veya belirlenmiş yetkililere erişim verilmesi daha düzenli sonuç sağlar.

Müşteri portalında hangi bilgiler gösterilmelidir?

Müşteri kendi binasına ait açık ve geçmiş çağrıları, kayıt tarihini, genel durum bilgisini ve tamamlanan işlemin özetini görebilmelidir. Başka müşterilere ait kayıtlar, personel iç notları ve yetki dışındaki ticari bilgiler gösterilmemelidir.

İnternet bağlantısı yoksa nasıl arıza bildirimi yapılır?

Acil çağrı hattı alternatif kanal olarak korunmalıdır. Telefonla alınan bildirim daha sonra görevli personel tarafından Asansör Arıza Çağrı Programı içerisine işlenerek cihaz geçmişine eklenmelidir.

Portal kullanımı müşteri memnuniyetini nasıl etkiler?

Çağrının kaybolmaması, kayıt numarasının paylaşılması ve durumun görülebilmesi belirsizliği azaltır. Memnuniyet yalnızca hızlı müdahaleden değil, müşterinin süreç boyunca düzenli ve doğru bilgilendirilmesinden de etkilenir.

Özet

Asansör Arıza Çağrı Programı üzerinden müşteri portalı kullanmak; bina yöneticisinin standart bilgilerle çağrı açmasını, bakım firmasının kaydı doğru önceliklendirmesini ve teknisyenin hazırlıklı biçimde sahaya yönlendirilmesini sağlar. Başarılı bir sistem; sade bildirim formu, açık acil durum kuralları, anlaşılır durum adımları ve eksiksiz müdahale kayıtları üzerine kurulmalıdır.

Asansorex ile portal üzerinden alınan bildirimlerin asansör geçmişi, saha görevlendirmesi ve servis sonucu ile birlikte tutulması mümkündür. Böyle bir dijital akış, telefon trafiğini azaltırken bakım firması ile bina yöneticisi arasında ölçülebilir ve şeffaf bir hizmet süreci oluşturur.