Telegram Bot Rich Messages Yanıt Akışı Nasıl Planlanır?

Telegram Bot Rich Messages ne zaman kullanılmalı?

Telegram Bot API'nin Rich Messages özelliği, bir bot yanıtını yalnızca düz metin olarak değil, yapılandırılmış bloklar hâlinde sunmayı sağlar. Telegram'ın 11 Haziran 2026 değişiklik kaydı bu desteği Bot API 10.1 altında duyurur. Müşteri destek botunda bir ürün özeti, işlem adımları, uyarı ve sonraki eylem aynı yanıt içinde ayrıştırılacaksa değerlendirilebilir. Ancak biçim zenginliği, cevabın doğruluğunun veya destek sürecinin yerini tutmaz. Önce botun hangi soruyu çözeceğini, hangi durumda insana devredeceğini ve hangi veriyi göstermeye yetkili olduğunu tanımlayın.

Bu yazı bot oluşturma veya token sahibi belirleme rehberi değildir. O temel kurulum için Telegram yönetilen bot yetki akışı yazımıza bakabilirsiniz. Buradaki odak, gelen destek talebinden kalıcı yanıta uzanan mesaj yaşam döngüsü ve bu döngünün hata karşısında tutarlı kalmasıdır.

Yanıtı bloklara ayırmadan önce karar verin

İyi bir destek yanıtında ilk satır kullanıcının durumunu açıklar. Sonra gerekliyse birkaç uygulanabilir adım ve varsa işlem sonucu gösterilir. Rich Messages bu bilgi sırasını görünür kılabilir; fakat tüm alanları aynı anda eklemek yanıtı ağırlaştırır. Kullanıcının bir cümlelik cevaba ihtiyacı varsa düz metin yeterlidir. Sipariş durumu, randevu değişikliği veya teknik hata özeti gibi bağlamlarda ise özet, ayrıntı ve sonraki eylem blokları yararlı olabilir. Hangi tür talebin hangi şablonu kullanacağını örnek konuşmalar üzerinden belirleyin.

Şablonda değişken veri ile sabit açıklamayı ayırın. Destek sisteminden gelen sipariş durumu bir veri alanıdır; "ödeme kesinleşti" gibi hukuki veya mali anlam taşıyan ifadeler otomatik varsayım olmamalıdır. Yanıttaki her alan için kaynak sistem, son güncelleme zamanı ve yetki koşulu belirleyin. Kullanıcıya özel verinin başka sohbet veya iş bağlantısı kapsamına taşınmaması, görsel biçimden önce gelen bir gerekliliktir. Deneme ortamında sahte kişisel veri kullanın; kayıt ve hata raporlarında gerçek müşteri bilgilerini gereksiz yere tutmayın.

Geçici taslak ile kalıcı mesaj farklı işlerdir

Güncel Bot API belgesi sendRichMessage yöntemini kalıcı zengin mesaj göndermek, sendRichMessageDraft yöntemini ise yanıt üretilirken geçici önizleme akıtmak için açıklar. Belge, taslağın geçici olduğunu ve tamamlanan cevabın sohbette kalması için ayrıca sendRichMessage çağrılması gerektiğini belirtir. Bu nedenle "taslağı gösterdim, iş bitti" yaklaşımı yanlış bir başarı ölçütüdür. Kullanıcı geçici metni görmüş olabilir ama daha sonra kalıcı konuşma geçmişinde bulamayabilir.

Akışı durum makinesi gibi tasarlayın: talep alındı, içerik doğrulanıyor, gerekliyse taslak gösteriliyor, nihai yanıt hazırlandı, kalıcı mesaj gönderildi, gönderim sonucu kaydedildi. Her durumun zaman aşımı ve hata dönüşü olsun. Taslak başarısızsa kalıcı mesajı göndermeyi denemek hâlâ mümkün olabilir; nihai gönderim başarısızsa "yanıtlandı" işaretini koymayın. Özellikle yapay zekâ destekli üretimde taslakta görünen kesin olmayan ifadeyi son mesajdan önce doğrulamak gerekir. Hızlı akan metin, yanlış bilgiyi daha erken gösterebilir.

Medya ve sohbet yetkisini nasıl kontrol etmeli?

