Asansör Arıza Ticket Programı Veri Aktarımı Checklist

İÇERİK

Asansör firmaları için arıza yönetimi çoğu zaman WhatsApp mesajları, telefon notları, Excel listeleri ve teknisyen hafızası arasında dağılır. Yeni bir Asansör Arıza Ticket Programı kullanmaya karar verildiğinde en kritik konu, mevcut verilerin doğru ve eksiksiz aktarılmasıdır. Çünkü iyi kurulmayan bir veri altyapısı, en güçlü yazılımı bile ilk haftada “karmaşık” gösterebilir. Bu rehberde; müşteri, bina, asansör, arıza geçmişi, personel, cari ve belge verilerini aktarırken nelere dikkat etmeniz gerektiğini pratik bir checklist mantığıyla ele alacağız.

Veri Aktarımı Neden Bu Kadar Kritik?

Bir arıza ticket programı sadece yeni arızaları kaydetmek için kullanılmaz. Geçmiş servis alışkanlıklarını, sık arıza yapan binaları, teknisyen performansını, müşteri iletişim geçmişini ve sözleşme yükümlülüklerini de görünür hale getirir. Bu nedenle yazılıma geçişte “boş sistemle başlayalım, zamanla dolar” yaklaşımı çoğu firma için doğru değildir.

Özellikle 100’den fazla asansöre hizmet veren firmalarda geçmiş verinin taşınmaması şu sorunları doğurabilir:

• Aynı binadan gelen tekrar arızalar fark edilmez.
• Teknisyen hangi cihazda hangi parçanın değiştiğini göremez.
• Bina yöneticisi geçmiş kayıt istediğinde ofis tekrar eski dosyalara döner.
• Garanti, revizyon, parça değişimi ve tahsilat bilgileri dağınık kalır.
• Eski Excel ve WhatsApp düzeni yeni sistemin yanında yaşamaya devam eder.

Veri aktarımı, sadece teknik bir işlem değil; firmanın operasyon hafızasını yeni sisteme taşıma sürecidir. Bu yüzden aktarılacak veriler önceden sınıflandırılmalı, temizlenmeli ve sorumluları belirlenmelidir.

Aktarıma Başlamadan Önce Hazırlık

Yeni bir arıza ticket programına geçmeden önce ilk yapılacak iş, mevcut veri kaynaklarını tespit etmektir. Birçok firmada bilgi tek bir yerde değildir. Ofis bilgisayarındaki Excel dosyası, muhasebe programı, teknisyen telefonları, WhatsApp grupları, klasördeki bakım formları ve eski servis fişleri birlikte değerlendirilmelidir.

Veri Kaynaklarını Listeleyin

Başlangıçta şu sorulara cevap verin:

1. Müşteri listesi nerede tutuluyor?
2. Bina ve asansör bilgileri ayrı mı, aynı tabloda mı?
3. Arıza kayıtları geçmişe dönük var mı?
4. Teknisyenlerin tuttuğu kişisel notlar sisteme aktarılacak mı?
5. Cari borç, tahsilat ve fatura bilgileri ayrı bir programda mı?
6. Sözleşme, etiket, periyodik muayene ve bakım belgeleri dijital ortamda mı?
7. WhatsApp üzerinden alınan arıza bildirimleri ne kadar geriye dönük saklanıyor?

Bu soruların cevabı, aktarım kapsamını belirler. Her şeyi aktarmak her zaman gerekli olmayabilir. Ancak müşteri, bina, asansör ve aktif arıza bilgileri mutlaka doğru girilmelidir.

Aktarım Dönemini Belirleyin

Geçmiş arıza kayıtlarının ne kadarının taşınacağı firma büyüklüğüne göre değişir. Genel uygulamada son 6-12 aylık arıza geçmişi operasyonel analiz için yeterli olabilir. Ancak kronik arıza, hukuki ihtilaf, garanti takibi veya büyük site projelerinde daha eski kayıtların da saklanması faydalıdır.

Burada amaç sistemi gereksiz veriyle şişirmek değil, karar almayı kolaylaştıracak geçmişi korumaktır.

Temel Veri Aktarım Checklist Tablosu

Aşağıdaki tablo, Asansör Arıza Ticket Programı’na geçişte hangi veri gruplarının kontrol edilmesi gerektiğini özetler.

