Alıcıyla konuşma genelde iyi geçer. Sayfayı beğenir, sorular sorar, "bir bakalım" der. Sonra sessizlik.

Aradaki boşluk ilgi eksikliği değil. Alıcı ilgileniyor ama bir şeyi bilmiyor: bu şey kendi işinde ne üretecek. Senin ekran kaydında güzel çalışıyor olması onun sorusunu cevaplamıyor, çünkü orada senin verin, senin en temiz örneğin var.

Deneme vardiyası tam olarak bu boşluk için var. Sınırlı girdisi ve çıktısı olan küçük bir gerçek görev; alıcının kendi verisiyle çalışıyor ve sonunda elinde tutabileceği bir şey bırakıyor.

İyi bir denemenin özelliklerini serinin ilk yazısı sayıyor. Bu yazı listeyi tekrarlamıyor; denemeyi kendi ürünün için nasıl tasarlayacağını anlatıyor.

Önce üç şeyle karıştırma

Demo videosuyla. Video senin elinde, senin verinle çalışan bir kayıt. İşe yarar ama başka bir soruyu cevaplar: "bu şey çalışıyor mu?" Denemenin cevapladığı soru farklı: "bende de çalışır mı?"

Ücretsiz kurulumla. Deneme, ürünü müşterinin sistemine kurmak değil. Kurulum yapıyorsan o iş satıştan önce başlamış demektir ve karşılığını alamazsın.

Pilot projeyle. Pilot, gerçek kullanımın küçük ölçekli hâlidir; haftalar sürer, erişim ister, sözleşme ister. Deneme günler sürer, dosya ister, sözleşme istemez. İkisi karışırsa müşteri pilot bekler, sen deneme yaparsın ve ikiniz de hayal kırıklığına uğrarsınız.

Bu üçünü ayırdıktan sonra tasarım dört parçadan ibaret: girdi, çıktı, süre, başarı ölçütü.

Parça 1 — Girdi: en küçük gerçek girdi

Tasarımın en zor parçası bu ve çoğu deneme burada ölüyor. Üretici işini iyi yapmak istediği için çok şey istiyor: hesap erişimi, tam veri seti, geçmiş kayıtlar. Müşteri listeyi görüyor ve erteliyor. Erteleme kalıcı oluyor.

Kural şu: erişim isteme, dosya iste.

Erişim istemek müşteriye üç iş çıkarır — bilgi işlemle konuşmak, yetki tanımlamak ve sana güvenmek. Dosya istemek hiçbirini çıkarmaz. Sürükle, bırak, gönder.

Girdiyi küçültmenin pratik yolları:

  • Fiyat tablosunun tamamı yerine iki üç ürün grubunu kapsayan bir bölümü
  • Canlı takvim bağlantısı yerine dışa aktarılmış bir haftalık program
  • Tüm müşteri geçmişi yerine son on gerçek talep
  • Hesap erişimi yerine bir ekran görüntüsü ya da örnek kayıt

Her girdi adayını üç soruyla sına:

  1. Müşteri bunu on beş dakikada toplayabilir mi?
  2. İçinde hassas veri var mı, varsa kaldırılabilir mi?
  3. Bu girdiyle ürünün ana işi gösterilebiliyor mu?

Üçüncüsü kritik. Girdiyi küçültürken denemenin gösterdiği işi de küçültürsen elinde etkileyici olmayan bir çıktı kalır. Doğru denge şu: girdi küçük, iş çekirdek.

Bir de sıralama tavsiyesi: istediğin girdileri numaralı bir liste hâlinde yaz ve her satırı tek bir nesneyle sınırla. "İlgili belgeler" bir madde değil; "son on teklif talebi, ekran görüntüsü veya metin olarak" bir madde.

Parça 2 — Çıktı: adı konmuş bir nesne

Çıktı, müşterinin göreceği ve gösterebileceği bir şey olmalı. "Sonuç" değil, "rapor" değil, adı konmuş bir nesne.

Kötü çıktı tanımı: "Ürünün nasıl çalıştığını gösteren bir örnek." İyi çıktı tanımı: "Yapılandırılmış ihtiyaç formu ve tek sayfalık taslak teklif, PDF olarak."

Sayı ver. "Birkaç gönderi taslağı" yerine "yedi günlük plan ve üç gönderi metni". Sayı vermek hem seni korur hem alıcıya beklentiyi verir.

İki tasarım kararı daha var.

Ara adımı da göster. Yalnızca son çıktıyı vermek "bunu sen mi yazdın, sistem mi?" sorusunu açık bırakıyor. Çıktının yanına ürünün kararlarını gösteren kısa bir bölüm koy: talebi hangi kategoriye koydu, hangi bilgiyi eksik buldu, hangi kuralı uyguladı. Bu bölüm çoğu zaman çıktının kendisinden daha ikna edici oluyor.

