İçeriğe atla
megapromotingHadi konuşalım

Uzmanlık · Entegrasyonlar ve otomasyonlar

Sistemleriniz birbirleriyle konuşsun, kimse aynı verileri yeniden yazmak zorunda kalmadan.

Rezervasyon sistemini, mağazayı, CRM’i, hesap tablolarını ve mesaj kanallarını birbirine bağlıyoruz; böylece bir agent veya zamanlanmış bir kural bunları gerçek zamanlı olarak okuyup yazabilsin. Anahtarlar sunucuda kalır, araçların yazılı sınırları vardır ve her entegrasyon, diğer sistemin çökmesi durumunda da test edilir.

Zaten kurduklarımızYerel olarak yazılmış ve çalıştırılmış, bugün kodda ölçülen entegrasyonlar: Altegio randevu sistemi konektörü (946 satır, ajana açık altı araçla), amoCRM CRM konektörü (mesajlaşma platformunda 2.888 satır, ayrıca sesli platformda 12 sunucu fonksiyonu), Bitrix24 (903 satır, ayrıca 4 fonksiyon), Google Sheets (615 satır, ayrıca 10 fonksiyon ve özel bir hizmet hesabı), mağaza üzerindeki canlı katalog (platform hizmeti, 318 satır), Telegram’da lead bildirimleri (1.776 satır), anti-kötüye kullanım sınırlarıyla Infobip üzerinden SMS, zamanlanmış otomasyonlar (1.088 satır) ve yerel bir ilan platformunun sohbet kanalı (2.459 satır). Çalışma sırasında ajan, webhook üzerinden araçlar ve izolasyonda çalıştırılan kendi kodlu araçlar dışında 15 tür dahili aracı çağırabilir.

Bir entegrasyon bir sayfadaki logo değildir. Çok somut bir sorunun yanıtıdır: bu sistem gerçek zamanlı olarak okunup yazılabilir mi, kim tarafından, hangi yetkilerle ve yanıt vermediğinde ne olur? Bu yüzden herhangi bir entegrasyonda ilk sorumuz “hangi API ile” değil, “hangi açık kapısı var”dır. Bazen cevap işin maliyetini tamamen değiştirir: örneğin WooCommerce üzerindeki mağazalar herkese açık, hiçbir tüketici anahtarı istemeyen bir mağaza API'si sunar, bu yüzden yeni bir müşteri yalnızca kendi site adresiyle bağlanır — oluşturması, göndermesi ve ardından döndürmesi gereken kimlik bilgileriyle değil.

Mesajlaşma platformumuzda, ajan konuşma sırasında çağırabileceği bir araç üç türden biridir: bir webhook'a çağrı, izole çalıştırılan kendi kodu veya platformun dahili bir aracı. Dahili araçları tercih ediyoruz, çünkü anahtarları veritabanının dışında tutarlar: bugün on beş tane, bir sayfa okumaktan ve bir elektronik tabloya yazmaktan, bir randevunun uygunluğu ve oluşturulmasına, SMS gönderimine ve ürün kataloğunun sorgulanmasına kadar.

Dayanan bir entegrasyon ile dağılan bir entegrasyon arasındaki fark neredeyse her zaman sahadaki küçük şeylerde yatar. Rezervasyon sistemi, bir hizmet vermeyen bir uzman için saatleri sorarsanız hiçbir şey döndürmez — hizmet ve uzman her zaman birlikte seyahat eder. Aynı sistem, istek HTTP kütüphanesinin varsayılan başlığıyla gelirse reddeder, bu yüzden her istek kendisini açıkça tanıtmalıdır. Bir mağaza, varyantlı ürünler için sıfır fiyat bildirebilir ve boş kelimelerle yapılan bir arama tüm kataloğu döndürür. Entegrasyon başına böyle on ayrıntı vardır ve hiçbiri belgelerde yoktur.

İntegrasyonların üstünde otomasyonlar durur: birinin isteğiyle değil, zaman içinde çalışan kurallar. Bizde bunlar süreç içi bir planlayıcıyla programlanır — yanıtsız kalan konuşmaların yeniden başlatılması, yeni bir kişiye ilk mesaj, çalışma saatlerinden sonra ajanı duraklatma ve yeniden başlatma — her birinin kendi sayaçları vardır; böylece kaç kez çalıştığı, kaç mesajın gönderildiği, kaçının atlandığı ve neden olduğu görülür. Sayacı olmayan bir otomasyon, çalışıp çalışmadığını söyleyemeyeceğiniz bir otomasyondur.

