Asansör Cari Programı Demo Senaryoları

İÇERİK

Bir asansör cari programı satın almadan önce yapılan demo, yazılımın yalnızca menülerini görmek için değil, firmanızdaki gerçek para akışını test etmek için kullanılmalıdır. Çünkü asansör bakım firmalarında cari süreçler klasik bir ticari işletmeden daha karmaşık olabilir. Aylık bakım bedelleri, arıza müdahaleleri, parça satışları, revizyon işleri, kısmi tahsilatlar, gecikmiş ödemeler ve farklı bina yöneticileri aynı cari hesapta birleşebilir.

Bu nedenle iyi bir demo, “müşteri nasıl ekleniyor?” sorusundan çok daha fazlasını cevaplamalıdır. Örneğin 20 bin TL borcu bulunan bir apartman 8 bin TL ödeme yaptığında bakiye nasıl değişiyor? Aynı müşteriye hem bakım hem de parça satışı işlendiğinde hareketler ayrı görülebiliyor mu? Fatura kesilen ve henüz faturaya dönüşmeyen işlemler ayırt edilebiliyor mu?

Bu rehberde, bir asansör cari programı demosunda mutlaka uygulanması gereken gerçekçi senaryoları ve değerlendirme noktalarını adım adım ele alacağız.

Demo İçin Gerçek Bir Cari Hesap Oluşturun

Demo sırasında yapılabilecek en büyük hata, yazılım firmasının önceden hazırladığı örnek müşterilere bakarak karar vermektir. Hazır veriler sistemi güzel gösterebilir ancak sizin günlük operasyonunuzu temsil etmeyebilir.

Bunun yerine gerçek hayata benzeyen bir test müşterisi oluşturun.

Örneğin:

• Müşteri: Örnek Sitesi Yönetimi
• Asansör sayısı: 4
• Aylık bakım bedeli: 6.000 TL
• Önceki dönem borcu: 12.000 TL
• Güncel bakım bedeli: 6.000 TL
• Parça değişimi: 4.500 TL
• Yapılan tahsilat: 10.000 TL

Bu örnek üzerinden müşterinin toplam borcunun, yaptığı ödemelerin ve kalan bakiyesinin sistemde nasıl görüntülendiğini kontrol edin.

Demo sırasında özellikle şu sorulara cevap arayın:

1. Cari borç hareketleri tarih sırasıyla görülebiliyor mu?
2. Bakım, parça ve revizyon işlemleri birbirinden ayırt edilebiliyor mu?
3. Tahsilat girildiğinde bakiye otomatik güncelleniyor mu?
4. Yanlış girilen bir işlem düzeltildiğinde geçmiş kayıt anlaşılır kalıyor mu?
5. Müşteriye hesap özeti gönderilebiliyor mu?

Asansör sektöründe yüzlerce bina bulunan bir portföyde küçük cari hataları bile Excel üzerinden manuel kontrol etmek zamanla ciddi iş yüküne dönüşür. Bu nedenle demo sırasında sistemin yalnızca çalışıp çalışmadığına değil, hatalı işlem riskini ne kadar azalttığına da bakılmalıdır.

Senaryo 1: Aylık Bakım Borcu Oluşturma

İlk test edilmesi gereken işlem aylık bakım bedelidir. Çünkü birçok bakım firmasında cari hareketlerin büyük bölümü düzenli bakım hizmetlerinden oluşur.

Örneğin bir binanın aylık bakım ücreti 3.500 TL olsun. Demo sırasında bu bedelin cari hesaba nasıl işlendiğini görün.

Şunları kontrol edin:

• Bakım tamamlandığında borç otomatik veya kolay şekilde oluşturulabiliyor mu?
• İşlem açıklamasında hangi aya ait olduğu anlaşılıyor mu?
• Birden fazla asansörü bulunan binalarda ücretler doğru şekilde takip edilebiliyor mu?
• Aylık bakım borçları toplu şekilde oluşturulabiliyor mu?
• Bakım yapılmayan bir aya yanlışlıkla borç yazılmasının önüne geçilebiliyor mu?

Özellikle yüzlerce bakım sözleşmesi bulunan firmalarda her müşteriye ay sonunda tek tek borç yazılması ciddi operasyon yükü yaratır.

