Asansör Teklif Programı için Teknik Şartname

İÇERİK

Asansör bakım ve servis firmalarında teklif süreci yalnızca bir fiyat belgesi hazırlamaktan ibaret değildir. Bakım sözleşmeleri, revizyon işleri, parça değişimleri, modernizasyon projeleri ve yeni müşteri kazanımı düşünüldüğünde teklif; satış, teknik ekip, finans ve müşteri arasında dolaşan kritik bir iş kaydına dönüşür. Bu nedenle asansör teklif programı seçerken yalnızca “teklif oluşturabiliyor mu?” sorusu yeterli değildir. Teknik şartname; hangi verilerin tutulacağını, tekliflerin nasıl revize edileceğini, kimlerin hangi işlemleri yapabileceğini, onaylanan teklifin sonraki süreçlere nasıl aktarılacağını ve firmanın kendi verilerine nasıl ulaşacağını açık biçimde tanımlamalıdır.

İyi hazırlanmış bir teknik şartname, farklı yazılım sağlayıcılarını aynı kriterlerle karşılaştırmayı kolaylaştırır. Aynı zamanda demo sırasında gözden kaçabilecek eksikleri henüz satın alma kararı verilmeden ortaya çıkarır. Bu rehberde bir asansör firmasının teklif yazılımı için şartname hazırlarken kullanabileceği temel kriterleri, pratik kontrol noktalarıyla ele alacağız.

Teknik Şartname Neden Özellik Listesinden Daha Fazlasıdır?

Yazılım satın alırken yapılan yaygın hatalardan biri, şartnameyi onlarca özellikten oluşan uzun bir liste haline getirmektir. Örneğin:

• Teklif oluşturma
• PDF çıktısı
• Müşteri kaydı
• Ürün ekleme
• Raporlama
• Kullanıcı yönetimi

Bu maddelerin tamamı gerekli olabilir. Ancak özelliğin bulunması, iş sürecinin doğru çalıştığı anlamına gelmez.

Örneğin sistem “teklif revizyonu” desteklediğini söylüyor olabilir. Fakat eski teklifin üzerine yazıyor ve önceki fiyatları saklamıyorsa, gerçek anlamda bir revizyon geçmişinden söz edilemez.

Benzer şekilde PDF oluşturmak tek başına yeterli değildir. Firmanın logosu, adresi, ödeme koşulları, teklif geçerlilik tarihi, açıklamalar ve teknik şartlar PDF üzerinde düzgün görünmüyorsa personel tekrar Word veya Excel kullanmaya başlayabilir.

Bu nedenle şartnamedeki maddeler mümkün olduğunca doğrulanabilir yazılmalıdır.

Zayıf ifade:

Sistem teklif hazırlamayı desteklemelidir.

Daha iyi ifade:

Kullanıcı, müşteriye bağlı bakım, revizyon veya parça teklifleri oluşturabilmeli; teklif kalemlerine miktar, birim, birim fiyat, iskonto, vergi ve açıklama ekleyebilmelidir.

Bu yaklaşım, satın alma sırasında “özellik var mı?” yerine “özellik bizim işimizi gerçekten karşılıyor mu?” sorusunun cevaplanmasını sağlar.

Asansör Teklif Programında Olması Gereken Temel Özellikler

Teklif modülünün ilk görevi teklif hazırlama süresini azaltmaktır. Bunun için kullanıcının her teklif için aynı bilgileri sıfırdan yazması beklenmemelidir.

Müşteri ve bina bilgilerinin otomatik gelmesi

Teklif oluştururken mevcut müşteri kartındaki bilgiler kullanılabilmelidir. Firma yapısına göre aşağıdaki bilgiler teklif içerisine aktarılabilir:

• Müşteri veya firma unvanı
• Yetkili kişi
• Telefon ve e-posta
• Bina veya tesis adı
• Adres
• Vergi bilgileri
• Teklif konusu
• İlgili asansör
• Mevcut bakım sözleşmesi bilgileri

Özellikle yüzlerce bina ile çalışan servis firmalarında aynı müşteri bilgilerini her seferinde elle girmek ciddi zaman kaybına ve yazım hatalarına yol açar.

Teklif türlerinin ayrılabilmesi

Her teklif aynı yapıda değildir. Asansör firmalarında en azından aşağıdaki işler birbirinden ayrılabilir:

