Instagram DM Yapay Zeka ile Yönetimi: Üç Yetki Seviyesi ve Nerede Durmalı

Instagram DM yapay zeka ile yönetimi bugün mümkün: kutuyu MCP üzerinden bir asistana bağlarsınız, asistan konuşmaları okur, sınıflandırır ve yanıt taslağı yazar. Asıl karar teknik değil: ne kadar yetki devrettiğiniz. Üç seçenek var. Yalnızca özetlesin, onayınıza taslak yazsın, ya da dar bir konu sınıfında kendi başına yanıtlasın.

Bu yazı o üç seviyeyi tek tek kuruyor. Her seviye için hangi araç hangi sırayla çağrılıyor, API anahtarının hangi kapsama ihtiyacı var, ne kazanıyorsunuz, hangi riski satın alıyorsunuz ve tam olarak nerede durmanız gerekiyor. Örnekler gerçek araç adları ve gerçek JSON gövdeleriyle yazıldı, çünkü bu kurulumun tamamı bir sohbet penceresinden yapılıyor ve yanlış çağrı sırası doğrudan müşteriye giden bir mesaja dönüşebiliyor.

Sipariş operasyonunun kendisini, yani adres alma, ödeme eşleştirme, kargo bildirimi ve iade akışını ayrı bir yazıda anlattık: Instagram DM'den sipariş alan işletmeler için operasyon rehberi. Burada o operasyonun üzerine oturan katmanı konuşuyoruz. Sıralama önemli: yapay zeka dağınık bir süreci düzeltmez, dağınık süreci hızlandırır. Sipariş kaydınız yoksa önce onu kurun, sonra bu yazıya dönün.

Mevzuata değinen bölümler bilgilendirme amaçlıdır, hukuki danışmanlık değildir.

Yoğun bir Instagram kutusunda gerçekte ne bozuluyor

Otomasyon konuşmasına "mesajlara yetişemiyoruz" diye başlamak yanlış teşhise götürür. Yetişememek bir sonuç. Nedeni dört ayrı arıza ve her biri farklı bir çözüm istiyor.

Niyet karışması: dört farklı iş aynı listede

Instagram gelen kutusu tek bir liste gösterir ama içinde en az dört farklı iş vardır. Destek talebi (siparişim nerede, ürün bozuk geldi), satış sorusu (bu üründen var mı, indirim yapıyor musunuz), spam ve alakasız temas (işbirliği teklifleri, takipçi satan hesaplar) ve hikâye yanıtları (çoğu tek kelimelik tepki, bir kısmı gerçek talep). Bu dördü aynı görsel ağırlıkla yan yana durur.

Sonucu şu: kutuya bakan kişi zamanının ciddi bir kısmını sınıflandırmaya harcar, yanıtlamaya değil. Gün sonunda "kırk mesaja baktım" der ama bunların on beşi tek kelimelik hikâye yanıtıydı, sekizi spamdı ve gerçek işi olan on yedisinin dördü hâlâ açık. Yapay zekanın ilk ve en güvenli işi tam burası: sınıflandırma insana en pahalıya mal olan, makineye en ucuza mal olan iştir.

Akşam ve hafta sonu: yanıt süresinin çöktüğü saatler

Perakende ve hizmet işletmelerinde mesaj trafiği mesai saatlerine değil, müşterinin boş vaktine göre şekillenir. Akşam saatleri ve hafta sonu, kutuya bakan kişinin çalışmadığı zamandır. Yani hacmin yoğunlaştığı saatler ile kapasitenin bulunduğu saatler birbirini tutmaz.

Bu makasın maliyeti sadece geç yanıt değil. Cuma akşamı gelen bir soru pazartesi sabahı yanıtlandığında, müşteri o arada başka bir hesaptan alışverişini yapmış olur. Kutuda görünen şey bir "yanıtlanmış konuşma"dır; kaybedilen satış hiçbir yerde görünmez. Yanıt süresinin gelirle ilişkisini genel olarak Türkçe konuşan yapay zeka müşteri temsilcisi kurma yazısında ayrıntılandırdık.

Kapanan mesajlaşma penceresi

Instagram Mesajlaşma API'si üzerinden çalışan her araç, platformun tanımladığı yanıt penceresine tabidir. Kullanıcının başlattığı bir konuşmaya standart olarak 24 saat içinde yanıt verebilirsiniz; pencere kullanıcının son mesajıyla açılır ve her yeni mesajında yeniden başlar. Pencere kapandıktan sonra elinizde kalan yol daralır.

Bunun otomasyon tasarımına doğrudan etkisi var: bir asistanın en değerli olduğu an, pencerenin kapanmasına birkaç saat kalan konuşmaları öne çıkardığı andır. "Kaç mesaj yanıtladık" değil, "hangi konuşmanın süresi doluyor" sorusu operasyonu yönetir.

DM sekmesinde kalan hiçbir şey kayda dönüşmüyor

Dördüncü arıza en sessiz olanı. Konuşma biter, sipariş çıkar, müşteri memnun olur ve geriye hiçbir aranabilir kayıt kalmaz. İkinci temasta aynı sorular yeniden sorulur. Kampanya planlarken kimin ne aldığı bilinmez. Ekipten biri ayrıldığında o kişinin baktığı konuşmaların bağlamı da gider.

Bunun ölçülebilir bir belirtisi var. Bir işletmenin Instagram'dan gelen müşterilerini kişi kaydında aratın. Aradığınız isimlerin çoğu bulunamıyorsa, kanal kayıtsız çalışıyor demektir. Bu testi yapan ekiplerin büyük bölümü, aylardır konuştuğu kişilerin sistemde hiç görünmediğini fark ediyor.

Bu dört arızanın ortak paydası var: hepsi okuma, sınıflandırma ve kayıt işlerinden oluşuyor. Hiçbiri "müşteriyle konuşma" değil. Yapay zekayı bu üç işe koyduğunuzda kazanç net; dördüncü işe, yani konuşmanın kendisine koyduğunuzda risk başlıyor. Yetki seviyesi ayrımı tam olarak bu çizgiyi çiziyor.

Üç yetki seviyesi: oku, taslak yaz, yanıtla

Yetki devri kademeli bir karardır ve seviyeler arasında geri dönüş kolaydır. Aşağıdaki tablo üç seviyeyi kazanç, risk, gereken anahtar kapsamı ve kime uygun olduğu üzerinden karşılaştırıyor.

Seviyeyi seçerken sorulacak tek soru

Seviye kararını "yapay zeka ne kadar iyi" sorusuyla vermeyin. Şu soruyla verin: bu mesaj sınıfında yanlış bir yanıt gitse, geri almanın maliyeti nedir?

Çalışma saatini yanlış söylemek düzeltilebilir bir hatadır, müşteri güler geçer. Bir iade talebine "iade süreniz doldu" demek düzeltilemez bir hatadır, çünkü müşteri o ekran görüntüsünü alır ve konuşma oradan itibaren şikayete döner. Aynı model, aynı istem, iki farklı sonuç. Fark modelde değil, sınıfta.

Pratik kural: seviye 3'e geçmeye karar verdiğiniz her mesaj sınıfı için önce en az iki hafta seviye 2'de çalışın ve o sınıftaki taslakların kaçının düzeltilmeden onaylandığını sayın. Oran yüzde doksanın altındaysa o sınıf otonoma hazır değil.

