Hukuk Yazılımı Referanslarında Bürolara Ne Sorulmalı?

Bir sağlayıcının yönlendirdiği referans büro, yazılımın gerçek kullanımına dair değerli ipuçları verebilir. Ancak o büro, sizin ekibinizle aynı rollere, dosya yoğunluğuna veya çalışma düzenine sahip olmayabilir. Bu nedenle görüşmenin hedefi yalnızca “memnunlar mı?” sorusuna yanıt bulmak değil, hangi koşullarda hangi deneyimi yaşadıklarını anlamak olmalıdır.

Aşağıdaki kontrol listesi, hukuk yazılımı kullanan bürolara sorulacak soruları ortak bir yapıda toplamanıza yardımcı olur. Böylece farklı görüşmeleri aynı ölçütlerle not edebilir, olumlu veya olumsuz yanıtların arkasındaki somut olayları ayırabilirsiniz.

1. Bir referans görüşmesi yazılım seçimine hangi bilgiyi ekler?

Referans kullanıcısı ile sağlayıcı anlatımını ayırmak

Demo, sağlayıcının ürünü planlı ve kontrollü bir akış içinde göstermesini sağlar. Referans görüşmesi ise yazılımı günlük işinde kullanan bir büronun gerçek işleyişini, karşılaştığı güçlükleri ve zaman içinde değişen beklentilerini anlamaya yarar. Bu iki kaynak farklı sorulara yanıt verir: Demo, sizin için önemli bir işin nasıl yürütülebildiğini gösterir; referans ise bu işin kullanıma geçtikten sonra büroda nasıl karşılandığını anlatabilir.

Bir kullanıcıdan yalnızca olumlu özellikleri değil, başlangıçta ne beklediğini, hangi işlerde yazılıma başvurduğunu ve hangi işleri mevcut yöntemlerle sürdürdüğünü de öğrenebilirsiniz. Örneğin, ekipte herkesin aynı ölçüde kullanıp kullanmadığını veya belirli bir iş akışının beklenenden fazla uyarlama gerektirip gerektirmediğini sorabilirsiniz. Bu tür ayrıntılar, sağlayıcının sunumunda görünmeyen benimseme ve uygulama farklarını ortaya çıkarabilir.

Görüşmeyi sağlayıcı sunumunun tekrarı gibi yürütmeyin. “Sistem hızlı mı?” yerine “Son dönemde işinizi aksatan bir yavaşlama yaşadınız mı; ne yapıyordunuz ve sonuç ne oldu?” diye sorun. Açık uçlu soru, muhatabın kendi deneyimini anlatmasına alan açar. Siz de yanıtı, genel bir sıfat yerine olay, etki ve çözüm üzerinden not edebilirsiniz.

Görüşmenin sınırları ve teyit edilmesi gereken yanıtlar

Tek bir büro, kendi koşullarındaki deneyimi anlatır; sizin büronuz için sonuç garantisi vermez. Yanıtlar, görüşülen kişinin rolüne ve hangi süreçleri doğrudan kullandığına bağlıdır. Örneğin, yönetici yazılımın satın alma ve geçiş sürecini iyi biliyor olabilir; fakat günlük dosya takibini başka bir ekip üyesi yürütüyor olabilir. Bu nedenle görüşme başında kişinin rolünü ve hangi işlerde sistemi kullandığını öğrenin.

Yanıtları üç başlıkta kaydedin: doğrudan yaşanan, kişisel değerlendirme ve teyit edilmesi gereken. “Geçiş kolaydı” kişisel bir değerlendirmedir. “Büro, önce belirli kayıtları aktardı; bazı dosyalar için ek kontrol yaptı ve ekip iş akışını bir süre paralel yürüttü” ise ayrıntılandırılmış bir deneyim anlatımıdır. Yine de bu deneyimi kendi büronuz için doğrulanmış sonuç saymayın.