Veri Grubu	Aktarım Önceliği	Kontrol Noktası	Sık Yapılan Hata
Müşteri bilgileri	Çok yüksek	Firma/kişi adı, telefon, e-posta, vergi bilgisi	Aynı müşterinin farklı adlarla tekrar açılması
Bina/site bilgileri	Çok yüksek	Adres, yönetici, kapıcı/görevli iletişimi	Eksik mahalle veya hatalı açık adres
Asansör bilgileri	Çok yüksek	Asansör no, kapasite, durak, marka, konum	Bir binadaki birden fazla asansörün karışması
Arıza geçmişi	Yüksek	Tarih, açıklama, teknisyen, sonuç	WhatsApp mesajının bağlamsız aktarılması
Teknisyen listesi	Yüksek	Ad, telefon, görev bölgesi, yetki	Eski personelin aktif görünmesi
Cari bilgiler	Orta-yüksek	Borç, tahsilat, fatura ilişkisi	Arıza bedeli ile bakım bedelinin karışması
Belgeler	Orta	Fotoğraf, form, imza, etiket, rapor	Dosya isimlerinin anlaşılmaz olması
Parça/stok bilgisi	Orta	Değişen parça, miktar, maliyet	Serbest metinlerin standartlaşmaması

Bu tabloyu geçiş toplantısında ekipçe değerlendirmek, sonradan çıkacak birçok karışıklığı önler.

Müşteri, Bina ve Asansör Verileri Nasıl Hazırlanmalı?

Arıza ticket sisteminin omurgası müşteri, bina ve asansör kartlarıdır. Bu üçlü yapı doğru kurulmazsa arıza kayıtları yanlış yere bağlanır. Özellikle aynı yöneticinin birden fazla binaya baktığı veya aynı sitede birkaç blok ve çok sayıda asansör olduğu durumlarda dikkatli olunmalıdır.

Müşteri Kartı

Müşteri kartında şu bilgiler mümkün olduğunca standart olmalıdır:

• Müşteri adı veya apartman/site adı
• Yetkili kişi adı
• Telefon numarası
• E-posta adresi
• Vergi dairesi ve vergi numarası, varsa
• Fatura ünvanı
• Cari kod veya eski sistem referansı
• İletişim tercihi

Burada en önemli konu tekrar kayıtları engellemektir. Örneğin “A Blok Yönetimi”, “A Blok Apt.” ve “A Blok Apartmanı” aynı müşteri ise tek kartta birleştirilmelidir. Aksi halde raporlarda aynı müşteriye ait arızalar farklı hesaplara dağılır.

Bina ve Adres Bilgisi

Bina adreslerinde açık ve standart bir format kullanılmalıdır. Mahalle, cadde/sokak, bina numarası, ilçe ve il bilgisi ayrı alanlarda tutulabiliyorsa aktarım öncesi ayrıştırılmalıdır. Teknisyenin sahada binayı kolay bulması için tarif notu da eklenebilir.

Örnek:

• Site adı: Deniz Konutları
• Blok: B Blok
• Adres: Atatürk Mahallesi, 145. Sokak, No: 12
• İlçe/İl: Kadıköy / İstanbul
• Görevli: Mehmet Bey
• Görevli telefonu: 05xx xxx xx xx

Asansör Kartı

Bir binada birden fazla asansör varsa her asansör ayrı tanımlanmalıdır. “Sol asansör”, “sağ asansör”, “yük asansörü”, “B Blok 2. asansör” gibi saha tarafından anlaşılacak açıklamalar önemlidir. Mümkünse kapasite, durak sayısı, marka, kumanda tipi, makine dairesi bilgisi ve varsa periyodik muayene etiketi de eklenmelidir.

TS EN 81-20/50 gibi standartlar ve Asansör İşletme ve Bakım Yönetmeliği kapsamında bakım ve güvenlik kayıtlarının düzenli tutulması, firmaya denetim ve müşteri iletişimi açısından avantaj sağlar. Burada uydurma belge üretmek değil, mevcut gerçek bilgiyi doğru kartta saklamak esastır.

Arıza Geçmişi Aktarılırken Nelere Dikkat Edilmeli?

Arıza geçmişi, ticket programının en değerli verilerinden biridir. Çünkü doğru aktarıldığında hangi binanın sık arıza verdiği, hangi parça grubunda tekrar eden sorun olduğu ve hangi teknisyenin hangi bölgeye baktığı görülebilir.

Arıza geçmişi aktarımında şu alanlar kritik kabul edilmelidir:

• Arıza tarihi ve saati
• Bildiren kişi
• Bildirim kanalı
• Arıza açıklaması
• Bağlı olduğu bina ve asansör
• Görevlendirilen teknisyen
• Müdahale tarihi
• Yapılan işlem
• Kullanılan parça
• Ücretli/ücretsiz işlem durumu
• Sonuç ve kapanış notu
• Fotoğraf veya servis formu

