Asansör Arıza Ticket Programı için Pilot Müşteri Seçimi

İÇERİK

Bir asansör arıza ticket programını denemek için ilk akla gelen yöntem, sistemi en yakın çalışılan binada açmaktır. Fakat uygun bir pilot müşteri, yalnızca ulaşılması kolay olan müşteri değildir. Çok az arıza çıkan bir bina programı sınamaz; sürekli sorun yaşanan bir bina ise ekibin yeni çalışma düzenine alışmasını güçleştirebilir. Doğru seçim, günlük arıza akışını gösterecek kadar hareketli, sonuçları değerlendirecek kadar düzenli bir müşteri grubudur. Bu rehberde hangi binaların seçileceğini, bina yöneticisiyle neyin konuşulacağını ve pilot sonunda hangi verilere bakılacağını adım adım bulacaksınız.

Pilot çalışmanın amacını önce belirleyin

Pilot uygulama, yazılımın ekranda çalıştığını görmek için yapılmaz. Asıl soru şudur: Bir arıza bildirimi geldiğinde bilgi kaybolmadan doğru teknisyene ulaşıyor, yapılan işlem kayıt altına alınıyor ve bina yöneticisi sonucu anlayabiliyor mu?

Firmanız bugün çağrıları telefon, WhatsApp ve ofis notlarıyla takip ediyorsa pilotun önceliği kaçan bildirimleri bulmak olabilir. Çağrılar zaten kayıtlı fakat kapanış açıklamaları yetersizse teknisyen kayıtlarının kalitesine odaklanabilirsiniz. Bina yöneticileri sürekli “Ne zaman gelinecek?” diye arıyorsa durum bilgilendirmesini ölçmek daha anlamlıdır.

Başlangıçta iki veya üç hedef seçin. Örneğin:

• Bildirilen her arızanın tek bir kayıt numarasıyla izlenmesi
• Çağrının alındığı saat ile teknisyene iletildiği saatin görülebilmesi
• Müdahale sonrasında yapılan işlemin ve sonucun anlaşılır biçimde yazılması

Bu hedefler, pilot için müşteri seçimini de kolaylaştırır. Durum bilgilendirmesini sınamak istiyorsanız iletişime açık bir bina yöneticisine ihtiyacınız vardır. Teknisyen yönlendirmesini sınamak istiyorsanız farklı ekiplerin hizmet verdiği binalar daha öğretici olacaktır.

Pilot müşteri adaylarını nasıl karşılaştırmalısınız?

Tek bir “ideal bina” aramak yerine, birkaç binadan oluşan küçük bir grup kurun. Böylece sonuçları yalnızca bir yöneticinin alışkanlığına veya bir asansörün arıza geçmişine bağlamazsınız. Başlangıç için farklı özellikler taşıyan 3–5 bina yönetilebilir bir kapsam olabilir; uygun sayı firmanızın günlük çağrı hacmine ve pilotu izleyecek kişinin zamanına bağlıdır.

Adayları seçerken son birkaç aydaki kendi servis kayıtlarını inceleyin. Arıza sayısı kadar, bildirimlerin nasıl geldiğine de bakın. Yönetici mi arıyor, güvenlik görevlisi mi haber veriyor, farklı sakinlerden aynı arıza için tekrar çağrı geliyor mu? Ticket düzeninin faydası çoğu zaman bu ayrıntılarda ortaya çıkar.

Seçim ölçütü	Pilot için uygun işaret	Dikkat edilmesi gereken durum
Arıza sıklığı	Ölçüm yapmaya yetecek sayıda bildirim var	Neredeyse hiç çağrı gelmiyor veya olağan dışı yoğunluk var
İletişim düzeni	Yönetici ya da yetkili bir muhatap belli	Bildirimi kimin yaptığı ve kimin bilgilendirileceği belirsiz
Ekip çeşitliliği	Birden fazla teknisyenin iş akışı gözlenebilir	Sonuç yalnızca tek kişinin alışkanlığını yansıtıyor
Bina profili	Firmanın olağan müşteri portföyünü temsil ediyor	Bina, portföydeki diğer müşterilerden çok farklı
Geri bildirim	Yönetici kısa değerlendirmeler yapmaya istekli	Deneme süresince iletişim kurulamıyor
Kayıt geçmişi	Önceki arızalara ilişkin karşılaştırma verisi var	Başlangıç durumu bilinmediği için ilerleme ölçülemiyor