Referans görüşmesinden çıkan somut soruları demo veya yazılı ürün açıklamasına taşıyın. Görüşmede bir sınırlama duyduysanız, bunun bugün de geçerli olup olmadığını ve sizin kullanım senaryonuzu etkileyip etkilemediğini sağlayıcıya sorun. Demo değerlendirmesinde soruları önceden düzenlemek için demo kontrol listesini kullanabilirsiniz.

2. Hangi bürolardan referans istemek daha anlamlıdır?

Büro benzerliğini belirleyen ölçütler

Benzerlik yalnızca avukat sayısı veya büronun genel büyüklüğü değildir. Aynı büyüklükte iki büro, dosyaları farklı biçimde paylaşabilir; birinde yönetici ve destek rolleri ayrıyken diğerinde avukatlar birçok işi birlikte yürütebilir. Bu fark, yazılımı kimin hangi amaçla kullandığını ve yeni bir çalışma düzeninin ekipte nasıl karşılandığını etkileyebilir.

Referans ararken kendi büronuz için aşağıdaki ölçütleri yazın. Hepsinin birebir örtüşmesini beklemeyin; önemli olan kararınızı etkileyebilecek benzerlik ve farkları önceden görmektir.

• Ekip rolleri: Sistemi avukatlar dışında idari ekip, asistanlar veya yöneticiler de kullanacak mı?
• Dosya ve iş yoğunluğu: Ekip, düzenli ve yüksek hacimli işler mi yürütüyor; yoksa daha az sayıda, farklı takip ihtiyaçları olan dosyalar mı var?
• İş akışları: Dosya açılışı, görev paylaşımı, takvim takibi veya müvekkil iletişimi sizin için ne kadar merkezi?
• Mevcut çalışma biçimi: Ekip bugün bilgiyi nasıl kaydediyor ve paylaşıyor? Yeni sisteme geçerken hangi alışkanlıkların değişmesi bekleniyor?
• Kullanım yeri: Ekip ağırlıklı olarak büroda mı çalışıyor, farklı yerlerden erişim ihtiyacı mı duyuyor?

Bu ölçütleri görüşme öncesinde sağlayıcıyla paylaşın. “Bize benzer bir büro önerir misiniz?” demek yerine, benzerliğin sizin için hangi boyutta önemli olduğunu belirtin. Böylece önerilen referansın hangi yönlerden karşılaştırılabilir olduğunu daha kolay değerlendirebilirsiniz.

Farklı kullanım deneyimlerini birlikte değerlendirmek

Sağlayıcının seçtiği tek örneğe bağlı kalmak, farklı deneyimleri görmenizi engelleyebilir. Birbirine tamamen benzeyen bürolarla görüşmeniz de her zaman en yararlı karşılaştırmayı sağlamaz. Örneğin, aynı büyüklükte iki bürodan biri günlük dosya takibini yoğun biçimde yürütürken diğeri yazılımı daha sınırlı kullanıyor olabilir. Farklılıkları baştan not etmek, görüşmeden çıkan sonuçları doğru kapsamda yorumlamayı kolaylaştırır.

İlk referans, ekibin günlük kullanımını anlamak için uygun olabilir. İkinci referans, geçiş deneyimi veya daha farklı bir ekip yapısı hakkında tamamlayıcı bilgi sağlayabilir. Seçiminizi yalnızca “en başarılı kullanıcı” anlatısına göre yapmayın; birden fazla iş akışının sizin karar ölçütlerinize nasıl karşılık geldiğine bakın.

Örnek senaryo: Orta ölçekli bir büro, sağlayıcının önerdiği referansın ekip yapısının kendisinden farklı olduğunu fark eder. Görüşmeyi iptal etmek yerine hangi işlerin benzer olduğunu belirler; örneğin, dosya takibi ve görev paylaşımı deneyimini sorar. Ardından farklı ölçekte bir büroyla görüşerek ekip uyumu konusunda ek bilgi toplar. Böylece tek örneği kendi bürosuna doğrudan uyarlamak yerine, her yanıtın sınırını korur.

