30 saniyelik özet

Teklif talebi, bir kurumun ihtiyacını açıklayarak tedarikçilerden karşılaştırılabilir çözüm ve ticari öneriler istemesidir. İngilizce Request for Proposal ifadesinin kısaltması RFP'dir. Alıcı açısından amaç, uygun çözümü seçmeye yardımcı olacak kanıt toplamaktır. İş geliştirme ekibi açısından ise müşterinin problemini anlayıp şirketin bu ihtiyacı hangi koşullarda karşılayabileceğini göstermektir. İyi bir RFP süreci; açık gereksinimler, değerlendirme ölçütleri, doğrulanabilir yanıtlar ve tutarlı taahhütler üzerine kurulur. Dosyanın zamanında tamamlanması önemlidir; ancak asıl başarı, teklifin uygulanabilir ve ekonomik açıdan anlamlı olmasıdır.

Neden önemli?

Bir satın alma ekibi tedarikçilerden serbest biçimde teklif istediğinde, her şirket farklı kapsam, varsayım ve fiyat yapısı sunabilir. Birinin fiyatı yalnızca lisansı, diğerinin fiyatı kurulum ve desteği de kapsar. Görünüşte aynı ihtiyaca verilen yanıtlar, gerçekte farklı işler önerir. RFP, bu karşılaştırma sorununu azaltmaya yardımcı olur.

Bunun için belgenin yalnızca özellik listesi olması yeterli değildir. İş probleminin, mevcut ortamın ve beklenen sonuçların açıklanması gerekir. Aksi halde tedarikçiler, müşterinin neden istediğini bilmedikleri maddelere olumlu yanıt vermeye çalışır. Alıcı da ihtiyaca uygunluğu değerlendirmek yerine işaretlenmiş kutuları saymaya başlayabilir.

İş geliştirme tarafında RFP önemli bir kaynak tahsis kararıdır. Teknik uzmanların, finansın, hukukun ve ürün ekiplerinin zamanı kullanılır. Şirketin karşılayamayacağı zorunlu koşullar veya zayıf rekabet konumu varsa, büyük sözleşme ihtimali tek başına teklif hazırlamayı haklı çıkarmaz.

Yönetici bakışı, kazanılan sözleşmenin sonrasını da kapsar. Teklifte verilen teslimat ve ürün taahhütleri, uygulama ekiplerinin yükümlülüğüne dönüşebilir. Bu nedenle RFP yanıtı satış ekibinin hazırladığı bağımsız bir metin olarak kalmamalıdır. Gereksinimler, kapasite ve ticari koşullar aynı teklif içinde tutarlı olmalıdır.

Terim nedir?

RFP, alıcının çözüm ihtiyacını, yanıt beklentilerini ve değerlendirme çerçevesini tarif eden yapılandırılmış taleptir. İş kapsamı, gereksinimler, mevcut sistemler, takvim, teklif formatı, fiyatlandırma beklentisi ve soru iletme yöntemi gibi bölümler içerebilir. İçeriği satın alınacak işin niteliğine göre değişir.

Bilgi talebi, İngilizce Request for Information veya RFI, pazardaki seçenekleri ve tedarikçi yeteneklerini anlamak için kullanılabilir. Fiyat teklifi talebi, Request for Quotation veya RFQ, kapsamın daha belirgin olduğu durumlarda fiyat ve koşul karşılaştırmasına odaklanabilir. RFP ise tedarikçinin çözüm yaklaşımını da değerlendirmeye açar. Kurumların bu adları farklı kullanabildiği unutulmamalı; belgenin fiilî beklentisi okunmalıdır.

Tedarikçi önce teklif verip vermeme kararını alır. İngilizce bid/no-bid olarak anılan bu karar; çözüm uyumu, zorunlu koşullar, müşteri ihtiyacına erişim, teslimat kabiliyeti ve ekonomik değer üzerinden değerlendirilir. Teklif vermeme kararı, uygun olmayan fırsatlarda kaynakları koruyabilir.

Teklif hazırlanacaksa her gereksinim için yanıt sahibi ve doğrulama kaynağı belirlenir. Gereksinimin standart ürünle, yapılandırmayla veya ek geliştirmeyle karşılanması farklı durumlardır. “Karşılanıyor” ifadesi bu ayrımları gizlememelidir. Ürün planında bulunan bir yetenek, bugün kullanılabilen özellik gibi sunulmamalıdır.

Gerçek vaka: Zendesk'in RFP yanıtlarını ortak içerikle yönetmesi

Loopio'nun yayımladığı müşteri vaka çalışması, Zendesk'in RFP ekibinin dağınık bilgiyi bulma ve yeniden kullanma güçlüğünü anlatıyor. Yanıt içeriklerinin merkezi ve aranabilir bir yapıda düzenlendiği; ürün, gizlilik ve sektör gibi ayrımlarla etiketlendiği belirtiliyor. Süreç, hukuk ve güvenlik gibi farklı uzmanlık alanlarını da bir araya getiriyor.

Kaynağa göre resmi müşteri dokümantasyonunu RFP iş akışına bağlayan özel entegrasyon, uzmanlara yönelen tekrar sorularını azaltmayı ve yanıt tutarlılığını geliştirmeyi destekledi. Küçük küresel ekibin ek personel almadan yılda 400'den fazla RFP'yi desteklediği, yanıt süreçlerinde yüzde 70'e varan verimlilik artışı sağlandığı bildiriliyor.

