Asansör Bakım Programı Alırken Destek SLA'sı

İÇERİK

Asansör bakım programı satın alırken firmaların ilk baktığı konular genellikle fiyat, mobil uygulama, bakım planlama, arıza yönetimi ve finans modülleridir. Ancak yazılım günlük operasyonun merkezine yerleştiğinde başka bir konu en az bu özellikler kadar önemli hâle gelir: teknik destek SLA'sı.

SLA, yani Service Level Agreement, Türkçede hizmet seviyesi anlaşması olarak ifade edilir. Basit anlatımla SLA; bir problem yaşadığınızda yazılım sağlayıcısının size ne kadar sürede dönüş yapacağını, hangi sorunlara hangi önceliği vereceğini ve destek kapsamının nerede başlayıp nerede biteceğini belirleyen çerçevedir.

Bir asansör bakım firmasında yazılımın birkaç saat kullanılamaması bile teknisyenlerin bakım föylerini kapatamaması, arıza kayıtlarının gecikmesi, tahsilat bilgilerinin girilememesi veya bina yöneticilerine zamanında bilgi verilememesi anlamına gelebilir. Bu nedenle program seçerken sadece "destek veriyoruz" cümlesini duymak yeterli değildir. Desteğin nasıl verildiği ve hangi sürede verildiği ölçülebilir olmalıdır.

Destek SLA'sı Neden Asansör Firmaları İçin Kritik?

Bir ofis programında yaşanan sorun bazen ertesi güne bırakılabilir. Fakat asansör bakım operasyonu büyük ölçüde sahada ilerlediği için yazılım kesintilerinin etkisi daha hızlı hissedilir.

Örneğin sabah 08.30'da teknisyenler günlük bakım rotasına çıktı. Mobil uygulamada bakım kapatma işlemi sırasında sorun oluştuğunu düşünelim. Firma 10 teknisyenle çalışıyorsa ve problem saatlerce çözülemezse gün sonunda onlarca bakım kaydının eksik kalması mümkündür.

Benzer şekilde;

• Arıza kaydı teknisyene iletilemeyebilir.
• Bakım formu tamamlanamayabilir.
• Fotoğraf veya imza sisteme eklenemeyebilir.
• Tahsilat kaydı gecikebilir.
• Müşteri geçmişine erişilemeyebilir.
• Teklif veya sözleşme süreçleri aksayabilir.
• Günlük operasyon yöneticisi hangi işlerin tamamlandığını göremeyebilir.

Bu nedenle destek hizmetini yalnızca "sorun olduğunda telefon açabileceğimiz bir yer var" şeklinde değerlendirmek doğru değildir.

İyi bir destek SLA'sı, sorunun hiç yaşanmayacağını garanti etmez; sorun yaşandığında belirsizliği azaltır.

Firma sahibi açısından önemli olan, problemin bildirildiği anda karşısında nasıl bir süreç olduğunu bilmektir.

SLA'da Yanıt Süresi ile Çözüm Süresini Karıştırmayın

Yazılım görüşmelerinde en sık yapılan hatalardan biri yanıt süresi ile çözüm süresini aynı şey sanmaktır.

Örneğin yazılım firması "15 dakikada destek veriyoruz" diyebilir. Burada sorulması gereken soru şudur:

15 dakika içinde sadece talebin alındığı mı bildiriliyor, yoksa sorun çözülüyor mu?

Bu iki kavram birbirinden farklıdır.

Kavram	Ne Anlama Gelir?	Örnek
İlk yanıt süresi	Destek ekibinin talebi gördüğünü ve incelemeye aldığını bildirme süresi	30 dakika
Müdahale süresi	Teknik ekibin problemi aktif olarak incelemeye başlaması	1 saat
Geçici çözüm süresi	Operasyonun devam etmesini sağlayacak alternatif çözüm sunulması	2 saat
Kalıcı çözüm süresi	Sorunun tamamen giderilmesi	Problemin seviyesine göre değişir
Güncelleme sıklığı	Çözüm devam ederken müşteriye durum bilgisi verilmesi	Örneğin her 2 saatte bir

Özellikle kritik problemlerde geçici çözüm süresi de önemlidir.

Örneğin teknisyenlerin bakım kaydı oluşturamadığı bir durumda kalıcı yazılım düzeltmesi birkaç saat sürebilir. Ancak destek ekibi operasyonun devam etmesini sağlayacak geçici bir yöntem sunabiliyorsa saha tamamen durmak zorunda kalmaz.

Bu nedenle program alırken şu soruyu mutlaka sorun:

