Teklif talebini yapay zekâyla okumak: şartname–yanıt uygunluk matrisi.

İyi yazılmış bir teklif zorunlu şartı karşılamayabilir

Müşterinin teklif talebi uzun bir PDF olarak geliyor. Satış ekibi özet çıkarıp fiyat bölümüne geçmek istiyor. Fakat bir cümledeki ‘bağlantısız ortamda çalışmalıdır’ şartı mevcut ürünün mimarisiyle uyuşmuyorsa, akıcı bir teklif metni temel engeli gizleyebilir. Şartnameyi AI ile işlerken önce her gereksinimin izini koruyan bir matris hazırlayın. Teklifin güzel anlatılması, ürünün belirtilen koşullarda çalışabildiğine kanıt değildir.

Bu örnekte kurumsal müşteri Koru'nun altı şartını, kurgusal Pera ürünü için hazırlanmış üç belgeyle karşılaştıracağız. İsimler, yetenekler, süreler ve paketler sentetiktir; gerçek bir ürünün özelliklerini anlatmaz. Çıktı fiyat teklifi değil, teklif hazırlamanın hangi noktalarda mümkün olduğunu gösteren uygunluk dosyasıdır. Önce şartları ayıracağız, sonra kaynaklarla eşleştirecek, en sonunda karşılanamayan maddeleri saklamayan bir yanıt taslağı yazacağız.

Şartın zorunluluğunu ve ölçülebilir ifadesini koruyun

Bir satırda birden fazla şart varsa onları ayrı kimliklere bölmek daha güvenilirdir. ‘CSV ve PDF çıktı’ tek hücrede tutulduğunda yalnız CSV desteğiyle maddenin tamamı karşılanmış sayılabilir. Burada R1 yalnız CSV'dir; PDF özelliği istenmediği için eklemiyoruz. Benzer biçimde 72 saati ‘çevrimdışı destek’ diye kısaltmak, müşterinin süre koşulunu kaybettirir. Matris, özet metninden farklı olarak bu küçük ama karar değiştiren ayrıntıları korur.

Karşılanıyor kararının yanında kaynak yeri bulunsun

İki şart karşılanıyor, iki şart açıklama bekliyor ve iki zorunlu şart karşılanmıyor. Bu dağılımı ‘yüzde 33 uygunluk’ olarak tek karar puanına çevirmiyoruz. Zorunlu çevrimdışı çalışma koşulu diğer maddelerdeki başarıyla telafi edilemez. Müşteri bu koşulu değiştirmedikçe mevcut kapsamla uygun teklif sunulduğu söylenemez. Fiyat indirimi de teknik gereksinimi karşılamaz; ticari ve teknik kararlar ayrı onay alanlarıdır.

R3'te ek paketin varlığı yeterli kanıt değildir. Müşterinin istediği kimlik yöntemi, teklif edilen paket ve kullanım ortamı eşleşmelidir. ‘Destekleniyor’ kelimesini belge içinde bulmak bütün kurum koşullarının sağlandığı anlamına gelmez. R5 ise açık bir ret değildir; teslim tarihi henüz belirlenmemiştir. Belirsizliği karşılanmıyor diye kapatmak da karşılanıyor diye taahhüt etmek kadar yanıltıcı olabilir. Soru, sorumlu ve gereken kanıt birlikte yazılmalıdır.

NIST AI RMF'nin bağlam ve insan sorumluluğu yaklaşımı, AI taslağının iş kararındaki yerini açıklamaya yardımcı olur. Burada AI şartları ve kaynakları eşleştirir; ürün yeteneğini değiştiremez, teslim tarihi onaylayamaz. Matrisin alanları ve müşteri koşulları bu yazının özgün eğitim tasarımıdır.Kaynak: NIST — AI RMF 1.0 Core

Eksikleri ticari metnin içinde de görünür bırakın

