Sesli agent ile navlun teklifi alma: neler kaydedilmeli

50 ila 100 kişilik bir nakliye aracısında, lojistik firmasında ya da yük pazaryerinde gelen teklif çağrısı çoğu zaman satış, araç tedariki ve müşteri hizmetleri arasında kalır. Arayanın elinde yalnızca bir güzergah ve bir son tarih olabilir; tırı teyit edebilecek kişi ise o sırada başka bir kuyruktadır. Sesli agent en çok, bu görüşmeyi eksiksiz ve kontrol edilebilir bir talebe çevirdiğinde işe yarar. Hedef, doğru kapasite bilgisiyle daha hızlı nitelemektir; boşlukları tahminle dolduran otomatik bir fiyat masası değil. Talep kaydı belirsizliği görünür kılmalı ki fiyatlandırma ya da operasyon ekibinden biri neyin hâlâ teyit beklediğini tam olarak bilsin.

Fiyatla değil, nitelemeyle başlayın

İlk sorular, talebin işlenebilir olup olmadığını ve kime ait olduğunu ortaya koymalı. Arayanın yük sahibi mi, aracı mı, taşıyıcı mı yoksa mevcut bir müşteri mi olduğunu sorun. Ardından firma adını, arayanın adını, geri arama numarasını, e-postasını ve yük ya da hesap referansını alın. Numarayı ve yazılışı sesli olarak teyit edin. Bir sonraki adımın satışa mı, operasyona mı, müşteri yöneticisine mi yoksa araç tedarikine mi gideceğini bu bilgiler belirler. Arayanın tercih ettiği iletişim yolunu ve başka birinin de bilgilendirilmesini isteyip istemediğini kaydedin. Ancak arayanın rolünü ya da firmasını, onaylı bir kayıtla eşleşene veya bir insan teyit edene kadar doğrulanmış saymayın.

Cevabı değiştiren alanları kaydedin

• Güzergah: çıkış ve varış noktası; şehir, bölge ya da ülke; ara duraklar ve varsa sınır geçişi gereksinimi.
• Araç: araç sınıfı, ölçüler, ağırlık, yükün cinsi, sıcaklık, tehlikeli madde durumu ve özel elleçleme.
• Hazır olma ve zamanlama: yükün hazır olacağı tarih ve saat, yükleme ve teslim aralıkları, saat dilimleri, randevular ve esneklik.
• Ticari bağlam: ihale ya da teklif için son tarih, ek hizmet bedelleri, hizmet seviyesi ve bir fiyatın konuşulup konuşulmadığı.

Zorunlu alanları açıkça tanımlayın. Arayan ağırlığı ya da teslim aralığını bilmiyorsa “bilinmiyor” yazıp devam edin, varsayımda bulunmayın. Eksik ama işe yarar bir talep, kendinden emin ama yanlış bir talepten daha güvenlidir. Genel lojistik iş akışı, her hizmet tipi için hangi alanların zorunlu olduğunu belirlemeli. Bilinmeyen bir alanı, arayanın vermek istemediği bir alandan ayırın ve iki durumu da kaydı inceleyecek kişi için saklayın.

Güzergahı, araç tipini ve zamanlamayı birlikte doğrulayın

Güzergah sorularını, bilgiyi kullanacak kişinin ihtiyaç duyacağı sırayla sorun. Çıkış ve varış noktasını şehir, bölge ya da ülke düzeyinde standart hale getirin; ardından tesis adlarını, rampa ya da randevu bilgilerini ve varsa ara durakların sırasını sorun. Telefonda net duyulan bir yer adı, örneğin “organize sanayi”, birden fazla konuma karşılık gelebilir. Arayan bir tesisi kendi aralarında kullandıkları adla söylüyorsa, eşleşme teyit edilene kadar söylenen değeri ve standart değeri ayrı tutun. Çok duraklı yüklerde her ayrıntıyı ilk noktaya yığmayın; hangi yükün, hangi miktarın ve hangi ek hizmetin hangi durağa ait olduğunu kaydedin.

