Перейти до основного вмісту
megapromotingПоговорімо

Експертиза · Інтеграції та автоматизації

Щоб ваші системи розмовляли між собою, без того щоб хтось повторно вводив ті самі дані.

Ми з’єднуємо систему запису, магазин, CRM, таблиці та канали повідомлень так, щоб агент або заплановане правило могли читати й писати в них у реальному часі. Ключі залишаються на сервері, інструменти мають прописані межі, а кожна інтеграція тестується також на випадку, коли інша система падає.

Вже збудованоIntegră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.

Інтеграція — це не логотип на сторінці. Це відповідь на дуже конкретне запитання: чи може цю систему читати і записувати в реальному часі, хто, з якими правами, і що відбувається, коли вона не відповідає? Тому наше перше запитання для будь-якої інтеграції — не «з яким API», а «які публічні ворота вона має». Іноді відповідь повністю змінює вартість роботи: магазини на WooCommerce, наприклад, публічно відкривають API магазину, який не вимагає жодного ключа споживача, тож новий клієнт підключається лише з адресою свого сайту — не з обліковими даними, які треба згенерувати, надіслати, а потім ротаувати.

У нашій платформі меседжингу інструмент, який агент може викликати під час розмови, має один із трьох типів: виклик webhook, власний код, запущений ізоляційно, або внутрішній інструмент платформи. Внутрішні інструменти — це ті, які ми надаємо перевагу, бо вони тримають ключі поза базою даних: сьогодні їх п’ятнадцять, від читання сторінки й запису в таблицю до доступності та створення запису, надсилання SMS і запиту каталогу продуктів.

Різниця між інтеграцією, яка тримається, і тією, що ламається, майже завжди криється в дрібницях, виявлених на практиці. Система запису нічого не повертає, якщо запитати години спеціаліста для послуги, яку він не надає — послуга і спеціаліст завжди ходять разом. Та сама система відповідає відмовою, якщо запит приходить із типовим заголовком HTTP-бібліотеки, тож кожен запит має явно ідентифікуватися. Магазин може повертати нульову ціну для товарів із варіантами, а пошук за порожніми словами повертає весь каталог. Є десять таких деталей на кожну інтеграцію, і жодна з них не є в документації.

Понад інтеграціями стоять автоматизації: правила, що виконуються в часі, а не на чиєсь запитання. У нас вони заплановані через планувальник у процесі — повторне відкриття розмов без відповіді, перше повідомлення новому контакту, призупинення й повторний запуск агента після робочого часу — кожна зі своїми лічильниками, щоб було видно, скільки було запусків, скільки повідомлень пішло, скільки було пропущено і чому. Автоматизація без лічильника — це автоматизація, про яку ви не можете сказати, чи працює вона.

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ă!

Що входить

Робота, за складовими

Спочатку перевіряємо, яка публічна брама є в системи

Для магазинів на WooCommerce ми використовуємо публічний магазинний API, який не потребує ключа споживача: клієнт підключається лише з адресою сайту. Це вибір, що має реальні наслідки, а не лише естетичні — ми замінили ним зроблені вручну інструменти, які тримали ключі магазину відкрито в базі даних. Коли в системи немає публічної брами, переходимо до автентифікації, але тоді ключ стає елементом, яким керують, а не тим, який забувають у рядку бази даних.

Ключі залишаються на сервері, не в інструменті й не на сторінці

Інструмент SMS є внутрішнім для платформи саме тому, що середовище, у якому виконується власний код інструмента, не має доступу до змінних середовища — якби надсилання виконувалося з коду інструмента, ключ довелося б записати в базу даних, а цей ключ може надсилати повідомлення коштом усіх. Так само і в системі записів: партнерський токен один, він зберігається в середовищі сервера, тоді як клієнт вказує лише ідентифікатор своєї компанії.

Агент викликає інструмент під час розмови, з параметрами і терміном

Кожен інструмент має опис, написаний для моделі, типізовані параметри з тим, що є обов’язковим, а що ні, і власний термін виконання — від 15 секунд для списку послуг до 30 для пошуку доступності. Термін для кожного інструмента — не дрібниця: без нього повільна інтеграція блокує розмову, а людина на іншому кінці чує тишу.

Реальні записи в системі салону або клініки

Шість інструментів поверх Altegio: список послуг із реальними цінами, спеціалісти, повна доступність, створення запису, скасування та зміна. Доступність повертає не лише «вільно/зайнято»: вона повертає, які спеціалісти виконують потрібну послугу, і перші вільні години для кожного, відсортовані за найранішою, саме щоб агент міг запропонувати конкретну альтернативу замість того, щоб казати «недоступно».

