Asansör Arıza Ticket Programı Kurulumunda Ekip Direnci Nasıl Aşılır?

İÇERİK

Asansör arıza ticket programı kurmak teknik olarak zor görünmeyebilir: firma bilgileri girilir, kullanıcılar açılır, arıza bildirim kanalları belirlenir, teknisyenler sisteme dahil edilir. Fakat gerçek zorluk çoğu zaman yazılımda değil, ekip alışkanlıklarında ortaya çıkar. Yıllardır WhatsApp, telefon, defter, Excel veya sözlü takip ile çalışan bir ekip için “artık her arıza ticket olarak açılacak” demek ciddi bir davranış değişikliğidir. Bu yazıda, asansör bakım firmalarında arıza ticket programı kurulumunda ekip direncinin neden oluştuğunu, nasıl azaltılacağını ve geçişin sahada kalıcı hale nasıl getirileceğini pratik örneklerle ele alacağız.

Ekip Direnci Neden Oluşur?

Bir firmada dijital arıza takip sistemine geçildiğinde ilk tepki genellikle yazılıma değil, değişimin kendisine verilir. Çünkü arıza yönetimi asansör sektöründe günlük iş akışının en stresli alanlarından biridir. Müşteri arar, bina yöneticisi baskı yapar, teknisyen sahadadır, ofis başka bir arızaya cevap verir. Böyle bir düzende yeni sistem eklenince ekip “işimiz kolaylaşacak mı, yoksa üzerimize yeni yük mü gelecek?” diye düşünür.

Direncin temel nedenleri genellikle şunlardır:

• Teknisyenin her işlem için telefondan kayıt girmek istememesi
• Ofis personelinin eski WhatsApp düzenini daha hızlı sanması
• Firma sahibinin sistemden rapor beklemesi ama ekibe yeterli geçiş süresi tanımaması
• Daha önce denenmiş yazılımların yarım kalmış olması
• “Bizi takip etmek için kuruldu” algısının oluşması
• Müşteri portalı, ticket numarası, durum güncellemesi gibi kavramların ilk etapta yabancı gelmesi

Bu direnç kötü niyetli değildir. Çoğu zaman ekip, işi aksatmadan devam ettirmek ister. Bu yüzden ilk yapılması gereken şey direnci bastırmak değil, nedenini anlamaktır.

Dijital dönüşümde en sık yapılan hata, yazılımı kurunca davranışın otomatik değişeceğini düşünmektir. Oysa sahada alışkanlık değişimi, sistem kurulumundan daha fazla emek ister.

Kuruluma Başlamadan Önce Beklentiyi Doğru Anlatın

Arıza ticket programı kurulumunda ilk toplantı çok önemlidir. Bu toplantıda sadece “bundan sonra herkes uygulamayı kullanacak” demek yeterli değildir. Ekip, sistemin kendisine ne kazandıracağını net duymalıdır.

Teknisyen için kazanım şudur: Arıza adresi, bina bilgisi, asansör notları, geçmiş arıza kayıtları ve müşteri talebi tek yerde görünür. Ofis için kazanım şudur: Kim hangi arızaya gitti, hangi arıza açık kaldı, müşteri ne zaman bilgilendirildi gibi bilgiler telefon trafiğine gömülmez. Firma sahibi için kazanım ise operasyonun ölçülebilir hale gelmesidir.

İyi bir başlangıç toplantısında şu sorular açık cevaplanmalıdır:

1. Arıza kaydı kim tarafından açılacak?
2. Müşteri portalından gelen bildirimler nasıl takip edilecek?
3. Teknisyen arızaya giderken hangi bilgileri görecek?
4. Arıza tamamlanınca hangi alanlar doldurulacak?
5. Fotoğraf, açıklama, parça bilgisi veya imza ne zaman istenecek?
6. WhatsApp ve telefon bildirimleri tamamen mi kapanacak, yoksa geçiş sürecinde destek kanal olarak mı kalacak?
7. İlk hafta hata yapan personele nasıl yaklaşılacak?

Bu sorular kurulumdan önce cevaplanmazsa, ekip kendi içinde farklı uygulamalar geliştirir. Bir teknisyen ticket kapatır, diğeri ofise mesaj atar, üçüncüsü hiç kayıt girmez. Sonra firma “program çalışmadı” sanır. Aslında sorun yazılım değil, süreç tanımının eksik olmasıdır.

Direnci Azaltmak İçin Kademeli Geçiş Planı Kurun

Asansör arıza ticket programına geçişte tüm firmayı bir gecede yeni sisteme taşımak çoğu zaman risklidir. Özellikle 500, 1000 veya daha fazla asansöre bakan firmalarda arıza trafiği yoğunsa, geçiş kademeli yapılmalıdır.