Tabloyu katı bir eleme listesi olarak kullanmayın. Örneğin kayıt geçmişi zayıf olan bir bina yine pilotta yer alabilir; ancak o bina için “önceye göre yüzde kaç iyileştik?” sonucunu güvenle çıkaramazsınız. Ölçebileceğiniz sonuçlarla öğrenmek istediğiniz iş akışını eşleştirin.

Temsil edici, fakat yönetilebilir bir bina grubu kurun

Pilot grubundaki bütün binalar birbirinin kopyası olmamalı. Bir apartman, yoğun kullanımlı bir iş yeri ve birden fazla asansörü olan site farklı bildirim alışkanlıkları gösterebilir. Ancak ilk denemeye firmanızın hiç alışık olmadığı bütün istisnaları aynı anda eklemek de sorunların kaynağını görmeyi zorlaştırır.

Pratik bir seçim şu şekilde yapılabilir:

• Alışılmış müşteri: Firmanızın sık hizmet verdiği bina tipini temsil eder. Günlük kullanımın nasıl işleyeceğini gösterir.
• İletişimi yoğun müşteri: Aynı olay hakkında birden fazla kişinin haber verdiği bir binadır. Mükerrer bildirimlerin nasıl yönetildiğini görmenizi sağlar.
• Operasyonu biraz daha karmaşık müşteri: Birden fazla asansörü veya farklı ulaşılabilirlik saatleri vardır. Doğru asansörü seçme ve doğru kişiyi bilgilendirme akışını sınar.

Seçimde geçmiş arıza adedini tek başına başarı ölçüsü yapmayın. Bir binada aynı parçaya bağlı tekrar eden arızalar varsa bu, ticket programından ayrı bir teknik inceleme gerektirebilir. Program kaydı ve takibi iyileştirebilir; arızanın fiziksel nedenini kendiliğinden ortadan kaldırmaz.

Acil güvenlik durumlarında pilot işleyişine alışılmasını beklemeyin. Yolcu mahsur kalması veya güvenlik riski içeren bir bildirimde firmanızın mevcut acil müdahale usulü ve yetkili kişilere ulaşma düzeni önceliklidir. Ticket kaydı, müdahaleyi desteklemeli ve yapılan işlemleri belgelemelidir.

Bina yöneticisiyle pilotun sınırlarını açıkça konuşun

Pilot müşteriyi seçtikten sonra yöneticiye yalnızca “Yeni bir uygulama deniyoruz” demek yeterli değildir. Bildirim için hangi kanalın kullanılacağı, kimin durum bilgisi alacağı ve acil durumda nasıl iletişim kurulacağı açık olmalıdır. Yönetici bu düzeni bina sakinlerine aktaracaksa kısa ve anlaşılır bir metin işini kolaylaştırır.

Görüşmede şu konuları netleştirin:

• Arızayı bildirecek yetkili kişiler kimler?
• Arıza hangi telefon numarası veya belirlenmiş kanal üzerinden bildirilecek?
• Bildirim sırasında bina, asansör ve olay hakkında hangi bilgiler istenecek?
• Teknisyenin yola çıkması, müdahale etmesi ve işi tamamlaması hakkında kim bilgilendirilecek?
• Yolcu mahsur kalması gibi acil hallerde doğrudan aranacak numara hangisi?
• Pilot sonunda yöneticiden hangi geri bildirim alınacak?

Bina yöneticisinden her ticket için uzun bir form doldurmasını beklemeyin. İlk bildirimde konum, hangi asansör olduğu, sorunun ne zaman fark edildiği ve içeride kişi bulunup bulunmadığı gibi temel bilgilerin doğru aktarılması daha değerlidir. Teknik teşhisi sahadaki yetkili ekip yapar.