Şeffaf otomasyon — doğrulanabilir entegrasyonlar · Rumence video, Türkçe altyazı ve deşifre metniyle

Tam döküm

Doğrudan konuya girelim. Bugün, yapay zekâ tabanlı asistanlar aracılığıyla otomasyonun teknik ve, dürüst olmak gerekirse, çoğu zaman göz ardı edilen gerçeklerini inceleyeceğiz. Mega Promoting tarafından geliştirilen iCat.md platformuna süper pragmatik bir yaklaşıma odaklanacağız. Bugün pazarlama vaatleri yok ve kesinlikle belirsiz kavramlar da yok. Doğrudan üretimde olan, işlevleri veritabanı mimarisinden doğrudan açıklanan bir platformdan bahsediyoruz. O yüzden gelin, tam şeffaf otomasyonun aslında nasıl göründüğüne bakalım. Bu analizin gündemi basit ve net. Zaman sorunundan, teknolojinin mekaniğinden, gerçek bir vakadan, sistemin açık sınırlarından, veri yönetiminden ve sonraki adımlardan geçiyoruz. İlk bölümle başlayalım, zaman sorunu. Hepiniz o son derece sinir bozucu soruyu biliyorsunuz, değil mi? Neden koca bir destek ekibi, gün be gün, aynı beş soruya birebir aynı cevapları elle yazarak saatler harcıyor? Bilgi zaten şirketin web sitesinde var, ama buna rağmen müşteriler ayrıntıları tekrar tekrar istemeye devam ediyor.

Ve işte sorunumuzun özü tam da bu. Uygun bir teknik çözüm olmadan bu tekrar eden tüm talepler doğrudan mesaj kutusunu tıkar; bunun Instagram ya da Messenger olması fark etmez. Sonuç olarak, gerçekten karmaşık bir sorunu olan müşteriler için cevaplar ciddi biçimde gecikir, talepler mesaj denizinde kaybolur ve tüm destek süreci pratikte ne kontrol edebileceğiniz ne de ölçebileceğiniz bir kara kutuya dönüşür. İkinci kısım. Teknoloji kaputun altında aslında nasıl çalışıyor? Bakın mesele şu. Platformun kurulumu dört çok mantıklı adıma dayanıyor. Önce kendi kodumuzu kullanarak iletişim kanallarını bağlıyoruz. Ardından tüm bilgi tabanı indeksleniyor. Sonra mevcut sistemlerinizde işlem yapabilen araçların bağlanması geliyor. Ve sonunda, bu ayrıntı hayati önem taşıyor, botun görüşmeyi bir insan operatöre devrettiği, doğrudan veritabanında kaydedilmiş net bir yol yapılandırılıyor. Her şey görünür ve tamamen yapılandırılabilir bir sistemdir.

Şimdi, kesinlikle büyüleyici bir ayrıntı. Burada plândan konuşmuyoruz. Bunlar doğrudan veritabanı şemasından çıkarılmış ayarlar. Asistanın bir cevaba ihtiyacı olduğunda, sözde hibrit arama kullanıyor. Varsayılan olarak algoritma 5 metin parçası çıkarır, 0-70 arasında sıkı bir benzerlik eşiği uygular ve kelimelerin tam eşleşmesine %30 önem verir. Her şey Text Embedding 3 Small modeliyle işlenir. Pratikte sistem, tam bağlamı yakalamak için kelimeleri matematiksel kavramlara dönüştürür. Cevaplar bir bilmece değil, saf matematiktir. Bu sayıyı aklınızda tutun. 15. Bu, sistemdeki mutlak bir teknik sınırdır. Herhangi bir aracı ya da aramayı çalıştırmak için ayrılan maksimum süreyi, saniye cinsinden, temsil eder. Bir dış entegrasyon bundan daha uzun sürerse, diyelim ki 40 saniye gerekiyorsa, onu görüşmenin canlı akışında bırakamayız. Asenkron işlenmesi gerekir, yoksa sohbetin doğal ritmi tamamen bozulur.

