Asansör Arıza Programı Seçiminde Entegrasyon Checklist

İÇERİK

Bir asansör arıza programı seçerken yalnızca “arıza kaydı açılıyor mu?” sorusuna bakmak yeterli değildir. Gerçek operasyon; müşterinin arıza bildirmesi, teknisyenin görevlendirilmesi, sahaya ulaşması, kullanılan parçanın stoktan düşmesi, yapılan işlemin kayıt altına alınması, gerekiyorsa ücretlendirilmesi ve müşteriye bilgi verilmesi gibi birbirine bağlı birçok adımdan oluşur.

Program bu adımlar arasında bağlantı kuramıyorsa dijitalleşme yalnızca defterin veya Excel dosyasının ekrana taşınması anlamına gelir. Personel yine farklı uygulamalara veri girmek, WhatsApp mesajlarını kontrol etmek, stok bilgisi sormak ve muhasebeye ayrıca bilgi aktarmak zorunda kalır.

Bu nedenle yazılım satın almadan önce kullanılabilecek en doğru yöntemlerden biri bir entegrasyon checklisti hazırlamaktır. Aşağıdaki kontrol noktaları, özellikle birden fazla teknisyeni, yüzlerce asansörü ve yoğun arıza trafiğini yöneten firmaların program seçiminde nelere bakması gerektiğini gösterir.

Asansör Arıza Programında Entegrasyon Neden Önemlidir?

Arıza yönetimi tek başına çalışan bir süreç değildir. Örneğin bina yöneticisi telefonla “asansör çalışmıyor” bilgisini verdiğinde operasyon zinciri başlamış olur.

İdeal senaryoda süreç şu şekilde ilerler:

1. Arıza kaydı oluşturulur.
2. Uygun teknisyen veya ekip belirlenir.
3. Teknisyene bildirim gönderilir.
4. Teknisyen arızayı sahiplenir veya görevi kabul eder.
5. Sahada yapılan işlemler kaydedilir.
6. Kullanılan yedek parçalar sisteme işlenir.
7. Ücretli işlem varsa müşterinin carisine yansıtılır.
8. Gerekirse faturalandırma süreci başlatılır.
9. Müşteriye arızanın çözüldüğü bildirilir.
10. Arıza geçmişi ilgili asansörün kayıtlarında saklanır.

Bu zincirin farklı programlarda veya farklı iletişim kanallarında yürütülmesi hata ihtimalini artırır.

Örneğin teknisyen bir kontaktör değiştirmiş ancak stok sorumlusuna bildirmemiş olabilir. Teknik açıdan arıza çözülmüş görünürken araç stoğu gerçekte eksilmiş olur. Benzer şekilde ücretli bir parça değişimi yapılmış fakat muhasebeye bilgi ulaşmamışsa firma teknik olarak başarılı bir servis vermesine rağmen gelir kaybı yaşayabilir.

İyi entegrasyonun amacı daha fazla özellik göstermek değil, aynı bilginin ikinci kez girilmesini engellemektir.

Temel Entegrasyon Checklist: Programda Neleri Kontrol Etmelisiniz?

Program demosunda yalnızca ekranları incelemek yerine gerçek bir arıza senaryosu üzerinden aşağıdaki bağlantıları test etmek daha sağlıklı sonuç verir.

Entegrasyon	Kontrol Edilecek Nokta	Operasyonel Faydası
SMS	Arıza açılışı ve kapanışında otomatik mesaj	Müşteri bilgilendirmesini hızlandırır
E-posta	Rapor ve servis bilgisinin gönderilmesi	Kurumsal kayıt oluşturur
Mobil saha	Görevin teknisyenin telefonuna düşmesi	Telefon trafiğini azaltır
Konum	Teknisyen veya ekip konumunun görülebilmesi	Yakın ekibin yönlendirilmesini kolaylaştırır
Cari hesap	Ücretli işlemin müşteriye aktarılması	Gelir kaybını azaltır
Stok	Kullanılan parçanın stoktan düşmesi	Gerçek stok bilgisini korur
e-Fatura	Faturalandırılabilir işlemin faturaya aktarılması	Muhasebe sürecini hızlandırır
QR kod	Binadan hızlı arıza kaydı oluşturulması	Doğru asansörün seçilmesini sağlar
Müşteri portalı	Arıza durumunun müşteri tarafından izlenmesi	Tekrarlayan telefonları azaltır
Raporlama	Arıza ve çözüm verilerinin analiz edilmesi	Tekrarlayan sorunları ortaya çıkarır

Buradaki kritik nokta entegrasyonun menüde bulunması değil, uçtan uca çalışmasıdır.

