Çeviri & tercüme bürosu için CRM: proje, teslim tarihi ve kurumsal müşteri

Sabah dokuzda telefona bakan tercüme bürosu sahibinin önünde üç iş birden durur: bir hukuk bürosunun öğleden sonraya yetiştirilmesi gereken sözleşmesi, Almanya’ya taşınacak bir ailenin diploma çevirisi ve altı dile çevrilecek bir kullanım kılavuzu için teklif talebi. Hangisi WhatsApp’tan geldi, hangisi e-postada bekliyor, hangisinin son tarihi gerçekten bugün — bunu hatırlamak tek başına bir iştir. Doğru kurulmuş bir çeviri bürosu CRM’i tam olarak bu karmaşayı çözmek için var: teklif, teslim tarihi ve kurumsal müşteri ilişkisini tek ekranda tutmak.

Bu yazıda bir tercüme bürosunun günlük işleyişinde nerelerin kırıldığını, teklif ve teslim sürecinin nasıl sistemli hale getirilebileceğini ve tekrar eden kurumsal müşterilerin nasıl büyütüleceğini ele alıyoruz.

Bir çeviri işi neden basit bir “yapılacaklar” satırı değildir?

Dışarıdan bakınca çeviri iş gibi görünür: metin gelir, çevrilir, gönderilir. Ama her iş aslında birkaç değişkenin kesiştiği bir noktadır: kaynak dil, hedef dil (bazen birden fazla), kelime veya sayfa sayısı, hizmet türü (standart çeviri, yeminli çeviri, redaksiyon, deşifre) ve teslim tarihi. Aynı müşteri aynı hafta içinde üç farklı işi üç farklı aciliyette gönderebilir.

Excel tablosu ya da kağıt üstü not bu kadar değişkeni bir süre taşıyabilir, ama sonsuza kadar değil. Üç ay sonra “bu müşteriye geçen sefer hangi çevirmen baktı, hangi terim listesini kullanmıştık” sorusunun cevabı genelde bir kişinin hafızasında kalır — ve hafıza, elde beş on düzenli kurumsal müşteri birikince yetmemeye başlar. Üstelik bu bilgi kaybolduğunda çoğu zaman fark eden ilk kişi büronun kendisi değil, müşterinin kendisi olur.

İki kişilik bir yeminli tercüme bürosu düşünün: sahiplerinden biri çeviri yapıyor, diğeri hem müşteriyle konuşuyor hem noter randevusu ayarlıyor hem de dosyaların peşinden koşuyor. Bu ekibin ihtiyacı büyük bir yazılım değil; hangi işin şu an nerede olduğunu bir bakışta gösteren basit bir tablo.

Teklif isteyen müşteri genelde aynı anda üç büroya daha soruyor

Kurumsal bir müşteri — bir üretici, bir e-ticaret firması, bir hukuk bürosu — çeviri ihtiyacı doğduğunda tek bir büroya yazmaz. Genelde üç dört büroya aynı anda mesaj atar ve iş, ilk makul teklifi verene çıkar. Bu yüzden teklif hızı, çeviri kalitesi kadar belirleyicidir.

CRM’de her teklif talebi bir kayıt olarak düşer: kim sordu, hangi dil çifti, tahmini kelime sayısı, hedef teslim tarihi. Kelime başı ya da sayfa başı standart fiyatlandırma tanımlıysa teklif dakikalar içinde çıkar ve WhatsApp’tan ya da e-postadan doğrudan gönderilir.

Aşağıdaki akış, bir çeviri talebinin teklif kutusundan teslimata kadar izlediği pratik yolu gösteriyor:

1Talep geldi2Teklif gönderildi3Onaylandı, çeviride4Teslim edildi

Bu akışın her adımı bir tarih ve bir sorumlu taşır. İş “onaylandı” aşamasına geçtiğinde teslim tarihi otomatik olarak takvime düşer — böylece kimse cuma mı söylemiştik, pazartesi mi diye hatırlamaya çalışmaz.

Teslim tarihi bir tercüme bürosunda pazarlık konusu değildir