Çıktıyı olduğundan iyi gösterme. Deneme çıktısını elle rötuşlamak kısa vadede işe yarar, sonra geri teper. Kurulumdan sonra gelen normal çıktı denemedekinden zayıfsa ilk ay içinde güven kaybedersin ve o kaybı geri almak yeni bir müşteri bulmaktan zordur. Denemede gösterdiğin şey, ürünün ortalama günündeki çıktısı olsun.

Parça 3 — Süre: en yavaş gününde tutabileceğin söz

24–72 saat aralığı çoğu ürün için doğru. Ama asıl soru "kaç saat yazayım?" değil, "hangi süreyi her koşulda tutarım?"

Söz verdiğin süre, işlerin yolunda gittiği günü değil, en yoğun haftanı esas almalı. Denemeyi zamanında teslim etmek en az çıktının kendisi kadar konuşulur, çünkü alıcı için bu, kurulum ve destek sözlerinin ön izlemesi.

İki pratik not:

  • Başlangıçta denemeyi elle çalıştırman sorun değil. Alıcı için önemli olan girdinin, çıktının ve sürenin önceden yazılı olması.
  • Süre, girdiler tamamlandığı anda başlar. Bunu deneme açıklamasına yaz. Eksik girdiyle gelen bir talepte saat işlemeye başlamamalı.

Parça 4 — Başarı ölçütü: en çok atlanan parça

Deneme teslim edilir, alıcı "güzelmiş" der, konuşma orada biter. Sebebi neredeyse her zaman aynı: başarının ne olduğu önceden yazılmamıştır.

Ölçütü tek cümlede yaz ve denemeye başlamadan önce alıcıya onaylat. Kalıp şu: "Bu deneme başarılı sayılır eğer ..."

  • "... taslak teklifteki kalemler ve tutarlar, sizin elle hazırladığınız teklifle karşılaştırıldığında düzeltme gerektirmiyorsa."
  • "... yedi günlük planın en az beş gününü değişiklik yapmadan yayınlayabiliyorsanız."
  • "... on talebin en az sekizinde doğru kategoriye ayırdıysa."

Dikkat: ölçüt senin değil, alıcının diliyle yazılmalı ve alıcının bakabileceği bir şey olmalı. "Doğruluk oranı yüksekse" bir ölçüt değil; kimse ona bakamaz.

Ölçütün ikinci faydası, deneme başarısız olduğunda ortaya çıkıyor. Yazılı ölçüt varsa konuşma "olmadı" değil, "sekizde altı çıktı, eksik olan iki vaka şunlar" oluyor. İkincisi bir satış konuşmasının devamı; birincisi sonu.

Denemenin sana maliyeti ve nasıl sınırlanır

Deneme alıcı için ücretsiz olabilir, ama senin için bedava değil. Her deneme saatini yiyor ve talep arttıkça bu saatler toplanıyor.

Önce ölç: bir denemenin uçtan uca kaç dakikanı aldığını iki üç denemede kaydet. Girdileri okumak, eksikleri sormak, çalıştırmak, çıktıyı gözden geçirmek, teslim mesajını yazmak — hepsi dahil.

Sonra sınırla. Üç yöntem:

  • Eleme sorusu. Ürünün kime uygun olduğunu deneme açıklamasında yaz. Uygun olmayan alıcıların bir kısmı kendiliğinden elenir.
  • Kapasite. Ayda kaç deneme yapabileceğine karar ver. Sınırı aştığında sıraya alman, geç ve kötü teslim etmenden iyidir.
  • Emeği küçült. Denemenin en çok vaktini alan adımını bul ve onu otomatikleştir. Genelde bu adım, gelen girdiyi temizlemektir.

Denemeyi ücretli yapmak da bir seçenek — özellikle emeğin büyük olduğu ürünlerde. İki yönü var ve ikisini de bilerek seç: ücret niyeti filtreler, ama talep sayısını da düşürür. Ücret alacaksan bunu deneme açıklamasında açıkça yaz ve başlamadan önce müşteriyle teyit et. Sürpriz ücret, bir denemenin verebileceği en kötü ilk izlenim.

Veri saklama: kısa ama atlanmaması gereken bölüm

Denemede müşterinin gerçek verisini istiyorsun. Karşılığında ne yaptığını yazman gerekiyor.