Örneğin 400 bakım müşterisi bulunan bir firmada her cari işlemin manuel olarak yalnızca 30 saniye sürdüğünü varsayalım. Sadece aylık bakım borçlarını oluşturmak için yaklaşık 200 dakika harcanabilir. Kontrol, düzeltme ve eksik kayıtlarla birlikte bu süre çok daha fazla olabilir.

Bu nedenle demo sırasında toplu işlemler ve otomasyon seçenekleri mutlaka değerlendirilmelidir.

Senaryo 2: Kısmi Tahsilat İşlemi

Asansör bakım firmalarının günlük hayatında müşterilerin tüm borcunu tek seferde ödememesi oldukça yaygındır.

Örneğin:

İşlem	Tutar
Geçmiş dönem borcu	8.000 TL
Nisan bakım bedeli	4.000 TL
Mayıs bakım bedeli	4.000 TL
Toplam borç	16.000 TL
Müşteri ödemesi	10.000 TL
Kalan bakiye	6.000 TL

Demo sırasında 10.000 TL tahsilat girin ve sistemin kalan borcu nasıl hesapladığını inceleyin.

Burada önemli olan sadece bakiyenin 6.000 TL görünmesi değildir. Tahsilatın hangi yöntemle yapıldığı da kayıt altına alınabilmelidir.

Örneğin:

• Nakit
• Banka havalesi
• EFT
• Kredi kartı
• Çek
• Diğer ödeme yöntemleri

Firma sahibi açısından bu ayrım günlük kasa ve banka kontrolünü kolaylaştırır.

Ayrıca tahsilat işlemi sonrasında müşteriye makbuz veya ödeme bilgisi gönderilip gönderilemediğini de test edin.

Senaryo 3: Bakım ve Parça Satışının Aynı Cari Hesapta İzlenmesi

Bir bina yöneticisinin cari hesabında yalnızca bakım ücreti bulunmaz.

Örneğin aynı ay içerisinde:

• Aylık bakım: 3.000 TL
• Fotosel değişimi: 2.500 TL
• Akü değişimi: 1.800 TL
• Kapı ayarı: 1.200 TL

gibi farklı işlemler oluşabilir.

Toplam borç 8.500 TL olabilir ancak firma sahibi açısından önemli olan yalnızca toplam rakam değildir.

Hangi tutarın hangi hizmetten kaynaklandığı açıkça görülebilmelidir.

Demo sırasında farklı işlem türleri oluşturun ve cari hareket ekranının okunabilirliğini inceleyin.

İyi bir sistemde birkaç ay sonra bile şu soruların cevabı kolayca bulunabilmelidir:

• Bu müşterinin borcunun ne kadarı bakım kaynaklı?
• Ne kadarı parça satışından oluşuyor?
• Hangi arıza işleminde ücret alınmış?
• Hangi işlem tahsil edilmiş?
• Hangi hizmet henüz faturaya dönüşmemiş?

Asansorex gibi asansör sektörüne özel yazılımlarda bakım, arıza, parça ve cari kayıtlarının aynı operasyon içinde tutulması, farklı Excel dosyaları arasında kontrol yapma ihtiyacını azaltabilir.

Senaryo 4: Gecikmiş Borçların Bulunması

Demo sırasında mutlaka test edilmesi gereken konulardan biri de gecikmiş alacak yönetimidir.

Örnek olarak sisteme üç müşteri girin:

Müşteri	Borç	Gecikme
A Apartmanı	4.000 TL	Güncel
B Sitesi	18.000 TL	45 gün
C İş Merkezi	32.000 TL	90 gün üzeri

Ardından yazılımdan gecikmiş borçları bulmaya çalışın.

Amaç şu soruya cevap vermektir:

Firma sahibi bugün tahsilat yapmak için kimi araması gerektiğini birkaç dakika içinde görebiliyor mu?

Bir cari programı yalnızca borç kaydetmemeli, tahsilat kararını da kolaylaştırmalıdır.

Özellikle şu filtreleri test etmek faydalıdır:

• Borçlu müşteriler
• Vadesi geçenler
• En yüksek bakiyeli müşteriler
• Belirli tarih aralığında ödeme yapmayanlar
• Belirli personelin takip ettiği müşteriler

Tahsilat listelerinin Excel'e veya rapora aktarılabilmesi de operasyon açısından avantaj sağlayabilir.