1. Periyodik bakım teklifi
2. Revizyon teklifi
3. Parça değişim teklifi
4. Modernizasyon teklifi
5. Arıza sonrası ücretli işlem teklifi
6. Sözleşme yenileme teklifi

Programın teklif türünü veya kategorisini kaydedebilmesi, ilerleyen dönemde hangi işlerden daha fazla teklif ve satış üretildiğinin analiz edilmesini kolaylaştırır.

Teklif kalemleri ve hazır ürün/hizmet kataloğu

Sık kullanılan malzeme ve hizmetlerin tekrar tekrar yazılması yerine bir katalogdan seçilebilmesi önemli bir verimlilik sağlar.

Örneğin:

• Aylık bakım hizmeti
• Fotosel
• Kapı kilidi
• Halat
• Kontaktör
• Kumanda kartı
• Kabin butonu
• Acil kurtarma ünitesi
• Montaj işçiliği

Firma kendi kullandığı ürün ve hizmetleri sisteme tanımlayabilmeli, ancak teklif sırasında gerektiğinde açıklama ve fiyat üzerinde yetki dahilinde değişiklik yapabilmelidir.

Teklif Revizyonu ve Fiyat Geçmişi Nasıl Yönetilmeli?

Asansör sektöründe özellikle revizyon ve modernizasyon tekliflerinin ilk gönderildiği haliyle kabul edilmesi her zaman mümkün olmaz.

Müşteri:

“Şu parçayı çıkaralım.”

“Bunu iki taksite bölebilir miyiz?”

“Bu fiyatı biraz daha iyileştirebilir misiniz?”

“İkinci asansörü de eklersek fiyat ne olur?”

gibi taleplerle geri dönebilir.

Bu noktada teklif programının eski teklifin üzerine yazmak yerine revizyon mantığıyla çalışması önemlidir.

Örneğin:

TKL-2026-0184 Revizyon 1

TKL-2026-0184 Revizyon 2

gibi bir geçmiş oluşturulabilir.

Böylece firma daha sonra müşteriye hangi fiyatların sunulduğunu görebilir.

Teknik şartnamede aşağıdaki kriterler açıkça aranabilir:

Kriter	Neden Gerekli?	Kontrol Yöntemi
Teklif numarası	Tekliflerin karışmasını önler	Yeni teklifte otomatik numara oluşuyor mu?
Revizyon geçmişi	Eski fiyatları korur	Eski revizyon tekrar görüntülenebiliyor mu?
Teklif durumu	Satış sürecini takip eder	Bekliyor, kabul, ret gibi durumlar var mı?
Geçerlilik tarihi	Süresi geçen fiyatları ayırır	Tarih girilip takip edilebiliyor mu?
PDF çıktısı	Profesyonel sunum sağlar	Gerçek teklif üzerinden kontrol edilmeli
İskonto yetkisi	Kontrolsüz indirimi önler	Kullanıcı bazında sınırlandırılabiliyor mu?
Açıklama alanları	Teknik kapsamı netleştirir	Kalem ve genel açıklama eklenebiliyor mu?
Dosya geçmişi	Anlaşmazlığı azaltır	Gönderilen eski teklif korunuyor mu?

Özellikle hammadde, yedek parça ve döviz hareketlerinin fiyatları etkileyebildiği dönemlerde teklif geçerlilik tarihinin açık şekilde takip edilmesi ticari açıdan önemlidir.

Yetkilendirme ve Fiyat Kontrolü Şartnamede Yer Almalı

Teklif yazılımının sadece hızlı olması yeterli değildir. Fiyat kontrolünü de desteklemesi gerekir.

Satış personelinin veya saha çalışanının tüm ürünlerin alış maliyetini, kâr oranını veya şirketin özel fiyat politikasını görmesi her firma için uygun olmayabilir.

Bu nedenle teknik şartnamede kullanıcı yetkilerinin incelenmesi gerekir.

Örneğin firma şu yapıyı tercih edebilir:

• Teknisyen yalnızca teklif talebi oluşturabilir.
• Satış personeli teklif hazırlayabilir.
• Satış sorumlusu belirlenen limite kadar iskonto uygulayabilir.
• Firma sahibi veya yetkili kişi yüksek iskontolu teklifleri onaylayabilir.
• Her kullanıcı yalnızca görev alanıyla ilgili teklifleri görüntüleyebilir.