Instagram DM yapay zeka kurulumu: kutuyu asistana MCP ile bağlamak

Üç seviyenin de altında aynı bağlantı var. Asistanın Instagram kutusunu görebilmesi için kutunun asistana bir protokol üzerinden açılması gerekiyor. Bunu Model Context Protocol ile yapıyoruz. MCP, bir yapay zeka istemcisinin (Claude Desktop, Claude Code, Cursor, ChatGPT gibi) dış sistemlerdeki araçları, kaynakları ve hazır istemleri keşfedip çağırmasını sağlayan açık bir standart.

Burada önemli bir mimari ayrıntı var. npm paketi Instagram ile konuşmuyor. Yerel makinede stdio üzerinden çalışan bir vekil (proxy) ve JSON-RPC çağrılarını bearer anahtarınızla POST https://api.crmsolid.com/mcp adresine iletiyor. Platform bağlantılarını CRM Solid tarafı tutuyor. Yani hiçbir Instagram şifresi, oturum çerezi ya da erişim jetonu yerel makinenize inmiyor. Güvenlik tarafındaki ayrıntılar için güvenlik sayfasına bakabilirsiniz.

İstemci yapılandırması şu şekilde:

{
  "mcpServers": {
    "crmsolid": {
      "command": "npx",
      "args": ["-y", "@crmsolid/mcp-server", "--read-only", "--tools", "social,contacts"],
      "env": { "CRMSOLID_API_KEY": "csk_live_..." }
    }
  }
}

Bu yapılandırmada iki bayrak var ve ikisi de seviye 1 için doğru ayarlanmış durumda. --read-only her yazma aracını yerelde düşürür; istemci o araçların var olduğunu bile görmez. --tools social,contacts yüzeyi iki aileye daraltır. Filtre yerel vekilde çalıştığı için filtrelenmiş bir araç ne listelenir ne de çağrılabilir. Aynı ayarlar ortam değişkeni olarak da verilebilir: CRMSOLID_READ_ONLY ve CRMSOLID_TOOLS.

Anahtarı https://app.crmsolid.com/settings/developers adresinden üretiyorsunuz ve kapsamları anahtar bazında veriyorsunuz. Seviye 1 için social:read yeterli. Seviye 2 ve 3'e geçtiğinizde social:write ekleniyor. Kişi kaydı yazacaksanız contacts:write, görev açacaksanız tasks:write gerekiyor. Kapsam ve araç yüzeyinin tamamını sosyal medya MCP sunucusunu anlattığımız yazıda bulabilirsiniz; aynı sunucu üzerinden gönderi planlamayı ise yapay zeka ile sosyal medya gönderi planlama yazısında ele aldık.

Bir not: MCP araç çıktıları camelCase, v1 REST API ise PascalCase kullanıyor. Bu yazıdaki tüm örnekler MCP tarafından, yani camelCase. REST tarafını API sayfasında göreceksiniz. İki gösterimi tek bir örnekte karıştırmayın.

Seviye 1 kurulumu: oku ve özetle

Seviye 1'in tamamı okuma. Anahtarda yazma kapsamı yok, vekilde --read-only açık. Bu seviyede bir hata yapmanız teknik olarak mümkün değil, o yüzden burada tereddüt etmeyin.

Çağrı sırası

1. crm_social_inbox_summary ile kutunun genel durumunu alın. Argümanı yok, tek çağrıda kaç konuşma aktif, kaçı okunmamış ve en uzun süredir yanıt bekleyenlerin hangileri olduğunu görürsünüz.
2. crm_list_social_conversations çağrısını platform: "instagram" ve status: "active" ile yapın. Sonuç conversations dizisi ile bir count taşır; limit ile kaç kayıt istediğinizi baştan söylersiniz (1 ile 100 arası, varsayılan 25).
3. Sınıflandırmaya değecek konuşmalar için crm_list_social_messages ile son mesajları okuyun. conversationId zorunlu, limit ve geçmişte geriye gitmek için beforeMessageId isteğe bağlı.
4. Asistandan sınıflandırma ve öncelik tablosu isteyin.

Bu dört adımın tamamı tek bir istemle tetiklenebilir. Aşağıdaki blokta istem, ardından ilk iki çağrının döndürdüğü gövdeler var.

İSTEM
Instagram gelen kutusunu incele. Önce kutu özetini al, sonra açık
Instagram konuşmalarını listele. Her konuşmayı şu dört sınıftan birine koy:
destek, satis, spam, hikaye-yaniti. Sonra bekleme süresine göre sırala ve
bir tablo çıkar. Hiçbir mesaj gönderme, sadece raporla.

crm_social_inbox_summary() ->
{
  "accounts": 4,
  "conversations": 132,
  "activeConversations": 34,
  "archivedConversations": 98,
  "unreadConversations": 11,
  "unreadMessages": 19,
  "lastMessageAt": "2026-08-24T08:41:12Z",
  "platforms": [
    { "platform": "instagram", "conversations": 71,
      "unreadConversations": 7, "unreadMessages": 12 },
    { "platform": "linkedin", "conversations": 38,
      "unreadConversations": 3, "unreadMessages": 5 }
  ],
  "awaitingReply": [
    { "conversationId": 4821, "platform": "instagram",
      "participantName": "Dilara K.", "contactId": 91043,
      "unreadCount": 2, "lastMessageAt": "2026-08-24T08:41:12Z",
      "lastMessagePreview": "12 aylık paket hâlâ var mı?" }
  ]
}

crm_list_social_conversations({ "platform": "instagram",
                                "status": "active", "limit": 20 }) ->
{
  "count": 18,
  "conversations": [
    {
      "id": 4821,
      "platform": "instagram",
      "participantName": "Dilara K.",
      "participantUsername": "dilarak",
      "contactId": 91043,
      "unreadCount": 2,
      "status": "active",
      "lastMessageAt": "2026-08-24T08:41:12Z",
      "lastMessageOutgoing": false,
      "lastMessagePreview": "12 aylık paket hâlâ var mı?"
    }
  ]
}

awaitingReply listesine dikkat edin. Kutuda gerçekten acil olan bilgi bu: en eskisi başta olmak üzere, hâlâ yanıt bekleyen konuşmalar (en fazla on tane). Okunmamış sayısı sizi yanıltır, çünkü içinde tek kelimelik hikâye yanıtları da vardır; bekleyenler listesi ise doğrudan çalışılacak sırayı verir.

İki yapısal ayrıntıyı burada not edin, çünkü ikisi de REST alışkanlığından gelen varsayımları bozuyor. Birincisi, bütün kimlikler tam sayıdır: conversationId: 4821, contactId: 91043. İkincisi, MCP listeleme araçları imleç tabanlı sayfalama kullanmaz: items, nextCursor, hasMore ve after bu yüzeyde yoktur. limit verirsiniz, adı olan bir dizi ile count alırsınız. Bunun pratik sonucu şu: limiti baştan söylemezseniz model 25 kaydı bütün kutu sanıp özetleyebilir, o yüzden dönen count değerini özetteki activeConversations sayısıyla karşılaştırın. İmleçli sayfalama v1 REST API tarafına aittir.

