Çatbot API və webhook inteqrasiya arxitekturası

Bir inteqrasiya yox, üç istiqamət

Nəyisə seçməzdən əvvəl üçünü ayırın. Oxumaq: bot söhbət zamanı canlı bir şey gətirir — sifariş statusu, anbar, boş qəbul vaxtı. Etmək: bot sistemdə nəyisə dəyişir — təyin edir, yaradır, yeniləyir. Xəbər vermək: söhbətdə baş verən bir şey kənara ötürülür — CRM-ə lead, komanda kanalına bildiriş.

Onların risk profilləri fərqlidir. Uğursuz oxuma botun etiraf edə biləcəyi narahatlıqdır. Uğursuz və ya dublikat əməliyyat insidentdir. Uğursuz bildiriş isə səssizdir — praktikada üçünün ən təhlükəlisi də elə odur, çünki lead-lər səssizcə gəlməyi dayandırarkən heç nə sınmış görünmür.

Sahibləri də fərqlidir. Oxuma adətən endpoint və məhdudlaşdırılmış etimadnamədən çox şey tələb etmir. Əməliyyatlar nəyin dəyişdirilə biləcəyi barədə siyasət qərarı tələb edir. Bildirişlər isə təyinatın sahibi olan və səsi kəsiləndə fərq edən adam tələb edir.

Canlı oxuma: nəyi indeksləmək yox, gətirmək

Ümumi qayda sadədir: fakt sizin yeniləmə dövrünüzdən tez dəyişirsə, onu bilik bazasına qoymayın. Gətirin.

• Sifariş və çatdırılma statusu — saatbasaat dəyişir və əksər biznesdə ən çox soruşulan canlı dəyərdir.
• Anbar və mövcudluq — indekslənmiş cavab bir gün ərzində yanlış olur, özü də mümkün ən dilxor istiqamətdə.
• Qəbul və təqvim əlçatanlığı — artıq tutulmuş vaxtı təklif etmək heç nə təklif etməməkdən pisdir.
• Hesaba xas dəyərlər — balans, plan, istifadə — bunları bir müştərinin datasını digərinə açmadan ümumiyyətlə indeksləmək mümkün deyil.
• Müştəriyə və ya müqaviləyə görə dəyişən qiymətlər — təhlükəsiz indekslənə bilən dərc olunmuş siyahı qiymətlərindən fərqli olaraq.

Qalan hər şeyi indeksləmək daha yaxşıdır. Canlı çağırış gecikmə, uğursuzluq forması və asılılıq əlavə edir, ona görə də köhnəlmənin sizə baha başa gələcəyi bir şeyi qazandırmalıdır.

Yaxşı uğursuz olan oxumanın dizaynı

1. 1Müştərinin dözə biləcəyi timeout qoyunİki-üç saniyə. API düşünərkən on beş saniyə donmuş söhbət nəticədə nə qaytarsa da, müştərini artıq itirib.
2. 2Timeout mesajını açıq təyin edin«Bunu indi yoxlaya bilmədim — kiminsə təsdiqləməsini təşkil edə bilərəm» düzgündür. Ağlabatan ümumi cavaba qayıtmaq ən pis nəticədir, çünki müştəri fərqi görə bilmir.
3. 3Söhbət daxilində oxumanı birdən çox təkrarlamayınTəkrarlar gecikməni çoxaldır. İlk cəhd və bir təkrar uğursuz olubsa, cavab yoxlaya bilmədiyinizdir.
4. 4Dəyər imkan verirsə qısa müddətli keş saxlayınAnbar bir neçə saniyəlik köhnə ola bilər. Balans adətən yox. Qlobal yox, dəyər üzrə qərar verin.
5. 5Etimadnaməni oxuma ilə məhdudlaşdırınYaza da bilən token nəticədə yazacaq tokendir.

Əməliyyatlar: bot nəyi dəyişə bilər

Əməliyyatlar inteqrasiyanın texniki yox, idarəçilik sualına çevrildiyi yerdir. Texniki hissə asandır; insidentlərə səbəb olan hissə əhatədir.

