Asansör Sözleşme Yönetim Yazılımı İçin Pilot Proje Tasarımı

İÇERİK

Asansör sözleşme yönetim yazılımı satın almak yalnızca teknik bir tercih değildir. Bu karar; satış ekibinin çalışma düzenini, bakım portföyünün kârlılığını, sözleşme yenileme süreçlerini ve bina yöneticileriyle kurulan iletişimi doğrudan etkiler. Bu nedenle yazılımı bir günde bütün firmaya açmak yerine, sınırlı müşteri grubu ve net başarı kriterleriyle pilot proje yürütmek daha güvenli bir yöntemdir. Bu rehberde pilot kapsamının nasıl belirleneceğini, hangi verilerin hazırlanacağını, 30 günlük test sürecinde nelerin ölçüleceğini ve sonuçların nasıl değerlendirileceğini öğreneceksiniz.

Pilot Proje Neden Gereklidir?

Asansör bakım firmalarında sözleşme bilgileri genellikle farklı yerlerde tutulur. İmzalı belgeler klasörde, fiyatlar Excel dosyasında, yenileme tarihleri personelin ajandasında, müşteri görüşmeleri ise telefon ve mesaj geçmişinde kalabilir. Bu da sözleşme yenileme zamanı geldiğinde eksik veya çelişkili bilgilerle karşılaşılmasına neden olur.

Bir sözleşme yönetim yazılımı bu kayıtları merkezileştirebilir. Ancak programın başarılı olması için mevcut iş akışına uygun şekilde kurulması gerekir. Pilot proje, yazılımın gerçek çalışma şartlarında denenmesini sağlar.

İyi tasarlanmış bir pilot çalışma şu sorulara cevap verir:

• Mevcut sözleşmeler eksiksiz aktarılabiliyor mu?
• Yaklaşan bitiş tarihleri zamanında fark ediliyor mu?
• Satış ekibi müşteri görüşmelerini düzenli kaydediyor mu?
• Fiyat artışı ve yenileme teklifleri takip edilebiliyor mu?
• Firma sahibi riskli sözleşmeleri tek ekranda görebiliyor mu?
• Kullanıcılar sistemi ek iş olarak mı, günlük işin parçası olarak mı görüyor?
• Bina yöneticisine sunulan bilgiler doğru ve güncel mi?

Pilotun amacı kusursuz bir ortam oluşturmak değil, gerçek kullanım sırasında ortaya çıkacak sorunları kontrollü ölçekte görmektir.

Pilot Kapsamı Nasıl Belirlenir?

İlk pilotta bütün müşterileri ve çalışanları sisteme taşımak doğru değildir. Çok geniş kapsam, hangi sorunun veriden, kullanıcı alışkanlığından veya yazılım yapılandırmasından kaynaklandığını anlamayı zorlaştırır.

Temsil gücü yüksek sözleşmeler seçin

Pilot portföy yalnızca düzenli ödeme yapan, sorunsuz müşterilerden oluşmamalıdır. Farklı çalışma koşullarını temsil eden yaklaşık 30–50 sözleşme seçilebilir. Firmanın portföyü küçükse toplam sözleşmelerin yüzde 10–20’siyle başlanması da mümkündür.

Seçilen grupta mümkünse şu örnekler bulunmalıdır:

• Yakında süresi dolacak bakım sözleşmeleri
• Birden fazla asansörü bulunan siteler
• Farklı bakım ücretlerine sahip müşteriler
• Fiyat güncellemesi bekleyen sözleşmeler
• Tahsilat gecikmesi yaşanan müşteriler
• Revizyon veya parça değişimi görüşülen binalar
• Farklı ilçelerde hizmet verilen noktalar
• Yeni kazanılmış ve uzun süredir çalışılan müşteriler

Bu dağılım, yazılımın yalnızca ideal senaryoda değil, gerçek portföy şartlarında değerlendirilmesini sağlar.

Pilot ekibini sınırlı tutun

Başlangıç için bir proje sorumlusu, bir satış veya müşteri ilişkileri çalışanı, bir operasyon sorumlusu ve gerektiğinde bir teknisyen yeterlidir. Firma sahibi ise günlük veri girişine değil, haftalık sonuçların değerlendirilmesine katılmalıdır.

Teknisyenin rolü sınırlı ama önemlidir. Sözleşmede yer alan bakım kapsamı ile sahada beklenen hizmet birbirinden farklıysa bunu en hızlı teknisyen fark eder. Örneğin bina yöneticisi sözleşmede bulunmayan bir parçanın ücretsiz değiştirilmesini bekliyor olabilir. Bu uyuşmazlık müşteri notlarına eklenerek yenileme görüşmesinde dikkate alınmalıdır.

