Hukuk Yazılımı Demosunda Sorulması Gereken Sorular

Bir hukuk yazılımı demosunda sorulması gereken sorular, sağlayıcının özellik listesini dinlemekten ibaret değildir. Önemli olan, yazılımın sizin büronuzdaki iş akışını nasıl karşıladığını ve vaat edilen işlevin hangi koşullarda çalıştığını görebilmektir. Bunun için demo öncesinde birkaç senaryo seçin; sağlayıcıdan bu senaryoları baştan sona göstermesini isteyin.

Aşağıdaki hukuk bürosu yazılımı demo kontrol listesi; dosya takibi, veri güvenliği, ekip yetkileri, UYAP aktarımı, güncellemeler ve sağlayıcıdan ayrılma gibi karar anlarına odaklanır. Demo sırasında gerçek müvekkil verisi kullanmak yerine, benzer yapıda örnek veya anonimleştirilmiş kayıtlarla ilerleyin. Yanıtları ve gösterilen adımları not edin; böylece belleğe veya genel izlenime dayalı karar vermek zorunda kalmazsınız.

Demo öncesi hangi büro iş akışlarını ve riskleri belirlemelisiniz?

Demonun verimli geçmesi için önce bürodaki tekrar eden işleri ve aksayan noktaları belirleyin. Sağlayıcının hazırladığı standart sunum, ürünün genel çerçevesini anlatabilir; ancak sizin için önemli olan, dosyanın açılmasından görev devrine ve güncel durumun bulunmasına kadar günlük işin nasıl yürüdüğüdür. Üç senaryo genellikle derinlemesine test için yeterlidir. Her senaryonun farklı bir iş akışını veya riski göstermesine dikkat edin.

En çok tekrar eden üç işi seçin

Büroda en sık yaşanan üç işi belirlerken yalnızca “en çok zaman alan” işleri değil, hata veya bilgi kaybı ihtimali yaratan adımları da düşünün. Örneğin bir dosyanın son durumunu bulmak, belgeyi dosyaya eklemek ve bir işi ekip arkadaşına devretmek farklı süreçlerdir. Her biri ayrı bir demo senaryosu olabilir. Fazla senaryo seçerseniz her birini yüzeysel geçme riski doğar.

Her iş için şu soruları not edin:

• İş hangi olayla başlıyor, hangi sonuçla tamamlanıyor?
• Sürece kimler katılıyor; hangi noktada devir yapılıyor?
• Bilgi şu anda nerede tutuluyor veya aranıyor?
• En çok hangi adım gecikiyor ya da tekrar ediliyor?
• Demo sonunda hangi gözlemlenebilir sonuç size yeterli olur?

Her iş için beklenen sonucu ve katılımcıları yazın

“Dosya takibi kolay mı?” ölçülebilir bir demo talebi değildir. Bunun yerine, “Bir dosyayı açın, son eklenen belgeyi bulun, sorumlu kişiyi gösterin ve bekleyen işi başka bir kullanıcıya atayın” gibi gözlemlenebilir adımlar belirleyin. Böylece sağlayıcıdan yalnızca olumlu bir yanıt değil, canlı bir gösterim talep edersiniz.

Demonun büro düzeninizi bilen kişilerle yapılması da önemlidir. İş akışını yöneten avukat, günlük kayıtları yapan ekip üyesi ve erişim düzeninden sorumlu kişi farklı noktaları fark edebilir. Başlamadan önce senaryoları ve başarı ölçütlerini sağlayıcıya gönderin; gerekiyorsa ekip, yetki ve güvenlik başlıklarını ayrıca test edeceğinizi belirtin. Ölçütleri önceden paylaşmak, sunumun yalnızca sağlayıcının tercih ettiği özelliklere yönelmesini azaltabilir.

Konunun bütününü hukuk bürosu yönetim programı: kapsamlı rehber rehberinde bulabilirsiniz.

Bir dosyanın günlük takibini gerçek senaryoyla nasıl denersiniz?

Dosya takibini değerlendirirken tek bir ekranın düzenine değil, işin başından sonuna nasıl ilerlediğine bakın. Yeni kayıt oluşturma, belge ekleme, dosyada arama, görev atama ve dosyanın son durumunu anlama adımlarını aynı senaryoda izleyin. Böylece bilgilerin farklı ekranlarda, farklı kullanıcıların katkısıyla nasıl güncellendiğini görebilirsiniz.

