Web Sitesi Talepleri Büro Yazılımına Doğrudan Aktarılabilir mi?

Bir web formunun gönderilmesi, talebin ekip tarafından fark edildiğini veya takip edildiğini tek başına göstermez. Önce form bilgisinin nerede saklandığını, kimin görebildiğini ve gönderimden sonra hangi adımın atıldığını netleştirin.

Bu ayrım, özellikle avukat web sitesi iletişim formu takibi ile hukuk bürosu aday müvekkil takibini birbirine karıştırmamak için önemlidir. Amaç, ilk iletişim bilgisinin güvenilir biçimde ilgili kişiye ulaşmasını sağlamak; hukuki değerlendirmeyi veya kabul kararını otomatikleştirmek değildir.

Web sitesinden gelen talebin yazılıma “düşmesi” hangi aşamayı ifade eder?

“Talep yazılıma düşüyor” ifadesi farklı işleri anlatabilir. Bir sağlayıcı form gönderiminin kaydedilmesini, başka bir sağlayıcı ekip üyesine e-posta gitmesini, bir diğeri de büro yazılımında yeni kayıt oluşmasını kastedebilir. Bu nedenle önce hangi aşamanın kastedildiğini sorun. Akışın bir bölümünün otomatik olması, sonraki bölümlerin de otomatik olduğu anlamına gelmez.

Form gönderiminin kaydedilmesi

İlk aşama, ziyaretçinin formu göndermesiyle bir talep kaydının oluşmasıdır. Bu kayıt web sitesi yönetim panelinde, ayrı bir talep ekranında, e-posta gelen kutusunda veya büro yazılımında bulunabilir. Bunlar aynı saklama yeri değildir. Sağlayıcıdan kaydın hangi ekranda göründüğünü, kaydı kimin açabildiğini ve ekip üyelerinin talebi nasıl bulacağını göstermesini isteyin.

Formun gönderildiğine dair ziyaretçiye bir mesaj görünmesi de kaydın büro yazılımına aktarıldığını kanıtlamaz. Bu mesaj yalnızca formun gönderildiğini bildiriyor olabilir. Dolayısıyla kullanıcıya gösterilen onay ile ekibin görebildiği kayıt konumunu ayrı ayrı doğrulayın.

Talebin ekip içinde takip edilmesi

Kayıt oluşturulduktan sonra ekibin talebi fark etmesi ve kimin ilgileneceğinin belirlenmesi gerekir. E-posta bildirimi, ekip içi yönlendirme veya yazılım içindeki bir takip kaydı bu aşamaya yardımcı olabilir. Ancak bildirimin gönderilmesi, sorumlu kişinin atandığını ya da talebin sonuçlandırıldığını kendiliğinden göstermez.

Takip için şu sorulara cevap arayın: Talep hangi ekranda görünür? Bildirim hangi adrese gider? İlgilenecek kişi değişirse bu nasıl anlaşılır? Sonuçlanmamış başvurular ekip tarafından nasıl yeniden kontrol edilir? Bu soruların yanıtı yoksa, “entegrasyon” denilen şey yalnızca bir e-posta yönlendirmesi olabilir.

Müvekkil veya dosya kaydının ayrı bir karar olması

Bir form kaydı, kişinin müvekkil olarak kabul edildiğini veya dosya açıldığını göstermez. İlk iletişim, büro tarafından incelenmesi gereken bir taleptir. Bu yazıda ele alınan kapsam, formdan gelen bilginin kaydedilmesi ve takip sorumlusuna ulaştırılmasıdır. Kabul kararı, hukuki inceleme ve büro içi dosya açma ise ayrı süreçler olarak kalmalıdır.

Konunun bütününü avukat web sitesi rehberi: planlamadan yayına tüm aşamalar rehberinde bulabilirsiniz.

Talebin formdan büro yazılımına ilerleme akışı nasıl kurulur?

Akışı kurarken her adımda üç noktayı tanımlayın: bilgi nerede oluşuyor, sonraki adımda kim görüyor ve kayıt nerede bulunuyor? Bu sorulara yanıt vermeden yalnızca “form yazılıma bağlanacak” demek, kurulum sonrası beklentiyi belirsiz bırakır. Akışı kâğıt üzerinde veya basit bir süreç notunda görünür kılmak, eksik sorumlulukları önceden yakalamanıza yardımcı olur.

Formda alınacak bilgiyi amaçla sınırlama

