AI support ticket triage automation daxil olan dəstək müraciətlərini mövzu, dil, müştəri konteksti, təcillik və eskalasiya riski üzrə sistemli şəkildə ayırmaq üçün istifadə olunur. Ən etibarlı yanaşmada AI müstəqil “dəstək agenti” kimi qərar vermir: o, help-desk növbəsini zənginləşdirir, kateqoriya və cavab layihəsi təklif edir, riskli halları isə mütləq insan yoxlamasına yönəldir.

Bu model e-poçt qutusu avtomatlaşdırmasından fərqlənir. Burada əsas obyekt help-desk tiketidir: sahiblik, SLA taymeri, növbə, eskalasiya siyasəti, müştəri tarixi və bağlanma keyfiyyəti birlikdə idarə olunur. Məqsəd “daha çox avtomatik cavab” deyil; doğru müraciətin doğru komandaya kifayət qədər kontekstlə və gecikmədən çatdırılmasıdır.

AI ilə dəstək triajı hansı işi görməlidir?

Tiket yaradıldığı anda sistem API, webhook və ya inteqrasiya qatından məlumatı qəbul edir. Mənbə help-desk forması, canlı çat, mobil tətbiqdaxili sorğu, əlaqə forması və ya e-poçt ola bilər. Sonra AI və qayda mühərriki birlikdə aşağıdakı strukturlu nəticəni yaradır:

  • İntent və kateqoriya: giriş problemi, ödəniş, texniki xəta, sifariş statusu, hesab dəyişikliyi, şikayət və s.;
  • Dil və ton: müştərinin dili, narazılıq və ya təcili cavab ehtiyacı siqnalları;
  • Prioritet əlamətləri: xidmət kəsintisi, mümkün təhlükəsizlik hadisəsi, SLA gecikməsi və ya təkrarlanan müraciət;
  • Kontekst: hesab növü, müqavilə/SLA səviyyəsi, açıq insident, əvvəlki tiketlər və məhsul sahəsi;
  • Təklif: kateqoriya, etiketlər, uyğun növbə, cavab layihəsi və lazım olduqda bilik bazası məqaləsi.

Bu çıxışlar “fakt” kimi deyil, yoxlanıla bilən təklif kimi saxlanmalıdır. Xüsusilə müştərinin statusu, məhsul sahibliyi və SLA kimi məlumatlar dil modelinin təxminindən deyil, CRM, müqavilə sistemi və ya help-deskdəki sistem qeydlərindən alınmalıdır.

Etibarlı AI ticket routing workflow necə qurulur?

1. Məlumatı qəbul edin və normallaşdırın

Fərqli kanallardan gələn mətn, əlavələr, forma sahələri, müştəri identifikatorları və söhbət tarixçəsi vahid tiket sxeminə çevrilməlidir. Hər hadisə üçün mənbə ID-si, vaxt möhürü və emal statusu saxlanmalıdır. Bu, təkrarlanan webhook-lar, gecikən hadisələr və yenidən göndərişlər zamanı idempotent emal üçün vacibdir.

2. Qaydaları AI-dan əvvəl tətbiq edin

Bəzi marşrut qərarları deterministik olmalıdır. Məsələn, “hesabım ələ keçirilib”, kart məlumatı, hüquqi bildiriş, özünə zərər siqnalı, təhlükəsizlik zəifliyi və ya VIP müqavilə hesabı müəyyən olunarsa, tiket birbaşa qorunan növbəyə keçməlidir. AI bu hallarda xülasə və kontekst hazırlaya bilər, lakin prioriteti azaltmamalı, bağlama və ya cavab göndərmə səlahiyyəti almamalıdır.

3. AI-dan məhdud, strukturlaşdırılmış nəticə istəyin

Modeldən sərbəst mətn əvəzinə təsdiqlənən sahələr qaytarın: intent, məhsul, dil, təcillik siqnalları, təklif edilən növbə, etibar göstəricisi və cavab layihəsi. Sxem yoxlaması, icazəli kateqoriya siyahısı və təhlükəsiz defoltlar vacibdir. Məsələn, model tanımadığı məhsulu “uydurmamalı”; nəticə unknown / human review olmalıdır.

4. Etibar həddinə görə marşrutlayın

Yüksək etibarlı, aşağı riskli “parol sıfırlama təlimatı haradadır?” kimi hallar təklif edilən etiket və növbə ilə avtomatik zənginləşdirilə bilər. Orta etibarlı hallarda agent təsdiqi tələb olunmalıdır. Aşağı etibarlı, ziddiyyətli və ya yüksək təsirli müraciətlər isə prioritet insan nəzərdən keçirmə növbəsinə düşməlidir. Etibar balı təkbaşına qərar deyil; risk səviyyəsi, hesab dəyəri, SLA və konkret açar söz qaydaları ilə birlikdə istifadə edilməlidir.

İnsan eskalasiyası məcburi olmalı olan hallar