Başlangıç Verileri Nasıl Hazırlanır?

Pilotun başarısı, sisteme aktarılan verinin kalitesine bağlıdır. Eksik başlangıç verisiyle çalışan en iyi yazılım bile yanlış uyarı üretir. Veri aktarımından önce sözleşmeler tek tek kontrol edilmelidir.

Her sözleşme için en az şu alanlar hazırlanmalıdır:

• Müşteri veya site adı
• Yetkili kişinin adı ve iletişim bilgileri
• Bina adresi
• Asansör sayısı ve ayırt edici bilgileri
• Sözleşme başlangıç ve bitiş tarihi
• Aylık veya yıllık bakım bedeli
• KDV durumu
• Fiyat güncelleme yöntemi
• Ödeme dönemi ve vade bilgisi
• Sözleşmeye dahil hizmetler
• Hariç tutulan işler ve parçalar
• Fesih veya bildirim süresi
• İmzalı sözleşme belgesi
• Son müşteri görüşmesi
• Yenilemeden sorumlu çalışan

Sözleşme bilgilerinin doğruluğu, yalnızca ofisteki tabloya bakılarak onaylanmamalıdır. İmzalı belge esas alınmalı; tablo ile belge arasında fark varsa uyuşmazlık ayrıca işaretlenmelidir.

Kontrol alanı	Sık görülen sorun	Pilot sırasında yapılacak işlem	Başarı ölçütü
Bitiş tarihi	Tarih girilmemiş veya hatalı	İmzalı belgeden doğrulama	Pilot kayıtlarının tamamında doğru tarih
Bakım bedeli	Eski fiyat kullanılması	Son fatura ve sözleşmeyle karşılaştırma	Güncel bedellerin eksiksiz kaydı
Bildirim süresi	Serbest metinde unutulması	Ayrı alana kaydetme	Kritik tarihten önce uyarı
Asansör sayısı	Bina ve cihaz sayısının karışması	Saha kaydıyla eşleştirme	Her sözleşmenin doğru cihazlarla bağlantısı
Yetkili kişi	Eski yönetici bilgisinin kalması	Telefonla veya son görüşmeyle teyit	Güncel iletişim oranının yükselmesi
Belge kaydı	İmzalı nüshanın bulunamaması	Tarama veya dijital dosya yükleme	Her pilot kaydında erişilebilir belge

Veri temizliği sırasında eski yönetici telefonları, yinelenen müşteri kayıtları ve süresi dolduğu hâlde aktif görünen sözleşmeler ayrıca ayrılmalıdır. Bu çalışma, pilotun en değerli çıktılarından biridir.

30 Günlük Pilot Uygulama Planı

Pilot için çoğu firmada 30 gün yeterli bir başlangıç süresidir. Ancak bu sürede en az birkaç gerçek yenileme, fiyat görüşmesi veya müşteri takibi yaşanmalıdır. Pilot portföyde hiç sözleşme bitişi yoksa sistemin yenileme kabiliyeti gerçek koşullarda ölçülemez.

Birinci hafta: kurulum ve veri doğrulama

İlk hafta kullanıcılar belirlenir, yetkiler tanımlanır ve seçilen sözleşmeler sisteme aktarılır. Her kullanıcının yalnızca kendi göreviyle ilgili alanlara odaklanması benimsenmelidir.

Bu haftanın sonunda:

1. Pilot kapsamındaki bütün sözleşmeler sisteme girilmiş olmalıdır.
2. İmzalı belgeler ilgili müşteri kayıtlarıyla eşleştirilmelidir.
3. Bitiş ve bildirim tarihleri kontrol edilmelidir.
4. Yenileme sorumluları atanmalıdır.
5. İlk uyarı ve görevler oluşturulmalıdır.

İkinci hafta: günlük kullanım

İkinci haftada yapay senaryolar yerine gerçek işler sisteme kaydedilir. Müşteri araması, fiyat görüşmesi, teklif gönderimi ve geri dönüş tarihi gibi adımlar yazılım üzerinden takip edilir.

Kullanıcıların aynı bilgiyi hem Excel’e hem yazılıma girmesi uzun süre devam etmemelidir. Kısa bir doğrulama dönemi uygulanabilir; ancak çift kayıt kalıcı hâle gelirse ekip yazılımı ikincil araç olarak görür.

Üçüncü hafta: yenileme senaryosu

En az üç farklı yenileme senaryosu uygulanmalıdır:

• Sorunsuz yenilenmesi beklenen sözleşme
• Fiyat itirazı beklenen müşteri
• Tahsilat veya hizmet kapsamı nedeniyle riskli sözleşme