Araç doğrulaması kapalı kasa, frigorifik ya da açık kasa arasında seçim yapmaktan ibaret değildir. İstenen araç tipini, dorse ölçülerini, ağırlığı ve birimini, yükün cinsini, sıcaklık aralığını, yükleme yöntemini, tehlikeli madde durumunu ve randevu ya da elleçleme kısıtlarını kaydedin. Gereksinimin kesin mi olduğunu, yoksa eşdeğer bir seçeneğin kabul edilip edilmeyeceğini sorun. Böylece araç tedarik ekibi kesin bir kısıtı bir tercihten ayırabilir. Ama bu, uygun bir tırın müsait olduğunu göstermez. Kaydın ayrı bir kapasite durumu olmalı: talep edildi, bilinmiyor, sistemde görünüyor ya da insan tarafından teyit edildi gibi. Durumun kaynağı ve saati de yanında durmalı.

Zamanlama da aynı disiplini ister. Yükün hazır olacağı tarihi yükleme randevusundan, teslim randevusundan ve teklif son tarihinden ayrı kaydedin. Her noktanın yerel saat dilimini saklayın, bir aralığın kesin mi esnek mi olduğunu not edin ve arayanın “sabah ilk iş”, “gün içinde” ya da “yarın sabaha” gibi ifadelerden ne anladığını yazın. Sıralama uygulanamaz görünüyorsa ya da son tarih istenen hizmetle çelişiyorsa kaydı incelemeye işaretleyin ve nedenini açıklayın. Agent netleştirici bir soru sormalı ya da görüşmeyi devretmeli. Bir aralığı sessizce genişletmemeli, bir taşıyıcının o saate yetişebileceğini de ima etmemeli.

Kısa bir teklif alma tablosu kullanın

Transkript değil, teklife hazır bir kayıt bırakın

Özet, bir sonraki kişinin ya da sistemin görüşmeyi yeniden dinlemeden harekete geçebileceği kadar yapılandırılmış olmalı. Örneğin: “Yük sahibi Trabzon'dan Tiflis'e bir kapalı kasa tır istiyor; yükleme salı 08:00-10:00, Türkiye saati; teslim çarşamba 15:00'e kadar, Gürcistan saati; 42.000 lb; paketli gıda, tehlikeli madde değil; teklif pazartesi 12:00'ye kadar gerekli; geri arama numarası teyit edildi; randevu gerekli.” Her değeri kendi alanında saklayın; araçlarınız destekliyorsa kaynağını ve güven düzeyini de. Kelimesi kelimesine notu bağlam olarak tutun, ama güzergahı, aralıkları, birimleri ve istisnaları makinenin okuyabileceği hale getirin.

Sisteme yazmadan önce özeti arayana okuyun ve çelişkileri giderin: 42.000 lb'lik bir yük 42.000 kg ile aynı şey değildir, “salı sabahı” da bir saat dilimi ve aralık ister. Arayandan yalnızca bilgileri değil, bir sonraki adımı da teyit etmesini isteyin. Yazılı teklif mi istiyor, canlı bir fiyat görüşmesi mi, taşıyıcı araması mı, yoksa mevcut bir yükte güncelleme mi? Arayan sonradan bir ayrıntıyı değiştirirse ikinci bir lead açmayın, mevcut talebi güncelleyin. Kimin, ne zaman, hangi alanı değiştirdiğini kaydedin ki operasyon yeni bir fırsatı bir düzeltmeden ayırabilsin.

Kayda, hâlâ yapılması gereken işi yansıtan bir durum verin. İşe yarar durumlar şunlar olabilir: talep alınıyor, incelemeye hazır, arayandan bilgi bekleniyor, fiyat incelemesi, kapasite incelemesi, devir bekliyor, takip planlandı ve kapandı. Adlar sisteme göre değişebilir, ama her birinin anlamı yazılı olmalı. “İncelemeye hazır” bir kayıt, fiyatı verilmiş bir yük gibi görünmemeli. “Kapasite teyit edildi” işaretli bir kayıt da görüşme notundaki bir cümleye dayanmamalı, onaylı kaynağı göstermeli.

