Asansör Teklif Programı Demo Senaryosu

İÇERİK

Bir asansör teklif programı demosu, yazılımın menülerini hızlıca gezmekten ibaret olmamalıdır. Asıl amaç, bakım firmasının günlük satış sürecinde yaşadığı gerçek bir durumu yazılım üzerinde baştan sona canlandırmaktır. Müşteri talebinin alınması, keşif bilgilerinin kaydedilmesi, bakım veya revizyon kalemlerinin eklenmesi, fiyatlandırma yapılması, teklifin PDF olarak gönderilmesi, revizyonların takip edilmesi ve kabul edilen teklifin sözleşmeye dönüştürülmesi aynı senaryo içinde test edilmelidir.

Doğru hazırlanmış bir demo senaryosu; firma sahibine yazılımın hız kazandırıp kazandırmadığını, satış personeline teklif hazırlarken hata riskini azaltıp azaltmadığını ve bina yöneticisine daha anlaşılır bir sunum yapılıp yapılmadığını gösterir. Bu rehberde, bir asansör teklif programının demosunu değerlendirirken uygulanabilecek gerçekçi bir senaryoyu adım adım inceleyeceğiz.

Demo Senaryosunun Amacı Ne Olmalıdır?

Demo başlamadan önce hangi sonucun ölçüleceği belirlenmelidir. Çünkü her teklif programı ekranda düzenli görünebilir; ancak günlük iş akışında önemli olan kullanım kolaylığı, hız, doğruluk ve izlenebilirliktir.

Demo sonunda şu soruların cevaplanabilmesi gerekir:

• Yeni bir müşteri için teklif kaç dakikada hazırlanabiliyor?
• Daha önce kullanılan hizmet ve parça kalemleri tekrar kullanılabiliyor mu?
• KDV, iskonto ve ara toplam hesaplamaları otomatik yapılıyor mu?
• Teklifin geçerlilik süresi ve ödeme koşulları açıkça yazılabiliyor mu?
• Aynı teklifin farklı revizyonları birbirine karışmadan saklanıyor mu?
• Teklif PDF olarak kurumsal bir görünümle oluşturulabiliyor mu?
• Müşteri teklifi kabul ettiğinde süreç sözleşmeye aktarılabiliyor mu?
• Firma sahibi hangi teklifin beklediğini, kabul edildiğini veya kaybedildiğini görebiliyor mu?

İyi bir demo, yazılımın ne kadar özelliği olduğunu değil, teklif hazırlama sürecinde kaç adımı ortadan kaldırdığını göstermelidir.

Örneğin teklif hazırlamak mevcut düzende Word, Excel, WhatsApp ve hesap makinesi arasında geçiş yapmayı gerektiriyorsa demo sırasında aynı işlem tek bir akışta tamamlanmalıdır.

Demo Öncesinde Hazırlanması Gereken Bilgiler

Gerçekçi sonuç almak için demo sırasında rastgele bilgiler kullanılmamalıdır. Firmanın sık karşılaştığı bir müşteri tipi üzerinden örnek oluşturulmalıdır.

Örnek demo vakası şu şekilde hazırlanabilir:

• Müşteri: Güneş Apartmanı Yönetimi
• Bina: 10 katlı konut binası
• Asansör sayısı: 2
• Asansör tipi: Elektrikli, makine daireli
• Teklif türü: Aylık periyodik bakım hizmeti
• Ek hizmet: Yıllık kurtarma eğitimi ve acil servis
• Ödeme şekli: Üç aylık peşin ödeme
• Teklif geçerlilik süresi: 15 gün
• Sözleşme süresi: 1 yıl
• Örnek aylık bakım bedeli: Asansör başına 2.500 TL + KDV

Bu tutarlar yalnızca demo senaryosunu canlandırmak için kullanılabilir. Gerçek fiyatlandırma; şehir, portföy yoğunluğu, asansör tipi, durak sayısı, bina konumu, parça kapsamı, servis yükümlülüğü ve firmanın maliyet yapısına göre değişir.

