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.

Bir projeyi konuşalım

Zaten kurduklarımızIntegrări proprii, scrise și rulate, măsurate azi în cod: conectorul pentru sistemul de programări Altegio (946 de linii, cu șase unelte expuse agentului), conectorul de CRM amoCRM (2.888 de linii în platforma de mesagerie, plus 12 funcții de server în platforma vocală), Bitrix24 (903 linii, plus 4 funcții), Google Sheets (615 linii, plus 10 funcții și un cont de serviciu dedicat), catalogul viu peste magazin (serviciu de platformă, 318 linii), notificări de lead pe Telegram (1.776 de linii), SMS prin Infobip cu limite anti-abuz, automatizări programate (1.088 de linii) și canalul de chat al unei platforme locale de anunțuri (2.459 de linii). În execuție, agentul poate chema 15 tipuri de unelte interne, pe lângă unelte prin webhook și unelte cu cod propriu rulat în izolare.

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.

Automatizare transparentă — integrări care se pot verifica · video în română, cu subtitrare și transcriere

Transcrierea completă

Să intrăm direct în subiect. Astăzi vom diseca realitățile tehnice și, sincer, adesea ignorate, ale automatizării prin asistenți bazați pe inteligență artificială. Ne vom concentra pe o abordare super pragmatică a platformei iCat.md dezvoltată de Mega Promoting. Nu avem promisiuni de marketing astăzi și, cu siguranță, nu avem concepte vagi. Discutăm despre o platformă aflată direct în producție, cu funcționalități explicate direct din arhitectura bazei de date. Așa că haideți să vedem cum arată, de fapt, automatizarea complet transparentă. Agenda acestei analize este simplă și la obiect. Trecem prin problema timpului, mecanica tehnologiei, un caz real, limitele clare ale sistemului, managementul datelor și pașii următori. Începem cu prima secțiune, problema timpului. Știți cu toții acea întrebare extrem de frustrantă? De ce o întreagă echipă de suport pierde ore bune, zi de zi, scriind de mână răspunsuri la fix aceleași cinci întrebări? Informația există deja pe site-ul companiei, dar, cu toate astea, clienții continuă să ceară detaliile în mod repetat. Și exact asta este esența problemei noastre. Fără o soluție tehnică potrivită, toate aceste solicitări repetitive pur și simplu înfundă mesageria directă, nu contează dacă e Instagram sau Messenger. În consecința, răspunsurile întârzie masiv pentru clienții care au cu adevărat o problemă complexă, cererile se rătăcesc în marea de mesaje, iar întregul proces de suport devine practic o cutie neagră pe care nu o poți nici verifica, nici măsura. Partea a doua. Cum funcționează, de fapt, tehnologia sub capotă? Uite care-i treaba. Setarea platformei se bazează pe patru pași foarte logici. Mai întâi conectăm canalele de comunicare folosind cod propriu. Apoi se indexează toată baza de cunoștințe. Urmează legarea uneltelor care pot executa acțiuni în sistemele voastre existente. Iar la final, și acest detaliu este vital, se configurează un traseu clar înregistrat direct în baza de date prin care botul predă discuția unui operator uman. Totul este un sistem vizibil și perfect configurabil. Acum, un aspect absolut fascinant. Nu vorbim din plian de aici. Acestea sunt setări extrase direct din schema bazei de date. Când asistentul are nevoie de un răspuns, el folosește o așa numită căutare hibridă. Implicit, algoritmul extrage 5 fragmente de text, aplică un prag strict de similitudine de 0-70 și acordă o importanță de 30% potrivirii exacte a cuvintelor. Totul este procesat prin modelul Text Embedding 3 Small. Practic, sistemul transformă cuvintele în concepte matematice pentru a prinde contextul exact. Răspunsurile nu sunt oghicitoare, ci matematică pură. Rețineți acest număr. 15. Este o limită tehnică absolută în sistem. Reprezintă timpul maxim, în secunde, alocat pentru a rula orice unealtă sau căutare. Dacă o integrare externă durează mai mult de atât, să zicem că are nevoie de 40 de secunde, nu o putem lăsa în fluxul live-a conversației. Ea trebuie procesată asincron, altfel s-ar rupe complet ritmul natural al dialogului. Și mai e ceva. Oamenii scriu pe chat în rafale, nu? 2, 3, 4 mesaje scurte trimise unul după altul. Pentru a nu înnebuni sistemul, există un tampon de concatenare de 15 secunde. Tot ce intră în această fereastră se lipește și devine o singură cerere clară. Mai mult, pe platforme ca Meta, unde uneori te lovești de mesaje duplicate trimise din eroare, sistemul aplică un filtru de memorie de 120 de secunde pe ID-ul mesajului. Astfel, clientul primește un singur răspuns coerent, nu 3 alarme false. Secțiunea a treia. Să vedem un caz real. Avem acest scenariu clasic de e-commerce. Avem un magazin online, cu un catalog impecabil pe site, dar care primește o avalanșă de mesaje private pe Instagram și Messenger? Mai e în stoc? Ce preț are? Aici integrarea s-a făcut elegant, conectând asistentul direct la interfața publică Store API de la WooCommerce. Fără complicații de securitate, catalogul viu al magazinului a fost pur și simplu pus în mânile asistentului. Doar aici intervine realitatea tehnică a fiecărei platforme, chiar și sub umbrela aceleiași companii, cum e Meta. Pe Messenger, asistentul vă poate arăta carusele de produse superbe. Pe Instagram, botul o să vă răspundă doar cu text și cel mult o imagine simplă. De ce? Pur și simplu pentru că Meta nu suportă acele șabloane generice pe Instagram. Asistentul trebuie să joace exact după regulile canalului unde se află. Aici este punctul critic. Ce se întâmplă când botul este depășit de situație? Ei bine, în baza de date conversația are stări explicite. Când o întrebare iese din zona de confort a catalogului, firul de discuție trece imediat din starea bot în starea umană. Și partea genială e că sistemul contorizează timpul în care răspundă operatorul uman, marcând totul clar, status OK, avertiziment sau termen depășit. Tot contextul este predat omului, fără să se piarda absolut nimic pe drum. Secțiunea A4 Limitele sistemului Pentru că transparența înseamnă să știm ce nu poate face. Sunt câteva limite ferme pe care trebuie să le acceptăm. Nu puteți trimite mesaje proactive pe WhatsApp dacă au trecut mai mult de 24 de ore de la mesajul clientului. Meta va trânti o eroare, mai exact eroarea 131047, iar acțiunea va eșua. Sistemul nu face fișie RPDF, nu citește atașamente. La partea de limbi străine, traducerile merg doar într-un singur sens. Clientul primește răspunsul tradus, dar operatorul vede originalul. Și, deși integrarea cu 999.md funcționează, este neoficială și se bazează pe cookie-urile din browser. Dacă platforma își modifică mecanismele, conexiunea cade și necesită reparații. Și rețineți neapărat asta. Asistentul este oglinda datelor voastre. Un preț greșit pe site va deveni garantat un preț greșit în conversație. El acționează ca un cititor, nu ca un manager de magazin. Nu va corecta din proprie inițiativă erorile umane din cataloge. Infrastructura tehnică de aici nu e o joacă. Totul este ținut pe un server privat Microsoft Azure. Discutăm despre o bază de date MySQL extrem de structurată, cu peste 80 de tabele modelate clar pentru a separa canalele și pentru audit. Cheile de acces pentru WhatsApp, care sunt supersensibile, folosesc criptare fernet. Pe lângă asta, la nivel de web, domeniile pentru widgetul de chat sunt adăugate manual într-o listă albă. Nimeni nu se conectează fără permisiune explicită. Trebuie însă să abordăm o realitate evidentă. Oamenii vor scrie tot felul de date personale în acele ferestre de chat, numere de telefon, adrese. Tehnic, nu ai cum să blochezi un câmp de text liber. Așa că soluția este administrativă. Când implementați un astfel de sistem, aveți nevoie, din secunda 1, de politici clare de retenție care să dicteze exact cine are voie să vadă acele date și pentru cât timp sunt stocate. Și am ajuns la punctul 6. Pașimul mători. Filozofia centrală a întregului sistem poate fi rezumată prin acest citat. Un asistent utim nu este cel care compune poezii sau scrie frumos, ci acela care este conectat la informații reale și, foarte important, știe exact unde trebuie să se oprească. Automatizarea eficientă în business înseamnă preluarea corectă a datelor și siguranța cu care cedes controlul unui operator uman la momentul oportun. Prin urmare, pasul următor nu este să cumpărați un soft, ci să vă analizați cu atenție procesele actuale. Evaluați ce fluxuri de lucru merită cu adevărat să fie construite și automatizate, cum se pot conecta ele în siguranță și, cel mai important, stabiliți cum veți măsura rezultatele cu date reale, nu cu iluzii de marketing. Și vă las cu această temă de gândire. Dintre toate procesele de comunicare dintr-o afacere, care sunt acelea care necesită cu adevărat empatia și tactul unui om și care sunt, de fapt, doar sarcinii repetitive ce așteaptă pur și simplu să fie conectate cu precizie la baza de date corectă? Orice plan de automatizare ar trebui să plece de la această întrebare. Mulțumim că ați fost alături de noi în această analiză!

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.

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.

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.

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.

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.

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.

Sistemele externe din jurul conversației: programări, catalogul magazinului, CRM, foi de calcul, SMS și canale de mesaje — fiecare citit la cerere, cu cheile rămase pe server.

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.

Nasıl çalışıyoruz Tüm hizmetler

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