Görüşme talebinde gizli veya hassas dosya bilgilerini istemeyin. Referans kullanıcısı olayları kendi deneyimi üzerinden, büroya ya da müvekkile ait tanımlayıcı ayrıntıları paylaşmadan anlatabilir. Siz de görüşme notlarını, karar vermek için gereken kapsamla sınırlı tutun.

3. İlk görüşmede kullanım süreci ve benimseme hakkında ne sorulmalı?

Yazılımı kimlerin hangi işlerde kullandığı

Önce sistemin büroda gerçekten kimler tarafından ve hangi işler için kullanıldığını öğrenin. Kullanım yaygınlığı, yalnızca lisans veya kullanıcı sayısıyla anlaşılmaz; ekibin yazılıma hangi işlerde başvurduğu ve bazı işleri dışarıda bırakıp bırakmadığı da önemlidir. Soruları belirli bir özelliği övdürmek yerine işin nasıl yürüdüğünü anlattıracak biçimde kurun.

• Yazılımı büroda hangi roller kullanıyor?
• Her ekip üyesi sistemi benzer sıklıkta mı kullanıyor, yoksa kullanım belirli kişilerde mi yoğunlaşıyor?
• Sisteme en sık hangi günlük işler için başvuruyorsunuz?
• Hangi işler hâlâ başka araçlarla veya farklı bir yöntemle yürütülüyor?
• Ekip içinde bilgi paylaşımında veya iş devrinde kullanım şekli nasıl?

Bu soruların ardından yakın zamanda yaşanmış bir günü ya da işi örnek vermesini isteyin. “Ekip kullanıyor” yanıtı, herkesin her işi sistem üzerinden yürüttüğü anlamına gelmeyebilir. Görüşülen kişinin kendi rolünü ve doğrudan gözlemlediği süreçleri ayrıca not edin.

İlk beklentiler ve sonradan değişen iş akışları

Kurulum veya geçiş öncesindeki beklentiyle bugünkü kullanım arasında fark olup olmadığını sorun. “Beklediğiniz gibi oldu mu?” sorusunun yanıtı genel kalabilir. Bunun yerine “Başlangıçta hangi işi kolaylaştırmasını bekliyordunuz; şimdi bu işi nasıl yürütüyorsunuz?” diye sorun. Böylece yazılımın günlük düzene nasıl girdiğini ve hangi alışkanlıkların değiştiğini öğrenebilirsiniz.

• İlk dönemde ekibin uyum sağlamasını kolaylaştıran ne oldu?
• Hangi iş akışını beklediğinizden farklı biçimde düzenlemeniz gerekti?
• Kullanım alışkanlıkları zaman içinde nasıl değişti?
• Geçiş sırasında hangi işlerin devam etmesi veya yeniden düzenlenmesi gerekti?
• Bugün başlangıçta önemli görünen ama artık öncelikli olmayan bir ihtiyaç var mı?

Özellikle bir kişinin sistemi sahiplenmesiyle bütün ekibin kullanması arasındaki farkı açın. Ekipte kullanımın yayılmasını destekleyen bir rutin veya sorumlu kişi olup olmadığını öğrenin. Yanıtları kendi büronuzda benzer bir sorumluluğun bulunup bulunmadığıyla karşılaştırın; aynı koşullar yoksa benzer sonucun ortaya çıkacağını varsaymayın.

Ekibin kullanmadığı veya zorlandığı alanlar

Kullanılmayan alanlar, her zaman ürün sorunu anlamına gelmez. İş akışına uymama, ekip eğitimi ihtiyacı, alışkanlık veya büroda o işe duyulan ihtiyacın düşük olması gibi farklı nedenler bulunabilir. “Sistemde kullanmadığınız bir bölüm var mı?” diye sormakla yetinmeyin; kullanılmama nedenini ve bunun iş üzerindeki etkisini de sorun.