"Kritik bir problemde sadece dönüş süreniz mi var, yoksa müdahale ve çözüm hedefiniz de tanımlı mı?"

Sorunların Öncelik Seviyesi Nasıl Belirlenmeli?

Her teknik problemin aynı önemde değerlendirilmesi doğru değildir.

Bir rapordaki sütunun yanlış sıralanması ile 15 teknisyenin sisteme giriş yapamaması aynı önceliğe sahip olamaz.

Profesyonel SLA yapılarında talepler genellikle önem seviyesine göre sınıflandırılır.

Kritik Seviye

Firmanın ana operasyonunun durduğu problemlerdir.

Örneğin:

• Kullanıcıların sisteme giriş yapamaması,
• Bakım veya arıza kayıtlarının tamamen açılamaması,
• Mobil uygulamanın tüm saha ekibinde çalışmaması,
• Sisteme genel erişimin kesilmesi.

Bu tür sorunlarda hızlı müdahale beklenmelidir.

Yüksek Öncelik

Operasyon devam eder ancak önemli bir fonksiyon kullanılamaz.

Örneğin bakım işlemleri yapılabiliyor fakat sahadan fotoğraf yüklenemiyor olabilir.

Normal Öncelik

Operasyonu doğrudan durdurmayan teknik problemlerdir.

Örneğin bir rapor filtresinin beklenen şekilde çalışmaması veya belirli bir ekranda görüntüleme problemi yaşanması.

Talep veya Geliştirme

Her destek talebi hata değildir.

Firma sahibi yeni bir rapor, farklı bir çıktı biçimi veya ek özellik isteyebilir. Bunların teknik arıza SLA'sı kapsamında değerlendirilmesi beklenmemelidir.

Bu ayrımı satın alma öncesinde netleştirmek, ileride yaşanabilecek "Biz bunu destek talebi sandık, yazılım firması geliştirme talebi saydı" tartışmalarını ciddi ölçüde azaltır.

Asansör Bakım Programı Alırken Sorulması Gereken SLA Soruları

Demo görüşmesinde çoğu firma özellikleri uzun uzun inceler ancak destek bölümünü birkaç dakikada geçer. Oysa satın alma kararından önce destek sisteminin de küçük bir teste tabi tutulması faydalıdır.

Yazılım sağlayıcısına şu soruları yöneltebilirsiniz:

1. Destek hangi kanallardan veriliyor? Telefon, WhatsApp, e-posta veya destek talebi sistemi kullanılabiliyor mu?

2. Destek saatleri nedir? Hafta içi mesai saatleri dışında ulaşılabilecek bir kanal var mı?

3. Kritik sorun nasıl tanımlanıyor? Firmanın çalışmasını tamamen durduran problemlere farklı öncelik uygulanıyor mu?

4. İlk yanıt hedefiniz nedir? Kritik ve normal talepler için farklı süreler bulunuyor mu?

5. Sorun çözülene kadar bilgi veriliyor mu? Talebi açtıktan sonra saatlerce cevapsız kalıp kalmayacağınızı öğrenin.

6. Destek ücretli mi? Yıllık lisansa hangi destek hizmetlerinin dahil olduğunu sorun.

7. Yeni personel eğitimi destek kapsamında mı? İşe yeni başlayan ofis veya saha personeli için tekrar eğitim verilmesi önemli olabilir.

8. Veri aktarımı ve kurulum desteği dahil mi? Eski Excel dosyalarından veya başka bir yazılımdan geçiş sürecini ayrıca değerlendirin.

9. Uzaktan bağlantı desteği sağlanıyor mu? Bazı problemleri telefonla anlatmak yerine doğrudan incelemek çok daha hızlı olabilir.

10. Destek geçmişi kayıt altında tutuluyor mu? Aynı problemin tekrarında eski çözüm kayıtlarının bulunması süreci hızlandırır.

Bu sorulara net cevap veremeyen bir sağlayıcının desteğinin günlük operasyonda nasıl çalışacağını öngörmek zorlaşır.

"7/24 Destek" İfadesini Tek Başına Yeterli Görmeyin

Satış görüşmelerinde "7/24 destek" güçlü bir ifade gibi görünür. Ancak bu cümlenin pratikte tam olarak ne anlama geldiği sorgulanmalıdır.

Örneğin gece 23.00'te gönderilen mesaja otomatik cevap gelmesi teknik olarak iletişim kanalının açık olduğunu gösterebilir. Fakat bu, problemi çözebilecek teknik personelin aynı anda devreye gireceği anlamına gelmez.

