Objektif Özet: Ops Liderinin Verimlilik Kısayolu Rehberi

Objektif özet, iyi bir özetle aynı şey değildir. Biri ne olduğunu bildirir. Diğeri de ne olduğunu bildirir, ama yazanın süzgecinden geçirerek. On kişilik bir GTM ekibinde üç günlük standup ve her çeyrekte bir QBR varsa, bu fark hızla büyür.

Berlin merkezli bir Series A B2B SaaS ekibiyle sekiz ay çalıştım: CRM süreci yok, üç farklı Notion wiki'si var ve toplantı özetleri kayıt yerine görüş yazısı gibi okunuyordu. Çözüm daha iyi bir şablon değildi. Çözüm, ekibe objektif özetin gerçekte ne gerektirdiğini öğretmek, sonra bunu otomatikleştirmekti.

Sonuç: deal review hazırlığı 40 dakikadan 10 dakikanın altına düştü. Board update'leri üç revizyon turundan bire indi. Post-mortem'ler suçlama seansı olmaktan çıktı, çünkü kayıt tarafsızdı ve herkes yazılanlar üzerinde hemfikirdi. Bu yazı, o projenin başında elimde olmasını dilediğim playbook.

Bu playbook teoriden değil, sekiz ay boyunca test edilmiş bir workflow'dan çıktı. Aynı yapıyı bugün 15 kişilik bir CS ekibinde, 40 kişilik bir sales ops organizasyonunda görüyorum: fark, ekip büyüklüğünde değil, kaydın ne kadar tarafsız tutulduğunda.

Objektif Özetin Gerçek Anlamı (Ders Kitabı Tanımı Değil)

Çoğu tanım "duyguları değil, olguları yaz" diyerek durur. Bu doğru ama yeterli değil. Ops bağlamında objektif özet şu demek:

• Sadece alınan kararlar: kararı doğuran tartışma değil

• Sadece atanan aksiyon maddeleri: kişinin kabul ederkenki ruh hali değil

• Sadece bahsedilen veri: o verinin ne anlama geldiğine dair yorum değil

Kullandığım test şu: aynı toplantıya iki kişi katılmışsa ve ikisi de objektif özet yazmışsa, bu iki özet neredeyse birebir aynı çıkmalı. Aynı değilse, biri objektif değildir.

Pratikte bu nerede çöküyor: biri "CEO pipeline konusunda endişeli görünüyordu" yazıyor, oysa doğrusu şu: "CEO, Cuma gününe kadar güncellenmiş bir Q3 pipeline tahmini istedi." Birincisi, üzerine yorum eklenmiş bir gözlem. İkincisi, gerçekte olan.

Bu ayrımı ekip içinde netleştirmenin en hızlı yolu: her cümleyi yazan kişiye "bunu nereden biliyorsun" diye sordurmak. Cevap "toplantıda söylendi" ise kalır. Cevap "öyle hissettim" veya "sanırım öyle düşünüyordu" ise, cümle özetten çıkar. Bu tek kural, sekiz aylık Berlin projesinde ekibin öğrendiği en pahalı derstir: ucuza öğrenilmiş olsaydı, üç Notion wiki'sine ihtiyaç kalmazdı.

Yapay Zeka Toplantı Özetlerinin Çoğu Neden Objektif Değil

İşte burada işler ilginçleşiyor, ve çoğu ekibin yandığı yer de burası.

Otter, Fireflies, hatta Zoom'un kendi transkripsiyonu gibi araçlardan çıkan yapay zeka toplantı özetleri, tarafsız olmak için değil, faydalı olmak için eğitilmiş. Faydalı olmak çoğu zaman bağlam eklemek, keskin kenarları yumuşatmak veya niyeti tahmin etmek anlamına gelir. Bu üç hareketin hepsi öznellik katar.

"Ekip ilerlemeye karar verdi" yazan yapay zeka özetleri gördüm, oysa gerçek transkript iki kişinin anlaşmadığını ve birinin sadece "tamam, deneyelim" dediğini gösteriyordu. Aynı şey değil.

Örüntü tutarlı: yapay zeka, boşlukları makul görünen bir dille dolduruyor. Bu bazı işler için değerli. Ama hukuki bir kayda, board update'ine veya post-mortem'e giden bir objektif özet için bu bir risk.

Çözüm yapay zekayı bırakmak değil. Çıkarım yapmayı açıkça yasaklayan bir promptla modelin çıktısını sınırlamak.

Bunu test etmenin ucuz bir yolu var: aynı transkripti hem varsayılan ayarlarla hem de objektif kısıtlamayla özetlet, iki çıktıyı yan yana koy. Fark genelde şaşırtıcı büyük çıkıyor: kısıtlanmamış versiyon üç ila beş cümlede bir yorum veya varsayım ekliyor, kısıtlanmış versiyon neredeyse hiç eklemiyor. Bu farkı bir kere gördükten sonra, kısıtlamasız özete geri dönmek zorlaşıyor.

Adım 1: Objektif Kısıtlamalı /summarize Komutunu Kur