Bir ekip üyesinin zorlandığı bir işi anlatmasını isteyin. Ne yapmaya çalıştığını, nerede takıldığını ve sonrasında nasıl ilerlediğini öğrenin. Aynı güçlüğün sizin ekibinizin kullanımını etkileyip etkilemeyeceğini değerlendirin. İhtiyaç duyduğunuz iş akışına dair yanıt eksik kalırsa, bu noktayı sağlayıcıdan uygulamalı olarak göstermesini isteyin. Farklı ekip ve yetki ihtiyaçlarını değerlendirirken ekip ve güvenlik başlıklarını kendi kullanım senaryonuzla birlikte inceleyebilirsiniz.

4. Veri kaybı ve güvenlik deneyimi nasıl sorgulanmalı?

Kesinti, arıza veya veri kaybı yaşanıp yaşanmadığını açık uçlu sormak

Güvenlik konusunda “Verileriniz güvende mi?” gibi bir soru, çoğunlukla kısa ve genel bir güvenceyle yanıtlanır. Referans görüşmesinde, kullanıcının bildiği olayları ve bunların bürodaki etkisini öğrenmeye odaklanın. Bir sorun yaşanıp yaşanmadığını sorun; yanıt olumluysa olayın ne zaman yaşandığını, hangi işe etkisi olduğunu ve büronun nasıl ilerlediğini açın.

1. Önce açık sorun: “Kullanım sürecinizde erişim, arıza veya veriyle ilgili bir sorun yaşadınız mı?”
2. Olayı sınırlandırın: “Bu hangi iş akışını etkiledi ve ekip o sırada ne yapıyordu?”
3. Müdahaleyi öğrenin: “Büro sorunu nasıl fark etti; sağlayıcıya nasıl iletti?”
4. Sonucu sorun: “İşler ne zaman ve nasıl sürdürülebildi; sonrasında ne değişti?”
5. Kapsamı netleştirin: “Bu, sizin doğrudan yaşadığınız bir olay mı, yoksa duyduğunuz bir durum mu?”

Yanıt “Hiç sorun yaşamadık” ise bunu olumlu veri olarak not edebilirsiniz, fakat tüm olası durumların sınandığı şeklinde yorumlamayın. Görüşülen kişi sorun yaşamamış olabilir veya konuya dair sınırlı görünürlüğe sahip olabilir. Hangi dönemi ve kullanım kapsamını bildiğini sorarak yanıtın sınırını belirleyin.

Yedekleme ve geri dönüş sürecinin nasıl anlatıldığını netleştirmek

Yedekleme konusunda soyut güvence yerine bir sorun çıktığında ne yapıldığını anlamaya çalışın. “Geri yükleme denediniz mi?” ve “Bu süreçte büronun hangi işlemleri yapması gerekti?” gibi sorular, günlük deneyim ile genel beklentiyi ayırmaya yardımcı olur. Referans kullanıcısının teknik ayrıntıları bilmiyor olması da mümkündür; bilmediği bir noktayı tahmin ederek yanıtlamasını istemeyin.

Şunları netleştirin:

• Referans kullanıcı, yedekleme ve geri dönüş sürecini doğrudan biliyor mu?
• Gerçek bir geri dönüş veya benzer bir işlem yaşandı mı; yaşandıysa hangi kapsamda?
• Büroya düşen kontrol veya takip işleri nelerdi?
• Sürecin tamamlandığını kullanıcı nasıl anladı?
• Yanıt, kullanıcının deneyimi mi yoksa sağlayıcıdan duyduğu açıklama mı?

Görüşme, teknik tasarımın veya sözleşme kapsamının doğrulanması yerine geçmez. Kullanım deneyiminden öğrendiğiniz soruları sağlayıcıya yöneltin ve ilgili yanıtı yazılı ürün bilgisiyle karşılaştırın. Somut bir olay anlatılmadıysa notunuza “teyit edilmedi” yazın; “yedekleme sorunu yok” gibi daha geniş bir sonuca çevirmeyin.

Erişim yetkileri ve ekipten ayrılan kullanıcılarla ilgili deneyim