Yeni dosyadan görev devrine kadar izleyin

Örnek senaryo: Bir dosyada belge bulma, görev atama ve güncel durumu görme adımlarını demo sırasında baştan sona izleyin. Sağlayıcıdan önce örnek dosyanın nasıl oluşturulduğunu veya mevcut kaydın nasıl açıldığını göstermesini isteyin. Ardından belirli bir belgeyi bulun, dosyanın güncel durumunu açın ve bir sonraki işi ekipteki başka bir kullanıcıya atayın. Her adımda işlemi kimin yaptığını ve bilginin hangi alanda göründüğünü sorun.

İşin yalnızca başarılı olduğu anı değil, yanlış veya eksik bilgi olduğunda ne yapılacağını da inceleyin. Bir belge yanlış dosyaya eklenirse düzeltme adımı nedir? Görev atanan kişi değişirse sorumluluk nasıl güncellenir? Arama beklediğiniz belgeyi bulmazsa alternatif arama veya filtreleme yolları var mı? Bunları sağlayıcının açıklamasıyla bırakmayın; mümkün olanları ekranda göstermesini isteyin.

Bilgiyi kimin güncellediğini ve kaydın geçmişini sorun

Dosya içindeki bilgi kendiliğinden güncel kalmayabilir. Bu nedenle sağlayıcıya, hangi bilgilerin kullanıcı tarafından girildiğini, hangi bilgilerin başka bir kaynaktan geldiğini ve bir kaydı kimin değiştirebildiğini sorun. “Sistem takip ediyor” gibi genel bir yanıt yerine, belirli bir değişiklik yapıldığında nerede ve nasıl göründüğünü görmek isteyin.

Bir kaydın geçmişi veya sorumlusu görünmüyorsa bu, iş akışınız için önemli bir belirsizlik olabilir. Değişiklik geçmişinin hangi ayrıntıları gösterdiğini, geçmiş kayıtlara kimlerin erişebildiğini ve eski bilginin nasıl ayırt edildiğini sorun. Demo ekranında göremediğiniz bir işlev varsa, kapsamını ve hangi koşullarda kullanılabildiğini sonradan yazılı olarak teyit edin.

Veri güvenliği, yedekleme ve geri yükleme için hangi kanıtları istemelisiniz?

“Güvenli”, “yedekli” veya “korumalı” gibi sözcükler tek başına uygulamayı anlamaya yetmez. Sağlayıcıdan bu ifadelerin kendi hizmetinde ne anlama geldiğini açıklamasını isteyin. Verinin nerede ve hangi düzen içinde tutulduğu, erişimin kimlerce yönetildiği, yedeklerin kapsamı ve geri yükleme adımları ayrı ayrı konuşulmalıdır. Büronuzun önceliğine göre hangi cevapların ek teyit gerektirdiğini de belirleyin.

Veri saklama ve yedekleme düzenini somutlaştırın

Aşağıdaki tabloyu sağlayıcıya yönelteceğiniz sorular için kullanabilirsiniz. Cevapların yanında, canlı gösterim veya yazılı açıklama gerekip gerekmediğini de işaretleyin.

“Düzenli yedek alıyoruz” yanıtını duyduğunuzda, bunun hangi verileri kapsadığını ve yedekten geri dönme sürecinin nasıl işlediğini sorun. Yedekleme ile geri yükleme aynı şey değildir. Yedeklerin bulunması, ihtiyaç halinde nasıl kullanılacağının da açıklandığı anlamına gelmez.

Geri yükleme ve arıza senaryosunu test edin

Sağlayıcıdan geri yükleme adımlarını canlı göstermesini isteyin. Demo ortamında bunu yapamıyorsa, hangi koşullarda yapılabileceğini, sürecin kim tarafından yürütüldüğünü ve bürodan hangi bilgilerin beklendiğini netleştirin. Örnek senaryo: Yedek geri yükleme gösterimi yapılamıyorsa, sağlayıcıdan bu sürecin kapsamını ve teyit edilebilir açıklamasını isteyin. Sadece “gerektiğinde halledilir” cevabını not etmek yerine, açık kalan noktaları yazılı teyit listesine alın.