Demo öncesinde ayrıca firma logosu, iletişim bilgileri, banka bilgileri, teklif şartları ve standart açıklamalar hazırlanmalıdır. Böylece oluşturulan PDF’nin gerçek müşteriye gönderilebilecek kalitede olup olmadığı anlaşılır.

Adım Adım Asansör Teklif Programı Demo Akışı

Demo için ideal süre yaklaşık 20–30 dakikadır. Ancak bu süre boyunca yalnızca anlatım yapılmamalı, mümkün olduğunca işlemler canlı olarak gerçekleştirilmelidir.

1. Müşteri ve Bina Bilgilerini Oluşturma

İlk aşamada bina yöneticisinin veya müşteri temsilcisinin temel bilgileri kaydedilir. Firma daha önce bu müşteriyle çalışmışsa mevcut kaydın tekrar kullanılabilmesi önemlidir.

Kontrol edilmesi gereken bilgiler şunlardır:

• Müşteri veya yönetim adı
• Yetkili kişinin adı ve soyadı
• Telefon ve e-posta bilgisi
• Vergi bilgileri
• Fatura adresi
• Hizmet verilecek bina
• Binadaki asansör sayısı
• Asansörlerin temel teknik özellikleri

Aynı bina için her teklif hazırlanışında bu bilgilerin yeniden yazılması gerekiyorsa süreç gereksiz şekilde uzar. İyi bir teklif programı, daha önce kaydedilen müşteri ve bina bilgilerini teklif formuna otomatik olarak getirebilmelidir.

2. Teklif Türünün Belirlenmesi

Asansör firmalarında her teklif aynı kapsamda değildir. Bu nedenle demo sırasında farklı teklif türlerinin nasıl yönetildiği görülmelidir.

Yaygın teklif türleri şunlardır:

• Aylık bakım teklifi
• Revizyon teklifi
• Arıza sonrası parça değişim teklifi
• Yeni asansör montaj teklifi
• Modernizasyon teklifi
• Yıllık bakım sözleşmesi yenileme teklifi
• Durum tespitine bağlı düzeltme teklifi

Demo senaryosunda aylık bakım teklifi seçildikten sonra ilgili hazır şablonun açılması beklenir. Böylece satış personeli her seferinde teklif açıklamalarını sıfırdan yazmak zorunda kalmaz.

3. Hizmet ve Fiyat Kalemlerinin Eklenmesi

Teklif kalemleri açık, ölçülebilir ve müşterinin anlayabileceği şekilde yazılmalıdır. Sadece “asansör bakımı” ifadesi kullanmak kapsam anlaşmazlığına yol açabilir.

Örnek teklif tablosu şu şekilde oluşturulabilir:

Teklif kalemi	Miktar	Birim fiyat	Toplam
Aylık periyodik bakım hizmeti	2 asansör	2.500 TL	5.000 TL
7/24 arıza çağrı hizmeti	1 paket	Dahil	0 TL
Yıllık kurtarma eğitimi	1 adet	Dahil	0 TL
Aylık ara toplam			5.000 TL
KDV		Güncel oran	Otomatik hesaplama
Genel toplam			Sistem tarafından hesaplanır

Programın miktar, birim fiyat, iskonto, KDV ve toplam alanlarını otomatik hesaplaması önemlidir. Özellikle çok sayıda parça bulunan revizyon tekliflerinde manuel hesaplama yapılması ciddi hata riski oluşturur.

Demo sırasında şu küçük test de yapılabilir: Birim fiyat değiştirildiğinde ara toplam, vergi ve genel toplamın otomatik güncellenip güncellenmediği kontrol edilir.

4. Kapsam, Hariç Tutulan İşler ve Ödeme Koşulları