Uzun bir metin gerekmiyor. Üç şey yeter: veriyi ne için kullandığın, ne kadar süre sakladığın, silme talebinde ne olacağı. Örnek: "Deneme girdileri yalnızca bu deneme için kullanılır, 30 gün sonra silinir; daha erken silinmesini isterseniz yazmanız yeterli."

Tek kural: yazdığına uy. Yazılmış ama uygulanmayan bir saklama sözü, hiç yazmamaktan daha kötü.

Deneme bittikten sonra: teslim mesajı

Denemelerin çoğu burada ölüyor. Çıktı gönderiliyor, karşı taraf teşekkür ediyor, konu kapanıyor.

Teslim mesajını dört parçalı yaz:

  1. Çıktı. Dosya ya da bağlantı, açıklama olmadan en üstte.
  2. Ölçüte göre değerlendirme. Önceden yazdığınız cümleye göre sonuç ne oldu. Tutmayan yer varsa önce sen söyle.
  3. Kurulumda ne değişir. Denemede elle yaptığın, kurulumda kendiliğinden olacak şeyler. Denemede yapamadığın ama üründe olan şeyler.
  4. Tek bir sonraki adım. Üç seçenek sunma; bir tane sun. "Kurulum için 30 dakikalık bir görüşme yapalım mı?" gibi.

İkinci maddedeki dürüstlük en çok işe yarayan kısım. Eksiği alıcı bulmadan senin söylemen, geri kalan her cümleni inandırıcı yapıyor.

Denemeyi reddetmek de bir seçenek

Her deneme talebine evet demek zorunda değilsin. Üç durumda hayır demek daha doğru:

  • Talep kapsam dışıysa. İstenen iş ürünün yaptığı iş değilse deneme yapmak yanlış anlaşılmayı büyütür.
  • Girdi verilemiyorsa. Müşteri veriyi paylaşamıyorsa deneme uydurma bir örnekle yapılır ve hiçbir şey kanıtlamaz.
  • Aslında pilot isteniyorsa. "Bir ay deneyelim, olursa devam" bir deneme değil, ücretsiz kullanım talebidir.

Hayır derken gerekçeyi ve bir alternatifi birlikte söyle: "Bu iş ürünün kapsamında değil; ama şu parçası kapsamda ve onu şu girdiyle gösterebilirim."

Üç ürün için örnek tasarım

Teklif hazırlama çalışanı

  • Girdi: son beş gerçek teklif talebi ve fiyat tablosunun bir ürün grubunu kapsayan bölümü
  • Çıktı: her talep için yapılandırılmış ihtiyaç formu, eksik bilgi listesi ve bir taslak teklif
  • Süre: 48 saat
  • Ölçüt: taslak tekliflerin kalem ve tutarları, elle hazırlanan teklifle karşılaştırıldığında düzeltme gerektirmiyorsa

Randevu ve hatırlatma çalışanı

  • Girdi: bir haftalık program, hizmet listesi ve on örnek müşteri mesajı
  • Çıktı: on mesaj için örnek konuşma akışı, önerilen randevu saatleri ve hatırlatma metinleri
  • Süre: 48 saat
  • Ölçüt: on konuşmanın en az sekizinde doğru hizmet ve uygun saat seçildiyse

Haftalık özet çalışanı

  • Girdi: geçen haftanın satış tablosu ve reklam paneli dışa aktarımı
  • Çıktı: tek sayfalık haftalık özet ve değişimi açıklayan üç madde
  • Süre: 24 saat
  • Ölçüt: özetteki sayılar kaynak dosyalarla eşleşiyorsa ve üç maddenin hepsi tablodaki bir veriye dayanıyorsa

Üç örnekte de ortak olan şu: girdi tek bir dosyaya sığıyor, çıktının adı var ve ölçüte alıcı kendi başına bakabiliyor.

Sık yapılan beş hata

  1. Girdi listesinin uzun olması. En sık ölüm sebebi.
  2. Çıktının adının olmaması. "Bir örnek göstereceğim" bir taahhüt değil.
  3. Ölçütün yazılmaması. Deneme "güzelmiş"le biter.
  4. Çıktının rötuşlanması. Kurulumdan sonraki ilk ayda ortaya çıkar.
  5. Teslimden sonra sonraki adımın söylenmemesi.

Deneme vardiyası bir ikna aracı değil, bir karşılaştırma aracı. Alıcıya "bu iyi bir ürün" dedirtmeye çalışmıyorsun; "bu benim işimde şunu üretiyor" dedirtiyorsun. İkincisi kalıcı.

AIÇalışanım tarafında ne oluyor