Bir şey daha var. İnsanlar chatte kısa kısa yazar, değil mi? 2, 3, 4 kısa mesaj arka arkaya gönderirler. Sistemin çıldırmaması için 15 saniyelik bir birleştirme tamponu var. Bu pencereye giren her şey yapışır ve tek, net bir talebe dönüşür. Ayrıca Meta gibi platformlarda, bazen yanlışlıkla gönderilen kopya mesajlara denk geldiğinizde, sistem mesaj kimliği üzerinde 120 saniyelik bir bellek filtresi uygular. Böylece müşteri 3 yanlış alarm değil, tek ve tutarlı bir cevap alır. Üçüncü bölüm. Gerçek bir vakaya bakalım. Elimizde bu klasik e-ticaret senaryosu var. Kusursuz bir web kataloğu olan bir çevrim içi mağaza var, ama Instagram ve Messenger’da özel mesaj yağmuru alıyor? Stokta var mı? Fiyatı ne? Buradaki entegrasyon zarif bir şekilde yapıldı, asistan doğrudan WooCommerce’in Store API halka açık arayüzüne bağlandı.

Güvenlik karmaşası olmadan, mağazanın canlı kataloğu basitçe asistanın ellerine verildi. Burada, Meta gibi aynı şirket şemsiyesi altındaki her platformun teknik gerçeği devreye giriyor. Messenger’da asistan size harika ürün karuselleri gösterebilir. Instagram’da ise bot size yalnızca metin ve en fazla basit bir görsel ile cevap verir. Neden? Basitçe çünkü Meta, Instagram’da bu genel şablonları desteklemiyor. Asistan, bulunduğu kanalın kurallarına birebir uymak zorunda. Kritik nokta burada. Bot durumun üstesinden gelemediğinde ne olur? İşte veritabanında konuşmanın açık durumları vardır. Bir soru katalogun konfor alanının dışına çıktığında, konuşma akışı anında bot durumundan insan durumuna geçer. Ve en güzel tarafı da sistemin insan operatörün ne kadar sürede cevap verdiğini sayması, her şeyi net biçimde işaretlemesi, OK durumu, uyarı ya da süre aşımı. Tüm bağlam insana aktarılır, yolda kesinlikle hiçbir şey kaybolmaz.

A4 bölümü Sistem sınırlamaları Şeffaflık, ne yapamayacağını bilmek demektir. Kabul etmemiz gereken birkaç kesin sınır var. Müşterinin mesajından 24 saatten fazla geçtiyse WhatsApp’ta proaktif mesaj gönderemezsiniz. Meta doğrudan bir hata verir, daha doğrusu 131047 hatası verir ve işlem başarısız olur. Sistem PDF dosyası işlemez, ekleri okumaz. Yabancı diller kısmında çeviriler yalnızca tek yönde çalışır. Müşteri çevrilmiş cevabı alır, ama operatör orijinali görür. Ve 999.md ile entegrasyon çalışsa da, resmî değildir ve tarayıcı çerezlerine dayanır. Platform mekanizmalarını değiştirirse bağlantı kopar ve onarım gerekir. Ve bunu mutlaka aklınızda tutun. Asistan verilerinizin aynasıdır. Sitedeki yanlış bir fiyat, konuşmada da kesin olarak yanlış bir fiyat olur. O bir okuyucu gibi davranır, mağaza yöneticisi gibi değil. Kataloglardaki insan kaynaklı hataları kendi kendine düzeltmez. Buradaki teknik altyapı hiç de oyuncak değil.

Her şey bir Microsoft Azure özel sunucusunda tutuluyor. Kanalları ayırmak ve denetim için açıkça modellenmiş 80’den fazla tabloya sahip, son derece yapılandırılmış bir MySQL veritabanından bahsediyoruz. Son derece hassas olan WhatsApp erişim anahtarları fernet şifrelemesi kullanır. Bunun yanında, web düzeyinde, sohbet widget’ı için alan adları manuel olarak beyaz listeye eklenir. Açık izin olmadan kimse bağlanmaz. Ancak apaçık bir gerçeği ele almamız gerekiyor. İnsanlar o sohbet pencerelerine her türlü kişisel veriyi, telefon numaralarını, adresleri yazacak. Teknik olarak, serbest metin alanını engellemenin bir yolu yok. Bu yüzden çözüm idaridir. Böyle bir sistemi uyguladığınızda, 1. saniyeden itibaren, o verileri kimin görmeye yetkili olduğunu ve ne kadar süreyle saklandığını tam olarak belirleyen net saklama politikalarına ihtiyacınız var. Ve 6. noktaya geldik. Sonraki adımlar. Tüm sistemin merkezindeki felsefe şu alıntıyla özetlenebilir.