Teklifin yalnızca fiyat bölümünden oluşması yeterli değildir. Hizmet kapsamı net değilse müşteri, teklif tutarına parça değişimlerinin veya büyük revizyonların da dahil olduğunu düşünebilir.

Bakım teklifinde aşağıdaki açıklamalar bulunabilir:

• Periyodik bakım sıklığı
• Arıza çağrı hizmetinin kapsamı
• Sarf malzemelerinin dahil olup olmadığı
• Büyük parça değişimlerinin nasıl fiyatlandırılacağı
• Mesai dışı müdahalelerin durumu
• Ödeme dönemi
• Teklif geçerlilik süresi
• Sözleşmenin başlangıç ve bitiş tarihleri
• Fiyat güncelleme şartları

Demo sırasında hazır açıklama şablonlarının olup olmadığı kontrol edilmelidir. Ancak bu şablonların müşteri veya teklif türüne göre düzenlenebilmesi de gerekir.

5. Teklifin PDF Olarak Oluşturulması

Teklif tamamlandıktan sonra müşteri gözüyle PDF incelenmelidir. Bina yöneticisinin teknik olmayan bir kullanıcı olabileceği unutulmamalıdır. Teklif sade, okunabilir ve güven veren bir düzende hazırlanmalıdır.

PDF kontrolünde şu noktalar değerlendirilmelidir:

1. Firma logosu ve iletişim bilgileri doğru mu?
2. Teklif numarası ve tarihi görünüyor mu?
3. Müşteri ve bina bilgileri doğru yerde mi?
4. Hizmet kalemleri kolay okunuyor mu?
5. KDV ve genel toplam açıkça belirtilmiş mi?
6. Ödeme koşulları ve geçerlilik tarihi bulunuyor mu?
7. Sayfa taşmaları veya kesilmiş metinler var mı?
8. Teklifi hazırlayan yetkilinin bilgisi yer alıyor mu?

Asansorex gibi teklif ve sözleşme süreçlerini bakım operasyonuyla birlikte yöneten sistemlerde, kayıtlı müşteri ve bina bilgilerinden yararlanılarak teklif oluşturulması tekrar veri girişini azaltabilir. Buradaki temel fayda, satış süreci ile operasyon kayıtlarının birbirinden kopmamasıdır.

6. Teklif Revizyonunun Oluşturulması

Demo senaryosunun en önemli bölümlerinden biri revizyondur. Çünkü müşteriler çoğu zaman ilk teklifi doğrudan kabul etmez.

Örnek senaryoda bina yöneticisi şu talebi iletsin:

“Üç aylık peşin ödeme yaparsak indirim uygulanabilir mi?”

Bu talep üzerine mevcut teklif silinmemeli veya üzerine kontrolsüz şekilde yazılmamalıdır. Yeni bir revizyon oluşturulmalıdır.

Örneğin:

• İlk teklif: Revizyon 0
• İndirimli teklif: Revizyon 1
• Son görüşme sonrası teklif: Revizyon 2

Her revizyonda tarih, fiyat, açıklama ve teklif durumu ayrı şekilde izlenebilmelidir. Böylece firma sahibi müşteriye en son hangi fiyatın gönderildiğini kolayca görebilir.

Kontrol noktası	Beklenen sonuç
Eski teklif korunuyor mu?	Önceki sürüm görüntülenebilmeli
Revizyon numarası değişiyor mu?	Her sürüm ayrı numara veya tarih taşımalı
Fiyat farkı görülebiliyor mu?	Eski ve yeni tutar karşılaştırılabilmeli
Son gönderilen sürüm belli mi?	Güncel teklif karışıklık olmadan bulunmalı
Revizyon nedeni yazılabiliyor mu?	İndirim veya kapsam değişikliği not edilebilmeli

7. Kabul, Red veya Beklemede Durumunun İşlenmesi