Каталог магазину, прочитаний наживо

Ціна й доступність читаються з магазину в момент запитання, а не з застарілої копії. Каталог завантажується пагіновано, до 30 сторінок по 100 продуктів, зберігається в тимчасовій пам’яті на десять хвилин на сайті й нормалізується в одну форму, що читається без змін усіма споживачами — включно з каруселлю продуктів у месенджері, якій потрібна числова ціна, і віджетом на сторінці, якому потрібен заголовок.

CRM, таблиці та канали повідомлень

amoCRM і Bitrix24 із повним OAuth, оновленням токена та перевіркою стану. Google Sheets через окремий сервісний обліковий запис, відокремлений від решти облікових даних, із записом, що запускається агентом. Telegram для сповіщень про лід. SMS через Infobip. Плюс канал чату локальної платформи оголошень, підключений із власним токеном оновлення — тип інтеграції, якого немає в жодному міжнародному каталозі й який має велике значення локально.

Автоматизації, що виконуються в часі, з лічильниками

Повторне відкриття розмов без відповіді, перше повідомлення новому контакту, призупинення й повторний запуск агента після графіка. Кожен запуск збільшує видимі лічильники: скільки запусків, скільки надісланих повідомлень, скільки пропущено, бо агент був вимкнений, скільки — бо не мав конфігурації, скільки помилок. Без них єдиний спосіб дізнатися, що автоматизація померла, — скарга клієнта.

Антизловживальні обмеження, бо рішення ухвалює модель

Інструмент, викликаний мовною моделлю, потребує меж, які модель не може перевищити. Для SMS: у режимі «до компанії» одержувач береться з конфігурації, ніколи — від моделі; у режимі «до клієнта» номер нормалізується й перевіряється. Понад це — денна межа на агента, пауза в одну хвилину до того самого номера і обмеження довжини повідомлення. Це паркани, записані в коді, а не інструкції в промпті — промпт можна обійти, паркан — ні.

Фільтри на виході, для даних, які не мають права вийти

Коли інтеграція повертає більше, ніж клієнт повинен знати, ми фільтруємо на виході, а не сподіваємося, що агент утримається. Реальний приклад: для клієнта з транспортної сфери політика забороняє, щоб агент диктував номер телефону водія, але API повертало ці номери у відповіді. Ми написали фільтр, який рекурсивно проходить результат інструмента й видаляє поля контакту водія, зберігаючи номери диспетчерської. Фільтр застосовується рівно там, де потрібно, не глобально, щоб випадково не приховати щось інше.

Як це виглядає

Шлях, крок за кроком.

01

Інвентар: які системи, які шлюзи, які права

Які системи задіяні, що відкриває кожна, хто має право створювати креденціали і хто їх ротує. Для кожної базове запитання: чи можна читати без автентифікації? Якщо так, інтеграція стає значно дешевшою і набагато легше повторюється для другого клієнта.

02

Конектор: оголошені інструменти, ключі на сервері, терміни

Кожна дія стає інструментом із назвою, описом, написаним для моделі, типізованими параметрами та власним терміном. Ключі залишаються в серверному середовищі. Наприкінці агент не «вміє робити» щось розмите: у нього є скінченний набір дій, кожна з власними межами.

03

Тест на випадку, який завершується помилкою, а не лише на тому, який працює

Конектор тестується на правильному запиті, на неповному запиті, на системі, що відповідає повільно, і на системі, що не відповідає зовсім. Те, що каже агент, коли інтеграція падає, — це рішення про проєктування, а не помилка, яку виявляє клієнт: ми надаємо перевагу чесному повідомленню та передаванню людині замість правдоподібної імпровізації.

04

Стійкість до нестабільності іншої системи

Повторна спроба із зростаючими паузами, але лише для помилок, які має сенс повторювати, — обмеження швидкості або помилка сервера, а не неправильний запит, який і вдруге буде неправильним. А коли проблема на рівні мережі іншої сторони, підхід інший; приклад нижче — саме такий випадок.

05

Передача: що змінюється, коли змінюється постачальник

Ми позначаємо, що зламається, якщо інша система змінить свій API, які креденціали спливають і коли, що треба оновити вручну. Інтеграція без цього списку — це прихований борг: вона працює ідеально до дня, коли перестає працювати, і ніхто не знає чому.

Un centru. În jur, ce intră în el — pe trasee separate.CENTRUL SE SPRIJINĂ PE CE E ÎN JURUL LUI
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.