Son kullanıcı bir asistan şiirler yazan ya da güzel yazan biri değildir; gerçek bilgilerle bağlantılı olan ve çok önemli olarak, tam olarak nerede durması gerektiğini bilen kişidir. İş dünyasında etkili otomasyon, verilerin doğru şekilde alınması ve zamanı geldiğinde kontrolü bir insan operatöre güvenle devretmek demektir. Dolayısıyla sonraki adım bir yazılım satın almak değil, mevcut süreçlerinizi dikkatle analiz etmektir. Hangi iş akışlarının gerçekten kurulup otomatikleştirilmeye değer olduğunu, bunların güvenli şekilde nasıl bağlanabileceğini değerlendirin ve en önemlisi, sonuçları pazarlama illüzyonlarıyla değil, gerçek verilerle nasıl ölçeceğinizi belirleyin. Ve sizi şu düşünceyle bırakıyorum. Bir işletmedeki tüm iletişim süreçleri arasında hangileri gerçekten bir insanın empatisini ve taktik duygusunu gerektirir ve hangileri aslında yalnızca doğru veritabanına tam olarak bağlanmayı bekleyen tekrarlayan görevlerdir? Her otomasyon planı bu sorudan yola çıkmalıdır. Bu analizde bizimle birlikte olduğunuz için teşekkürler!

Neleri kapsıyor

Çalışma, bileşenlerine ayrılmış hâliyle

Önce sistemin hangi herkese açık kapısı olduğunu kontrol ederiz

WooCommerce üzerindeki mağazalar için, consumer key gerektirmeyen public store API’sini kullanırız: istemci yalnızca site adresiyle bağlanır. Bu, sadece estetik değil, gerçek sonuçları olan bir seçimdir — mağaza anahtarlarını veritabanında açık halde tutan el yazımı araçların yerini bununla aldık. Sistem public gate’e sahip değilse, kimlik doğrulamaya geçeriz; ancak o zaman anahtar, veritabanı satırında unutulan bir şey değil, yönetilen bir parça olur.

Anahtarlar sunucuda kalır, araçta ve sayfada değil

SMS aracı platformun içindedir; çünkü kendi araç kodunun çalıştığı ortamın ortam değişkenlerine erişimi yoktur — gönderim araç kodundan yapılırsa anahtarın veritabanına yazılması gerekir ve o anahtar herkesin masrafına mesaj gönderebilir. Programlama sisteminde de aynı: ortak jeton tektir, sunucu ortamında tutulur, müşteri ise yalnızca kendi şirket tanımlayıcısını koyar.

Ajan, aracı konuşma sırasında parametre ve süre ile çağırır

Her aracın model için yazılmış bir açıklaması, zorunlu olanı ve olmayanı belirten tiplenmiş parametreleri ve kendi yürütme süresi vardır — hizmet listesi için 15 saniyeden uygunluk araması için 30 saniyeye kadar. Araç başına süre bir ayrıntı değildir: onsuz, yavaş bir entegrasyon konuşmayı kilitler ve karşı taraftaki kişi sessizlik duyar.

Salon veya klinik sisteminde gerçek programlamalar

Altegio üzerinde altı araç: gerçek fiyatlarla hizmet listesi, uzmanlar, tam uygunluk, programlama oluşturma, iptal ve değiştirme. Uygunluk yalnızca „boş/dolu” döndürmez: talep edilen hizmeti hangi uzmanların verdiğini ve her biri için en erken boş saatleri, en erkenden başlayacak şekilde sıralı olarak döndürür; tam da bu yüzden ajan „uygun değil” demek yerine somut bir alternatif önerebilir.

Mağaza kataloğu, canlı okunan