Bu nedenle şu ayrımı yapın:

• Talep oluşturma kanalı 7/24 açık mı?
• Gerçek bir destek personeli ulaşılabilir mi?
• Kritik olaylara mesai dışında müdahale ediliyor mu?
• Hafta sonu için farklı bir prosedür var mı?

Özellikle yüzlerce asansörü yöneten ve nöbetçi arıza ekibi bulunan firmalarda bu konunun satın alma öncesinde konuşulması önemlidir.

Firma yalnızca hafta içi çalışıyor olsa bile acil arıza operasyonunun hafta sonu devam edebileceği unutulmamalıdır.

SLA Sadece Arıza Çözmekten İbaret Değildir

İyi destek hizmeti yalnızca yazılım çöktüğünde ortaya çıkmaz.

Asansör firmalarının günlük işleyişinde kullanıcı kaynaklı sorular da oldukça fazladır.

Örneğin:

• Yeni teknisyen nasıl tanımlanır?
• Bakım planı yanlış oluşturulduysa nasıl düzenlenir?
• Bir bina başka personele nasıl atanır?
• Geçmiş bakım kayıtları nasıl bulunur?
• Bir teklif yeniden nasıl hazırlanır?
• Cari hesapta yanlış girilen işlem nasıl düzeltilir?

Bu sorular doğrudan sistem hatası değildir ancak kullanıcının işini aksatabilir.

Bu nedenle destek anlaşmasında kullanım danışmanlığı ile teknik hata desteğinin ayrımını anlamak gerekir.

Asansorex gibi asansör sektörüne özel bakım yönetim yazılımları değerlendirilirken yalnızca modül listesine değil; onboarding, kullanıcı eğitimi ve günlük operasyon sırasında alınabilecek desteğin kapsamına da bakmak satın alma kararını daha sağlıklı hâle getirir.

Destek Kalitesini Satın Almadan Önce Nasıl Test Edebilirsiniz?

SLA belgesi görmek önemlidir fakat gerçek deneyimi anlamanın en iyi yollarından biri destek sürecini satış öncesinde test etmektir.

Bunun için küçük bir değerlendirme yapabilirsiniz.

Demo Sonrası Teknik Bir Soru Gönderin

Örneğin:

"İnternet bağlantısı zayıf olan bölgede teknisyen bakım kaydını nasıl tamamlıyor?"

veya:

"Yanlış binaya kaydedilen bakım işlemini nasıl düzeltebiliriz?"

Gönderdiğiniz soruya ne kadar sürede ve ne kadar açıklayıcı yanıt verildiğini gözlemleyin.

Referans Firmalara Destek Konusunu Sorun

Referans görüşmesinde yalnızca "Programdan memnun musunuz?" sorusunu sormayın.

Daha somut sorular yöneltin:

• Sorun yaşadığınızda ulaşabiliyor musunuz?
• Ortalama dönüş süresi nasıl?
• Kritik bir problem yaşadınız mı?
• Destek ekibi çözüm üretebildi mi?
• Personel değiştiğinde eğitim desteği aldınız mı?

Bu sorular çok daha gerçekçi bilgi verir.

Deneme Sürecinde Destek Ekibini Kullanın

Pilot veya deneme hesabı sunuluyorsa birkaç gün boyunca sadece programı değil, destek hizmetini de test edin.

Çünkü yazılımın kullanım ömrü boyunca muhatap olacağınız ekip satış temsilcisinden çok destek ekibi olacaktır.

SLA Sözleşmesinde Nelere Dikkat Edilmeli?

Yazılım lisansı alınırken SLA şartlarının mümkün olduğunca açık olması faydalıdır.

Özellikle aşağıdaki konular belirsiz bırakılmamalıdır:

• Destek kanalları,
• Destek çalışma saatleri,
• Kritik olay tanımı,
• İlk yanıt hedefi,
• Planlı bakım ve güncelleme bildirimleri,
• Kullanıcı eğitiminin kapsamı,
• Veri aktarım desteği,
• Yeni özellik taleplerinin kapsam dışında olup olmadığı,
• Ek ücret gerektiren hizmetler.

Buradaki amaç onlarca sayfalık karmaşık sözleşme hazırlamak değildir. Önemli olan tarafların beklentisini baştan aynı noktaya getirmektir.

Örneğin bakım firmasının beklentisi "Telefon açtığım anda teknik ekip bağlanır" iken yazılım sağlayıcısının hizmet modeli "Talep açılır ve mesai saatleri içinde değerlendirilir" şeklindeyse, ürün ne kadar iyi olursa olsun ileride memnuniyetsizlik çıkabilir.

