Bir yazılım sağlayıcısıyla ilk görüşmeye hazırlıksız giren acente, genellikle karşısındakinin anlattığı özellik listesine göre düşünmeye başlar. Oysa doğru soru “Bu yazılım neler yapıyor?” değil, “Bizim acentemizin hangi işlerinin daha düzenli yürümesi gerekiyor?” sorusudur. İhtiyaç dokümanı, bu sorunun cevabını görüşmelerden önce yazıya döken kısa ve net bir belgedir. Büyük kurumların kullandığı kalın teknik şartnamelere benzemek zorunda değildir; birkaç sayfalık, sade bir belge çoğu acente için yeterlidir.
İhtiyaç dokümanı neden işe yarar?
Yazılım seçimi çoğu zaman birden fazla kişinin görüşüyle yapılır. Acente sahibi raporlamayı, operasyon sorumlusu yenileme takibini, satış ekibi teklif hızını önemser. Bu beklentiler yazılı olmadığında her demo farklı bir bakış açısıyla izlenir ve karar, en etkileyici sunuma kayar. Yazılı bir ihtiyaç dokümanı:
- Farklı adayları aynı ölçütlerle değerlendirmenizi sağlar.
- Sağlayıcıya genel bir tanıtım yerine sizin senaryolarınızı göstermesini istemenize imkân verir.
- Kurulumdan sonra “Bunu almıştık ama kullanmıyoruz” durumunu azaltır.
- Ekip içindeki öncelik tartışmalarını seçim sürecinin başında çözer.
Belgenin iskeleti: altı bölüm
Aşağıdaki iskelet, küçük veya orta ölçekli bir acentenin ihtiyaçlarını düzenli biçimde yazmasına yardım eder. Bölümleri sırayla doldurmak, düşünceyi de sıraya sokar.
1. Acentenin kısa profili
Kaç kullanıcının sistemi kullanacağını, şube veya saha çalışanı olup olmadığını, hangi branşlarda yoğunlaştığınızı birkaç cümleyle yazın. Bu bölüm, sağlayıcının çözümünü sizin ölçeğinize göre anlatmasını kolaylaştırır.
2. Bugünkü çalışma biçimi
Müşteri bilgisinin nerede tutulduğunu, teklifin nasıl hazırlandığını, yenilemelerin kim tarafından ve hangi araçla takip edildiğini anlatın. Burada amaç kusur aramak değil, mevcut durumu dürüstçe kaydetmektir. Örneğin “Trafik teklifleri için şirket portalları tek tek açılıyor, kasko teklifleri ayrı bir tabloda karşılaştırılıyor” gibi somut cümleler, soyut ifadelerden çok daha değerlidir.
3. Çözülmesi gereken sorunlar
Her sorunu bir cümleyle ve bir örnekle yazın. “Yenilemeleri kaçırıyoruz” yerine “Poliçe bitişleri tek bir kişinin takviminde duruyor; o kişi izindeyken takip aksıyor” demek, sağlayıcının çözümünü doğrudan bu senaryo üzerinde göstermesini sağlar.
4. İşlevsel ihtiyaçlar
Bu bölümde sistemin yapması gereken işleri süreç bazında listeleyin. Teklif tarafında trafik, kasko ve DASK'ın birbirinden farklı bilgi ihtiyaçları olduğunu unutmayın: trafikte araç ve ruhsat bilgileri, kaskoda araç değeri ve teminat tercihleri, DASK'ta ise adres ve yapı bilgileri öne çıkar. Bu nedenle her branş için ayrı bir sorgu akışı beklediğinizi açıkça yazın. Ardından müşteri kartı, yenileme takibi, tahsilat, görev yönetimi ve raporlama gibi başlıkları ekleyin.
5. Teknik ve yönetsel beklentiler
Kullanıcı yetkilendirmesi, iki aşamalı doğrulama, işlem kayıtları, mobil erişim, veri dışa aktarma ve yedekleme gibi konular bu bölüme girer. Teknik ekibiniz olmasa bile “Bir çalışan ayrıldığında erişimini tek adımda kapatabilmeliyiz” gibi yönetsel bir cümle, önemli bir güvenlik ihtiyacını tarif eder.
6. Kabul ölçütleri
Her ihtiyacın yanına, karşılandığını nasıl anlayacağınızı yazın. “Yenileme listesi kullanıcı bazında filtrelenebiliyor” veya “Hazırlanan teklif müşteriye PDF olarak gönderilebiliyor” gibi gözlemlenebilir ifadeler, demo sırasında işaretlenebilir bir kontrol listesine dönüşür.
Öncelikleri üç kademede sınıflandırın
Her ihtiyaç aynı ağırlıkta değildir. Listeyi tamamladıktan sonra her maddeyi şu üç kademeden birine yerleştirin:
- Vazgeçilmez: Karşılanmazsa yazılımı kullanamayacağınız işler. Örneğin branş bazlı teklif akışı veya merkezi müşteri kaydı.
- Önemli: İlk aylarda olmasa da kısa vadede ihtiyaç duyacağınız işler. Örneğin şube bazlı raporlama.
- İyi olur: Değer katan ama karar verdirmeyen işler. Örneğin arayüzde kişiselleştirme seçenekleri.
Vazgeçilmez listesi kısa kalmalıdır. Her şeyi vazgeçilmez saymak, önceliklendirmenin anlamını ortadan kaldırır.
Kimin katkı vereceğini baştan belirleyin
İhtiyaç dokümanını yalnızca acente sahibinin yazması sık yapılan bir hatadır. Günlük işi yürüten kişiler, belgede görünmeyen pek çok ayrıntıyı bilir. Kısa bir toplantıda her rolden bir kişiye şu iki soruyu sorun: “Gününüzde en çok zaman alan iş hangisi?” ve “Hangi bilgiye ulaşmakta zorlanıyorsunuz?” Bu cevaplar, üçüncü ve dördüncü bölümün ham maddesidir.
Sık yapılan yazım hataları
- Çözümü ihtiyaç gibi yazmak: “Şu ekran olmalı” yerine “Şu bilgiye iki tıkta ulaşmalıyız” demek, sağlayıcıya farklı çözümler sunma alanı bırakır.
- Belirsiz sıfatlar kullanmak: “Hızlı”, “kolay”, “gelişmiş” gibi kelimeler ölçülemez. Yerine somut bir senaryo yazın.
- Gelecek planlarını unutmak: Önümüzdeki dönemde şube açmayı veya saha ekibi kurmayı düşünüyorsanız bunu belirtin.
- Veri çıkışını sormamak: Verilerinizi gerektiğinde dışa aktarabilmek, ilk günden yazılması gereken bir ihtiyaçtır.
Belgeyi demo sürecinde kullanmak
İhtiyaç dokümanı hazır olduğunda, sağlayıcıdan genel tanıtım yerine belgede yazdığınız senaryoları sırayla göstermesini isteyin. InsureHub gibi bir sigorta acentesi yazılımı değerlendirirken, örneğin bir trafik teklifinin araç sorgusuyla başlayıp karşılaştırma ekranına ve PDF teklif formuna kadar nasıl ilerlediğini kendi verilerinize benzer örneklerle görmek, belgedeki kabul ölçütlerini tek tek işaretlemenizi sağlar. Müşteri kartı ve yenileme takibine ilişkin maddeler için acente CRM modülünü aynı şekilde senaryo üzerinden incelemek mümkündür.
Demo hesabıyla yapılan denemelerde, belgeyi ekip üyelerine dağıtıp her birinin kendi bölümünü kontrol etmesini isteyin. Böylece değerlendirme tek bir kişinin izlenimine değil, ortak bir kayda dayanır. Kendi senaryolarınızı denemek için demo talep sayfasından hesap oluşturabilirsiniz.
Belge yaşayan bir kayıttır
İhtiyaç dokümanı yazılım seçildikten sonra çöpe atılacak bir evrak değildir. Kurulum ve eğitim aşamasında hangi işlerin önce devreye alınacağını belirlemek, birkaç ay sonra ise beklentilerin karşılanıp karşılanmadığını kontrol etmek için aynı belgeye geri dönebilirsiniz. Belgenin sonuna bir “gözden geçirme tarihi” ekleyerek bu alışkanlığı baştan kurmak, dijital dönüşümün plansız bir satın alma olarak kalmamasını sağlar.