Fiyat ve stok durumu, sorunun sorulduğu anda mağazadan okunur; güncelliğini yitirmiş bir kopyadan değil. Katalog sayfalandırılmış olarak yüklenir, her biri 100 üründen oluşan en fazla 30 sayfaya kadar, sitede on dakika geçici bellekte tutulur ve tüm tüketiciler tarafından değişiklik yapılmadan okunacak tek bir biçime normalize edilir — mesajlaşmadaki ürün karuseli de dahil, çünkü sayısal fiyata ihtiyaç duyar, sayfadaki widget da dahil, çünkü başlığa ihtiyaç duyar.

CRM’ler, hesap tabloları ve mesaj kanalları

amoCRM ve Bitrix24, tam OAuth, jeton yenileme ve durum kontrolü ile. Google Sheets, geri kalan kimlik bilgilerinden ayrı, özel bir hizmet hesabı üzerinden; yazma işlemi ajan tarafından tetiklenir. Bildirimler için Telegram. Infobip üzerinden SMS. Artı, kendi yenileme jetonu olan yerel bir ilan platformunun chat kanalı — uluslararası hiçbir katalogda olmayan ve yerel olarak çok önemli olan türden bir entegrasyon.

Zaman içinde çalışan, sayaçlı otomasyonlar

Yanıtsız kalan konuşmaların yeniden başlatılması, yeni bir kişiye ilk mesaj, çalışma saatlerinden sonra ajanın duraklatılması ve yeniden başlatılması. Her çalıştırma görünür sayaçları artırır: kaç çalıştırma, kaç mesaj gönderildi, ajan kapalı olduğu için kaç tanesi atlandı, yapılandırması olmadığı için kaç tanesi atlandı, kaç hata. Bunlar olmadan, bir otomasyonun öldüğünü anlamanın tek yolu bir müşterinin şikayetidir.

Karşı kötüye kullanım sınırları, çünkü kararı bir model verir

Bir dil modeli tarafından çağrılan bir aracın, modelin aşamayacağı sınırlarına ihtiyacı vardır. SMS’te: „firmaya” modunda alıcı yapılandırmadan gelir, asla modelden gelmez; „müşteriye” modunda numara normalize edilir ve doğrulanır. Bunun üstünde, ajan başına günlük üst sınır, aynı numaraya bir dakikalık ara ve mesaj uzunluğu limiti. Bunlar prompt içinde talimat değil, kodda yazılı çitlerdir — bir prompt aşılabilir, bir çit aşılamaz.

Çıkış filtreleri, dışarı çıkmasına izin verilmeyen veriler için

Bir entegrasyon, müşterinin bilmesi gerekenden fazlasını döndürdüğünde, çıktıda filtreleriz; ajanın kendini tutmasını ummayız. Gerçek bir örnek: ulaşım alanındaki bir müşteri için politika, ajanın şoförün telefon numarasını söylemesini yasaklıyordu, ancak API o numaraları yanıtta döndürüyordu. Aracın sonucunu yinelemeli olarak dolaşıp şoförün iletişim alanlarını kaldıran, dispeçer numaralarını ise koruyan bir filtre yazdık. Filtre, başka bir şeyi yanlışlıkla gizlememek için genel değil, tam gerektiği yerde uygulanır.

Nasıl görünüyor

Süreç, adım adım.

01

Envanter: hangi sistemler, hangi kapılar, hangi yetkiler

Hangi sistemler devrede, her biri neyi açığa çıkarıyor, kim kimlik bilgisi oluşturma hakkına sahip ve kim onları döndürüyor. Her biri için temel soru şudur: kimlik doğrulama olmadan okunabilir mi? Evetse, entegrasyon çok daha ucuz olur ve ikinci müşteride çok daha kolay tekrar edilir.

02

Bağlayıcı: bildirilmiş araçlar, sunucuda anahtarlar, süreler

Her eylem; bir ad, modele yazılmış açıklama, tiplenmiş parametreler ve kendi süresi olan bir araç haline gelir. Anahtarlar sunucu ortamında kalır. Sonunda ajan, bir şeyi belirsiz biçimde “yapmayı bilir” durumda olmaz: sınırları olan, sonlu bir eylem kümesine sahiptir.

03

Sadece çalışan vakada değil, başarısız olan vakada da test