Arayanı ve taşıyıcı bağlamını doğrulayın

Kontrol, arayanın kim olduğuna göre değişir. Taşıyıcılar için ticari unvanı ya da kullandıkları adı ve gerekiyorsa onaylı bir kimlik bilgisini alın: örneğin vergi numarası ya da ABD hatlarında MC veya DOT numarası. Araç bilgisini, çalıştıkları bölgeyi, uygunsa şu anki ya da bir sonraki boş konumu ve müsaitlik aralığını da kaydedin. Arayanın bu talep için mi araç önerdiğini, yoksa ileride çıkacak bir iş için mi sorduğunu öğrenin. Yük sahipleri ve aracılar için hesap ya da firma referansını, talebin sahibini ve varsa mevcut yük ya da teklif numarasını kaydedin. Bağlı sistem ya da bir insan doğrulayana kadar kimlik bilgilerini ve kapasite beyanlarını arayanın beyanı olarak ele alın.

Arayanı eşleştirmek için bilinen bir TMS ya da CRM kaydını kullanın. Eşleşmeyen bir kayıt, çelişen firma bilgisi ya da olağandışı bir erişim talebi güvenilir bir profil değil, inceleme doğurmalı. Agent duyduğunu teyit edebilir; ama onaylı bir kaynak olmadan bir taşıyıcının onaylı, sigortalı, atanmış ya da müsait olduğunu söylememeli. Eksik bir taşıyıcı kimlik bilgisini hafızadan ya da benzer bir firma adından doldurmayın. İki kayıt da makul bir eşleşme gibi görünüyorsa belirsizliği koruyun ve kaydı tedarikçi ya da hesap doğrulamasından sorumlu kuyruğa gönderin.

Kapasite belirsizliğini açıkça yazın

Kapasite değişen bir operasyon gerçeğidir. Bir taşıyıcının “o hatta genelde çalışırız” demesinden çıkarılacak bir sonuç değildir. Her müsaitlik beyanının kaynağını, kontrol edildiği saati ve hangi araca ya da tarihe ait olduğunu saklayın. Sistem bir aday gösterebilir, bir taşıyıcı ilgilendiğini söyleyebilir ya da bir planlamacı belirli bir tırı teyit edebilir. Bunlar farklı durumlardır ve tek bir “araç bulundu” durumunda birleşmemelidir. Bağlı bir kaynak güncel değilse, erişilemiyorsa ya da tutarsızsa, durumun insan teyidi gerektirdiğini söyleyin. Sesli agent taşıyıcının teklifini toplayıp bir araç tedarik görevi açabilir; teklifin kullanılabilir olup olmadığına görevin sorumlusu karar verir.

Sınırları net çizin, insana devri tanımlayın

Agent talebi toplayabilir, aldığı bilgileri tekrar edebilir, bağlı bir sistemdeki onaylı durumu paylaşabilir ve bir takip görevi açabilir. Kapasite uyduramaz, araç tutamaz, ihaleyi teyit edemez, randevu sözü veremez, onaylanmamış bir fiyat söyleyemez ya da bir istisnayı kabul edemez. Fiyat, pazarlık ve ek hizmet bedelleri, gerekçe koduyla birlikte insana devri başlatır. Devre güzergahı, araç bilgisini, zamanlamayı, arayanın bağlamını, eksik alanları, istenen sonucu ve kullanılan onaylı veriyi ekleyin. Devir paketi ayrıca agent'ın arayana ne söylediğini, neyin hâlâ doğrulanmadığını ve arayanın hatta mı beklediğini, geri arama mı beklediğini yoksa başka seçeneklere bakmayı mı sürdürdüğünü belirtmeli.