Customer service AI escalation dizaynının mərkəzində “insana nə vaxt keçmək lazımdır?” sualı dayanır. Aşağıdakı kateqoriyalar üçün məcburi eskalasiya siyasəti yazılı və test edilə bilən olmalıdır:

  • təhlükəsizlik, məxfilik, hesabın ələ keçirilməsi və ya məlumat sızması şübhəsi;
  • ödəniş mübahisələri, geri qaytarma istisnaları, hüquqi və tənzimləyici müraciətlər;
  • xidmət kəsintisi, genişmiqyaslı məhsul problemi və ya təkrar açılan tiketlər;
  • müqaviləli/VIP hesablar, SLA pozuntusu riski və rəhbərliyə eskalasiya;
  • hədələyici, zorakılıq və ya həssas şəxsi vəziyyət bildirən mesajlar;
  • AI nəticəsinin qeyri-müəyyən, ziddiyyətli və ya aşağı etibarlı olması.

Bu qaydalar yalnız promptda yazılmamalıdır. Onlar iş axınında icra olunan siyasətlər, giriş nəzarəti və növbə icazələri kimi qurulmalıdır. Bu yanaşma modelin səhv başa düşməsi və ya zərərli mətnin sistemi yönləndirməsi halında təsiri məhdudlaşdırır.

Agent nəzarəti: layihə cavabı, avtopilot deyil

Yaxşı AI customer support automation agentə ilk baxışda lazımi məlumatı göstərir: qısa xülasə, ehtimal olunan intent, əlaqəli hesab faktları, oxşar açıq tiketlər, tövsiyə olunan növbə və cavab layihəsi. Agent təklifi qəbul, redaktə və ya rədd edə bilməlidir. Rədd səbəbləri — səhv kateqoriya, çatışmayan kontekst, uyğun olmayan ton, yanlış prioritet — sonrakı təkmilləşdirmə üçün dəyərlidir.

Ən təhlükəsiz başlanğıc adətən “yalnız təklif” rejimidir. Komanda nəticələri qiymətləndirəndən sonra aşağı riskli etiketləmə və marşrutlama mərhələli şəkildə avtomatlaşdırıla bilər. Müştəriyə cavab göndərilməsi, tiket bağlanması, kompensasiya və hesab dəyişiklikləri isə ayrıca səlahiyyət modeli və təsdiq qapısı tələb edir.

Ölçməli olduğunuz metriklər

Avtomatlaşdırmanın uğurunu yalnız bağlanan tiketlərin sayı ilə ölçməyin. Əməliyyat paneli aşağıdakıları göstərməlidir:

  • kateqoriya və növbə üzrə AI təklifi ilə agentin son qərarı arasındakı uyğunluq;
  • override və eskalasiya nisbətləri, səbəblər və komandalar üzrə paylanma;
  • ilk cavab vaxtı, SLA pozuntusu riski və prioritet tiketlərin gözləmə müddəti;
  • aşağı etibarlı nəticələrin həcmi və “unknown” kateqoriyasının artması;
  • yenidən açılan tiketlər, təkrar əlaqələr və həll olunmamış dövrlər;
  • inteqrasiya xətaları, gecikən webhook-lar və emal olunmayan tiketlər.

Bu metriklər modelin “ağıllı” görünməsindən daha əhəmiyyətlidir. Onlar səhv marşrutlama, dəyişən məhsul terminləri, yeni insident növləri və ya komandanın prosesdəki boşluqlarını erkən aşkar etməyə kömək edir. NIST-in AI risk idarəetmə yanaşması da insan rollarının aydın müəyyənləşdirilməsini, davamlı ölçmə və monitorinqi vurğulayır.

Praktik tətbiq planı

  1. Bir növbəni seçin: çoxsaylı məhsul və bütün kanallarla deyil, təkrarlanan və nisbətən aşağı riskli tiket növü ilə başlayın.
  2. Taksonomiyanı təmizləyin: kateqoriyalar, prioritetlər, eskalasiya səbəbləri və sahiblik qaydaları qeyri-müəyyən qalmamalıdır.
  3. İnteqrasiyanı təhlükəsiz qurun: help-deskdən oxuma, etiket yazma, növbə dəyişmə və cavab layihəsi yaratma icazələrini ayrıca məhdudlaşdırın.
  4. Tarixi tiketlərdə sınaq keçirin: canlı marşrutlamadan əvvəl nəticələri keçmiş agent qərarları ilə müqayisə edin.
  5. İnsan təsdiqi ilə pilot edin: ilkin mərhələdə avtomatik bağlama və ya xarici sistemdə geri dönməz dəyişiklik etməyin.
  6. Monitorinq və yenidən kalibrləmə qurun: hədləri, qaydaları və kateqoriyaları override məlumatı əsasında dövri yeniləyin.

POLADO bu cür həlləri Süni intellekt və avtomatlaşdırma xidməti çərçivəsində proses dizaynı, help-desk inteqrasiyası, qorunan eskalasiya qaydaları və ölçülə bilən monitorinq ilə hazırlayır. Mürəkkəb müştəri portalları və daxili əməliyyat ekranları üçün veb platformaların hazırlanması, istehsal mühitində müşahidə və davamlı təkmilləşdirmə üçün isə texniki dəstək və konsaltinq imkanları da birləşdirilə bilər.

Komandanızın tiket həcmi, SLA-ları, eskalasiya matrisi və mövcud help-desk alətlərini qiymətləndirmək üçün POLADO ilə əlaqə saxlayın. Məqsəd daha çox işi avtomatlaşdırmaq deyil, doğru hallarda təhlükəsiz və ölçülə bilən avtomatlaşdırma qurmaqdır.