Bir bağlayıcı, doğru istekte, eksik istekte, yavaş cevap veren sistemde ve hiç cevap vermeyen sistemde test edilir. Entegrasyon çöktüğünde ajanın ne söyleyeceği bir tasarım kararıdır, müşterinin keşfedeceği bir hata değil: makul bir doğaçlama yerine dürüst bir mesajı ve insan devralmasını tercih ederiz.

04

Diğer sistemin kararsızlığına dayanıklılık

Arttırılan beklemeli yeniden deneme, ancak yeniden denenmesi anlamlı olan hatalarda — bir hız sınırı veya sunucu hatası; yanlış bir istek değil, çünkü o ikinci kez de yanlış olacaktır. Sorun karşı tarafın ağ katmanındaysa yaklaşım farklıdır; aşağıdaki örnek tam da böyle bir durumdur.

05

Devir teslim: tedarikçi değişince ne değişir

Karşı sistem API’sini değiştirirse ne bozulur, hangi kimlik bilgileri ne zaman sona erer, hangileri manuel olarak yenilenmelidir diye not ederiz. Bu liste olmadan yapılan entegrasyon gizli bir borçtur: bir gün artık çalışmayana kadar kusursuz çalışır ve nedenini kimse bilmez.

Bir merkez. Etrafında, ona girenler — ayrı yollarla.MERKEZ, ÇEVRESİNDEKİLERE DAYANIR
Konuşma çevresindeki harici sistemler: randevular, mağaza kataloğu, CRM, hesap tabloları, SMS ve mesaj kanalları — her biri istek üzerine okunur, anahtarlar sunucuda kalır.

Veriler

Neye dokunuyoruz, nerede duruyorlar ve ne kadar kalıyorlar

Veri koruma sorumlusu olan herkesin soracağı sorular — o sormadan önce burada sorulmuş hâliyle.

Kimlik bilgilerinin nerede durduğu
Platformun sağlayıcı anahtarları sunucu ortamında durur, veritabanında değil ve asla istemci sayfasında değil. Bir müşterinin kendi kimlik bilgileri — entegrasyon bunları gerektirdiğinde — şifrelenmiş olarak saklanır. Fark önemlidir: ele geçirilmiş bir platform anahtarı herkesi etkiler, bir müşteri kimlik bilgisi tek bir hesabı etkiler; riski farklı olduğu için bunları farklı ele alırız.
Dış sistemlerden ne saklanır, ne saklanmaz
Ürün kataloğu kopyalanmaz: isteğe bağlı okunur ve on dakikalık geçici bellekte tutulur, böylece aynı mağaza hakkında art arda on soru on tam tarama anlamına gelmez. Randevular bizde çoğaltılmaz — doğruluk kaynağı salonun sistemi olarak kalır. Sakladığımız şey konuşmanın izi ve eylemin sonucudur, karşı sistemin veritabanının bir kopyası değil.
Dil modeline ne ulaşır
Bir aracın sonucu konuşmaya girer, dolayısıyla modelin bağlamına da girer. Bu yüzden filtreleme, modele verilmeden önce sonucun üzerinde yapılır; talimatlarda değil. Müşterinin duymaya hakkı olmayan alanlar kaynağında çıkarılır; çıkarılan şey, ajan nasıl sorulursa sorulsun dikte edilemez.
Kim bir entegrasyonu bağlayabilir
Bir entegrasyonu bağlamak, hesap doğrulaması yapılmış bir işlemdir; iş hesabına bağlıdır ve ortaya çıkan araçlar tümüne değil, belirli bir ajente eklenir. Bir ajanın tam olarak kendi rolü için ihtiyaç duyduğu araçları vardır. Aynı mantık, bir çalışanın erişimi için de geçerlidir: daha kolay diye ona tüm anahtarlar verilmez.
Düzeltilmesi gerekenler, açıkça söylenmiş
Platformumuzdaki tüm entegrasyon modülleri aynı seviyede değildir. Burada listelenenler yazılmış ve çalıştırılmıştır. Başlatılmış, birkaç düzine satırlık ve henüz hiçbir yararlı şey yapmayan modüller de vardır — bunları kullanılabilir olarak sunmuyor ve hiçbir teklife koymuyoruz. Bizde o aşamada olan bir sisteme ihtiyacınız varsa, onu hazır bir seçenek olarak değil, önce uyumluluk kontrolü yapılan, inşa edilecek bir çalışma olarak ele alırız.