Her senaryoda ilk uyarının ne zaman geldiği, müşteriye hangi gün ulaşıldığı, teklifin ne zaman gönderildiği ve sonucun nasıl kaydedildiği ölçülmelidir. Bina yöneticisinin talep ettiği ek hizmetler de görüşme notunda tutulmalıdır.

Asansorex gibi bir bakım ve sözleşme takip yazılımında sözleşme tarihlerini, müşteri geçmişini ve saha kayıtlarını ilişkilendirmek; satış ekibinin görüşmeye yalnızca fiyat bilgisiyle değil, geçmiş hizmet verileriyle hazırlanmasına yardımcı olur.

Dördüncü hafta: ölçüm ve karar

Son hafta yeni özellik eklemek yerine mevcut kullanım değerlendirilmelidir. Kullanıcılardan yalnızca “beğendim” veya “zorlandım” şeklinde yorum alınması yeterli değildir. Her geri bildirim gerçek bir işlem üzerinden incelenmelidir.

Örneğin “Sözleşmeyi bulamadım” diyen kullanıcıdan hangi müşteriyi, hangi yöntemle aradığı gösterilmesi istenebilir. Böylece sorun eğitim, veri adlandırması veya arama özelliğiyle ilişkilendirilebilir.

Başarı Kriterleri Nasıl Ölçülür?

Pilot başlamadan önce ölçütler yazılı hâle getirilmelidir. Aksi hâlde ekip, proje sonunda farklı beklentilere göre değerlendirme yapar. Firma sahibi hız ve görünürlük beklerken satış çalışanı yalnızca veri giriş kolaylığına odaklanabilir.

Örnek pilot hedefleri şunlardır:

Performans göstergesi	Başlangıç durumu	30 günlük pilot hedefi
Eksiksiz temel veriye sahip sözleşme oranı	Ölçülmemiş	En az yüzde 95
İmzalı belgesi erişilebilir kayıt oranı	Yüzde 60	En az yüzde 90
Süresi yaklaşan sözleşmelerin zamanında fark edilmesi	Kişiye bağlı	Yüzde 100
Müşteri görüşmelerinin aynı gün kaydedilmesi	Yüzde 40	En az yüzde 85
Sorumlusu belli yenileme işi oranı	Yüzde 50	Yüzde 100
Kayıp yenilemelerde neden kaydı	Yapılmıyor	Yüzde 100
Bir sözleşme dosyasına erişim süresi	5–10 dakika	1 dakikanın altı

Yüzdeler tek başına yeterli değildir. Pilot sonunda şu nitel sonuçlar da değerlendirilmelidir:

• Çalışanlar hangi alanları gereksiz buldu?
• Hangi bilgiye ulaşmakta zorlandılar?
• Bina yöneticisinden gelen talepler kayda geçirilebildi mi?
• Sözleşme bedeli ile verilen hizmet arasındaki uyumsuzluk görülebildi mi?
• Yenileme sürecindeki sorumluluk belirsizliği azaldı mı?
• Firma sahibi portföy riskini daha hızlı değerlendirebildi mi?

Pilot Sonrası Geçiş Kararı

Pilot tamamlandığında üç sonuçtan biri seçilebilir: genel kullanıma geçiş, düzeltmelerden sonra ikinci pilot veya projenin durdurulması. Her sorun yazılımın yetersiz olduğu anlamına gelmez. Bazı problemler eksik veri, belirsiz görev dağılımı veya yetersiz kullanıcı eğitiminden kaynaklanabilir.

Genel kullanıma geçmeden önce şu kontrol listesi tamamlanmalıdır:

• Pilot hedeflerinin büyük bölümü karşılandı.
• Kritik tarih ve fiyat bilgileri doğru çalışıyor.
• Kullanıcılar günlük işlemleri sürekli destek almadan yapabiliyor.
• Sözleşme belgelerine kolayca erişilebiliyor.
• Yenileme sorumlulukları açıkça tanımlandı.
• Eski sistemin ne zaman bırakılacağı belirlendi.
• Kalan portföyün aktarım takvimi hazırlandı.
• Veri yedekleme ve erişim yetkileri gözden geçirildi.
• Firma içinde sistemi takip edecek bir sorumlu atandı.

Tüm portföyün tek seferde aktarılması yerine şube, bölge veya müşteri grubu bazında aşamalı geçiş yapılabilir. Örneğin ilk hafta süresi 90 gün içinde dolacak sözleşmeler, ikinci hafta yüksek cirolu müşteriler, üçüncü hafta kalan aktif portföy aktarılabilir.