Formun amacı, talebin ilk değerlendirme için doğru kişiye ulaşmasını sağlayacak kadar bilgi almaktır. İsim, iletişim bilgisi ve kişinin hangi konuda iletişime geçtiğini kısaca açıklayabileceği bir alan başlangıç için değerlendirilebilir. Her alanı eklemeden önce “Bu bilgi ilk yönlendirme için neden gerekli?” diye sorun. Yanıt net değilse alanı çıkarmayı veya isteğe bağlı yapmayı değerlendirin.

Uzun ve ayrıntılı açıklama isteyen bir form, başvuru sahibinin gereğinden fazla bilgi yazmasına yol açabilir. Ayrıca ekip, henüz incelemediği geniş bir anlatıyı hangi ekranda takip edeceğini bilemeyebilir. Formdaki yönlendirme metni, ilk iletişimin kapsamını anlaşılır biçimde anlatmalı; ayrıntı vermeyi teşvik eden muğlak ifadelerden kaçınmalıdır. Form tasarımına ilişkin iletişim formu önerilerini değerlendirmek, alanları işlevlerine göre gözden geçirmenizi kolaylaştırabilir.

Talebi hangi ekip üyesinin izleyeceğini belirleme

Her talep için kimin ilk kontrolü yapacağı belli olmalıdır. Bu kişi her zaman hukuki değerlendirmeyi yapacak avukat olmak zorunda değildir; büro içindeki iş bölümü neyi gerektiriyorsa onu tanımlayın. Önemli olan, talebin ortak bir gelen kutusuna düşüp sahipsiz kalmamasıdır. Görevli kişi değiştiğinde de kaydın nerede bulunduğu ve kime devredildiği anlaşılmalıdır.

Aşağıdaki sıra, akışın temelini kurar:

1. Ziyaretçi formu gönderir.
2. Form gönderimi bir kayıt oluşturur.
3. Kayıt ekipteki belirlenmiş kişiye bildirilir veya o kişinin görebildiği ekranda belirir.
4. Sorumlu kişi talebi ilk inceleme için ele alır.
5. Sonraki adım ve sonuç, büroda belirlenmiş takip yöntemine göre kayda geçirilir.

Sonuçlanmayan talepler için takip noktası koyma

Talep ilk incelemeden sonra hemen sonuçlanmayabilir. Yanıt bekleniyor, bilgi eksik veya sorumlusu değişmiş olabilir. Bu nedenle “kayıt oluştu” adımından sonra talebin durumunu yeniden kontrol edeceğiniz bir nokta belirleyin. Bu kontrolün nerede yapılacağı, mevcut yazılımın özelliklerine ve büronun işleyişine göre değişebilir; özelliği varmış gibi kabul etmeyin.

İş akışını tarif ederken her adım için kayıt yerini not edin: formun geldiği yer, bildirimin ulaştığı yer ve takip sorumlusunun baktığı yer. Bu yerler farklıysa geçişin nasıl gerçekleştiğini açıkça yazın. Böylece bir çalışan e-postayı görmediğinde talebin başka nerede bulunabileceğini bilir. Ayrıca web sitesi ile büro yazılımının aynı sağlayıcıdan alınmasının otomatik bağlantı anlamına gelmediğini baştan hesaba katarsınız; tek sistem veya ayrı sağlayıcı değerlendirmesi bu ayrımı konuşmanıza yardımcı olabilir.

Entegrasyonun kapsamını sağlayıcıya hangi sorularla doğrularsınız?

“Entegrasyon var” yanıtı, tek başına satın alma veya kurulum kararı vermek için yeterli değildir. Sağlayıcının bu kelimeyle neyi kastettiğini, hangi verinin hangi ekranda oluştuğunu ve süreçte hangi adımların kullanıcı tarafından yapılacağını sorun. Yanıtları mümkünse yazılı alın; böylece demo sırasında gördüğünüz akışı teklif veya kurulum kapsamıyla karşılaştırabilirsiniz.

Aktarılan alanlar ve kayıt konumu

Önce, formdaki hangi alanların aktarıldığını tek tek sorun. Ad, iletişim bilgisi ve açıklama alanı aktarılıyor mu? Formdaki bütün alanlar mı taşınıyor, yoksa bazıları dışarıda mı kalıyor? Alanların adlarının veya içeriklerinin büro yazılımındaki karşılığını gösteren bir eşleştirme açıklaması isteyin. “Form bilgileri aktarılır” ifadesi, her alanın aktarıldığını varsaymak için yeterli değildir.