Bir vaka

Entegrasyon aralıklı olarak düşüyordu ve sorun bizde değildi

Durum

Bir CRM bağlayıcısı bazen çalışıyor, bazen çalışmıyordu; ilk bakışta bir düzen yoktu. İstekler, sunucu ortamının yürütme sınırını aşana kadar takılı kalıyordu; bu yüzden günlüklerde bir zaman aşımı görünüyordu — bu da yanlışlıkla sizi kendi kodunuzda yavaşlık aramaya yönelten işaretti.

Ne kurduk

Neden ağdaydı, diğer uçta. CRM hesabının alan adı birkaç IP adresine çözümleniyor ve küme düğümlerinin bir kısmı sağlıksızdı. Normal bir HTTP isteği bir adres seçer ve o yanıt vermezse, DNS’in döndürdüğü diğer adresleri denemez — bir sonraki yanıta otomatik geçiş yoktur. Düzeltme, o alan adı için varsayılan HTTP istemcisini kullanmayı bırakmaktı: adı biz çözüyoruz, her bir adrese paralel olarak doğrudan şifreli bağlantılar açıyoruz, her biri için kısa bir süre sınırı koyuyoruz ve yanıt veren ilkini kullanıyoruz; eğer bir turda hepsi soğuksa, süreç yeniden başlıyor.

Ne çıktı

Aralıklı kesintiler bir piyango olmaktan çıktı. Müşteri için daha önemlisi: teşhis tek cümlede söylenebilir hale geldi — „sağlayıcının düğümleri aralıklı olarak kullanılamıyor ve biz onları by-pass ediyoruz” — yerine „bazen çalışmıyor”.

Vakanın söylemedikleri

Bu, başkasının sorununu telafi eden bir düzeltmedir ve bu açıkça söylenmelidir. Sağlayıcının altyapısındaki bir hata için kendi kodumuza ek karmaşıklık getirir; onlar kümelerini düzelttiklerinde, karmaşıklık bizde kalır. Bunu, artık gerekmediğinde kaldırılabilsin diye, bu şekilde belgeliyoruz.

Sorular

İnsanların aramadan önce bize sordukları

Hangi sistemleri teorik olarak değil, gerçekten bağladınız?

Altegio rezervasyon sistemi, ajan tarafından çağrılan altı eylemle. amoCRM ve Bitrix24, tam OAuth ve token yenileme ile. Google Sheets, özel bir hizmet hesabıyla. WooCommerce mağazaları, kamuya açık mağaza API’si üzerinden. Bildirimler için Telegram. SMS için Infobip. Yerel bir ilan platformunun sohbet kanalı. Ayrıca konuşmalar için Meta ve Telegram mesajlaşma kanalları. Diğer tüm sistemler için — tamamına erdirmediğimiz mağaza platformları da dahil — dürüst cevap şudur: talep üzerine, bir çalışma olarak ele alınan uyumluluk kontrolünden sonra; bir ayar olarak değil.

Mağazamın API anahtarları üretmesi mi gerekiyor?

WooCommerce için hayır. Tüketici anahtarı gerektirmeyen kamuya açık mağaza API’sini kullanıyoruz — site adresiyle bağlanıyorsunuz. Bu sadece daha kolay değil, daha güvenli de: bu yaklaşımla, mağaza anahtarlarını veritabanında açık biçimde tutan daha eski araçların yerini aldık. Diğer platformlar için, ne sunduklarına bağlı; söz vermeden önce kontrol ediyoruz.

Ajan, sadece yapıyormuş gibi söylemek yerine gerçek bir programlama yapabilir mi?

Evet, rezervasyon sistemi buna izin veriyorsa. Programlamayı oluşturur, iptal edebilir ve değiştirebilir; ayrıca önce uygunluğu kontrol eder. Sadece sahada öğrenilen bir ayrıntı: o sistemde hizmet ve uzman birlikte hareket eder — eğer bir uzmanın yapmadığı bir hizmet için boş saatleri isterseniz, hata değil, sıfır sonuç alırsınız. Bu yüzden uygunluk aracı, hizmeti yapan tüm uzmanları ve her biri için ilk boş saatleri döndürür; böylece ajan somut bir alternatif önerebilir.

Anahtarlarım nereye gidiyor?