Senaryo 5: Fatura Kesme Süreci

Cari kayıt ile fatura aynı şey değildir. Bu ayrımın yazılımda doğru kurulması önemlidir.

Örneğin bir müşterinin cari hesabında:

• 5.000 TL bakım hizmeti
• 7.500 TL parça satışı
• 12.500 TL toplam borç

bulunduğunu düşünelim.

Müşteri yalnızca bakım bedeli için fatura isteyebilir veya firma belirli işlemleri farklı zamanlarda faturalandırabilir.

Demo sırasında şu senaryoyu deneyin:

1. Cari hesaba bakım ve parça işlemleri ekleyin.
2. Sadece bakım işlemini faturaya dönüştürün.
3. Parça satışını faturalanmamış bırakın.
4. Cari hesapta iki işlemin durumunu kontrol edin.
5. Daha sonra kalan işlemi de faturaya dönüştürün.

Programın faturalandırıldı ve faturalandırılmadı ayrımını net biçimde göstermesi önemlidir.

Aksi halde ay sonunda hangi işlemin faturaya dönüştüğü, hangisinin unutulduğu manuel olarak kontrol edilmek zorunda kalabilir.

Senaryo 6: Yanlış Tahsilat veya Cari Hareket Düzeltme

Demo ortamında özellikle hata yapmaya çalışın.

Çünkü gerçek hayatta personel yanlış rakam girebilir.

Örneğin 5.000 TL tahsilat yerine yanlışlıkla 50.000 TL girin.

Ardından şu işlemleri test edin:

• İşlem düzenlenebiliyor mu?
• İptal edilebiliyor mu?
• Düzeltme sonrası bakiye doğru hesaplanıyor mu?
• Önceki işlem geçmişte anlaşılır şekilde kalıyor mu?
• Yetkisiz personelin kritik finans kayıtlarını değiştirmesi sınırlandırılabiliyor mu?

Bir yazılımı değerlendirirken yalnızca doğru kullanım senaryoları değil, insan hatası senaryoları da test edilmelidir.

Çünkü finans tarafında küçük bir yanlış kayıt bile müşteriye gönderilen hesap ekstresinin hatalı görünmesine ve gereksiz tartışmalara neden olabilir.

Demo Sırasında Sorulması Gereken Kritik Sorular

Bir asansör cari programı demosunda aşağıdaki kontrol listesini kullanabilirsiniz:

• Cari hesapta tüm borç ve alacak hareketleri görülebiliyor mu?
• Bakım ücretleri kolay veya toplu şekilde oluşturulabiliyor mu?
• Kısmi tahsilat destekleniyor mu?
• Tahsilat türleri ayrı takip edilebiliyor mu?
• Gecikmiş borçlar filtrelenebiliyor mu?
• Müşteri hesap ekstresi oluşturulabiliyor mu?
• Parça satışları cari hesaba aktarılabiliyor mu?
• Arıza nedeniyle oluşan ücretler kaydedilebiliyor mu?
• Faturalandırılan işlemler ayırt edilebiliyor mu?
• Cari geçmişi kolay anlaşılabiliyor mu?
• Yanlış kayıtlar kontrollü şekilde düzeltilebiliyor mu?
• Kasa ve banka hareketleri izlenebiliyor mu?
• Tahsilat raporları alınabiliyor mu?
• Müşteri bazlı bakiye hızlı bulunabiliyor mu?
• Yüzlerce müşteride performans düşüyor mu?

Demo sonunda bu maddeleri “var/yok” şeklinde değil, mümkünse kendiniz işlem yaparak değerlendirin.

Demo İçin Küçük Bir Test Portföyü Oluşturun

Tek bir müşteriyle yapılan demo çoğu zaman yanıltıcıdır.

Daha gerçekçi sonuç almak için en az 5 farklı müşteri tipi oluşturabilirsiniz.

Örneğin:

Düzenli ödeme yapan müşteri

Her ay bakım borcu oluşur ve aynı ay içinde ödeme yapar.

Sürekli geciken müşteri

Üç aylık bakım borcu birikir ve ara sıra kısmi ödeme yapar.

Parça işlemi yoğun müşteri

Bakım dışında sık sık yedek parça ve revizyon işlemleri bulunur.

Çok asansörlü site

Aynı yönetim altında birden fazla asansör bulunur.

Fatura süreci farklı müşteri

