Tüm yazılar

Sunum Tasarımı

Ankara Satış Sunumu Hazırlama: Ürün Özelliklerinden Müşteri Kararına

Satış sunumu, ürünün bütün özelliklerini sıraladığında değil, müşterinin karar sorularını cevapladığında işe yarar. İhtiyaç, öneri, kanıt, uygulama ve sonraki adımı birbirine bağlayan bir içerik düzeni kuruyoruz. Farklı paydaşlar için anlatının nasıl uyarlanacağını ve düzenlenebilir dosyanın nasıl test edileceğini de ele alıyoruz.

16 Ekim 2026·91 Ajans·6 dk okuma

Sunumu ürün listenizden önce müşterinin işiyle açın

Satış sunumlarının sık görülen sorunu bilgi eksikliği değil, bilgilerin müşterinin kararından kopuk olmasıdır. Şirket tarihi, ekip sayısı ve bütün ürün özellikleri arka arkaya geldiğinde müşteri kendi ihtiyacına hangi bölümün cevap verdiğini aramak zorunda kalır. Ankara'da bir üreticiye bakım çözümü sunan ekiple, bir teknoloji şirketine kurumsal yazılım anlatan ekibin dili farklı olabilir. İkisinde de başlangıç noktası, alıcının tamamlamak istediği iştir. Sunumun sırası buna göre kurulmalıdır.

Görüşme öncesinde müşterinin durumunu bildiğiniz kadarıyla yazın: mevcut yöntem, zorlandığı adım, etkilenen ekip ve değerlendireceği seçenekler. Bilinmeyenleri kesin bilgi gibi sunmayın; görüşmede doğrulanacak sorular olarak ayırın. Örneğin “teklif hazırlama süreniz uzun” demek yerine hangi adımların bekleme yarattığını sormak daha yararlı olabilir. Sunum, müşteriyi tanıyormuş gibi davranmak yerine doğru soruları konuşmaya açmalıdır. Bu hazırlık, standart dosyanın hangi bölümlerinin kullanılacağını da belirler.

Karar verenlerle kullananların sorularını ayırın

Bir B2B satışta tek izleyici bulunmayabilir. Günlük kullanıcı, teknik ekip, satın alma ve yönetim farklı sorular sorar. Kullanıcı işinin kolaylaşıp kolaylaşmayacağını, teknik ekip uyumluluğu, satın alma kapsamı, yönetim ise kararın etkisini değerlendirebilir. Bütün paydaşlara aynı slaytları aynı ayrıntıyla sunmak çoğu zaman gereksiz yük oluşturur. Ana dosyada ortak çerçeve kurulup ek bölümlerde farklı soruların cevapları tutulabilir. Amaç herkese ayrı bir gerçek anlatmak değil, aynı çözümü ilgili açıdan açıklamaktır.

Paydaş haritası hazırlarken yalnızca unvanları yazmayın. Her grubun hangi bilgiyi görmek istediğini, hangi kaygıyı taşıdığını ve sonraki adımda ne yapacağını belirtin. Teknik inceleme tamamlanmadan ticari karar verilemiyorsa bu bağımlılık sunum planına yansıtılmalıdır. Bir toplantının amacı ilk keşifken son teklif dosyası gibi konuşmak erken olabilir. CRM iş akışı rehberindeki aşama tanımları, sunumun satış sürecindeki yerini belirlemek için kullanılabilir. Dosyanın amacı bulunduğu aşamayla uyumlu olmalıdır.

Özelliği faydaya bağlarken açıklama zincirini koruyun

Bir özelliğin adını yazıp yanına “verimlilik sağlar” eklemek çoğu zaman yeterli değildir. Özellik hangi davranışı değiştirir, bu değişiklik hangi işi kolaylaştırır ve müşteri bunu nasıl gözleyebilir? Örneğin ortak teklif geçmişi, satış temsilcisinin farklı e-postaları taramasını azaltabilir; fakat bunun etkisi kullanılan sürece bağlıdır. Sunumda neden ve sonuç ilişkisini açık anlatın. Kanıtlanmamış süre veya kazanç oranları eklemek yerine işleyişi gösterin. Böylece iddianın sınırı da anlaşılır kalır.

Her özellik için ayrı slayt hazırlamak zorunda değilsiniz. Müşterinin bir görevi üzerinden ilgili özellikler birlikte gösterilebilir. Bir servis kaydının açılması, göreve atanması ve kapanış bilgisinin görünmesi gibi bir senaryo, dağınık menü ekranlarından daha açıklayıcı olabilir. Ekran görüntüsü kullanılıyorsa gerçek kişisel veya ticari bilgiler temizlenmelidir. Henüz üründe bulunmayan bölüm, varmış gibi sunulmamalıdır. Demo ile planlanan geliştirme arasındaki ayrım satış ekibinin anlatımında da dosyada da açık olmalıdır.

Kanıtı müşterinin sorusuyla eşleştirin