Şartnameye sadece “kullanıcı yetkilendirme bulunmalıdır” yazmak yerine, hangi işlemlerin sınırlandırılacağı belirtilmelidir.

Özellikle iskonto konusunda “yüzde kaç indirim yapılabileceği” gibi sınırlar her firmanın kendi ticari politikasına göre belirlenebilir.

Tekliften Sözleşmeye ve İş Emrine Geçiş

Teklif kabul edildiğinde aynı bilgileri başka bir sisteme yeniden yazmak dijitalleşmenin faydasını azaltır.

İdeal süreç şu şekilde ilerlemelidir:

Müşteri → Teklif → Revizyon → Onay → Sözleşme / İş → Tahsilat

Örneğin bina yöneticisine yıllık bakım teklifi gönderildiğini düşünelim. Teklif kabul edildiğinde bakım hizmetinin kapsamı, fiyatı ve müşteri bilgileri mümkün olduğunca tekrar veri girişi gerektirmeden sonraki sürece aktarılmalıdır.

Revizyon tekliflerinde ise kabul edilen iş kalemleri operasyon ekibi açısından önemlidir. Teklifte “kapı kilidi değişimi” ve “fotosel değişimi” bulunuyorsa saha ekibine aktarılacak iş kaydında bu kapsamın görülebilmesi bilgi kaybını azaltır.

Asansorex gibi asansör sektörüne odaklanan bakım ve yönetim yazılımlarında teklif, müşteri ve operasyon kayıtlarının aynı yapı içerisinde tutulması; satış sırasında oluşturulan bilginin sonraki iş süreçlerinde tekrar kullanılmasını kolaylaştırabilir.

Dijital Onay, PDF ve Müşteri İletişimi

Teklif hazırlamak sürecin sadece yarısıdır. Teklifin müşteriye ulaştırılması ve sonucun takip edilmesi de gerekir.

Teknik şartnamede en azından şu noktalar değerlendirilmelidir:

• Teklif PDF olarak oluşturulabiliyor mu?
• Firma logosu ve iletişim bilgileri kullanılabiliyor mu?
• Ödeme koşulları yazılabiliyor mu?
• Teklif geçerlilik tarihi gösteriliyor mu?
• Teknik açıklamalar eklenebiliyor mu?
• Müşteri teklifin hangi revizyonunu aldığını anlayabiliyor mu?
• Kabul veya ret durumu sisteme işlenebiliyor mu?
• Teklifin kabul tarihi kaydedilebiliyor mu?

Dijital onay özelliği varsa bunun nasıl çalıştığı ayrıca incelenmelidir. “Dijital onay” ile hukuki anlamda belirli bir elektronik imza türünün aynı şey olduğu varsayılmamalıdır. Satın alma öncesinde kullanılan yöntemin niteliği ve firmanın ihtiyacına uygunluğu ayrıca değerlendirilmelidir.

Amaç yalnızca PDF göndermek değil, hangi teklifin hangi şartlarla kabul edildiğini geriye dönük gösterebilecek bir kayıt zinciri oluşturmaktır.

Veri Güvenliği, Yedekleme ve Veri Sahipliği

Teklif sistemi firmanın ticari hafızasını taşır. Müşteri listeleri, fiyat politikaları, verilen indirimler ve geçmiş teklifler önemli ticari verilerdir.

Bu nedenle teknik şartnamede yalnızca satış özelliklerine odaklanılmamalıdır.

Satın alma öncesinde şu sorular mutlaka sorulmalıdır:

• Veriler düzenli şekilde yedekleniyor mu?
• Kullanıcılar yetkilerine göre sınırlandırılabiliyor mu?
• Sistemden ayrılmak istenirse veriler dışarı alınabiliyor mu?
• Müşteri ve teklif kayıtları hangi formatlarda dışarı aktarılabiliyor?
• Silinen veya değiştirilen kritik kayıtlarla ilgili izleme imkânı bulunuyor mu?
• Kullanıcı hesapları ayrı ayrı oluşturulabiliyor mu?
• İşten ayrılan personelin erişimi kolayca kapatılabiliyor mu?
• Web tabanlı sistemlerde bağlantı güvenliği sağlanıyor mu?