• Əməliyyatları ayrı-ayrı sadalayın. «Rezervasiyaları idarə etmək» əməliyyat deyil; «rezervasiya yaratmaq» və «rezervasiyanı siyasət daxilində sonraya keçirmək» əməliyyatdır.
• Hər əməliyyatı söhbətdən çıxarılan açarla idempotent edin. Şəbəkələr təkrar göndərir, müştərilər iki dəfə toxunur, iki dəfə yaradılmış rezervasiya isə özünüzün yaratdığı dəstək müraciətidir.
• Dağıdıcı əməliyyatları insanın arxasında saxlayın. Ləğv, geri qaytarma və silinmə bot tərəfindən hazırlanıb insan tərəfindən icra oluna bilər — təcrübəyə demək olar heç bir xərc olmadan.
• Hər parametri hüdudlandırın — nə qədər irəli, neçə dəfə, hansı saatlar daxilində, hansı məbləğə qədər.
• Müştərinin əsaslana biləcəyi təsdiq qaytarın, istinad nömrəsi də daxil. Müştərinin yoxlaya bilmədiyi əməliyyat yenidən cəhd olunacaq.
• Əməliyyatı söhbətlə birlikdə jurnala yazın ki, mübahisəli dəyişiklik mübahisə yox, araşdırma mövzusu olsun.

Çıxan hadisələr: səssiz uğursuz olan istiqamət

Bu, nəzərə çarpmadan sınmaq ehtimalı ən yüksək istiqamətdir, çünki sınanda müştəri tərəfində heç nə dəyişmir. CRM-ə heç vaxt çatmayan lead az lead olan həftə ilə eyni görünür.

• Çatdırılmanı müşahidə oluna bilən edin. Kimsə bazanı açmadan «son bir saatın lead-ləri gəldimi?» sualına cavab verə bilməlidir.
• Artan fasilə ilə təkrar cəhd edin və təkrarların sayına hədd qoyun. Bir saat sıradan çıxmış endpoint qayıdanda dörd min dublikat almamalıdır.
• Hadisə identifikatoru daxil edin ki, qəbul edən dublikatı kəsə bilsin. Ən azı bir dəfə çatdırma normal zəmanətdir və qəbul edənlər buna görə qurulmalıdır.
• Yalnız xətaya yox, yoxluğa görə də xəbərdarlıq qurun. Həqiqətən qarşılaşacağınız uğursuzluq forması sükutdur və «iş saatlarında dörd saat ərzində lead yoxdur» kimi hədd onu tutur.
• Yükü kiçik və sabit saxlayın. Bütün söhbət mətnini göndərən webhook iki sistemi ilk sxem dəyişikliyində sınan şəkildə bir-birinə bağlayır.
• Yükə versiya qoyun. Onu dəyişəcəksiniz, qəbul edən isə sizin qrafikinizlə deploy etməyəcək.

Təhlükəsizlik hədləri

Hər istiqamətə fərqli hədd lazımdır və aşağıdakılar ümumi yoxlama siyahısı yox, həqiqətən baş verən uğursuzluqlardır.

• Çıxan təyinatları icazə siyahısına salın. İş zamanı verilən ünvanı çağıracaq sistem sizin daxili şəbəkənizə yönəldilə bilər.
• Söhbətin məzmunu yoxlanılmadan təyinatı və ya parametri müəyyən etməsin. Müştərinin mesajı hər həddə etibarsız girişdir.
• API cavablarına göstəriş yox, data kimi yanaşın. Modelə əmr kimi oxunan mətn daşıyan qeyd nəzəri yox, real hücumdur.
• Hər etimadnaməni bir məqsədə məhdudlaşdırın və sahibi olan qrafiklə rotasiya edin.
• Söhbət və müştəri üzrə sorğu limiti qoyun ki, bir söhbət öz sistemlərinizə qarşı yük generatoruna çevrilməsin.
• Cavabın tələb etdiyindən çoxunu qaytarmayın. Rahat olduğu üçün tam müştəri qeydini qaytaran endpoint bütün digər səhvlərin təsir dairəsini genişləndirib.

Vexvon-da inteqrasiya necə işləyir

Mesajlaşma tərəfində şirkət öz API-lərini AI mühərrikinin söhbət zamanı çağıra biləcəyi alətlər kimi qeydiyyatdan keçirir — yuxarıda təsvir olunan canlı oxuma istiqaməti — sorğuların daxili ya digər təhlükəsiz olmayan ünvanlara yönəldilməsinə qarşı qoruma ilə. «1234 nömrəli sifariş haradadır?» sualına həqiqətən bilən sistemdən cavab verməyin mexanizmi budur.