Konuşma durumu da yalnızca iki değer alır: active ya da archived. "Açık" diye bir durum değeri yoktur, dolayısıyla status: "open" yazan bir örnek görürseniz o örnek eskidir. Katılımcı alanları ise participantName ve participantUsername adını taşır ve kullanıcı adı baştaki at işareti olmadan gelir.

Asistanın çıkardığı triyaj tablosu

Yukarıdaki istem karşılığında beklediğiniz çıktı bir metin paragrafı değil, doğrudan çalışılabilir bir tablodur. Tipik biçimi şu:

Seviye 1'den ne bekleyebilirsiniz

Bu seviyenin getirisi çoğu ekibin tahmin ettiğinden büyük. Sabah kutuyu açan kişi artık "nereden başlayayım" sorusuyla karşılaşmıyor, önüne sıralanmış bir liste geliyor. Spam konuşmalar listeden düşüyor. Yanıt penceresi kapanmak üzere olan konuşmalar üste çıkıyor.

Bir de gizli faydası var: asistanın sınıflandırmasını bir hafta izlediğinizde kendi kutunuzun dağılımını sayıyla öğreniyorsunuz. Çoğu işletme "mesajlarımızın çoğu sipariş sorusu" der ve ölçtüğünde dağılımın destek ağırlıklı olduğunu görür. Bu bilgi hem mesaj şablonlarınızı hem de gönderi planınızı değiştirir; en sık gelen üç sorunun cevabı zaten içerikte olmalıdır.

Sınıflandırma sonuçları tek kanalla sınırlı kalmasın. Aynı çağrılar platform argümanı olmadan yapıldığında bütün kanalları kapsar; tek gelen kutusu mantığının değeri de burada ortaya çıkar.

Sınıflandırma isabetini nasıl ölçersiniz

Seviye 2'ye geçme kararını hisle değil sayıyla verin. Yöntem basit ve bir saatinizi alır: asistanın bir günde sınıflandırdığı konuşmalardan rastgele elli tanesini seçin, sınıfları gizleyin ve aynı elli konuşmayı kutuya bakan kişi elle sınıflandırsın. Sonra iki listeyi karşılaştırın.

Burada bakacağınız şey genel isabet oranı değil, hangi yönde yanıldığı. Spam olan bir konuşmaya "destek" demek zararsız bir hatadır, sadece gereksiz iş üretir. Destek olan bir konuşmaya "spam" demek ise gerçek bir kayıptır, çünkü o konuşma bir daha listede görünmez. İkinci tür hata sıfıra yakın olmalı; birinci türde toleranslı olabilirsiniz.

Aynı testi ayda bir tekrarlayın. Ürün yelpazeniz değiştikçe, kampanya dönemlerinde ve yeni bir kanal açtığınızda dağılım kayar ve sınıflandırma kuralı eskir.

Seviye 2 kurulumu: onaya taslak yazan asistan

Seviye 2'de asistan yazmaya başlıyor ama göndermiyor. Aradaki fark tek bir insan onayı. Bu seviye çoğu ekibin uzun süre kalacağı yer ve doğru kurulduğunda seviye 3'e ihtiyaç bile duyulmuyor.

dm-reply-draft hazır istemi ve tone argümanı

Sunucu dm-reply-draft adında hazır bir istem yayımlıyor. İki argümanı var: zorunlu ve sayısal conversationId ile isteğe bağlı tone. Hazır istemler MCP istemcisinde seçilebilir bir komut olarak görünür, yani her seferinde uzun bir istem yazmanız gerekmez. İstem yalnızca taslak yazar; onu gönderime çeviren bir argüman yoktur, bu yüzden işe yeni başlayan birine güvenle verilebilir.

tone argümanı süs değil, ama serbest metin de değil: üç değer alır. friendly (varsayılan), professional ve urgent. Aynı konuşmaya farklı tonlarda iki taslak istediğinizde çıkan metinler ölçülebilir biçimde farklılaşır ve bu fark Türkçede daha keskindir, çünkü hitap biçimi (siz/sen) tonun taşıyıcısıdır. Türkiye pratiğinde güvenli varsayılan "siz"dir ve bunu professional ile birlikte marka sesi dosyanızda sabitlemeniz gerekir.

Küme kapalı olduğu için listede olmayan bir değer yazmayın. tone: "resmi" geçtiğinizde uyarı almazsınız; istem o değeri tanımaz ve uyguladığınızı sandığınız yönlendirmeyi kaybedersiniz. Üç seçeneğin ötesindeki incelik marka sesi dosyasına aittir, ki zaten doğru yeri orasıdır.

dm-reply-draft({ "conversationId": 4821, "tone": "professional" })

Asistan önce konuşmayı okur:
crm_list_social_messages({ "conversationId": 4821, "limit": 10 }) ->
{
  "conversationId": 4821,
  "platform": "instagram",
  "count": 1,
  "messages": [
    {
      "id": 88213,
      "direction": "inbound",
      "senderName": "Dilara K.",
      "text": "12 aylık paket hâlâ var mı?",
      "attachmentUrl": null,
      "attachmentType": null,
      "transcript": null,
      "translation": null,
      "status": "delivered",
      "sentAt": "2026-08-24T08:41:12Z"
    }
  ]
}

TASLAK
Merhaba Dilara Hanım, 12 aylık paket satışta. Kapsamı ve güncel koşulları
paket sayfasında görebilirsiniz. Aklınıza takılan bir nokta olursa buradan
yazmanız yeterli.

Taslakta bir şeyin olmadığına dikkat edin: rakam yok. Asistan fiyat, stok adedi ya da teslim tarihi gibi doğrulanabilir bir veriyi üretemez; ya canlı bir kaynaktan okur ya da söylemez. Modelin hafızasından çıkan her rakam bir taahhüttür ve sizi bağlar.

Marka sesi dosyası ve içine ne yazılır

Taslak kalitesini belirleyen şey modelden çok marka sesi tanımıdır. Bunu istemin içine gömmeyin, ayrı bir dosyada tutun ve asistana bağlam olarak verin. Dosya dört başlıktan oluşur ve her başlık kural cümleleriyle yazılır, örnekle değil.

• Hitap. Her zaman "siz", müşteri "sen" dese bile. Müşterinin hitabını (abi, canım, hocam) tekrarlama. İsim biliniyorsa "Ad + Hanım/Bey" ile başla, bilinmiyorsa yalın bir "Merhaba" yeterli.
• Uzunluk ve biçim. En fazla üç cümle, liste gerekiyorsa en fazla dört madde. Emoji yok. Bir mesajda en fazla bir ünlem işareti. Büyük harfle vurgulama yok.
• Asla yazılmayacaklar. Fiyat, indirim oranı, stok adedi, teslim tarihi. İade veya iptal kararı ("iade edebilirsiniz", "süreniz doldu"). Kesin taahhüt ("yarın kesin elinizde olur"). Bilinmeyen bir bilgiyi tahminle doldurma.
• Türkçe kuralları. Diyakritikler tam yazılır: ı, İ, ş, ğ, ü, ö, ç. Ekler isme uydurulur ("Ayşe'ye", "Burak'a"). Otomatik çeviri kokan kalıplardan kaçınılır ("size yardımcı olmaktan mutluluk duyarım").