Örneğin “stok entegrasyonu var” denildiğinde şu soruyu sorun:

Teknisyen mobil uygulamadan bir parça kullandığını kaydettiğinde ilgili parçanın araç veya depo stoğu otomatik olarak azalıyor mu?

Cevap yalnızca “stok modülümüz var” ise süreç gerçekten entegre olmayabilir.

SMS, Mobil Uygulama ve Müşteri İletişimi Nasıl Bağlanmalı?

Asansör arızalarında müşterinin en sık sorduğu soru genellikle teknik detay değildir: “Ekip geliyor mu?”

Bu nedenle iletişim entegrasyonları arıza programının önemli parçalarındandır.

SMS entegrasyonu

Programın farklı aşamalarda otomatik veya kontrollü SMS gönderebilmesi yararlıdır.

Örneğin:

• Arıza kaydı oluşturuldu.
• Teknik ekip yönlendirildi.
• Arıza çözüldü.
• Ücretli işlem gerçekleştirildi.
• Servis raporu hazırlandı.

Burada sınırsız bildirim göndermek yerine hangi aşamalarda müşteriye bilgi verilmesi gerektiği firma tarafından belirlenebilmelidir.

Mobil saha entegrasyonu

Teknisyene yalnızca “X binasına git” mesajı göndermek yeterli değildir. Teknisyen mobil tarafta ilgili asansörün geçmişini görebilmeli ve yaptığı işlemi doğrudan kayıt altına alabilmelidir.

İdeal olarak teknisyenin erişebileceği bilgiler arasında şunlar bulunur:

• Bina ve asansör bilgileri
• Arıza açıklaması
• Önceki arıza kayıtları
• Müşteri iletişim bilgileri
• Yapılacak işlem
• Kullanılan parçalar
• Fotoğraf veya servis formu
• Tahsilat veya ücret bilgisi gerekiyorsa ilgili işlem alanı

Asansorex gibi saha ve arıza süreçlerini aynı yapı içerisinde yöneten sistemlerin avantajı da burada ortaya çıkar. Ofiste açılan arızanın saha ekibine aktarılması ve sahadaki işlemin tekrar ofise yazılmasına gerek kalmadan kayıt altına alınması, özellikle yoğun servis operasyonlarında çift veri girişini azaltır.

Müşteri portalı ve QR arıza bildirimi

Müşterinin her arızada telefonla ulaşmak zorunda kalması hem bina yöneticisini hem servis firmasını yorabilir.

QR kod üzerinden doğru bina veya asansör için kayıt oluşturulması, özellikle çok sayıda cihaz yöneten firmalarda yanlış adres ve yanlış cihaz bilgilerinin önüne geçilmesine yardımcı olur.

Müşteri portalı varsa bina yöneticisinin açık ve geçmiş arızaları görebilmesi de ayrıca değerlendirilmelidir.

Cari, Stok ve e-Fatura Entegrasyonu Neden Kritik?

Teknik ekip açısından arıza “asansörü yeniden çalıştırmakla” sona erebilir. Firma sahibi açısından ise süreç burada bitmez.

Değiştirilen parçanın maliyeti, müşteriye yansıtılacak ücret, stok hareketi ve gerekiyorsa faturalandırma da takip edilmelidir.

Örneğin bir teknisyen arıza sırasında:

• 1 adet kontaktör,
• 2 adet kapı makarası,
• 1 adet röle

kullandıysa bu parçaların yalnızca servis açıklamasına yazılması yeterli değildir.

Parçaların stok sistemine bağlanması gerekir. Aksi hâlde ay sonunda sistemde 15 adet görünen bir ürünün depoda yalnızca 4 adet kaldığı fark edilebilir.

Cari entegrasyonunda da benzer bir mantık geçerlidir.

Arıza sözleşme kapsamındaysa müşteriye ek ücret çıkmayabilir. Ancak sözleşme dışı parça değişimi veya ek hizmet gerçekleştirildiyse bu işlem cariye aktarılabilmelidir.

Program seçerken şu soruları sorun:

• Arıza işlemi müşterinin carisine bağlanabiliyor mu?
• Sözleşme içi ve sözleşme dışı işlemler ayrılabiliyor mu?
• Kullanılan parça otomatik olarak stoktan düşüyor mu?
• Araç stoğu ve merkez depo ayrılabiliyor mu?
• Faturalandırılabilir işlemler ayrıca görülebiliyor mu?
• Birden fazla işlemi tek faturada toplamak mümkün mü?
• Kısmi faturalandırma gerektiğinde takip yapılabiliyor mu?