Firma Büyüdükçe SLA'nın Önemi Artar

50 asansörlük portföyü olan bir işletme ile 2.000 asansörlük operasyonu yöneten şirketin yazılım kesintisine toleransı aynı değildir.

Portföy büyüdükçe;

• günlük bakım sayısı,
• teknisyen sayısı,
• arıza kaydı,
• müşteri iletişimi,
• tahsilat işlemleri,
• raporlama ihtiyacı

artar.

Dolayısıyla yazılım firmanın operasyonunda daha kritik bir noktaya gelir.

Örneğin 3 teknisyen kullanan küçük bir işletmede bir saatlik problem manuel yöntemlerle geçici olarak yönetilebilir. Ancak 30 saha çalışanı bulunan organizasyonda aynı problem kısa sürede yüzlerce işlemi etkileyebilir.

Bu nedenle firma büyüdükçe fiyat karşılaştırmasında destek kalitesine verilen ağırlığın da artması gerekir.

Yıllık lisans fiyatı daha düşük olduğu için seçilen ancak ihtiyaç anında ulaşılamayan bir yazılım, birkaç operasyon kaybında oluşan iş gücü maliyeti nedeniyle beklenenden daha pahalı hâle gelebilir.

Sıkça Sorulan Sorular

SLA nedir?

SLA, Service Level Agreement ifadesinin kısaltmasıdır. Yazılım sağlayıcısının destek, erişilebilirlik, müdahale ve hizmet seviyelerine ilişkin taahhütlerini belirleyen hizmet seviyesi anlaşmasıdır.

Asansör bakım programında SLA şart mı?

Her yazılım firmasında ayrı bir SLA belgesi bulunması zorunlu olmayabilir. Ancak destek saatleri, iletişim kanalları ve kritik sorunlara müdahale yaklaşımının satın alma öncesinde yazılı şekilde netleştirilmesi işletme açısından oldukça faydalıdır.

İlk yanıt süresi ile çözüm süresi aynı mı?

Hayır. İlk yanıt, destek ekibinin talebi aldığını bildirdiği süredir. Çözüm süresi ise problemin giderilmesi için gereken süreyi ifade eder. Satın alma görüşmesinde ikisinin ayrı ayrı sorulması gerekir.

Yazılım desteğinin lisans ücretine dahil olup olmadığını sormalı mıyım?

Evet. Bazı sağlayıcılarda temel destek lisansa dahilken özel eğitim, veri aktarımı veya yerinde destek gibi hizmetler ayrıca ücretlendirilebilir. Bu nedenle toplam maliyeti değerlendirmeden önce kapsam netleştirilmelidir.

SLA sadece büyük asansör firmaları için mi önemlidir?

Hayır. Küçük firmalarda da operasyon kaybını önlemek açısından önemlidir. Ancak çalışan ve portföy sayısı arttıkça sistem kesintisinin işletmeye etkisi büyüdüğü için SLA'nın önemi daha da yükselir.

Program seçerken destek mi özellik mi daha önemli?

İkisini birbirinden ayırmak doğru değildir. Güçlü özelliklere sahip ancak gerektiğinde destek alınamayan bir sistem günlük kullanımda sorun yaratabilir. En sağlıklı seçim; işlev, kullanım kolaylığı, destek, veri güvenliği ve toplam maliyetin birlikte değerlendirilmesiyle yapılır.

Özet

Asansör bakım programı satın almak yalnızca bir yazılım lisansı satın almak değildir. Firma aynı zamanda bakım, arıza, tahsilat, teklif ve müşteri iletişimi gibi günlük operasyonlarının önemli bir bölümünü o sisteme emanet eder.

Bu nedenle satın alma görüşmesinde destek SLA'sını fiyat kadar ciddiye almak gerekir.

Yanıt süresi, müdahale yöntemi, kritik olay sınıflandırması, destek saatleri, eğitim kapsamı ve ek ücretli hizmetler mümkün olduğunca baştan netleştirilmelidir. Özellikle "7/24 destek" veya "anında destek" gibi genel ifadelerin yerine ölçülebilir süreçler sorulmalıdır.

Asansorex gibi asansör bakım ve yönetim yazılımlarını değerlendirirken de modüllerin yanında destek sürecini, geçiş yardımını ve günlük kullanım sırasında karşılaşabileceğiniz problemlerde nasıl bir iletişim modeli sunulduğunu incelemek daha doğru bir satın alma kararı vermenizi sağlar.