Satış öncesi POC nasıl yönetilir: kapsamdan karara kadar

POC nedir ve ne zaman gerekir?

POC (proof of concept, kavram kanıtı), müşterinin kendi ortamında ve kendi verisiyle çözümün belirli bir iş sorununu gerçekten çözdüğünü gösteren sınırlı bir deneme çalışmasıdır. Demo "bu şekilde çalışır" der, POC ise "sizin için de çalışır" kanıtını arar. Bu yüzden POC, tipik olarak demodan sonra, teklif ve sözleşmeden önce gelir ve genellikle teknik riskin ya da entegrasyon belirsizliğinin yüksek olduğu satışlarda gündeme gelir.

Her satışta POC gerekmez. Ürün standartsa, müşterinin kullanım senaryosu bilinen bir kalıba uyuyorsa ve referans müşteriler yeterli güveni veriyorsa POC zaman ve kaynak kaybıdır. Gerekçeler şunlardır: Müşterinin veri yapısı alışılmış değil, çözüm kritik bir sistemle entegre olacak, mevcut çözümden geçiş riski büyük ya da karar kuruluna teknik kanıt sunulması gerekiyor.

POC'yi bir müşteri talebi olarak değil, bir satış kararı olarak ele alın. "Biz bir deneyelim" cümlesine hemen evet demek, çoğu zaman ücretsiz danışmanlık verip sonunda sözleşmesiz kalmanın başlangıcıdır. POC'ye girmeden önce bunun gerçekten ilerleyen bir fırsat olup olmadığını netleştirin.

Girmeden önce: nitelendirme ve kapsam sözleşmesi

POC'nin sonucu çoğunlukla başlamadan önce belirlenir. Bu aşamada yapılacaklar:

• Fırsatı nitelendirin: Gerçek bir bütçe, bir karar verici ve zamanlama var mı? POC bitince olumlu sonuç gelirse satın alma kararı kimin elinde ve hangi sürece bağlı?
• Sorunu tek cümleye indirin: "Fatura işleme süresini kısaltabilir miyiz?" gibi ölçülebilir bir hipotez yazın. Birden çok hedefi aynı POC'ye yüklemeyin.
• Başarı ölçütlerini yazılı hale getirin ve müşteriyle imzalatın ya da en azından e-postayla teyit ettirin. Kriterler ölçülebilir olmalı: hangi metrik, hangi veri üzerinde, hangi eşik değerle başarılı sayılacak?
• Kapsam dışını açıkça listeleyin: Hangi özellikler, hangi entegrasyonlar, hangi kullanıcı gruplarının bu çalışmada olmadığını yazın.
• Süre ve takvimi sabitleyin: POC zaman sınırlı olmalıdır; açık uçlu POC, ek isteklerle genişleyen bir ücretsiz projeye dönüşür.
• Karar toplantısı tarihini baştan koyun: POC bittiğinde sonucu değerlendirip karara bağlayacak toplantı daha başlamadan takvimde olmalıdır.

Bu belgeyi çoğu ekip tek sayfalık bir POC planında toplar. Plan, ileride itiraz çıktığında "ne üzerine anlaşmıştık" sorusunun yanıtıdır.

Rolleri, ortamı ve veriyi hazırlamak

POC'de taraflar kaynak ayırır. Siz tarafta en az şu roller netleşmelidir: POC sahibi (genellikle pre-sales mühendisi), gerektiğinde çağrılacak ürün ve teknik destek uzmanı ve fırsatın sahibi olan satış temsilcisi. Müşteri tarafında ise iş sahibi, teknik sorumlu, veriye erişimi sağlayacak kişi ve karar verici gerekir. Müşteri tarafında kimin ne kadar zaman ayıracağı sözel bir niyet değil, yazılı bir taahhüt olmalıdır. Müşteri kaynak ayıramıyorsa POC sonuç vermez.

Ortam ve veri konusu en sık gecikme sebebidir. Neyi nerede çalıştıracaksınız: kendi bulut ortamınızda ayrı bir kiracı mı, müşterinin ortamında mı? Hangi verilerle: gerçek veri mi, maskelenmiş kopya mı, sentetik veri mi? Kişisel veri içeren kayıtlar için KVKK kapsamında müşterinin bilgi güvenliği ve hukuk ekipleriyle onay süreci gerekebilir ve bu süre takvime eklenmelidir.

Başlamadan önce bir "hazır olma" listesi yapın: erişim yetkileri verildi mi, ağ ve güvenlik duvarı izinleri tamam mı, örnek veri alındı mı, test kullanıcıları tanımlandı mı? Hazır olma listesi tamamlanmadan POC saatini başlatmayın; aksi halde süre ortam sorunlarıyla geçer.

Yürütme: ritim, görünürlük ve kapsam kayması

POC süresince düzenli bir ritim kurun. Sık ve kısa durum toplantıları, karşılıklı ilerlemeyi görünür kılar. Her toplantıda ilerleme başarı ölçütleri üzerinden raporlanmalı: hangi ölçütler karşılandı, hangileri açık, engel ne?