Son başlık Türkçe için özellikle önemli. Aksansız yazılmış bir marka yanıtı ("Merhaba Ayse Hanim, siparisiniz kargoya verildi") müşteride derhal "bu bir bot" izlenimi bırakır. Diyakritik tutarlılığı ton kadar ciddi bir kalite sinyalidir ve ölçmesi kolaydır: bir haftalık giden mesajları alıp içinde ı, ş, ğ, ü, ö, ç harflerinin hiç geçmediği yanıtları sayın. Sıfırdan büyük her sonuç düzeltilmesi gereken bir kalite açığıdır.

Dosyayı kısa tutun. Otuz satırı geçen bir marka sesi tanımı, her çağrıda modele yeniden gönderildiği için hem maliyet üretir hem de asıl kuralların ağırlığını azaltır. Kural sayısı arttıkça uyum oranı düşer.

İnsan onayı kapısı

Onay kapısının sorunu teknik değil, davranışsal. İlk hafta herkes taslakları dikkatle okur. Üçüncü haftada okumadan onaylamaya başlar. Bunu engellemenin üç somut yolu var.

1. Taslakların yüzde onunu rastgele işaretleyip ikinci bir kişiye okutun. Denetimin var olduğunu bilmek yeterlidir.
2. İçinde rakam, tarih veya "iade" geçen taslakları ayrı bir kuyruğa alın. Bu üç kelime, düzeltilemez hataların büyük bölümünü kapsıyor.
3. Onay öncesi düzeltme oranını haftalık ölçün. Oran aniden düşerse bu bir kalite artışı değil, dikkat düşüşüdür.

Bir de tasarım tarafında alınabilecek bir tedbir var: taslağı gönderim düğmesinin içine gömmeyin. Onaylayan kişinin metni bir kez daha görmesini gerektiren küçük bir sürtünme, okumadan onaylamayı belirgin biçimde azaltır. Aynı mantıkla, asistanın ürettiği taslağı otomatik olarak yazma alanına doldurup imleci sona koymak yanlış bir tercihtir; kişi metni okumadan enter'a basar.

Onay kapısı ekip büyüdükçe daha da önemli hâle gelir. İki kişilik bir ekipte herkes her taslağı görür. Sekiz kişilik bir ekipte kimin neyi onayladığı görünmez ve sorumluluk dağılır. Onaylayan kişinin kaydını tutun; bu bir denetim aracı değil, hatanın nereden geldiğini bulma aracıdır.

Çift gönderimi gerçekte ne engelliyor

Taslak onaylandıktan sonra gönderim crm_send_social_message ile yapılır. Argümanlarının tamamı şu: conversationId, text ve isteğe bağlı mediaUrl. Metin ya da medyadan biri zorunlu, metin 8000 karakterle sınırlı.

Şimdi bu bölümün asıl konusu olan arızaya gelelim. crm_send_social_message sözleşmede açıkça idempotent olmayan bir yazma aracı olarak işaretli. Bir ağ zaman aşımı olduğunda model çağrının başarısız olduğunu sanır ve tekrar dener. Oysa mesaj ilk denemede gitmiştir. Müşteri aynı yanıtı iki kez alır. Bir asistanın yapabileceği en itibar bozucu hatalardan biri budur, çünkü doğrudan "bu bir bot" anlamına gelir.

Bu araçta idempotencyKey diye bir parametre yok. Bir yerde böyle bir alan gördüyseniz o örnek ya REST uç noktasına aittir ya da sunucu yayımlanmadan önce yazılmıştır. Tekrarı birincinin içine katlayan geçebileceğiniz bir alan bulunmuyor. Sizi koruyan üç şey var ve hangisinin iş gördüğünü bilmek önemli:

1. Araç yazma olarak işaretli, bu yüzden istemci önce sorar. Seviye 2 kurulumunda bu ekstra bir adım değil, zaten yukarıdaki onay kapısının ta kendisidir. Yeniden deneme ikinci bir onay ekranı demektir; aynı mesajı iki kez onaylamak, okuyan bir insanın fark edebileceği bir şeydir.
2. Platform reddi hata döndürür, sessiz yeniden deneme değil. Yanıt penceresi kapandıysa geriye The platform rejected this message: outside the 24 hour window (code 10) gibi bir hata gelir. Sunucu bunu yutmaz, kuyruğa alıp arkanızdan denemez. Sert pencereleri olan bir kanalda bu önemlidir: sessizce yeniden deneyen bir sistem duvara vurmaya devam ederken size hiçbir şey söylemezdi.
3. Yeniden çalıştırmadan önce konuşmayı okuyun. Üç saniyelik kural: crm_list_social_messages ile konuşmayı okuyup metninizi taşıyan bir outbound mesaj var mı bakın. Varsa gönderim olmuş, yalnızca yanıt kaybolmuştur.

Asistan yerine kod yazıyorsanız v1 REST gönderim uç noktası idempotency anahtarı kabul eder ve gözetimsiz işler için doğru yüzey odur. Anahtarın neden orada olduğu da anlaşılır: idempotency yalnızca anahtar niyetten deterministik türetildiğinde, yani ilk denemeden önce bir kez üretilip her tekrarda aynı kaldığında çalışır. Bu bir program için kolay, bir dil modeli için güvenilmezdir; model kimlik alanını her çağrıda yeni bir değer uydurma daveti olarak görür ve her denemede yenilenen anahtar hiçbir şeyi korumaz.

crm_send_social_message({
  "conversationId": 4821,
  "text": "Merhaba Dilara Hanım, 12 aylık paket satışta. Kapsamı ve güncel koşulları paket sayfasında görebilirsiniz. Aklınıza takılan bir nokta olursa buradan yazmanız yeterli."
}) ->
{
  "status": "sent",
  "messageId": 88214,
  "conversationId": 4821,
  "platform": "instagram",
  "contactId": 91043,
  "externalMessageId": "aWdfZG1fMTo...",
  "sentAt": "2026-08-24T12:03:41Z",
  "message": "Message sent on instagram to Dilara K."
}

crm_mark_social_conversation_read({ "conversationId": 4821 })

Bu gönderimin iki yan etkisi var ve ikisi de bayrakla açılmıyor. Birincisi, gönderim operatör devralması işaretler ve yapay zeka ajanını o kişi için duraklatır. Seviye 2 ve 3 kurulumlarında asıl tehlikeli çift gönderim, aynı mesajın iki kez gitmesi değil, insan yanıtı ile otomatik yanıtın aynı konuşmaya bir dakika arayla farklı şeyler söylemesidir. Devralma gönderimin kendisiyle tetiklendiği için, bir insan konuştuğu anda otomasyon geri çekilir. İkincisi, gönderim kişi zaman tüneline bir mesaj etkinliği olarak yazılır.

Yazma araçlarının ortak bir tasarım kuralı var ve güvenlik açısından önemli: hiçbir araç hem okuyup hem yazmıyor. Bir yazma çağrısı size neyin değiştiğinin onayını döndürür, veri akışı döndürmez. Bu ayrım sayesinde --read-only bayrağı gerçekten anlamlı bir kilit oluyor.

Seviye 3 kurulumu: dar bir sınıfta otonom yanıt

Seviye 3'te asistan insana sormadan yanıtlıyor. Bu seviyenin tek doğru kurulum biçimi var: izin verilen konu sınıfını olabildiğince daraltmak ve geri kalan her şeyi kapalı tutmak. Beyaz liste mantığı, kara liste değil.