Briefing 30 saniye: aşağıdaki prompt, çağrılardan ve dokümanlardan objektif özete ihtiyaç duyan ekipler için CommanderGPT'de kullandığım versiyon. Fork'la, son beş toplantından birinde test et, farkı ölç.

Komut yapısı şöyle:

/summarize [transkripti veya notları buraya yapıştır]

Talimat: Yukarıdakinin objektif özetini yaz.
Kurallar:
1. Sadece açıkça belirtileni raporla: çıkarım yok, yorum yok.
2. Format: alınan kararlar, aksiyon maddeleri (sorumlu + son tarih), bahsedilen kilit veri noktaları.
3. Kaynakta belirsiz bir şey varsa, tahmin etme, [belirsiz] olarak işaretle.
4. Maksimum 150 kelime.

[belirsiz] etiketi en önemli satır. Etiket olmadan, model boşlukları otomatik dolduruyor. Etiketle, belirsizlikleri gömmek yerine yüzeye çıkarıyorsun. Üç [belirsiz] etiketi taşıyan bir objektif özet, netlik uyduran cilalı bir özetten daha kullanışlı.

150 kelime sınırı da tesadüfi değil. Bu, bir Slack mesajına veya bir Linear yorumuna sığacak uzunluk: okuyan kişi kaydırma yapmadan tamamını görür. Daha uzun bir sınır koyarsan, model tekrar bağlam ve yorum eklemeye başlıyor; kısıtlama gevşedikçe objektiflik de gevşiyor.

CommanderGPT'de bu, bir kere yazıp herhangi bir transkript, çağrı özeti veya dokümanda çalıştırdığın slash command'a dönüşür. Çıktı tek adımda Notion veya Linear ticket'ına düşer: /summarize + yapıştır → 150 kelimelik objektif kayıt.

Ops Stack'inde Objektif Özetin En Çok Zaman Kazandırdığı Yerler

Her use case buna ihtiyaç duymaz. İşte kazandığı yerler:

Deal review'lar: sales ops ekipleri QBR öncesi çağrı kayıtlarını özetliyor. Objektif özet = müşteri adayının gerçekten söylediği, AE'nin hatırladığı değil. 300 bin dolarlık bir deal'de bu fark önemsiz değil.

Board ve yatırımcı update'leri: board senin sayı yorumuna ihtiyaç duymaz. Sayılara ve kararlara ihtiyaç duyar. Her inisiyatifin 100 kelimeyi geçmeyen objektif özeti, okuması daha hızlı ve yanlış aktarılması daha zor. Bir board üyesi üç dakikada beş inisiyatifi okuyup net bir görüş oluşturabilmeli; yorumla dolu bir özette bu mümkün değil.

Post-mortem'ler: bir şey ters gittiğinde, en faydalı doküman ne olduğunu sırayla, suçlama ya da yargı olmadan belirten doküman. Objektif özet formatı, post-mortem formatıdır.

Async standup'lar: Loom veya Slack üzerinden async standup yürüten dağınık ekipler, katılmadan 30 saniyede okunabilecek özetlere ihtiyaç duyar. Objektif = bağlam gerektirmez.

Ortak nokta şu: bu dört kullanım alanının hepsinde, özeti okuyan kişi toplantıda yoktu veya kararı vermedi. Onlar için tek referans, elindeki metin. Metin yorum içeriyorsa, karar da yorum üzerine kurulmuş olur; bu da altı ay sonra "kim ne zaman ne karar verdi" tartışmasında geri döner. Objektif özet bu tartışmayı baştan kapatır.

3 Komutluk Workflow: /research → /summarize → /flag

Prospect research veya account review yapan GTM ops ekipleri için objektif özetler doğal olarak bir komut zincirine oturur:

1. /research [şirket adı]: herkese açık veriyi çeker: son funding round, yeni işe alımlar, basın haberleri, ürün değişiklikleri

2. /summarize: bu çıktıyı şirketin şu an nerede olduğuna dair 100 kelimelik objektif bir anlatıya damıtır

3. /flag [kriter]: özeti ICP kriterlerine karşı çalıştırır ve uyuşmazlıkları işaretler

Recon complet avant d'envoyer le premier email. AE, 90 saniyenin altında üç parçalı bir çıktı alır: şirket ne yapıyor, son zamanda ne değişti, ICP'ye uyuyor mu. Çıkarım yok. Editoryal yok. Sadece veri.

Bu, Berlin ekibi için 40 dakikalık manuel hazırlığın yerini alan workflow. Yapay zeka okumakta daha hızlı olduğu için değil (öyle de olsa), objektif özet adımı verinin doğru okunup okunmadığı tartışmasını ortadan kaldırdığı için.

Bir Objektif Özeti Ne Bozar (ve Yayınlanmadan Önce Nasıl Yakalanır)

Kısıtlanmış bir promptla bile objektif özetler kayabilir. En sık gördüğüm hata modları:

Yumuşak atıf: "ekip zaman çizelgesinin agresif olduğunu hissetti" yerine "üç ekip üyesi zaman çizelgesinin çok kısa olduğunu söyledi, ikisi yorum yapmadı." Duygusal fiil içeren her cümleyi işaretle: hissetti, göründü, endişelendi.

