Asansör Teklif Programı Değiştirme Kararları

İÇERİK

Asansör bakım sektöründe teklif hazırlamak yalnızca müşteriye bir fiyat göndermek değildir. Bakım kapsamı, asansör sayısı, aylık bakım bedeli, parça dahil veya hariç koşullar, ödeme şekli, teklif geçerlilik tarihi ve gerektiğinde revizyonlar aynı süreç içinde yönetilir. Firma büyüdükçe birkaç Excel dosyası veya temel bir teklif programı yeterli görünmemeye başlayabilir. Asansör teklif programı değiştirme kararı, yalnızca mevcut yazılımın eski görünmesi nedeniyle değil; satış süreçlerinde zaman kaybı, fiyat hatası, revizyon karmaşası ve fırsat kaybı oluşmaya başladığında gündeme alınmalıdır.

Doğru zamanda yapılan bir yazılım değişikliği teklif hazırlama süresini kısaltabilir, müşteriye daha profesyonel dokümanlar gönderilmesini sağlayabilir ve satış ekibinin hangi teklifin hangi aşamada olduğunu izlemesini kolaylaştırabilir. Ancak acele verilen bir değişim kararı da geçmiş tekliflerin kaybolması, personelin yeni sisteme adapte olamaması veya mevcut iş akışının bozulması gibi sorunlara neden olabilir.

Bu nedenle karar verirken yalnızca yazılım özelliklerini değil, firmanın günlük teklif sürecindeki gerçek sorunları değerlendirmek gerekir.

Asansör Teklif Programının Değişmesi Gerektiğini Gösteren İşaretler

Bir teklif programını yıllardır kullanıyor olmak, o programın hâlâ firma için doğru araç olduğu anlamına gelmez. Özellikle bakım portföyü ve satış ekibi büyüdükçe sistemin sınırları daha görünür hale gelir.

Teklif hazırlamak gereğinden uzun sürüyorsa

Bir satış personeli standart bir bakım teklifi hazırlamak için sürekli eski Word dosyalarını açıyor, fiyatları Excel'den kontrol ediyor ve müşteri bilgilerini manuel kopyalıyorsa süreç gereksiz yere uzar.

Örneğin 10 asansörlü bir site için teklif hazırlanırken şu işlemler ayrı ayrı yapılıyorsa sorun vardır:

• Müşteri bilgilerini başka bir dosyadan kopyalamak
• Asansör sayısını manuel girmek
• Birim bakım fiyatını hesaplamak
• KDV ve toplam tutarı kontrol etmek
• Teklif şartlarını eski bir belgeden almak
• PDF oluşturmak
• WhatsApp veya e-posta üzerinden göndermek
• Sonrasında müşteriye tekrar dönüş tarihini ayrıca not etmek

Bu işlemler birkaç teklif için yönetilebilir. Fakat ayda 50–100 teklif hazırlanıyorsa ciddi zaman kaybı oluşur.

Revizyon geçmişi takip edilemiyorsa

Asansör sektöründe müşterinin ilk teklifi doğrudan kabul etmesi her zaman mümkün değildir.

Örneğin ilk teklif:

12 asansör x 1.500 TL = 18.000 TL / ay

olarak hazırlanabilir.

Müşteri daha sonra:

• Fiyat indirimi isteyebilir.
• Yıllık ödeme seçeneği sorabilir.
• Bazı parçaların sözleşmeye dahil edilmesini talep edebilir.
• Bakım kapsamının değiştirilmesini isteyebilir.

İkinci teklif 17.000 TL, üçüncü teklif ise 16.500 TL olabilir. Eski sistem yalnızca son PDF'yi saklıyorsa, birkaç ay sonra ilk fiyatın ne olduğu, kimin indirim yaptığı ve hangi koşulların değiştiği bilinmeyebilir.

Bu durum özellikle satış kârlılığı açısından risklidir.

Eski Sistem Firmanın Satış Performansını Nasıl Etkiler?

Teklif programının yetersizliği çoğu zaman doğrudan "yazılım problemi" olarak görülmez. Sorun farklı noktalarda kendini gösterir.