Pilot Tasarımında Yapılan Yaygın Hatalar

En sık yapılan hata, pilotu yalnızca program tanıtımı olarak görmektir. Birkaç ekranı incelemek pilot proje sayılmaz; gerçek müşteri verisiyle işlem yapılmalı ve sonuç ölçülmelidir.

Diğer yaygın hatalar şunlardır:

• Yalnızca kolay ve sorunsuz müşterileri seçmek
• Başarı kriterlerini proje sonunda belirlemek
• İmzalı sözleşme yerine eski Excel verisini esas almak
• Bütün çalışanları ilk günden sisteme dahil etmek
• Kullanıcı eğitimini tek seferlik uzun toplantıyla sınırlamak
• Aynı veriyi aylarca iki ayrı yerde tutmak
• Pilot sırasında sürekli kapsam değiştirmek
• Kullanıcı yorumlarını işlem örnekleriyle doğrulamamak
• Yenileme uyarısını başarı kabul edip gerçek müşteri sonucunu ölçmemek

Başarılı pilot, yazılımın bütün özelliklerini kullanmak değil; sözleşme kaybını azaltan temel iş akışının güvenilir biçimde çalıştığını kanıtlamaktır.

Pilot sırasında “olsa iyi olur” talepleri ayrı bir listede tutulmalıdır. Kritik ihtiyaçlarla tercih niteliğindeki özelliklerin karıştırılması, uygulama süresini uzatır ve ana hedefin gözden kaçmasına neden olur.

Sıkça Sorulan Sorular

Pilot proje kaç gün sürmelidir?

Çoğu asansör bakım firması için 30 gün uygun bir başlangıçtır. Ancak seçilen dönemde gerçek sözleşme yenilemeleri yaşanmıyorsa süre 45 veya 60 güne çıkarılabilir. Önemli olan takvimden çok, yeterli sayıda gerçek işlemin tamamlanmasıdır.

Pilot için kaç sözleşme seçilmelidir?

Orta ölçekli bir firma için 30–50 sözleşme yönetilebilir bir aralıktır. Küçük firmalarda portföyün yüzde 10–20’si seçilebilir. Grubun farklı fiyat, müşteri ve yenileme senaryolarını temsil etmesi sayıdan daha önemlidir.

Eski sözleşmelerin tamamı pilotta aktarılmalı mı?

Hayır. Öncelik aktif, süresi yaklaşan ve ticari açıdan önemli sözleşmelere verilmelidir. Feshedilmiş veya uzun süredir işlem görmeyen kayıtlar ayrı bir arşiv çalışmasında değerlendirilebilir.

Pilot sırasında Excel kullanılmaya devam edilmeli mi?

Kısa bir veri doğrulama döneminde karşılaştırma yapılabilir. Ancak çift kayıt uzun süre sürerse çalışanlar eski alışkanlıklarını bırakmaz. Doğrulama tamamlandıktan sonra pilot kapsamındaki işlemler için tek kayıt kaynağı belirlenmelidir.

Teknisyenlerin pilot projeye katılması gerekir mi?

Her teknisyenin katılması gerekmez. En az bir deneyimli teknisyenin bakım kapsamı, cihaz bilgileri ve sahadaki müşteri beklentileri konusunda doğrulama yapması yararlıdır. Sözleşme ile fiilî hizmet arasındaki farklar bu şekilde erkenden görülebilir.

Asansorex pilot projede nasıl kullanılabilir?

Asansorex; sözleşme tarihleri, müşteri bilgileri, bakım geçmişi ve yenileme görevlerinin ortak bir düzende takip edilmesine yardımcı olabilir. Pilot sonunda yalnızca kullanım kolaylığı değil, kaç sözleşmenin zamanında ele alındığı ve kayıt kalitesinin ne kadar yükseldiği değerlendirilmelidir.

Özet

Asansör sözleşme yönetim yazılımı için doğru pilot tasarımı; temsil gücü yüksek bir müşteri grubu, temiz başlangıç verisi, sınırlı kullanıcı ekibi ve ölçülebilir hedefler gerektirir. Yaklaşık 30 günlük süreçte veri doğruluğu, yenileme takibi, müşteri görüşmeleri ve kullanıcı alışkanlıkları birlikte sınanmalıdır. Sonuçlar beklentiyi karşılıyorsa aşamalı geçiş yapılmalı; sorun varsa kaynağın yazılım, veri veya iş akışı olup olmadığı ayrıştırılmalıdır. Böylece firma, bütün portföyü etkileyecek kararı tahmine göre değil, gerçek kullanım verilerine dayanarak verir.