İçeriğe geç
Asansör bakım, servis ve montaj firmaları için yazılım
Asansör Arıza Çözümleri

Asansör Arıza Ticket Programı İçin Teknik Şartname Maddeleri

Asansör arıza ticket programı alırken teknik şartnameye hangi maddeler eklenmeli? Mobil kullanım, müşteri bildirimi, SLA, raporlama ve denetim kayıtları için pratik rehber.

İÇERİK

Asansör bakım firmaları için arıza yönetimi artık sadece telefona gelen çağrıyı teknisyene iletmekten ibaret değil. Bir arıza kaydının kim tarafından açıldığı, hangi asansöre ait olduğu, teknisyenin ne zaman yönlendirildiği, hangi parçanın değiştiği, bina yöneticisine nasıl bilgi verildiği ve tekrar arıza olup olmadığı net biçimde izlenmelidir. Bu nedenle asansör arıza ticket programı satın alırken ya da teklif toplarken teknik şartname hazırlamak, sonradan yaşanacak birçok karışıklığı önler.

Bu yazıda, asansör firmalarının 2026 Türkiye şartlarında kullanabileceği teknik şartname maddelerini pratik bir dille ele alacağız. Amaç, yalnızca yazılım almak değil; saha, ofis, müşteri ve denetim tarafını aynı kayıt düzeninde buluşturan doğru sistemi seçmektir.

Teknik Şartname Neden Gerekli?

Birçok firma arıza takip programı araştırırken sadece “arıza kaydı açılıyor mu?” sorusuna bakar. Oysa gerçek hayatta ihtiyaç daha geniştir. Arıza kaydı açılır, teknisyene atanır, müşteri aranır, parça değişir, ücret oluşur, fotoğraf eklenir, fiş yazdırılır, bazı durumlarda fatura kesilir ve en sonunda geçmiş kayıtlar tekrar incelenir.

Teknik şartname, bu sürecin net tarifidir. Şartname olmadan alınan yazılımda şu sorunlar sık görülür:

  • Mobil uygulama vardır ama offline çalışmaz.
  • Arıza kaydı açılır ama bina veya asansör geçmişiyle bağ kurulmaz.
  • Rapor alınır ama tekrar arıza oranı ölçülemez.
  • Müşteri portalı vardır ama yöneticinin göreceği bilgiler sınırlanamaz.
  • Fiş çıktısı alınır ama firma formatına uygun değildir.
  • Kullanıcı yetkileri belirsiz olduğu için herkes her kayda müdahale eder.

Bu yüzden şartname, satın alma sürecinde sadece “teknik evrak” değil, firmanın çalışma düzenini koruyan bir kontrol listesidir.

Temel Arıza Ticket Modülü Maddeleri

Şartnamenin ilk bölümü, arıza ticket sisteminin temel işleyişini anlatmalıdır. Burada hedef, her arızanın benzersiz bir kayıt numarasıyla takip edilmesi ve geçmişte kaybolmamasıdır.

Teknik şartnameye şu maddeler eklenebilir:

  • Sistem, her arıza bildirimi için otomatik ve benzersiz ticket numarası oluşturmalıdır.
  • Arıza kaydı; müşteri, bina, asansör, arıza tipi, açıklama, tarih ve öncelik bilgileriyle açılabilmelidir.
  • Arıza kaydı manuel olarak ofis tarafından açılabilmeli, ayrıca müşteri portalı veya QR kod üzerinden bildirime uygun olmalıdır.
  • Arıza durumları en az Yeni, Atandı, Yolda, İşlemde, Çözüldü, Kapatıldı, İptal gibi aşamalarla takip edilebilmelidir.
  • Her durum değişikliği tarih, saat ve kullanıcı bilgisiyle kayıt altına alınmalıdır.
  • Aynı asansör için geçmiş arızalar kolayca görüntülenebilmelidir.
  • Arıza kaydına fotoğraf, açıklama, kullanılan malzeme, teknisyen notu ve müşteri imzası eklenebilmelidir.
  • Acil arızalar için öncelik seviyesi tanımlanabilmelidir.

