Asansör Arıza Çağrı Programı Veri Aktarımı Checklist

İÇERİK

Bir asansör arıza çağrı programı satın almak, dijital dönüşümün yalnızca başlangıcıdır. Asıl başarı; müşteri, bina, asansör, sözleşme, teknisyen ve geçmiş arıza kayıtlarının yeni sisteme doğru biçimde aktarılmasına bağlıdır. Eksik veya hatalı veriyle başlatılan bir program, ekibin işini kolaylaştırmak yerine yanlış yönlendirmelere, mükerrer kayıtlara ve raporlama sorunlarına yol açabilir.

Bu rehberde, mevcut bilgilerinizi yeni programa taşırken uygulayabileceğiniz pratik bir veri aktarımı checklisti bulacaksınız. Amaç yalnızca dosyaları sisteme yüklemek değil; günlük operasyonun kesintiye uğramadan devam edebileceği temiz, güncel ve kullanılabilir bir veri yapısı oluşturmaktır.

Veri Aktarımından Önce Kapsamı Belirleyin

Veri aktarımına doğrudan Excel dosyalarını yükleyerek başlamak sık yapılan bir hatadır. Önce hangi verilerin aktarılacağı, hangilerinin arşivde bırakılacağı ve hangi kayıtların temizleneceği belirlenmelidir.

Bir asansör bakım firmasındaki bilgiler genellikle farklı kaynaklara dağılmış durumdadır:

• Excel müşteri listeleri
• Muhasebe programındaki cari kartlar
• Teknisyenlerin telefon rehberleri
• WhatsApp arıza grupları
• Kâğıt bakım ve arıza formları
• Eski servis takip programı
• Sözleşme klasörleri
• E-posta üzerinden alınan arıza bildirimleri
• Apartman ve bina yöneticisi iletişim listeleri
• Asansör kimlik ve periyodik kontrol kayıtları

İlk adım, bu kaynakların tamamını listelemektir. Ardından her veri kaynağı için bir sorumlu belirlenmelidir. Örneğin müşteri ve sözleşme bilgilerinden ofis personeli, cihaz teknik bilgilerinden teknik müdür, geçmiş arıza kayıtlarından operasyon sorumlusu sorumlu olabilir.

Veri aktarımında temel hedef, eski sistemde bulunan her şeyi taşımak değil; yeni sistemde ihtiyaç duyulan doğru ve güncel bilgileri oluşturmaktır.

Eski ve aktif olmayan kayıtları ayırmadan yapılan toplu aktarım, yeni programın daha ilk günden karmaşık görünmesine neden olur. Bu nedenle aktif müşteriler, feshedilmiş sözleşmeler ve potansiyel müşteriler farklı gruplar halinde ele alınmalıdır.

Aktarılacak Temel Veri Alanlarını Hazırlayın

Her yazılım aynı alan yapısını kullanmayabilir. Eski sistemde “müşteri adı” olarak tutulan bir kayıt, yeni sistemde firma unvanı, yetkili adı, bina adı ve fatura unvanı şeklinde ayrı alanlara bölünebilir. Aktarım öncesinde eski alanlarla yeni alanların eşleştirilmesi gerekir.

Aşağıdaki tablo, temel veri grupları için örnek bir hazırlık kontrolü sunar:

Veri grubu	Kontrol edilecek alanlar	Yaygın sorun	Önerilen işlem
Müşteri	Unvan, yetkili, telefon, e-posta	Aynı müşteri birden fazla kayıtlı	Mükerrer kayıtları birleştirin
Bina	Bina adı, açık adres, konum	Adres eksik veya eski	Yöneticiyle doğrulayın
Asansör	Kimlik numarası, marka, durak, kapasite	Cihaz ile bina eşleşmiyor	Teknik listeyle karşılaştırın
Sözleşme	Başlangıç, bitiş, ücret, kapsam	Tarih veya ücret boş	Sözleşme belgesinden tamamlayın
Arıza geçmişi	Tarih, bildiren kişi, sorun, sonuç	Serbest metinler düzensiz	Standart arıza türleri oluşturun
Teknisyen	Ad, telefon, ekip, bölge	İşten ayrılan personel mevcut	Yalnızca gerekli kayıtları taşıyın
Yönetici	Ad, telefon, bildirim tercihi	Eski yönetici kayıtlı	Güncel yetkiliyi teyit edin

Aktarım dosyasında her satırın tek bir kaydı temsil etmesi önemlidir. Bir hücreye birden fazla telefon numarası, adres veya cihaz bilgisi yazılması otomatik aktarımı zorlaştırır. Birden fazla bilgi gerekiyorsa ayrı sütunlar kullanılmalıdır.