Yöneticinin pilotu kabul etmesini kolaylaştıran şey yeni bir ekran göstermek değil, bildiriminden sonra ne olacağını bilmesidir. Ayrıca kişisel iletişim bilgilerinin kimlerle paylaşılacağı ve hangi amaçla kullanılacağı konusunda firmanızın yerleşik veri işleme düzenine uygun, açık bir bilgilendirme yapılmalıdır.

Pilot başlamadan önce başlangıç verisini kaydedin

Yeni program kullanılmaya başladıktan sonra eski yöntemin ne kadar iyi çalıştığını hatırlamak güçleşir. Bu yüzden pilot öncesinde seçilen binaların yakın dönem arıza kayıtlarından basit bir başlangıç tablosu çıkarın. Veriler eksikse bunu da not edin; eksik kayıt, pilotun çözmeye çalıştığı sorunlardan biri olabilir.

Aşağıdaki göstergeler yeterli bir başlangıç sağlar:

• Bildirilen toplam arıza sayısı
• Bildirimin alındığı saatin kayıtlı olduğu işlerin oranı
• Teknisyene yönlendirme bilgisinin bulunduğu işlerin oranı
• Yapılan işlemin anlaşılır biçimde yazıldığı işlerin oranı
• Aynı arıza için tekrar iletişim kurulup kurulmadığı
• İş kapandıktan sonra yöneticiye sonuç bilgisinin verilip verilmediği

Süreleri ölçerken tanımları baştan belirleyin. “İlk yanıt”, ofisin telefonu açması mı yoksa teknisyenin görevi kabul etmesi mi? “Çözüm”, asansörün yeniden çalışması mı yoksa gerekli parçanın sipariş edilmesi mi? Ekip içinde aynı terimlere farklı anlamlar verilirse pilot sonundaki rakamlar karar vermeyi kolaylaştırmaz.

Asansorex gibi bir asansör bakım ve yönetim yazılımında arıza bildirimini, görevlendirmeyi ve servis geçmişini aynı kayıt üzerinden takip etmek bu karşılaştırmayı kolaylaştırabilir. Yine de faydayı görmek için pilot öncesi tanımları ve kayıt disiplinini firmanın kendisi oluşturmalıdır.

Pilot sırasında haftalık kontrol yapın

Pilotun bitmesini bekleyip yalnızca toplam arıza sayısına bakmayın. İlk hafta yanlış bina seçimi, eksik telefon numarası veya kapanış notlarının boş bırakılması gibi sorunlar görülebilir. Bunlar erken düzeltilirse deneme süresinin geri kalanı daha anlamlı veri üretir.

Haftada bir kez ofis sorumlusu ile pilotta çalışan teknisyenler kısa bir değerlendirme yapabilir. Beş örnek ticket açıp şu soruları sorun: Bildirim doğru asansöre bağlanmış mı? Öncelik anlaşılır mı? Teknisyen sahada ne gördüğünü yazmış mı? Parça bekleniyorsa kayıt “tamamlandı” diye kapatılmış mı? Yöneticiye verilen bilgi teknik sonuçla tutarlı mı?

Bina yöneticisine de kısa bir geri bildirim fırsatı verin. “Durumu öğrenmek için tekrar aramak zorunda kaldınız mı?” ve “Sonuç açıklaması anlaşılır mıydı?” soruları, genel bir memnuniyet puanından daha uygulanabilir cevaplar verir. Teknisyen açısından ise hangi bilgilerin işe yaradığına ve hangi alanların gereksiz zaman aldığına bakın.

Pilot sırasında birden fazla bildirim kanalı açık kalacaksa, gelen her bildirimin ticket kaydına nasıl aktarılacağını belirleyin. Telefonla alınan çağrının sistem dışında kalması, pilotun başarısız olduğu anlamına gelmeyebilir; fakat iş akışında kapatılması gereken somut bir boşluğu gösterir.

Yaygınlaştırma kararını hangi sonuçlarla verirsiniz?

Pilot sonunda tek bir başarı oranı aramayın. Önce hedeflerinize dönün: Bildirimlerin ne kadarı kayda girdi? Görevlendirme bilgisi izlenebiliyor mu? Yönetici işin durumunu öğrenebiliyor mu? Teknisyenler kapanış kaydını işi bitirdiği anda yazabiliyor mu?