İnsansız yanıtlanabilecek mesaj sınıfı

Otonom yanıt için uygun bir mesaj sınıfının üç özelliği vardır: cevabı sabittir, cevabı doğrulanabilir, yanlış cevabın maliyeti düşüktür. Bu üçünü aynı anda sağlayan sınıf listesi kısadır.

Listede olmayan her şey seviye 2'de kalır. Özellikle "ürün önerisi" cazip görünür ve tuzaktır: öneri bir taahhüt üretmez ama yanlış öneri satış kaybettirir ve müşteride "bu hesap beni tanımıyor" izlenimi bırakır.

Kesin durak listesi

Otonom kuralın en önemli parçası nerede duracağını söyleyen kısımdır. Bunu istemin sonuna değil başına yazın.

OTONOM YANIT KURALI

Yalnızca şu sınıflarda kendi başına yanıt ver:
calisma-saati, kargo-durumu, beden-tablosu, odeme-yontemleri, mesai-disi-karsilama

Aşağıdakilerden BİRİ bile geçerliyse yanıt verme, konuşmayı devret:
- Mesajda iade, iptal, para iadesi, garanti veya değişim geçiyor.
- Mesajda avukat, tüketici hakem heyeti, şikayet, ters ibraz geçiyor.
- Müşteri daha önce en az bir kez yanıt aldı ve konu kapanmadı.
- Mesajda bir tarih taahhüdü isteniyor ("ne zaman elimde olur").
- Fiyat, indirim veya stok adedi soruluyor.
- Mesaj tek kelime ve sınıfı belirsiz.
- Mesaj Türkçe değil ve marka sesi dosyasında o dil tanımlı değil.
- Sınıflandırma güveni düşük. Emin değilsen devret, tahmin etme.

Yanıt verirken:
- Yalnızca canlı kaynaktan okuduğun bilgiyi yaz. Hafızandan rakam üretme.
- Bilgi kaynakta yoksa "kontrol edip döneceğim" deme, doğrudan devret.
- Her otonom yanıttan sonra kişi kaydına not düş.

"Emin değilsen devret" maddesi tek başına en çok kazandıran satırdır. Bir asistanın en tehlikeli hâli bilgisizliğini fark etmediği hâldir; kurala açıkça yazıldığında devretme davranışı ölçülebilir biçimde artar.

Satış konuşmalarında seviye 3'e geçmeyin

Bu bir fikir ve arkasında duruyoruz: çoğu ekip satış konuşmalarında seviye 3'e geçmemeli.

Gerekçe şu. Destek konuşmasında hedef sorunun çözülmesidir ve doğru cevap tektir. Satış konuşmasında hedef karşı tarafı ikna etmektir ve doğru cevap kişiye göre değişir. Bir müşteri fiyat duyarlı, diğeri teslim süresi duyarlı, üçüncüsü sadece güven arıyor. Bu ayrımı yapmak bağlam okumayı gerektirir ve bağlamı yanlış okuyan bir otonom yanıt satışı kapatmaz, kapatır gibi görünüp müşteriyi soğutur.

İkinci gerekçe daha somut: satış konuşmalarında rakam geçer. Rakam geçen her yerde taahhüt riski vardır. Seviye 2'de aynı hızın büyük bölümünü zaten alıyorsunuz, çünkü asistan taslağı yazdıktan sonra insanın yaptığı iş okumak ve göndermek; bu iş saniyeler sürüyor. Aradaki farkı, kaybetme ihtimaliniz olan satışla karşılaştırın.

Yükseltme ve insana devir: tetikleyici ifadeler ve devir notu

Otonom ya da yarı otonom her kurulumda asıl kalite, devir mekanizmasının kalitesidir. Kötü kurulmuş bir devir, hiç otomasyon olmamasından daha kötü sonuç verir.

Tetikleyici ifadeler

Devrin dört adımı

1. Görev açın. crm_create_task ile konuşmaya bağlı bir görev oluşturun. Görev başlığında konuşma kimliği geçsin, aksi hâlde görev listesinden konuşmaya dönmek zorlaşır.
2. Kişiyi atayın. Devir bir kişiye yapılır, ekibe değil. "Ekip bakar" diye bırakılan konuşma kimsenin bakmadığı konuşmadır.
3. Asistanı o kişide durdurun. Bunu kurmanız gerekmiyor ve kurmaya çalışmayın. crm_send_social_message gönderimi operatör devralması işaretler ve yapay zeka ajanını o kişi için otomatik olarak duraklatır; yani devri alan insan ilk yanıtını gönderdiği anda otomasyon o kişiye cevap vermeyi bırakır. Kapsam da doğru yerde: tek bir kişi, bütün hesap değil. Etiketle işaretleyip kuralın o etikete bakmasını sağlamak gibi bir çözüm uydurmanıza gerek yok. Yalnızca ilk insan yanıtından önceki boşluk sizin elinizde kalır ve oranın cevabı yukarıdaki görev ile atamadır. Yapay zeka ajanları tarafındaki devir ayarları bu davranışı yönetiyor.
4. Devir notunu yazın. Devri alan kişinin konuşmayı yukarı doğru kaydırarak okuması gerekiyorsa devir başarısızdır.

Devir notu formatı

Not serbest metin olmasın. Sabit beş satır, her zaman aynı sırada:

crm_add_contact_note({
  "contactId": 91043,
  "note": "DEVİR | konuşma 4821 | instagram\nTALEP: 12 aylık paket kapsamı ve süre sonu koşulları\nBAĞLAM: 24.08 08.41'de yazdı, otonom yanıt verilmedi (fiyat sorusu)\nDENENEN: Yok. Sınıf 'satis' olduğu için doğrudan devredildi\nSONRAKİ ADIM: Paket koşulları teyit edilip yanıt yazılacak\nPENCERE: Standart yanıt penceresi 25.08 08.41'de kapanıyor"
})

Son satır Instagram'a özgü ve en çok işe yarayan satır. Devri alan kişi elindeki işin ne zamana kadar yapılabilir olduğunu görmeden doğru önceliklendiremez.

DM'i CRM kaydına çevirmek: not, etiket, skor, aşama

Bu bölüm yazının en çok atlanan ama parasal karşılığı en yüksek kısmı. Yapay zeka kutuyu yönetirken aynı anda kayıt da üretmezse, hızlanmış bir unutma makinesi kurmuş olursunuz.

Dört çağrı ve ne zaman yapılır

Bu dört çağrı contacts:write kapsamı ister. Seviye 1'de bu kapsam yoktur, dolayısıyla kayıt üretimi seviye 2 ile birlikte devreye girer. Kişi kartı mantığının tamamını müşteri takip programı sayfasında görebilirsiniz.

Tek başına gelen kutusu neden para kaybettirir

Bir gelen kutusu zaman sırasına göre çalışır. Müşteri ilişkisi ise duruma göre çalışır. Bu iki mantık aynı ekranda birleşmez.

Somut sonuç şu: kutuda "yanıtlanmış" görünen bir konuşma, ilişki tarafında hiçbir iz bırakmaz. Aynı kişi altı hafta sonra döndüğünde ona ilk kez yazıyormuş gibi davranılır. Beden yeniden sorulur, adres yeniden istenir, geçen siparişteki kargo gecikmesi bilinmez. Müşteri bunu fark eder ve fark ettiğinde satın alma ihtimali düşer.

