Forwarder Satış Süreci: Navlun Teklifinden Sözleşmeye

Forwarder satış süreci, bir hattın fırsata açılmasından sözleşmeye kadar yedi adımdan oluşur: hat, nitelendirme, fiyat çalışma, teklif, müzakere, kazanma ve operasyona devir. Her pazarlık turu ayrı bir teklif sürümü olarak saklanır; booking, konşimento ve araç takibi ise bu sürecin dışında, TMS’te kalır.

Forwarder satış süreci nedir, TMS’teki operasyondan farkı ne?

Forwarder satış süreci CRM’de izlenir: yük sahibi firma, fiyat talebi, teklif sürümleri, takip görevleri ve yıllık sözleşme. TMS (taşımacılık yönetim sistemi) ise satılan yükün operasyonunu yürütür: booking, konşimento, araç ve sürücü planlaması, sevkiyat takibi. İkisi aynı soruya yanıt vermez: CRM “bu hatta hangi fiyatı, kime, ne zaman verdik?” sorusunu, TMS ise “bu yük şu an nerede?” sorusunu yanıtlar.

Bu ayrımı bilmek önemli, çünkü sektör derneği düzeyinde de satış ve operasyon ayrı çalışır. UTİKAD (Uluslararası Taşımacılık ve Lojistik Hizmet Üretenleri Derneği), 1986’da UNMAD adıyla otuz üye firmayla kurulmuş, uluslararası forwarder ve lojistik hizmet sağlayıcılarını bir araya getiren bir sektör derneğidir ve dünya çapındaki forwarder derneklerini bir araya getiren federasyon FIATA’ya üyedir (UTİKAD). CRM ise bu operasyonel tarafın değil, satışın kaydını tutar.

Navlun teklif takibi neden Excel’de ya da e-postada zorlaşır?

Fiyat talebi e-postadan, telefondan ve WhatsApp’tan aynı anda gelir; hattın fiyatını genelde tek bir kişi bilir, o kişi izindeyken talep saatlerce bekler. Aynı hat için iki temsilci iki ayrı fiyat verebilir, çünkü teklifin hangi kurla ve hangi geçerlilik tarihiyle çıktığı bir PDF’in ya da e-posta zincirinin içinde kalır. Teklif gönderildikten sonra geri dönüş tarihi kimsenin takviminde olmaz; müşteri sessizleşir, yük başka firmayla yola çıkar ve bunun nedeni kayda hiç geçmez.

Forwarder satış süreci nasıl kurulur, hangi adımlardan oluşur?

Bir forwarder ya da nakliye firmasının kurabileceği yedi adım, sorumlusu ve çıktısıyla:

1. Hat fırsat olarak açılır. Sorumlu: satış temsilcisi. Çıktı: çıkış, varış, taşıma modu, ekipman ve yükleme tarihi yazılı bir fırsat; sorumlusu belli.
2. Nitelendirme yapılır. Sorumlu: satış temsilcisi. Çıktı: hacim, sefer sıklığı, teslim şekli ve kararı veren kişi kayıtta; taşınamayacak yük burada bir kayıp nedeniyle kapatılır.
3. Fiyat çalışılır. Sorumlu: satış/fiyatlandırma. Çıktı: armatörden, taşıyıcıdan ya da acenteden en az bir alış fiyatı fırsata eklenir, hedef satış fiyatı belirlenir.
4. Teklif gönderilir. Sorumlu: satış temsilcisi. Çıktı: para birimi ve geçerlilik tarihi olan bir teklif sürümü müşteriye gider, takip görevinin tarihi belli olur.
5. Müzakere edilir. Sorumlu: satış temsilcisi. Çıktı: yeni bir teklif sürümü ya da müşterinin söylediği rakip fiyat fırsata not edilir.
6. Fırsat kazanılır. Sorumlu: satış müdürü. Çıktı: yazılı onay, imzalı navlun sözleşmesi ya da ihale kararı fırsata eklenir; yıllık işte başlangıç ve bitiş tarihi yazılır.
7. Operasyona devredilir. Sorumlu: satış temsilcisi. Çıktı: devir notu ve anlaşılan koşullar operasyon ekibine, booking TMS’te açılır.

Dördüncü ve beşinci adım en çok karışan adımlardır: bir e-posta zincirinde üçüncü revizyonun mu, dördüncü revizyonun mu geçerli olduğu unutulur. İkisini fırsatın üzerine, sürüm sürüm taşımak, hangi rakamın müşteriye en son sunulduğu tartışmasını ortadan kaldırır. Sürüm ve onay düzenini teklif revizyon ve onay akışı yazısında ayrıntılı anlattık.

