Asansör Teklif Programı Seçiminde Entegrasyon İhtiyacı

İÇERİK

Bir Asansör Teklif Programı seçerken yalnızca teklif ekranının güzel görünmesine, PDF çıktısının kurumsal olmasına veya ürün kalemlerinin hızlı eklenebilmesine bakmak yeterli değildir. Asıl kritik soru şudur: Hazırlanan teklif, firmanın geri kalan operasyonuna nasıl bağlanacak? Teklif kabul edildiğinde müşteri kaydı, cari hesap, sözleşme, stok, iş emri, tahsilat ve gerekiyorsa faturalandırma süreçleri yeniden elle mi oluşturulacak, yoksa bilgiler aynı akış içinde ilerleyebilecek mi?

Özellikle yüzlerce bakım sözleşmesi bulunan veya modernizasyon, revizyon ve parça değişimi teklifleri yoğun olan asansör firmalarında entegrasyon eksikliği zamanla ciddi iş yüküne dönüşür. Bu nedenle program seçerken "hangi entegrasyonlar var?" sorusundan önce "bizim hangi süreçlerimizin birbirine bağlanması gerekiyor?" sorusunu sormak gerekir. Bu rehberde entegrasyon ihtiyacının nasıl belirleneceğini, hangi bağlantıların gerçekten önemli olduğunu ve gereksiz entegrasyon taleplerinden nasıl kaçınılabileceğini ele alacağız.

Entegrasyon Neden Teklif Programının Önemli Bir Parçasıdır?

Asansör sektöründe teklif çoğu zaman tek başına kalan bir belge değildir. Teklif, ticari sürecin başlangıç noktalarından biridir.

Örneğin bir bina yöneticisi mevcut asansör için kontaktör, fotosel veya kapı mekanizması değişimi talep ettiğinde süreç şöyle ilerleyebilir:

1. Firma keşif veya arıza kaydı oluşturur.
2. Teknik personel yapılması gereken işlemleri bildirir.
3. Ofis fiyatlandırmayı yapar.
4. Müşteriye teklif gönderilir.
5. Teklif onaylanır.
6. Parça hazırlanır veya sipariş edilir.
7. Teknik personele iş atanır.
8. İş tamamlanır.
9. Tahsilat veya faturalandırma süreci başlar.
10. İşlem müşteri ve asansör geçmişine kaydedilir.

Teklif sistemi yalnızca üçüncü ve dördüncü adımı yapabiliyorsa, işletme kalan adımlar için Excel, WhatsApp, muhasebe programı, telefon görüşmeleri ve farklı listeler arasında dolaşmak zorunda kalabilir.

Entegrasyonun amacı her şeyi tek programa doldurmak değil, aynı veriyi tekrar tekrar girmeyi azaltmaktır.

Örneğin teklif üzerinde zaten şu bilgiler bulunuyorsa:

• Firma veya bina adı
• İlgili kişi
• Asansör bilgisi
• Teklif kalemleri
• Ürün veya parça miktarları
• Fiyat
• KDV bilgisi
• Ödeme koşulları
• Teklif tarihi

teklif kabul edildiğinde bu bilgilerin başka süreçlerde yeniden yazılması gerekmemesi ciddi zaman kazandırır.

İlk Olarak Firmanın Mevcut İş Akışı Çıkarılmalı

Program demosuna geçmeden önce yapılabilecek en doğru çalışma, firmanın mevcut teklif sürecini bir sayfaya yazmaktır.

Örneğin şu sorular cevaplanmalıdır:

Teklif nereden doğuyor?

Teklif;

• Arıza kaydından mı?
• Periyodik bakım sırasında bulunan eksikten mi?
• Periyodik kontrol sonrası düzeltme işinden mi?
• Yeni müşteri talebinden mi?
• Modernizasyon keşfinden mi?
• Telefon veya WhatsApp talebinden mi?

oluşuyor?

Çünkü teklif kaynağını bilmeden entegrasyon ihtiyacını belirlemek zordur.