Özellikle veri dışa aktarımı, yazılım satın alırken ihmal edilen ancak ileride kritik hale gelebilen maddelerden biridir.

Firmanın kendi müşteri ve teklif verilerini gerektiğinde kullanılabilir bir formatta alabilmesi satın alma kriterleri arasında bulunmalıdır.

Teknik Destek ve Geçiş Süreci de Şartnamenin Parçasıdır

İyi bir yazılımın başarısız uygulanmasının en yaygın nedenlerinden biri geçiş sürecinin hesaba katılmamasıdır.

Firma yıllardır Excel kullanıyor olabilir. Eski müşteriler, fiyat listeleri veya açık teklifler farklı dosyalarda bulunabilir.

Bu nedenle sağlayıcıya şu sorular yöneltilmelidir:

1. Mevcut müşteri kayıtları sisteme aktarılabilecek mi?
2. Ürün ve hizmet listeleri toplu yüklenebilecek mi?
3. İlk kullanıcı eğitimi verilecek mi?
4. Teknik destek hangi kanallardan sağlanıyor?
5. Destek saatleri nedir?
6. Kritik sorunlarda geri dönüş süreci nasıl işliyor?
7. Güncellemeler lisans ücretine dahil mi?
8. İlave kullanıcı, eğitim veya entegrasyon için ayrıca ücret var mı?

Teknik şartname hazırlanırken sadece yazılım ekranları değil, yazılımın toplam kullanım süreci değerlendirilmelidir.

Aksi halde teklif aşamasında düşük görünen maliyet; veri aktarımı, eğitim, ek kullanıcı veya destek ücretleriyle büyüyebilir.

Örnek Asansör Teklif Programı Teknik Şartname Kontrol Listesi

Satın alma komitesi veya firma sahibi aşağıdaki maddeleri başlangıç şartnamesi olarak kullanabilir:

• Müşteri kartından teklif oluşturulabilmelidir.
• Bina ve ilgili asansör bilgileri teklifle ilişkilendirilebilmelidir.
• Bakım, revizyon, parça ve modernizasyon gibi farklı teklif türleri tanımlanabilmelidir.
• Teklif kalemlerine miktar, birim, birim fiyat ve açıklama girilebilmelidir.
• İskonto ve vergi hesaplamaları desteklenmelidir.
• Tekliflere benzersiz numara verilebilmelidir.
• Teklif revizyon geçmişi korunmalıdır.
• Eski revizyonlar sonradan görüntülenebilmelidir.
• Teklif geçerlilik tarihi tanımlanabilmelidir.
• Teklifler PDF olarak oluşturulabilmelidir.
• Kurumsal logo ve firma bilgileri teklif çıktısında yer alabilmelidir.
• Kullanıcı yetkileri ayrıştırılabilmelidir.
• İskonto veya fiyat değiştirme yetkisi sınırlandırılabilmelidir.
• Teklifin bekliyor, kabul edildi veya reddedildi gibi durumu izlenebilmelidir.
• Kabul edilen teklif sonraki operasyon veya sözleşme sürecine aktarılabilmelidir.
• Teklif kayıtları filtrelenebilmeli ve aranabilmelidir.
• Veriler dışarı aktarılabilmelidir.
• Düzenli yedekleme yöntemi bulunmalıdır.
• Kullanıcı erişimleri gerektiğinde kapatılabilmelidir.
• Teknik destek ve eğitim kapsamı teklif öncesinde açıklanmalıdır.

Bu liste doğrudan kopyalanabilir; ancak her firmanın iş modeline göre ek maddeler eklenmesi gerekir.

Örneğin sadece bakım yapan küçük bir işletmenin ihtiyaçlarıyla büyük modernizasyon projeleri yöneten çok şubeli bir firmanın şartnamesi aynı olmayacaktır.

Yazılım Demosunda Şartname Nasıl Test Edilir?

Teknik şartname hazırlanıp sağlayıcıya göndermek yeterli değildir. Maddelerin demo sırasında gerçek bir senaryo üzerinden doğrulanması gerekir.

En iyi yöntem örnek bir müşteri oluşturmaktır.

Örneğin:

“ABC Apartmanı için 12 aylık bakım teklifi hazırlayalım. Ardından teklifin fiyatını değiştirip ikinci revizyonu oluşturalım. Eski revizyonu görüntüleyelim. Son olarak teklifi kabul edilmiş duruma getirip sonraki işlemin nasıl ilerlediğini görelim.”

