DoğruTeklif’i neden inşa etmeye başladık?
Teklif toplamak bir e-posta problemi gibi görünüyordu. Aslında güven, sınıflandırma ve karar izi problemiydi.
DEXA COMMUNITY / 2026
Mühendislik ve ürün geliştirme için uygulanabilir teknik bilgi.
BUILD LOG / DT-01
Mühendislik kararları · gerçek proje notları
Görünen problem: teklif istemek
Sanayi tedarikinde ilk bakışta süreç basittir: ihtiyacı yaz, birkaç tedarikçiye gönder, fiyatları karşılaştır. Pratikte ise teknik şartname farklı formatlarda dolaşır, doğru tedarikçiye ulaşmak kişisel çevreye bağlı kalır ve teklifler karşılaştırılabilir biçimde gelmez.
Bu nedenle ekipler teklif toplamaktan çok bilgiyi normalleştirmeye zaman harcar. Son kararın neden verildiği ise çoğunlukla e-posta zincirleri ve Excel dosyaları arasında kaybolur.
Asıl problem: ortak bir karar zemini
DoğruTeklif fikri, yalnızca daha fazla tedarikçi listelemekten doğmadı. Alıcının ihtiyacını doğru sınıflandırabildiği, tedarikçinin gerçekten uygun talepleri görebildiği ve iki tarafın aynı veri üzerinden ilerlediği bir karar zemini oluşturma ihtiyacından doğdu.
Bu yüzden sistemin merkezinde ilan değil RFQ nesnesi var. Teknik dosyalar, termin, para birimi, miktar, teslimat ve değerlendirme bilgileri aynı akışta tutuluyor. Amaç insan kararını ortadan kaldırmak değil; karar için gereken veriyi daha görünür ve izlenebilir hale getirmek.
İlk ürün ilkeleri
DoğruTeklif'i geliştirirken üç ilkeyi koruyoruz:
- Alıcı için talep açmak, dağınık e-posta sürecinden daha zor olmamalı.
- Tedarikçi yalnızca kapasitesi ve uzmanlığıyla eşleşen fırsatları görmeli.
- Teklifler fiyat dışındaki kritik şartlarla birlikte karşılaştırılabilmeli.
İlk sürümün başarısını kayıt sayısıyla değil, nitelikli bir talebin doğru tedarikçilerden karşılaştırılabilir teklif alabilmesiyle ölçeceğiz. Bu seri boyunca veri modeli, kategori sistemi ve ilk kullanıcı akışlarında öğrendiklerimizi paylaşacağız.
KONULAR