Teklif gönderildikten sonra satış sürecinin takip edilebilmesi gerekir. Tekliflerin yalnızca hazırlanması değil, sonuçlarının da kaydedilmesi önemlidir.

Temel durumlar şu şekilde olabilir:

• Taslak
• Gönderildi
• Görüşme bekleniyor
• Revizyon istendi
• Kabul edildi
• Reddedildi
• Süresi doldu
• Sözleşmeye dönüştürüldü

Demo sırasında teklif “kabul edildi” durumuna getirildiğinde ne olduğu görülmelidir. Kabul edilen tekliften sözleşme hazırlanabiliyor mu, fiyat ve kapsam bilgileri otomatik aktarılıyor mu, başlangıç ve bitiş tarihleri belirlenebiliyor mu kontrol edilmelidir.

Bu bağlantı kurulmadığında satış personeli teklifi hazırlar, operasyon ekibi ise aynı bilgileri farklı bir dosyaya yeniden yazmak zorunda kalır.

Demo Sırasında Sorulması Gereken Kritik Sorular

Yazılımı tanıtan kişinin anlattıkları kadar, firma sahibinin sorduğu sorular da demonun kalitesini belirler.

Aşağıdaki sorular doğrudan sorulabilir:

• Teklif kalemlerini hazır şablon olarak kaydedebilir miyiz?
• Eski müşteriye yeni teklif hazırlarken bilgileri tekrar girmek gerekir mi?
• Aynı teklifin tüm revizyonlarını görebilir miyiz?
• Personel kendi başına sınırsız iskonto uygulayabilir mi?
• Teklif PDF’sinde kendi logomuz ve bilgilerimiz yer alır mı?
• Farklı bakım paketleri oluşturabilir miyiz?
• Teklifin geçerlilik süresi dolduğunda takip edebilir miyiz?
• Kabul edilen teklif sözleşmeye aktarılabilir mi?
• Reddedilen teklifin nedeni kaydedilebilir mi?
• Aylık kaç teklif hazırladığımızı ve kaçının satışa dönüştüğünü görebilir miyiz?
• Teklifler telefondan veya tabletten görüntülenebilir mi?
• Veriler dışarı aktarılabilir veya yedeklenebilir mi?

Bu sorular, gösterişli ancak günlük kullanımda eksik kalan sistemlerle gerçekten operasyonu destekleyen teklif programlarını ayırmaya yardımcı olur.

Başarılı Bir Demo Nasıl Ölçülür?

Demo sonunda yalnızca “program güzel görünüyor” değerlendirmesi yapılmamalıdır. Ölçülebilir bir kontrol listesi kullanılmalıdır.

Başarılı bir demo sonucunda:

• Teklif en fazla birkaç dakika içinde hazırlanabilmelidir.
• Müşteri ve bina bilgileri tekrar tekrar yazılmamalıdır.
• Fiyat hesaplamaları otomatik yapılmalıdır.
• Teklif kapsamı açıkça belirtilebilmelidir.
• Kurumsal PDF oluşturulabilmelidir.
• Revizyon geçmişi korunmalıdır.
• Teklif durumu takip edilebilmelidir.
• Kabul edilen teklif sözleşme sürecine aktarılabilmelidir.
• Yetkisiz fiyat veya iskonto değişiklikleri sınırlandırılabilmelidir.
• Firma sahibi tekliflerin satışa dönüşme durumunu görebilmelidir.

Demo sırasında işlemleri yalnızca yazılımı tanıtan kişi yapıyorsa gerçek kullanım kolaylığı tam olarak anlaşılamaz. Mümkünse teklifin bir bölümünü firma sahibi veya satış personeli kendisi hazırlamalıdır.

Demo Yaparken Kaçınılması Gereken Hatalar

En sık yapılan hata, yüzlerce özelliğin kısa sürede gösterilmeye çalışılmasıdır. Bu yaklaşım kullanıcının ihtiyacını netleştirmek yerine kafasını karıştırır.