İkinci sonuç ölçümle ilgili. Kayıt yoksa "Instagram bize ne kazandırıyor" sorusunun cevabı da yoktur. Kanalın gelirini görebilmek için konuşmanın bir kişiye, kişinin bir fırsata ve fırsatın bir tutara bağlanması gerekir. Bu zinciri kurduğunuzda raporlama tarafı kanal bazında gerçek sayı üretmeye başlar. Fırsat tarafını ise satış hunisi üzerinden takip edersiniz.

Bir uyarı: asistanın ürettiği notlar konuşmanın kopyası olmasın. Otuz satırlık bir DM geçmişini kişi kartına yapıştırmak arama sonuçlarını çöpe çevirir. Not, kararı ve sonucu yazar; konuşmanın kendisi zaten konuşmada durur.

Instagram'ın kendi kuralları: yanıt penceresi ve otomasyon sınırları

Buradaki bilgilerin tamamı Meta'nın kendi geliştirici dokümanlarına dayanıyor. Üçüncü taraf blog yorumlarına değil, birincil kaynağa bakın, çünkü bu alan sık değişiyor.

Standart 24 saatlik pencere

Instagram Mesajlaşma API'sinin temel kuralı Meta'nın mesaj gönderme dokümanında tanımlı: konuşmalar bir Instagram kullanıcısı işletmenin profesyonel hesabına mesaj gönderdiğinde başlar ve uygulamanızın o mesaja yanıt vermek için 24 saati vardır. Pencere kullanıcının her yeni mesajıyla yeniden açılır.

Bunun otomasyon tasarımına iki etkisi var. Birincisi, önceliklendirme mantığınızın merkezinde "bekleme süresi" değil "pencerenin kalan süresi" olmalı. İkincisi, mesai dışı ilk karşılama yanıtı sadece nezaket değil, pencereyi yönetme aracıdır.

İnsan temsilci yolu

Meta, insan temsilcinin her zaman 24 saat içinde yetişemeyeceğini kabul ediyor. Messenger Platform ve Instagram Mesajlaşma API'si politikasında mesaj etiketleri, işletmelere standart pencerenin dışında kişiye özel önemli güncellemeler gönderme imkânı veriyor; insan temsilci etiketi ise işletmenin kullanıcı mesajlarına daha uzun bir süre içinde elle yanıt vermesine izin veriyor.

Adındaki kelimeye dikkat: elle. Politika bu yolu geciken bir insan yanıtı için tanımlıyor, otomatik gönderim için değil. Yani bu etiketi "asistan hafta sonu birikeni pazartesi göndersin" diye kurgulamak yanlış okumadır. Aynı politika, giderilmeyen ihlallerde mesaj gönderme yeteneğinin kısıtlanabileceğini de söylüyor.

İstenmeyen toplu DM

Elinizde kullanıcı adı listesi olması o kişilere mesaj atabileceğiniz anlamına gelmiyor. Konuşmayı müşteri başlatır. İstenmeyen toplu DM hem platform kurallarına aykırı hem de pratikte çalışmaz: istek klasörüne düşer, spam işaretlenir ve hesap risk altına girer. Bu yüzden bu yazıdaki hiçbir kurulum soğuk mesaj üretmiyor; hepsi gelen mesaja yanıt üretiyor. Hesap kısıtlarının nasıl işlediğini mesajlaşma kanallarında hesap kapanma riskini anlattığımız yazıda bulabilirsiniz.

Politika değişir, dokümanı siz kontrol edin

Bu bölümdeki kuralların hepsi yayın tarihinde geçerliydi. Meta'nın mesajlaşma politikaları ve otomasyon kuralları düzenli olarak güncelleniyor; pencere süreleri, etiket tanımları ve izinli kullanım biçimleri değişebiliyor. Kurulumu yapmadan önce güncel politika dokümanını kendiniz okuyun. Emin olmadığınız bir kuralı varsayımla uygulamayın.

Türkiye tarafı: izin, KVKK, ton ve Europe/Istanbul

Yapay zeka kutuyu yönetirken Türkiye'de üç ek başlık devreye giriyor. Hiçbiri kurulumu engellemiyor ama üçü de tasarımı değiştiriyor.

Yanıt ile ticari ileti arasındaki çizgi

Gelen bir mesaja yanıt vermek ile kendiliğinden kampanya duyurusu göndermek hukuken aynı şey değil. İkisini ayıran soru şu: konuşmayı kim başlattı? Asistanınız gelen soruya cevap verirken serbesttir; kendi inisiyatifiyle promosyon mesajı göndermeye başladığı anda ticari elektronik ileti rejimine girer ve izin yükümlülüğü doğar.

Bu ayrımın ayrıntısı ve onay kayıtlarının nasıl tutulacağı için toplu mesajın yasal çerçevesini ve İYS rehberini okuyun. Pratik tasarım kararı basit: otonom kurala "kendiliğinden promosyon mesajı üretme" satırını ekleyin ve kampanya gönderimlerini bu akışın tamamen dışında tutun.

DM içeriği kişisel veridir

Bir DM konuşması ad, kullanıcı adı, telefon, adres ve zaman zaman sipariş ve ödeme bilgisi taşır. Bunların tamamı kişisel veridir ve bir yapay zeka asistanına okutulması işleme faaliyetidir. Üç somut sonucu var.

Birincisi, kişi kartına yazılan not ne kadar azsa risk o kadar düşüktür. Konuşmanın tamamını kopyalamak yerine kararı yazın. İkincisi, asistanın hangi verileri gördüğünü kapsamla sınırlayın: --tools ve --read-only bayrakları burada uyum aracı olarak da işe yarıyor. Üçüncüsü, verinin nerede işlendiği önemli. Yurt dışı aktarım tarafını KVKK yurt dışına veri aktarımı yazısında ayrıntılı ele aldık.

Türkçe taslaklarda ton ve diyakritik

Türkçe yanıtlarda iki hata markayı hemen ele verir. Birincisi aksansız yazım. İkincisi ek çekiminin isme uymaması: "Ayşe'ya", "Burak'e" gibi biçimler bir insanın yapmayacağı hatalardır ve şablon motoru bunları düzenli olarak üretir. Marka sesi dosyanızdaki ek kuralları bu yüzden var.

Üçüncü bir ayrıntı hitapla ilgili. Bir konuşma asistandan insana devredildiğinde hitabın değişmemesi gerekir. Asistan "siz" diyip devralan temsilci "sen" derse, müşteri devri fark eder ve devir fark edildiğinde güven düşer.

Mesai saati ve zaman dilimi

Zamanlama kararlarını her zaman Europe/Istanbul üzerinden verin. MCP çıktılarındaki zaman damgaları UTC (örneğin 2026-08-24T08:41:12Z); yerel saat dönüşümünü yapmadan "üç saattir bekliyor" gibi bir çıkarım yaparsanız üç saat sapma alırsınız.

