Asansör Sözleşme Programı İçin Pilot Proje Tasarımı

İÇERİK

Bir Asansör Sözleşme Programı satın almadan önce yalnızca ürün sunumuna veya kısa bir demoya bakarak karar vermek önemli riskler taşır. Yazılımın gerçek değeri; mevcut müşteri kayıtları, yaklaşan yenilemeler, fiyat güncellemeleri, saha operasyonları ve satış ekibinin günlük çalışma biçimiyle birlikte kullanıldığında anlaşılır. Bu nedenle kontrollü bir pilot proje, yatırım kararını tahminlere değil ölçülebilir sonuçlara dayandırır. Bu rehberde pilot kapsamının nasıl belirleneceğini, hangi verilerin hazırlanacağını, kimlerin sürece katılacağını ve başarı kararının nasıl verileceğini adım adım ele alacağız.

Pilot Projenin Amacı Ne Olmalı?

Pilot projenin amacı bütün şirketi bir anda yeni sisteme geçirmek değildir. Temel amaç, sözleşme programının seçilmiş bir müşteri grubunda gerçek sorunları çözüp çözmediğini görmektir.

Asansör bakım firmalarında sözleşme yönetimi çoğu zaman Excel dosyaları, fiziksel klasörler, e-posta kutuları ve çalışanların kişisel hatırlatmaları arasında dağılır. Bir sözleşmenin bitiş tarihi farklı dosyada, güncel fiyatı başka tabloda, son müşteri görüşmesi ise satış sorumlusunun telefonunda kalabilir. Pilot proje bu dağınıklığın tek bir sistemde azaltılıp azaltılamayacağını göstermelidir.

Pilot başlamadan önce yönetimin cevaplamak istediği sorular açıkça yazılmalıdır:

• Yaklaşan sözleşme bitişleri zamanında görülebiliyor mu?
• Yenileme görüşmeleri daha erken başlatılabiliyor mu?
• Sözleşmenin güncel nüshasına ofis ekibi kolayca ulaşabiliyor mu?
• Satış sorumlularının yaptığı görüşmeler kayıt altına alınabiliyor mu?
• Fiyat artışı yapılması gereken müşteriler ayırt edilebiliyor mu?
• Süresi dolmuş fakat sistemde aktif görünen sözleşmeler tespit edilebiliyor mu?
• Müşteri, bina ve asansör bilgileri birbiriyle doğru ilişkilendirilebiliyor mu?

Başarılı bir pilotun çıktısı “program güzel görünüyor” değil, “yenileme takibinde şu kadar zaman kazandık ve şu riskleri azalttık” olmalıdır.

Pilot Kapsamı Nasıl Belirlenir?

En sık yapılan hata, firmanın bütün sözleşmelerini ilk günden sisteme aktarmaya çalışmaktır. Bu yaklaşım hem veri temizliğini zorlaştırır hem de çalışanların yeni programa karşı direnç geliştirmesine neden olabilir.

İdeal pilot kapsamı, şirket büyüklüğüne göre 30 ila 100 bakım sözleşmesi içerebilir. Çok küçük firmalarda daha düşük sayıyla başlanabilir. Önemli olan yalnızca kolay ve sorunsuz müşterileri değil, farklı senaryoları temsil eden kayıtları seçmektir.

Pilot grubuna şu tür sözleşmelerin dengeli biçimde alınması yararlı olur:

• Önümüzdeki 30–90 gün içinde yenilenecek sözleşmeler
• Birden fazla asansörü bulunan site veya işletmeler
• Fiyat güncellemesi bekleyen eski sözleşmeler
• Ödeme veya iletişim problemi yaşanan müşteriler
• Farklı bakım paketlerine sahip binalar
• Yeni kazanılan müşteriler
• Yakın zamanda kaybedilme riski bulunan sözleşmeler
• Birden fazla muhatabı bulunan apartman ve site yönetimleri