Bunlar çözüm sağlayıcısının yayımladığı müşteri sonuçlarıdır. Metin, kazanma oranının aynı ölçüde arttığını göstermiyor; verimlilik ölçümünün bütün ayrıntılarını da sunmuyor. Vakadan çıkarılabilecek ders, tekrar kullanılabilir içeriğin aranabilir ve güncel tutulmasının koordinasyonu kolaylaştırmasıdır. Hazır yanıtlar, her müşterinin kapsamına göre yeniden değerlendirilmelidir.

Kaynak: Loopio, Zendesk Automates and Scales RFP Delivery, Increasing Efficiency up to 70% with Loopio.

Varsayımsal örnek: Bankanın müşteri hizmetleri platformu seçimi

Bir banka, müşteri hizmetleri platformunu yenilemek için RFP gönderir. Belgede farklı kanallardan gelen taleplerin ortak kayıtta tutulması, mevcut müşteri sistemiyle entegrasyon ve belirli raporların hazırlanması istenir. Bir yazılım şirketinin iş geliştirme ekibi, yanıt hazırlamadan önce zorunlu gereksinimleri inceler.

Ürün ekibi ana işlevlerin mevcut olduğunu, ancak bazı raporların özel geliştirme gerektirdiğini belirtir. Teknik ekip entegrasyonun yapılabileceğini düşünür; erişilebilir arayüzler ve veri kalitesi hakkında ek bilgi ister. İş geliştirme ekibi bu belirsizlikleri müşteriye ayrılan soru döneminde iletir. Yanıt alınmayan konular teklif varsayımları içinde açıkça gösterilir.

Teklif verme kararı sonrasında bir gereksinim matrisi hazırlanır. Her satırda müşterinin isteği, önerilen çözüm, kapsam sınırlaması, kanıt ve yanıt sorumlusu yer alır. Finans ekibi fiyatın hangi hizmetleri kapsadığını açıklar. Teslimat ekibi, müşterinin sağlaması gereken verileri ve personel katılımını takvimle ilişkilendirir.

Son kontrolde teknik metin ile ticari teklif karşılaştırılır. Teknik bölümde dahil görünen bir raporun fiyat tablosunda ek hizmet olması düzeltilir. Teklif gönderildiğinde ekip, yalnızca dosyanın ulaşıp ulaşmadığını izlemez; gelen açıklama sorularını ve değerlendirme sonucunu da kaydeder. Sözleşme aşamasına geçilirse, kabul edilen kapsam teslimat ekibine aynı gereksinim matrisiyle aktarılır.

Yaygın üç hata

  1. Her RFP'ye yanıt vermek

Büyük görünen fırsatlar, kapasiteyi hızla tüketebilir. Zorunlu gereksinimlere uyum, teklif hazırlama yükü ve uygulanabilirlik başlangıçta değerlendirilmelidir. Eksik bilgi varsa bunun kararı nasıl etkilediği belirtilmelidir. Bir fırsata kaynak ayırmak, başka bir fırsatı takip etmek için daha az zaman bırakır.

  1. Eski yanıtları kontrol etmeden kullanmak

Ürün yetenekleri, hizmet koşulları ve teknik belgeler değişebilir. Önceki bir müşteriye verilmiş yanıt yeni müşterinin bağlamına uymayabilir. İçerik kütüphanesinde sorumlu kişi, son inceleme tarihi ve kaynak tutulmalıdır. Tekrar kullanım, doğrulama ihtiyacını ortadan kaldırmaz.

  1. Bütün gereksinimlere koşulsuz olumlu yanıt vermek

Kazanmak için belirsizlikleri gizlemek, uygulama sırasında kapsam anlaşmazlığı yaratabilir. Standart yetenek, ek çalışma ve müşteri bağımlılığı açıkça ayrılmalıdır. Henüz doğrulanmamış bir özellik için kesin taahhüt verilmemelidir. Güçlü teklif, sınırları saklamak yerine uygulanabilir çözüm yolunu gösterir.

Mini uygulama / şablon

RFP geldiğinde önce kısa bir fırsat değerlendirmesi hazırlayın:

Müşterinin çözmek istediği problem
—
Zorunlu koşullara uyum
—
Çözümün güçlü ve zayıf yönleri
—
Açıklama gerektiren konular
—
Teklif hazırlama ve teslimat kapasitesi
—
Beklenen ekonomik değer
—
Teklif verme kararı ve gerekçesi
—

Karar olumluysa her gereksinim için şu alanları kullanın:

Gereksinim numarası ve metni
—
Karşılama biçimi
—
Kanıt veya referans belge
—
Varsayım ve kapsam sınırı
—
Yanıt sahibi
—
Kontrol edecek uzman
—
Fiyat ve takvim etkisi
—
Son onay durumu
—

Gönderim öncesinde yanıtların tutarlılığını, açık kalan soruları ve ticari kapsamı birlikte kontrol edin. Sonrasında yeniden kullanılabilir bilgileri güncelleyin. Yanıt hazırlama süresini izlerken kazanılan ve kaybedilen fırsatların gerekçelerini de değerlendirin. Hızlı tamamlanan dosyalar kadar doğru seçilen fırsatlar da iş geliştirme performansını belirler.

İlgili terimler

Bilgi talebi, Fiyat teklifi talebi, Gereksinim analizi, Gereksinim izlenebilirliği, Teklif yönetimi, Ticari karar masası, Sözleşme yönetimi, Kapsam yönetimi, Satış etkinleştirme, İş gerekçesi