Sonuçları üç grupta değerlendirmek yararlıdır:

• İşe yarayan akışlar: Ek düzenleme gerektirmeden başka binalara taşınabilecek uygulamalar.
• Düzeltilmesi gereken akışlar: Eksik bina bilgisi, belirsiz sorumluluk veya yetersiz eğitim nedeniyle aksayan noktalar.
• Henüz ölçülemeyen sonuçlar: Pilot boyunca yeterli sayıda yaşanmayan arıza türleri veya çok az veri bulunan binalar.

Örneğin bütün çağrılar kayıt altına alınmış, fakat teknisyenlerin yarısı işin sonucunu yalnızca “yapıldı” diye yazmış olabilir. Bu durumda yeni müşterileri eklemeden önce kısa bir kapanış standardı belirlemek daha doğru olur: şikâyet, sahada görülen durum, yapılan işlem ve işin mevcut durumu. Parça bekleyen işlerin açık kalması veya bekleme durumuyla görünmesi de ayrıca kontrol edilmelidir.

Asansorex üzerinde pilot binaların arıza geçmişini incelemek, bu tür eksik kayıtları ve tekrar eden başvuruları görmenize yardımcı olabilir. Kararı verirken programdaki verileri bina yöneticisi ve teknisyen geri bildirimiyle birlikte okuyun. İyi bir pilotun çıktısı yalnızca “devam edelim” kararı değil, diğer müşterilere geçerken uygulanacak net bir çalışma düzenidir.

Sıkça Sorulan Sorular

Pilot için en sorunsuz bina mı seçilmeli?

Hayır. Hiç arıza bildirimi gelmeyen bir bina, çağrıdan kapanışa kadar olan akışı sınamak için yeterli veri üretmez. Firmanızın olağan iş yükünü temsil eden ve yöneticisi geri bildirim verebilen bir bina daha uygundur.

Sürekli arıza çıkaran bir bina pilotta yer alabilir mi?

Yer alabilir, fakat tek pilot müşteri olmamalıdır. Tekrarlayan teknik sorunların etkisini, bildirim ve takip sürecindeki sorunlardan ayırmanız gerekir. Aksi halde programın performansını yalnızca arıza sayısına bakarak yanlış değerlendirebilirsiniz.

Pilot ne kadar sürmeli?

Süreyi takvimden çok, gözlemlemek istediğiniz çağrı sayısına göre belirleyin. Seçilen binalarda yeterli arıza oluşmazsa daha uzun izleme veya ek bina gerekebilir. Başlangıç ve bitiş tarihini, haftalık kontrol günlerini önceden kararlaştırın.

Bina yöneticisi ticket programını kullanmak zorunda mı?

Bu, firmanızın seçtiği bildirim akışına bağlıdır. Yönetici telefonla bildirmeye devam etse bile ofisin çağrıyı düzenli biçimde kaydetmesi mümkündür. Esas konu, bildirimin kaybolmaması ve yöneticinin sonucunu öğrenebilmesidir.

Pilot başarısız görünürse yazılımdan vazgeçmek gerekir mi?

Önce sorunun kaynağını ayırın. Yanlış bina bilgisi, eksik kullanıcı eğitimi veya belirsiz kapanış kuralları düzeltilebilir süreç sorunlarıdır. Aynı aksaklıklar açık kurallara rağmen sürüyorsa çözümün firmanızın çalışma biçimine uygunluğunu yeniden değerlendirin.

Özet

Asansör arıza ticket programı için pilot müşteri seçerken yalnızca yakınlığı veya iyi ilişkiyi ölçüt almayın. Arıza sıklığı, bina profili, iletişim düzeni, geçmiş kayıtlar ve yöneticinin geri bildirim isteği birlikte değerlendirilmelidir. Küçük ve çeşitli bir bina grubuyla başlayın; pilot öncesi durumu kaydedin, haftalık örnek işleri inceleyin ve yaygınlaştırma kararını hem kayıt kalitesine hem sahadaki deneyime dayandırın.