Aşağıdaki tablo, pratik bir geçiş planı için örnek olabilir:

Aşama	Süre	Amaç	Dikkat Edilecek Nokta
Hazırlık	2-3 gün	Bina, müşteri, teknisyen ve kullanıcı bilgilerinin kontrolü	Eksik cari ve bina bilgileri geçişi zorlaştırır
Pilot kullanım	1 hafta	Seçili ekip veya bölge ile ticket akışını test etmek	İlk hafta cezalandırma değil gözlem yapılmalı
Karma dönem	1-2 hafta	Telefon/WhatsApp destekli ama ana kayıt ticket üzerinden ilerleyen model	Çift kayıt oluşmaması için ofis sorumlusu belirlenmeli
Tam geçiş	3. veya 4. hafta	Tüm arızaların program üzerinden açılması ve kapanması	Eski yöntem sadece istisnai durumlar için kullanılmalı
Değerlendirme	Ay sonu	Açık arıza, müdahale süresi, kapanış kalitesi gibi KPI’ların incelenmesi	Ekipten geri bildirim alınmalı

Bu plan firmaya göre değişebilir. Küçük bir bakım firmasında geçiş daha hızlı yapılabilir. Ancak ekip sayısı arttıkça eğitim, pilot ve değerlendirme aşaması daha kritik hale gelir.

Asansorex gibi bakım ve arıza takip yazılımlarında arıza kaydı, teknisyen atama, müşteri bildirimi ve geçmiş kayıtların aynı akışta tutulması bu geçişi daha kontrollü hale getirir. Buradaki asıl fayda, herkesin aynı arıza üzerinden konuşmasıdır; ayrı ayrı mesaj zincirleri yerine tek bir kayıt üzerinden ilerlenir.

Teknisyen Direncini Azaltmanın Pratik Yolları

Saha teknisyeni için yazılımın kabul edilmesi, ekran sayısından çok kullanım kolaylığına bağlıdır. Arıza anında teknisyenin önceliği form doldurmak değil, problemi çözmektir. Bu yüzden ticket programı kurulurken teknisyene gereksiz alan yüklenmemelidir.

İlk Gün Her Alanı Zorunlu Yapmayın

Kurulumun ilk gününde çok fazla zorunlu alan açmak direnci artırır. Örneğin arıza nedeni, işlem açıklaması, fotoğraf, parça, süre, müşteri imzası, malzeme seçimi ve detaylı not aynı anda istenirse teknisyen bunu “ofis işi bana yüklendi” diye yorumlayabilir.

İlk aşamada şu alanlar yeterli olabilir:

• Arızaya gidildi bilgisi
• Arıza durumu
• Kısa işlem açıklaması
• Gerekirse fotoğraf
• Tamamlandı veya tekrar gidilecek durumu

Sistem alışkanlığı oturduktan sonra daha detaylı alanlar eklenebilir. Amaç ilk hafta mükemmel veri toplamak değil, ekibin programa düzenli girmesini sağlamaktır.

Sahadaki Gerçek Dili Kullanın

Teknisyen “ticket durumu güncelle” ifadesini soğuk bulabilir. Bunun yerine eğitimde “arızaya gittim”, “işlem devam ediyor”, “parça gerekiyor”, “tamamlandı” gibi sahadaki gerçek ifadeler kullanılmalıdır. Yazılım ekranları ne kadar anlaşılır olursa, ekip o kadar hızlı benimser.

Başarılı Kullanımı Görünür Hale Getirin

Bir teknisyen ticket üzerinden arızayı düzgün kapattığında, ofis müşteriye hızlı bilgi verebiliyorsa bu örnek ekip içinde paylaşılmalıdır. “Bakın sistem işe yaradı” demek yerine somut sonuç gösterilmelidir:

• Müşteri tekrar aramadan bilgilendirildi.
• Aynı binada daha önceki arıza geçmişi görüldü.
• Gereksiz ikinci ziyaret önlendi.
• Açık kalan arıza listeden fark edildi.
• Ay sonunda müdahale süreleri raporlandı.

Bu örnekler teknisyene yazılımın sadece kontrol değil, işini kolaylaştıran bir araç olduğunu gösterir.

Ofis Ekibini Sürecin Merkezine Alın

Arıza ticket programında ofis ekibi kilit roldedir. Çünkü müşteri aramasını çoğu zaman ofis karşılar, portal bildirimlerini ofis takip eder, teknisyen atamasını ofis yapar ve bina yöneticisine bilgi verir. Ofis ekibi sistemi sahiplenmezse, saha ekibinden düzenli kullanım beklemek zorlaşır.

