Asansör Teklif-Sözleşme Programı Alırken Yapılmaması Gerekenler

İÇERİK

Bir asansör bakım firmasında teklif göndermek yalnızca fiyat yazıp PDF oluşturmak değildir. Binadaki asansör sayısı, bakım kapsamı, arıza hizmetinin sınırları, malzeme koşulları, ödeme düzeni ve sözleşmenin başlangıç tarihi aynı süreçte doğru yönetilmelidir. Bu nedenle Asansör Teklif-Sözleşme Programı seçerken güzel görünen bir belge şablonu tek başına yeterli ölçüt olmaz. Yanlış seçim, satış ekibine tekrar iş çıkarabilir; imzalanan koşullarla sahada verilen hizmet arasında fark oluşmasına da yol açabilir.

Bu rehber, satın alma görüşmesinde sık yapılan hataları somut örneklerle gösteriyor. Amaç, bir yazılımı kendi firmanızın gerçek teklif ve sözleşme akışıyla sınayabilmeniz.

1. Mevcut süreci çıkarmadan ürün seçmek

İlk hata, yazılım demosuna firmanın nasıl çalıştığını tarif etmeden girmektir. Bir bakım firması teklifleri bina yöneticisine e-postayla gönderirken başka bir firma önce keşif yapar, sonra revize fiyat verir ve son sürümü yüz yüze onaylatır. İki firmanın ihtiyaç duyduğu kayıt ve takip adımları aynı değildir.

Demo öncesinde yakın zamanda sonuçlanmış üç işi seçin: kabul edilen bir teklif, fiyatı değişen bir teklif ve kaybedilen bir teklif. Her biri için şu soruları yanıtlayın:

• İlk talep kimden ve hangi kanaldan geldi?
• Keşifte hangi asansör ve bina bilgileri toplandı?
• Teklifi kim hazırladı, fiyatı kim kontrol etti?
• Müşteriye kaç sürüm gönderildi?
• Kabul edilen koşullar sözleşmeye nasıl aktarıldı?
• İş sonuçlanmadıysa gerekçe kaydedildi mi?

Bu çalışma, demoda genel bir özellik turu yerine kendi işinizi baştan sona denemenizi sağlar. Örneğin teklif üç kez değişiyorsa eski sürümün hangisi olduğunu bulabilmek önem kazanır. Satış temsilcisi ayrıldığında müşteriyle görüşülen son koşullara ulaşmak da aynı derecede önemlidir.

2. Yalnızca teklif PDF’sinin görünüşüne karar vermek

Logo, renk ve düzen önemlidir; müşterinin gördüğü belge firmanızı temsil eder. Ancak iyi görünen bir PDF, eksik ya da çelişkili içeriği düzeltmez. Teklifte “aylık bakım” yazarken sözleşmede farklı bir hizmet kapsamı bulunması, sonradan açıklanması güç bir durum yaratır.

Örnek bir bina için demoda şu bilgileri girin: iki asansör, ayrı bakım bedelleri, önerilen bir revizyon işi ve geçerlilik tarihi olan bir teklif. Oluşan PDF’yi okuyarak kontrol edin:

• Bina ve asansörler açıkça ayırt ediliyor mu?
• Bakım bedeli ile bir defalık işlerin bedeli ayrı görünüyor mu?
• Toplam ve ödeme koşulları anlaşılır mı?
• Teklifin geçerlilik tarihi görünür mü?
• Revize teklif gönderildiğinde sürümler karışıyor mu?

Müşterinin anlayamadığı bir teklif, ofiste hızlı hazırlanmış olsa bile satış görüşmesini uzatır. Bu nedenle PDF’yi yalnızca ekranda önizlemekle yetinmeyin; indirip gerçek bir müşteri gibi baştan sona okuyun.

3. Hazır sözleşme metnini incelemeden kullanmak

Bir programın sözleşme şablonu sunması, o metnin firmanızın bütün ticari koşullarına uyduğu anlamına gelmez. Özellikle bakım kapsamı, arıza müdahalesi, parça ve malzeme bedelleri, ödeme koşulları ile yenileme süreci firma bazında değerlendirilmelidir. Sözleşme diliyle ilgili tereddütlerde metni hukuk danışmanınıza inceletin.

