AI e-poçt iş axınının avtomatlaşdırılması ümumi poçt qutusuna gələn məktubları avtomatik cavablandırmaq və ya CRM-i sərbəst yeniləmək demək deyil. Düzgün yanaşmada AI məktubun məzmununu başa düşmək üçün istifadə olunur, lakin nəticə qaydalar, etibar səviyyələri, sistem-of-record prinsipi və insan təsdiqi ilə idarə olunan iş axınına daxil edilir. Beləliklə procurement, əməliyyat, maliyyə və xidmət komandaları gələn müraciətləri daha sürətli emal edir, lakin nəzarəti itirmir.

Bu model xüsusilə shared inbox artıq əməliyyat giriş nöqtəsinə çevriləndə faydalıdır: məsələn, procurement@, operations@, finance@ və ya service@. Məqsəd poçt qutusunu yeni CRM və ya ERP ilə əvəz etmək deyil; məktubdan etibarlı, izlənilə bilən və nəzərdən keçirilə bilən giriş yaratmaqdır.

AI shared inbox automation nəyi etməlidir?

Yaxşı qurulmuş email intake automation prosesi hər yeni məktub üçün ardıcıl cavab verir: bu nə tip müraciətdir, hansı strukturlaşdırılmış məlumatlar var, hansı sənədlər əlavə edilib, məlumat yetərlidirmi, məsul komanda kimdir və növbəti addım avtomatik yaradılmalıdır, yoxsa yoxlama tələb olunur?

  1. Məktubu qəbul edin və dəyişməz surətini saxlayın. Message ID, conversation ID, göndərən, alıcılar, qəbul vaxtı, mövzu, mətn, HTML və əlavələrin metadatası saxlanmalıdır.
  2. Deterministik ilkin filtrlər tətbiq edin. Spam, auto-reply, newsletter, dublikat, icazəsiz göndərən və ya artıq bağlanmış mövzu AI mərhələsinə keçməzdən əvvəl qayda ilə idarə edilməlidir.
  3. Məktubu təsnifləşdirin. Məsələn: qiymət sorğusu, təchizatçı qeydiyyatı, satınalma tələbi, ödəniş sorğusu, xidmət hadisəsi, müqavilə dəyişikliyi və ya yanlış ünvanlanmış məktub.
  4. Yalnız təsdiq edilmiş sxem üzrə sahələri çıxarın. Şirkət adı, sorğu nömrəsi, məbləğ, valyuta, sifariş nömrəsi, tarix, obyekt, prioritet, tələb edilən fəaliyyət və əlaqədar müqavilə kimi sahələrdə “mətn nə deyir?” sualı ilə “sistem hansı formata icazə verir?” sualı ayrılmalıdır.
  5. Çatışmayan məlumatı və istisnaları aşkar edin. Məsələn, ödəniş tələbində invoice yoxdur, service request-də lokasiya yoxdur və ya göndərənin müqavilə ilə əlaqəsi təsdiqlənmir.
  6. Case, tapşırıq və ya qaralama yaradın. Bu, yalnız təyin olunmuş hədəf sistemdə, idempotency açarı və qaydalarla həyata keçirilməlidir.
  7. Riskə uyğun insan təsdiqi tətbiq edin. Aşağı riskli, yüksək etibarlı müraciətlər seçilmiş sahələrdə avtomatik draft yarada bilər; maliyyə, hüquqi və ya reputasiya təsiri olan addımlar isə təsdiq növbəsinə düşməlidir.

Email-to-case automation üçün nəzarətli arxitektura

Etibarlı həll “mailbox → LLM → CRM update” xəttindən ibarət olmur. Bu yanaşma eyni məktubun təkrar işlənməsi, yanlış əlaqələndirmə, səssiz məlumat itkisi və icazəsiz status dəyişiklikləri yarada bilər. Daha düzgün arxitektura hadisə əsaslı qəbul qatı, dəyişməz sübut deposu, AI çıxarış qatı, biznes qaydaları, approval queue, hədəf sistem inteqrasiyası və müşahidə qatından ibarətdir.

1. Qəbul və normalizasiya