Arıza veya zararlı yazılım kaynaklı erişim sorunu gibi durumlarda hizmetin nasıl sürdürüleceğini de sorun. Bu tür senaryolarda neyin sağlayıcı, neyin büro sorumluluğunda olduğunu ayırmasını isteyin. Güvenlik veya yedekleme konusunda teknik ayrıntılar size açık değilse, açıklamanın yazılı ve anlaşılır olmasını talep edin. Sunumda gösterilmeyen veya kapsamı netleşmeyen bir noktayı, değerlendirme tablosunda “gösterildi” olarak işaretlemeyin.

Ekip rolleri ve erişim yetkileri büro düzeninize uyuyor mu?

Ekip yetkilerini tek bir yönetici hesabıyla değerlendirmek yanıltıcı olabilir. Yönetici, avukat ve idari personelin aynı dosyada hangi bilgilere eriştiğini, hangi işlemleri yapabildiğini ve kendi sorumluluk alanında ne gördüğünü karşılaştırın. Testi büronuzdaki gerçek rol ayrımına göre kurun; böylece yalnızca ayar ekranlarını değil, günlük kullanımdaki sonucu da görürsünüz.

Farklı rollerle aynı dosyayı açıp karşılaştırın

Sağlayıcıdan farklı örnek kullanıcılarla aynı dosyayı açmasını isteyin. Önce her rolün dosyayı bulup hangi bilgileri görebildiğini gözlemleyin. Ardından bir kullanıcının belge ekleme, görev atama veya kayıt değiştirme gibi işlemleri yapıp yapamadığını sınayın. Bir işlem mümkün değilse, kullanıcının ne gördüğünü ve erişim engelinin nasıl anlaşıldığını sorun.

Test sırasında yalnızca “bu rol sınırlıdır” açıklamasını yeterli görmeyin. Hangi işlemin hangi ayarla sınırlandığını ekranda göstermelerini isteyin. Bir kullanıcının görüntüleyebildiği bilgiyle değiştirebildiği bilgi arasında ayrım olup olmadığını kontrol edin. Rol adları büroda kullandığınız unvanlarla uyuşmasa bile, önemli olan her role verilen yetkinin pratikte sizin ihtiyacınıza karşılık gelmesidir.

Yetki verme, geri alma ve değişiklik takibini gösterin

Yeni bir kullanıcıya erişim verme ve mevcut bir kullanıcının yetkisini değiştirme adımlarını demo sırasında izleyin. Hangi kişinin bu değişiklikleri yapabildiğini, değişikliğin nasıl kaydedildiğini ve sonradan nasıl kontrol edilebildiğini sorun. Personelin bürodan ayrılması veya görev değiştirmesi gibi bir durumda erişimin nasıl ele alınacağını da senaryoya ekleyin.

Bu test için şu adımları sırayla isteyebilirsiniz:

1. Örnek kullanıcıya belirli bir rol verin.
2. Kullanıcının erişebildiği dosya ve işlemleri açın.
3. Rolün bir yetkisini değiştirin ve sonucu yeniden kontrol edin.
4. Yetkiyi geri alın veya kullanıcı erişiminin nasıl kapatıldığını gösterin.
5. Bu değişikliklerin geçmişte nerede görülebildiğini sorun.

Ekranda görünen erişimle, sağlayıcının tarif ettiği ayar arasında fark varsa not alın. Rol yönetimi beklentiniz kritikse, hangi rollerin hangi kayıtları görebileceğini sağlayıcıdan yazılı biçimde açıklamasını isteyin.

UYAP aktarımı ve yazılım güncellemelerinde sınırlar nasıl doğrulanır?

Bir aktarım özelliğini değerlendirirken “entegrasyon var mı?” sorusu yerine, hangi bilginin nereden geldiğini, hangi koşulda aktarıldığını ve hangi işlemleri kapsamadığını sorun. Aktarılan verinin kapsamı ile sistemde sonradan yapılan diğer işlemleri birbirinden ayırın. Güncellemelerde de değişikliğin kim tarafından, nasıl dağıtıldığını ve büro kullanımına olası etkilerin nasıl bildirildiğini öğrenin.

Hangi bilginin, hangi koşulda aktarıldığını sorun

Sağlayıcıdan demo sırasında aktarımın başlangıç koşulunu, kapsamını ve kullanıcı tarafından yapılması gereken adımları açıklamasını isteyin. Hangi bilgilerin geldiğini örnek üzerinden gösterin; aktarımın tüm dosya ayrıntılarını kapsadığını varsaymayın. Aktarılan bilginin okunabilir veya değiştirilebilir olup olmadığını ve aktarım sonrası hangi kontrollerin kullanıcı tarafından yapılması gerektiğini sorun.