İkinci nokta mesai dışı karşılamanın içeriğiyle ilgili. "En kısa sürede döneceğiz" cümlesi hiçbir şey söylemez. "Yarın 09.00'dan itibaren yanıtlıyoruz" der ve gerçekten 09.00'da dönerseniz, geç yanıtın maliyeti büyük ölçüde ortadan kalkar. Beklenti yönetimi, hızın kendisinden ucuz bir ikamedir.

Ölçme: dört sayı ve içlerindeki tuzaklar

Kurulum çalışıyor mu sorusunun cevabı dört sayıda. Her birinin içinde bir tuzak var ve tuzağı bilmeden bakılan sayı yanlış karar ürettirir.

Ölçümü nereden okursunuz

İlk üç sayı sosyal kutu tarafından, dördüncüsü kişi ve fırsat kayıtlarından geliyor. Bu dördünü bir arada gösteren yer panelde raporlama ekranı; MCP yüzeyinin ne verip ne vermediği konusunda net olalım, çünkü burada beklenti sık şişiyor. crm_social_inbox_summary anlık durumu verir: platform kırılımıyla aktif ve okunmamış sayıları, üstüne hâlâ yanıt bekleyen konuşmalar. crm_messaging_stats ise windowDays argümanını alır (yalnızca 1, 7 veya 30) ve giden mesaj hacmi ile başarı oranını döner: kuyruğa alınan, gönderilen, başarısız, toplam. Bu bir teslim sağlığı ölçüsüdür, yanıt süresi raporu değildir ve platform kırılımı vermez.

Yanıt süresi medyanları, kohort görünümleri ve konuşmadan fırsata dönüşüm oranı bugün MCP yüzeyinde yok; bunlar panelin raporlama tarafından gelir. Bu ayrımı baştan planlayın: asistandan anlık durumu ve gönderim sağlığını isteyin, trend çizgisi olan her şey için raporlama ekranını açın. Modelden kendi sayfaladığı bir listeden medyan hesaplamasını istemek, kimsenin tekrar üretemeyeceği kendinden emin bir sayı üretmenin en kısa yoludur.

Bir haftalık ölçümle karar vermeyin. Instagram trafiği kampanya, hikâye ve gönderi takvimine bağlı dalgalanır. En az dört haftayı, mümkünse aynı dönemin geçen yılını da karşılaştırın.

Başlangıç çizgisini kurulumdan önce alın

Bu dört sayının en çok atlanan yanı, kurulumdan sonra ölçülmeye başlanması. Asistanı bağladıktan sonra alınan ilk ölçüm neyle karşılaştırılacak? Hafızayla. Hafıza da her zaman iyimserdir.

Kurulumdan önce en az iki hafta boyunca aynı dört sayıyı elle toplayın. Bu iki hafta sıkıcıdır ama sonrasında yapacağınız her tartışmayı bitirir. "Yapay zeka işe yaradı mı" sorusunun cevabı, öncesi ve sonrası olan tek bir tabloda durur. Öncesi yoksa cevap da yoktur.

Bir de sayıya girmeyen ama izlenmesi gereken bir sinyal var: müşteriden gelen "botla mı konuşuyorum" tipi tepkiler. Bu cümlenin sıklığı, taslak kalitesinin en dürüst göstergesidir ve hiçbir panelde görünmez. Ayda bir kez giden mesajlar arasında arama yapın.

Yedi hata

1. İki bot arasında otomatik yanıt döngüsü

Karşı taraf da otomatik yanıt veriyorsa iki sistem birbirini tetikler. Sizin asistanınız yanıtlar, karşıdaki "mesajınızı aldık" der, sizinki onu yeni mesaj sanıp tekrar yanıtlar. Döngü dakikalar içinde onlarca mesaja çıkar ve hesabınız spam davranışı sergilemiş olur. Korunma yolu üç satır: aynı konuşmada arka arkaya en fazla iki otonom yanıt, aynı kişiye günde en fazla belirlenmiş bir sayıda otomatik mesaj, ve gelen mesaj otomatik yanıt kalıbına benziyorsa yanıt üretme.

2. Her yanıtın aynılaşmasına yol açan aşırı şablonlaşma

Marka sesi dosyası fazla katı yazıldığında asistan tek bir cümle kalıbını her yere uygular. Müşteri üç farklı soru sorar, üçüne de aynı yapıda cevap gelir. Bu, şablon kullanmaktan daha kötüdür, çünkü şablon olduğunu gizlemeye çalışan bir şablondur. Çözüm, marka sesi dosyasında cümle kalıbı değil sınır tanımlamak: neyi yazmayacağını söyleyin, nasıl yazacağını dikte etmeyin.

3. Hikâye yanıtlarının göz ardı edilmesi

Hikâye yanıtlarının çoğu tek kelimelik tepkidir ve bu yüzden toptan görmezden gelinir. Ama içlerinde gerçek talep de vardır ve hikâye kaybolduğunda bağlam da kaybolur. Doğru kurulum, hikâye yanıtlarını ayrı bir sınıfa alıp içinde soru işareti veya ürün adı geçenleri öne çıkarmaktır. Geri kalanına kısa bir teşekkür yeter.

4. Müşterinin saatiyle gece üçte mesaj atmak

Asistan yirmi dört saat çalışır, müşteri çalışmaz. Gece üçte gelen bir bildirim, içeriği ne kadar iyi olursa olsun rahatsız edicidir. Otonom yanıtın çalışacağı saat aralığını açıkça tanımlayın; aralık dışında ya sessiz kalın ya da sadece "sabah dönüyoruz" tipi tek bir karşılama gönderin. Zaman dilimini müşterinin değil hesabın saatine göre hesaplamak da yaygın bir hatadır.

5. Modele iade politikası uydurtmak

"İade koşullarımız nedir" sorusuna asistanın hafızasından cevap vermesi, en pahalı halüsinasyon türüdür. Model makul görünen bir gün sayısı üretir, müşteri o cümlenin ekran görüntüsünü alır ve o cümle sizi bağlar. Kural net: iade, garanti ve iptal koşulları asla üretilmez. Ya kaynaktan okunur ya da devredilir.

6. Rozeti temizlemek için her şeyi okundu işaretlemek

crm_mark_social_conversation_read pratik bir araçtır ve tam da bu yüzden kötüye kullanılır. Kutuyu temiz göstermek için toplu okundu işaretlemesi yapmak, sadece görsel bir rahatlama sağlar; işi ortadan kaldırmaz, görünmez kılar. Okundu işareti yalnızca gerçekten kapanmış ya da yanıt gerektirmediği doğrulanmış konuşmalara uygulanmalı.

7. Yapay zekayı ilk eleme yerine kadro yerine koymak

En büyük hata en başta yapılır: asistan kurulduktan sonra kutuya bakan kişinin işine son vermek. Bu kurulumun kazandırdığı şey kapasite değil, kapasitenin doğru yere kaydırılması. Sınıflandırma ve taslak yazma makineye geçer, insan devir alan ve kapatan işlere yoğunlaşır. Kadroyu düşürürseniz devir alacak kimse kalmaz ve seviye 3'ün durak listesi anlamsızlaşır, çünkü devredecek bir yer yoktur.

Aynı akış diğer platformlarda: on iki kanal, tek tarif