Referans logosu tanınırlık sağlayabilir, ancak alıcının belirli kaygısını tek başına cevaplamaz. Benzer kapsamın nasıl ele alındığı, teslim edilen işin ne olduğu veya uygulama sürecinin nasıl yürüdüğü daha açıklayıcı olabilir. Yayınlanabilir proje bilgisi yoksa uydurma vaka yazmak yerine yöntem ve örnek iş akışı gösterin. Temsili senaryo kullanıldığında bunun örnek olduğu anlaşılmalıdır. Sunumun güveni, her boşluğun bir başarı hikâyesiyle kapatılmasına bağlı değildir.

Veri sunulacaksa dönem, kaynak ve kapsam belirtilmelidir. Bir ürünün farklı müşterilerde aynı sonucu üreteceği varsayılmamalıdır. Önceki bir projeden alınan bilgi yeni bağlam için doğrudan garanti değildir. Kanıt slaytının amacı karar sorusunu aydınlatmaktır. “Bu çözüm bizim işimize uyarlanabilir mi?” sorusu için süreç örneği, “ekip nasıl devralacak?” sorusu için eğitim ve teslim planı daha yararlı olabilir. Kullanılan kanıt türü ile müşterinin değerlendirdiği risk arasında açık bir ilişki kurulmalıdır.

Uygulama ve kapsamı satış anlatısının parçası yapın

Müşteri yalnızca öneriyi değil, uygulamanın kendi ekibinden ne isteyeceğini de bilmek ister. Gerekli veriler, karar verecek kişiler, başlangıç hazırlıkları ve temel teslimler sunumda anlaşılır biçimde gösterilebilir. Zaman planı kesinleşmediyse koşullar açıkça belirtilmelidir. “Hızlı kurulum” gibi genel bir ifade yerine hangi hazırlık tamamlandığında hangi aşamanın başlayacağını anlatmak daha yararlıdır. İşletmenin katkısı görünmez bırakılırsa satış sonrası beklenti farkı oluşabilir.

Kapsama dahil olmayan işler de uygun yerde açıklanmalıdır. Yeni geliştirme, veri temizliği veya dış sistem erişimi gibi kalemler müşterinin kararını etkileyebilir. Bu ayrıntıları ana akışta uzun bir şartnameye dönüştürmek gerekmez; ancak görüşmede erişilebilir olmalıdır. Kurumsal sunum hazırlama rehberindeki ana akış ve ek bölüm ayrımı burada işe yarar. Sunumla yazılı teklifin farklı kapsamlar anlatmaması için iki dosya birlikte kontrol edilmelidir.

Canlı anlatım ve gönderilen dosya farklı ihtiyaç taşır

Toplantıda konuşmacı açıklama yapabildiği için slaytlar daha kısa olabilir. Sonradan e-postayla paylaşılan dosya ise tek başına okunacaktır. Gerekirse gönderim sürümünde kısa açıklamalar ve kapsam notları bulunabilir. İki sürümün ayrı kaynaklardan güncellenmesi çelişki yaratabilir; ortak içerik havuzu kullanmak daha kontrollüdür. Her slaytta bütün metni okumak da doğru çözüm değildir. Konuşmacı notları, ana mesajı ve örnekleri hatırlatmak için kullanılabilir. Görsel akış anlatımı desteklemelidir.

Microsoft'un sunucu görünümü rehberi, konuşmacı notlarının izleyici ekranından ayrı görüntülenmesini açıklar. Kullanacağınız bilgisayar ve toplantı ortamında bu düzeni önceden deneyin. Ekran paylaşımında yanlış pencerenin görünmesi veya notların açığa çıkması son dakika sorunu olmamalıdır. Ayrıca PDF sürümünde bağlantıların ve grafiklerin doğru göründüğünü kontrol edin. Satış sunumunun kullanılacağı ortam, dosyanın son kontrolünü belirler; yalnızca editör görünümünde incelemek yeterli değildir.

Kapanışı bir sonraki kararı kolaylaştıracak biçimde kurun

Her satış sunumunun sonunda doğrudan satın alma kararı beklemek gerçekçi olmayabilir. Teknik değerlendirme, ihtiyaç atölyesi, örnek veri paylaşımı veya kapsam görüşmesi gibi daha yakın bir adım bulunabilir. Bu adımın amacı ve sorumluları açık olmalıdır. “İletişimde kalalım” cümlesi yerine hangi bilginin kim tarafından paylaşılacağını konuşun. Son slayt, toplantıda yapılan değerlendirmeyi toparlayıp ilerlemek için gereken kararı görünür kılmalıdır. Satış sürecinin aşaması, kapanışın biçimini belirler.

Sunum ajanslığı hizmeti için brief hazırlarken standart şirket dosyanızın yanında müşteri sorularını ve satış ekibinin sık karşılaştığı itirazları da paylaşın. Tasarımın başarısını yalnızca slaytların beğenilmesiyle değerlendirmeyin. Ekibiniz dosyayı güncelleyebiliyor mu, müşteri öneriyi kendi işine bağlayabiliyor mu ve sonraki adım anlaşılabiliyor mu? Bu sorulara verilen cevaplar satış sunumunun gerçek kullanımını gösterir. İyi hazırlanmış bir dosya, konuşmayı ürün listesinden çıkarıp müşterinin kararını değerlendirebileceği açık bir zemine taşır.

Birlikte çalışalım

Okumak güzeldi.
Şimdi üretelim.

Projeyi anlat