Kaçınılması gereken diğer hatalar şunlardır:

• Gerçek dışı müşteri bilgileriyle demo yapmak
• Teklif PDF’sini incelemeden geçmek
• Revizyon sürecini test etmemek
• KDV ve iskonto hesaplarını kontrol etmemek
• Sözleşmeye geçiş adımını göstermemek
• Mobil kullanım ihtiyacını değerlendirmemek
• Satış sonrası destek ve veri aktarımını sormamak
• Sadece fiyat üzerinden karar vermek

Özellikle mevcut müşteri, teklif kalemi ve fiyat listelerinin yeni sisteme nasıl aktarılacağı öğrenilmelidir. Program kolay olsa bile başlangıç verileri yüklenemiyorsa firma uzun süre çift sistem kullanmak zorunda kalabilir.

Sıkça Sorulan Sorular

Asansör teklif programı demosu ne kadar sürmelidir?

Temel bir demo yaklaşık 20–30 dakika sürebilir. Ancak bakım teklifi, revizyon, PDF oluşturma, onay ve sözleşmeye geçiş gibi tüm adımlar test edilecekse daha uzun bir uygulama oturumu gerekebilir.

Demo sırasında hazır bir teklif örneği kullanılmalı mı?

Evet. Firmanın gerçek iş yapısına benzeyen bir bina ve hizmet senaryosu kullanılmalıdır. Böylece yazılımın günlük iş akışına uygunluğu daha doğru değerlendirilir.

Teklif programında revizyon takibi neden önemlidir?

Müşteriler fiyat, ödeme şekli veya hizmet kapsamı için değişiklik talep edebilir. Revizyon geçmişi tutulmazsa hangi fiyatın en son gönderildiği karışabilir ve firma ile müşteri arasında anlaşmazlık yaşanabilir.

Teklifin PDF olarak hazırlanması yeterli midir?

Hayır. PDF oluşturmak temel bir özelliktir. Asıl önemli olan müşteri bilgilerinin otomatik gelmesi, hesaplamaların doğru yapılması, revizyonların saklanması ve teklif sonucunun takip edilmesidir.

Demo hesabına kendi müşteri verilerimizi girmeli miyiz?

Mümkünse gerçek verilerin anonimleştirilmiş bir örneği kullanılabilir. Böylece firma kendi teklif yapısının sisteme uygun olup olmadığını daha net görür. Kişisel ve ticari verilerin paylaşımında gizlilik kurallarına dikkat edilmelidir.

Asansorex teklif sürecinde nasıl yardımcı olur?

Asansorex, müşteri ve bina kayıtlarıyla bağlantılı teklifler hazırlanmasına, teklif sürümlerinin takip edilmesine ve kabul edilen işlemlerin sözleşme sürecine aktarılmasına yardımcı olabilir. Böylece satış ve bakım kayıtlarının farklı dosyalarda dağılması azaltılabilir.

Özet

Bir asansör teklif programı demo senaryosu, yalnızca yazılım ekranlarını tanımak için değil, firmanın gerçek satış sürecini test etmek için hazırlanmalıdır. Demo; müşteri kaydıyla başlamalı, hizmet kalemlerinin eklenmesi, fiyat hesaplama, PDF oluşturma, revizyon, müşteri onayı ve sözleşmeye geçiş adımlarıyla tamamlanmalıdır.

Firma sahibi açısından doğru program; teklif hazırlama süresini azaltmalı, fiyat hatalarını önlemeli ve bekleyen tekliflerin takibini kolaylaştırmalıdır. Satış personeli açısından tekrar veri girişini azaltmalı, bina yöneticisi açısından ise anlaşılır ve profesyonel teklifler sunmalıdır. Karar vermeden önce gerçek bir bakım veya revizyon senaryosunu baştan sona uygulamak, yazılımın günlük operasyona gerçekten uyup uymadığını görmenin en sağlıklı yoludur.