Örneğin tekliflerin büyük bölümü teknisyenlerin sahada gördüğü eksiklerden oluşuyorsa saha uygulaması ile teklif sistemi arasındaki bağlantı önem kazanır.

Ancak firmanın işi ağırlıklı olarak yeni asansör veya kapsamlı modernizasyon projeleriyse, ürün-hizmet kataloğu, revizyon takibi ve teklif versiyonlama daha önemli olabilir.

Teklif kabul edilince ne oluyor?

Asıl entegrasyon ihtiyacı bu noktada ortaya çıkar.

Bir teklif kabul edildiğinde çalışanların hangi işlemleri yaptığını gözlemleyin.

Örneğin:

Teklif onaylandı → muhasebeye bilgi verildi → depoya WhatsApp gönderildi → teknisyene telefon edildi → müşteri cari kartına borç işlendi.

Bu süreçte dört ayrı manuel işlem bulunuyor.

Doğru yazılım kurgusunda teklif onaylandığında bu süreçlerin bazıları otomatik veya yarı otomatik ilerleyebilir.

Hangi Entegrasyonlar Gerçekten Önemlidir?

Her firmanın bütün entegrasyonlara ihtiyacı yoktur. Ancak asansör bakım ve servis firmalarında bazı bağlantılar diğerlerinden daha sık değer üretir.

Entegrasyon	Ne Sağlar?	Öncelik
Müşteri / CRM	Teklif geçmişini müşteri kaydıyla ilişkilendirir	Yüksek
Cari hesap	Kabul edilen tekliflerin finansal takibini kolaylaştırır	Yüksek
Stok	Teklifte kullanılan parçaların stok durumunu görmeyi sağlar	Orta-Yüksek
Saha / İş emri	Onaylanan işi teknisyene aktarır	Yüksek
Sözleşme	Bakım veya hizmet teklifini sözleşme sürecine taşır	Orta-Yüksek
E-fatura	Tamamlanan işlerin faturalandırılmasını hızlandırır	İhtiyaca göre
Tahsilat	Teklif sonrası ödeme takibini merkezileştirir	Yüksek
SMS / E-posta	Teklif gönderimi ve hatırlatmayı kolaylaştırır	Orta
Muhasebe yazılımı	Finansal verilerin başka sisteme aktarılmasını sağlar	Firmaya göre

Buradaki öncelikler genel uygulamaya göredir. Örneğin küçük bir firmanın ayrı depo operasyonu yoksa stok entegrasyonu ilk aşamada kritik olmayabilir. Buna karşılık 15 teknisyen ve birkaç depo kullanan bir işletme için stok bağlantısı büyük önem taşıyabilir.

CRM ve Müşteri Geçmişi Bağlantısı Olmadan Teklifler Kopuk Kalabilir

Teklif programında en temel ihtiyaçlardan biri müşterinin geçmişini görebilmektir.

Örneğin bir apartman yöneticisine son iki yıl içerisinde:

• 3 farklı revizyon teklifi,
• 2 parça değişim teklifi,
• 1 bakım sözleşmesi teklifi

gönderilmiş olabilir.

Yeni teklif hazırlanırken geçmiş fiyatlar veya önceki reddedilen teklifler görünmüyorsa satış personeli müşterinin geçmişini tekrar araştırmak zorunda kalabilir.

Daha önemlisi, aynı bina için farklı personeller farklı fiyat politikaları uygulayabilir.

CRM bağlantısı sayesinde şu soruların cevabı daha kolay bulunabilir:

• Bu müşteriye daha önce ne teklif edildi?
• Teklif kabul edildi mi?
• Reddedildiyse gerekçe neydi?
• Son görüşmeyi kim yaptı?
• Müşteri hangi hizmetlerle ilgileniyor?
• Açık bir teklif hâlâ bekliyor mu?
• Aynı asansör için benzer bir işlem daha önce yapılmış mı?

Bu bağlantı özellikle satış takibi açısından önemlidir.