Bir vize randevusu, bir ihalenin son teslim saati, bir mahkeme celsesi — geç kalan çeviri müşterinin başka bir işini de geciktirir. Bu yüzden teslim tarihi CRM’de sadece bir not değil, hatırlatma tetikleyen bir alan olmalı.

Pratikte işe yarayan yapı şu: her proje bir aşamadan geçer (teklif, onay, çeviride, redaksiyonda, teslime hazır, teslim edildi) ve her aşamada geçen süre görünür olur. Teslim tarihine bir gün kala otomatik hatırlatma gelirse, “unuttum” diye bir bahane kalmaz.

• Acil işler ayrı işaretlenmeli: aynı gün teslim gereken bir iş listenin en üstünde durmalı, haftalık işlerin arasında kaybolmamalı.
• Çok dilli projelerde her dil ayrı satır olmalı: bir kılavuzun İngilizce, Almanca ve Rusça sürümleri üç farklı çevirmene gidiyorsa, üçü de ayrı ayrı takip edilmeli.
• Gecikme riski erken görülmeli: çevirmen teslim tarihinden iki gün önce hâlâ “başlamadım” diyorsa, müşteriye haber vermek için hâlâ zaman olmalı.

Bu disiplin, hukuk bürolarının müvekkil ve son tarih takibinde kullandığı mantıkla neredeyse birebir aynı — orada da gecikme kabul edilebilir bir seçenek değil.

Kurumsal müşteriyle bireysel müşteriyi aynı kefede tutmayın

Bir öğrencinin diploma çevirisi ile bir hukuk bürosunun ayda on beş sözleşmesi aynı türden iş değildir. Biri tek seferlik, diğeri düzenli ve tekrar eden bir ilişki. CRM’de ikisini aynı listede görmek yeterli değil; ayrı etiketlerle, ayrı beklenti seviyeleriyle yönetmek gerekir.

Kurumsal müşteride önemli olan tekrarlılık: geçen ay kaç iş gönderdi, ortalama ödeme vadesi ne, hangi çevirmen ya da terim listesiyle çalışmaya alışkın. Bu bilgi bir kişinin kafasında değil, müşteri kartında durmalı — çünkü o çalışan bir gün izne çıkar, işe yeni biri başlar, müşteri hiçbir şey fark etmemeli.

Tıpkı muhasebe ofislerinin düzenli müşterilerini takip ederken yaptığı gibi, tercüme bürosu da kurumsal müşteriyi “bu ay ne kadar iş geldi, ne zaman yenilenecek” sorusuyla izlemeli. Bireysel müşteride ise asıl mesele hız ve netlik: fiyat, teslim tarihi, ödeme yöntemi net olsun, iş kapansın.

Yeminli çeviri ve noter onayı: standart işten bir adım fazlası

Türkiye’de yeminli tercüme standart çeviriden farklı bir süreç taşır: yeminli tercüman onayı, çoğu zaman noter tasdiki, bazen apostil. Bu adımların her biri ayrı bir randevu, ayrı bir bekleme süresi demektir — ve müşteri genelde bu detayları bilmez, sadece “ne zaman elimde olur” diye sorar.

CRM’de bu tür işler için ekstra bir ara aşama tanımlamak işe yarar: “çeviri tamam, noterde”, “noterden çıktı, teslime hazır” gibi. Böylece müşteriye gerçekçi bir tarih verilir — “yarın” değil, “noter onayı dahil perşembe”.

Bu, mimarlık ofislerinin proje onay süreçlerinde yaşadığı duruma benziyor: iş bittikten sonra bile resmi bir onay adımı kalıyor ve o adım takvime dahil edilmezse teslim tarihi baştan yanlış hesaplanmış olur.

Talep WhatsApp’tan mı geldi, e-postadan mı? Fark etmemeli

Bir tercüme bürosuna iş dört farklı kanaldan gelir: WhatsApp, e-posta, web sitesindeki form, bazen telefon. Her kanalı ayrı ayrı kontrol etmek zaman kaybettirir, daha kötüsü bir talebin cevapsız kalmasına yol açar. Rakip büro daha hızlı yazdıysa iş elden gider.