UYAP aktarımını, resmî bir işlemin yazılım tarafından yapıldığı iddiasıyla karıştırmayın. Gösterilen şeyin veri aktarımı mı, başka bir kullanıcı işlemi mi olduğunu sağlayıcıdan ayrı ayrı açıklamasını isteyin. Ürünün UYAP aktarımıyla ilgili kapsamını incelerken de demo sırasında gördüğünüz akışla karşılaştırın.

Gecikme, hata ve güncelleme sürecini konuşun

Aktarım anlık değilse ya da başarısız olursa kullanıcının ne gördüğünü sorun. Son aktarımın zamanı, olası hata bildirimi ve yeniden deneme adımları hakkında açıklama isteyin. Belirli bir senaryoda gösterilemeyen bir durum için “her zaman çalışır” türünde genel bir ifade yerine, sınırların ve istisnaların açıkça yazılmasını talep edin.

Güncellemeler konusunda hangi sürüm değişikliklerinin büroya ulaştığını, dağıtımın nasıl yönetildiğini ve sorun yaşanırsa kiminle iletişim kurulacağını öğrenin. Güncellemeyi kimin yaptığı kadar, büro tarafında ek işlem gerekip gerekmediği de önemlidir. Güncelleme sırasında oluşabilecek kesinti veya uyumluluk sorularını sağlayıcıya yöneltin; yanıtı, ürünün çalışma düzenine dair gözleminizden ayrı kaydedin. Böylece gösterilmiş işlevle açıklanmış süreç birbirine karışmaz.

Raporlama ve yapay zekâ çıktısını büro kontrolüyle nasıl değerlendirirsiniz?

Rapor veya yapay zekâ çıktısını, doğru ya da tamamlanmış kabul edilecek bir sonuç gibi değil, incelenecek bir ürün çıktısı gibi test edin. Sağlayıcıdan örnek bir belge veya girdi üzerinden çıktının nasıl oluştuğunu göstermesini isteyin. Hangi kaynaklara dayandığını, hangi bilgileri içermediğini ve son kontrolün kim tarafından yapılacağını anlamaya çalışın.

Çıktının hangi girdi ve belgelere dayandığını sorun

Örnek senaryo: Anonimleştirilmiş veya demo için hazırlanmış bir belge üzerinden rapor oluşturulmasını isteyin. Ardından çıktıda yer alan bilgilerin hangi belgeden veya girdiden geldiğini sorun. Sağlayıcı kaynakla çıktı arasındaki ilişkiyi göstermiyorsa, hangi dayanak bilgisinin kullanıcıya sunulabildiğini ve hangi noktaların açıklanamadığını not edin.

Çıktıda eksik veya hatalı bir bilgi fark ederseniz, bunu nasıl kontrol edeceğinizi sorun. Kaynağı karşılaştırma, metni düzenleme veya çıktıyı kullanmadan önce inceleme gibi adımlar ürünün ve büronuzun sürecine göre değişebilir. Demo sırasında tek bir örneğin olumlu sonuç vermesi, her belgede aynı sonucu alacağınız anlamına gelmez. Sağlayıcının hangi girdi türlerinin sınanabildiğini ve hangi sınırlamaların bulunduğunu açıklamasını isteyin.

Raporun rolünü ve avukat incelemesini ayırın

Bir raporun bilgi sunmasıyla karar vermesi aynı şey değildir. Sağlayıcıya, çıktının neyi özetlediğini ve hangi konuda öneri sunduğunu sorun. Ardından hangi değerlendirmelerin kullanıcı incelemesi gerektirdiğini, belirsizlik veya eksiklik olduğunda bunun nasıl fark edilebildiğini öğrenin. Bir çıktının profesyonel incelemenin yerini alacağını ima eden açıklamaları, karar notunda ayrıca işaretleyin.

Raporlama veya yapay zekâ aracı büro için önemliyse, yapay zekâ özelliğini sadece hazır bir tanıtım örneğiyle değerlendirmeyin. Örnek girdinin sizin iş akışınıza ne kadar benzediğini ve çıktıdaki dayanakların ne ölçüde izlenebildiğini karşılaştırın. Bu adım, etkileyici görünen bir sonucu, günlük kullanımda işe yarayıp yaramayacağı sorusundan ayırmaya yardımcı olur.