Sorun	Günlük Etkisi	Uzun Vadeli Sonuç
Teklif hazırlama süresinin uzun olması	Satış personeli daha az müşteriye dönüş yapar	Fırsat kaybı
Revizyonların ayrı dosyalarda tutulması	Eski fiyatlar karışabilir	Kârlılık hatası
Teklif durumunun bilinmemesi	Takip aramaları unutulur	Satış oranı düşebilir
Standart şablon bulunmaması	Her personel farklı teklif hazırlar	Kurumsal görünüm bozulur
Mobil erişim olmaması	Sahadaki satışçı ofise bağımlı kalır	Yanıt süresi uzar
Müşteri geçmişinin dağınık olması	Önceki görüşmeler bulunamaz	Müşteri deneyimi zayıflar

Buradaki kritik nokta şudur: Teklif sistemi satış ekibinin hızını sınırlamaya başladıysa yazılım maliyetinden daha büyük bir operasyon maliyeti oluşabilir.

Bir bakım firması ayda 80 teklif gönderiyorsa ve her teklif ortalama 15 dakika gereksiz manuel işlem içeriyorsa ayda yaklaşık 20 saat yalnızca tekrar eden işlere harcanır.

Bu süre doğrudan satış görüşmesine, müşteri ziyaretine veya takip aramasına ayrılabilir.

Program Değiştirme Kararı Vermeden Önce Sorulması Gereken Sorular

Yeni yazılım aramadan önce mevcut problemleri netleştirmek gerekir. Aksi halde firma yalnızca farklı arayüze sahip ama aynı sorunları yaşatan başka bir sisteme geçebilir.

Karar öncesinde şu sorular cevaplanmalıdır:

1. Bir teklif ortalama kaç dakikada hazırlanıyor?
2. Ayda kaç teklif oluşturuluyor?
3. Tekliflerin kaçında revizyon yapılıyor?
4. Eski tekliflere ne kadar hızlı ulaşılabiliyor?
5. Teklifin görüntülenip görüntülenmediği veya müşteriye ulaşıp ulaşmadığı takip edilebiliyor mu?
6. Satış personeli teklif durumlarını düzenli olarak güncelliyor mu?
7. Kabul edilen teklif kolayca sözleşmeye dönüştürülebiliyor mu?
8. Fiyat değişikliklerinin geçmişi görülebiliyor mu?
9. Yetkisiz personelin fiyat değiştirmesi engellenebiliyor mu?
10. Aynı müşteriye gönderilen farklı teklif versiyonları karışıyor mu?

Bu soruların birkaçına bile olumsuz cevap veriliyorsa mevcut sistem gözden geçirilmelidir.

İyi bir teklif programının görevi yalnızca PDF üretmek değil, teklifin hazırlanmasından satış sonucuna kadar geçen süreci izlenebilir hale getirmektir.

Yeni Asansör Teklif Programında Hangi Özellikler Aranmalı?

Program değiştirme kararı verildiğinde en sık yapılan hata, mümkün olduğunca fazla özelliğe sahip yazılım aramaktır. Oysa önemli olan özellik sayısı değil, asansör firmasının iş akışına uygunluk düzeyidir.

Teklif şablonları

Bakım, revizyon, modernizasyon veya parça satışı gibi farklı iş türleri için ayrı şablonlar oluşturulabilmelidir.

Örneğin bakım teklifinde:

• Asansör sayısı
• Aylık bakım bedeli
• Hizmet kapsamı
• Parça dahil/hariç bilgisi
• Ödeme koşulları
• Teklif geçerlilik süresi

ön plana çıkarken, revizyon teklifinde malzeme kalemleri ve işçilik detayları daha önemli olabilir.

Revizyon takibi

Teklif değiştirildiğinde eski sürüm kaybolmamalıdır.

Örneğin:

• Revizyon 0: 95.000 TL
• Revizyon 1: 89.000 TL
• Revizyon 2: 87.500 TL

şeklinde geçmiş görülebilmelidir.

Bu kayıtlar satış yöneticisinin verilen indirimleri kontrol etmesini de kolaylaştırır.

Teklif durumları

Teklif yalnızca "hazırlandı" şeklinde kayıtlı kalmamalıdır.

Pratik durumlar şunlar olabilir:

• Taslak
• Gönderildi
• Görüşme aşamasında
• Revizyon istendi
• Onaylandı
• Reddedildi
• Süresi doldu

Bu yapı sayesinde satış ekibi hangi tekliflere tekrar dönmesi gerektiğini kolayca belirleyebilir.

Tekliften sözleşmeye geçiş

Özellikle periyodik bakım hizmetlerinde kabul edilen teklifin yeniden elle yazılmadan sözleşme sürecine aktarılması önemli bir avantajdır.