R1 ve R6 mevcut ürün/hizmet belgelerinde karşılanmaktadır. R2 için istenen 72 saat bağlantısız çalışma mevcut çevrimiçi ürün kapsamımızda yoktur. R4 için mevcut paket 30 gün kayıt saklar; 90 gün şartını karşılamaz. R3'ün kimlik yöntemi ve ek paket kapsamını, R5'in teslim başlangıcını ayrıca netleştirmemiz gerekir. Mevcut şartlarla tam uygunluk beyanı veremiyoruz. Kapsamın değiştirilmesi değerlendirilirse yeni koşullara göre matrisi tekrar hazırlayabiliriz.

Bu taslak gönderilmiş bir mesaj değildir. Satış sorumlusu kaynakları, ürün sahibi teknik ifadeleri ve yetkili yönetici ticari yaklaşımı kontrol eder. Karşılanmayan bir şart için ürün yol haritasında fikir bulunması, bu teklif döneminde yetenek varmış gibi yazılmamalıdır. Gelecek geliştirme taahhüdü verilecekse ayrı kapsam, tarih, sorumlu ve onay gerekir. AI'ın ‘özel geliştirmeyle karşılanabilir’ demesi bunların yerine geçmez.

Şartname değişirse eski satırı sessizce güncellemeyin. Yeni sürümde hangi gereksinimin değiştiğini, önceki kararın neden yeniden açıldığını ve hangi kanıtın tekrar kontrol edileceğini kaydedin. R2 kaldırılmışsa o ret kalkabilir, ancak R4'ün 90 günlük koşulu hâlâ durur. Tek değişikliği bütün teklifin uygunluğuna yaymak, kalan engelleri görünmez yapar. İki metni karşılaştırma yazısındaki yöntem burada sürüm kontrolü için başvuru kaynağıdır.

Özeti değil her şartın izini kontrol edin

R1–R6 müşteri şartlarını D1–D3 belgeleriyle eşleştir. Her satırda şart kimliği, tam koşul, zorunluluk, karşılanıyor/açıklama gerekli/karşılanmıyor kararı, kaynak bölümü ve sorumluya soru ver. Kaynakta olmayan ürün yeteneği veya teslim tarihi üretme. Zorunlu şartı yüksek toplam puanla telafi etme. Sonunda eksikleri koruyan müşteri yanıtı taslağı hazırla. Teklif gönderme veya ticari onay verme; çalışma taslağı oluştur.

1. Altı şartın her biri matriste tam bir kez bulunuyor mu?
2. Süre, sayı, zorunluluk ve paket koşulları kaynakla aynı mı?
3. Karşılanıyor denilen satırlarda belge ve bölüm var mı?
4. Belirsiz maddelerin sorumlusu ve istenecek bilgisi açık mı?
5. Yanıt metni tablodaki retleri veya açık soruları gizliyor mu?

Küçük alıştırma: Müşteri R4'ü 90 günden 30 güne indirdi ve bunu yeni şartname sürümünde onayladı. Yeni durumda tam uygun teklif verebilir misiniz? Cevap anahtarı: R4, D2 ile eşleşir ve karşılanıyor olarak yeniden değerlendirilebilir. Ancak R2 hâlâ zorunlu ve karşılanmıyor; R3 ile R5 açıklama bekliyor. Dolayısıyla bütün teklif için uygunluk sonucu çıkmaz. R4'ün değişen sürümü ve kararı kaydedilir, diğer satırlar kendi kanıtlarına göre korunur.

Kendi uygulamanızda önce kısa bir şartname seçin ve AI çıktısını kaynak metinden bağımsız okumayın. Her satırdan geriye doğru belgeye gidilebilmelidir. Matrisin amacı teklif işini ağırlaştırmak değil, sonradan pahalı düzeltmeye dönüşecek bir varsayımı erken görünür kılmaktır. Gereksinim ve onay dosyası tamamlandığında fiyat, indirim ve teslim hesaplarını mevcut satış teklifi rehberindeki yöntemle bir sonraki aşamaya taşıyabilirsiniz.