Pilotun yalnızca “temiz” müşterilerle yürütülmesi yanıltıcı sonuç verir. Gerçek sistem; yönetici değişikliği, eksik telefon numarası, imzasız nüsha, yanlış bitiş tarihi ve birden fazla cihaz gibi günlük sorunlarla karşılaştığında sınanmalıdır.

Pilot kapsamı	Önerilen yaklaşım	Kontrol edilecek sonuç
Müşteri sayısı	20–60 farklı müşteri	Arama, filtreleme ve kullanıcı kolaylığı
Sözleşme sayısı	30–100 sözleşme	Bitiş tarihi ve durum takibi
Uygulama süresi	30 gün	Düzenli kullanım ve ölçülebilir değişim
Kullanıcı sayısı	3–7 kişi	Yetki, sorumluluk ve ekip adaptasyonu
Yenileme dönemi	30–90 gün içinde dolacak kayıtlar	Hatırlatma ve satış takibi
Toplantı sıklığı	Haftada bir, 20–30 dakika	Sorunların ve kazanımların değerlendirilmesi

Pilot Ekibi ve Sorumluluklar Nasıl Kurulmalı?

Pilot proje yalnızca bilgi işlem veya muhasebe personeline bırakılmamalıdır. Asansör sözleşmesi; satış, operasyon, tahsilat ve müşteri ilişkilerini aynı anda etkiler. Bu nedenle küçük fakat farklı görevleri temsil eden bir ekip kurulmalıdır.

Pilot proje sorumlusu

Firma sahibi, satış müdürü veya operasyon yöneticisi pilotun ana sorumlusu olabilir. Bu kişinin görevi her veriyi kendisinin girmesi değil, kapsamın korunmasını ve alınan kararların uygulanmasını sağlamaktır.

Satış temsilcisi

Satış temsilcisi yenileme görüşmelerini, teklif durumlarını, müşteri itirazlarını ve sonraki görüşme tarihini sisteme işler. Programın gerçekten günlük satış sürecine uyup uymadığını en iyi değerlendirecek kişilerden biridir.

Ofis personeli

Ofis çalışanı müşteri kartlarını, bina bilgilerini ve sözleşme belgelerini kontrol eder. Eksik veya birbiriyle çelişen kayıtların bulunmasında önemli rol oynar.

Operasyon temsilcisi

Operasyon sorumlusu, sözleşmede yer alan cihaz ve bakım kapsamının sahadaki gerçek durumla eşleşip eşleşmediğini inceler. Örneğin sözleşmede üç asansör görünürken bakım planında iki cihaz bulunması önemli bir veri uyuşmazlığıdır.

Yönetim temsilcisi

Firma sahibi veya yetkili yönetici, pilot sonunda ölçülen sonuçları maliyet, verimlilik ve ticari risk açısından değerlendirir. Son karar yalnızca kullanıcı yorumuna değil verilere dayanmalıdır.

Başlamadan Önce Veri Hazırlığı

Pilot projenin başarısı büyük ölçüde aktarılan verinin kalitesine bağlıdır. Yanlış bitiş tarihi girilmiş bir sözleşmenin doğru zamanda hatırlatılması mümkün değildir. Programdan önce veri temizliği yapılması bu nedenle zorunludur.

Her pilot sözleşme için mümkün olduğunca şu bilgiler hazırlanmalıdır:

1. Müşteri veya yönetim unvanı
2. Bina, site ya da tesis adı
3. Açık adres
4. Yetkili kişinin adı ve iletişim bilgileri
5. Sözleşme başlangıç ve bitiş tarihi
6. Aylık veya yıllık sözleşme bedeli
7. KDV uygulaması ve ödeme dönemi
8. Sözleşme kapsamındaki asansörler
9. Bakım paketi veya hizmet kapsamı
10. Yenileme ve fiyat artış koşulları
11. İmzalı sözleşme dosyası
12. Varsa fesih bildirimi ve özel hükümler
13. Son müşteri görüşmesi
14. Sorumlu satış veya müşteri temsilcisi