Bu test yalnızca birkaç dakika içinde pek çok noktayı ortaya çıkarabilir.

Özellikle şu işlemleri satış temsilcisinin anlatması yerine ekranda göstermesini isteyin:

• Teklif oluşturma
• Ürün veya hizmet ekleme
• İskonto yapma
• Revizyon oluşturma
• Eski revizyona ulaşma
• PDF oluşturma
• Kabul durumuna alma
• Müşteri geçmişinden teklifi bulma
• Yetkisiz kullanıcının fiyat değiştirememesi
• Veriyi dışarı aktarma

İyi bir teknik şartnamenin amacı en fazla özelliği istemek değil, firmanın gerçek operasyonunda ihtiyaç duyduğu süreçlerin eksiksiz çalıştığını doğrulamaktır.

Sıkça Sorulan Sorular

Asansör teklif programı için teknik şartname zorunlu mu?

Özel bir yazılım satın alımında her durumda resmi bir teknik şartname hazırlama zorunluluğu olduğu söylenemez. Ancak özellikle birden fazla yazılım sağlayıcısını karşılaştırırken yazılı kriter listesi hazırlamak son derece faydalıdır. Böylece karar yalnızca demo sunumuna veya fiyata göre verilmez.

Teklif programında revizyon geçmişi neden önemlidir?

Çünkü müşteriler teklif üzerinde fiyat, ürün veya kapsam değişikliği isteyebilir. Eski tekliflerin üzerine yazılması durumunda geçmişte hangi şartların sunulduğu kaybolur. Revizyon geçmişi her değişikliğin ayrı şekilde korunmasını sağlar.

Excel ile teklif hazırlamak yerine program kullanmak gerekli mi?

Az sayıda teklif hazırlayan firmalarda Excel başlangıçta yeterli görülebilir. Teklif sayısı arttığında versiyon karışıklığı, fiyat güncelleme hataları, müşteri geçmişini bulamama ve teklif sonucunu takip edememe gibi sorunlar ortaya çıkar. Program kullanımı özellikle düzenli teklif üreten firmalarda avantaj sağlar.

Teklif programı bakım yazılımıyla entegre olmalı mı?

Zorunlu değildir ancak büyük kolaylık sağlar. Müşteri, bina, asansör, teklif, sözleşme ve bakım bilgilerinin ayrı sistemlerde tutulması aynı verinin tekrar girilmesine neden olabilir. Asansorex gibi bu süreçleri aynı sistem içinde ele alan çözümler, tekliften operasyon sürecine geçerken veri tekrarını azaltabilir.

En önemli satın alma kriteri hangisidir?

Tek bir kriter yoktur. Ancak teklif hazırlama kolaylığı, revizyon geçmişi, kullanıcı yetkileri, veri dışa aktarımı, destek kalitesi ve mevcut operasyonla uyum birlikte değerlendirilmelidir. Çok özellikli fakat ekibin kullanamadığı bir yazılım pratikte beklenen faydayı sağlamaz.

Teknik şartname demo öncesinde mi hazırlanmalı?

Evet. Mümkünse demo görüşmelerinden önce temel kriterler belirlenmelidir. Böylece her sağlayıcıya aynı senaryo uygulanabilir ve ürünler daha objektif şekilde karşılaştırılabilir.

Özet

Asansör teklif programı seçerken yalnızca fiyat veya ekrandaki özellik sayısına bakmak sağlıklı bir satın alma yöntemi değildir. Teknik şartname; teklif hazırlama, ürün ve hizmet yönetimi, revizyon geçmişi, kullanıcı yetkileri, PDF çıktısı, teklif onayı, veri güvenliği, yedekleme, dışa aktarım ve teknik destek gibi konuları ölçülebilir şekilde tanımlamalıdır.

En sağlıklı yöntem, firmanın gerçek bir teklif senaryosunu teknik şartnameye dönüştürmek ve yazılım demosunda her kritik maddeyi tek tek test etmektir. Böylece satın alınan çözüm yalnızca teklif hazırlayan bir araç değil; müşteri görüşmesinden kabul edilen işe kadar satış sürecinin izlenebilir hale gelmesini sağlayan bir çalışma sistemi olur.