Telegram belgesine göre zengin mesajda medya bloğu bulunursa botun ilgili sohbete medya gönderme hakkı gerekir. Bu yüzden zengin mesajın her tür sohbette aynı şekilde çalışacağını varsaymayın. Özel sohbet, grup, iş hesabı bağlantısı ve yönetici kısıtları için yetki matrisi çıkarın. Medya yetkisi yoksa kritik yanıtın tamamını kaybetmek yerine, aynı soruyu metinle açıklayan bir yedek biçim tasarlayın. Yedek mesaj, başarısız denemeyi saklamamalı; kullanıcıya eksik bir kanıt veya görsel gönderilemediği anlaşılır biçimde söylenmelidir.

Medya bir gereklilik değilse hiç eklememek de geçerli bir tasarım kararıdır. Bir iade sürecinde işlem numarası ve durum metni yeterliyse zengin bir kart için görsel üretmeye gerek yoktur. Yapılandırılmış tablo veya bölüm başlıkları da gereksiz bilgi yoğunluğu yaratabilir. Her blok için "kullanıcı bu bilgiyle ne yapacak?" sorusunu sorun. Yanıtı olmayan blokları çıkarın.

İnsan desteğine devir sınırı

Botun cevap vermemesi gereken durumları baştan yazın: kaynak sistemden doğrulanamayan ödeme bilgisi, hesap sahipliği ihtilafı, yanlış kişiye ait kayıt, ısrarlı hata veya kullanıcının açıkça temsilci istemesi. Devir sırasında temsilciye kısa, doğrulanmış bir olay özeti verin; üretilmiş taslak metni gerçek işlem kaydıymış gibi aktarmayın. Kullanıcının tekrar aynı hikâyeyi anlatmaması faydalıdır, fakat gereksiz kişisel veriyi taşımak değildir. Onay, yetki ve saklama süresi ürünün gerçek veri akışına göre ayrıca değerlendirilmelidir.

Temsilci devir alırken botun yeni otomatik cevap üretmesini durduracak bir sahiplik durumu tanımlayın. Aynı talebe hem insan hem bot yanıt verirse zengin biçim kafa karışıklığını azaltmaz; tersine iki çelişkili açıklamayı daha görünür kılar. Devir tamamlandıktan sonra botun ne zaman tekrar devreye gireceği de açık olmalıdır.

Kabul testlerinde hangi hatalar olmalı?

En az dört tür test yapın. Birincisi, doğru veri geldiğinde kısa ve uzun yanıtların okunabilirliği. İkincisi, medya gönderme hakkı yokken metin yedeğinin çalışması. Üçüncüsü, taslak gösterilip kalıcı gönderimin başarısız olması; bu durumda işlem tamamlandı görünmemeli. Dördüncüsü, ağ tekrarları nedeniyle aynı nihai mesajın iki kez gönderilmesi. Bunlara boş sonuç, geç yanıt ve insan desteği isteğini ekleyin. Test kaydında kullanıcıya görünen metni, API yanıtını ve iç durum geçişini birlikte tutun.

Başarı yalnızca API'nin olumlu dönmesi değildir. Kullanıcı doğru sohbet içinde doğru kaynağa dayanan, daha sonra yeniden bulunabilir bir yanıt almalıdır. Yanıtın tonu da destek işine uygun olmalıdır: belirsizliği kesinlik gibi sunmamak, tamamlanmayan işlemi tamamlandı dememek ve alternatif iletişim yolunu açık bırakmak. Bu ilkeler düz metinde de geçerlidir; Rich Messages yalnızca sunum aracıdır.

Webinle ile uygulama kapsamı

Webinle'nin bot yazılımları ve entegrasyonlar hizmetinde böyle bir akış değerlendirilirken önce örnek talepler, veri kaynakları, yanıt yetkisi ve temsilci devri birlikte tarif edilmelidir. Mevcut Telegram botunuz varsa hangi mesajların gerçekten yapılandırılmış sunuma ihtiyaç duyduğunu ayırabiliriz. Yeni botta ise komut, kimlik ve veri entegrasyonu tamamlanmadan yalnızca Rich Messages görünümünü teslim edilmiş çözüm saymayız. Proje kapsamınızı iletin; hedeflenen konuşma türlerini ve hata senaryolarını beraber netleştirelim.