Chatbot til hjemmeside: vælg en løsning, der passer til opgaven

Begynd med én opgave, som besøgende faktisk har

En god kravbeskrivelse begynder med en situation: En besøgende vil vide, hvilket forløb der passer, hvilke dokumenter der kræves, eller hvordan et produkt bruges. Skriv det ønskede resultat, før I vælger chatværktøj. Det gør det lettere at vurdere, om en chatbot overhovedet er den bedste hjælp.

Tag et udvalg af rigtige spørgsmål fra e-mail, telefon og eksisterende søgninger. Fjern personoplysninger, og del spørgsmålene i tre grupper: dem I kan besvare med offentlig viden, dem der kræver kundespecifikke opslag, og dem et menneske skal håndtere. Et ordrenummer i en chat er eksempelvis ikke i sig selv bevis for, at brugeren må se ordren.

Vælg en afgrænset første målgruppe. En offentlig vejledningsbot og en intern medarbejderassistent kan bruge samme teknologi, men har forskellige adgangs- og kvalitetskrav.

Vælg mellem standardværktøj og egen løsning

En indlejret chatbot kan være tilstrækkelig, når spørgsmålene er enkle, viden er offentlig, og administrationen passer til et standardprodukt. En mere tilpasset løsning bliver relevant, når samtalen skal følge en bestemt faglig metode, bruge flere systemer eller håndtere forskellige brugerroller.

Bed om en demonstration med jeres materiale. En flot samtale om leverandørens egen virksomhed siger begrænset om kvaliteten i jeres opgave. Undersøg også, om dokumenter, samtaler og konfiguration kan eksporteres, hvis I skifter leverandør. Beslutningen handler om hele driften, ikke kun det første chatvindue.

WordPress er visningen og en mulig kilde til viden

På et WordPress-site kan chatten vises som en diskret knap, et felt på udvalgte sider eller en selvstændig vejledningsside. Placeringen skal passe til læserens opgave og fungere på mobil uden at skjule navigation eller formularer.

WordPress-indhold kan være en kilde til svar. Aftal hvilke sider der må indlæses, hvor hurtigt ændringer slår igennem, og hvordan kladder eller interne sider holdes ude. Skal løsningen bruge beskyttede data, kræves en særskilt adgangsmodel. WordPress REST API har muligheder for godkendt adgang, herunder Application Passwords over HTTPS.

Tekniske nøgler skal håndteres på serveren. Et chatvindue på hjemmesiden skal ikke indeholde en nøgle, der giver besøgende direkte adgang til virksomhedens systemer. Test også, at chatten kan slås fra uden at gøre resten af sitet utilgængeligt.

Egen viden kræver mere end en mappe med dokumenter

Når chatten skal svare ud fra jeres eget materiale, kan en RAG-løsning finde relevante kildestykker før svaret formuleres. OpenAI File Search er ét eksempel på en tjeneste, der kombinerer semantisk søgning og søgeordssøgning i uploadede filer.

Den praktiske opgave er at afgøre, hvilke kilder der gælder. Har I to beskrivelser af samme ydelse, bør en redaktør tage stilling til forskellen. Chatten skal kunne vise en relevant kilde og sige fra, når grundlaget mangler. At der står en kilde under svaret, er ikke alene bevis for, at svaret følger den.

Brug almindelige dokumenter, som en fagperson kan vedligeholde. Aftal ejer og revisionsdato for hvert vigtigt emne, så kvaliteten kan bevares efter lanceringen.

Brug jeres prototype som et konkret projektgrundlag

Har I allerede en fungerende assistent eller Custom GPT, kan den vise den ønskede tone, spørgerækkefølge og faglige logik. Saml instruktioner, godkendte kilder og gode eksempelsamtaler. Beskriv også de steder, hvor prototypen opfører sig forkert. De eksempler gør tilbud og test langt mere præcise.

En selvstændig løsning kræver stadig beslutninger om login, samtalehistorik, administration, fejlbeskeder, forbrug og support. Skal brugeren kunne gemme et resultat, vende tilbage til et forløb eller hente en fil? Skal en redaktør kunne ændre instruktioner uden en udvikler?

Et kort møde med skærmdeling kan afklare meget: Vis den nuværende løsning og et typisk forløb fra start til slut. Det giver et bedre grundlag end en lang funktionsliste uden eksempler.

Gør datagrænser og godkendelsestest konkrete

Tegn et enkelt kort over, hvor brugerens spørgsmål, dokumenter og samtalehistorik bevæger sig. Vælg, hvad der er nødvendigt at gemme, hvem der må se det, og hvornår det slettes. Datatilsynet fremhæver, at databeskyttelse skal tænkes ind fra designfasen.

Lav derefter en testliste, der omfatter normale spørgsmål, uklare spørgsmål, forældede oplysninger og forsøg på at få adgang til intern viden. En bot til faglig vejledning bør også testes på spørgsmål, der ligger uden for dens mandat. Aftal, hvem der bedømmer svarene.

Brug de samme tests ved ændringer i model, instruktioner eller dokumenter. Et bestået testforløb er en begrundet beslutning om den aktuelle version; det er ikke en garanti for alle fremtidige svar.

• Kan svaret føres tilbage til en gældende kilde?
• Bliver manglende viden gjort tydelig?
• Er overdragelse til et menneske enkel?
• Kan én bruger få oplysninger, der tilhører en anden?

Det skal et brugbart chatbotbrief indeholde

Et godt brief beskriver målgruppen, én vigtig opgave, det nuværende website og de systemer, der eventuelt skal forbindes. Vedlæg nogle få repræsentative spørgsmål og angiv, hvilke svar I vil betragte som gode. Del ikke følsomme kundedata for at få et første overslag.

Bed tilbudsgiveren skelne mellem første version og mulige udvidelser. Det skal fremgå, hvem der leverer indhold, hvem der godkender kvaliteten, hvad der indgår i driften, og hvad der udløser ekstra arbejde. Med de afklaringer kan I sammenligne løsninger på et fælles grundlag.