Destek, kurulum ve sağlayıcıdan ayrılma sürecinde ne sormalısınız?

Bir yazılımı yalnızca işler yolundayken değerlendirmeyin. Kullanıcı desteğe ihtiyaç duyduğunda hangi kanala başvuracağını, kurulum ve bakım sorumluluğunun nasıl paylaşıldığını, veriyi dışarı almak istediğinde hangi seçeneklerin bulunduğunu öğrenin. Bu konular çoğu demoda kısa geçilebilir; bu nedenle sorularınızı önceden hazırlayıp yanıtlara somut örnek isteyin.

Destek kanalını ve sorumlulukları netleştirin

Destek için hangi kanalların kullanılabildiğini ve hangi tür sorunların bu kapsama girdiğini sorun. “Destek veriyoruz” cevabını; kullanıcının başvuru adımları, sağlayıcının sorumluluğu ve bürodan beklenen bilgiler şeklinde açtırın. Demo sırasında, örnek bir teknik sorun bildiriminin nasıl iletileceğini ve yanıtın nereden takip edileceğini öğrenin. Beklediğiniz yanıt süresi gibi bir taahhüt varsa, bunu sözlü anlatım yerine yazılı olarak istemek daha net bir kayıt sağlar.

Kurulum, kullanıcıların ilk kullanıma hazırlanması ve devam eden bakımın kim tarafından yürütüldüğünü ayrı ayrı sorun. “Kurulum dahil” açıklaması, tüm büro yapılandırmalarının veya kullanıcı eğitimlerinin aynı kapsamda olduğu anlamına gelmeyebilir. Hangi adımların sağlayıcıya, hangilerinin büroya ait olduğunu senaryo üzerinden konuşun. Teknik düzen tercihinizi anlamak için bulut tabanlı ve bilgisayara kurulan seçeneklerin farklarını da sağlayıcıya soracağınız sorularla eşleştirebilirsiniz.

Veriyi dışa aktarma ve hesap kapanışını konuşun

Sağlayıcıdan verilerin hangi biçimlerde dışa aktarılabildiğini, hangi kayıt ve eklerin bu kapsama girdiğini sorun. Bir örnek dışa aktarma gösterimi isteyin; dosya adlarının, klasör düzeninin veya kayıt ilişkilerinin nasıl korunduğunu inceleyin. Gösterim yapılamıyorsa, bu ayrıntıları yazılı açıklama olarak talep edin. Veriyi dışarı alabilmek ile başka bir sistemde aynı şekilde kullanabilmek farklı konular olduğundan, geçişte hangi düzenlemelerin gerekebileceğini de sorun.

Hesap kapanışında veriye erişimin ne zaman sona erdiğini ve saklama ya da silme sürecinin nasıl yürüdüğünü açıklığa kavuşturun. Büronun elinde kalacak kopyalar, dışa aktarma için gereken adımlar ve sağlayıcının süreçteki rolü gibi noktaları ayrı not edin. Bu başlıklarda sözleşme veya teknik koşullara ilişkin kesin varsayım kurmayın; cevabı sağlayıcıdan alın ve gerekiyorsa güncel koşulları ilgili taraflarla teyit edin.

Demo sonrasında seçenekleri nasıl puanlayıp karar verirsiniz?

Demo bitince sağlayıcıları hafızanızdaki genel izlenime göre karşılaştırmayın. Aynı senaryolara verilen yanıtları tek bir tabloda toplayın ve gösterilen işlevi, sözlü açıklamayı ve açık kalan noktayı birbirinden ayırın. Değerlendirme yöntemi, kararınızı otomatik olarak vermez; hangi başlıklarda ek kanıt veya büro içi görüş gerektiğini görünür kılar.

Zorunlu ölçütleri tercih edilenlerden ayırın

Önce büro için vazgeçilmez olan ihtiyaçları belirleyin. Örneğin dosya takibinde belli bir kayıt geçmişi görünmüyorsa bu bir zorunluluk olabilir; farklı bir ekranda fazladan filtre sunulması ise tercih edilen özellik olarak kalabilir. Her maddeyi aynı ağırlıkta puanlamak, kritik bir eksikliği çok sayıda küçük kolaylığın gölgelemesine yol açabilir.

Karşılaştırma tablonuzda her sağlayıcı için şu alanlara yer verin:

Her cevabı sınıflandırın ve yazılı teyitleri kaydedin