Burada önemli nokta, arızanın sadece “kapatıldı” olarak görünmesi değil, hangi süreçten geçerek kapandığının anlaşılmasıdır. Özellikle sık arıza yapan asansörlerde geçmiş kayıtlar, bakım kalitesi ve parça değişim kararları için ciddi veri sağlar.

Mobil Kullanım ve Teknisyen Tarafı

Asansör arıza yönetiminde en kritik taraf sahadır. Ofiste düzgün görünen sistem, teknisyenin telefonunda yavaş, karmaşık veya eksik çalışıyorsa beklenen fayda alınamaz. Bu nedenle şartnamede mobil kullanım maddeleri açık yazılmalıdır.

Şartname Başlığı Beklenen Özellik Sahadaki Faydası
Mobil uygulama Android ve iOS desteği Teknisyen cihaz bağımlılığı azalır
Offline çalışma İnternet yokken kayıt alabilme Bodrum, makine dairesi, zayıf çekim alanlarında iş durmaz
Fotoğraf ekleme Öncesi/sonrası görsel yükleme Parça değişimi ve hasar ispatı kolaylaşır
Konum ve zaman kaydı İşe başlama/bitirme saatleri Müdahale süresi ölçülür
Fiş/PDF çıktısı Servis formu oluşturma Bina yöneticisine net belge sunulur
İmza alma Dijital müşteri onayı “Servis yapılmadı” itirazları azalır

Mobil tarafta şartnameye eklenebilecek örnek madde:

Teknisyen, kendisine atanan arıza ticket kaydını mobil cihazından görüntüleyebilmeli; işlem notu, fotoğraf, kullanılan parça, çalışma süresi ve müşteri onayı ekleyerek kaydı sahadan tamamlayabilmelidir.

Bu madde basit görünür ama uygulamada çok şey değiştirir. Teknisyen ofise dönmeden kayıt tamamlanır, müşteri bilgilendirilir, ofis de güncel durumu anlık görür. Asansorex gibi asansör bakım ve arıza takip yazılımları, bu tip saha kayıtlarını tek müşteri ve asansör geçmişinde topladığı için özellikle yoğun çalışan firmalarda takip yükünü azaltır.

Müşteri Bildirimi ve Portal Maddeleri

Arıza yönetiminde bina yöneticisi veya apartman görevlisi de sürecin parçasıdır. Eğer müşteri sürekli “Usta geldi mi?”, “Arıza kapandı mı?”, “Hangi parça değişti?” diye arıyorsa, ticket sistemi ofisteki telefon yükünü azaltmıyor demektir.

Teknik şartnamede müşteri tarafı için şu maddeler değerlendirilebilir:

  1. Müşteri, yetkisi dahilindeki bina ve asansörlere ait arıza kayıtlarını görüntüleyebilmelidir.
  2. Müşteri portalı üzerinden yeni arıza bildirimi yapılabilmelidir.
  3. QR kod ile asansör üzerinden arıza bildirimi alınabilmelidir.
  4. Arıza durumu değiştiğinde müşteriye SMS, e-posta veya uygulama bildirimi gönderilebilmelidir.
  5. Müşteri, tamamlanan servis formunu PDF olarak görüntüleyebilmelidir.
  6. Portalda yalnızca müşteriyi ilgilendiren bilgiler gösterilmeli; firma içi notlar müşteri ekranına yansımamalıdır.

Burada hassas nokta bilgi seviyesidir. Bina yöneticisi için “arıza alındı, teknisyen yönlendirildi, işlem tamamlandı” bilgisi yeterli olabilir. Ancak firma içi maliyet, personel değerlendirmesi veya özel notlar müşteriye açılmamalıdır. Bu nedenle şartnamede kullanıcı yetkilendirme maddeleri ayrıca yazılmalıdır.

Raporlama ve KPI Şartları