Eksik son tarihler: son tarih ve sorumlu olmadan kaydedilen bir karar aksiyona dökülemez. Komutuna bir kontrol ekle: her aksiyon maddesinde sorumlu/son tarih çifti yoksa, özet eksik demektir.

Çökmüş anlaşmazlık: iki kişi ters şeyler söylediğinde, objektif özet iki pozisyonu da kaydeder. Yardımcı olmaya eğitilmiş bir yapay zeka modeli genelde daha makul görünen pozisyonu seçip konsensüs gibi sunar. Bu objektiflik değildir.

Kapsam kayması: özet, toplantıda olmayan bağlamı eklemeye başlar: sektör trendleri, arka plan, çıkarımlar. Bunların hepsi editoryal. Ayıkla.

Sessiz çoğunluk varsayımı: toplantıda üç kişi konuştu, yedi kişi sessiz kaldıysa, özet "ekip hemfikirdi" yazamaz. Doğrusu: "üç kişi görüş bildirdi, yedi kişi yorum yapmadı." Sessizlik onay değildir, kaydı da öyle değildir.

En hızlı inceleme: özeti oku, sonra "buradaki her cümle doğrudan kaynaktan mı geliyor" diye sor. Nereden geldiğini gösteremiyorsan, orada olmamalı. Bu incelemeyi özet yayınlanmadan önce 60 saniyelik bir kontrol olarak workflow'una ekle. Kayma, bir ekip uyum sorununa dönüşmeden önce çoğunu yakalar.

"İçgörüler" Bölümünü Atla

Birçok yapay zeka özet aracı, sona varsayılan olarak bir "içgörüler" veya "çıkarımlar" bölümü koyar. Objektif özetler için bunu atla. İçgörüler yorumdur. Çıkarımlar editoryaldir.

Bu bölümü sildiğinde bazı ekip üyeleri ilk başta rahatsız olur: "peki ne yapmalıyız" sorusunun cevabını arıyorlardı. Doğru tepki, o soruyu ayrı bir dokümana taşımak, objektif kaydı sulandırmamak. İki ihtiyaç gerçek ama aynı belge onları karşılayamaz.

Analiz istiyorsan ayrı bir komut çalıştır: /analyze [özet]. Objektif kaydı ve analiz katmanını ayrı tut. Bu, objektif özeti geniş çapta paylaşmana izin verir (ekipler arası, hukuka, board'a), analiz kısmını ait olduğu bağlamda tutarken.

Birlikte çalıştığım ops liderlerinin çoğu, her önemli toplantıdan iki doküman çıkarıyor: objektif özet (paylaşılan) ve analiz notu (dahili). Objektif özet doğruluk kaynağı. Analiz notu, ekibin bu konuda ne yapılacağına dair okuması.

Faydalı bir yan etki: bu katmanları ayrı tuttuğunda, paylaşılan kaydı değiştirmeden analizi kimin yazdığını rotasyona sokabilirsin. Yeni bir ekip üyesi QBR'a katılıyor mu? Neyin kararlaştırıldığını öğrenmek için objektif özeti alır. Analiz katmanı, katkı sağlayacak yeterli bağlama sahip olana kadar dahili kalır. Bu yapı, ekipler 5 kişiden 20 kişiye büyüdükçe ve fonksiyonlar arası paydaş sayısı arttıkça doğal olarak ölçeklenir.

Renewal review yürüten CS ops ekipleri için bu ayrım özellikle faydalı. Renewal çağrısının objektif özeti CRM'e girer. Analiz notu ("bu hesap risk altında çünkü...") dahili CS aracında kalır. Aynı kaynak çağrıya kadar izlenebilen, iki farklı kitleye hizmet eden iki doğruluk kaynağı.

Marketing ops tarafında da aynı ayrım işe yarar: bir kampanya retrospektifinin objektif özeti (hangi kanal hangi sayıyı üretti) paylaşılan dashboard'a gider, "neden işe yaramadı" analizi ise büyüme ekibinin dahili kanalında kalır. İki doküman, tek kaynak, sıfır karışıklık.

Şimdi Kuracağın Komut

CommanderGPT kullanıyorsan, buradan başla: yukarıdaki objektif kısıtlamayla /summarize komutunu kur ve son beş toplantı notun üzerinde çalıştır. Çıktıyı gerçekte yazılanla karşılaştır. Aradaki fark, mevcut özetlerinin ne kadar editoryal kayma taşıdığını tam olarak gösterir.

Fark büyükse, ki genelde büyük çıkar, bu bir yazım sorunu kadar bir ölçüm sorunu. Objektif özet baseline. Geri kalan her şey bunun üzerine kurulur.

Küçük başla: tek bir toplantı tipinde dene, bir hafta boyunca sonucu takip et, sonra genişlet. On beş dakikalık kurulum, ölçülebilir bir başlangıç noktası verir; bu, "daha iyi iletişim kuralım" gibi belirsiz bir hedeften çok daha kullanışlı.

Lance la commande. Lis le output. Ship.