Teklif sürümleri nasıl izlenir?

Aşağıdaki rakamlar açıklama amaçlı bir örnektir, gerçek bir teklifi göstermez. Bursa–Stuttgart hattı için bir teklif üç sürümden geçebilir: v1, ilk fiyat teklifi olarak 1.850 EUR’dan, on günlük geçerlilik tarihiyle çıkar. Müşteri hacmi artırınca v2, aynı hat için 1.720 EUR’a iner ve yeni bir geçerlilik tarihi alır. Müşteri rakip firmadan 1.680 EUR duyduğunu söylediğinde v3 hazırlanır; bu sefer ödeme vadesi de değişir. Her sürüm ayrı bir kayıt olarak saklanır: v3 kazanılsa bile v1 ve v2 silinmez, böylece hangi rakamın ne zaman ve neden değiştiği geriye dönük okunabilir.

Geçerlilik tarihi geçen bir teklifin durumunu elle takip etmek yerine, sistemin kendiliğinden “süresi doldu” olarak işaretlemesi ve tarihi yaklaşan teklifleri bir raporda toplaması, satış temsilcisinin her sabah tek tek kontrol etmesinin önüne geçer.

Lojistik CRM kurulumunda hangi alanlar olmalı?

• Çıkış ve varış. Hat, fırsatın başlığında ya da özel alanında net yazılı olmalı.
• Taşıma modu ve ekipman. Karayolu/denizyolu/havayolu ve konteyner/araç tipi gibi bilgiler filtrelenebilir alanlar olmalı.
• Teklifin para birimi ve geçerlilik tarihi. Her teklif kendi kurunu ve süresini taşımalı, fırsatın genel para biriminden bağımsız olabilmeli.
• Alış fiyatı ve marj. Fiyatlandırmayı yapan ekip görmeli, satış temsilcisinin ekranında zorunlu olarak görünmemeli.
• Sözleşme başlangıç ve bitiş tarihi. Yıllık sözleşmeler için bitiş, bir hatırlatmayı tetikleyebilmeli.
• Kayıp nedeni. Kaybedilen fırsatta rakip fiyatın ya da nedenin seçilebilmesi, sonraki teklifleri doğru ayarlamaya yarar.

Genel amaçlı CRM mi, lojistiğe özel yazılım mı?

Navlun teklif takip programı kurulurken sık yapılan hatalar

• Teklifi e-posta zincirinde bırakmak. Son geçerli sürümün hangisi olduğu, zincir uzadıkça aranır hale gelir.
• Alış fiyatını satış fiyatıyla aynı alana yazmak. Marjı korumak isteyen ekipler için bu, yanlışlıkla paylaşılan bir bilgiye dönüşür.
• Takip görevini teklifle birlikte açmamak. Görev yoksa, gönderilen teklifin geri dönüşü kimsenin ajandasında olmaz.
• Kayıp nedenini yazmamak. Neden kaydı olmadan, aynı hatta neden sürekli kaybedildiği aylar sonra bile anlaşılamaz.
• Yıllık sözleşmenin bitişini yalnız bir tabloda tutmak. Tablo güncellenmezse, müşteri yeni ihaleye çıktığında hazırlık sıfırdan başlar.

Örnek: Kahramanmaraş merkezli altı kişilik bir forwarder satış ekibinde kurulum

Aşağıdaki firma ve rakamlar açıklama amaçlı bir kurgudur; gerçek bir firmayı ya da bir Senitix müşterisini anlatmaz. Kahramanmaraş merkezli, ağırlıkla Avrupa hatlarına çalışan altı kişilik bir forwarder satış ekibi, fiyat tekliflerini kişisel e-posta hesaplarından gönderiyor, hangi teklifin hangi müşteriye, hangi kurla gittiğini yalnızca gönderen temsilci biliyordu. Bir temsilci ayrıldığında, elindeki açık teklifler haftalarca kimseye devredilmedi.

Ekip önce her hattı bir fırsat olarak açmaya, teklif revizyonlarını sürüm olarak kaydetmeye başladı; teklif gönderildiğinde otomatik bir takip görevi açılmasını sağladılar. İki ay sonra fark şuydu: bir temsilci izindeyken müşteri aradığında, başka bir temsilci fırsat kaydına bakarak hangi sürümün son gönderildiğini ve geçerlilik tarihini anında söyleyebiliyordu. Daha önce aynı durumda müşteriyi “kontrol edip döneceğiz” diyerek bekletiyorlardı.

Yenilemeyi kaçırmamak için hangi göstergeler izlenmeli?

Üç gösterge yenilemenin gözden kaçmasını önler:

• Bitişe yaklaşan sözleşmeler raporu. Bitiş tarihine göre sıralanan bir liste, son haftaya kalmadan görülür.
• Hatta göre kazanma/kayıp oranı. Hangi hatta sürekli kaybedildiği, rakip fiyat notlarıyla birlikte okunur.
• Yanıt bekleyen teklifler. Geçerlilik tarihi yaklaşan ya da geçmiş teklifler, takip görevi açılmamışsa ayrıca listelenir.

Senitix CRM’de navlun teklifinden sözleşmeye süreç nasıl kurulur?

Yukarıdaki yedi adım Senitix CRM’de şöyle karşılık bulur: her fiyat talebi bir fırsat olarak açılır, hat ve ekipman bilgisi özel alanlara yazılır. Teklif katalogdan hazırlanır ve teklif yönetimi bölümünde anlattığımız gibi her revizyon, kendi para birimini ve geçerlilik tarihini taşıyan ayrı bir sürüm olarak saklanır. Bir otomasyon kuralı, teklif “gönderildi” aşamasına geçtiğinde tarihli bir takip görevi açar. Kabul edilen teklif, kalemleri yeniden yazılmadan sözleşmeye dönüşür; sözleşmenin bitiş tarihine bağlı bir otomasyon da süre dolmadan sorumluya bildirim gönderir.

Senitix CRM’in TMS ya da booking sistemiyle hazır bir bağlantısı yoktur; bu kayıtlar CSV ya da Excel ile aktarılır, özel bir entegrasyon ihtiyacı satış ekibimizle görüşülür. Muhasebe programınız Paraşüt ya da Mikro ise bağlantı hazırdır: cari kartlar ve satış faturaları CRM’e gelir, e-Fatura ve e-Arşiv bağlı hesap üzerinden gönderilir. Bu kurulumun sektörün geneline nasıl oturduğunu Lojistik ve Dış Ticaret sayfamızda, farklı sektörlerden örnekleri ise müşteriler sayfamızda görebilirsiniz. Ücretsiz başlayabilir, hat alanlarını ve teklif sürecini firmanıza göre nasıl kuracağınızı satış ekibimizle konuşabilirsiniz. Plan ayrıntıları fiyatlandırma sayfasında.

Sık sorulan sorular

Forwarder satış ekibi ücretsiz bir CRM ile başlayabilir mi?

Evet. Senitix CRM’in Ücretsiz planı 2 kullanıcıya kadar süresiz ücretsizdir. Hat için özel alanların, teklif sürümlerinin ve otomasyonların hangi planda olduğunu fiyatlandırma sayfasında görebilirsiniz. Ücretli planları 14 gün boyunca ücretsiz deneyebilirsiniz, kredi kartı gerekmez; deneme sonunda çalışma alanınız verileriyle Ücretsiz planda kalır.

Dövizli navlun teklifi bu CRM’de hazırlanabilir mi?

Evet. Bunun için CRM’in birden fazla para birimini tanıması ve teklifin kendi kurunu ayrı taşıması gerekir. Senitix CRM’de her teklif kendi para birimini taşır; böylece Avrupa hattına avro, yurt içi taşımaya Türk lirası cinsinden teklif verebilirsiniz.

Navlun teklifinin geçerlilik tarihi geçince ne olur?

İyi kurulmuş bir lojistik CRM’inde teklif, geçerlilik tarihi geçince kendiliğinden “süresi doldu” durumuna geçer ve müşteriye eski rakamla dönülmesi önlenir. Senitix CRM’de bu davranış teklif sürümleriyle birlikte çalışır; tarihi yaklaşan teklifler ayrıca raporda listelenir.

Alış fiyatını satış temsilcisinden gizleyebilir miyiz?

Evet, alanları role göre gizleyebilen bir CRM’de bu mümkündür: alış fiyatı ve marj yalnızca fiyatlandırmayı yapan role açılır, temsilci satış fiyatı ve teklif sürümüyle çalışır. Senitix CRM’de bunu rol ve alan izinleriyle kurarsınız: alış fiyatını özel alan olarak ekler, alanı yalnızca fiyatlandırma rolüne açarsınız.

Yıllık navlun sözleşmesinin yenilenmesini kim takip etmeli?

Sözleşmenin bir sorumlusu net olmalı. İyi kurulmuş bir lojistik CRM’inde yürürlükteki sözleşmenin sorumlusu bitişten belirli bir süre önce bildirim alır ve yenileme, mevcut sözleşmeden taslak bir yeni kayıt olarak başlar. Sorumlu belirsizse yenileme genelde ancak müşteri yeni ihaleye çıktığında fark edilir.