Дані

Чого торкаємося, де воно лежить і скільки лишається

Запитання, які ставить кожен, у кого є відповідальний за захист даних, — поставлені тут раніше, ніж їх поставить він.

Де зберігаються креденціали
Ключі постачальника платформи зберігаються в серверному середовищі, не в базі даних і ніколи не на клієнтській сторінці. Власні креденціали клієнта — там, де інтеграція їх вимагає — зберігаються зашифрованими. Різниця важлива: скомпрометований ключ платформи зачіпає всіх, креденціал клієнта зачіпає один обліковий запис; ми обробляємо їх по-різному, бо ризик різний.
Що зберігається із зовнішніх систем, а що ні
Каталог продуктів не копіюється: він читається на запит і тримається в тимчасовій пам’яті десять хвилин, щоб десять послідовних запитань про один і той самий магазин не означали десять повних проходів. Записи не дублюються у нас — джерелом істини залишається система салону. Ми зберігаємо слід розмови та результат дії, а не копію бази іншої системи.
Що потрапляє до мовної моделі
Результат інструмента потрапляє в розмову, отже потрапляє і в контекст моделі. Саме тому фільтрація робиться на результаті, перед тим як його буде передано моделі, а не в інструкціях. Поля, які клієнт не має права чути, видаляються на джерелі; те, що було видалено, не можна продиктувати, незалежно від того, як запитують агента.
Cи може підключити інтеграцію
Підключення інтеграції — це автентифікована операція, прив’язана до облікового запису бізнесу, а отримані інструменти прикріплюються до конкретного агента — не до всіх. У агента є рівно ті інструменти, які йому потрібні для його ролі. Така сама логіка, як і з доступом працівника: йому не дають усі ключі лише тому, що так простіше.
Що ще треба виправити, сказано прямо
Не всі модулі інтеграції на нашій платформі перебувають на одному рівні. Ті, що перелічені тут, написані й запущені. Є також модулі, з яких почали, на кілька десятків рядків, які ще нічого корисного не роблять — ми не подаємо їх як доступні й не включаємо в жодну пропозицію. Якщо вам потрібна система, яка у нас перебуває на такому етапі, ми розглядаємо її як роботу на розробку, з попередньою перевіркою сумісності, а не як пункт для позначки.

Випадок

Інтеграція періодично падала, і це було не в нас

Ситуація

Конектор CRM іноді працював, а іноді ні, без видимого на перший погляд шаблону. Запити зависали, доки не перевищували ліміт виконання серверного середовища, тож у журналах з’являвся тайм-аут — ознака, яка хибно підштовхує шукати повільність у власному коді.

Що ми збудували

Причина була в мережі, на іншому кінці. Ім’я домену облікового запису CRM розв’язується в кілька IP-адрес, а частина вузлів кластера була несправною. Звичайний HTTP-запит обирає одну адресу і, якщо вона не відповідає, не пробує інші адреси, які повернув DNS — автоматичного переходу до наступної відповіді немає. Виправлення полягало в тому, щоб більше не використовувати стандартний HTTP-клієнт для цього домену: ми самі розв’язуємо ім’я, відкриваємо зашифровані з’єднання безпосередньо до кожної адреси паралельно, з коротким терміном для кожної, і використовуємо першу, що відповість; якщо всі в раунді холодні, повторюємо.

Що вийшло

Періодичні збої перестали бути лотереєю. Що важливіше для клієнта: діагноз став висловлюваним в одному реченні — «вузли постачальника періодично недоступні, і ми їх оминаємо» — замість «іноді не працює».

Чого цей випадок не каже

Це виправлення компенсує проблему когось іншого, і про це треба сказати. Воно додає складності до нашого коду через дефект в інфраструктурі постачальника; якщо той виправить свій кластер, складність залишиться в нас. Ми документуємо це саме так, щоб можна було прибрати, коли воно більше не буде потрібне.

Питання

Про що нас питають, перш ніж зателефонувати

Які системи ви фактично підключили, а не теоретично?

Систему запису Altegio, із шістьма діями, викликаними агентом. amoCRM і Bitrix24, із повним OAuth і оновленням токена. Google Sheets, із виділеним сервісним обліковим записом. Магазини на WooCommerce, через публічний API магазину. Telegram, для сповіщень. Infobip, для SMS. Канал чату локальної платформи оголошень. Плюс канали обміну повідомленнями Meta і Telegram для розмов. Для будь-якої іншої системи — включно з платформами магазинів, які ми не довели до кінця — чесна відповідь така: на запит, після перевірки сумісності, що розглядається як робота, а не як налаштування.