Bu yazıda anlatılan üç seviye Instagram'a özgü değil. Aynı araç seti Instagram, Facebook, X (Twitter), LinkedIn, TikTok, YouTube, Threads, Pinterest, Reddit, Bluesky, Telegram ve WhatsApp kutularını kapsıyor. crm_list_social_conversations çağrısına platform argümanını vermezseniz hepsi tek listede gelir.

Taşınan ne, taşınmayan ne? Tarifin kendisi taşınır: sınıflandırma, taslak, onay kapısı, dar otonom sınıf, devir notu, kişi kaydı. Taşınmayan iki şey var. Birincisi yanıt pencereleri: her platformun kendi süresi ve kendi istisnaları var. İkincisi otomasyon politikaları: bir kanalda serbest olan bir davranış diğerinde ihlal sayılabiliyor.

Kanal karakterleri de farklı ve bu, aynı marka sesi dosyasının her yerde çalışmadığı anlamına geliyor. LinkedIn'de üç cümlelik resmi bir yanıt yerinde durur, Instagram'da soğuk kaçar. X'te kısalık zorunluluk, WhatsApp'ta beklenti neredeyse anlık yanıt. Marka sesi dosyanızı tek dosya olarak tutup kanala göre yalnızca "uzunluk ve biçim" başlığını değiştirmek, en az bakım isteyen çözüm.

Pratik sonuç şu: seviye 1 her kanalda aynı gün açılabilir, çünkü okuma her yerde güvenli. Seviye 3'ü ise kanal kanal açın ve her kanal için o platformun güncel dokümanını ayrıca okuyun. Kanal bazlı ayrıntılar için WhatsApp tarafına, Telegram tarafına ve X tarafına bakabilirsiniz. Kurulumun ürün tarafındaki karşılığı otomatik yanıt ve otomasyon akışları sayfalarında; plan kapsamları fiyatlandırma sayfasında.

Sık sorulan sorular

Instagram DM'lerine yapay zeka bağlamak platform kurallarına aykırı mı

Hayır, gelen mesaja yanıt üretmek için resmi API üzerinden çalışan bir kurulum politikaya uygundur. Aykırı olan, izinsiz toplu mesaj göndermek, yanıt penceresi dışında promosyon içeriği iletmek ve mesaj etiketlerini tanımlı amaçlarının dışında kullanmaktır.

Kurulumdan önce Meta'nın güncel mesajlaşma politikası dokümanını okuyun. Bu alan sık güncelleniyor ve bir yıl önceki bilgiye dayanarak tasarım yapmak risklidir.

Hangi seviyeden başlamalıyım

Seviye 1'den. Anahtara sadece social:read verin, vekili --read-only ile çalıştırın ve iki hafta boyunca yalnızca sınıflandırma ve önceliklendirme yaptırın. Bu iki hafta size iki şey kazandırır: kutunuzun gerçek dağılımı ve asistanın sınıflandırma isabetinin ölçüsü.

İkinci ölçü olmadan seviye 2'ye geçmek erken olur. Yanlış sınıflandırma seviye 1'de zararsızdır, seviye 3'te yanlış mesaja dönüşür.

Asistan yanlış bir mesaj gönderirse sorumluluk kimde

Sizde. Asistan sizin hesabınızdan, sizin adınıza yazar ve verdiği bilgi sizi bağlar. Bu yüzden fiyat, tarih, iade ve garanti içeren yanıtların hiç üretilmemesi en güvenli tasarımdır. Bu dört başlık, düzeltilemez hataların büyük bölümünü oluşturuyor.

Yanlış mesaj gittiğinde yapılacak şey de önceden yazılı olsun: mesajı silmeye çalışmak yerine hemen ardından düzeltmeyi yazın ve konuşmayı insana devredin. Silinen bir mesaj müşteride "bir şey gizlendi" izlenimi bırakır; açık bir düzeltme bırakmaz.

Müşteriye yapay zeka ile konuştuğunu söylemek zorunda mıyım

Türkiye'de bunu doğrudan emreden özel bir madde bulunmuyor, ancak Kişisel Verileri Koruma Kurumu'nun üretken yapay zeka rehberi, bireylerin bir yapay zeka sistemiyle iletişim kurduklarını bilmesinin önemine işaret ediyor. Avrupa Birliği tarafında ise şeffaflık bir yükümlülük.

Pratik değerlendirme: söylemenin maliyeti yok, gizlemenin riski var. Seviye 2'de zaten mesajı insan onaylıyor; seviye 3'te ilk otonom mesajın içine kısa bir bilgilendirme koymak yeterli.

Aynı mesaj iki kez giderse ne olur

Sorun ağ zaman aşımı yaşandığında çıkar: model çağrının başarısız olduğunu sanıp tekrar dener ve mesaj ikinci kez gider. crm_send_social_message aracında bunu kesen bir idempotencyKey parametresi yoktur. Sizi koruyan şey, aracın yazma olarak işaretli olması sayesinde istemcinin her gönderimden önce onay sorması (yani tekrarın ikinci bir onay ekranı olarak görünmesi) ve platform reddinin sessiz yeniden deneme yerine hata döndürmesidir.

Belirsiz bir gönderim hatasından sonraki alışkanlık üç saniye sürer: yeniden denemeden önce crm_list_social_messages ile konuşmayı okuyun ve metninizi taşıyan bir outbound mesaj olup olmadığına bakın. Gözetimsiz çalışan kodlar için v1 REST gönderim uç noktası idempotency anahtarı kabul eder; orada anahtarı deterministik üretmek gerekir, çünkü her denemede yenilenen bir değer hiçbir şeyi korumaz.

Asistan sadece belirli saatlerde çalışsın diyebilir miyim

Evet, ve seviye 3 için bunu yapmalısınız. Otonom yanıtın çalışacağı saat aralığını kuralın içinde tanımlayın ve aralığı Europe/Istanbul üzerinden hesaplayın. MCP çıktılarındaki zaman damgaları UTC olduğu için dönüşümü atlarsanız saat sapması alırsınız.

Mesai dışında tamamen sessiz kalmak da geçerli bir tercih. Ama o zaman mesai içi ilk yanıt süresi hedefinizi sıkılaştırın: gece sessiz kalıp sabah da iki saat bekletirseniz, müşteri açısından fark yoktur.

Seviye 3'ü satış sorularında kullanmak neden önerilmiyor

Çünkü satış konuşmasında doğru cevap kişiye göre değişir ve içinde rakam geçer. Rakam geçen her yerde taahhüt riski vardır. Seviye 2 zaten hızın büyük bölümünü veriyor: taslak hazır, insanın yaptığı iş okuyup göndermek ve bu saniyeler sürüyor.

Bu kurulum sadece Instagram için mi çalışıyor

Hayır. Aynı araçlar on iki kanalı kapsıyor ve platform argümanı verilmediğinde hepsi tek listede geliyor. Tarif taşınır, pencereler ve politikalar taşınmaz; her kanalı açarken o platformun güncel dokümanını ayrıca okuyun.

Asistan kişi kaydına ne yazmalı, ne yazmamalı

Kararı ve sonucu yazmalı: talep neydi, ne yapıldı, sıradaki adım ne. Konuşmanın kopyasını yazmamalı. Uzun yapıştırmalar hem aramayı bozar hem de gereksiz kişisel veri biriktirir.

Not formatını sabitleyin. Serbest metin notlar ilk hafta düzgün, üçüncü hafta okunamaz hâle gelir.