Sırayla dağıtmayın, sorumluluğa göre yönlendirin. Yük sahibi ya da pazaryeri lead'ini ilgili müşteri ya da hat sorumlusuna, taşıyıcı fırsatını araç tedariki ya da tedarikçi operasyonuna, mevcut bir yükle ilgili soruyu o yükün sorumlusuna gönderin. Eşleşmeyen ya da acil talepler, başında birinin olduğu bir inceleme kuyruğuna gitsin. Adı geçen sorumlu müsait değilse devreye girecek yedeği açıkça tanımlayın. Agent, arayana görüşmeyi aktardığını mı, geri arama oluşturduğunu mu, yoksa talebi ekibin çalıştığı bir sonraki saat aralığı için kaydettiğini mi açıkça söylemeli. Bir insan devri kabul ettiğinde kabulü ve ilk aksiyonu kaydedin. Kuyruğa bırakılan bir görev, tamamlanmış bir görüşmeyle aynı şey değildir.

Takibin sorumlusu kaybolmasın

Birden fazla ekip katkı verse bile, çözülmemiş her talebin hesap veren tek bir sorumlusu olmalı. İş kaydına sorumluyu ya da kuyruğu, istenen aksiyonu, saat dilimi belli bir son saati, arayanın tercih ettiği kanalı ve bir sonraki iletişim aralığını yazın. Takibin nedenini de ekleyin: eksik teslim bilgisi, fiyat incelemesi, taşıyıcı doğrulaması ya da başarısız bir aktarım gibi. Sorumlu değişirse adı sessizce değiştirmeyin, devri kaydedin. Döngüyü bir sonuçla kapatın: teklif verildi, uygun değil, arayana ulaşılamadı, mükerrer, üst seviyeye taşındı, aranmak istemiyor ya da tanımlı başka bir sonuç. Böylece hiçbir transkript sahipsiz bir lead'e dönüşmez.

Tekrar denemeleri ve mesai dışını tasarlayın

Bir durma koşulu tanımlayın. Kaçan aktarım, cevapsız arama ya da yarım kalan geri aramada sonucu kaydedin ve yalnızca izin verilen iletişim aralığında yeniden deneyin. Tek bir takip denemesiyle başlayın; ikinci denemeyi yüksek öncelikli taleplere ya da arayanın tercihine saklayın. Ulaşıldığında, arayan aranmak istemediğini söylediğinde, talep kapandığında ya da deneme sınırı dolduğunda durun. Sisteme yazma başarısız olursa bir döngü değil, operatör için bir istisna kaydı oluşmalı. Deneme geçmişini kanal, zaman damgası, sonuç ve bir sonraki uygun aralıkla birlikte aynı talep üzerinde tutun.

Mesai dışında güzergahı, son tarihi ve aciliyeti alın; yalnızca tanımlı bir nöbet kuralını karşılayan durumları yönlendirin. Kural, devri kimin kabul edebileceğini, o kişiyi uyandırmadan önce hangi bilgilerin gerektiğini ve kimse kabul etmezse ne olacağını belirtmeli. Geri kalan her şey için yapılandırılmış inceleme aralığını söyleyin; ekipte kimsenin olmadığı saatler için yanıt süresi vaat etmeyin. Görüşmeyi bitirmeden önce geri arama numarasını ve arayanın saat dilimini teyit edin. Telefoni kurulumu, çalışma takvimlerini, aktarım hedeflerini, sesli mesaj davranışını ve hata durumlarını görünür kılmalı. Kaydedilen talep bir mesai dışı işareti taşımalı ki sıradaki inceleyen, neden canlı yanıt verilmediğini anlasın.

Bir kez yazın, istisnalarda uyarın

Sisteme yazmayı açmadan önce, alınan talebi doğru nesneyle eşleyin. Yeni bir yük sahibi talebi CRM'de bir lead'e, taşıyıcı teklifi bir tedarikçi ya da kapasite kaydına, mevcut bir yükle ilgili çağrı da TMS'deki yük hareketine ait olabilir. Agent'ın hangi alanları oluşturabileceğini, hangilerini güncelleyebileceğini ve hangilerinin onay gerektirdiğini tanımlayın. Olası mükerrer kayıtları bulmak için telefon numarasını, hesap ya da yük referansını, güzergahı ve zaman aralığını kullanın; eşleşme belirsizse incelemeye gönderin. Entegrasyon idempotent olmalı, yani aynı istek iki kez gelse de sonuç değişmemeli. Tekrarlanan bir çağrı ya da webhook, ikinci bir iş kaydı açmak yerine hedeflenen talebi güncellemeli.