WhatsApp mesajlarından aktarım yapılacaksa mesajlar tek başına yeterli olmayabilir. “Abi yine kaldı”, “motor hata verdi”, “B blok çalışmıyor” gibi ifadeler bağlam olmadan sisteme girildiğinde ileride rapor değeri taşımaz. Bu nedenle aktarım sırasında açıklamalar sadeleştirilmeli ve mümkünse standart arıza türleriyle eşleştirilmelidir.

Örneğin:

• Kapı arızası
• Fotosel problemi
• Kumanda panosu hatası
• Buton arızası
• Kat seviye problemi
• Kurtarma operasyonu
• Elektrik kesintisi sonrası arıza
• Tekrar eden belirsiz arıza

Asansorex gibi bir bakım ve arıza takip yazılımında arıza kayıtlarının bina, asansör ve teknisyenle ilişkilendirilmesi; geçmişe dönük sorgulamayı kolaylaştırır. Böylece “bu bina son 3 ayda kaç kez kapı arızası verdi?” sorusuna dosya karıştırmadan cevap verilebilir.

Cari, Fatura ve Ücret Bilgileri Nasıl Ele Alınmalı?

Arıza ticket programı sadece teknik kayıt tutuyorsa bile ücretli işlemlerle cari tarafın bağlantısı net olmalıdır. Özellikle bakım sözleşmesi dışında yapılan parça değişimi, revizyon, gece müdahalesi veya ekstra servis bedeli gibi kalemler doğru sınıflandırılmalıdır.

Aktarım öncesi şu ayrımı yapmak gerekir:

• Sözleşme dahilindeki ücretsiz arızalar
• Ücretli arıza müdahaleleri
• Parça değişimi yapılan işler
• Faturası kesilmiş işlemler
• Tahsilatı yapılmış işlemler
• Açık bakiye oluşturan işler
• İptal veya iade edilen işlemler

Cari bilgiler aktarılırken teknik açıklama ile finansal açıklama birbirine karıştırılmamalıdır. Örneğin “kapı kartı değişti” teknik bir sonuçtur; “2.500 TL + KDV ücretlendirildi” finansal bilgidir. İkisi aynı ticket içinde görünse bile raporlama açısından ayrı alanlarda tutulması daha sağlıklıdır.

Eğer firma ön muhasebe veya cari takibi de dijital ortamda yapmak istiyorsa, geçiş sırasında açılış bakiyeleri ayrıca kontrol edilmelidir. Eski borçlar yeni sistemde yanlış müşteriye yazılırsa hem ofis hem müşteri tarafında güven sorunu oluşur.

Belge, Fotoğraf ve Servis Formu Aktarımı

Arıza kayıtlarının yanında servis formu, fotoğraf, imza, teklif, fatura, periyodik muayene raporu veya etiket görseli gibi belgeler de bulunabilir. Ancak belge aktarımı yapılırken her dosyanın sisteme yüklenmesi şart değildir. Öncelik, ileride gerçekten ihtiyaç duyulacak belgelere verilmelidir.

Aktarılabilecek belge türleri:

• Son servis formları
• Parça değişim fotoğrafları
• Arıza öncesi/sonrası görseller
• Müşteri imzalı formlar
• Periyodik muayene raporları
• Sarı, mavi, yeşil veya kırmızı etiket durumuna ait belgeler
• Revizyon teklifleri
• Garanti kapsamındaki işlem belgeleri

Dosya adları anlaşılır olmalıdır. “IMG_4472.jpg” yerine “deniz-konutlari-b-blok-kapi-karti-2026-02-14.jpg” gibi bir adlandırma, ileride belge aramayı kolaylaştırır. Ayrıca kişisel veri içeren belgelerde erişim yetkileri dikkatli belirlenmelidir.

Geçiş Günü İçin Adım Adım Checklist

Veri aktarımı bir günde yapılacaksa, işlem sırası önceden belirlenmelidir. Plansız geçişlerde en sık yaşanan sorun, teknisyenlerin yeni kayıtları eski yöntemle almaya devam etmesidir.

Geçiş günü için pratik sıra şöyle olabilir:

1. Eski sistemden son veri çıktısı alın.
2. Müşteri ve bina listesini kontrol edin.
3. Asansör kartlarını bina bazında eşleştirin.
4. Aktif arızaları ayrı listeleyin.
5. Son 6-12 aylık arıza geçmişini aktarın.
6. Teknisyen ve ofis kullanıcılarını tanımlayın.
7. Açık cari ve ücretli iş kayıtlarını doğrulayın.
8. Test amaçlı birkaç arıza kaydı oluşturun.
9. Mobil kullanım veya saha ekranlarını teknisyenle deneyin.
10. Eski yöntemden yeni sisteme geçiş tarihini ekipçe netleştirin.