Tüm kanalları tek bir gelen kutusunda toplamak bu riski azaltır. Aşağıdaki şema, dağınık kanalların nasıl tek bir merkeze bağlandığını gösteriyor:

Ortak gelenkutusuWhatsAppE-postaWeb formuTelefon

Bu birleşim sadece rahatlık değil, süreklilik sağlar: bir müşteri önce WhatsApp’tan yazıp sonra dosyayı e-postayla gönderirse, ikisi de aynı kayıtta görünür. Kimse “o mesajı kim okudu” diye sormak zorunda kalmaz.

Hangi dil çifti, hangi müşteri asıl kazandırıyor?

Yıl sonunda çoğu büro sahibi “çok çalıştık ama nereye” diye düşünür. Oysa CRM’deki geçmiş veriye bakmak yeterli: hangi dil çifti en çok iş getiriyor, hangi müşteri en düzenli ödeme yapıyor, hangi iş türü — yeminli, teknik, edebi — en çok zaman alıp en az kazandırıyor.

Bu tablo bazen rahatsız edici gerçekleri gösterir: nadir bir dil çiftinden gelen tek seferlik işlerin aslında zar zor başa baş gittiği ya da bir kurumsal müşterinin hep geç ödediği ortaya çıkabilir. Bazen de tam tersi olur: küçük ve sessiz görünen bir müşterinin aslında en istikrarlı geliri getirdiği fark edilir. Bu bilgiyle fiyatlandırma ya da öncelik sırası değiştirilebilir.

Aynı mantık, catering firmalarının tekrar eden kurumsal müşterilerini değerlendirirken kullandığı yaklaşımla örtüşüyor: hangi müşteri gerçekten kârlı, hangisi sadece yoğunluk yaratıyor — bunu veri olmadan bilmek zor.

CRM’in yapmayacağı şeyler

Burada dürüst olmak gerekiyor: bir CRM çeviri yapmaz, terim tutarlılığı sağlamaz, CAT aracının (Trados, memoQ gibi) yerini almaz. Çevirmen havuzunu detaylı yönetmek, kelime hafızası tutmak, kalite kontrol yapmak — bunlar ayrı araçların işi.

Açıkçası, her çeviri bürosunun koca bir CRM sistemine ihtiyacı yok — ama iş takibini hafızada tutmaya güvenen her büro er ya da geç bir teslim tarihini unutur.

Küçük, tek dilli, düzensiz iş akışına sahip bir büro için tam bir CRM kurmak bazen gereğinden fazla olabilir; birkaç düzenli kurumsal müşteri ve bir iş takvimi olan paylaşılan bir tabloyla bile idare edilebilir. Ama iş sayısı artıp müşteri çeşitlendikçe, “hangi iş nerede” sorusunun cevabı bir kişinin hafızasından çıkıp sisteme taşınmalı — CRM tam bu noktada anlamlı hale gelir.

İç mimarlık ofislerinin de benzer bir eşiği var: iç mekan projelerinde müşteri onayı ve malzeme takibini tek kişinin hafızasında tutmak bir noktadan sonra yürümüyor. Çeviri bürosu için de eşik aynı: düzenli kurumsal müşteri sayısı arttıkça sistemsiz takip önce yavaşlatır, sonra iş kaybettirir.

Sıkça sorulan sorular

Çeviri bürosu işletmek, aslında sürekli birkaç projeyi aynı anda havada tutmaktır: farklı diller, farklı teslim tarihleri, farklı müşteri beklentileri. Bunu hafızada ya da dağınık tablolarda yönetmeye çalışmak bir noktadan sonra işi büyütmeyi değil, günü kurtarmayı öğretir. Rocketly gibi bir CRM, teklif, teslim tarihi ve kurumsal müşteri geçmişini tek ekranda toplayarak bu jonglörlüğü biraz daha yönetilebilir hale getirir — kalan zamanı da asıl işe, çeviriye ayırabilirsiniz.