Мій магазин має генерувати мені API-ключі?

Для WooCommerce — ні. Ми використовуємо публічний API магазину, який не вимагає ключа споживача — ви підключаєтеся через адресу сайту. Це ще й безпечніше, не лише простіше: ми замінили цим підходом старіші інструменти, які зберігали ключі магазину у відкритому вигляді в базі даних. Для інших платформ усе залежить від того, що вони відкривають; ми перевіряємо це до того, як щось обіцяти.

Чи може агент зробити реальний запис, а не лише сказати, що робить його?

Так, якщо система запису це дозволяє. Вона створює запис, може його скасувати й змінити, а також перевіряє доступність перед цим. Деталь, яку вивчають лише на практиці: у цій системі послуга і спеціаліст подорожують разом — якщо ви запитуєте вільні години спеціаліста для послуги, яку він не виконує, ви отримуєте нуль результатів, а не помилку. Тому інструмент доступності повертає всіх спеціалістів, які надають послугу, і перші вільні години для кожного, щоб агент міг запропонувати конкретну альтернативу.

Куди потрапляють мої ключі?

Ключі платформи залишаються в середовищі сервера, ніколи не в базі даних і ніколи на вашій сторінці. Креденціали, які належать вам, зберігаються зашифрованими. Правило, яке ми застосовуємо: якщо ключ може витрачати гроші або може читати дані для всіх клієнтів, йому не місце ніде, куди потрапляє код, що виконується на запит мовної моделі.

Чи може агент надсилати SMS кому завгодно?

Ні, і це навмисне обмеження. У режимі сповіщення компанії одержувач береться з конфігурації — модель не може його обрати. У режимі до клієнта номер нормалізується і перевіряється. Понад це є добова межа на агента, пауза в одну хвилину до того самого номера і ліміт довжини повідомлення. Це запобіжники в коді, не інструкції в промпті; промпт можна обійти через розмову, запобіжник — ні.

Що стається, коли система іншої сторони падає або відповідає повільно?

Кожен інструмент має власний час виконання, тож повільна система не блокує розмову. Ми повторюємо спроби з наростаючими паузами, але лише для тих помилок, які варто повторювати, — обмеження швидкості або помилка сервера, не неправильний запит. А поведінка агента при збої прописується в сценарії: він каже, що зараз не може перевірити, і передає розмову, замість того щоб вигадувати правдоподібну відповідь.

Що стається, якщо постачальник змінює свій API?

Щось ламається, і саме тому ми надаємо перевагу офіційним шлюзам, а не читанню сторінок. Інструменти, що витягують інформацію з HTML сайту, ламаються від будь-якої зміни теми — ми свідомо замінили їх однією реалізацією поверх офіційного API, саме щоб не підтримувати десятки крихких варіантів. Коли альтернативи немає, ми кажемо, що це крихке рішення, і ставимося до нього саме так.

Ви можете робити автоматизації без агента, лише за запланованими правилами?

Так. Повторне відкриття розмов, що залишилися без відповіді, перше повідомлення новому контакту, зупинка і запуск агента після робочого часу — це заплановані завдання, що виконуються самі. Кожне має власні лічильники запусків, надісланих повідомлень, пропущених повідомлень і помилок, щоб на запитання «чи спрацювало?» можна було відповісти цифрою, а не припущенням.

Як ви забезпечуєте, щоб агент не казав зайвого з інтеграції?

Ми фільтруємо результат до того, як він потрапить до моделі, а не після. Конкретний випадок, який ми вирішили: політика клієнта забороняла агенту диктувати номер телефону водія, але API повертав ці номери. Ми написали фільтр, що рекурсивно проходить відповідь інструмента і прибирає поля контактів водія, зберігаючи номери диспетчерської, застосований саме до того інструмента. Те, що не потрапляє до моделі, не може бути сказане, незалежно від того, як питають агента.

На чому ґрунтуються твердження вище (18 джерел)

18 з них — це код і файли з наших репозиторіїв. Ми не публікуємо їхні назви чи номери рядків: разом, на одній сторінці, це надто точно описало б, як побудовані системи, які належать не лише нам. Ми проходимо їх разом із вами, у репозиторії, за запитом — перевірка залишається можливою, просто вона відбувається в розмові.

Що вам хотілося б налагодити?

Розкажіть про свій процес. Разом визначимо, що варто збудувати, що можна підключити і як перевіримо результат.

Поговорімо