Demonun hemen ardından her cevap için üç seçenekten birini işaretleyin: gösterildi, açıklandı veya belirsiz. “Gösterildi” demek, ilgili adımı canlı olarak gördüğünüz anlamına gelsin; yalnızca anlatılan bir özellik bu sınıfa girmesin. Bir konu ekran paylaşımında gösterilmediyse ama sağlayıcı ayrıntılı biçimde anlattıysa “açıklandı” olarak kaydedin. Yanıt, kapsam veya sorumluluk konusunda boşluk bırakıyorsa “belirsiz” seçeneğini kullanın.

Ardından yazılı teyit bekleyen maddeleri ve bunları takip edecek kişiyi belirleyin. Özellikle veri kapsamı, geri yükleme, yetkiler, UYAP aktarım sınırları, güncellemeler ve hesap kapanışı gibi kararınızı etkileyen cevapları bu listeye alın. Karar notuna, hangi senaryonun test edildiğini ve hangi adımın gösterilmediğini ekleyin. Demo öncesinden karar notuna uzanan akışı ve demo cevaplarını karşılaştırma yöntemini, bu yazıdaki ve

işaretçilerinin temsil ettiği görsel rehberlerle de takip edebilirsiniz.

Bir platform demosunda hangi özellikleri kendi senaryonuzla sınayabilirsiniz?

Bir platformu değerlendirirken sağlayıcının genel tanıtımına değil, sizin hazırladığınız kontrol listesine dönün. Her özelliği büroya ait bir senaryoya bağlayın ve uygulamalı gösterim isteyin. Platform adı veya özellik başlığı, iş akışınıza uyduğunu tek başına göstermez; bunu, sağlayıcının hangi adımı nasıl gösterdiğine bakarak değerlendirmeniz gerekir.

Kurulum ve güncelleme yaklaşımını sorup UYAP aktarımını doğrulayın

Örneğin AvukatSiteleri.net, her büronun verisinin kendi bağımsız kurulumunda tutulduğunu ve yazılım güncellemelerinin platform tarafından yapıldığını belirtiyor. Güncellemelerin merkezden, kademeli ve geri alınabilir şekilde dağıtıldığı açıklanıyor. Bu yaklaşımın büro düzeninize uygun olup olmadığını anlamak için demoda kurulumun ne anlama geldiğini, güncellemelerin nasıl dağıtıldığını ve bir sorun durumunda sürecin nasıl ele alındığını sorun. Size sunulan açıklamayı, beklentileriniz ve sağlayıcıdan istediğiniz teyitlerle karşılaştırın.

UYAP aktarımı konusunda da kendi erişiminiz ve hazırladığınız senaryo üzerinden gösterim isteyin. AvukatSiteleri.net’in açıklamasına göre, avukatın UYAP’ta erişebildiği dosyaların bilgileri eklenti aracılığıyla panele aktarılır ve aktarım UYAP oturumu açıkken arka planda ilerler. Demo sırasında hangi bilgilerin aktarıldığını, hangi koşullarda aktarımın başladığını ve bu aktarımın kapsamı dışında ne kaldığını ayrıca sorun. Bu açıklama, başka resmî işlemlerin yapıldığı anlamına gelmez.

Raporu inceleyin ve demoyu kendi ölçütlerinizle tamamlayın

Raporlama veya yapay zekâ çıktısı sunuluyorsa, sağlayıcıdan örnek girdi üzerinden çıktı oluşturmasını isteyin. Hangi belge ve girdilere dayandığını, eksik bilgi olduğunda nasıl fark edilebileceğini ve avukat incelemesinin nerede devreye girmesi gerektiğini sorun. Gösterilen çıktının sizin dosya yapınıza benzemesine dikkat edin; örnek senaryo büro işinize uymuyorsa, kontrol listenizdeki daha ilgili bir senaryoyla test edin.

Bir platformu değerlendirirken özellikleri inceleyebilir ve sağlayıcının demosunda bu bölümdeki soruları kullanabilirsiniz. Önce aynı senaryoları sağlayıcı demolarında uygulayın; cevapları gösterildi, açıklandı veya belirsiz diye not edin. İlgileniyorsanız demo talep edip aynı senaryolarla platformu kendi büro ihtiyaçlarınıza göre değerlendirin. Böylece tanıtım anlatımından bağımsız olarak, hangi iş akışlarının karşılandığını ve hangi cevapların yazılı teyit beklediğini görebilirsiniz.