Kan teknikeren bruge det, agenten sender?

Forestil jer en opgave, som går fra en planlægger til en tekniker. Teknikeren skal kunne genkende anlægget, åbne de godkendte dokumenter og se, hvad andre allerede har besluttet. Vælg tilladte eksempler fra jeres egen hverdag: en almindelig sag, en manglende anlægsreference, dokumenter med modstridende revisioner og den samme henvendelse igen. Skriv det forventede resultat, før leverandøren viser, hvad agenten gør.

Bed modtageren være med. Et velskrevet sammendrag kan mangle netop det nummer, teknikeren bruger til at finde sagen. Aftal særskilte felter til anlæg, ordrehenvisning, kilder, manglende oplysninger og den person, der skal afklare dem. Fritekst kan forklare sammenhængen. Den bør ikke skjule, at en nødvendig reference mangler, eller at ingen har taget ansvar for det næste skridt.

Glean siger, at kildesystemets rettigheder gælder, når der læses og skrives. Microsoft beskriver, at svar fra videnskilder begrænses til det indhold, agentens bruger må se, når brugerens identitet er bekræftet.^1,2

Prøv derfor sagen med forskellige roller, for eksempel en intern planlægger og en ekstern servicetekniker. Brug testkonti, hvis rettigheder I kender. Den eksterne tekniker skal kunne åbne det aftalte materiale og blive afvist ved andet materiale. Gem både forventningen og det faktiske resultat. Et link i agentens svar er ikke nok, hvis det næste klik blot giver teknikeren beskeden “adgang nægtet”.^1,2

Prøv igen efter en ændring i adgang eller en ny dokumentrevision. Spørg, hvornår ændringen slår igennem, og få det vist for den valgte forbindelse, før I accepterer svaret. Prøv også den enhed og kanal, teknikeren skal bruge. En administrator ved en stabil forbindelse er ikke en dækkende prøve på arbejdet ude ved anlægget. I skal vide, hvad brugeren ser, når forbindelsen forsvinder og kommer tilbage.

UiPath beskriver, at processer kan vente på godkendelse og fortsætte bagefter. LangGraph beskriver, at processens tilstand kan gemmes, så den fortsætter efter fejl eller pauser.^3,4

Prøv, hvad det betyder for jeres ordre. Aftal en kontrolleret afbrydelse efter godkendelsen, men før modtagelsen er bekræftet. Find så ud af, om ordren allerede er oprettet i modtagersystemet. Et nyt forsøg skal ikke ske på et gæt om, at det første mislykkedes. Bed om en reference, som lader jer følge samme henvendelse gennem godkendelse, forsøget på at gemme og den modtagne post.^3,4

Prøv også en afvisning fra ordresystemet og en godkendelse, som ingen svarer på. Aftal, hvem der tager sagen, og hvilke oplysninger der følger med. Beskeden “fejl” hjælper ikke meget uden anlægsreference og sidste kendte status. Lad modtageren vise, hvordan sagen afsluttes eller fortsætter. Hvis det kræver en forklaring fra projektteamet, mangler der stadig noget i overdragelsen.

Nexus beskriver, at agenten sender sagen videre med fuld kontekst, når den er usikker. Selskabet tilbyder også, at en ingeniør bygger den første arbejdsgang sammen med kundens team og viser den i kundens egne værktøjer.^5,6

Den hjælp kan bruges til at forme overdragelsen sammen med den kollega, der skal tage imod. Bed Nexus bygge et eksempel, hvor en uklar anlægsreference sendes til planlæggeren med henvendelsen, de fundne oplysninger og sidste kendte status. Når planlæggeren er med under opbygningen, kan I få rettet mangler i selve forløbet, mens behovet bliver afklaret. Accepter eksemplet, når modtageren kan fortsætte sagen uden at samle historien forfra.^5,6

Giv hver prøvesag en række med forventet resultat, faktisk resultat, bevis, ansvarlig og beslutning. Brug for eksempel “accepteret”, “skal rettes” eller “kræver afklaring”. Vedlæg den modtagne ordre og relevante logudsnit, hvor I har adgang til det. En optagelse af agentens svar viser ikke i sig selv, at ordren findes i fagsystemet, eller at teknikeren kan åbne den. Beviset skal passe til det, I godkender.

I kan for eksempel beslutte, at forkert anlægsidentitet, adgang til uvedkommende data eller en ukontrolleret dobbeltordre kræver rettelse og en ny prøve. Aftal sådanne stopregler mellem drift og it, inden I begynder. Denne prøve handler om oplysninger og overdragelse; den omfatter ikke tekniske sikkerhedsbeslutninger. Lad den kommende driftsansvarlige acceptere både den almindelige vej og håndteringen af de svære tilfælde, I har prøvet.