Satın almadan önce kullandığınız güncel sözleşmeyle sistemden üretilen örneği yan yana koyun. Hangi alanların her müşteri için değiştiğini belirleyin. Örneğin asansör sayısı, adres, başlangıç tarihi ve bedel değişken olabilir; firmanızın onayladığı standart maddeler ise kontrollü biçimde kullanılmalıdır.

Elle sonradan düzenleme gerektiren her alanı not edin. Her sözleşmede PDF indirip başka bir programda düzeltme yapmak zorundaysanız, yazılım hazırlık süresini beklediğiniz kadar azaltmayabilir. Ayrıca sonradan düzenlenen dosyanın sistemde kayıtlı sürümle aynı olup olmadığını takip etmeniz gerekir.

4. Tekliften sözleşmeye geçişi test etmemek

Teklif kabul edildiğinde süreç bitmez; kabul edilen bedelin, bina bilgilerinin ve hizmet koşullarının sözleşmeye doğru aktarılması gerekir. Bu geçişte bilgiler yeniden elle yazılıyorsa yanlış rakam, eski adres veya eksik asansör listesi riski doğar.

Demoda bir teklif oluşturun, bedelini revize edin ve son sürümü kabul edilmiş kabul ederek sözleşme hazırlayın. Ardından iki belgeyi karşılaştırın. Sözleşme hangi teklif sürümüne dayanıyor? Kabul tarihi kaydedilebiliyor mu? Müşterinin istediği bir değişiklik yapıldığında önceki koşullara ulaşabiliyor musunuz?

Küçük bir test için yeterince somut senaryo şudur: “Üç asansör için teklif verildi. Görüşme sonunda biri kapsamdan çıkarıldı ve ödeme koşulu değişti.” Yazılım bu durumu anlaşılır biçimde yönetemiyorsa, gerçek satış görüşmelerinde ekip yine ayrı dosyalara ve mesajlaşma geçmişine dönebilir.

5. Yenileme takibini yalnızca takvim uyarısı sanmak

Sözleşmenin bitiş tarihinden önce bildirim almak faydalıdır. Fakat yenileme işi, tek bir hatırlatıcıdan ibaret değildir. Hangi müşteriye yeni fiyat gönderildiğini, kimin yanıt beklediğini ve hangi sözleşmenin yeni koşullarla kabul edildiğini de bilmek gerekir.

Örneğin aynı hafta bitecek 25 sözleşmeniz varsa, yalnızca “25 sözleşme sona eriyor” uyarısı satış ekibine iş sırası vermez. Şu ayrımların yapılabildiğini kontrol edin: görüşme planlandı, teklif gönderildi, revizyon istendi, kabul edildi veya yenilenmedi. Yenilenmeyen müşterinin gerekçesini kaydetmek de sonraki fiyatlandırma ve hizmet kararlarında işe yarar.

Uyarının ne kadar önceden verilmesi gerektiğini firmanızın görüşme süresine göre belirleyin. Büyük bir site yönetiminde karar ve imza süreci uzayabilir; tek asansörlü bir binada daha kısa olabilir. Her müşteriye aynı tarihte hatırlatma yapmak yerine, ekibin görüşmeye hazırlanabileceği bir düzen kurun.

6. Yetki ve onay düzenini belirsiz bırakmak

Satış ekibinde herkes teklif hazırlayabilir; fakat herkesin sınırsız indirim yapması veya standart sözleşme koşullarını değiştirmesi istenmeyebilir. Satın alma sırasında “yetkilendirme var mı?” diye sormak yerine günlük örnekler üzerinden ilerleyin.

Örneğin satış sorumlusu standart fiyatla teklif hazırladığında süreç nasıl işler? Belirlediğiniz sınırın üzerinde indirim gerektiğinde kim kontrol eder? Sözleşme metnindeki özel koşul kim tarafından gözden geçirilir? Onaylanan son belgeyi kim müşteriye gönderir?

Burada amaç ekibe gereksiz adım eklemek değildir. Firmanızda gerçekten kullanılan karar noktalarını belirleyip yazılımın bunları destekleyip desteklemediğini görmektir. İki kişilik ekip için yeterli olan akış, birden fazla şubesi ve satış temsilcisi bulunan firma için yetersiz kalabilir.