Ardından kaydın hangi ürün veya ekranda oluştuğunu sorun. Talep büro yazılımında bir kayıt mı olur, web sitesi panelinde mi kalır, yoksa bir e-posta olarak mı ulaşır? Çalışanlar aynı talebi hangi aramayla bulabilir? Kayıt oluşturulduktan sonra formdaki bilginin değişmesi durumunda ne olacağını da açıklatın. Sağlayıcının yanıtı, ilgili ekranı canlı göstererek veya test kaydı üzerinden açıklayabilmesiyle daha somut hale gelir.

Bildirim, başarısız aktarım ve tekrar kontrolü

Aktarımın başarısız olması halinde bunun nasıl fark edildiğini öğrenin. Ekranda bir uyarı mı çıkar, bildirim mi gelir, yoksa talep yalnızca kaynak form panelinde mi kalır? Hata bildiriminin kime gittiğini, bu kişinin yokluğunda süreci kimin kontrol edeceğini ve kaydın yeniden gönderilip gönderilemeyeceğini sorun. Bu özelliklerin mevcut olduğunu varsaymayın; sağlayıcıdan sistemin gerçekten ne yaptığını açıklamasını isteyin.

Kayıtla ilgili tekrar kontrol yöntemini de netleştirin. Örneğin ekip, form gönderimlerini bir kaynaktan ve yazılım kayıtlarını başka bir ekrandan karşılaştırabiliyor mu? Böyle bir karşılaştırma özelliği yoksa, büronun elle uygulayacağı kontrol adımı ne olacak? Sistemin mevcut ekranlarını görmek, hangi kontrolün yapılabileceğini anlamaya yardımcı olur. Bu sorular yalnızca teknik ekibe değil, günlük takip sorumluluğunu üstlenecek kişiye de yöneltilmelidir.

Test ortamı, sorumlu taraf ve destek kapsamı

Akışın kurulum öncesinde nasıl deneneceğini sorun. Test için ayrı bir ortam, örnek bir form veya deneme kaydı sunuluyor mu? Test kaydının nerede görüleceğini kim gösterecek? Bir sorun çıktığında web sitesi sağlayıcısı mı, büro yazılımı sağlayıcısı mı, yoksa büronun kendi sorumlusu mu ilk incelemeyi yapacak? Bu paylaşım belirsiz kalırsa hata bildirimi iki taraf arasında sahipsiz kalabilir.

Sağlayıcıdan “entegrasyon”u adım adım tarif etmesini isteyin: Formdan hangi kayıt oluşuyor, kayıt nereye gidiyor, kim bildirim alıyor, hata nasıl anlaşılıyor ve akış nasıl yeniden kontrol ediliyor? Yanıtı şu kısa listeyle karşılaştırabilirsiniz:

• Aktarılan alanların listesi ve kayıt konumu gösterildi mi?
• Bildirim ile başarısız aktarım süreci açıklandı mı?
• Test yöntemi ve sorumlu taraf belirlendi mi?

Talep kaydı ile otomatik müvekkil veya dosya açma neden ayrılmalıdır?

Formun gönderilmesi yalnızca ilk iletişimi başlatır. Başvuru sahibinin kim olduğu, talebin büro için uygun olup olmadığı, hangi kişinin inceleyeceği ve sonraki adımın ne olacağı ayrıca değerlendirilir. Bir web formunun otomatik kaydı bu değerlendirmelerin yapıldığını göstermez. Bu sınır, hem sağlayıcıdan beklenen özelliği doğru tanımlamak hem de büro içindeki karar adımlarını korumak için önemlidir.

İlk talep kaydı

İlk kayıt, başvurunun geldiğini ve ekip içinde bulunabilir olduğunu gösteren bir başlangıç noktasıdır. Kayıtta formdan gelen bilgiler, gönderim zamanı veya takip için gereken başka unsurlar bulunabilir; hangi alanların tutulduğu kullanılan sisteme bağlıdır. Sağlayıcıdan kayıt ekranını göstermesini isteyin ve ekibin bu kaydı nasıl ayırt edeceğini sorun. Kayıt, “büro bu başvuruyu kabul etti” anlamına gelmemelidir.

Örnek senaryo: Web formu gönderildiğinde bir aday takip numarası oluşuyor ve ekibe bildirim e-postası geliyor. Ekip, kaydın büro panelinde nerede göründüğünü ve ilk takibi kimin üstleneceğini test ediyor. Bu senaryoda form talebinin takip edilmesi otomatikleşebilir; ancak yeni müvekkil kabulü veya dosya açılması bu akışın parçası olarak varsayılmaz.