Microsoft 365 və ya Google Workspace inteqrasiyası yeni mesaj hadisəsini qəbul edə bilər. Microsoft Graph Outlook mesajları üzrə dəyişiklik bildirişlərini dəstəkləyir; Gmail API isə mailbox dəyişiklikləri üçün push notification mexanizmi təqdim edir. Praktikada webhook yalnız “mesaj dəyişib” siqnalıdır: emal xidməti sonradan mesajı səlahiyyətli API çağırışı ilə oxumalı, qəbul hadisəsini jurnallaşdırmalı və eyni mesajın ikinci dəfə işlənməsinə qarşı idempotency tətbiq etməlidir.

2. Sübut və attachment zənciri

Orijinal EML/MIME və ya API-dən alınmış ekvivalent məzmun, attachment hash-ləri, emal versiyası və sonrakı qərarlar case ilə əlaqələndirilməlidir. Məktubda yazılan mətn, AI-nin çıxardığı dəyər və istifadəçinin sonradan düzəltdiyi dəyər ayrı saxlanmalıdır. Bu ayrım audit, araşdırma və model keyfiyyətinin ölçülməsi üçün vacibdir.

Attachment emalı ayrıca təhlükəsizlik sərhədidir. Fayl tipi, ölçü limiti, zərərli proqram yoxlaması və OCR/çıxarış statusu qeyd edilmədən sənədin məzmununa əsasən case açmaq risklidir. Şəkil və ya skan edilmiş PDF-dən alınmış məbləğ, tarix və kontragent adı mətn email-dən daha aşağı etibarlı qayda ilə qiymətləndirilə bilər.

3. AI çıxarışı və sxem yoxlaması

Modelə sərbəst xülasə yazdırmaq əvəzinə, JSON kimi ciddi sxem tələb edin: intent, entities, missing_fields, evidence_spans, confidence və recommended_action. Evidence span hər kritik sahənin mənbə məktubdakı hissəsini göstərir. Məsələn, “valyuta = USD” nəticəsi mətn və ya attachment səhifəsi ilə əlaqələndirilə bilməlidir.

Sxem yoxlamasından keçməyən nəticə heç vaxt ERP və ya CRM-ə yazılmamalıdır. Məbləğ üçün onluq formatı, tarix üçün ISO formatı, valyuta üçün icazəli kodlar, vendor ID üçün master-data axtarışı kimi yoxlamalar AI-dən sonra həyata keçirilməlidir.

Confidence threshold təkbaşına kifayət deyil

“95% confidence” tək qərar qaydası olmamalıdır. Modelin özünə verdiyi bal bəzən düzgün kalibrasiya olunmur və biznes təsirini nəzərə almır. Daha təhlükəsiz qərar matrisi ən azı bu amilləri birləşdirir:

  • niyyət və kritik sahələr üçün etibar balı;
  • məktubun məlum göndərəndən gəlməsi və domen yoxlaması;
  • məbləğ, təchizatçı, müqavilə və ya müştəri üzrə risk səviyyəsi;
  • master data və mövcud case ilə uyğunluq;
  • attachment-in mövcudluğu və emal keyfiyyəti;
  • əməliyyatın növü: draft yaratmaq, case açmaq, status dəyişmək və ya xarici email göndərmək eyni risk daşımır.

Məsələn, tanınan təchizatçıdan gələn, sifariş nömrəsi mövcud olan və bütün sahələri təsdiqlənən aşağı dəyərli çatdırılma sorğusu əməliyyat növbəsinə avtomatik case draft kimi düşə bilər. Bank rekvizitlərinin dəyişməsi, kredit notu, müqavilə istisnası və ya yüksək məbləğli ödəniş sorğusu isə etibar balından asılı olmayaraq insan yoxlaması tələb etməlidir.

Avtonom göndəriş və nəzarətsiz CRM yeniləməsindən fərq

Bu yanaşma “AI agent incoming email-i oxuyur və istədiyini edir” modeli deyil. Nəzarətli email workflow-da səlahiyyətlər minimuma endirilir:

  • AI cavab mətnini qaralama kimi təklif edə bilər, lakin təsdiq olmadan göndərmir;
  • AI potensial CRM sahələrini çıxara bilər, lakin source-of-truth rekordunu yalnız mapping və biznes qaydası icazə verərsə yeniləyir;
  • müəyyən action-lar yalnız case yaratmaq hüququna malikdir; ödəniş, status dəyişikliyi və ya əlaqə məlumatı dəyişməsi üçün ayrıca icazə tələb olunur;
  • istifadəçi düzəlişi və təsdiqi audit trail-ə daxil edilir.