Örneğin Telefon 1, Telefon 2 ve Acil Durum Telefonu gibi açık sütun adları tercih edilebilir. Tarihler için de dosyanın tamamında tek biçim kullanılmalıdır. 21.09.2026, 21/09/26 ve Eylül 2026 gibi farklı gösterimlerin aynı sütunda bulunması hata riskini artırır.

Müşteri, Bina ve Asansör Eşleşmesini Doğrulayın

Asansör sektöründe veri aktarımının en kritik noktası, müşteri ile cihaz arasındaki ilişkinin doğru kurulmasıdır. Bir müşterinin birden fazla binası, bir binanın da birden fazla asansörü olabilir. Ayrıca ödeme yapan cari ile arıza bildiren bina yöneticisi aynı kişi olmayabilir.

Bu nedenle veri yapısı şu sırayla kontrol edilmelidir:

1. Müşteri veya cari kartı oluşturulur.
2. Müşteriye bağlı bina ya da tesis kaydı belirlenir.
3. Binaya bağlı asansörler ayrı ayrı tanımlanır.
4. Her asansör için kimlik ve teknik bilgiler eşleştirilir.
5. Sözleşme, doğru müşteri ve cihazlarla ilişkilendirilir.
6. Yönetici ve diğer yetkili kişiler ilgili binaya bağlanır.
7. Geçmiş arızalar doğru asansör kaydına atanır.

Aynı binadaki iki asansörü tek cihaz gibi aktarmak, ilerleyen dönemde arıza sıklığı ve parça değişimi raporlarını bozar. Her asansörün ayrı bir cihaz kartı olmalı; mümkünse bina içindeki tanımlayıcı adı da belirtilmelidir. Örneğin A Blok Yolcu Asansörü, B Blok Servis Asansörü veya Otopark Asansörü gibi açık isimler kullanılabilir.

Adreslerin de standartlaştırılması gerekir. Aynı binanın “Atatürk Cad. No:12”, “Atatürk Caddesi 12” ve “Atatürk Cd No 12” biçiminde üç farklı kayda dönüşmesi saha planlamasını etkileyebilir. Özellikle harita ve rota özellikleri kullanılacaksa il, ilçe, mahalle, cadde ve bina numarası mümkün olduğunca ayrı alanlarda tutulmalıdır.

Geçmiş Arıza Kayıtlarını Seçerek Aktarın

Geçmiş arıza kayıtları, cihazın sorun geçmişini anlamak ve tekrarlayan arızaları tespit etmek açısından değerlidir. Ancak yıllar boyunca birikmiş düzensiz mesajların tamamını taşımaya çalışmak gereksiz iş yükü yaratabilir.

Öncelikle şu kararlar verilmelidir:

• Kaç yıllık arıza geçmişi operasyonel olarak gerekli?
• Kapanış açıklaması olmayan kayıtlar aktarılacak mı?
• Fotoğraf ve ek belgeler taşınacak mı?
• Arıza türleri hangi standart başlıklarda toplanacak?
• Ücretli işlemler ve garanti kapsamındaki işlemler nasıl ayrılacak?
• Tekrarlayan arızalar hangi cihazla ilişkilendirilecek?

Genel uygulamada, yakın döneme ait ve karar vermede işe yarayan kayıtların aktarılması daha verimlidir. Daha eski kayıtlar ise erişilebilir bir dijital arşivde saklanabilir. Böylece yeni sistem gereksiz veriyle doldurulmaz.

Serbest metinle yazılmış arızalar da mümkün olduğunca sınıflandırılmalıdır. “Kapı açılmıyor”, “kapı sıkıştı” ve “kabin kapısı kapanmıyor” ifadeleri uygun bir standart altında toplanabilir. Ancak özgün teknisyen açıklaması silinmemeli; standart arıza türünün yanında not olarak korunmalıdır.

Bu kayıtları kâğıt, WhatsApp ve birbirinden kopuk Excel dosyaları yerine Asansorex gibi bir bakım takip yazılımında cihaz bazında toplamak, geçmiş müdahalelere sahadan ve ofisten daha hızlı ulaşılmasını sağlar.

Veri Temizliği Checklistini Uygulayın

Veri temizliği, aktarımın en fazla dikkat isteyen aşamasıdır. Program hatasız çalışsa bile yanlış telefon numarası, süresi bitmiş sözleşme veya hatalı cihaz eşleşmesi operasyonu aksatabilir.

Aktarımdan önce aşağıdaki checklist uygulanmalıdır:

• [ ] Aktif ve pasif müşteriler ayrıldı.
• [ ] Aynı müşteriye ait mükerrer kayıtlar birleştirildi.
• [ ] Firma unvanları ve bina adları standartlaştırıldı.
• [ ] Telefon numaraları aynı biçime getirildi.
• [ ] E-posta adreslerindeki yazım hataları kontrol edildi.
• [ ] İl, ilçe ve açık adres alanları tamamlandı.
• [ ] Her asansör benzersiz bir cihaz kaydına bağlandı.
• [ ] Asansör kimlik numaraları kontrol edildi.
• [ ] Cihazların marka, model ve teknik bilgileri gözden geçirildi.
• [ ] Sözleşme başlangıç ve bitiş tarihleri doğrulandı.
• [ ] Bakım ücretlerinin KDV durumu açıkça belirtildi.
• [ ] Bina yöneticisi ve iletişim kişileri güncellendi.
• [ ] İşten ayrılan teknisyenler aktif listeden çıkarıldı.
• [ ] Açık arıza kayıtları ayrıca işaretlendi.
• [ ] İptal edilmiş veya deneme amaçlı kayıtlar temizlendi.
• [ ] Aktarım dosyasının yedek kopyası oluşturuldu.

Telefon numaralarını yalnızca görsel olarak kontrol etmek yeterli değildir. Eksik hane, metin içinde kalan açıklama ve bir hücreye girilmiş iki farklı numara ayrıca aranmalıdır. Aynı şekilde ücret alanlarında TL, nokta, virgül ve KDV açıklamalarının farklı biçimlerde kullanılması aktarım sorunlarına neden olabilir.

Önce Pilot Aktarım Yapın

Binlerce kaydı tek seferde aktarmak yerine küçük bir pilot veri grubu seçilmelidir. Pilot kapsamına farklı senaryoları temsil eden 10–20 müşteri alınabilir. Tek asansörlü bina, çok cihazlı site, birden fazla sözleşmesi bulunan müşteri ve açık arıza kaydı olan cihaz gibi farklı örnekler seçilmelidir.

Pilot aktarım sonrasında şu kontroller yapılmalıdır:

Kayıt sayısı kontrolü

Kaynak dosyadaki müşteri, bina, cihaz ve sözleşme sayılarıyla programa aktarılan sayılar karşılaştırılmalıdır. Sayılar eşleşmiyorsa aktarılmayan veya mükerrer oluşan kayıtlar araştırılmalıdır.

Alan doğruluğu kontrolü

Rastgele örnekleme yapmak yerine belirlenmiş pilot kayıtların bütün alanları incelenmelidir. Telefon, adres, cihaz kimliği, sözleşme tarihi ve bakım ücreti ayrı ayrı doğrulanmalıdır.

İlişki kontrolü

Müşteri doğru binaya, bina doğru asansöre, arıza doğru cihaza bağlanmış mı kontrol edilmelidir. Veri aktarımında en zor fark edilen hatalar genellikle bu ilişkilerdedir.

Saha testi

Bir teknisyen pilot cihazlardan birini mobil uygulamada açmalı; adresi, geçmiş arızaları, yetkili kişiyi ve teknik bilgileri kontrol etmelidir. Ofiste doğru görünen bir aktarımın sahadaki kullanım kolaylığı da test edilmelidir.

Pilot başarıyla tamamlanmadan toplu aktarıma geçilmemelidir. Tespit edilen hata aktarım şablonunda düzeltilmeli ve pilot işlem yeniden denenmelidir.

Geçiş Gününü ve Sorumlulukları Planlayın

Eski ve yeni sistemin uzun süre aynı anda kullanılması veri tutarsızlığı doğurabilir. Bir arıza eski sisteme, başka bir arıza yeni programa kaydedildiğinde eksiksiz rapor üretmek zorlaşır. Bu nedenle net bir geçiş tarihi belirlenmelidir.

Geçiş planında şu görevler yer almalıdır:

Görev	Sorumlu	Tamamlanma zamanı
Kaynak dosyaları toplama	Ofis sorumlusu	Geçişten 7–10 gün önce
Müşteri ve cihaz doğrulama	Operasyon sorumlusu	Geçişten 5 gün önce
Sözleşme kontrolü	Muhasebe veya satış ekibi	Geçişten 4 gün önce
Pilot aktarım	Yazılım yetkilisi ve firma sorumlusu	Geçişten 3 gün önce
Son veri yedeği	Yetkili personel	Geçişten 1 gün önce
Toplu aktarım	Belirlenen teknik ekip	Geçiş günü
Örnek kayıt kontrolü	Ofis ve saha ekibi	Aynı gün
Eski sistemi salt okunur kullanma	Firma yönetimi	Geçiş sonrasında

Geçiş saatinden sonra gelen yeni arızaların hangi sisteme kaydedileceği tüm personele açıkça bildirilmelidir. Teknisyenlere ve çağrı karşılayan personele kısa bir kullanım eğitimi verilmesi de önemlidir.