Avukat incelemesi ve kabul kararı

İlk iletişim ile hukuki değerlendirme aynı iş değildir. Talebin konusunu ve büronun nasıl ilerleyeceğini ilgili kişi incelemelidir. Bu yazı, kabul ölçütlerini veya hukuki incelemenin nasıl yürütüleceğini belirlemez; otomasyonun başlangıç kaydı ve yönlendirmeyle sınırlı tutulması gerektiğini vurgular.

Sağlayıcı “formdan otomatik müvekkil oluşturuyoruz” diyorsa, bu ifadenin hangi işlem adımını anlattığını sorun. Bir iletişim kaydı mı açılıyor, yoksa büronun daha sonra vermesi gereken bir karar sistemde tamamlanmış gibi mi işaretleniyor? Ekrandaki etiketler ve işlem adları ekip üyelerinde yanlış beklenti yaratabilir. Bu nedenle “aday”, “talep” veya “müvekkil” gibi adlandırmaların neyi temsil ettiğini demo sırasında netleştirin.

Büro içi kayda geçiş

Büro, kendi işleyişine göre ilk talep kaydından sonra ayrı bir kayıt veya dosya açabilir. Bu adıma kimin karar verdiği ve talep kaydıyla dosyanın nasıl ilişkilendirildiği sağlayıcıya sorulmalıdır. Bu bağlantının yazılımda mevcut olduğunu peşinen varsaymayın; demo sırasında örnek kayıt üzerinden gösterilmesini isteyin. Otomatik aktarımın teknik olarak çalışması, büro içi süreçlerin kendiliğinden tamamlandığı anlamına gelmez.

Satın alma görüşmesinde kapsamı üç ayrı cümleyle yazdırmak işe yarar: Formdan hangi bilgilerin kaydedileceği, kaydın kime ve nasıl bildirileceği, müvekkil veya dosya kararının kim tarafından verileceği. Böylece “talep yazılıma düşüyor” ifadesi, kapsamı belirsiz bir vaat olmaktan çıkar ve ekibin denetleyebileceği bir sürece dönüşür. Belirli hukuki yükümlülükler veya büroya özgü uygulamalar söz konusuysa güncel mevzuattan ve baronuzdan kontrol edilmelidir.

Form verisi, erişim ve kayıp talep riskleri nasıl kontrol edilir?

Form alanları, erişim yetkileri ve takip sorumluluğu birlikte düşünülmelidir. Gereğinden fazla bilgi istemek, ekip içinde gereğinden fazla kişiye erişim açmak veya yalnızca tek kişinin e-postasına güvenmek farklı operasyonel riskler doğurabilir. Buradaki öneriler bir hukuki uyum değerlendirmesi değildir; büronun akışı gözden geçirmesine yardımcı olacak pratik kontrollerdir. Hukuki gereklilikler için güncel mevzuattan ve baronuzdan kontrol alın.

Form alanlarını ve yönlendirme metnini gözden geçirme

Formdaki her alanın neden gerekli olduğunu ekipçe değerlendirin. İlk yönlendirme için gerekli olmayan ayrıntıları zorunlu istemeyin; formun açıklama alanını sınırsız bilgi paylaşımına teşvik edecek biçimde bırakmayın. Kişiye formu doldururken ne tür bir bilgi vermesinin beklendiğini açıkça anlatın. Hangi bilgilerin isteneceği, büronun ihtiyacına ve mevzuat değerlendirmesine göre ayrıca ele alınmalıdır.

Gözden geçirmede şu noktaları kullanabilirsiniz:

• Her alanın amacını ve zorunlu olup olmadığını yazın.
• Form açıklamasının ne istendiğini anlaşılır kıldığını kontrol edin.
• Talep sahibine gösterilen gönderim onayının ne ifade ettiğini açıklayın.
• Test sırasında formdan gelen bilginin ekranda nasıl göründüğünü inceleyin.

Formu yalnızca masaüstünde değerlendirmeyin. Ekran boyutu değiştiğinde alanların anlaşılır kalıp kalmadığını, gönderim mesajının fark edilip edilmediğini ve kullanıcının hangi adımı tamamladığını anlayıp anlamadığını kontrol edin. Bu kontroller, talep sahibinin yanlışlıkla birden fazla form göndermesi veya gönderimin tamamlandığını sanması gibi karışıklıkları azaltmaya yardımcı olabilir.

Erişim ve sorumlulukları belirleme