Çünkü asansör firmalarında kaybedilen tekliflerin önemli bir kısmı yalnızca fiyat nedeniyle değil, teklif sonrası takibin yapılmaması nedeniyle de oluşabilir.

Cari, Tahsilat ve Faturalandırma Bağlantısı

Teklif kabul edildiğinde operasyon bitmez; ticari süreç yeni başlamış olur.

Örneğin 48.000 TL değerinde bir modernizasyon teklifi kabul edildiğini düşünelim. Ödeme planı şöyle olabilir:

• %40 siparişte
• %40 montaj öncesi
• %20 iş tesliminde

Teklif programı yalnızca toplam fiyatı biliyor ancak cari veya tahsilat sistemiyle bağlantı kuramıyorsa firma ödeme vadelerini ayrıca takip etmek zorunda kalabilir.

Entegrasyon bulunan bir yapıda ise kabul edilen teklif üzerinden;

• müşteri borcu oluşturulması,
• ödeme planının takip edilmesi,
• yapılan tahsilatların görülmesi,
• kalan bakiyenin izlenmesi,
• gerektiğinde faturaya dönüştürme sürecinin başlatılması

daha düzenli ilerler.

Burada önemli bir nokta vardır: Her firmanın kullandığı muhasebe sistemi farklı olabilir. Bu nedenle program seçerken yalnızca "muhasebe entegrasyonu var mı?" diye sormak yerine şu soruyu sorun:

"Bizim kullandığımız sistemle veri alışverişi nasıl yapılacak?"

API bağlantısı, Excel aktarımı, manuel dışa aktarma veya doğrudan entegrasyon seçeneklerinin hangisinin desteklendiğini netleştirmek gerekir.

Stok Entegrasyonu Hangi Firmalar İçin Kritik?

Her teklif kalemi stoktan düşmek zorunda değildir. Teklif henüz kabul edilmemişken stok düşmek zaten doğru olmaz.

Ancak teklif hazırlanırken stok bilgisine erişebilmek satış ve operasyon ekipleri açısından faydalıdır.

Örneğin müşteri için şu parçalar teklif edildi:

• 2 adet kapı fotoseli
• 1 adet kontaktör
• 1 adet acil aydınlatma ünitesi

Satış personeli parçaların depoda olup olmadığını bilmiyorsa müşteriye gerçekçi olmayan teslim süresi verebilir.

Stok entegrasyonu sayesinde kullanıcı teklif oluştururken en azından:

• mevcut miktarı,
• kritik stok seviyesini,
• alış maliyetini,
• satış fiyatını,
• alternatif ürünü

görebilir.

Ancak burada aşırı otomasyondan kaçınmak gerekir.

Teklif oluşturuldu diye ürünün stoktan otomatik düşmesi çoğu işletmede doğru yöntem değildir. Daha mantıklı akış genellikle şöyledir:

Teklif → Onay → İş / Sipariş → Malzeme Çıkışı → Tamamlama

Böylece henüz satışa dönüşmemiş teklifler gerçek stok miktarını bozmaz.

Saha Ekibiyle Entegrasyon Asansör Firmalarında Özel Önem Taşır

Asansör sektörünü birçok masa başı satış sektöründen ayıran nokta, teklif ihtiyacının çoğu zaman sahada ortaya çıkmasıdır.

Teknisyen bakım sırasında;

• aşınmış bir makara,
• arızalı bir fotosel,
• gevşemiş veya değiştirilmesi gereken ekipman,
• revizyon gerektiren bir kapı sistemi,
• periyodik kontrol sonrası düzeltilmesi gereken bir eksiklik

tespit edebilir.

Eğer saha sistemi ile teklif süreci arasında bağlantı yoksa genellikle şu yöntemlerden biri kullanılır:

• teknisyen WhatsApp'tan fotoğraf yollar,
• ofis çalışanı not alır,
• fiyat araştırılır,
• teklif ayrı sistemde hazırlanır,
• müşteriye gönderilir.