Platform anahtarları sunucu ortamında kalır, asla veritabanına ve asla sayfanıza gitmez. Size ait olan kimlik bilgileri şifreli olarak saklanır. Uyguladığımız kural şu: bir anahtar para harcayabiliyorsa ya da tüm müşteriler için veri okuyabiliyorsa, bir dil modeli talebi üzerine çalışan kodun ulaştığı hiçbir yerde bulunmamalıdır.

Ajan istediği herkese SMS gönderebilir mi?

Hayır, ve bu kasıtlı bir kısıtlamadır. Firmaya bildirim modunda alıcı yapılandırmadan gelir — model onu seçemez. Müşteriye gönderim modunda numara normalleştirilir ve doğrulanır. Bunun üstünde, ajan başına günlük bir üst sınır, aynı numaraya bir dakikalık bir ara ve mesaj uzunluğu sınırı vardır. Bunlar kodda kapılardır, promptta talimatlar değil; bir prompt konuşmayla aşılabilir, bir kapı aşılmaz.

Karşı tarafın sistemi çöktüğünde veya yavaş yanıt verdiğinde ne olur?

Her araçta kendi yürütme süresi vardır, böylece yavaş bir sistem konuşmayı kilitlemez. Artan beklemelerle yeniden deneriz, ama yalnızca yeniden denenmeyi hak eden hatalarda — bir hız limiti ya da bir sunucu hatası, yanlış bir istek değil. Ve ajanın başarısızlık durumundaki davranışı senaryoda yazılır: şu anda doğrulayamadığını söyler ve uydurulabilir bir yanıt vermek yerine konuşmayı devreder.

Sağlayıcı API’sini değiştirirse ne olur?

Bir şey bozulur, ve bu yüzden sayfa okumak yerine resmi kapıları tercih ederiz. Bir sitenin HTML’inden bilgi çıkaran araçlar, tema değişikliğiyle bile kırılır — onları bilerek resmi API’nin üzerinde tek bir uygulamayla değiştirdik, tam da onlarca kırılgan varyantı sürdürmemek için. Alternatif olmadığında, bunun kırılgan bir çözüm olduğunu söyler ve onu öyle ele alırız.

Aracı olmadan, yalnızca planlanmış kurallarla otomasyon yapabilir misiniz?

Evet. Cevapsız kalan konuşmaların yeniden ele alınması, yeni bir kontakla ilk mesaj, çalışma saatlerinden sonra ajanın durdurulması ve yeniden başlatılması — bunlar kendi başına çalışan planlanmış görevlardır. Her birinin kendi çalışma, gönderilen mesaj, atlanan mesaj ve hata sayaçları vardır; böylece “çalıştı mı?” sorusuna bir varsayımla değil, bir sayı ile yanıt verilebilir.

Bir entegrasyondan, ajanın söylememesi gerekeni söylemediğinden nasıl emin oluyorsunuz?

Sonucu modele ulaşmadan önce filtreleriz, sonrasında değil. Çözdüğümüz somut vaka: bir müşterinin politikası, ajanın sürücünün telefon numarasını söylemesini yasaklıyordu, ama API o numaraları döndürüyordu. Araç yanıtını özyinelemeli olarak gezen ve sürücüye ait iletişim alanlarını çıkaran, dispeçerin numaralarını ise koruyan bir filtre yazdık; tam olarak o araca uygulandı. Modele ulaşmayan şey, ajan nasıl sorulursa sorulsun söylenemez.

Yukarıdaki iddialar neye dayanıyor (18 kaynak)

Bunlardan 18 tanesi depolarımızdaki kod ve dosyalardır. Adlarını ya da satırlarını yayımlamıyoruz: hepsi bir arada, tek bir sayfada, yalnızca bize ait olmayan sistemlerin nasıl kurulduğunu fazla net anlatırdı. İstek üzerine, depoda sizinle birlikte gözden geçiriyoruz — doğrulama hâlâ mümkün, sadece bir görüşme içinde yapılıyor.

Neyin daha iyi çalışmasını isterdiniz?

Bize sürecinizi anlatın. Neyin kurulmaya değer olduğuna, neyi bağlayabileceğimize ve sonucu nasıl doğrulayacağımıza birlikte karar verelim.

Hadi konuşalım