Güvenlik yalnızca bir kesinti veya veri kaybı olayı üzerinden değerlendirilmez. Ekipteki kişilerin sisteme nasıl eriştiği, görev değişikliğinde veya ekipten ayrılma durumunda sürecin nasıl yürüdüğü de günlük kullanım deneyiminin parçasıdır. Referans büroya, bu tür bir değişikliği yaşayıp yaşamadığını ve sürecin kim tarafından nasıl yönetildiğini sorun.

“Erişim yetkilerini kim takip ediyor?” ve “Bir ekip üyesinin rolü değiştiğinde neleri gözden geçiriyorsunuz?” soruları, sorumlulukların netliğini anlamaya yardımcı olur. Yanıtı, sizin büronuzda bu işi kimin yürüteceğiyle karşılaştırın. Görüşülen kişi bu sürece katılmamışsa, bilgi eksikliğini de kaydedin.

Bu görüşme, belirli bir koruma düzeyinin yeterli olduğunu veya bir olayın hukuki sonucunu kanıtlamaz. Amaç, kullanıcının yaşadığı süreci anlamak ve sağlayıcıdan sorulacak somut soruları belirlemektir. Görseldeki akışın işaret ettiği gibi, deneyimden çıkan soruyu ayrıca teyit aşamasına taşıyın.

5. Destek, güncelleme ve geçiş deneyimini hangi örneklerle ölçmeli?

Son destek talebinin baştan sona izini sürmek

“Destekten memnun musunuz?” sorusu, yararlı bir başlangıç olabilir; ancak tek başına destek sürecini ölçmez. Son destek talebini baştan sona anlattırın: sorun nasıl ortaya çıktı, kim iletti, hangi bilgiler istendi, büro ne zaman yanıt aldı ve iş nasıl devam etti? Böylece “iyi destek” gibi genel bir değerlendirme, gerçek bir sürece bağlanır.

• En son hangi konuda destek istediniz?
• Talep, günlük işinizin hangi bölümünü etkiliyordu?
• İlk yanıtı nasıl aldınız ve sonrasında hangi adımlar izlendi?
• Çözüm için bürodan hangi bilgi veya işlem istendi?
• Sorun çözülene kadar ekip işini nasıl sürdürdü?
• Bugün aynı durumla karşılaşsanız farklı ne yapardınız?

Yanıt süresi hakkında belirli bir sayı veriliyorsa, bunun tek bir olaya mı yoksa düzenli gözleme mi dayandığını sorun. Bir olayın hızlı sonuçlanması, her talebin aynı şekilde ele alınacağını göstermez. Buna karşılık, belirli bir talepte yaşanan gecikme de tüm destek deneyimini tek başına açıklamayabilir. Olayın etkisini ve tekrarlanıp tekrarlanmadığını kaydedin.

Güncelleme sırasında ekip ve iş akışına etkisini sormak

Güncelleme deneyimini, yalnızca “sorunsuz muydu?” diye sormak yerine iş akışı üzerinden açın. Güncelleme sırasında ekip bilgilendirildi mi, hangi işlerin yürütüldüğünü etkiledi mi ve bir aksaklık olursa ekip nasıl ilerledi? Referans kullanıcısı teknik ayrıntıları bilmiyorsa, gözlemleyebildiği kısmı anlatmasını isteyin.

Büronun işini etkileyen bir değişiklik olduysa, etkiyi somutlaştırın: Kimler çalışıyordu, hangi süreç etkilendi ve ekip nasıl devam etti? Görüşülen kişi güncellemeyi fark etmediyse bu da kayda değer bir yanıt olabilir; ancak teknik süreç hakkında doğrudan bilgi sahibi olduğu anlamına gelmez. Sağlayıcının kontrolündeki işlemle büronun hazırlık veya bilgilendirme sorumluluğunu ayrı ayrı sorun.

Uygulama sırasındaki deneyimi, sizin yoğun iş dönemleriniz ve çalışma düzeninizle karşılaştırın. Aynı etki düzeyinin oluşacağını varsaymak yerine, hangi işlerin kritik olduğunu belirleyin ve sağlayıcıdan bu senaryoyu açıklamasını isteyin.