Yapılandırılmış alanları, kaynağı, çağrı kimliğini, izin varsa transkript linkini, güven ya da doğrulama durumunu ve sonraki adımın sorumlusunu yazın. Zorunlu bir eşleme başarısız olursa talebi bir istisna kuyruğunda erişilebilir tutun ve operatöre hangi alanın ya da sistemin hata verdiğini söyleyin. Ses platformu transkripti kaydetti diye teklif talebini başarıyla alınmış saymayın. Sesli kayıt ile TMS ya da CRM arasındaki mutabakat, pilot testlerin ve düzenli incelemenin bir parçası olmalı.

Pilotu kontrollü aşamalarla yürütün

Dar bir kapsamla başlayın: tek bir iş kolu, birkaç araç tipi ve fiyat verme yetkisi yok. Birinci aşamada agent özetlerini ekibin notlarıyla karşılaştırın ve zorunlu alanları ayarlayın. İkinci aşamada alan eşlemeleri, mükerrer kayıt yönetimi ve hata durumları test edildikten sonra TMS ya da CRM'e yazmayı ve yönlendirmeyi açın. Üçüncü aşamada seçili mesai dışı çağrıları, devirleri ve taşıyıcıya özel akışları ekleyin. Süreç boyunca bir insan inceleme yolu açık kalsın. Kapsamı ancak görüşme kayıtları eklenen kapsamın anlaşıldığını gösterdiğinde genişletin.

Her aşama için giriş ve çıkış kapıları koyun. Canlı trafikten önce onaylı bir alan şeması, sorumlu haritası, yedek kuyruk, test senaryoları ve bir durdurma prosedürü hazır olsun. Sisteme yazmayı açmadan önce bir inceleyici örnek kayıtları kaynak görüşmeyle karşılaştırsın, mükerrer kayıt ve hata davranışını teyit etsin. Devirlerden ya da mesai dışı kapsamdan önce test edilmiş hedefler, her sonuç için arayana söylenecek cümleler ve bir nöbetçi sorumlu hazır olsun. Genişleme için sorunsuz geçen bir demo yetmez; çözülmemiş kritik senaryoların onaylanması beklenmeli.

Uç durumları canlıya çıkmadan önce yazın: belirsiz yer adları, çok duraklı yükler, değişen yükleme tarihleri, kötü ses, zorunlu bir alanı vermeyi reddeden arayan, iki ekibe birden düşen bir talep ve görüşme sırasında müsaitliği değişen bir taşıyıcı. Bu durumları canlıda kullanılan prompt, entegrasyonlar ve kuyruklarla birebir çalıştırın. Hızlı bir cevabın kapasite tablosunu nerede bozabileceğini gösterirler. Yeni talep alma aksiyonlarını kapatırken kayıtları incelemeye açık tutan bir geri alma ya da durdurma kontrolü bulundurun.

Kaliteyi inceleyin ve Agent Factory döngüsünü kapatın

Operasyon ve satış sorumlularına düzenli bir örneklemi inceleme görevi verin; bulguları çözmekten sorumlu kişinin adı belli olsun. Arayanın doğru sınıflandırılmasını, zorunlu alanları, tarih ve birimleri, verilen sözlerin dilini, devir gerekçesini, kapasite durumunu ve hedef sistemi puanlayın. Başarılı çağrıların yanında başarısız olanları da inceleyin; hiçbir insana ulaşmamış kayıtlar dahil. İyi bir denetim iki şey sorar: sıradaki operatör görüşmeyi yeniden dinlemeden kayıttan yola çıkarak harekete geçebilir mi, arayana yalnızca sistemin teyit etmesine izin verilen bilgiler mi söylendi?