Bu akış çok büyüdüğünde bazı talepler unutulabilir.

Daha sağlıklı yapıda saha personelinin kaydettiği bulgu veya iş ihtiyacı, ofiste teklif hazırlayacak personele aktarılabilir.

Böylece fotoğraf, bina bilgisi, asansör bilgisi ve teknisyen notu kaybolmadan teklif sürecine taşınır.

Asansorex gibi asansör bakım ve saha süreçlerini teklif, cari, arıza ve müşteri kayıtlarıyla aynı operasyon içinde takip etmeye odaklanan sistemlerde bu bağlantı, özellikle tekrar veri girişini azaltmak açısından değerlendirilebilir.

Entegrasyon İhtiyacı Belirlerken Yapılan Hatalar

Program satın alma aşamasında iki uç yaklaşım görülür.

Birinci yaklaşım:

"Bizim hiçbir entegrasyona ihtiyacımız yok."

İkinci yaklaşım ise:

"Kullandığımız bütün sistemlerle bağlantı olsun."

İkisi de yanlış olabilir.

En sık yapılan hatalar şunlardır:

• Gerçekte kullanılmayan entegrasyonlar için ekstra geliştirme istemek.
• Firma iş akışını çıkarmadan yazılım seçmek.
• Sadece bugünkü ihtiyaca göre karar vermek.
• Teklif sonrasındaki operasyonu düşünmemek.
• Muhasebe entegrasyonu ile cari takibi aynı şey sanmak.
• API var denildiğinde bütün sistemlerin otomatik bağlanacağını düşünmek.
• Stok entegrasyonunun hangi aşamada devreye girdiğini sormamak.
• Mobil saha kullanıcılarının sürece dahil olup olmadığını kontrol etmemek.
• Teklif revizyon geçmişinin korunup korunmadığını incelememek.

Özellikle "API desteği var" ifadesi tek başına yeterli değildir.

Hangi verilerin okunabildiği, hangi verilerin gönderilebildiği, bağlantının hazır mı yoksa özel geliştirme mi gerektirdiği sorulmalıdır.

Demo Sırasında Entegrasyon Nasıl Test Edilmeli?

Demo görüşmesinde yalnızca ekranları izlemek yerine gerçek bir senaryo çalıştırmak çok daha faydalıdır.

Örneğin şu senaryoyu deneyebilirsiniz:

Örnek test senaryosu

Bir apartman yöneticisi arayarak kapı fotoseli değişimi istiyor.

Program üzerinde:

1. Mevcut müşteriyi bulun.
2. İlgili binayı ve asansörü seçin.
3. Yeni teklif oluşturun.
4. Ürün veya hizmet kalemini ekleyin.
5. Fiyat ve ödeme koşulunu girin.
6. Teklifi PDF olarak oluşturun.
7. Teklifi müşteriye gönderilmiş olarak kaydedin.
8. Teklifi kabul edildi durumuna getirin.
9. Sonrasında hangi işlemlerin otomatik oluştuğunu inceleyin.
10. Cari, stok, iş emri, tahsilat ve müşteri geçmişinde ne değiştiğini kontrol edin.

Bu kısa test, onlarca özellik listesinden daha fazla bilgi verebilir.

Çünkü satın alacağınız sistemin ekranlarını değil, iş akışını test etmiş olursunuz.

Entegrasyon İçin Öncelik Matrisi Oluşturun

Program seçiminden önce ihtiyaçları üç gruba ayırmak faydalıdır.

Olmazsa olmaz

Firmanın günlük operasyonunu doğrudan etkileyen bağlantılar.

Örneğin:

• Müşteri kayıtları
• Asansör kayıtları
• Cari takip
• İş emri oluşturma
• Teklif geçmişi

Faydalı

Operasyonu hızlandıran ancak başlangıç için zorunlu olmayan özellikler.

Örneğin:

• Stok bağlantısı
• SMS gönderimi
• E-posta otomasyonu
• Gelişmiş satış raporları

Gelecekte gerekli olabilir