Veri aktarımı ve eski düzene dönüş konusunu açmak

Geçiş deneyimi, yalnızca kurulumun ne kadar sürdüğüyle ölçülmez. Hangi verilerin aktarıldığı, aktarımın nasıl kontrol edildiği, ekibin eski yöntemle paralel çalışıp çalışmadığı ve geçiş sırasında hangi işlerin büro tarafından yürütüldüğü önemlidir. Referans kullanıcısından “geçiş kolaydı” demesinin ötesinde adımları anlatmasını isteyin.

“Geçiş öncesinde hangi bilgileri hazırladınız?”, “Aktarılan kayıtları nasıl kontrol ettiniz?” ve “Eksik veya beklediğinizden farklı bir şey oldu mu?” soruları, sorumluluk sınırlarını açığa çıkarır. Eski düzene dönüş ihtimali büro için önemliyse, bu konunun nasıl ele alındığını ve hangi seçeneklerin konuşulduğunu sorun. Referans kullanıcısının böyle bir ihtiyacı hiç yaşamamış olması mümkündür; bu durumda deneyim yokluğunu net biçimde not edin.

Soruları sağlayıcıya yöneltirken, referansın anlattığı süreçle sizin geçiş planınızın aynı olup olmadığını kontrol edin. Referans görüşmesindeki bir çözümü kendi büronuz için varsaymayın; aktarım kapsamı ve büronun yapacağı işler sağlayıcıdan ayrıca açıklanmalıdır.

6. Olumlu ve olumsuz yanıtları nasıl takip sorularıyla açmalı?

Yanıtı somutlaştıran takip soruları

Olumlu ve olumsuz yanıtların ikisi de, arkasında bir örnek olduğunda kararınıza katkı sağlar. “Çok memnunuz” veya “Geçiş zordu” ifadelerini tartışmaya açmak için karşı çıkmanız gerekmez. Nazikçe, yakın zamandaki bir olayı anlatmasını ve kendi rolünü belirtmesini isteyin.

Görüşme sırasında sorularınızı takip edilebilir bir sırada tutun: olay neydi, ne zaman yaşandı, kimi etkiledi, nasıl çözüldü ve bugün ne farklı? Her yanıt için bu beş sorunun hepsini sormak gerekmez. Kararınızı etkileyen belirsiz noktaları açmak için uygun olanları seçin.

Kaçamak veya aşırı genelleyici yanıtları not etmek

Bir yanıt somut örnek içermiyorsa, bunu görüşülen kişinin niyetine dair yorum yapmadan kaydedin. “Yanıt geneldi; olay örneği alınamadı” notu, “büro konuyu gizledi” gibi bir çıkarımdan daha güvenilirdir. Kısa görüşme süresi veya kişinin deneyime doğrudan katılmaması, ayrıntı verememesinin nedeni olabilir.

Aşağıdaki ayrımları notlarınızda koruyun:

• Doğrudan deneyim: Kişi olayı gördü veya sürecin içindeydi.
• Dolaylı bilgi: Kişi olayı başka ekip üyelerinden duydu.
• Genel görüş: Deneyim anlatmadan memnuniyet veya endişe ifade etti.
• Belirsizlik: Zaman, etki, kapsam ya da çözüm açıklanmadı.
• Teyit ihtiyacı: Sağlayıcıdan veya yazılı bilgiden kontrol edilecek konu var.

Bu ayrım, olumlu yanıtı kanıtlanmış sonuç; olumsuz yanıtı da ürünün genel niteliği gibi kaydetmenizi önler. Yanıtların nasıl karşılaştırılacağına ilişkin örnek görseli, genel sözle yaşanmış deneyim arasındaki farkı hatırlamak için kullanabilirsiniz.

Referans kullanıcısına sağlayıcı olmadan konuşma seçeneği sunmak

