O notificare intră: un utilizator nu se poate autentifica, o imprimantă nu funcționează, un server dă erori. Cineva de la serviciul de asistență transformă asta într-un tichet, alege o categorie și stabilește urgența. Poate AI să preia asta? În mare parte da, cu o excepție importantă care diferă de la firmă la firmă.
Trei axe sunt decisive: volumul, marja de apreciere și contactul cu clientul.
Volumul este ridicat. Un serviciu de asistență procesează zilnic zeci până la sute de notificări, iar multe dintre acestea sunt variații ale unui număr mic de probleme cunoscute: parolă uitată, fără acces la un share, laptopul nu se pornește. La volume mari și repetiție, o sarcină este prin definiție potrivită pentru automatizare, pentru că un model învață din tipare care se repetă frecvent.
Marja de apreciere este limitată. Urgența și categoria decurg de obicei dintr-un arbore decizional: câți utilizatori sunt afectați, există o soluție temporară, despre care sistem este vorba. Acesta este exact genul de activitate la care modelele de text se pricep: citirea unei notificări, extragerea caracteristicilor și confruntarea acestora cu un model de categorizare. Ce poate AI să facă astăzi este text — notificările propriu-zise, formulate adesea liber de către utilizator, și retraducerea acestora într-un tichet structurat.
Contactul cu clientul este funcțional, nu relațional. Un utilizator care raportează o defecțiune vrea mai ales ca aceasta să fie luată în lucru, nu să se creeze o conversație. Situația este diferită în momentul în care lucrurile nu funcționează bine sau devin sensibile — vedeți pentru aceasta și cum este comunicată o defecțiune către utilizatori, pentru că este o altă sarcină cu un alt profil.
Componenta fizică nu joacă niciun rol: este o activitate administrativă la un ecran, nu o acțiune asupra unor echipamente. Costurile erorilor sunt medii. O notificare prioritizată greșit rareori duce la daune directe, dar în cazul sistemelor supuse conformității — un sistem financiar, o fișă a pacientului — situația este diferită, iar axa conformității are aici un scor mai mare decât media. O defecțiune într-un mediu cu obligație legală de raportare necesită un motiv documentat pentru clasificare, nu doar o etichetă.
Punctul vulnerabil este creativitatea, și exact de aceea nu este vorba de o preluare completă. O notificare care nu se încadrează în tiparul cunoscut — o combinație nouă de simptome, un sistem care se defectează pentru prima dată, un utilizator care descrie problema neclar — necesită pe cineva care gândește, nu doar clasifică. Acolo intervine supravegherea: AI propune o categorie și o urgență, un om aprobă sau ajustează, cu motiv. Aceasta este o organizare diferită de preluarea completă, și este de asemenea practica cea mai frecventă la firmele care lucrează deja astfel.
La o firmă cu un peisaj de aplicații mic și bine delimitat și câteva sute de utilizatori, nouăzeci la sută din notificări sunt o repetare a ceva care s-a mai întâmplat de o sută de ori. Acolo, un model cu un model de categorizare bun poate rezolva independent cea mai mare parte a preluării, cu un om care vede doar excepțiile.
La o firmă cu multe sisteme legacy, software personalizat și un istoric de fuziuni, tiparul este mai puțin previzibil. Notificările sunt mai diverse, categoriile sunt mai puțin clar delimitate, iar șansa ca o notificare să nu se încadreze în tiparul cunoscut este mai mare. Acolo rămâne o parte mai mare din activitate în sarcina unui om, nu pentru că AI nu ar vrea să o facă, ci pentru că informația de intrare este prea nestructurată pentru a obține automat ceva de încredere.
Condiția prealabilă nu este deci tehnologia, ci procesul de preluare: formulare de intrare structurate și un model de categorizare a incidentelor bine dezvoltat determină în mare măsură cât din această activitate este deja transferabilă astăzi. Fără aceste două elemente, cea mai mare parte rămâne muncă manuală, cu AI ca instrument, nu ca executant.
Aceasta nu este un sfat de personal și nici o justificare pentru reducerea unei echipe de serviciu de asistență. Dacă și cum o organizație trage consecințe de personal din modificarea activității este o decizie a angajatorului, pentru care se aplică cerințe legale proprii; pentru rigoarea necesară în acest sens, consultați punctele de atenție la eliminarea funcțiilor. Această pagină descrie doar ce se întâmplă cu sarcina în sine.
Este util, de asemenea, să nu privim această sarcină izolat de restul operațiunii IT. Înregistrarea incidentelor este legată de activități precum monitorizarea performanței sistemelor, care oferă adesea semnalele timpurii înainte de a exista o notificare, și de sarcini de administrare precum efectuarea și verificarea copiilor de siguranță sau păstrarea actualizată a datelor de bază, care au aceeași combinație de volum ridicat și marjă de apreciere limitată. Cine dorește să știe pentru întregul departament IT unde se află deja schimbarea, face cel mai bine să analizeze toate sarcinile împreună, nu un singur proces de tichete.
Rezultatul pentru propriul dumneavoastră serviciu de asistență depinde de câte dintre notificările dumneavoastră se încadrează în tipare recognoscibile și cât de bine este deja structurată intrarea dumneavoastră. Aceasta diferă de la firmă la firmă și nu poate fi exprimată printr-o regulă fixă.
Scanarea rapidă gratuită de la FTE TO AI oferă o primă indicație în acest sens: douăsprezece întrebări, fără cont, cu o indicație privind partea din orele din profilul dumneavoastră care poate fi preluată astăzi de AI. Scanarea completă a activității, care calculează activitatea unei întregi firme, sarcină cu sarcină, în capacitate de fte, este încă în construcție.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.