Talep kayıtlarına kimlerin erişeceğini görev dağılımına göre belirleyin. Ekipte bir kişinin izinli veya görev dışında olması halinde talebin nasıl devredileceğini de kararlaştırın. Ortak bir e-posta kutusu kullanılıyorsa, gelen mesajın tek başına takip edildiğini varsaymayın; ilgili kişinin mesajı gördüğünü ve sonraki adımı üstlendiğini nasıl anlayacağınızı belirleyin.

Sorumluluk notunda en azından ilk incelemeyi kimin yaptığı, yönlendirme gerektiğinde kime haber verileceği ve bekleyen taleplerin nerede kontrol edileceği yer alabilir. Yazılımda bu roller için bir özellik bulunduğunu varsaymayın. Mevcut ürün bunu desteklemiyorsa, ekibin hangi işleyişle boşluğu kapatacağını kararlaştırın. Erişim ve saklama uygulamalarının hukuki yönü için güncel mevzuattan/baronuzdan kontrol alın.

Test talebiyle baştan sona kontrol

Kayıp talep riskini yalnızca hata oluştuğunda araştırmayın. Deneme formu gönderip kaydın kaynağından takip sorumlusuna kadar nasıl ilerlediğini baştan sona izleyin. Bu testte ekipten biri talebi görmeli, kayıt konumunu doğrulamalı ve takip sorumluluğunu üstlenmelidir. Sonra aynı kaydı diğer ekip üyelerinin nasıl bulduğunu da kontrol edin.

Yayına geçmeden önce aşağıdaki kontrolü uygulayın:

• Form gönderildiğinde onay mesajı görünüyor mu?
• Talep beklenen kayıt yerinde bulunuyor mu?
• Bildirim doğru kişiye veya belirlenmiş ekibe gidiyor mu?
• Bildirimi alan kişi kaydı açıp sonraki adımı tarif edebiliyor mu?
• Kayıt bulunamazsa kimin hangi kaynağı kontrol edeceği belli mi?

Bu kontrollerin sonucu, sistemin yalnızca teknik olarak veri taşıyıp taşımadığını değil, büro ekibinin talebi gerçekten takip edip edemediğini de gösterir. Akışta farklı sağlayıcılar varsa, bir tarafta kaydın oluştuğunu görmek diğer tarafta da göründüğünü kanıtlamaz. Her geçişi ayrı ayrı doğrulayın ve sonuçları kurulum notlarına ekleyin.

Kurulum öncesi hangi testlerle akışın çalıştığını anlarsınız?

Kurulum öncesi test, sağlayıcının anlattığı akışı gerçek bir örnekle karşılaştırmanızı sağlar. “Çalışıyor” yanıtı yerine formu gönderin, kaydı bulun, bildirimi kontrol edin ve takip sorumlusunun ne yapacağını doğrulayın. Testte kullanılan bilgiler gerçek bir başvuruya ait olmamalıdır. Test koşullarını sağlayıcıyla netleştirin; deneme kayıtlarının nasıl ayırt edileceğini ve sonrasında ne yapılacağını sorun.

Örnek talep gönderip kayıt yerini doğrulama

İlk olarak formun tamamlanabilir olduğunu ve gönderimden sonra ne görüldüğünü kontrol edin. Ardından sağlayıcıdan talep kaydının nerede oluştuğunu göstermesini isteyin. Kaydı yalnızca kendisinin bulduğu ekranı değil, günlük takip edecek ekip üyesinin kullanacağı görünümü de inceleyin. Talebin hangi bilgilerle arandığını ve kayıt bulunamazsa hangi kaynağa dönüleceğini not edin.

Basit bir kabul testi şöyle ilerleyebilir:

1. Deneme formunu, test olduğu anlaşılacak biçimde gönderin.
2. Ekrandaki gönderim onayını kaydedin veya gözlemleyin.
3. Kayıt oluşması beklenen ekranı açıp deneme talebini bulun.
4. Form alanlarının doğru görünüp görünmediğini karşılaştırın.
5. Talebin sorumlusunun kim olacağını ve takip adımını teyit edin.

Alanlar eksik ya da yanlış görünüyorsa, sorunun formda mı yoksa aktarımda mı olduğunu sağlayıcıyla birlikte ayırın. Bir aşamada düzeltilen sorunun sonraki aşamaları nasıl etkileyeceğini de tekrar test edin. Tek bir başarılı gönderim, bütün olası durumların denendiğini göstermez.

E-posta ve takip adımını kontrol etme

