Yapay Zeka ile Sosyal Medya Gönderi Planlama: Üçüncü Haftayı Geçen İçerik Döngüsü

Yapay zeka ile sosyal medya gönderi planlama, takvimi MCP üzerinden tutan bir asistana haftayı anlatmak, ürettiği taslakları gözden geçirmek ve yalnızca yayına değer olanları onaylamaktır. Asistan okur, yazar, zamanlar; kararı siz verirsiniz. Zor olan kısım planlama değil, girdilerdir: asistana ne verdiğinize göre ya işinizi anlatır ya da herkesin yazdığı cümleleri üretir.

Bu yazı o girdileri kurmakla ilgili. İçinde haftalık planlama oturumunun tam istemi, taslakların geçtiği inceleme kapısı, scheduledAt ile timeZone arasındaki en sık hata ve düzeltilmiş hâli, tek fikri dört platforma kopyala yapıştır kokmadan dağıtmanın yolu, plan bozulduğunda ne yapılacağı, gelen kutusundan içerik çıkarmanın araç sırası ve ayda bir bakılacak sayılar var. Örnekler gerçek araç adları ve gerçek yanıt gövdeleriyle yazıldı.

İçerik takvimleri neden üçüncü haftada ölür

Örüntü her ekipte aynı. Birinci hafta bir oturuşta on iki gönderi yazılır, takvim dolar, herkes memnundur. İkinci hafta altı gönderi çıkar ve üçü pazartesi sabahına yığılır. Üçüncü hafta takvimde boş kutular vardır ve kimse açmaz. Dördüncü hafta takvimden söz eden kalmaz.

Bu duruma verilen olağan teşhis iki tanedir ve ikisi de yanlıştır. Birincisi disiplin teşhisi: "düzenli olamadık". İkincisi araç teşhisi: "planlama aracımız iyi değildi". Oysa birinci hafta da aynı disiplinle, aynı araçla çalışıldı ve on iki gönderi çıktı. Değişen şey disiplin değil, stok.

Darboğaz takvim değildi, söylenmeye değer şey arzıydı

Birinci haftada ekip, aylardır biriken her şeyi boşaltır: kurulum hikâyesi, sık sorulan üç soru, geçen yılın dersi, ürünün en sevilen özelliği. Bu stok bitince geriye üretim hızı kalır. Bir işletme haftada iki ila dört anlatmaya değer şey üretir; on iki değil. Takvim on iki kutu gösteriyorsa, sekizi doldurulmak zorunda hissedilir ve dolgu içerikle doldurulur.

Dolgu içerik sessizlikten daha pahalıdır. Takipçiye "bizim gönderilerimizi açmaya değmez" diye öğretir, sıralama sistemine de aynı şeyi öğretir: açılmayan, kaydedilmeyen, üzerinde durulmayan bir gönderi bir sonraki gönderinin erişimini de aşağı çeker. Yani boş kutuyu doldurma refleksi, doldurmadığınızda kaybedeceğinizden fazlasını kaybettirir.

Bu yüzden bir planlama aracının ilk işi boş kutuları göstermek olmamalı. İlk işi, elinizde gerçekten ne olduğunu göstermek olmalı. Takvim bir kap; kabı büyütmek içeriği çoğaltmaz.

Asistanın ham maddesi zaten elinizde

Bir asistandan "bana 20 içerik fikri ver" diye istediğinizde çıkan liste her işletmeye uyar, çünkü hiçbir işletmeye ait değildir. Aynı asistan üç kaynağa erişebildiğinde bambaşka bir şey üretir:

• Bu hafta ekipten çıkan iş. Kapanan bir hata, biten bir özellik, teslim edilen bir proje, kazanılan bir müşteri, düzelen bir süre. Bu, asistanın kendi başına bulamayacağı tek girdi ve elle verilir.
• Müşterinin sorduğu sorular. DM kuyruğunda, canlı destekte ve e-postada aynı soru tekrar ediyorsa, o soru bir gönderi konusudur. Kanıtı da elinizdedir: kaç kez soruldu.
• Geçen ayın sayıları. Hangi gönderi kaydedildi, hangisi yanıt aldı, hangisinden sonra DM geldi. Bu üçlü, bir sonraki ayın biçim kararlarını verir.

Bu üç kaynağın ikisi zaten CRM'in içinde duruyor. Asistanın onları okuyabilmesi için bir köprü gerekiyor ve o köprü MCP. Protokolün kendisi ve istemci tarafındaki karşılığı için sosyal medya MCP sunucusu yazısına bakabilirsiniz; burada protokolü değil, protokolün üstünde kurulan haftalık iş akışını anlatıyorum.

Planlama oturumunun araçları ve ne döndürdükleri