Geçiş tarihinden sonra yeni arızaların sadece ticket programı üzerinden açılması gerekir. Aksi halde verinin bir kısmı yeni sistemde, bir kısmı WhatsApp’ta kalır. Bu da dijitalleşmenin en başta çözmeye çalıştığı dağınıklığı yeniden üretir.

Aktarım Sonrası İlk Hafta Kontrolü

Veri aktarımı bittiğinde iş tamamlanmış sayılmaz. İlk hafta, sistemin gerçek sahada nasıl çalıştığını görmek için izleme dönemi olmalıdır. Bu süreçte firma sahibi, ofis personeli ve teknisyenlerden kısa geri bildirim alınmalıdır.

Kontrol edilmesi gereken noktalar:

• Arıza kayıtları doğru binaya bağlanıyor mu?
• Teknisyenler kendilerine atanan işleri görebiliyor mu?
• Kapanan ticketlarda işlem sonucu yeterince açık mı?
• Acil arızalar kaybolmadan takip ediliyor mu?
• Müşteri geçmişi doğru görüntüleniyor mu?
• Ücretli işler cari kayda doğru yansıyor mu?
• Tekrar eden arızalar raporda fark ediliyor mu?
• Eksik veya yanlış aktarılan kayıt var mı?

İlk hafta sonunda küçük düzeltmeler yapılması normaldir. Önemli olan bu düzeltmeleri ertelememektir. Çünkü sistem oturduktan sonra yanlış veri alışkanlığı da kalıcı hale gelebilir.

Sıkça Sorulan Sorular

Eski WhatsApp arıza mesajlarının tamamı aktarılmalı mı?

Genelde tamamını aktarmak gerekmez. Son 6-12 ay içindeki önemli arızalar, tekrar eden sorunlar, ücretli işlemler ve açık durumdaki kayıtlar önceliklendirilmelidir. Çok eski ve bağlamsız mesajlar rapor kalitesini düşürebilir.

Excel’deki müşteri listesi doğrudan programa yüklenebilir mi?

Evet, ancak önce temizlik yapılmalıdır. Tekrarlı müşteri adları, eksik telefonlar, hatalı adresler ve yanlış bina eşleşmeleri düzeltilmeden yükleme yapılırsa yeni sistemde de aynı karışıklık devam eder.

Arıza geçmişi olmadan yeni ticket programına başlanır mı?

Başlanabilir, fakat operasyonel hafıza zayıf kalır. En azından aktif arızalar, son dönemde tekrar eden sorunlar ve önemli parça değişimleri aktarılmalıdır. Bu kayıtlar teknisyenin sahada daha hızlı karar almasını sağlar.

Bina ve asansör bilgileri ayrı ayrı mı girilmeli?

Evet. Özellikle bir binada birden fazla asansör varsa her asansör ayrı tanımlanmalıdır. Aksi halde hangi asansörde hangi arızanın yaşandığı net görülemez.

Cari bilgiler arıza ticket sistemiyle ilişkilendirilmeli mi?

Ücretli arıza, parça değişimi, revizyon veya ekstra servis bedeli varsa ilişkilendirilmelidir. Böylece teknik işlem ile müşteriye yansıyan borç arasında kopukluk oluşmaz.

Asansorex veri aktarımında nasıl yardımcı olur?

Asansorex, müşteri, bina, asansör, arıza ve saha kayıtlarını tek yapı içinde takip etmeye yardımcı olur. Doğru hazırlanmış veriyle geçiş yapıldığında firma hem geçmiş kayıtları hem de yeni arıza süreçlerini daha düzenli yönetebilir.

Özet

Asansör Arıza Ticket Programı’na geçişte başarının önemli kısmı veri aktarımında belirlenir. Müşteri, bina, asansör, arıza geçmişi, teknisyen, cari ve belge verileri doğru hazırlanırsa yeni sistem kısa sürede verim üretir. Plansız aktarım ise eski dağınıklığı dijital ortama taşır.

En sağlıklı yaklaşım; önce veri kaynaklarını listelemek, sonra gereksiz ve hatalı kayıtları temizlemek, ardından öncelikli bilgileri sisteme kontrollü şekilde aktarmaktır. Böylece firma sahibi rapor alabilir, teknisyen geçmişi görebilir, bina yöneticisi daha şeffaf hizmet alır. Asansorex gibi sahaya uygun bir yazılım kullanıldığında bu geçiş, sadece veri taşıma işi olmaktan çıkar; arıza yönetimini ölçülebilir ve sürdürülebilir hale getiren güçlü bir başlangıca dönüşür.