Bildirim bekleniyorsa hangi adrese gittiğini, mesajın talep kaydını bulmaya yetecek bilgiyi içerip içermediğini ve sorumlunun sonraki adımı nasıl belirlediğini doğrulayın. E-postanın ulaşması tek başına talebin yazılımda kayıtlı olduğunu kanıtlamaz. Bu nedenle e-postadaki bilgiyle ilgili ekrandaki kaydı eşleştirin. Bildirim başka bir ekip üyesine yönlendirildiğinde de sorumluluğun nasıl devredileceğini sorun.

Test kaydı ekipte görünür olsa bile takip yöntemi tanımlı değilse akış tamamlanmış sayılmaz. Talep için kimin işlem yapacağını, sonuçlanmadığında nerede yeniden kontrol edileceğini ve ilgili kişinin yokluğunda kimin devralacağını belirleyin. Mevcut yazılım bu adımları desteklemiyorsa, ekip içinde hangi alternatif kontrolün uygulanacağını yazılı hale getirin.

Başarısız durumda kimin ne yapacağını yazma

Testte bir hata çıktığında bunun nasıl fark edildiğini gözlemleyin. Sorunu kimin bildireceğini, hangi sağlayıcıyla iletişime geçeceğini ve kaynak formda talebin bulunup bulunmadığını kimin kontrol edeceğini belirleyin. Hata bildirimi veya otomatik tekrar özelliği mevcut değilse, varmış gibi işlem planlamayın. Süreçteki boşluğu hangi kontrolün kapatacağını açıkça yazın.

Örnek bir test planında başarılı gönderim, boş bırakılmış alan, bildirim alıcısı ve takip sorumlusunun adımı ayrı ayrı yer alabilir. Her senaryoda beklenen sonucu ve sonucu kimin doğruladığını not edin. Kapsamı ve destek sorumluluğunu sağlayıcıyla yazılı olarak karşılaştırın. Gerçek ortamda özelliği doğrulamadan “otomatik entegrasyon hazır” sözü vermeyin; deneme sırasında hangi kapsamın görüldüğünü ve neyin test edilmediğini de ekibe aktarın.

Web sitesi ve aday takibi özellikleri bu akışın neresinde yer alır?

Bir web sitesi ile aday takibi aynı iş akışının parçaları olabilir, ancak bu durum her büro yazılımına otomatik senkronizasyon olduğu anlamına gelmez. Özelliğin nerede başladığını ve nerede bittiğini ürün açıklamasından değil, kendi talep akışınızla yapılan testten anlayabilirsiniz. Önce web sitesindeki formun talebi nasıl aldığına, sonra kaydın nerede göründüğüne ve ekibin nasıl takip ettiğine bakın.

Web sitesini panelden yönetme

AvukatSiteleri.net, hazır tema kütüphanesinden seçilen ve panelden yönetilen kurumsal hukuk bürosu web sitesi sunar. Bu özellik, web sitesinin nasıl oluşturulup yönetildiğini açıklar; tek başına kullanılan başka bir büro yazılımıyla bağlantı kurulduğunu göstermez. Sizin için önemli olan, formdan gelen talebin hangi ekranda kayda alındığını ayrıca doğrulamaktır.

Form talebinin takip numarasıyla kayda alınması

Web sitesinden gelen talepler takip numarasıyla kayda alınır; form gönderimiyle iki tarafa e-posta gider. Bu işleyiş, talebin takip edilmesine yardımcı olabilir. Ancak herhangi bir büro yazılımına otomatik aktarım veya otomatik müvekkil/dosya açılışı olarak yorumlanmamalıdır. Demo sırasında takip numarasının nerede görüldüğünü, bildirimin hangi adrese gittiğini ve talebi kimin izleyeceğini kendi akışınız üzerinden kontrol edin.

Kendi ihtiyacınız için kapsamı demo sırasında doğrulama

Demonuzda form gönderimi, kayıt konumu, takip sorumlusu, bildirim ve hata halinde uygulanacak kontrol adımlarını tek tek deneyin. Büro yazılımınızla bağlantı sizin için şartsa, hangi bağlantı biçiminin desteklendiğini ve hangi adımların ayrıca yapılacağını yazılı biçimde sorun. Aday takibi özelliğinin kapsamını ve tüm özellikleri incelemek, demo sırasında sorularınızı somutlaştırabilir. Karar vermeden önce demo talep edin ve web sitesi ile takip numarasıyla talep kaydının kendi sürecinize uyup uymadığını sağlayıcıyla birlikte doğrulayın.