Ürün sayfası hazırlanırken deneme vardiyası için ayrı bir bölüm var. Doldurduğun alanlar şunlar: deneme başlığı, denemenin amacı, müşteriden istenen girdiler, teslim edeceğin çıktı, dönüş süresi ve veri saklama açıklaması. Yani bu yazının dört parçasından üçü doğrudan alan olarak duruyor; başarı ölçütünü denemenin amacı bölümüne yazabilirsin.

Yazdıkların formda kalmıyor, alıcının gördüğü sayfaya çıkıyor. Deneme talebi sayfasında senin istediğin girdiler ve teslim edeceğin çıktı madde madde listeleniyor, dönüş süresi ayrı bir satırda gösteriliyor. İstediğin girdi listesi ayrıca formun içinde de ipucu olarak görünüyor, böylece alıcı ne göndereceğini bakarak yazıyor. Veri saklama açıklaman ise onay kutusunun altındaki bilgilendirmeye ekleniyor.

Deneme vardiyası bölümü zorunlu değil — sayfa o bölüm boşken de incelemeye gidebiliyor. Ama boş bırakıldığında alıcının elinde karşılaştırabileceği hiçbir şey kalmıyor.

İlk aşamada denemeyi elle çalıştırman da sorun değil: talep panele düşüyor, sen çalıştırıyorsun, teslimatı iletiyorsun.

Açık olalım: platform üzerinden ödeme alınmıyor. Müşteriyle doğrudan sen anlaşıyorsun; platform talebi ve talebin nereden geldiğini kaydediyor.

Yayındaki ürünlerin denemelerini AI çalışanlar kataloğunda, CV'nin diğer alanlarını nasıl yazacağını da AI çalışan CV'si nasıl hazırlanır? yazısında bulabilirsin.

=== GÖVDE SONU ===

Yayın öncesi kontrol (yönetici için)

  • Bağımlılık: İki iç blog bağlantısı var — /blog/n8n-otomasyonunu-nasil-urunlestirirsin ve /blog/ai-calisan-cvsi-nasil-hazirlanir. İkisi de yayına girmeden bu yazı yayınlanmamalı, yoksa bağlantılar 404 verir. Yayın sırası: 1 → 2 → 3 → bu.
  • Üçüncü yazıya (ai-calisan-cvsi-nasil-hazirlanir) bu yazının bağlantısı eklenebilir; o taslakta "serinin bir sonraki yazısı" diye atıf var ama bağlantı yok.
  • audience alanı producer seçilmeli.
  • Gövdenin sonuna ayrıca çağrı eklenmedi: /blog/[slug] "Ürününü yayınlamaya hazır mısın?" kutusunu kendisi ekliyor.
  • Metinde uydurma istatistik, uydurma müşteri hikâyesi ve para tutarı yok (§16.1, §32). Örnek deneme tasarımları FIKIRLER.md'deki fikirlerle ve §11'deki örneklerle tutarlı; müşteri adı ya da sonucu iddia edilmiyor.
  • Koda bakılarak doğrulanan iddialar:

- Deneme bölümünün alanları — src/components/product-wizard.tsx 5. adım: trialTitle, trialDescription ("Denemenin amacı"), trialRequiredInputs, trialPromisedOutputs, trialTurnaroundHours, trialDataRetentionNote. Yazıdaki liste bu altı alanla birebir. - Girdi ve çıktının alıcıya madde madde gösterilmesi, dönüş süresinin ayrı satırda olması — src/app/(site)/deneme-vardiyasi/[slug]/page.tsx. - İstenen girdi listesinin form içinde ipucu olarak görünmesi — aynı sayfa, trialInputsHint özelliği LeadForm'a geçiriliyor. - Veri saklama açıklamasının onay kutusu altındaki bilgilendirmeye eklenmesi — src/components/lead-form.tsx, dataRetentionNote. - Deneme vardiyasının zorunlu olmaması — zorunluAlanKontrolu (src/app/actions/products.ts) deneme alanlarını aramıyor. - "Platform üzerinden ödeme alınmaz" — lead-form.tsx gönder düğmesinin yanında zaten yazılı; yazıdaki cümle bununla çelişmiyor.

  • Bilerek yazılmayan iddia: Şemada trialDefinitions.isPaid ve price alanları var ve deneme sayfası "Ücret: Ücretsiz / Ücretli" satırını bu alandan basıyor; ancak ürün formunda bu alanı ayarlayan bir giriş yok, yani her deneme sayfada "Ücretsiz" görünüyor. Bu yüzden yazıda "panelden ücretli deneme işaretleyebilirsin" gibi bir cümle kurulmadı; ücretli deneme, açıklamaya yazılması ve müşteriyle teyit edilmesi gereken ticari bir karar olarak anlatıldı. Ayrıntı takim/kayitlar/icerik.md üzerinden gelistiriciye bırakıldı.