e-Fatura entegrasyonu kullanılıyorsa programın yalnızca fatura kesebilmesi değil, arıza işleminden faturaya kadar veri zincirini koruması önemlidir.

Konum, Rota ve Ekip Yönetimi Entegrasyonunda Ne Aranmalı?

Özellikle büyük şehirlerde arıza yönetiminin önemli maliyetlerinden biri teknisyenlerin yolda geçirdiği zamandır.

Aynı anda üç farklı arıza geldiğini düşünelim:

• A ekibi müşteriden 3 km uzakta,
• B ekibi 18 km uzakta,
• C ekibi başka bir arızayla ilgileniyor.

Operasyon sorumlusu ekiplerin durumunu bilmiyorsa arızayı telefon görüşmeleriyle dağıtmaya çalışır. Bu da hem zaman kaybettirir hem de gereksiz kilometre oluşturabilir.

Konum entegrasyonu bulunan bir sistemde ise karar verilirken en azından ekibin mevcut saha durumu dikkate alınabilir.

Ancak burada önemli bir ayrıntı vardır: konum görmek tek başına rota yönetimi değildir.

Program seçerken şu özellikleri ayrı ayrı kontrol edin:

• Aktif teknisyenlerin konum bilgisi
• Açık arızaların haritada gösterilmesi
• Teknisyenin mevcut görev durumu
• Aynı bölgedeki işlerin gruplanabilmesi
• Yeni arızanın uygun ekibe atanabilmesi
• Müdahale ve çözüm sürelerinin kaydedilmesi

Bu veriler birkaç ay biriktiğinde yalnızca günlük operasyon değil, bölgesel servis planlaması için de değerli hâle gelir.

Örneğin belirli bir ilçede sürekli yoğun arıza oluşuyorsa firmanın ekip dağılımı yeniden planlanabilir.

Programı Satın Almadan Önce Uygulanacak 15 Maddelik Test

Demo sırasında satıcının hazırladığı örnek ekranları izlemek yerine mümkün olduğunca kendi gerçek çalışma şeklinizi test edin.

Aşağıdaki checklist doğrudan kullanılabilir:

1. Yeni bir müşteri ve bina oluşturun.
2. Binaya bir asansör tanımlayın.
3. Bu asansör için arıza kaydı açın.
4. Arızayı bir teknisyene atayın.
5. Teknisyenin görevi mobil tarafta görmesini kontrol edin.
6. Arıza için otomatik bildirim gönderilip gönderilemediğini inceleyin.
7. Teknisyenin fotoğraf ve açıklama eklemesini deneyin.
8. Arızada bir yedek parça kullandırın.
9. Parçanın stoktan düşüp düşmediğine bakın.
10. Sözleşme dışı bir işlem ücreti oluşturun.
11. İşlemin müşterinin cari hesabına yansıyıp yansımadığını kontrol edin.
12. Faturalandırma bağlantısını test edin.
13. Arızayı kapatın ve müşteriye kapanış bildirimi oluşturun.
14. Aynı asansörün geçmiş arızalarını yeniden açın.
15. Arıza süresi, teknisyen ve kullanılan parçaları raporda görüntüleyin.

Bu test yaklaşık olarak programın gerçek hayatta ne kadar bütünleşik çalıştığını ortaya çıkarır.

Ayrıca kullanıcı yetkilendirmesini de atlamayın. Teknisyenin görmesi gereken bilgilerle muhasebe veya firma yöneticisinin erişmesi gereken bilgiler aynı olmayabilir.

2026 Türkiye uygulamasında asansörlerin periyodik kontrolleri A tipi muayene kuruluşları tarafından yürütülür ve yılda en az bir defa periyodik kontrol yaptırılması öngörülür. ([Sanayi Bakanlığı][1]) Arıza programı bu resmi kontrolün yerine geçmez; ancak bakım, servis, arıza ve geçmiş işlem kayıtlarının düzenli tutulması işletme tarafında önemli bir izlenebilirlik sağlar. Asansör İşletme ve Bakım Yönetmeliği de bakım ve işletme süreçleri için temel düzenleyici çerçevelerden biridir. ([Sanayi Bakanlığı][2])

Entegrasyon Seçerken Yapılan En Büyük Hatalar

En sık karşılaşılan hata, uzun özellik listesini güçlü entegrasyon zannetmektir.

Bir programda cari, stok, SMS, arıza ve bakım modüllerinin bulunması bu modüllerin gerçekten birlikte çalıştığı anlamına gelmez.

Örneğin teknisyen arızayı kapattıktan sonra ofis personelinin aynı işlemi stok ekranına, ardından cari hesaba ve daha sonra fatura ekranına tekrar girmesi gerekiyorsa sistemde modüller vardır ancak süreç bütünleşik değildir.