Aşağıdaki araçlar bir MCP istemcisine (Claude Desktop, Claude Code, Cursor ya da ChatGPT'nin MCP desteği) bağlandığınızda asistanın elinde olur. Adlar dondurulmuştur, uydurmayın; bir istemci listede olmayan bir adı çağırırsa hata alır.

Tablodaki iki satırın altını çizmek gerekiyor, çünkü ikisi de adından beklenenden dar iş yapıyor. crm_social_post_stats yayın sonuçlarını sayar: toplam, yayımlanan, bekleyen, işlenen, başarısız, iptal edilen ve bunların platform kırılımı. Gösterim, etkileşim ve erişim döndürmez. "Ne çıktı, ne düştü" sorusunun cevabıdır; "bu gönderi ağda nasıl performans gösterdi" sorusunun değil. Ağ üzerindeki performans, her platformun kendi analitiğinden gelir ve bu yazıda ölçüm bölümünde ayrıca ele alınıyor.

crm_messaging_stats ise giden mesaj kuyruğunun sayacı. Argümanı windowDays (yalnızca 1, 7 veya 30 kabul edilir, varsayılan 7) ve isteğe bağlı bir accountId. Döndürdüğü gövde şu: { windowDays, accountId, since, totals: { queued, sent, failed, total }, successRate, generatedAt }. Yani hacim ve başarı oranı. Platform kırılımı yok, yanıt süresi yok, konuşma sayısı yok; platform bazlı kırılımı crm_social_inbox_summary verir.

İki ayrıntı yazının geri kalanını okumayı kolaylaştırır. Birincisi biçim: MCP araçlarının çıktısı camelCase, aynı veriyi veren v1 REST yüzeyi ise PascalCase. Bu yazıdaki bütün örnekler MCP tarafından, yani camelCase. REST tarafını doğrudan kullanacaksanız herkese açık API sayfasındaki alan adlarına bakın ve iki biçimi tek örnekte karıştırmayın. Kimlikler de bu yüzeyde tam sayıdır: postId: 993 gibi. Dizeye benzeyen bir gönderi kimliği gördüğünüz her örnek eskidir.

İkincisi güvenlik sınırı: hiçbir araç hem okuyup hem yazmaz. Yazan bir araç, değişen şeyin onayını döndürür, veri akışı döndürmez. Bu ayrım, asistanın "önce bir şey yazayım, sonra sonucu okuyup devam edeyim" biçiminde kendi kendine ilerlemesini engeller. Protokolün genel çerçevesi için Model Context Protocol belgelerine, kurulum ve bayraklar için CRM Solid MCP entegrasyon belgelerine bakabilirsiniz.

Yapay zeka ile sosyal medya gönderi planlama: haftalık oturumun tam yürüyüşü

Oturum haftada bir yapılır, yirmi beş dakika sürer ve tek kişi yürütür. Sıra önemlidir, çünkü her adım bir öncekinin çıktısını kullanır.

1. Girdileri toplayın: üç aracı çalıştırın, bir de elle yazılan "bu hafta ne çıktı" listesini ekleyin.
2. Planlama istemini çalıştırın ve altı fikir isteyin, her fikrin yanında dayanağıyla.
3. Planı tartışın: dayanağı zayıf olanları kesin, iki fikri birleştirin, bir tanesini siz ekleyin.
4. Taslakları isteyin, ama önce tablo isteyin. Bu adımda hiçbir araç çağrılmaz.
5. Tabloyu onaylayın; asistan metinleri sohbet penceresinde yazsın. Burada da hiçbir araç çağrılmaz, çünkü tarihi henüz siz vermediniz.
6. Metinleri tek tek okuyun, düzeltilecekleri düzeltin, sonra her birine tarihini verip planlatın.
7. Takvimi tek listede doğrulayın: aynı gün iki gönderi var mı, saatler doğru mu.

Girdiler: üç araç ve bir insan

crm_social_post_stats son 30 günde ne çıktığını söyler: kaç gönderi yayımlandı, kaçı kuyrukta bekliyor, kaçı düştü ve bu kırılım platform bazında nasıl. Beklentiyi doğru kurun; bu araç "hangi gönderi tuttu" sorusuna cevap vermez, çünkü içinde gösterim, etkileşim ve erişim yoktur. Planlamadaki işi başka: geçen ayın gerçek üretim hızını ve nerede tıkandığını gösterir. Söz verdiğiniz haftada sekiz gönderiden dördü çıkmışsa problem fikirde değil kapasitededir, ve bir platformdaki failed sayısı yüksekse o kanalda planlamaya devam etmeden önce bağlantıyı düzeltmeniz gerekir.

crm_social_inbox_summary şu anda hangi platformda ne kadar aktif konuşma olduğunu ve hangilerinin hâlâ yanıt beklediğini verir. Planlamada bunu iki soruya cevap vermek için kullanırsınız: hangi platformda gerçekten insan var, ve bu hafta hangi konu insanları yazmaya itmiş.

crm_messaging_stats giden gönderim hacmini ve başarı oranını verir; argümanı windowDays ve yalnızca 1, 7 ya da 30 kabul eder. Tek başına içerik fikri üretmez ama bir fikri öldürmeye yarar: giden hacmi düşen ya da failed oranı yükselen bir kanala haftada üç gönderi planlıyorsanız, plan yanlış yerdedir. Platform kırılımını buradan beklemeyin, o bir önceki araçtan gelir.

Dördüncü girdi elle yazılır ve oturumun en değerli kısmıdır: bu hafta ekipten ne çıktı. Biçimi kısa tutun. Beş satır, her satır on beş kelimeyi geçmesin, her satırda ya bir sayı ya bir bağlantı olsun. Sayı ya da bağlantı olmayan satır bir gönderiye dönüşmez, çünkü içinde doğrulanabilir hiçbir şey yoktur.

Hazır istem: weekly-content-plan

Sunucu üç hazır istem yayınlar: social-inbox-triage, weekly-content-plan ve dm-reply-draft. İstemciler bunları genelde bir eğik çizgi komutu ya da ekleme menüsü olarak gösterir. weekly-content-plan, yukarıdaki okuma adımlarını paketler; siz yalnızca insan girdisini eklersiniz. Hazır istemi kullanmıyorsanız aynı işi aşağıdaki gibi elle yazabilirsiniz.

Haftalık içerik planı, 1 ile 7 Eylül arası.

Önce şu üçünü oku, sonra konuş:
1. crm_social_post_stats, days: 30
2. crm_social_inbox_summary
3. crm_messaging_stats, windowDays: 30

Bu hafta ekipten çıkanlar:
- Toplu mesaj ekranına zamanlama eklendi, 3 müşteri istemişti
- Instagram DM ortalama yanıt süremiz 41 dakikadan 12 dakikaya indi
- Bir bayi 900 kişilik listeyi 6 dakikada içeri aldı, eski yöntem 2 gün sürüyordu
- Faturalandırmadaki çift kayıt hatası kapandı
- Threads hesabı bağlandı, ilk gönderi henüz yok

Kurallar:
- 6 fikir öner. Altısı da yukarıdaki üç kaynaktan birine dayansın.
- Her fikrin yanına dayanağını yaz: hangi istatistik, hangi DM konusu, hangi iş.
- Fikirlerden en az ikisi somut bir sayı içersin.
- Hiçbir araç çağırma. Sadece listeyi ver.
- Türkçe yaz, kısa cümle kur, ünlem kullanma, hashtag önerme.

Son iki satır önemsiz görünür ama oturumun yarısını kurtarır. "Hiçbir araç çağırma" demezseniz asistan planla birlikte taslak da oluşturabilir ve siz daha planı beğenmeden takvimde kayıtlar belirir. "Sadece listeyi ver" demezseniz altı fikrin altına altı paragraf açıklama gelir ve tartışılacak şey kaybolur.

Tartışabileceğiniz bir plan neye benzer

İyi bir plan çıktısı bir program değil, kesilebilir bir listedir. Her satırda fikir, biçim, platform ve dayanak vardır. Dayanak sütunu, planın tek denetim mekanizmasıdır. Şu iki satırın farkına bakın:

Fikir 3: "Yanıt süresini nasıl 12 dakikaya indirdik" (LinkedIn, uzun metin). Dayanak: ekip girdisi, ölçülen süre 41 dakikadan 12 dakikaya.

Fikir 5: "Sosyal medyada tutarlılığın önemi" (LinkedIn, uzun metin). Dayanak: genel farkındalık.

İkincisi silinir. "Genel farkındalık" dayanağı, asistanın "elimde veri yok ama kutu doldurmam gerekiyordu" demesinin kibar hâlidir. Bir haftada altı fikirden ikisinin böyle çıkması normaldir; ikisini de kesin ve dört gönderiyle ilerleyin. Dolgu içerikten kaçınmanın maliyeti, planı eksik bırakmaktır ve bu maliyet ucuzdur.

Plandan taslağa: önce tablo, sonra araç çağrısı

Bu bölümdeki tek kural şudur: asistan, metni uydurduğu turda crm_schedule_social_post çağırmasın. Aynı turda hem yazıp hem kaydettiğinde, beğenmediğiniz üç taslak da takvime girmiş olur ve temizlemek yazmaktan uzun sürer.

Çözüm, araya bir tablo koymak. Asistandan önce önerdiği gönderilerin tablosunu istersiniz: platform, gün ve saat, ilk cümle, dayanak, uzunluk. Tabloyu okumak kırk saniye sürer ve taslakların yarısını burada elersiniz.

Onayladığım fikirler: 1, 3, 4, 6.

Şimdi taslakları hazırla. Hiçbir araç çağırma.
Önce şu sütunlarla tek bir tablo ver:
platform | gün ve saat (Europe/Istanbul) | ilk cümle | dayanak | karakter sayısı

Kurallar:
- LinkedIn 900-1300 karakter, X 240 karakterin altında, Instagram 400-700 karakter.
- İlk cümlede rakam varsa, rakamın nereden geldiğini parantez içinde yaz.
- Hashtag yok, emoji yok, "heyecanla duyuruyoruz" yok, soru ile başlama.
- Aynı cümle iki platformda geçmesin.
- Metinleri sohbette ver, hiçbir araç çağırma. Onayladığım metinleri
  ben tarihlerini verdikten sonra planlayacaksın.

Burada bir ürün gerçeğini bilmek akışı kurtarıyor: gönderi için taslak durumu yoktur. Yani "şimdi kaydet, tarihi sonra veririm" diye bir orta hâl bulunmuyor. crm_schedule_social_post, publishNow: true verilmedikçe bir scheduledAt ister ve ikisi de yoksa hiçbir kayıt oluşturmadan hata döner:

crm_schedule_social_post
{
  "content": "41 dakikadan 12 dakikaya ...",
  "platforms": ["linkedin"],
  "accountIds": [12]
}

Hata:
"scheduledAt is required unless publishNow is true"

Bu, sanıldığından iyi bir haber. Metinleri sohbette tutup takvime yalnızca tarihini verdiklerinizi yazdığınızda, beğenmediğiniz üç metin hiçbir yere kaydolmaz; temizlenecek bir şey de olmaz. Asıl güvenlik hikâyesi de burada: ne zaman diyeceğini unutan bir asistan sürpriz bir gönderi değil, bir hata alır. Yayın, ancak birinin bilerek yazdığı publishNow: true alanıyla olur; sessiz bir varsayılan yoktur. İkinci bir emniyet, scheduledAt değerinin gelecekte olma zorunluluğu: geçmiş bir tarih de reddedilir.

Metni onayladıktan ve tarihini verdikten sonra çağrı ve dönen yanıt şöyle görünür:

crm_schedule_social_post
{
  "content": "41 dakikadan 12 dakikaya. Instagram DM yanıt süremizi dört haftada böyle indirdik ...",
  "platforms": ["linkedin"],
  "accountIds": [12],
  "scheduledAt": "2026-09-03T09:30:00+03:00",
  "timeZone": "Europe/Istanbul"
}

Yanıt:
{
  "count": 1,
  "postIds": [993],
  "platforms": ["linkedin"],
  "scheduledAt": "2026-09-03T06:30:00Z",
  "status": "pending",
  "skipped": null,
  "message": "Scheduled on 1 account(s) for 2026-09-03 06:30 UTC."
}

İstekteki scheduledAt değerinin saat farkını (+03:00) açıkça taşıdığına dikkat edin; yanıt aynı anı UTC olarak geri veriyor, böylece hesabı onay ekranında doğrulayabiliyorsunuz. Bu yazım biçimini alışkanlık hâline getirin. Alternatifi de geçerlidir: çıplak bir yerel saati aynı çağrıda timeZone ile gönderirseniz sunucu çevirir. Bozuk olan tek durum, ikisini birden atlamaktır; o zaman değer UTC sayılır.

Dönen status değeri pending, yani "kuyrukta, henüz çıkmadı". Gönderi durum sözlüğünün tamamı beş değerden ibaret: pending, processing, published, failed, cancelled. Bir örnekte durum olarak draft ya da scheduled yazıyorsa o örnek eskidir; ikisi de bu sunucunun üretebileceği değerler değil.

Yanıtın bir veri akışı döndürmediğine de dikkat edin: gönderi listesi, hesap listesi, istatistik yok. Yazan araç yalnızca ne değiştiğinin onayını verir. postIds alanının bir dizi olması ise tesadüf değil: hedef hesap başına bir gönderi satırı oluşur, yani iki hesaba planladığınız tek metin iki kayıttır ve ikisi ayrı ayrı düzenlenip ayrı ayrı iptal edilir. Tek çağrıda en fazla 20 hedef hesap kabul edilir ve sunucu hiçbir şey yazmadan önce her hedefin günlük gönderi limitini kontrol eder; böylece bir dağıtım yarısı başarılı yarısı kotaya takılmış hâlde kalmaz. Kimlikleri saklayın (993); bundan sonraki her düzeltme ve iptal bu kimlikle yapılır.

Takvimi yalnızca okumasını istediğiniz bir kişi ya da otomasyon varsa, yerel proxy'yi --read-only ile başlatın: yazan bütün araçlar istemci listeyi görmeden önce düşer. Yüzeyi daha da daraltmak için --tools posts yeterlidir. Filtre yerelde çalıştığı için elenen araç ne listelenir ne çağrılabilir. Paketin kendisi ve bayrakların tamamı npm sayfasında ve depo README dosyasında.

İnceleme kapısı: bir taslakta neye bakılır

Taslakların hepsini okumak zorunda değilsiniz, ama her taslakta dört şeye bakmak zorundasınız. Bu dört madde sırasıyla uygulanırsa bir gönderi kırk saniyede incelenir.

1. İddianın doğruluğu

Metinde bir sayı varsa, o sayının bu ayın sayısı olduğunu doğrulayın. Asistan geçen ay konuştuğunuz bir rakamı bu ayın gönderisine memnuniyetle taşır, çünkü bağlam penceresinde duruyordur ve kulağa doğru gelir. En sık görülen hata "yüzde 30 hızlandık" cümlesinin altı hafta boyunca aynı kalmasıdır. Sayı değiştiyse gönderi de değişmeli.

Aynı denetim isimler için de geçerli. Bir müşterinin adı geçen taslak, o müşterinin yazılı onayı olmadan yayına çıkmaz. Bu kural, ekipteki tek kişilik onay sürecinin de iki kişilik olması gereken tek yerdir.

2. Açılan bir bağlantı

Taslaktaki her bağlantıya tıklayın. Dil modelleri makul görünen adresler üretir ve makul görünen adreslerin bir kısmı yoktur. Yayınlanmış bir gönderideki kırık bağlantı, çoğu platformda düzeltilemez; gönderiyi silip yeniden atmanız gerekir ve o zaman da ilk saatteki etkileşimi kaybedersiniz.

3. Yalnızca ilk cümle

Metnin geri kalanını kapatın ve sadece ilk cümleyi okuyun. Akışta okunan tek şey odur. İlk cümle bir hazırlık cümlesiyse ("Sosyal medya yönetimi zorlu bir alan"), gönderi ölmüştür. İyi ilk cümle ya bir sayı ya bir sonuç ya da bir itiraf içerir. "41 dakikadan 12 dakikaya" iyidir. "Yanıt sürelerimizi iyileştirdik" değildir.

4. Yalnızca sizin söyleyebileceğiniz bir şey

Metindeki şirket adını bir rakibinizinkiyle değiştirin. Gönderi hâlâ tutarlıysa, o gönderi hiçbir şey söylemiyor demektir. Bu test, dil modeli çıktısını en hızlı eleyen testtir, çünkü model varsayılan olarak herkes için doğru olan cümleleri üretir. Sizin işinizde doğru olan cümle genelde biraz rahatsız edicidir: bir sayı beklenenden düşüktür, bir yöntem beklenenden ilkeldir, bir şey iki kez denenmiştir.

Tek varyantı düzeltmek, partiyi yeniden üretmemek

Dört taslaktan biri kötüyse, asistandan "hepsini yeniden yaz" demeyin. Yeniden üretim iki şeyi bozar: onayladığınız üç taslak da değişir ve yeni parti ilk partiden uzaklaşır, çünkü model her turda biraz kayar. Bunun yerine tek kaydı düzeltin: crm_update_social_post aracına postId ve yeni content verirsiniz, gerisi olduğu gibi kalır.

Araç idempotent olarak işaretlidir, yani aynı çağrıyı iki kez yapmak zararsızdır. Bu, istemci bir yanıtı kaçırıp yeniden denediğinde önemli olur. Aynı özellik crm_cancel_social_post için de geçerlidir. Yalnızca crm_schedule_social_post tekrarlanabilir değildir: iki kez çağırırsanız iki kayıt oluşur.

Zamanlamanın ısıran ayrıntıları: ISO 8601 ve IANA saat dilimi

Gönderi planlamada en çok zaman kaybettiren hata, içerikle ilgili değil, hangi saati kastettiğinizi söylemeyi atlamakla ilgilidir. İki alan var ve ikisi de aynı soruya cevap veriyor:

Sunucunun doğrulanmış davranışı dört satırda bitiyor:

Okunuşu şu: scheduledAt üzerindeki saat farkı ile timeZone argümanı, hangi saati kastettiğinizi söylemenin iki geçerli yoludur. Değer bir saat farkı taşıyorsa (Z ya da +03:00) o kazanır ve timeZone o değer için yok sayılır. Değer çıplak bir duvar saatiyse timeZone devreye girer ve çevirmeyi yapar; alan tam olarak bunun için var, sunucu bunu Europe/Istanbul saatinin 09.00'ı olarak okuyup 06:00 UTC yazar. timeZone bir IANA kimliği olarak doğrulanır, geçersiz bir ad reddedilir.

Bozuk olan tek durum ikisini birden atlamaktır. Çıplak bir değeri saat dilimi vermeden gönderirseniz UTC sayılır ve Türkiye'de gönderi üç saat geç çıkar. Yani hata "timeZone çalışmadı" değil, "hangi saat olduğunu hiç söylemedik" hatasıdır.

En sık hata: aynı saati iki kez çevirmek

Süreç şöyle bozulur. Asistan planı yerel saatle konuşur ("salı sabah 07:00"). Biri bunu UTC'ye çevirir ve 04:00 bulur. Sonra aynı kişi, değerin İstanbul'a ait olduğunu belirtmek istediği için sonuna +03:00 ekler. Böylece saat ikinci kez çevrilmiş olur.

Niyet: 2 Eylül 2026, sabah 07:00, Europe/Istanbul.

YANLIŞ (iki kez çevrilmiş):
{
  "content": "...",
  "platforms": ["linkedin"],
  "scheduledAt": "2026-09-02T04:00:00+03:00",
  "timeZone": "Europe/Istanbul"
}
Bu değerin gösterdiği an 2026-09-02T01:00:00Z, yani İstanbul saatiyle 04:00.

DOĞRU (UTC anı, sonunda Z):
{
  "content": "...",
  "platforms": ["linkedin"],
  "scheduledAt": "2026-09-02T04:00:00Z",
  "timeZone": "Europe/Istanbul"
}

Aynı anı yazmanın ikinci geçerli yolu (yerel duvar saati ve ofset):
"scheduledAt": "2026-09-02T07:00:00+03:00"

Belirti çok tanıdıktır: gönderi sabah 4'te düşer. Kimse fark etmez, erişim düşük çıkar, ekip "bu konu tutmadı" diye yorumlar ve iyi bir fikir yanlış nedenle çöpe gider. Üstelik hata sessizdir; hiçbir yerde hata mesajı görmezsiniz, çünkü 2026-09-02T04:00:00+03:00 tamamen geçerli bir ISO 8601 değeridir.

Türkiye 2016'dan beri yaz saati uygulamıyor ve yıl boyunca UTC+3'te kalıyor. Bu, ofset aritmetiğini burada kolaylaştırır: üç saat her zaman üç saattir. Ama aynı takvimde Avrupa ya da Amerika hesabı da varsa, orada ofset yılda iki kez değişir ve elle yazılmış bir +02:00 altı ay sonra yanlış saati gösterir. Çok ülkeli takvimlerde en dayanıklı biçim bu yüzden çıplak duvar saatini yazıp saat dilimi adını timeZone alanına bırakmaktır: yaz saati geçişini sunucu hesaplar, siz hesaplamazsınız.

Asistanı bir kez eğitmek yeterli, yeter ki ekipçe tek bir biçim seçilsin. İki biçim de geçerlidir ve ikisi de aynı anı üretir. Birincisi: "scheduledAt alanına yerel duvar saatini yaz, ofset ekleme, timeZone alanına Europe/Istanbul koy; çevirmeyi sunucu yapar." İkincisi: "scheduledAt her zaman saat farkını taşısın, ya Z ile bitsin ya +03:00 ile." Hangisini seçerseniz seçin talimatın sonuna şunu ekleyin: "planlamadan önce hedef saati hem yerel hem UTC olarak bana yaz." Çevirdiğini yazdırdığınızda üç saatlik sapmayı gönderi çıkmadan görürsünüz. Yasaklanacak tek biçim, ikisini birden atlayan biçimdir: ofsetsiz bir değeri saat dilimi vermeden göndermek.

Bir aylık takvimi eksiksiz okumak

"Eylülde kaç gönderi var" sorusunun yanlış cevaplanması ikinci sık hatadır, ama sebebi çoğu kişinin sandığı şey değil. MCP liste araçları imleç tabanlı sayfalama kullanmaz. Yanıtta items zarfı, nextCursor ve hasMore yoktur; after diye bir parametre de yoktur. Liste limit alır (1 ile 100 arası, varsayılan 25) ve adı olan bir dizi ile bir count döner. İmleçli sayfalama v1 REST API tarafına aittir.

Hata bu yüzden şöyle çıkar: limit vermezseniz asistan 25 kaydı okur, sayar ve tam bir güvenle "eylülde 25 gönderi var" der. Oysa 63 tanedir. Hiçbir yerde hata görünmez, çünkü sistem tam olarak söylediği şeyi yapmıştır.

crm_list_social_posts
{ "status": "pending", "fromDate": "2026-09-01",
  "toDate": "2026-09-30", "limit": 100 }

Yanıt (kısaltılmış):
{
  "count": 63,
  "posts": [
    {
      "id": 993,
      "platform": "linkedin",
      "externalAccountId": "acc_zx91",
      "content": "Üç şey öğrendik: 40 destek kutusunu tek yere taşırken ...",
      "scheduledAt": "2026-09-02T06:00:00Z",
      "status": "pending",
      "publishedUrl": null,
      "errorMessage": null,
      "publishedAt": null
    }
  ]
}

Bağımsız bir sayıyla doğrulama:
crm_social_post_stats { "days": 30 }  ->  "pending": 63

Argüman adlarına da dikkat edin, çünkü en sık yanlış tahmin edilenler bunlar: tarih filtreleri fromDate ve toDate adını taşır, from ve to değil. Durum filtresi gerçek bir durum değeri ister, yani kuyrukta bekleyenler için pending. Filtrelenecek scheduled ya da draft diye bir durum yoktur. Bir de liste sonucunda content alanının 400 karaktere kırpıldığını bilin; metnin tamamını okumanız gerekiyorsa crm_get_social_post çağırın.

İsteme şu cümleyi koyun: "Liste çağrılarında kullandığın limit değerini yaz ve dönen count ona eşit mi söyle." Eşitse büyük ihtimalle tavana çarpmışsınızdır ve pencereyi daraltıp yeniden sormanız gerekir; 100 sunucunun kabul ettiği üst sınırdır. Aynı dikkat konuşma listelerinde de gerekir, orada dönen count değerini crm_social_inbox_summary içindeki activeConversations ile karşılaştırırsınız. Gerçekten sayfalanan tek yer mesaj geçmişidir ve geriye doğru ilerler: crm_list_social_messages aracına elinizdeki en eski mesajın kimliğini beforeMessageId olarak verirsiniz.

Kopyala yapıştır kokmadan çoklu platform

Tek fikri dört platforma dağıtmanın iki yolu var ve ikisi de meşru. Yanlış olan, hangisinin ne zaman kullanılacağını bilmemek.

Varyantların gerçekten farklı olduğu yer

Platform sayfalarındaki biçim ayrıntıları ve hesap bağlama adımları ayrı ayrı duruyor: LinkedIn gönderi planlayıcı, X (Twitter) gönderi planlayıcı, Instagram gönderi planlayıcı, TikTok gönderi planlayıcı, Threads gönderi planlayıcı ve Facebook gönderi planlayıcı. Video tarafında sıra ve süre kuralları farklı işlediği için YouTube video planlayıcıyı ayrı okumakta fayda var.

Bir uyarı: "bağlantıyı ilk yoruma taşıyın", "ilk 30 dakikada yorumlara cevap verin" gibi kuralların çoğu ölçüm paylaşmadan dolaşıyor. Bunları kural gibi değil, hipotez gibi ele alın ve kendi hesabınızda iki hafta boyunca bir yarısını öyle, bir yarısını böyle yayınlayın. Karşılaştırmayı nereden okuyacağınız konusunda net olun: crm_social_post_stats size hangi gönderilerin çıktığını verir, hangisinin daha çok görüldüğünü değil. Etkileşim, erişim ve kaydetme sayıları platformların kendi analitik ekranlarında durur, iki grubu oradan karşılaştırırsınız. Araç tarafındaki payı, hangi gönderinin hangi gruba ait olduğunu postId ile temiz tutmaktır. Kendi hesabınızın verisi, herkesin paylaştığı listelerden daha değerlidir.

Birebir aynı metnin gerçekten doğru olduğu yerler

Varyant üretmenin anlamsız olduğu birkaç durum var ve bunlarda tek metin, tek kayıt doğrusudur:

• Arıza ve durum bildirimi. Kelimenin aynısı olmalıdır; farklı platformda farklı ifade, kriz anında güvensizlik üretir.
• Tarih değişikliği. Etkinlik saati kaydıysa herkes aynı cümleyi görsün.
• Yasal ya da idari bir hatırlatma. Yorumlanacak bir şey yok, biçim değiştirmek fayda getirmez.
• İş ilanı. Aynı ilan metni, aynı bağlantı.
• Stok ya da erişilebilirlik duyurusu ("bu ürün geri geldi").

Aynı metin gerçekten doğruysa tek kayıt:
crm_schedule_social_post
{
  "content": "Bugün 14:10 ile 15:35 arasında gönderim kuyruğunda gecikme yaşandı. Kuyruk boşaldı, kayıp mesaj yok.",
  "platforms": ["linkedin", "x", "facebook"],
  "accountIds": [12, 15, 18],
  "publishNow": true
}

Metin platforma göre değişiyorsa platform başına bir kayıt:
crm_schedule_social_post
{
  "content": "41 dakikadan 12 dakikaya. Instagram DM yanıt süremizi dört haftada böyle indirdik ...",
  "platforms": ["linkedin"],
  "accountIds": [12],
  "scheduledAt": "2026-09-03T06:30:00Z",
  "timeZone": "Europe/Istanbul"
}

crm_schedule_social_post
{
  "content": "Yanıt süresini kısaltmanın yolu daha hızlı yazmak değil, aynı soruyu ikinci kez almamak.",
  "platforms": ["x"],
  "accountIds": [15],
  "scheduledAt": "2026-09-03T12:00:00Z",
  "timeZone": "Europe/Istanbul"
}

Tek varyantı düzeltmek (parti yeniden üretilmez):
crm_update_social_post
{
  "postId": 995,
  "content": "Yanıt süresini kısaltmanın yolu daha hızlı yazmak değil, sorunun kendisini ortadan kaldırmak."
}

Yukarıdaki ilk çağrıda publishNow: true bilerek var: arıza bildirimi zamanlanmaz, hemen çıkar. Bu, alanın hangi durumda kullanılacağının en net örneği. Planlı içerikte bu alanı hiç yazmayın.

Plan gerçekle çarpıştığında: arıza, ertelenen lansman

Salı 14:20. API hata döndürüyor, durum sayfası açık, ekip telefonda. 15:00'te takvimde "yeni sürüm hazır" diye bir gönderi var ve kimsenin haberi yok. Bu senaryo yılda bir iki kez yaşanır ve iki dakikada çözülmezse yaşanan şey teknik bir arıza olmaktan çıkıp itibar meselesine döner.

Yayınlanmamışı iptal etmek

crm_cancel_social_post, henüz çıkmamış bir gönderiyi iptal eder ve postId dışında bir şey istemez. Idempotenttir: aynı gönderiyi iki kez iptal etmek hata üretmez, bu da paniğe kapılmış bir asistanın tekrar denemesini zararsız kılar.

1. Tek cümleyle kapsamı söyleyin: "bugün 14:00 ile yarın 09:00 arasındaki bütün planlı gönderiler dursun."
2. Asistan crm_list_social_posts ile status: "pending", fromDate ve toDate vererek listeyi çıkarsın; limit değerini yeterince yüksek verip dönen count değerinin ona eşit olmadığını doğrulasın.
3. Kimlikleri size göstersin. Onaylamadan iptal etmesin.
4. Onay verdikten sonra her biri için crm_cancel_social_post çağırsın.
5. Aynı listeyi yeniden okuyup boş döndüğünü doğrulasın.

Üçüncü adımı atlamayın. "Bugünkü gönderileri iptal et" cümlesinin sınırı sizin kafanızda nettir, asistanın elinde ise bir tarih aralığıdır. Kimlikleri görmek, aralığın yanlış çıktığı durumu saniyeler içinde yakalar.

Yayınlanmış gönderi API tarafından silinmez

Bu kural pazarlık konusu değildir: yayına çıkmış bir gönderi API üzerinden platformdan kaldırılmaz. Yanlış bir şey yayınlandığında elinizde üç seçenek kalır ve hiçbiri sihirli değildir.

1. Düzeltme yayınlayın ve yanlış gönderiye yanıt olarak bağlayın. Türkçe akışlarda düzeltme, sessizce silmekten daha iyi karşılanır.
2. Gerçekten kaldırılması gerekiyorsa, platformun kendi uygulamasından elle silin. Bunu yapan kişi ve saat, ekip günlüğüne yazılsın.
3. Kalan planlı gönderileri gözden geçirin. Yanlış bir gönderi genelde yanlış bir varsayımdan çıkar ve aynı varsayım takvimde iki üç yerde daha durur.

Bunun tasarım gereği böyle olduğunu bilmek işe yarar: bir aracın dış dünyada geri alınamaz iş yapması, o aracın asistana verilmesini riskli hâle getirir. Silme yetkisinin API'de olmaması, asistanın yapabileceği en kötü şeyin sınırını çizer.

Ertelenen lansman: iptal değil, taşıma

Lansman iki hafta kaydıysa gönderileri iptal etmeyin. İptal metni de götürür ve iki hafta sonra aynı metni yeniden yazdırırsınız; yeni metin eskisinden kötü çıkar, çünkü ilk yazıldığı gündeki ayrıntılar unutulmuştur. Bunun yerine crm_update_social_post ile yalnızca scheduledAt alanını değiştirin. Metin, hesaplar ve platformlar olduğu gibi kalır.

Toplu taşıma yaparken sırayı koruyun: önce listeyi okuyun, kimlikleri ve mevcut tarihleri yan yana görün, sonra her kayda yeni tarihi verin. "Hepsini iki hafta ileri al" talimatını doğrudan vermek, aynı güne yığılmış üç gönderiyi yine aynı güne yığar.

Döngüyü gelen kutusundan beslemek

Buraya kadar anlatılan her şey, içerik stoğu varsa çalışır. Stoğu sürekli dolduran tek mekanizma gelen kutusudur. Müşteriler size zaten ne merak ettiklerini yazıyor; iş, o soruları saymaktan ibaret.

Araç sırası şöyle:

1. crm_social_inbox_summary: hangi platformda kaç aktif konuşma var, kimler yanıt bekliyor. Nereye bakacağınızı bu belirler.
2. crm_list_social_conversations: platform ve status: "active" vererek konuşmaları çekin, limit değerini baştan verin.
3. crm_list_social_messages: her konuşma için mesajları okuyun. Yalnızca direction: "inbound" olanlar konu üretir; geçmişe inmeniz gerekirse beforeMessageId ile geriye gidersiniz.
4. Soruları gruplayın ve sayın. Gruplama işini asistan yapar, sayıyı siz doğrularsınız.
5. 30 günde beş kez ya da daha çok sorulan her soru bir gönderi adayıdır.
6. Adayı beğendiyseniz crm_schedule_social_post ile bir inceleme saatine planlayın. Tarihsiz kayıt açamazsınız: taslak durumu yok ve scheduledAt zorunlu.

Kritik kural dördüncü adımda: müşterinin kelimelerini kullanın, sizin ürün kelimelerinizi değil. Dokuz kişi "toplu mesaj atarken numaralar nereden geliyor" diye sorduysa gönderinin ilk cümlesi tam olarak o sorudur. Aynı soruyu "veri kaynağı yönetimi" diye yeniden adlandırdığınızda, arama yapan da akışta gezen de o gönderiyi tanımaz.

İkinci kural, cevabın uzunluğuyla ilgili ve ayrımı basitleştirir. DM'de üç paragraf tutan bir cevap bir gönderidir. Tek satırda biten bir cevap gönderi değil, bir şablondur; mesaj şablonlarına yazılır ve bir daha yazılmaz. Bu ikisini karıştırmak, gönderileri sıkıcı, şablonları da gereksiz uzun yapar.

Gelen kutusunun kendisini asistanla yönetiyorsanız triaj, taslak yanıt ve devir kuralları ayrı bir konu; Instagram DM'lerini yapay zeka ile yönetme yazısı o tarafı ayrıntılı anlatıyor. Kanalların tek ekranda toplanması tek gelen kutusu sayfasında, sipariş akışının DM üzerinden yürüdüğü işletmeler için pratik kurulum ise Instagram DM sipariş operasyonu yazısında duruyor.

Bir sınır: gelen kutusundan çıkan bir soruyu gönderiye çevirmek serbesttir, ama aynı listeye toplu ileti göndermek bambaşka bir yükümlülüktür. Ticari elektronik ileti tarafındaki kurallar için tacir ve esnaf ayrımını anlatan yazıya bakın. Bu yazı hukuki tavsiye değildir.

Aylık gözden geçirme: önce sayılar, sonra anlatı

Ayda bir, kırk dakika. Masaya üç kaynak koyarsınız ve hangisinin neyi verdiğini karıştırmamak bu oturumun yarısıdır. crm_social_post_stats (days: 30) üretim tarafını verir: kaç gönderi çıktı, kaçı kuyrukta kaldı, kaçı düştü, platform bazında nasıl dağıldı. crm_dashboard_summary işin genelini verir. Üçüncüsü araçtan gelmez: gösterim, kaydetme, yanıt ve profil ziyareti gibi ağ üzerindeki performans sayıları her platformun kendi analitik ekranında durur ve oradan alınır.

Bu ayrımı baştan söylemek gerekiyor, çünkü asistandan "geçen ayın performansını çıkar" diye isterseniz elindeki tek sayıyla, yani yayın sonuçlarıyla, size performans gibi görünen bir tablo yazar. Yayımlanan gönderi sayısının artması bir performans iyileşmesi değildir; sadece daha çok yayın yaptığınız anlamına gelir. Üçlüyü yan yana koymanın amacı da tam olarak bu: içerik tarafındaki değişimin ağ tarafında ve iş tarafında karşılığı olup olmadığını görmek.

Sayıyı anlatıdan önce isteyin

Bir dil modeline sayıları verip "bu ay nasıl geçti" diye sorarsanız, size hangi sayılar olursa olsun tutarlı bir anlatı yazar. Anlatı, sayılara uyar; çünkü model tam olarak bunu yapmakta iyidir. Bu yüzden sırayı tersine çevirin ve isteme şu iki satırı koyun: "Önce tabloyu ver. Yorum yazma. Tabloyu onayladığımda üç cümlede ne öğrendiğimizi yaz."

Tabloyu kendiniz okuduğunuzda, çıkarımı siz yaparsınız ve asistanın üç cümlesi sizin çıkarımınızı doğrular ya da çürütür. Sıra ters olduğunda ise anlatıyı okur, doğru bulur ve tabloya hiç bakmazsınız.

Sürdür, kes, test et

Üç deneme kuralı keyfi değil, pratik. Tek gönderiyle karar vermek gürültüyle karar vermektir: bir gönderi bir haber gününe denk gelir, bir başkası tatile. Üç denemeden sonra da kesin karar veremiyorsanız zaten aradaki fark iş için önemsizdir.

Ortalama yerine medyana bakın. Otuz günlük pencerede tek bir gönderi beklenmedik biçimde yayılırsa ortalama yukarı kayar ve bütün ay iyi görünür. Medyan bu etkiyi emer. Aynı nedenle "toplam erişim" yerine "gönderi başına" değerlere bakın; ay içinde daha çok gönderi yayınlamak toplamı zaten büyütür ve hiçbir şey öğretmez. Pano tarafındaki kırılımlar ve dönem karşılaştırmaları raporlama ve analitik sayfasında.

Türkiye bağlamı: ton, diyakritik, tatil ve gerçekçi saatler

Ton: resmiyet mesafe üretir

Türkçe kurumsal yazımın varsayılanı fazla resmidir ve akışta mesafe olarak okunur. "Sayın takipçilerimiz", "kıymetli müşterilerimiz", "siz değerli iş ortaklarımız" kalıpları bir bültenin dilidir, bir gönderinin değil. Doğrusu ikinci çoğul şahıs ve düz cümledir: "Şunu denedik, şu çıktı."

Bir dil modeli Türkçe yazarken bu kalıplara kendiliğinden kayar, çünkü eğitim verisindeki Türkçe kurumsal metinlerin çoğu böyle yazılmıştır. İsteminize açık bir yasak listesi koyun: "heyecanla duyuruyoruz", "sizlerle paylaşmaktan mutluluk duyuyoruz", "sektörde fark yaratan" gibi kalıplar yasak olsun. Yasak listesi, olumlu ton talimatlarından daha iyi çalışır.

Diyakritik ve i harfi tuzağı

Türkçe metinlerde iki teknik hata gönderiyi amatör gösterir. Birincisi diyakritiklerin düşmesi: "açık" yerine "acik", "değişiklik" yerine "degisiklik". Model bunu genelde uzun metinlerin sonuna doğru ya da başlık üretirken yapar.

İkincisi büyük harf dönüşümü. Türkçede küçük "i" harfinin büyüğü "İ"dir, "I" değil. Başlığı büyük harfe çeviren herhangi bir araç (elektronik tablo formülü, tasarım aracı, bir betikteki dil ayarı yapılmamış büyütme işlevi) "İSTANBUL" yerine "ISTANBUL", "İLETİŞİM" yerine "ILETISIM" üretir. Bu, gönderi metnini elle kontrol etmediğiniz her yerde ortaya çıkar.

İki satırlık bir kural bunu kapatır: "Türkçe karakterleri eksiksiz yaz. Büyük harfe çevirirken i harfi İ olur, ı harfi I olur. Başlıkları büyük harfe hiç çevirme." Üçüncü cümle en pratik olanı; büyük harf başlıklar zaten Türkçe akışta bağırıyormuş gibi okunur.

Tatil ve gündem duyarlılığı

Planlı içeriğin en pahalı hatası, ülke gündeminin ortasında neşeli bir gönderinin çıkmasıdır. Deprem, büyük bir kaza, ulusal yas ilanı ya da geniş kapsamlı bir kesinti sırasında takvimin kendiliğinden akmaya devam etmesi, itibar açısından iki ay boyunca yaptığınız her şeyi silebilir.

Bunun çözümü bir yazılım özelliği değil, bir yetkidir. Ekipte bir kişiye "gündem durdurma" yetkisi verin, o kişi tek başına ve kimseye sormadan takvimi durdurabilsin. Prosedür yukarıdaki arıza prosedürüyle aynıdır: listeyi oku, kimlikleri gör, crm_cancel_social_post ile durdur. Gecikebilecek gönderiler için iptal yerine tarih taşıma tercih edilir.

Takvim tarafında iki blok her yıl kendini gösterir: ramazan ve kurban bayramı arifeleriyle bayram günleri, bir de temmuz ile ağustostaki izin yoğunluğu. Bu dönemlerde gönderi sayısını düşürüp yanıt hızını korumak, tersini yapmaktan iyi sonuç verir; çünkü akış sakinken görünürlük artar ama karar verecek kişi tatildedir.

Europe/Istanbul saatiyle gerçekçi pencereler

"En iyi paylaşım saati" listelerini olduğu gibi almayın; hiçbiri sizin takipçi kitleniz üzerinde ölçülmedi. Bunun yerine test edilecek üç yapısal pencereyle başlayın ve dört hafta sonra kendi verinizle daraltın:

• 08:00 ile 09:30 arası: iş gününün başı. LinkedIn ve X için mantıklı; okunma niyeti yüksek, etkileşim niyeti düşük.
• 12:30 ile 13:30 arası: öğle arası. Kısa biçimler burada tutar, uzun metinler tutmaz.
• 21:00 sonrası: akşam. Instagram ve TikTok tarafında hacim burada; kurumsal içerik burada kaybolur.

Cuma öğleden sonrası ve pazar sabahı, Türkiye'de B2B içeriği için en zayıf iki pencere olma eğiliminde. Bunu bir yasa gibi değil, ilk hipoteziniz gibi ele alın ve crm_social_post_stats ile sınayın.

Platform alışkanlıkları

Türkiye'de kanal ağırlıkları küresel ortalamalardan farklı. Instagram küçük ve orta ölçekli ticaretin fiilen satış kanalı; LinkedIn kitlesi küçük ama karar verici yoğunluğu yüksek; X gündemle birlikte ani yükselip düşüyor; WhatsApp ise insanların gerçekten cevap verdiği yer, ama bir yayın yüzeyi değil. Kanal kullanım oranlarının kaynaklı tablosu için Türkiye CRM ve iletişim kanalı kullanım oranları yazısına bakabilirsiniz; kanal başına maliyet karşılaştırması ise SMS, WhatsApp ve Instagram DM maliyet yazısında.

Pratik sonuç şu: gönderi planınızın hedefi beğeni toplamak değil, DM'e insan getirmek olmalı. Türkiye'de satış konuşması akışta değil, mesaj kutusunda başlıyor.

Yanıltan metrikler ve para kazandıran metrikler

Ay sonunda bakacağınız sayıların yarısı sizi rahatlatmak dışında bir işe yaramaz. İkisini ayırmak, planlama oturumunun yönünü de değiştirir.

Gösterim neden rahatlatıcı ve işe yaramaz

Gösterim bir arz sayısıdır: sizin değil, platformun kararıdır. Aynı içerikle bir gün 3.000, ertesi gün 30.000 gösterim alabilirsiniz ve arada değişen şey içeriğiniz olmaz. Daha kötüsü, yüksek gösterim düşük ilgiyle birleştiğinde zarar verir: 40.000 kişiye gösterilip kaydedilmeyen, üzerinde durulmayan bir gönderi, sıralama sistemine "bu hesabın içeriği tutmuyor" bilgisini verir ve bir sonraki gönderiyi aşağı çeker.

İkinci sorun daha basit: gösterimi arayamazsınız. Gelir tarafında bir gösterimin karşılığı yoktur. Bir konuşmanın vardır.

Somut bir örnek üzerinden bakalım; aşağıdaki sayılar ölçüm değil, aritmetiği göstermek için kurulmuş bir örnek. Bir gönderi 900 kişiye ulaşır, 6 kaydetme ve 2 DM üretir; DM'lerden biri fırsata dönüşür. Aynı ay ikinci bir gönderi 40.000 kişiye ulaşır, 380 beğeni alır, hiç DM üretmez. Panoya bakan biri ikinciyi ayın en başarılı gönderisi ilan eder. Gelir tablosuna bakan biri ise birinciyi çoğaltmak ister. İkinci gönderiyi çoğaltmaya çalışan ekip, üç ay sonra hâlâ neden hiçbir şey satmadığını tartışıyor olur.

Gönderiyi paraya bağlamanın ucuz yolu

Bağlantı noktası konuşmadır. DM'ler CRM'e düşüyorsa, bir gönderiyle bir konuşma arasında iki bağ kurabilirsiniz: zaman ve ilk mesajın içeriği. İkincisi çok daha güvenilir ve kurması bedava.

1. Gönderiye ayırt edici bir çağrı koyun: "DM'den 'takvim' yazın, planlama şablonunu göndereyim."
2. Gönderiden sonraki 72 saat içinde crm_list_social_conversations ile aktif konuşmaları çekin.
3. crm_list_social_messages ile gelen mesajları okuyun ve o kelimeyi içerenleri sayın.
4. Sayıyı gönderi kimliğiyle birlikte kaydedin. Üç ay sonra elinizde hangi konunun konuşma ürettiğine dair kendi veriniz olur.

Bu, atıf modeli değil; sayaçtır. Ama akışta ne işe yaradığını gösteren en dürüst sayaçtır ve kurulumu on dakika sürer. Konuşmalar fırsat aşamasına geçtiğinde takibi fırsat yönetimi tarafında, kişi kayıtları ve etiketleme ise müşteri takip programı tarafında tutulur.

Ekipler için yönetişim: kim onaylar, anahtar nasıl kapsamlanır, denetim izi

Onay tek kişide, ama yazan kişide değil

Haftalık planı yürüten kişiyle taslakları onaylayan kişi aynı olmasın. Kendi yazdığınız metnin ilk cümlesini kör okumak mümkün değildir; onu kırk kez okumuşsunuzdur ve artık ne dediğini görmezsiniz. Onay sırası ekipte dönebilir, ama o hafta kimin onayladığı yazılı olsun.

İki kişilik onay kuralı yalnızca iki durumda gerekir: metinde bir müşterinin adı geçiyorsa, ya da metinde henüz kamuya açıklanmamış bir sayı varsa. Geri kalan her şey için tek onay yeterli; daha fazlası süreci öldürür ve ekip takvimi terk eder.

Paylaşılan anahtarı kapsamlamak

İçerik asistanının kullandığı anahtara posts:read ve posts:write verin, başka bir şey vermeyin. Özellikle social:read vermeyin: bu kapsam DM içeriklerini açar ve içerik planlayan bir asistanın müşteri konuşmalarını okumaya ihtiyacı yoktur. Gelen kutusundan konu çıkarmak istediğinizde, bunu ayrı bir oturumda, ayrı bir anahtarla ve o konuşmaları görmeye zaten yetkili bir kişiyle yapın.

--read-only ve --tools filtrelerinin yerel proxy'de çalıştığını hatırlayın: elenen araç istemciye hiç gösterilmez, dolayısıyla model onu çağırmayı deneyemez bile. Bu, "sistem isteminde yazmayı yasakladım" yaklaşımından temelde farklıdır ve daha güvenilirdir.

Denetim izi ve anahtarların ömrü

Her yazma işlemi bir kimlik döndürür. O kimlikleri saklayın. Pratik kural: asistanın "üç gönderi oluşturdum" özetine değil, döndürdüğü postIds dizisindeki sayısal kimliklere güvenin. Diziyi tamamen not edin, ilk elemanını değil: dört hesaba dağıtılan bir gönderi dört kimlik üretir ve sorun çıkan, genelde not aldığınız olmaz. Özet, modelin cümlesidir; kimlik, sistemin kaydıdır. Haftalık oturumun sonunda kimlikleri tek satırda not etmek yeterli.

Anahtarlar kişiye bağlı olsun, ekibe değil. Ayrılan bir kişinin anahtarı o gün iptal edilir; paylaşılan tek anahtar kullanılıyorsa bunu yapamazsınız ve herkesin akışını bozmadan geri alamazsınız. Anahtar oluşturma ve iptal ekranı panelin geliştirici ayarlarında; şifreleme, erişim ve saklama tarafındaki ayrıntılar güvenlik sayfasında anlatılıyor. Hangi kapsamların hangi pakette açık olduğunu fiyatlandırma sayfasından kontrol edebilirsiniz.

Son bir mimari not, güvenlik yazısı yazarken işinize yarar: npm paketi bir stdio proxy'sidir. Instagram ya da LinkedIn ile kendisi konuşmaz; JSON-RPC isteklerini bearer anahtarınızla CRM Solid arka ucuna iletir, platform bağlantıları orada durur. Yani hiçbir platform şifresi ya da çerezi yerel makineye inmez. Kaybolan bir dizüstü bilgisayar, sosyal hesaplarınızın kaybı anlamına gelmez; iptal edeceğiniz tek şey bir anahtardır.

Bu akışın çalışmadığı yerler

Dürüst bir sınır listesi, akışı kurarken yaşanacak hayal kırıklıklarının çoğunu önler.

• Görsel üretimi bu yüzeyin dışında. mediaUrls bir URL listesi alır. Asistan görsel üretmez, yüklemez; siz yükler, adresini verirsiniz.
• Platforma özgü ince ayarlar yok. Instagram karusel sırası, TikTok ses seçimi, YouTube bölüm işaretleri gibi alanlar araç yüzeyinde bulunmuyor. Bunlar platformun kendi uygulamasında yapılır.
• Yorum yönetimi gönderi araçlarının işi değil. Gönderi altındaki yorumlar bu araçlarla okunmaz. DM tarafı ayrı bir araç ailesidir.
• Yayınlanmış metin değiştirilemez. Bu bir ürün sınırı değil, platformların çoğunun sınırı. Düzeltme yeni bir gönderidir.
• Asistan gündemi bilmez. Model, eğitim verisinin kestiği tarihe kadar olanı bilir. Bugünün gündemi, trendler ve dün çıkan haber sizden gelmelidir.
• Onay hâlâ insanda. Bu akışın tek gerçek riski, onay adımını otomatikleştirme isteğidir. Otomatikleştirdiğiniz gün, kazandığınız zamanın tamamını bir gönderiyi geri almaya çalışırken harcarsınız.

Tekrarlayan iş akışlarını asistan olmadan da kurmak istiyorsanız, tetikleyici tabanlı kurulum otomasyon akışları tarafında; asistanın kendi başına çalıştığı senaryolar ise yapay zeka ajanları sayfasında anlatılıyor. İkisi de bu yazıdaki insan onaylı döngünün yerine geçmez, yanına eklenir.

Sık sorulan sorular

Yapay zeka ile sosyal medya gönderi planlama gerçekten zaman kazandırıyor mu?

Kazandırdığı yer yazma değil, hazırlık. Haftalık oturum girdileri toplamak, geçen ayın sayılarına bakmak ve fikirleri dayanaklarıyla listelemek için normalde bir buçuk iki saat sürer; asistan bu kısmı birkaç dakikaya indirir. Metin yazımında kazanç daha küçüktür, çünkü inceleme kapısı zaman ister.

Asıl kazanç üçüncü haftada görünür: stok bittiğinde durmak yerine, aynı üç kaynağa bakıp yeni dört fikir çıkarabilirsiniz. Döngünün ayakta kalması, tek tek gönderilerin hızlı yazılmasından daha değerlidir.

Asistan yanlışlıkla gönderi yayınlayabilir mi?

Hayır, çünkü belirsiz bir çağrı yayına değil hataya çıkar. crm_schedule_social_post, publishNow: true verilmedikçe scheduledAt alanını zorunlu tutar; ikisi de yoksa çağrı scheduledAt is required unless publishNow is true hatasıyla reddedilir ve hiçbir kayıt oluşmaz. Taslak durumu diye bir ara hâl de yoktur: gönderi pending, processing, published, failed ya da cancelled olur. Yani ne zaman diyeceğini unutan bir asistan sürpriz gönderi değil, hata alır.

Ek bir güvence isterseniz, takvimi yalnızca okuyan roller için yerel proxy'yi --read-only ile başlatın. Bu durumda yazan araçlar istemciye hiç gösterilmez.

scheduledAt alanına yerel saat yazabilir miyim?

Yazabilirsiniz, ve bunu söylemenin iki geçerli yolu var. Birincisi ofseti değerin içine koymak: 2026-09-02T07:00:00+03:00 geçerlidir ve 2026-09-02T04:00:00Z ile aynı anı gösterir. İkincisi ofseti hiç yazmayıp saat dilimini ayrı söylemek: scheduledAt: "2026-09-02T07:00:00" ile birlikte timeZone: "Europe/Istanbul" geçerseniz sunucu çeviriyi yapar ve 04:00 UTC olarak saklar. Yazamayacağınız şey, UTC'ye çevrilmiş bir değere bir de yerel ofset eklemektir; o saati ikinci kez çevirir.

timeZone alanı IANA adı alır (Europe/Istanbul) ve işi, saat farkı taşımayan bir değeri çevirmektir. Değer bir farkla geliyorsa (Z ya da +03:00) o kazanır, timeZone o değer için yok sayılır. Bozuk olan tek durum ikisini birden atlamaktır: ofsetsiz bir değer saat dilimi verilmediğinde UTC sayılır ve Türkiye'de gönderi üç saat geç çıkar. Karışıklığın en sık belirtisi, sabah 7 için planlanan bir gönderinin sabah 4'te ya da sabah 10'da çıkmasıdır.

Aynı metni bütün platformlara göndermek ne zaman doğru?

Yorumlanacak bir şey olmadığında doğrudur: arıza ve durum bildirimleri, etkinlik tarihi değişiklikleri, iş ilanları, idari hatırlatmalar ve stok duyuruları. Bunlarda ifade farkı fayda değil şüphe üretir. Tek kayıt açıp platforms dizisine bütün platformları yazarsınız.

Anlatı içeren her şeyde platform başına ayrı kayıt açın. Uzunluk, ilk cümle ve okuma bağlamı üç platformda üç farklı şey ister.

Yayınlanmış bir gönderiyi API ile silebilir miyim?

Hayır. Yayına çıkmış bir gönderi API üzerinden platformdan kaldırılmaz. crm_cancel_social_post yalnızca henüz çıkmamış gönderileri iptal eder.

Yanlış bir şey yayınlandıysa düzeltme yayınlayın ve yanlış gönderiye bağlayın; gerçekten kaldırılması gerekiyorsa platformun kendi uygulamasından elle silin ve bunu ekip günlüğüne yazın. Ardından takvimdeki diğer gönderileri gözden geçirin, aynı yanlış varsayım genelde birden fazla yerde durur.

Ekipteki herkese aynı anahtarı verebilir miyim?

Verebilirsiniz ama vermeyin. Anahtarlar kişiye bağlı olduğunda ayrılan birinin erişimini o gün kapatırsınız; paylaşılan anahtarda bunu kimsenin işini durdurmadan yapamazsınız.

Kapsamları da rol başına daraltın. İçerik planlayan bir asistana posts:read ve posts:write yeter; DM içeriklerini açan social:read kapsamını içerik oturumuna eklemeyin.

Asistan Türkçe metinde karakterleri bozarsa ne yapmalıyım?

İki ayrı arıza var. Birincisi diyakritiklerin düşmesi ("değişiklik" yerine "degisiklik"); bunu isteme konulan açık bir kural çözer. İkincisi büyük harf dönüşümü: Türkçede "i" harfinin büyüğü "İ"dir ve dil ayarı yapılmamış bir büyütme işlevi "İLETİŞİM" yerine "ILETISIM" üretir.

En pratik önlem, başlıkları hiç büyük harfe çevirmemek. Metni bir tasarım aracına ya da elektronik tabloya taşıyorsanız, taşındıktan sonra Türkçe karakterleri bir kez daha gözden geçirin; bozulma çoğu zaman modelde değil, aradaki araçta oluşur.

Haftalık oturum ne kadar sürüyor ve kim yürütüyor?

Girdiler hazırsa yirmi beş dakika. Tek kişi yürütür; kalabalık bir toplantıya çevirmek oturumu bir saate çıkarır ve çıktının kalitesini artırmaz.

Oturumu yürüten kişiyle taslakları onaylayan kişinin farklı olması tek yapısal kuraldır. Onay sırası haftalık dönebilir, yeter ki o hafta kimin onayladığı yazılı olsun.

Hangi metrikleri raporlamalıyım?

Gönderi başına kaydetme, soru içeren yanıt sayısı ve gönderiden sonraki 72 saatte gelen DM sayısı. Bu üçü niyet gösterir ve gelir hattına bağlanabilir.

Gösterim, erişim ve takipçi sayısını rapordan çıkarmasanız bile karar ölçütü yapmayın. Bunlar büyük ölçüde platformun dağıtım kararıdır ve ay içinde sizin yaptığınız hiçbir şeye bağlı olmadan iki katına çıkabilir ya da yarıya inebilir.