Bir asansör arıza ticket programının değeri sadece kayıt tutmasında değil, bu kayıtlardan anlamlı rapor üretmesindedir. Firma sahibi için en kritik konular; müdahale süresi, tekrar arıza oranı, en çok arıza yapan bina, en yoğun teknisyen ve parça kullanım maliyetidir.

Şartnameye şu rapor maddeleri eklenebilir:

  • Tarih aralığına göre açılan, çözülen ve bekleyen arıza sayısı raporlanmalıdır.
  • Bina, müşteri, asansör ve teknisyen bazlı arıza raporu alınabilmelidir.
  • Ortalama ilk müdahale süresi ve ortalama çözüm süresi hesaplanabilmelidir.
  • Tekrar arıza analizi yapılabilmeli; aynı asansörde belirli süre içinde tekrarlayan arızalar listelenebilmelidir.
  • Kullanılan parça ve malzeme bilgileri arıza kaydıyla ilişkilendirilebilmelidir.
  • Raporlar Excel veya PDF formatında dışa aktarılabilmelidir.
  • Yönetici, açık ve geciken arızaları tek ekranda görebilmelidir.

Tekrar Arıza Takibi Neden Önemli?

Tekrar arıza, asansör firması için hem maliyet hem itibar riskidir. Aynı binaya kısa sürede tekrar gitmek yakıt, zaman, personel ve müşteri memnuniyeti kaybı anlamına gelir. Ayrıca bina yöneticisi açısından da “bakım firması sorunu çözemiyor” algısı oluşabilir.

Bu nedenle şartnamede tekrar arıza için ölçüm tanımı yapılmalıdır. Örneğin:

  • Aynı asansörde 7 gün içinde aynı arıza tipinin tekrar açılması.
  • Aynı katta veya aynı kapı sisteminde tekrarlayan kayıtlar.
  • Parça değişiminden sonra kısa sürede yeniden oluşan sorunlar.

Kesin süre firma politikasına göre değişebilir; önemli olan sistemin bu kayıtları filtreleyebilmesidir.

Yetkilendirme, Veri Güvenliği ve Kayıt Geçmişi

Asansör firmalarında herkesin her kaydı değiştirebilmesi doğru değildir. Teknisyen kendi iş emrini tamamlayabilir, ofis müşteri bilgisi düzenleyebilir, firma sahibi raporları görebilir. Bu ayrım yapılmazsa hem veri güvenliği hem de kayıt güvenilirliği zayıflar.

Teknik şartnamede şu maddeler bulunmalıdır:

  • Kullanıcılar rol bazlı yetkilendirilebilmelidir.
  • Her kullanıcının erişebileceği müşteri, bina, asansör ve rapor alanları sınırlandırılabilmelidir.
  • Silme ve düzeltme işlemleri kayıt geçmişinde izlenebilmelidir.
  • Arıza kaydındaki kritik değişiklikler tarih, saat ve kullanıcı bazında loglanmalıdır.
  • Firma verileri düzenli olarak yedeklenmelidir.
  • Kişisel verilerin korunması açısından kullanıcı erişimleri ve müşteri iletişim bilgileri kontrollü tutulmalıdır.
  • Aktif olmayan personelin erişimi hızlıca kapatılabilmelidir.

2026 Türkiye bağlamında firmalar sadece operasyonel kolaylığı değil, veri güvenliğini de düşünmek zorundadır. Bina yöneticisi telefonları, adresler, bakım geçmişi, arıza notları ve tahsilat bilgileri dağınık şekilde WhatsApp veya kişisel telefonlarda kalırsa ileride ciddi karmaşa doğabilir.

Denetim, Bakım Geçmişi ve Mevzuat Uyumu

Asansör sektörü, teknik kayıt düzeninin önemli olduğu bir alandır. Asansör İşletme ve Bakım Yönetmeliği, periyodik kontrol süreçleri, A/B/C/D kusur sınıfları ve yeşil, mavi, sarı, kırmızı etiket uygulamaları firmaların günlük işleyişine doğrudan etki eder. Arıza ticket sistemi bakım ve periyodik muayene yerine geçmez; ancak arıza geçmişinin düzenli tutulması, teknik kararların daha sağlıklı verilmesini sağlar.