Müşteri sürekli yeni istek getirir: "bunu da deneyebilir miyiz?" Bu, POC'nin en bilinen tehlikesi olan kapsam kaymasıdır. Her yeni isteği şu yollardan birine yönlendirin: Başarı ölçütleriyle doğrudan ilgiliyse ve sürede sığıyorsa plana yazılı olarak ekleyin; değilse "bu, POC sonrası aşamaya alınabilir" deyip kayda alın. Her kabul, başka bir şeyin takvimini kaydırır; bunu müşteriye açıkça söyleyin.

Sorunlar çıkacaktır. Bir entegrasyon beklendiği gibi çalışmayabilir ya da veri kalitesi kötü olabilir. Bu durumda gizlemek yerine hemen paylaşın ve etkisini ölçülü anlatın. Müşteri, zorluk karşısındaki şeffaflığınızı satın alma sonrası destek davranışınız hakkında bir işaret olarak okur.

Çalışmayı kayıt altına alın: yapılan her test, alınan her sonuç, değiştirilen her ayar bir günlükte yer alsın. Hem rapor yazarken hem de itiraz yönetirken bu kayıt değerlidir.

Sonuçları raporlamak ve ticari karara bağlamak

POC'nin amacı iyi geçmesi değil, karara bağlanmasıdır. Bitişte şu adımları izleyin:

• Sonuçları, baştan belirlenen başarı ölçütlerine göre tek tek raporlayın: karşılandı, kısmen karşılandı, karşılanmadı ve nedeni.
• Teknik sonuçları iş etkisine çevirin. Karar vericinin dili metrik değil, iş sonucudur: zaman kazancı, hata azalması, risk düşüşü gibi POC verisinden doğrudan türeyen çıktılar.
• Beklenmeyen bulguları ve sınırlamaları dürüstçe yazın. Müşteri bunları zaten fark etmiştir; sizden duyması güveni artırır.
• Üretime geçiş için gereken işleri çıkarın: entegrasyon çalışmaları, ek yapılandırma, eğitim ve destek modeli.
• Karar toplantısını planladığınız gibi yapın ve toplantıda net bir "bir sonraki adım" isteyin: teklif, sözleşme, genişletilmiş pilot.

Ticari model konusunda net olun. Bazı POC'ler ücretsiz yürütülür, bazıları ücretli ya da sonraki sözleşmeden mahsup edilir. Hangisini seçeceğiniz sektöre ve şirket politikasına bağlıdır; ancak ücretsiz POC'de bile karşı taraftan bir taahhüt (zaman, kaynak, karar tarihi) almak sağlıklı bir ticari disiplindir. Bu ayrıntı çoğu zaman satış yöneticisi ve sözleşme ekibiyle önceden uyumlaştırılmalıdır.

Sık yapılan hatalar

POC yönetiminde tekrarlayan hatalar, birkaç başlıkta toplanabilir:

• Başarı ölçütü olmadan başlamak. Ölçütsüz POC'de "iyi gitti" ya da "beklediğimiz gibi değil" yalnızca bir hissin ifadesidir.
• Karar vericiyi sürece dahil etmemek. Teknik ekip memnun kalsa bile bütçe sahibi hiç görmediği bir çalışmaya onay vermez.
• POC'yi demo gibi kurgulamak. POC müşterinin gerçek verisi ve gerçek süreciyle çalışmalıdır; şirket içi sahte senaryo burada yeterli değildir.
• Açık uçlu süre. Bitiş tarihi olmayan POC'nin sonu da yoktur.
• Çok fazla özelliği aynı anda denemek. Dar ama net bir hipotez, geniş ama bulanık bir hedeften daha çok öğretir.
• Rakip POC'lerini izlememek. Müşteri birden çok satıcıyla aynı anda POC yürütüyorsa karşılaştırma ölçütlerinin aynı olduğundan emin olun.
• Ürün olgunlaşmamış bir özelliği POC'de taahhüt etmek. Zaman baskısı altında verilen söz, POC sonrasında sözleşme riskine dönüşür.

Her POC sonrası kısa bir değerlendirme yapın: Kazansak da kaybetsek de ne öğrendik? Bu kayıtlar sonraki POC'lerin planını ve zamanlamasını iyileştirir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

POC yönetimi; pre-sales mühendisleri, çözüm danışmanları, teknik hesap yöneticileri ve karmaşık B2B satışlarda hem satış hem teknik tarafı birleştiren ekipler için günlük iştir. Hata maliyeti de yüksektir: yanlış kurgulanmış bir POC aylarca kaynak harcatıp satışsız sonuçlanabilir.

Pre-Sales ve Solution Consulting programı, pre-sales rolünü ve satış döngüsündeki konumunu, keşif ve gereksinim analizini, çözüm tasarımını ve mimari konuşmasını, demo mükemmeliyetini ve RFP, POC ve teklif sürecini modül başlıkları olarak sunar. Bir ekibin POC sürecini standartlaştırmak istediğinde bu program rol tanımından teklif aşamasına kadar ortak bir çerçeve verir; POC planı şablonu, başarı ölçütü yazma disiplini ve karar toplantısı alışkanlığı ekip içinde birlikte oturtulabilir.