API səviyyəsində record ID ilə işləyən bütün funksiyalarda obyekt-səviyyəli authorization tətbiq edilməlidir. Bu, xüsusilə mailbox-dan case management və ERP sistemlərinə məlumat ötürüləndə vacibdir. POLADO-nun süni intellekt və avtomatlaşdırma xidmətləri belə inteqrasiyalarda AI nəticəsini biznes qaydaları və icazə sərhədləri ilə birləşdirməyə yönəlib.

Praktik nümunə: procurement və operations shared inbox

Tutaq ki, əməliyyat komandası hər gün təchizatçılardan gecikmə, çatdırılma pəncərəsi, qiymət dəyişikliyi və sənəd çatışmazlığı barədə məktublar alır. AI email classification workflow məktubu “delivery exception” kimi tanıyır, purchase order nömrəsini çıxarır, əlavədəki delivery note-u oxuyur, çatdırılma tarixini strukturlaşdırır və mövcud order ilə uyğunluğu yoxlayır.

Əgər order tapılır, tarix dəyişiklik həddini keçmir və kontakt təsdiqlənirsə, sistem mövcud əməliyyat case-inə qeyd və planlaşdırıcı üçün tapşırıq draftı yarada bilər. Order tapılmırsa, PDF oxunmursa və ya göndərən tanınmırsa, “missing reference / reviewer needed” növbəsi yaranır. Sistem özündən purchase order yaratmır, təchizatçıya öhdəlik vermir və ERP-də maliyyə statusunu dəyişmir.

PoV və istehsala keçid üçün ölçüləcək göstəricilər

Layihəni yalnız “model neçə məktubu təsnif etdi?” ilə qiymətləndirməyin. Hər intent üzrə precision və recall, kritik sahə extraction accuracy, reviewer correction rate, yanlış routing rate, dublikat case rate, emal gecikməsi və insanın case başına sərf etdiyi vaxt ayrıca izlənməlidir. Həmçinin approval queue-da gözləmə müddəti, override səbəbləri və avtomatlaşdırmanın çatışmayan məlumat sorğularını azaltma təsiri ölçülməlidir.

İlk proof of value üçün bir mailbox, iki-üç yüksək həcmli intent və aydın qəbul meyarları seçmək daha yaxşıdır. Keçmiş məktublardan etiketlənmiş test dəsti yaradın, istisnaları ayrıca sinifləndirin, əvvəlcə “draft only” rejimində işə salın və insan düzəlişləri əsasında qaydaları, prompt-ları və threshold-ları tənzimləyin. NIST AI RMF-in govern, map, measure və manage məntiqi bu cür davamlı nəzarət üçün yararlı çərçivədir.

Başlamaq üçün checklist

  • Hansı shared inbox-lar biznes girişi sayılır və hansı müraciət növləri təkrarlanır?
  • Hər intent üçün yaradılacaq obyekt nədir: case, task, draft, məlumat sorğusu, yoxsa yalnız etiket?
  • Hansı tətbiq hər sahə üçün system of record-dir?
  • Hansı sahələr AI tərəfindən təklif edilə, hansı sahələr yalnız insan tərəfindən təsdiqlənə bilər?
  • Hansı istisnalar avtomatik insan növbəsinə keçməlidir?
  • Orijinal məktub, attachment, qərar və düzəlişlər necə saxlanacaq?
  • Retry, dublikat və API nasazlığı zamanı case-in iki dəfə yaranmasının qarşısı necə alınacaq?

Shared inbox prosesiniz təkrarlanan manual triage yaradırsa, AI Solutions & Automation çərçivəsində mailbox, case-management, CRM və ERP inteqrasiyalarını xəritələndirmək mümkündür. Daha mürəkkəb audit, role-based queue və daxili əməliyyat ekranları üçün veb platformaların hazırlanması da eyni idarəetmə modelinin bir hissəsi ola bilər. Məqsəd AI-ni nəzarətsiz operator etmək deyil; email girişini ölçülə bilən, yoxlanıla bilən və komandanızın idarə etdiyi iş axınına çevirməkdir.