Cari borç oluşur ancak faturası daha sonra veya kısmi olarak kesilir.

Bu beş profil, programın farklı iş modellerinde nasıl davrandığını çok daha net gösterir.

Cari Programı Değerlendirirken Hız da Ölçülmeli

Bir işlem yapılabiliyor olması tek başına yeterli değildir.

Örneğin tahsilat girmek için altı farklı ekran arasında geçmek gerekiyorsa, sistem teorik olarak işlevsel olsa bile günlük kullanımda verimsiz olabilir.

Demo sırasında süre tutabilirsiniz.

Örneğin:

Test	İdeal değerlendirme
Yeni müşteri cari açma	Kolay ve birkaç adım
Tahsilat kaydı	Tek akış içinde hızlı
Borç sorgulama	Birkaç saniyede erişilebilir
Hesap ekstresi	Tek ekrandan ulaşılabilir
Gecikmiş borç listesi	Filtreyle hızlı bulunabilir
Fatura durumu kontrolü	Cari hareketten anlaşılabilir

Özellikle saha ve ofis personelinin yoğun olduğu firmalarda birkaç saniyelik işlem farkları ay sonunda ciddi zaman tasarrufuna dönüşebilir.

Sıkça Sorulan Sorular

Asansör cari programı demosu ne kadar detaylı olmalı?

Demo yalnızca temel ekran tanıtımıyla sınırlı kalmamalıdır. Bakım borcu, parça satışı, kısmi tahsilat, gecikmiş ödeme, fatura ve cari düzeltme gibi gerçek senaryolar mutlaka uygulanmalıdır.

Demo sırasında kendi müşteri verilerimizi kullanmak gerekir mi?

Gerçek müşteri bilgilerini kullanmak şart değildir. Ancak firmanızdaki tipik müşteri yapılarını temsil eden örnek veriler oluşturmak değerlendirmeyi çok daha sağlıklı hale getirir.

Cari programında en önemli rapor hangisidir?

Tek bir rapor yerine borçlu müşteriler, gecikmiş alacaklar, tahsilatlar ve müşteri hesap hareketleri birlikte değerlendirilmelidir. Özellikle gecikmiş alacak raporu firma sahibinin nakit akışı açısından önemlidir.

Asansör bakım programı ile cari programı aynı sistemde olabilir mi?

Evet. Sektöre özel sistemlerde bakım, arıza, parça ve cari süreçlerinin bağlantılı çalışması mümkündür. Bu yapı, aynı işlemin farklı sistemlere tekrar tekrar girilmesini azaltabilir.

Demo sırasında mobil kullanım test edilmeli mi?

Tahsilat veya saha işlemleri teknisyenler tarafından yapılıyorsa mobil kullanım mutlaka test edilmelidir. Özellikle sahada tahsilat kaydı, makbuz veya işlem geçmişi gibi özelliklerin kullanım kolaylığı önemlidir.

Program seçerken yalnızca fiyat karşılaştırması yeterli midir?

Hayır. Daha ucuz görünen bir yazılım, günlük işlemleri yavaşlatıyor veya cari kontrol için ek Excel dosyaları gerektiriyorsa toplam operasyon maliyeti daha yüksek olabilir. Demo sırasında işlem hızını ve iş yükünü de değerlendirmek gerekir.

Özet

Bir asansör cari programı demosunun amacı menüleri gezmek değil, firmanızdaki gerçek finansal akışı yazılım üzerinde canlandırmaktır. Aylık bakım borcu oluşturma, kısmi tahsilat, parça satışı, gecikmiş alacak, fatura ve yanlış işlem düzeltme senaryolarını test etmek programın gerçek performansını ortaya çıkarır.

Demo sırasında mümkün olduğunca farklı müşteri tipleri oluşturun, işlemleri kendiniz gerçekleştirin ve özellikle birkaç ay sonra geçmiş kayıtların ne kadar kolay anlaşılabileceğine dikkat edin.

Asansorex gibi asansör bakım operasyonu ile cari süreçleri aynı yapı içerisinde takip etmeye odaklanan çözümler değerlendirilirken de aynı yöntemi kullanabilirsiniz. Böylece satın alma kararını yalnızca özellik listesine göre değil, gerçek günlük operasyonunuza ne kadar uyduğuna göre verebilirsiniz.