ChatGPT Team Tasks, bir kişinin kişisel hatırlatıcısı yerine bir ekip adına çalışan zamanlanmış veya olay tetiklemeli görevler. DevDay 2026 duyurusunda işlerin ekip servis hesabı ve onaylı bağlantılarla yürütüldüğü açıklandı. Haftalık rapor, yeni proje güncellemesi özeti veya belirli olay sonrası brifing gibi işler bu yapıya uyuyor.
Resmî kılavuz, ekibin ChatGPT içindeki üyeliğinin workspace grupları ya da Slack kanallarıyla aynı olmadığını söylüyor. Görevler, yaratıcının kişisel hafızasını ve sohbet geçmişini devralmıyor. Bu iki ayrıntı, otomasyonu gerçekten kurumsal hale getirmek için kritik: kaynaklar, talimatlar ve erişim kişilerden bağımsız açıkça tanımlanmalı.
Bu yazının duyuru ve erişim bilgileri OpenAI’nın resmî özellik belgesi ile DevDay 2026 toplu duyurusu üzerinden doğrulandı. Örnek proje ve deneme önerileri editoryal yorumdur.
Takvim ve olay tetikleyicisi
Team Task için tetikleyici belirli saat veya desteklenen olay olabilir. Pazartesi müşteri durum özeti, yeni satış anlaşması sonrası onboarding briefi ya da lansman kanalına mesaj gelince engel raporu örnekleri resmî kılavuzda yer alıyor. Her olayı otomasyona çevirmek gerekmiyor; çıkan sonucun okuyucusu ve karar noktası olmalı. Tekrarlı görevin tarihi ve zaman dilimi açık yazılmalı. Olay tetikleyicisinde de hangi bağlantıdan, hangi koşulla geldiği anlaşılmalı; aksi halde yanlış güncelleme gereksiz iş başlatır.
Servis hesabı neden ayrı?
Görevler yaratıcının kişisel hesabından değil ekibin servis hesabı ve yapılandırılmış bağlantılarıyla bulutta çalışıyor. Bu, bir kişinin izinlerinin veya işten ayrılmasının bütün akışı bozmasını azaltabilir. Aynı zamanda ekip hesabına ne verildiğini dikkatle yönetmeyi gerektirir. Görev müşteri e-postası okuyacaksa bağlantı kapsamı ve çıktı erişimi açıkça sınırlandırılmalı. Servis hesabı ortak olduğu için “benim kişisel ChatGPT'm zaten bunu biliyor” beklentisi yanlış; kaynaklar ve talimatlar görevin içine yazılmalı.
Ekip üyeliği ve çıktı erişimi
ChatGPT takımı, workspace gruplarından ve Slack/Teams kanallarından bağımsız. Üyeler elle eklenip çıkarılıyor; kılavuz otomatik içe aktarma veya senkron olmadığını söylüyor. Ayrıca önceki çalışmalar ve üretilen dosyalar için ekip erişimi paylaşım öncesi incelenmeli; tekil görev çalışması başına ayrı erişim kısıtı bulunmuyor. Bir pazarlama ekibinde müşteri A'nın raporuna müşteri B projesindeki kullanıcılar aynı ekipten erişebilecekse ekip sınırını yeniden çizmek gerekir. Üyelik listesi burada içerik politikasının parçası.
Kurulum için rol izinleri
Çalışma alanı sahibi, “Create teams” ve “Create and manage team tasks” izinlerini uygun kullanıcılara açmalı. Workspace connections yönetici tarafından hazırlanabilir; takım sahibi kendisine izinli olan bağlantıyı seçer. Kişisel team connection ile şirket yönetimli workspace connection farklı hesaplara dayanabilir. Görev oluşturmadan önce hangi dış hesabın veri okuyup yazacağını görmek gerekir. Otomasyon yetkisi ile bağlantı yetkisi ayrı değerlendirildiğinde yanlış kişinin güçlü bir servis hesabıyla iş başlatması engellenebilir.
İyi görev talimatı nasıl yazılır?
Resmî kurulum akışında Team toggle, takım seçimi, tetikleyici, talimatlar, eklentiler, gelişmiş ayarlar ve model seçimi var. Talimata hedef çıktı, kullanılacak kaynak, başarı ölçütü ve durma koşulu yazılmalı. Örneğin “her pazartesi özetle” yerine “onaylı proje panosunda geçen hafta kapanan işler, açık engeller ve kaynağı olan kararları listele; eksik veri varsa uydurma, açık soru olarak belirt” daha denetlenebilir. Görev kişisel hafızayı devralmadığından, özel şirket terimleri ve bağlantılar görünür biçimde eklenmeli.
Örnek: haftalık kampanya raporu
Pazarlama ekibi her pazartesi 09.00'da proje bağlantısından son durum, teslim tarihleri ve açık yorumlar için rapor istiyor olsun. Ekip servis hesabı yalnız ilgili çalışma alanını okur. Çıktı, üç bölüm içerir: bitenler, riskler, karar gerektirenler; her madde kaynağa bağlanır. İlk birkaç çalışmada rapor insan tarafından karşılaştırılır, yanlış varsayımlar talimatta düzeltilir. Bu editoryal senaryo, OpenAI'nın hazır kampanya raporu şablonu sunduğu iddiası değil; Team Tasks akışının iş problemine uygulanması.
İlk çalışma ve önceki çalışmalar
Kılavuz görevi oluşturmadan sonra “Run now” ile denemeyi ve Previous runs içinde sonucu incelemeyi öneriyor. Bu önemli: takvim saati gelene kadar beklemek, yanlış bağlantı veya eksik talimatı canlı üretim anında fark ettirir. İlk çalışmada tarih aralığı, zaman dilimi, kaynak ve çıktı izni kontrol edilmeli. Bir sonraki çalışmada aynı bilgi iki kez yazılıyor mu, eski yorum yeniymiş gibi alınıyor mu, karşılaştırılmalı. İyi otomasyon ilk kurulumda değil, birkaç tur düzeltmeden sonra oturur.
Olay tabanlı görevde dikkat
Bir ekip görevi MCP Events veya desteklenen başka olayla tetikleniyorsa olayın gerçekten o takım için anlamlı olması gerekir. Örneğin her yorum yerine yalnız belirli belgede yeni onay yorumu geldiğinde özet hazırlanabilir. Olay yanlış yapılandırılırsa görev çok sık çalışır ve gürültü üretir. Ayrıca çalışma hesabının o anda kaynağa erişimi hâlâ var mı kontrol edilmeli. Ben tetik kayıtlarını, üretilen sonucu ve insanın hangi durumda müdahale ettiğini birlikte izlerdim. Böylece ekip görevine güven gelişir.
Ekibi doğru sınırda kurmak
ChatGPT takımı ile şirket dizinindeki grup aynı değil; üyeleri ayrıca yönetmek gerekiyor. Bu nedenle otomasyonun ürettiği dosyaları kimlerin görmesi gerektiğini başlangıçta listelerim. Bir takım birden çok müşteri için çalışıyorsa görev geçmişinin ortak görünürlüğü müşteri sınırıyla çelişebilir. Resmî kılavuz tekil run ve dosyalar için ayrı erişim kısıtı olmadığını söylüyor. Bu durumda daha küçük takım yapısı veya hassas içeriği göreve hiç almama seçeneği değerlendirilmeli. Ekip adı organizasyon şemasını değil, paylaşılan bilgi sınırını da temsil etmeli.
Tetikleyiciyi gürültüden ayırmak
Her yeni mesajı rapor sebebi yapmak çoğu ekipte fazla çıktı üretir. Önce gerçekten karar doğuran olayları tanımlarım: onay yorumu, teslim tarihi değişimi, kritik engel. Takvimli görevde ise tarih aralığı net olmalı; “geçen hafta” ifadesi zaman dilimiyle birlikte yazılmalı. Aynı olay tekrar gelirse iki rapor oluşması bekleniyor mu, test edilir. Otomasyonun görevi kullanıcıyı daha az belirsizlikle bırakmak; her gelişmede yeni belge oluşturmak değil. Pilot sonunda kaç çıktı okunduğu ve kaçının eyleme dönüştüğü ölçülebilir.
Talimat ve kaynak paketinin sahibi
Team Task yaratıcının kişisel hafızasını kullanmadığından kurumsal terimlerin, proje linklerinin ve çıktı biçiminin açıkça yazılması gerekir. Bir görevde “müşteri A” tanımı herkes için aynı kaynağı göstermeli. Talimatın sahibi ayrıldığında görevi kimin güncelleyeceği belirlenmeli. Ben görev açıklamasına üç örnek eklerdim: beklenen iyi çıktı, eksik veri durumunda verilecek uyarı ve yapılmaması gereken eylem. Böylece başka ekip üyesi görevi devralınca niyeti yalnız eski sohbetten tahmin etmek zorunda kalmaz. Bakım anlaşılır talimatla başlar.
Önceki çalışmaların incelemesi
Run now ile ilk sonucu görmek hızlı, ama yalnız bir çalışmaya bakmak yeterli değil. Birkaç tekrar sonrası eski verinin yeniden yeniymiş gibi yazılıp yazılmadığına, bağlantı yetkisinin sabit kalıp kalmadığına ve çıktının istenen kitleye uyup uymadığına bakardım. Previous runs kayıtları hatayı geriye dönük incelemek için önemli. Bir görevin son üç çalışması aynı hatayı yapıyorsa modele daha uzun talimat eklemek yerine kaynak veya tetik filtresini değiştirmek gerekebilir. Otomasyon denetimi, üretilen metnin üslubundan çok görev sözleşmesinin çalışıp çalışmadığına odaklanmalı.
Bağlantı değişimi ve ayrılma
Şirket yönetimli bağlantının hesabı değiştiğinde veya ekip üyesi ayrıldığında Team Task aynı adla durabilir ama kullandığı bilgi farklılaşabilir. Bu yüzden bağlantı sahibi ve takım sahibi arasında değişiklik bildirimi gerekir. Bağlantı iptalinden sonra hata durumunu “bu hafta hiç yeni bilgi yok” diye yanlış raporlamamak kritik. Ben bağlantıyı yeniledikten sonra hemen Run now çalıştırıp beklenen bir kayıt ve erişilmemesi gereken bir kaydı test ederdim. Böylece kurumsal otomasyonun kişiden bağımsız olması, sahipsiz kalması anlamına gelmez.
Çıktının ulaşacağı yer
Team Task raporu üretiyor ama kimse okumuyorsa otomasyon değeri yok. Çıktının ekip içindeki hangi sayfaya, kanala veya dosyaya gideceği ve kimin karar vereceği tanımlanmalı. Haftalık raporda ilk bölümün “karar bekleyenler” olması bazen uzun kronolojik özetten daha yararlı. Bir olay tetikliyorsa olay ile çıktı arasındaki ilişki başlıkta görünmeli. Resmî ürün, görevi takım servis hesabıyla yürütüyor; fakat raporun editoryal biçimini ve işletim sahipliğini ekip belirliyor. Bir aylık denemede çıktının okuma ve karar oranını ölçmek gerekir.
Görevi durdurma kuralı
Otomasyonlar genellikle kurulduktan sonra unutuluyor. Kampanya bittiğinde veya kaynak bağlantısı değiştiğinde Team Task'in durdurulması ve önceki çalışmalara erişimin değerlendirilmesi gerekir. Ben her görev için bitiş koşulu yazarım: proje kapanışı, üç ardışık boş rapor, bağlantı sahibinin değişmesi gibi. Çıktı güncel veri bulamazsa eski metni yeniden üretmek yerine durumu açık söylemeli. Bu yaklaşım çalışan sayısını azaltmak için değil, ekibin güven duyduğu az sayıda doğru otomasyon tutmak için. Takım sahibi düzenli gözden geçirmeyi üstlenmeli.
Sonuç
Team Tasks, ekip işini kişisel sohbetten ayrıştıran yönetilebilir otomasyon. Servis hesabı, takım üyeliği, bağlantı seçimi ve önceki çalışmalara erişim birlikte düşünülmeli. Doğru başlangıç dar bir tekrar eden iş, açık başarı ölçütü ve hemen yapılan test çalışması. Çalışan otomasyon sayısı değil, doğru bilginin doğru ekibe zamanında gelmesi hedef olmalı.
Sık sorulan sorular
Team Task kişisel ChatGPT hafızamı kullanır mı?
Hayır. Resmî kılavuz görevin yaratıcının kişisel hafıza, özel talimat ve sohbet geçmişini devralmadığını söylüyor.
Ekip üyeliği Slack kanalıyla senkron mu?
Hayır. ChatGPT takım üyeliği workspace grupları ve Slack/Teams kanallarından ayrı yönetilir.
Görevi nasıl test ederim?
Oluşturduktan sonra Run now ile çalıştırıp Previous runs içinde çıktı ve erişimi inceleyin.
İlgili yazılar
- DevDay 2026: bütün duyurular
- ChatGPT Slack ve Microsoft Teams İçinde Nasıl Çalışıyor?
- Workspace Connections: Şirket Hesabıyla Ortak Bağlantı
- Agent Security: Yerel ve Bulut Ajanlarına Politika Kontrolü