Ofis tarafında dikkat edilmesi gerekenler şunlardır:

• Her telefon araması için ticket açma standardı belirlenmeli.
• Aynı arıza için tekrar kayıt açılmamalı, mevcut kayıt güncellenmeli.
• Müşteri portalından gelen bildirimler düzenli kontrol edilmeli.
• Açık arızalar gün sonunda gözden geçirilmeli.
• Teknisyenin eksik kapattığı kayıtlar yapıcı şekilde geri bildirilmelidir.
• Acil arıza, normal arıza ve tekrar arıza ayrımı net yapılmalıdır.

Özellikle müşteri portalı kullanılan firmalarda bina yöneticisinin bildirdiği arıza doğrudan kayıt altına alınır. Bu durum ofisin işini azaltabilir; fakat sadece portalı açmak yetmez. Müşteriye nasıl arıza bildireceği anlatılmalı, ilk dönemde gelen kayıtlar kontrol edilmeli ve yanlış kategori seçimi gibi durumlar düzeltilmelidir.

Firma Sahibi Ne Yapmalı?

Firma sahibi veya operasyon yöneticisi için en kritik konu tutarlılıktır. Bir gün “her şey programa girilecek” deyip ertesi gün acele durumlarda WhatsApp üzerinden işi yürütmek, ekibe karışık mesaj verir. Geçiş döneminde istisnalar olabilir; fakat ana kural net kalmalıdır.

Firma sahibinin uygulayabileceği adımlar:

1. Geçiş tarihini ve kapsamını yazılı duyurun.
2. İlk hafta hedefi “yüzde yüz doğru veri” değil, “düzenli kullanım” olarak belirleyin.
3. Ekipten gelen makul itirazları not alın.
4. Gereksiz zorunlu alanları sadeleştirin.
5. Gün sonunda açık arızaları birlikte kontrol edin.
6. Programı kullanan ekipleri küçük başarı örnekleriyle öne çıkarın.
7. Eski yöntemleri sınırsız açık bırakmayın.

Burada önemli nokta, sistemi bir denetim sopası gibi kullanmamaktır. Elbette arıza ticket programı sayesinde kimin hangi işe ne zaman gittiği görülebilir. Fakat ilk anlatım “sizi izleyeceğiz” üzerine kurulursa direnç artar. Daha doğru çerçeve şudur: “Müşteri arızası kaybolmasın, açık iş unutulmasın, herkes aynı bilgiye baksın.”

Direnç Noktaları ve Çözüm Önerileri

Aşağıdaki tablo, sahada sık duyulan itirazları ve bunlara verilebilecek pratik cevapları özetler:

Ekipten Gelen İtiraz	Altındaki Gerçek Kaygı	Çözüm Yaklaşımı
“Telefondan yazmak zaman kaybettiriyor.”	Arıza anında ek iş yükü oluşması	İlk etapta kısa açıklama ve durum seçimi yeterli tutulmalı
“WhatsApp daha hızlı.”	Alışılmış iletişim kanalından kopmak istememe	WhatsApp geçici destek kanal olarak kalabilir ama ana kayıt ticket olmalı
“Bizi takip etmek için yapılıyor.”	Kontrol baskısı hissi	Müşteri memnuniyeti, açık iş takibi ve geçmiş kayıt faydası anlatılmalı
“Müşteri portaldan yanlış kayıt açar.”	Ofis düzeninin bozulması	Portal kategorileri sadeleştirilmeli, ilk ay ofis kontrolü yapılmalı
“Ben zaten işi yapıyorum, kayıtla uğraşamam.”	Emek görünmez kalıyor olabilir	Kayıt sayesinde yapılan işin görünür ve raporlanabilir olduğu anlatılmalı
“Eski sistemde sorun yoktu.”	Değişime karşı doğal temkin	Kaybolan arıza, unutulan dönüş, tekrar arama gibi gerçek örnekler gösterilmeli

Bu yaklaşım, tartışmayı kişisel olmaktan çıkarır. Direnç “kullanmak istemiyorlar” diye değil, “hangi noktada zorlanıyorlar?” diye ele alınır.

Başarılı Kurulum İçin Kontrol Listesi

Arıza ticket programı kurulumunda aşağıdaki kontrol listesi geçişi ciddi şekilde kolaylaştırır:

• Bina ve asansör bilgileri güncel mi?
• Müşteri ve bina yöneticisi iletişim bilgileri doğru mu?
• Teknisyen kullanıcıları tanımlandı mı?
• Arıza durumları sade ve anlaşılır mı?
• Acil arıza kriteri ekip tarafından biliniyor mu?
• Müşteri portalı kullanılacaksa müşteriye kısa açıklama yapıldı mı?
• İlk pilot ekip belirlendi mi?
• Gün sonunda açık ticket kontrolü yapılacak kişi belli mi?
• Teknisyenin mobil kullanımda zorlandığı ekranlar not alındı mı?
• İlk ay sonunda müdahale süresi, açık arıza sayısı ve tekrar arıza oranı değerlendirilecek mi?

Bu kontrol listesi yalnızca kurulum için değil, 30 günlük geçiş takibi için de kullanılabilir. Özellikle periyodik bakım, arıza ve revizyon işlerini aynı anda yürüten firmalarda kayıt disiplininin kurulması müşteri tarafında da güven oluşturur.

Sıkça Sorulan Sorular

Asansör arıza ticket programına geçişte ekip direnci normal mi?

Evet, oldukça normaldir. Özellikle uzun süredir WhatsApp, telefon ve defterle çalışan ekiplerde yeni sisteme karşı temkinli yaklaşım olabilir. Önemli olan bu direnci kişisel algılamadan, nedenlerini anlayarak yönetmektir.

Teknisyenler programa kayıt girmek istemezse ne yapılmalı?

İlk aşamada kayıt alanları sadeleştirilmeli ve teknisyenden sadece gerekli bilgiler istenmelidir. Ayrıca programa girilen bilgilerin sahada nasıl fayda sağladığı somut örneklerle gösterilmelidir. “Kayıt girmedin” demek yerine “bu kayıt sayesinde müşteri tekrar aramadan bilgilendirildi” gibi sonuçlar paylaşılmalıdır.

WhatsApp tamamen kapatılmalı mı?

Geçişin ilk döneminde WhatsApp destek kanal olarak kalabilir. Ancak ana arıza kaydı mutlaka ticket programında olmalıdır. Aksi halde bilgiler iki ayrı yerde dağılır ve sistemin faydası azalır. Genel uygulamada 2-3 haftalık karma dönemden sonra ana akışın programa taşınması daha sağlıklıdır.

Müşteri portalı ekip direncini artırır mı?

Doğru kurgulanmazsa artırabilir. Çünkü ofis ekibi “müşteri yanlış kayıt açacak” diye düşünebilir. Ancak portal kategorileri sade tutulur, ilk ay kayıtlar kontrol edilir ve bina yöneticilerine kısa bilgilendirme yapılırsa müşteri portalı arıza bildirimlerini daha düzenli hale getirir.

Arıza ticket programı denetimlerde işe yarar mı?

Arıza kayıtlarının düzenli tutulması, bakım ve servis geçmişinin izlenmesi açısından faydalıdır. Asansör İşletme ve Bakım Yönetmeliği kapsamında bakım kayıtlarının düzenli tutulması önemlidir; ayrıca periyodik muayene süreçlerinde geçmiş işlemlerin hızlı görülebilmesi firmaya operasyonel avantaj sağlar. Burada önemli olan kayıtların eksiksiz ve tutarlı tutulmasıdır.

Asansorex bu süreçte nasıl yardımcı olur?

Asansorex, arıza bildirimi, teknisyen atama, durum takibi, müşteri portalı ve geçmiş kayıtların tek yerde tutulmasına yardımcı olur. Böylece firma sahibi, ofis ve saha ekibi aynı arıza kaydı üzerinden ilerleyebilir; açık işler daha kolay takip edilir.

Özet

Asansör arıza ticket programı kurulumunda ekip direnci, çoğu zaman yazılıma karşı değil, alışkanlık değişimine karşı oluşur. Bu nedenle başarılı geçiş için önce beklenti doğru anlatılmalı, sonra kademeli geçiş planı kurulmalı ve ilk haftalarda ekip cezalandırılmadan desteklenmelidir. Teknisyen için sade kullanım, ofis için net süreç, firma sahibi için tutarlı takip şarttır.

Doğru yönetilen bir geçişten sonra arıza kayıtları kaybolmaz, müşteri bilgilendirmesi hızlanır, açık işler daha görünür hale gelir ve tekrar arızalar daha iyi analiz edilir. Asansorex gibi bir asansör bakım ve arıza takip yazılımı bu noktada firmaya düzenli kayıt, müşteri portalı ve saha koordinasyonu açısından pratik bir altyapı sunar. En iyi sonuç ise yazılım, süreç ve ekip alışkanlığı birlikte ele alındığında ortaya çıkar.