7. Müşterinin onay yöntemini varsaymak

“Online onay var” ifadesi, satın alma kararı için tek başına yeterince açık değildir. Müşteri neyi görüyor, hangi işlemi yapıyor ve firmanız hangi kaydı saklıyor? Bunları uygulamalı olarak görün. Online teklif kabulü ile sözleşmenin taraflarca imzalanması aynı işlem olarak değerlendirilmemelidir.

Bazı bina yöneticileri belgeyi e-postayla alıp yönetim kurulu görüşmesinden sonra dönüş yapar. Bazıları basılı evrak kullanır. Firmanızın müşterileri farklı yöntemlerle ilerliyorsa programın yalnızca tek bir kabul biçimine dayanması takipte boşluk oluşturabilir.

Bir deneme müşterisi üzerinden teklif gönderin. Gelen yanıtı, istenen revizyonu ve nihai kabulü kaydetmeyi deneyin. Sonradan dosyayı açan başka bir çalışan, müşterinin hangi koşulları kabul ettiğini ek açıklama istemeden anlayabilmelidir.

8. Veri aktarımını ve toplam maliyeti sona bırakmak

Yeni yazılımın değeri, mevcut müşteri ve sözleşmeleriniz sisteme taşındığında ortaya çıkar. Farklı Excel dosyalarında bina adları tutarsızsa veya eski sözleşmelerin bitiş tarihleri eksikse aktarım ayrıca çalışma gerektirir. Teklif aşamasında bunu konuşmamak, kurulum süresine ilişkin beklentiyi bozabilir.

Maliyet değerlendirmesinde de yalnızca aylık veya yıllık kullanım bedeline bakmayın. Firmanız için geçerli kalemleri yazılı teklifte görün:

Kontrol konusu	Satın almadan önce sorulacak soru	Uygulamalı test
Eski veriler	Müşteri, bina ve sözleşmeler nasıl aktarılacak?	Örnek kayıtları içe aktarın
Şablonlar	Mevcut teklif ve sözleşme düzenimiz uyarlanabiliyor mu?	Gerçek bir belge üretin
Kullanıcılar	Ekip büyüdüğünde maliyet nasıl değişiyor?	İki ekip büyüklüğü için teklif alın
Eğitim	Satış ve ofis ekibine hangi eğitim veriliyor?	Eğitim kapsamını yazılı alın
Destek	Hatalı belge veya aktarım sorunu nasıl çözülüyor?	Destek kanalını ve kapsamını sorun
Veriyi alma	Ayrılmak istersek kayıtlarımızı nasıl alırız?	Örnek dışa aktarımı görün

Bu tabloyu iki veya üç sağlayıcı için aynı şekilde doldurmak, fiyatları daha adil karşılaştırmanızı sağlar. “Kurulum dâhil” ifadesinin hangi işleri kapsadığını da netleştirin; veri temizleme ve özel şablon hazırlama gibi işler ayrıca değerlendirilebilir.

Asansorex gibi asansör bakım işine odaklanan bir yazılımı incelerken de değerlendirme ölçütü aynı olmalı: Kendi bina listenizle bir teklif hazırlayın, sözleşmeye geçişi deneyin ve yenileme takibini ekibinizin günlük işi içinde görün.

9. Saha ve müşteri bilgilerinin tutarlılığını kontrol etmemek

Teklifte yer alan asansör sayısıyla firmanın güncel bakım listesi farklıysa önce nedenini bulmak gerekir. Yeni devralınan bir bina, hizmet dışına çıkan bir asansör veya yanlış girilmiş bir adres, ticari belgeyi de etkiler. Yazılım seçerken teklif ve sözleşmede kullanılan bilgilerin nasıl güncellendiğini sorun.

Bir örnek üzerinden ilerleyin: Binada dört asansör var; ilk görüşmede üçü için bakım teklifi isteniyor. Teklifte yalnızca kapsam dahilindeki üç asansörün görünmesini sağlayın. Sözleşme yapıldıktan sonra dördüncü asansörün eklenmesi istenirse bunun hangi belge ve bedel değişikliğiyle kayda alınacağını gösterin.