Firma büyüdükçe ihtiyaç duyulabilecek bağlantılar.

Örneğin:

• Harici ERP
• Özel muhasebe entegrasyonu
• API bağlantıları
• Şube bazlı operasyon
• E-tahsilat
• Gelişmiş finans entegrasyonları

Bu yöntem gereksiz özelliklerin karar sürecini karmaşıklaştırmasını engeller.

Aynı zamanda bugün küçük olan firmanın iki yıl sonra yaşayabileceği büyüme problemlerini de hesaba katmayı sağlar.

Sıkça Sorulan Sorular

Asansör teklif programının muhasebe programıyla entegre olması şart mı?

Her firma için şart değildir. Küçük işletmelerde teklif, cari ve tahsilat takibi aynı sistem içinde yeterli olabilir. Ancak ayrı muhasebe veya ERP kullanan firmaların veri aktarım yöntemini program satın almadan önce kontrol etmesi faydalıdır.

Teklif kabul edildiğinde stok otomatik düşmeli mi?

Genellikle doğrudan teklif kabulünde stok düşürmek yerine iş emri, sipariş veya malzeme çıkışı aşamasında stok hareketi oluşturmak daha kontrollü bir yöntemdir. Firmanın operasyonuna göre farklı kurgu yapılabilir.

API entegrasyonu ne anlama gelir?

API, iki farklı yazılımın belirli verileri elektronik olarak birbirine aktarabilmesini sağlayan teknik yapıdır. Ancak bir programda API bulunması, bütün yazılımlarla hazır entegrasyon olduğu anlamına gelmez. Hangi işlemlerin desteklendiği ayrıca kontrol edilmelidir.

Teklif programı saha teknisyenleriyle bağlantılı olmalı mı?

Teklif ihtiyacının önemli bölümü bakım ve arıza sırasında oluşuyorsa saha bağlantısı oldukça faydalıdır. Teknisyenin bulgularını, fotoğraflarını ve notlarını ofise aktarması teklif hazırlanma süresini kısaltabilir.

E-fatura entegrasyonu gerekli mi?

Firmanın kullandığı faturalandırma yapısına bağlıdır. Yoğun teklif ve satış hacmi bulunan firmalarda tekliften faturaya geçişi hızlandırabilir. Ancak düşük işlem hacmine sahip işletmeler için ilk aşamada zorunlu olmayabilir.

En önemli entegrasyon hangisidir?

Tek bir doğru cevap yoktur. Asansör bakım firmalarında genellikle müşteri, asansör, cari, saha ve iş emri bağlantıları en fazla operasyonel faydayı sağlar. Ancak öncelik firmanın iş modeline göre belirlenmelidir.

Özet

Bir Asansör Teklif Programı seçerken karar yalnızca teklif hazırlama ekranına veya PDF tasarımına göre verilmemelidir. Teklifin satıştan sonraki yolculuğu da incelenmelidir.

Müşteri kaydı, asansör geçmişi, saha ekibi, cari hesap, tahsilat, stok, sözleşme ve faturalandırma süreçleri birbirinden tamamen kopuksa çalışanlar aynı bilgileri farklı sistemlere tekrar tekrar girmek zorunda kalabilir.

Bu nedenle seçimden önce mevcut iş akışınızı çıkarın, hangi noktalarda manuel veri girişi yapıldığını belirleyin ve entegrasyon ihtiyaçlarını olmazsa olmaz, faydalı ve gelecekte gerekli şeklinde sınıflandırın.

Asansorex gibi teklif sürecini bakım, arıza, müşteri, saha ve finansal operasyonlarla birlikte ele alan bir sistem değerlendiriliyorsa, demo sırasında yalnızca özellik listesini incelemek yerine gerçek bir teklif senaryosunu baştan sona çalıştırmak daha sağlıklı sonuç verir. İyi bir entegrasyon yapısının temel amacı daha fazla özellik göstermek değil, firmanın aynı işi ikinci kez yapmasını önlemektir.