Səs tərəfində alət modeli açıqdır və üç növə bölünür: statik dəyərlər, zəngin ötürülməsi, zəngin bitirilməsi və bilik bazasında axtarış kimi daxili əməliyyatlar və öz endpoint-lərinizə webhook-lar. Ssenarilər konkret zəngin hansı alətləri işlədə biləcəyini istiqamət, dil, səs və çıxarılacaq sahələrlə birlikdə təyin edir — yəni əməliyyat əhatəsi qlobal verilmir, ssenari üzrə konfiqurasiya olunur.

Çıxan istiqamət triggerlər vasitəsilə işləyir: lead satış qrupuna «Başla» düyməsi ilə Telegram bildirişi kimi çatdırıla, Bitrix24-ə ötürülə və ya daxili CRM-ə yazıla bilər — hər əməliyyat on növü olan fəaliyyət jurnalına qeyd olunmaqla. Çatdırılma nəzərdə tutulan yan təsir yox, konfiqurasiya olunmuş təyinat olduğu üçün «çatdımı» sualının cavablanacağı yer var.

Xərc və davranış bunların hamısında müşahidə oluna bilir: AI istifadəsi model, kanal və gecikmə göstərilməklə on yeddi ayrı məqsəd üzrə loglanır, zəng üzrə isə tokenlər, uğur faizi və dollar dəyəri qeyd olunur — inteqrasiya probleminin rəvayət yox, diaqnoz mövzusu olmasını təmin edən budur.

Tez-tez verilən suallar

1. 1Çatbot nəyi indeksləmək yox, canlı gətirməlidir?Yeniləmə dövrünüzdən tez dəyişən hər şeyi: sifariş statusu, anbar, qəbul əlçatanlığı, hesaba xas dəyərlər və müqavilə qiymətləri. Dərc olunmuş siyahı qiymətləri və sabit siyasətlər isə indekslənməlidir.
2. 2Canlı sorğunun timeout-u nə qədər olmalıdır?İki-üç saniyə, bitəndə isə açıq mesajla. On beş saniyə donmuş söhbət nəticədə nə qaytarsa da müştərini artıq itirib.
3. 3Bota əməliyyat aparmağa icazə verilməlidirmi?Hüdudlanmış, idempotent və geri alına bilən əməliyyatlar üçün bəli — rezervasiya yaratmaq, lead yaratmaq, üstünlük yeniləmək. Ləğv, geri qaytarma və silinmə bot tərəfindən hazırlanıb insan tərəfindən icra olunmalıdır.
4. 4İdempotentlik burada niyə vacibdir?Şəbəkələr təkrar göndərir, müştərilər iki dəfə toxunur. Söhbətdən çıxarılan açar olmadan bir sorğu iki rezervasiyaya çevrilir və siz öz dəstək müraciətinizi özünüz yaratmış olursunuz.
5. 5Ən yayğın inteqrasiya uğursuzluğu hansıdır?Çıxan hadisələrin səssiz sınması. Müştəri tərəfində heç nə sınmış görünmür, ona görə lead almağı dayandırmış CRM sakit həftə ilə eyni görünür. Yalnız xətaya yox, yoxluğa görə də xəbərdarlıq qurun.
6. 6Əsas təhlükəsizlik hədləri hansılardır?İcazə siyahısındakı təyinatlar, söhbət məzmununun yoxlanılmadan təyinat ya parametr seçməməsi, API cavablarına göstəriş yox data kimi yanaşma, dar məhdudlaşdırılmış etimadnamələr və söhbət üzrə sorğu limitləri.

Üç istiqaməti sadalamaqla başlayın

Hər hansı inteqrasiya imkanını qiymətləndirməzdən əvvəl üç qısa siyahı yazın: botun canlı oxumalı olduqları, dəyişə biləcəkləri və söhbət bitəndə kənara ötürülməli olanlar. Əksər komanda üçüncü siyahının heç kimin düşünmədiyi siyahı olduğunu görür — uğursuzluğu səssiz olan da məhz odur.