Eski sistem hemen silinmemelidir. Belirli bir doğrulama süresi boyunca yalnızca geçmiş bilgilere bakmak amacıyla erişilebilir tutulabilir. Kaynak dosyalar ve aktarım öncesi yedekler de yetkisiz erişime karşı korunmalıdır.

Aktarım Sonrası Doğrulama Yapın

Veri aktarımı, “yükleme tamamlandı” mesajıyla bitmez. İlk gün, ilk hafta ve ilk ay sonunda farklı kontroller yapılmalıdır.

İlk gün kayıt sayıları ve kritik müşteri bilgileri kontrol edilmelidir. İlk hafta teknisyenlerden yanlış adres, eksik telefon, görünmeyen cihaz veya hatalı sözleşme bildirimi toplanmalıdır. İlk ay sonunda ise raporlardaki sonuçlar incelenmelidir.

Özellikle şu göstergeler takip edilmelidir:

• Açık arıza sayısı
• Cihaza bağlanamayan arıza kayıtları
• Yetkilisi veya telefonu bulunmayan binalar
• Sözleşme tarihi eksik müşteriler
• Mükerrer müşteri ve cihaz kayıtları
• Pasif müşterilere açılan yeni işler
• Teknisyeni atanmamış çağrılar
• Kapanış bilgisi girilmeyen arızalar

Asansorex üzerinde müşteri, cihaz ve arıza geçmişinin ilişkili tutulması, aktarım sonrası kontrollerin daha sistemli yürütülmesine yardımcı olabilir. Bunun için aktarım öncesi dosyanın temiz hazırlanması ve firma içinden bir veri sorumlusunun süreci sahiplenmesi gerekir.

Sıkça Sorulan Sorular

Eski programdaki bütün kayıtlar aktarılmalı mı?

Hayır. Aktif operasyon için gerekli kayıtlar öncelikli olmalıdır. Güncelliğini kaybetmiş, mükerrer veya deneme amaçlı bilgiler temizlenebilir. Yasal veya ticari nedenle saklanması gereken eski belgeler ise ayrı bir dijital arşivde korunabilir.

WhatsApp arıza mesajları yeni programa aktarılabilir mi?

Mesajlar teknik olarak dosya veya metin halinde alınabilse de doğrudan aktarım her zaman sağlıklı sonuç vermez. Cihazı, tarihi ve sonucu belli olan önemli kayıtların sınıflandırılarak aktarılması daha kullanışlıdır.

Excel dosyasındaki eksik alanlar aktarımı engeller mi?

Bu durum kullanılan programın zorunlu alanlarına bağlıdır. Müşteri adı, bina veya cihaz bağlantısı gibi temel alanların eksik olması aktarımı engelleyebilir. Zorunlu olmayan bilgiler sonradan tamamlanabilir; ancak kritik alanlar aktarım öncesinde düzeltilmelidir.

Veri aktarımı sırasında günlük arıza yönetimi durmalı mı?

İyi planlanan bir geçişte uzun süreli duruş gerekmez. Bununla birlikte belirlenen geçiş saatinde eski sisteme yeni kayıt girilmemesi gerekir. O sırada gelen çağrılar geçici bir listeye alınarak aktarım tamamlandıktan sonra yeni sisteme kaydedilebilir.

Aktarılan verilerin doğru olduğunu kim onaylamalı?

Tek bir kişinin onayı yeterli olmayabilir. Ofis personeli müşteri ve iletişim bilgilerini, teknik sorumlu cihaz bilgilerini, muhasebe veya satış ekibi ise sözleşme ve ücret alanlarını kontrol etmelidir.

Veri aktarımından önce yedek almak gerekli mi?

Evet. Kaynak dosyaların değişiklik yapılmamış bir kopyası mutlaka saklanmalıdır. Ayrıca temizlenen son aktarım dosyası da ayrı olarak yedeklenmelidir. Böylece hata durumunda kaynak veriye geri dönülebilir.

Özet

Asansör arıza çağrı programına veri aktarımı; dosya yüklemekten çok daha kapsamlı bir hazırlık, temizlik ve doğrulama sürecidir. Müşteri-bina-asansör ilişkisi doğru kurulmalı, sözleşmeler güncellenmeli, geçmiş arızalar seçilerek sınıflandırılmalı ve önce pilot aktarım yapılmalıdır.

Başarılı bir geçiş için en güvenli yöntem; veri kaynaklarını belirlemek, sorumluları atamak, standart bir aktarım şablonu hazırlamak ve sonuçları saha ekibiyle birlikte kontrol etmektir. Temiz veriyle başlatılan bir sistem, arıza çağrılarının doğru cihaza yönlendirilmesini, geçmiş müdahalelerin izlenmesini ve firma performansının güvenilir biçimde ölçülmesini sağlar.