Bu aşamada fiziksel klasörler ile Excel kayıtları karşılaştırılmalıdır. Hangi bilginin esas alınacağı belirlenmeden toplu veri aktarımı yapılmamalıdır. Örneğin Excel’deki bitiş tarihi ile imzalı sözleşmedeki tarih farklıysa öncelikle belge kontrol edilmeli, ardından doğru kayıt sisteme girilmelidir.

Asansorex gibi sözleşme ve bakım süreçlerini birlikte izleyebilen bir yazılım kullanıldığında müşteri, bina, cihaz ve sözleşme bilgilerinin ilişkili tutulması kolaylaşır. Ancak yazılım ne kadar gelişmiş olursa olsun, hatalı kaynak veriyi kendiliğinden doğru hale getirmeyeceği unutulmamalıdır.

30 Günlük Pilot Uygulama Planı

Pilot çalışma kısa fakat yoğun biçimde yönetilmelidir. Çok uzun tutulan denemelerde ekip odağını kaybedebilir; çok kısa tutulan uygulamalarda ise yenileme ve takip işleyişi yeterince görülemez. Çoğu firma için 30 günlük plan pratik bir başlangıçtır.

İlk hafta: Kurulum ve doğrulama

İlk hafta pilot müşteriler sisteme alınır, kullanıcı yetkileri tanımlanır ve veri kontrolü yapılır. Ekip, temel kullanım senaryoları üzerinden kısa bir eğitim almalıdır.

İlk haftanın kontrol noktaları şunlardır:

• Pilot kapsamındaki sözleşmelerin tamamı kaydedildi mi?
• Başlangıç ve bitiş tarihleri doğrulandı mı?
• Sözleşme dosyaları ilgili kayıtlara eklendi mi?
• Her müşteri için sorumlu personel belirlendi mi?
• Hatırlatma süreleri firma politikasına göre ayarlandı mı?
• Kullanıcılar yalnızca görevleriyle ilgili bilgilere erişebiliyor mu?

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

Bu haftada ekip, eski takip yöntemini referans olarak tutsa bile tüm yeni görüşmeleri programa işlemelidir. Müşteri araması yapıldığında görüşme sonucu, sonraki işlem tarihi ve teklif durumu aynı gün kaydedilmelidir.

Amaç çalışanlara ek iş oluşturmak değil, dağınık notların yerini ortak kayıt düzenine bırakmaktır. Bir görüşmenin hem kâğıda hem Excel’e hem programa yazılması pilot süresince sürdürülebilir değildir. Geçici çift kayıt gerekiyorsa bunun süresi önceden sınırlandırılmalıdır.

Üçüncü hafta: Yenileme senaryoları

Üçüncü hafta, yaklaşan sözleşmeler için gerçek yenileme süreci işletilir. Satış sorumlusu müşteriyi arar, fiyat teklifini iletir ve sonucu kaydeder. Yönetim aşağıdaki durumları ayrı ayrı izlemelidir:

• Görüşme bekliyor
• Müşteriye ulaşılamadı
• Teklif gönderildi
• Pazarlık devam ediyor
• Yenilendi
• Fesih riski var
• Rakip teklif bekleniyor
• Sözleşme sona erdi

Bu durumların şirket içinde ortak anlam taşıması önemlidir. “Beklemede” gibi belirsiz bir ifade yerine, bir sonraki eylemi gösteren net durumlar kullanılmalıdır.

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

Son hafta yeni sistemden alınan veriler eski yöntemle karşılaştırılır. Kaç sözleşmenin zamanında fark edildiği, kaç yenileme görüşmesinin planlandığı ve kullanıcıların işlem başına ne kadar zaman harcadığı ölçülür.

Pilot sonunda üç karardan biri verilebilir:

• Yazılım mevcut haliyle şirket geneline yayılır.
• Belirli düzenlemeler ve ek eğitim sonrasında ikinci aşamaya geçilir.
• Kritik ihtiyaçlar karşılanmadığı için farklı çözüm değerlendirilir.

Başarı Ölçütleri Nasıl Belirlenir?

Başarı göstergeleri pilot başlamadan yazılmalıdır. Pilot tamamlandıktan sonra ölçüt belirlemek, sonuçların kişisel yorumlara göre değiştirilmesine yol açabilir.

Örnek performans göstergeleri şunlardır:

Başarı göstergesi	Pilot öncesi durum	30 günlük hedef
Eksik bitiş tarihi bulunan sözleşme oranı	Ölçülür	Yüzde 5’in altı
Zamanında başlatılan yenileme görüşmesi	Ölçülür	Yüzde 90 ve üzeri
Güncel sözleşmeye ulaşma süresi	Ölçülür	1 dakikanın altı
Kayıt altına alınan müşteri görüşmeleri	Ölçülür	Yüzde 95 ve üzeri
Sorumlusu belli olmayan sözleşmeler	Ölçülür	Sıfır
Haftalık aktif kullanıcı oranı	Ölçülür	Yüzde 80 ve üzeri

Bu oranlar her firmaya aynen uygulanmak zorunda değildir. Örneğin beş kişilik bir ekipte yüzde hesabı yerine aktif kullanıcı sayısı izlenebilir. Önemli olan hedeflerin açık, ölçülebilir ve iş sonucuyla bağlantılı olmasıdır.

Mali etki de değerlendirilmelidir. Bir sözleşmenin yenilemesinin unutulması, yalnızca bir aylık bakım bedelinin kaybı değildir. Müşterinin rakip firmaya geçmesi halinde yıllık bakım geliri, arıza hizmetleri ve muhtemel modernizasyon fırsatları birlikte kaybedilebilir.

Pilot Sırasında Yapılan Yaygın Hatalar

Çok geniş kapsamla başlamak

Bütün arşivin ilk haftada aktarılması ekibi yorar. Önce temsili müşteri grubu denenmeli, veri aktarım yöntemi doğrulandıktan sonra kapsam genişletilmelidir.

Sadece yöneticinin sistemi kullanması

Programı firma sahibi düzenli kullanırken satış ve ofis ekibi eski yöntemle devam ediyorsa gerçek pilot yapılmış sayılmaz. Yazılım, işi yapan personelin günlük akışında sınanmalıdır.

Eğitimi özellik anlatımına çevirmek

Eğitimde her menüyü göstermek yerine gerçek görevler çalışılmalıdır. “Süresi 45 gün sonra dolacak müşteriyi bul, görüşme ekle ve sonraki aramayı planla” gibi senaryolar daha kalıcıdır.

Başarıyı yalnızca kullanıcı memnuniyetiyle ölçmek

Kullanıcıların programı sevmesi önemlidir ancak tek ölçüt değildir. Daha az yenileme kaçırılması, sözleşmeye hızlı erişim ve görevlerin zamanında tamamlanması gibi sonuçlar ayrıca ölçülmelidir.

Mevcut süreci sorgulamadan dijitalleştirmek

Karmaşık bir Excel düzenini aynı şekilde programa taşımak dijitalleşme değildir. Gereksiz durumlar, tekrarlanan alanlar ve belirsiz sorumluluklar pilot sırasında sadeleştirilmelidir.

Pilot Sonrası Şirket Geneline Geçiş

Pilot başarılı olduğunda tüm sözleşmeler bir günde aktarılmamalıdır. Kademeli geçiş daha güvenlidir. Sözleşmeler; bölgeye, satış sorumlusuna, yenileme ayına veya müşteri grubuna göre partiler halinde sisteme alınabilir.

Geçiş sırasında şu sıra izlenebilir:

1. Önümüzdeki üç ay içinde süresi dolacak sözleşmeler
2. Yüksek cirolu veya çok cihazlı müşteriler
3. Eksik belge riski bulunan kayıtlar
4. Kalan aktif bakım sözleşmeleri
5. Sona ermiş ve arşivlenmesi gereken sözleşmeler

Her aktarım grubundan sonra örnek kayıt kontrolü yapılmalıdır. Ayrıca şirket içinde “sözleşme sisteme girilmeden aktif kabul edilmez” gibi net bir çalışma kuralı oluşturulmalıdır.

Asansorex üzerinden sözleşme tarihleri, müşteri kayıtları ve bakım süreçlerinin birlikte takip edilmesi, pilot sonrasında farklı ekiplerin aynı güncel bilgi üzerinden çalışmasına yardımcı olabilir. Buradaki asıl kazanım yalnızca dijital arşiv değil, yaklaşan ticari risklerin görünür hale gelmesidir.

Sıkça Sorulan Sorular

Pilot proje kaç gün sürmeli?

Genel uygulamada 30 gün, hem ekip kullanımını hem de yenileme senaryolarını görmek için yeterli bir başlangıçtır. Çok az sözleşmesi bulunan firmalarda 14 günlük pilot yapılabilir; ancak bu süre içinde gerçek yenileme işlemleri gözlenmelidir.

Pilot çalışmaya kaç sözleşme alınmalı?

Firma büyüklüğüne bağlı olmakla birlikte 30–100 sözleşme çoğu işletme için yönetilebilir bir aralıktır. Sayıdan daha önemli olan, seçilen sözleşmelerin farklı müşteri ve risk türlerini temsil etmesidir.

Eski Excel kayıtları tamamen bırakılmalı mı?

Pilotun ilk günlerinde doğrulama amacıyla Excel dosyası korunabilir. Ancak günlük işlemlerin sürekli iki sisteme birden girilmesi doğru değildir. Eski dosyanın yalnızca referans olduğu tarih ve yeni sistemin esas alınacağı gün açıkça belirlenmelidir.

İmzalı sözleşme bulunmuyorsa kayıt açılmalı mı?

Kayıt açılabilir ancak belge eksikliği açıkça işaretlenmeli ve sorumlu personele tamamlama görevi verilmelidir. Eksik belgenin fark edilmesi de pilot projenin sağladığı önemli çıktılardan biridir.

Pilot başarısız olursa yazılım hemen elenmeli mi?

Önce başarısızlığın nedeni incelenmelidir. Sorun eksik eğitimden, hatalı veriden veya yanlış pilot kapsamından kaynaklanıyorsa düzeltme yapılarak kısa bir ikinci aşama uygulanabilir. Temel iş ihtiyacı karşılanmıyorsa alternatif çözüm değerlendirilmelidir.

Bina yöneticileri pilot sürece dahil edilmeli mi?

Seçilmiş birkaç bina yöneticisinden iletişim, teklif ve yenileme süreci hakkında geri bildirim alınabilir. Ancak iç kullanım ekranlarının müşteriye gösterilmesi gerekmez; müşteri açısından önemli olan doğru zamanda, tutarlı bilgiyle iletişim kurulmasıdır.

Özet

Asansör Sözleşme Programı için doğru tasarlanmış pilot proje, satın alma kararını özellik listelerinden çıkarıp gerçek iş sonuçlarına taşır. Temsili bir müşteri grubu seçmek, verileri temizlemek, ekip sorumluluklarını belirlemek ve başarı göstergelerini önceden yazmak sürecin temelidir. Yaklaşık 30 günlük kontrollü uygulama sonunda firma; yenileme takibinin güçlenip güçlenmediğini, sözleşmelere erişimin hızlanıp hızlanmadığını ve çalışanların sistemi sürdürülebilir biçimde kullanıp kullanamadığını açıkça görebilir. Böylece şirket geneline geçiş daha düşük riskle ve daha sağlam bir veri düzeniyle gerçekleştirilir.