Sağlayıcı temsilcisinin görüşmeye katılması, bazı kullanıcıların rahatça konuşmasını zorlaştırabilir. Görüşmeyi mümkünse referans kullanıcısıyla doğrudan yapma seçeneğini önceden sorun. Temsilcinin katılması gerekiyorsa, deneyim sorularına kimin yanıt verdiğini ve yanıtın hangi bilgiye dayandığını not edin.

Görüşmenin başında amacınızı ve zaman sınırınızı açıklayın. Hassas bilgileri veya başka bir büroya ait dosya ayrıntılarını istemediğinizi belirtin. Referans kullanıcısına cevap vermek istemediği soruları geçebileceğini söyleyin; bu yaklaşım hem görüşmeyi rahatlatır hem de gereksiz bilgi paylaşımını önler.

Kopyalanabilir görüşme notu şablonu

Görüşme biter bitmez aşağıdaki alanları doldurun. Bu kısa not, sonraki referansları aynı düzende karşılaştırmanıza yardımcı olur.

• Büronun bizimle benzer yönleri:
• Farklı yönleri ve görüşmenin sınırı:
• Görüşülen kişinin rolü ve doğrudan kullandığı işler:
• Anlatılan son destek, geçiş veya kullanım olayı:
• Olayın büroya ve ekibe etkisi:
• Büronun yaptığı işler / sağlayıcıdan beklenen işler:
• Olumlu deneyim ve dayandığı örnek:
• Zorluk veya kullanılmayan alan:
• Genel görüş olarak kalan yanıtlar:
• Sağlayıcıya sorulacak ve ayrıca teyit edilecekler:
• Kararımızı etkileyebilecek açık soru:

7. Referans yanıtlarını seçenekler arasında nasıl karşılaştırmalı?

Görüşme notu için ortak değerlendirme alanları

Farklı yazılımlar için görüşmeler yaparken aynı soru setini ve not başlıklarını kullanın. Bir büronun etkileyici anlatımı veya görüşülen kişinin kişisel memnuniyeti, tek başına seçenekleri karşılaştırmaya yetmez. Yanıtı hangi büro bağlamında aldığınızı, anlatılan olayın ne kadar somut olduğunu ve sizin karar ölçütlerinizle nasıl ilişkili olduğunu birlikte değerlendirin.

Karar notunda her konu için şu alanlara yer verin:

Puanlama kullanacaksanız, puanın yanına mutlaka kısa gerekçe ekleyin. Örneğin, “geçiş deneyimi olumlu” notunun yanına büronun geçiş öncesinde hangi hazırlıkları yaptığını yazın. Aksi halde birkaç gün sonra puanın hangi olaya dayandığını hatırlamak zorlaşır. Bir başlık için yeterli bilgi yoksa, boşluğu olumlu ya da olumsuz yorumla doldurmayın; “bilgi alınamadı” veya “teyit bekliyor” olarak işaretleyin.

Çelişen yanıtları demo ve yazılı açıklamayla teyit etmek

İki referans farklı deneyimler anlattığında, birini doğru diğerini yanlış kabul ederek başlamayın. Kullanım süresi, ekip rolleri, iş akışı veya görüşülen kişinin bilgisi farklı olabilir. Önce yanıtların hangi koşullarda verildiğini karşılaştırın. Sonra fark sizin kararınızı etkiliyorsa, soruyu sağlayıcıya belirli bir senaryo üzerinden yöneltin.

Örneğin, bir referans belli bir geçiş adımının kolay olduğunu söylerken diğeri ek iş yükü yaşadığını anlatabilir. Her iki büroya hangi verilerin aktarıldığını, ekibin ne kadar hazırlık yaptığını ve işlerin nasıl kontrol edildiğini sorun. Ardından kendi büronuzun ihtiyaç duyduğu kapsamı sağlayıcıya açıklatın. Bir başlık önemliyse, yalnızca sözlü yanıtla kalmayıp yazılı ürün bilgisini de inceleyin.