Müşteri, bina, asansör sayısı, fiyat ve hizmet kapsamı gibi bilgiler tekrar girilmemelidir.

Asansorex gibi asansör sektörüne yönelik sistemlerde teklif, müşteri ve operasyon bilgilerinin aynı yapı içinde tutulması, kabul edilen bir teklifin sonraki iş süreçlerine aktarılmasını kolaylaştırabilir.

Program Değiştirirken Veri Kaybı Nasıl Önlenir?

Yeni programa geçerken en büyük hata, eski sistemi hemen kapatmaktır.

Öncelikle geçmiş veriler yedeklenmelidir.

Taşınması gereken temel kayıtlar şunlardır:

• Aktif müşteri listesi
• Bina bilgileri
• İletişim kişileri
• Açık teklifler
• Kabul edilmiş teklifler
• Reddedilmiş teklifler
• Teklif revizyonları
• Kullanılan fiyat listeleri
• Standart teklif açıklamaları
• Sözleşmeye dönüşmüş teklifler

Eski PDF tekliflerin tamamının yeni sisteme tek tek işlenmesi her zaman gerekli olmayabilir. Ancak özellikle aktif müşteriler, açık fırsatlar ve son dönem satış kayıtları öncelikli tutulmalıdır.

Paralel kullanım yapılabilir

Geçişin ilk gününde eski sistemi tamamen bırakmak yerine kısa süreli paralel kullanım daha güvenlidir.

Örneğin:

1. hafta: Yeni sistemde deneme teklifleri oluşturulur.

2. hafta: Yeni gelen tüm teklifler yeni sistemden hazırlanır.

3. hafta: Açık eski teklifler aktarılır.

4. hafta: Eski sistem yalnızca arşiv amacıyla tutulur.

Bu yöntem personelin yeni programa alışmasını kolaylaştırır.

Değişim Kararı Maliyet Üzerinden Değil Verimlilik Üzerinden Verilmeli

Asansör firmaları yazılım değiştirirken genellikle ilk olarak yıllık lisans ücretini karşılaştırır. Fakat yalnızca fiyat üzerinden karar vermek yanıltıcı olabilir.

Örneğin mevcut sistem yıllık 8.000 TL, yeni sistem 20.000 TL olabilir.

Aradaki fark 12.000 TL'dir.

Ancak yeni sistem sayesinde:

• Teklif hazırlama süresi azalıyor,
• Satış takipleri unutulmuyor,
• Revizyon hataları düşüyor,
• Satış personeli daha fazla müşteriye ulaşabiliyor,
• Kabul edilen teklif hızlıca sözleşmeye dönüşüyorsa,

yazılımın gerçek değeri yalnızca lisans fiyatıyla ölçülemez.

Basit bir hesap yapılabilir:

Firma ayda 60 teklif hazırlıyor ve yeni sistem her teklifte ortalama 10 dakika kazandırıyorsa:

60 x 10 dakika = 600 dakika

Bu da ayda yaklaşık 10 saat, yılda yaklaşık 120 saatlik operasyon tasarrufu anlamına gelir.

Buna kaybedilen tekliflerin geri kazanılması dahil değildir.

Hangi Durumlarda Programı Hemen Değiştirmek Gerekmeyebilir?

Her problem yazılım değiştirmeyi gerektirmez.

Bazı durumlarda mevcut sistem doğru yapılandırılmamış olabilir.

Örneğin:

• Teklif şablonları oluşturulmamış olabilir.
• Personel programın özelliklerini bilmiyor olabilir.
• Teklif durumları düzenli güncellenmiyor olabilir.
• Fiyat listeleri sisteme tanımlanmamış olabilir.
• Yetki ayarları yanlış yapılmış olabilir.

Bu durumda önce süreç iyileştirilmelidir.

Mevcut yazılımın sağlayıcısından eğitim veya destek alınabilir. Sorun kullanıcı alışkanlığından kaynaklanıyorsa program değişikliği aynı problemin yeni sistemde de devam etmesine neden olur.

Ancak sistem temel olarak revizyon geçmişi, teklif takibi veya müşteri bağlantısı gibi ihtiyaçları desteklemiyorsa yazılım değişimi daha mantıklı hale gelir.

Yeni Sisteme Geçiş İçin Pratik Kontrol Listesi

Değişim sürecinde aşağıdaki kontrol listesi kullanılabilir:

• Mevcut sistemdeki sorunları yazılı hale getirin.
• Kullanıcıların en çok zaman kaybettiği işlemleri belirleyin.
• En az 3 gerçek teklif senaryosunu yeni yazılımda test edin.
• Bakım ve revizyon tekliflerini ayrı ayrı deneyin.
• PDF çıktısının müşteriye uygunluğunu kontrol edin.
• Teklif revizyon geçmişini test edin.
• Kullanıcı yetkilerini inceleyin.
• Tekliften sözleşmeye geçişi deneyin.
• Açık tekliflerin nasıl aktarılacağını belirleyin.
• Eski kayıtların yedeğini alın.
• Satış personeline kısa bir eğitim verin.
• İlk ay sonuçlarını ölçün.

Demo sırasında yalnızca hazır ekranların gösterilmesini izlemek yerine şirketinizde gerçekten kullanılan bir teklifin sisteme girilmesini istemek çok daha doğru sonuç verir.

Örneğin "8 asansörlü bina için yıllık bakım teklifi oluştur, ardından müşteri yüzde 10 indirim istediğinde revizyon yap" şeklinde gerçek bir senaryo denenebilir.

Sıkça Sorulan Sorular

Asansör teklif programı ne zaman değiştirilmelidir?

Teklif hazırlama süresi uzuyorsa, revizyonlar karışıyorsa, satış takipleri unutuluyorsa veya kabul edilen tekliflerin sonraki süreçlere aktarılması yoğun manuel işlem gerektiriyorsa program değişimi değerlendirilmelidir.

Eski teklifler yeni programa aktarılmalı mı?

Tüm arşivin aktarılması her zaman gerekli değildir. Öncelikle aktif müşteriler, açık teklifler, güncel fiyatlar ve yakın dönemde hazırlanmış önemli tekliflerin taşınması daha pratiktir. Eski kayıtlar ayrıca arşivlenebilir.

Excel yerine teklif programı kullanmak gerekli mi?

Az sayıda teklif hazırlayan küçük firmalarda Excel bir süre yeterli olabilir. Ancak teklif sayısı arttığında revizyon kontrolü, takip, kullanıcı yetkilendirmesi ve raporlama gibi ihtiyaçlar Excel'de zorlaşır.

Yeni teklif programında en önemli özellik nedir?

Tek bir özellik öne çıkmaz. Hızlı teklif hazırlama, revizyon geçmişi, teklif durum takibi, müşteri kaydı ve tekliften sözleşmeye geçiş birlikte değerlendirilmelidir.

Teklif programını değiştirmek satışları artırır mı?

Tek başına yazılım satış garantisi vermez. Ancak teklif hazırlama süresini kısaltması, takiplerin düzenli yapılmasını sağlaması ve satış fırsatlarının unutulmasını önlemesi satış sürecinin verimliliğini artırabilir.

Yeni sisteme geçiş ne kadar sürede yapılmalı?

Bu süre firma büyüklüğüne ve taşınacak veri miktarına göre değişir. Genel uygulamada kritik verilerin önce aktarılması ve kısa bir paralel kullanım dönemiyle ilerlenmesi, ani geçişe göre daha kontrollü bir yöntemdir.

Özet

Asansör teklif programı değiştirme kararı, yalnızca mevcut yazılımın eski olması nedeniyle verilmemelidir. Asıl değerlendirilmesi gereken; teklif hazırlama süresi, revizyon kontrolü, satış takibi, müşteri geçmişi ve tekliflerin sözleşmeye dönüşme sürecidir.

Teklifler farklı dosyalara dağılıyorsa, fiyat revizyonlarının geçmişi görülemiyorsa, satış personeli müşteriye dönüşleri manuel olarak takip ediyorsa veya standart bir teklif hazırlamak gereğinden uzun sürüyorsa mevcut yapı firmanın büyümesini yavaşlatıyor olabilir.

Yeni sistem seçerken özellik listesinden çok gerçek iş akışınızı test etmek önemlidir. Kendi bakım ve revizyon tekliflerinizi demo sırasında hazırlatmak, sistemin firmanıza uygunluğunu en hızlı şekilde ortaya çıkarır.

Asansorex gibi asansör bakım firmalarının teklif, sözleşme, müşteri ve saha süreçlerini birlikte ele alan çözümler, özellikle farklı araçlar arasında tekrar veri girişi yapılan işletmelerde süreci daha bütünlüklü yönetmeye yardımcı olabilir. En doğru karar ise yazılım fiyatından önce kaybedilen zamanı, teklif hatalarını ve kaçırılan satış fırsatlarını ölçerek verilir.