Teknisyenin sahada gördüğü bilgilerle müşteriye verilen hizmet sözü arasında fark çıkarsa sorun sadece ofiste kalmaz. Teklif hazırlayan kişi ile operasyon sorumlusu, kapsamı aynı şekilde anlayabilmelidir.

10. Demoyu izleyip ekibe kullandırmadan satın almak

Ürün tanıtımı akıcı olabilir; fakat tanıtımı yapan kişi sistemi her gün kullanan ekibiniz değildir. Son karardan önce satış veya ofis çalışanınızın gerçek bir işi kendisinin yapmasını isteyin. Bir bina kaydı açsın, teklif oluştursun, fiyat değiştirsin, PDF’yi göndersin ve kabul sonrasında sözleşmeyi hazırlasın.

Denemeyi üç ölçütle değerlendirin: İş tamamlandı mı? Nerede yardım gerekti? Son belge doğru muydu? Süre tutabilirsiniz, ancak tek başına hız puanı vermeyin. İlk denemede iki dakika kazandıran bir işlem, yanlış bedel gönderme ihtimalini artırıyorsa firmanız için iyi sonuç değildir.

Pilot için en karmaşık müşteriyi seçmeniz gerekmez. Sık karşılaştığınız, birkaç asansörü olan ve teklif revizyonu ihtimali bulunan bir bina yeterlidir. Böylece deneme, firmanızın olağan işini temsil eder.

Sıkça Sorulan Sorular

Küçük bir bakım firması teklif-sözleşme programına ihtiyaç duyar mı?

Teklif ve sözleşme sayısından çok, kayıtları bulmak ve takip etmek için harcanan zamana bakın. Birkaç kişilik ekipte bile yenilemeler unutuluyor, farklı teklif sürümleri karışıyor veya müşteri koşulları yalnızca bir çalışanın mesajlarında kalıyorsa düzenli bir sistem fayda sağlayabilir. Önce mevcut iş akışınızda bu sorunların ne sıklıkla yaşandığını ölçün.

Teklif şablonu özelleştirmesi neden önemlidir?

Teklifte firmanızın gerçekten sunduğu hizmet ve fiyat yapısı açıkça görünmelidir. Bakım bedeli, ek iş, ödeme koşulu ve geçerlilik tarihi her müşteride aynı şekilde ele alınmıyorsa tek tip şablon elle düzeltme gerektirebilir. Örnek PDF üretmek, bu ihtiyacı satın almadan önce gösterir.

Online teklif onayı sözleşme imzası yerine geçer mi?

Bu işlemleri aynı kabul etmeyin. Teklifin müşteri tarafından kabul edilmesiyle sözleşmenin taraflarca tamamlanması farklı aşamalar olabilir. Kullanacağınız onay ve imza yöntemini, firmanızın belge süreci ve hukuki danışmanınızın değerlendirmesiyle belirleyin.

Eski sözleşmeleri yeni programa taşımak zorunlu mu?

Hepsini aynı anda taşımak zorunda olmayabilirsiniz. Önce yürürlükteki sözleşmelerin müşteri, bina, kapsam ve bitiş tarihi bilgilerini düzenlemek pratik bir başlangıçtır. Eski belgeler için de ekibin ihtiyaç duyduğunda ulaşabileceği bir saklama düzeni belirleyin.

Demo sırasında sorulacak en önemli soru nedir?

“Bizim gerçek bir teklifimizi, revizyonunu ve sözleşmesini burada baştan sona hazırlayabilir miyiz?” sorusunu sorun. Sonucu ekibinizin kendisinin denemesi, özellik listesinden daha açıklayıcıdır.

Özet

Asansör Teklif-Sözleşme Programı seçerken en pahalı hata, ürünü firmanızın gerçek işiyle sınamamaktır. Teklif sürümlerini, sözleşme metnini, kabul yöntemini, yenileme takibini ve veri aktarımını örnek kayıtlarla deneyin. Çıkan PDF’leri okuyun; satış ve ofis ekibine işlemleri yaptırın. Asansorex dâhil değerlendirdiğiniz her çözüm için aynı senaryoyu kullanırsanız, kararınızı vaatlere değil, tamamlanmış bir iş akışına dayandırabilirsiniz.