Popülerlik, tekil memnuniyet beyanı veya bir referansın güçlü tavsiyesi karar ölçütü olarak tek başına yeterli değildir. Karar, sizin iş akışınız ve risk önceliklerinizle ilişkili kanıtlara dayanmalıdır. Ürün kapsamını ayrıca gözden geçirmek için hukuk bürosu yönetim programı rehberini kullanabilir, önemli gördüğünüz başlıkları kendi kontrol listenize ekleyebilirsiniz.

8. Referans kontrolünden sonra yazılım seçimi için hangi adımlar kalır?

Referans yanıtı ile sağlayıcı beyanını ayrı kaydetmek

Referans görüşmesi, karar sürecinin bir girdisidir; ürünün kapsamını tek başına doğrulamaz. Karar notunuzda kullanıcı deneyimini, sağlayıcının açıklamasını ve sizin çıkarımınızı ayrı alanlarda tutun. Örneğin, referansın “şu iş akışında şu adımı uyguladık” demesi kullanıcı deneyimidir; sağlayıcının bu işin ürün içinde nasıl karşılandığını açıklaması ise ayrıca kontrol edilmesi gereken ürün bilgisidir.

Her önemli konu için şu üç soruyu sorun:

1. Referans kullanıcısı hangi olayı veya iş akışını doğrudan anlattı?
2. Sağlayıcı bu ihtiyacın ürün kapsamındaki karşılığını nasıl açıklıyor?
3. Büro ekibimiz bu süreci yürütmek için neye ihtiyaç duyacak?

Yanıtlardan biri eksikse, bunu karar aşamasında görünür tutun. Referansın yaşamadığı bir durum için olumlu veya olumsuz sonuç çıkarmayın. Sağlayıcı açıklamasını da gerçek kullanım deneyimiyle aynı tür kanıt gibi değerlendirmeyin.

Büroya uygunluğu demo ve kapsam kontrolüyle teyit etmek

Referansların anlattığı bir iş akışı sizin için kritikse, uygulamalı gösterimde aynı senaryoyu adım adım inceleyin. Demo sırasında hangi rolün ne yaptığını, sürecin hangi noktada tamamlandığını ve büro ekibinin hangi hazırlıkları üstlendiğini sorun. Böylece referans görüşmesinde öğrendiğiniz deneyimi kendi ihtiyacınızla eşleştirebilirsiniz. Demo için hazırlayacağınız soruların yanına, referanslardan çıkan açık noktaları da ekleyin.

Ürün özelliklerini güncel ürün bilgisi üzerinden kontrol edin; referans kullanıcısının geçmişte kullandığı kapsamın bugünle aynı olduğunu varsaymayın. Özellikle erişim, ekip düzeni, müvekkil iletişimi ve güncelleme gibi konularda sağlayıcıdan sizin senaryonuza özgü açıklama isteyin. Örneğin, müvekkil portalı sizin için önemliyse portalın ve mobil kullanımın kapsamını ayrıca inceleyin. Bu bağlantı, referans görüşmesinin yerine geçmez; ürün kapsamını kendi ihtiyacınızla karşılaştırmak için ek bir kaynaktır.

Referans görüşmelerinden sonra AvukatSiteleri.net’i inceliyorsanız, ürüne ilişkin değerlendirmeyi yalnızca doğrulanmış ürün bilgisiyle sınırlayın: büroya özel bağımsız kurulumda her büronun verisi kendi bağımsız kurulumunda tutulur; yazılım güncellemeleri platform tarafından yapılır. Bu bilgileri, referans büroların deneyiminden ayrı tutarak kendi sorularınızla karşılaştırın.

Özellik sayfasını incelemek isteyenler tüm özellikleri görebilir; kendi bürosuna uygunluğu uygulamalı değerlendirmek isteyenler ise demo talep edebilir. Demo öncesinde referanslardan çıkan soruları notlarınıza ekleyin. Aşağıdaki kontrol listesi de görüşme öncesi hedef, karşılaştırılabilirlik ve teyit edilecek noktaları bir arada tutmanıza yardımcı olur.