Şartnamede mevzuat tarafı için şu maddeler yer alabilir:

  • Her asansörün bakım, arıza ve servis geçmişi tek dosyada görüntülenebilmelidir.
  • Periyodik muayene sonucu, etiket durumu ve kritik notlar asansör kaydında takip edilebilmelidir.
  • Arıza kaydı, ilgili asansörün bakım geçmişiyle ilişkilendirilebilmelidir.
  • Denetim veya müşteri talebi halinde geçmiş servis kayıtları PDF olarak sunulabilmelidir.
  • TS EN 81-20/50 gibi standartlara ilişkin teknik değerlendirmeler için saha notları ve fotoğraflar kayıt altına alınabilmelidir.

Burada dikkat edilmesi gereken konu şudur: Yazılım standartların yerine geçmez, fakat standartlara uygun çalışma disiplininin belgelenmesine yardımcı olur. Kayıt yoksa yapılan işin ispatı zayıftır.

Satın Alma Öncesi Kontrol Listesi

Teknik şartname hazırlarken sadece özellik yazmak yetmez. Yazılımın firmanın günlük temposuna uyup uymadığı da test edilmelidir. Özellikle demo sürecinde gerçek senaryolarla kontrol yapılmalıdır.

Aşağıdaki liste, teklif almadan önce kullanılabilir:

  • Programda müşteri, bina ve asansör yapısı net kurulabiliyor mu?
  • Arıza bildirimi ofis, mobil ve müşteri tarafından açılabiliyor mu?
  • Teknisyen uygulaması hızlı ve sade mi?
  • İnternetin zayıf olduğu alanlarda kayıt tutulabiliyor mu?
  • Fotoğraf, imza ve servis formu alınabiliyor mu?
  • Tekrar arıza raporu alınabiliyor mu?
  • Kullanıcı yetkileri firma yapısına göre ayrılabiliyor mu?
  • PDF servis formu firma logonuz ve bilgilerinizle düzenlenebiliyor mu?
  • Geçmiş veriler dışa aktarılabiliyor mu?
  • Destek, eğitim ve kurulum süreci net mi?

Asansorex gibi sektöre özel geliştirilen çözümler, genel servis programlarından farklı olarak asansör, bina, bakım periyodu, arıza ve saha teknisyeni ilişkisini aynı yapı içinde ele alır. Bu da şartname hazırlarken “genel iş takip” yerine “asansör operasyonu” odaklı düşünmeyi kolaylaştırır.

Örnek Teknik Şartname Maddeleri

Aşağıdaki maddeler, doğrudan teklif dosyasına uyarlanabilecek örneklerdir:

  • Yazılım, asansör bakım firmalarının arıza, bakım, müşteri, bina ve teknisyen süreçlerini tek sistem üzerinden yönetebilmelidir.
  • Her arıza bildirimi için otomatik ticket numarası oluşturulmalıdır.
  • Arıza kayıtları müşteri, bina ve asansör bazında ilişkilendirilmelidir.
  • Mobil uygulama üzerinden teknisyenlere iş atanabilmeli ve teknisyenler işlem sonucunu sahadan girebilmelidir.
  • Arıza kaydına fotoğraf, açıklama, kullanılan malzeme, çalışma süresi ve müşteri imzası eklenebilmelidir.
  • Sistem, açık, geciken, tamamlanan ve iptal edilen arızaları ayrı ayrı raporlayabilmelidir.
  • Aynı asansöre ait geçmiş arızalar tek ekranda görüntülenebilmelidir.
  • Müşteri portalı veya QR kod ile arıza bildirimi yapılabilmelidir.
  • Servis formu PDF olarak oluşturulabilmeli ve gerektiğinde paylaşılabilmelidir.
  • Kullanıcı yetkileri rol bazlı tanımlanabilmelidir.
  • Raporlar tarih, müşteri, bina, asansör ve teknisyen bazında filtrelenebilmelidir.
  • Sistem yedekleme, kayıt geçmişi ve erişim kontrolü özelliklerine sahip olmalıdır.
  • Kurulum sonrası kullanıcı eğitimi ve teknik destek sağlanmalıdır.