İkinci hata yalnızca bugünkü firma büyüklüğüne göre seçim yapmaktır.

Bugün:

• 2 teknisyen,
• 150 asansör,
• günde 5 arıza

ile çalışan firma birkaç yıl sonra daha fazla ekip ve daha yoğun operasyon yönetebilir. Bu nedenle ekip sayısı arttığında sistemin nasıl davranacağı da sorgulanmalıdır.

Üçüncü hata ise entegrasyonun toplam maliyetini sormamaktır.

SMS, e-Fatura veya farklı dış servis bağlantılarında kullanım bazlı ücretler bulunabilir. Satın alma öncesinde hangi hizmetlerin lisansa dahil olduğu, hangilerinin kontör veya kullanım bazlı ücretlendirildiği açıkça öğrenilmelidir.

Sıkça Sorulan Sorular

Asansör arıza programında en önemli entegrasyon hangisidir?

Tek bir entegrasyon seçmek doğru değildir. Ancak saha operasyonu açısından mobil teknisyen uygulaması; ticari operasyon açısından ise cari ve stok bağlantıları en kritik alanlar arasındadır. Programın asıl değeri bu parçaların birlikte çalışmasından gelir.

SMS entegrasyonu zorunlu mudur?

Her firma için zorunlu değildir ancak yoğun arıza trafiği bulunan işletmelerde müşteriye otomatik bilgi verilmesini ciddi ölçüde kolaylaştırabilir. Özellikle arıza kaydı, ekip yönlendirmesi ve kapanış aşamalarında faydalıdır.

Arıza programının stok modülü olması yeterli mi?

Hayır. Önemli olan arıza sırasında kullanılan parçanın stok hareketiyle ilişkilendirilebilmesidir. Teknisyen parçayı kaydettikten sonra ofiste yeniden stok çıkışı yapmak gerekiyorsa entegrasyonun faydası azalır.

e-Fatura entegrasyonu neden arıza yönetimiyle bağlantılı olmalı?

Sözleşme dışı parça veya hizmetler ücretlendirildiğinde işlemin arıza kaydından cari hesaba ve gerektiğinde faturaya aktarılması veri tekrarını azaltır. Böylece teknik işlem ile ticari kayıt arasındaki bağlantı korunabilir.

Küçük bakım firmalarının bu kadar entegrasyona ihtiyacı var mı?

Her özelliğin ilk günden kullanılması gerekmez. Ancak firma büyüdüğünde yeniden yazılım değiştirmemek için ihtiyaç duyulabilecek temel entegrasyonların sistemde bulunması avantaj sağlar. Küçük firmalar önce arıza, mobil saha ve müşteri iletişimiyle başlayıp diğer modülleri kademeli kullanabilir.

Program seçiminde demo sırasında ne yapılmalı?

Hazır sunumu izlemek yerine gerçek bir arızayı baştan sona sisteme işletmek en iyi testlerden biridir. Arıza oluşturun, teknisyene gönderin, parça kullandırın, cariye yansıtın ve kaydı kapatın. Böylece entegrasyonların gerçekten birlikte çalışıp çalışmadığı görülebilir.

Özet

Doğru asansör arıza programı, yalnızca arıza kaydı tutan bir ekran değil; müşteri bildirimiyle başlayıp teknisyen görevlendirme, saha işlemleri, stok, cari hesap, faturalandırma ve raporlamaya kadar uzanan operasyon zincirini birbirine bağlayan bir sistem olmalıdır.

Program seçerken “Bu özellik var mı?” sorusundan çok, “Bu özellik arıza sürecindeki diğer kayıtlarla otomatik bağlantı kuruyor mu?” sorusunu sorun.

SMS, mobil saha, QR arıza bildirimi, müşteri portalı, konum, stok, cari ve e-Fatura gibi bağlantıları gerçek bir senaryo üzerinden test etmek satın alma sonrasında yaşanabilecek birçok sorunu önceden görmenizi sağlar.

Asansorex gibi asansör sektörüne özel geliştirilen bakım ve arıza yönetim yazılımlarında arıza, teknisyen, stok, cari ve müşteri iletişimi gibi süreçlerin aynı operasyon akışı içerisinde yönetilebilmesi, özellikle büyüyen bakım firmalarında manuel veri aktarımını azaltmaya yardımcı olur. Yazılım seçiminde ise marka veya özellik sayısından önce, firmanızın gerçek arıza sürecini uçtan uca ne kadar karşılayabildiğine bakmak en sağlıklı yaklaşımdır.