Metrikleri toplamadan önce tanımlayın. Niteleme tamamlama oranı, uygun teklif talepleri içinde her zorunlu alanı dolu ya da açıkça “bilinmiyor” olarak işaretlenmiş olanların payı olabilir. Alan doluluğu hangi zorunlu alanların mevcut olduğunu göstermeli; alan doğruluğu ise arayanla ya da onaylı sistemle yapılan denetimli bir karşılaştırmadan gelmeli. Başarılı insana devir, aktarımın denenmesi değil, talebin hedeflenen kuyruk ya da kişi tarafından kabul edilmesi demek olmalı. İnsan yanıt süresi görev açıldığında başlamalı, kaydedilen ilk insan aksiyonunda bitmeli. Sisteme yazma başarısı, yalnızca ses platformunda duran kayıtları dışarıda bırakmalı. Mükerrer kayıt oranı, tekrar denemede ulaşma oranı ve insan düzeltme oranı da aynı netlikte bir payda ve zaman aralığı ister.

Tekrarlayan hataları prompt'a, alan şemasına, yönlendirme kurallarına, onaylı cümlelere ve test setine geri besleyin. Her seferinde odaklı tek bir değişiklik yayınlayın, önceki sürümle karşılaştırın, başarılı ve başarısız örnekleri saklayın. Bu inceleme ve iyileştirme döngüsü, DRING'in agent'ları kurduğu, test ettiği ve geliştirdiği sistem olan Agent Factory'nin pratikteki işidir: tek seferlik bir senaryo yazmak değil, bir iş akışını yaşatmak. Kalite inceleme süreci de kararları kapasite operasyonuyla aynı hizada tutar.

Her sürümü bir operasyon değişikliği gibi yönetin

Her sürümün bir numarası, bir sorumlusu, bir değişiklik gerekçesi ve etkilediği bileşenlerin listesi olsun: prompt, veri çıkarma şeması, yönlendirme, onaylı cümleler, entegrasyon eşlemesi ya da tekrar deneme kuralı. Sürümü canlı trafiğe çıkmadan önce sıradan çağrılardan ve uç durumlardan oluşan sabit bir setle test edin. Agent'ın ne söyleyebileceğini, neyi kaydedebileceğini ya da sisteme ne yazabileceğini değiştiren her değişikliği iş sahibine onaylatın. Sınırlı bir kapsamda yayına alın, yeni sürümü öncekiyle karşılaştırın, ilk kayıtları inceleyin ve geri dönüş yolunu açık tutun. Kalite örneklemi, istisnalar ve operatör geri bildirimi incelenmeden sürüm tamamlanmış sayılmaz. Agent Factory yönetişimi böylece somutlaşır: değişiklikler izlenebilir, geri alınabilir ve gözlenen iş akışı davranışına bağlıdır.

Canlıya çıkış kontrol listesi

• Her teklif tipi için zorunlu, isteğe bağlı ve açıkça bilinmeyen alanları tanımlayın.
• Güzergah adlarını, tarihleri, saat dilimlerini, birimleri, aksanları ve sektör kısaltmalarını test edin.
• Agent'ın neyi teyit edebileceğini ve insana devrin tam olarak hangi durumlarda başlayacağını yazın.
• TMS ve CRM alanlarını, mükerrer kayıt kurallarını, başarısız yazma uyarılarını ve sorumlulukları eşleyin.
• Lead, taşıyıcı, mevcut yük ve acil talep yollarını, adı belli kuyruk sorumlularıyla kurun.
• Tekrar deneme sınırlarını, aranmak istemeyenler için davranışı, mesai saatlerini, mesai dışı kuralları ve nöbetçiye aktarımları yapılandırın.
• Kapsamı genişletmeden önce pilot çağrılarını doğruluk, yönlendirme, kapasite durumu ve verilen sözlerin dili ölçütlerine göre inceleyin.
• Metriklerin paydalarını, denetim sorumluluğunu, sürüm onayını, sürüm geçmişini ve geri alma ölçütlerini tanımlayın.
• Bir sorumluya panel, istisna kuyruğu ve sorunlar düzeltilirken akışı durdurabileceği bir yol verin.