Bu maddeler firmanın büyüklüğüne göre sadeleştirilebilir veya genişletilebilir. Örneğin 50 asansöre bakan bir firma için temel arıza ve mobil kayıt yeterliyken, 1000 asansör yöneten bir firma için detaylı raporlama, şube ayrımı ve gelişmiş yetkilendirme daha kritik hale gelir.

Sıkça Sorulan Sorular

Asansör arıza ticket programı teknik şartnamesinde en önemli madde hangisidir?

En önemli madde, arıza kaydının müşteri, bina ve asansörle ilişkilendirilmesidir. Çünkü bu bağ kurulmazsa sistem sadece basit bir yapılacaklar listesine dönüşür. Asıl değer, her asansörün geçmiş arıza ve bakım kayıtlarının birlikte izlenmesidir.

Mobil uygulama şartnameye mutlaka yazılmalı mı?

Evet. Asansör arızası sahada çözülen bir iştir. Teknisyen mobil uygulamadan kayıt güncelleyemiyor, fotoğraf ekleyemiyor veya servis formu oluşturamıyorsa ofis tekrar manuel işlem yapmak zorunda kalır. Bu da dijitalleşmenin faydasını azaltır.

Müşteri portalı her firma için gerekli mi?

Her firma için zorunlu değildir, ancak yoğun arıza alan veya çok sayıda bina yöneticisiyle çalışan firmalarda ciddi avantaj sağlar. Müşteri portalı sayesinde bina yöneticisi arıza durumunu kendisi görebilir, ofise gelen telefon sayısı azalır.

Teknik şartnamede fiyat maddesi olmalı mı?

Fiyat ayrı teklif bölümünde yer alabilir; ancak şartnamede lisans kapsamı, kullanıcı sayısı, asansör limiti, destek, eğitim, kurulum ve ek modül koşulları net yazılmalıdır. Böylece düşük görünen tekliflerin sonradan ek maliyet çıkarması önlenir.

Arıza ticket programı mevzuat uyumu sağlar mı?

Program tek başına mevzuat uyumu sağlamaz. Ancak bakım, arıza, servis formu, fotoğraf ve işlem geçmişini düzenli tuttuğu için denetim ve müşteri taleplerinde güçlü bir kayıt altyapısı sunar. Teknik sorumluluk yine firmanın yetkin personeli ve doğru saha uygulamasındadır.

Excel ile arıza takibi yerine ticket programı ne zaman gerekir?

Arıza sayısı arttığında, birden fazla teknisyen sahaya çıktığında, aynı bina için tekrar kayıtlar oluştuğunda ve müşteri sürekli durum bilgisi istediğinde Excel yetersiz kalmaya başlar. Bu noktada ticket mantığıyla çalışan bir program daha güvenilir ve ölçülebilir sonuç verir.

Özet

Asansör arıza ticket programı için teknik şartname hazırlarken sadece “arıza kaydı açılsın” demek yeterli değildir. Müşteri bildirimi, mobil teknisyen kullanımı, tekrar arıza analizi, PDF servis formu, rol bazlı yetki, raporlama ve geçmiş kayıtlar birlikte düşünülmelidir.

İyi hazırlanmış bir şartname, firmanın yanlış yazılım seçmesini önler ve demo sürecinde net karşılaştırma yapmasını sağlar. Asansorex gibi asansör sektörüne özel çözümler, bakım ve arıza süreçlerini aynı müşteri, bina ve asansör geçmişinde topladığı için teknik şartname maddelerinin pratikte karşılığını daha kolay görmenize yardımcı olur.

Benzer Yazılar

Asansör operasyonlarınızı bugün dijitalleştirin

Asansorex — 3 gün ücretsiz deneme.

Demo Talep Et