Hjemmesidebrief: få de rigtige oplysninger fra kunderne

En virksomhed vil have flere relevante henvendelser gennem sin hjemmeside. Det er et nyttigt mål, men det fortæller endnu ikke, hvad siden skal hjælpe en besøgende med. Skal kunden bestille et besøg, beskrive en opgave eller undersøge, om virksomheden overhovedet er den rette? Et godt hjemmesidebrief besvarer det, før arbejdet med farver, billeder og knapper begynder.

Brug eksemplerne til jeres eget brief, og erstat dem med de kundesituationer, I møder i hverdagen.

Begynd med en konkret kundesituation

Skriv, hvem der kommer ind på siden, og hvad der lige er sket. En driftsansvarlig med en dør, der ikke lukker, har brug for noget andet end en indkøber, der planlægger en større udskiftning. Hvis begge skal bruge samme side, skal deres næste skridt være tydelige. Det behøver ikke betyde to formularer. En kort forklaring på, hvilke opgaver I tager, kan være tilstrækkelig.

• Besøgende: Hvem træffer beslutningen, og hvem udfylder formularen?
• Anledning: Hvilket problem eller hvilken ændring fik personen til at lede efter jer?
• Spørgsmål: Hvad skal personen forstå, før det giver mening at kontakte jer?
• Handling: Hvad er det første rimelige skridt, kunden kan tage på siden?

Beslut hvad en brugbar henvendelse indeholder

Tag et eksempel fra jeres arbejde, og fjern navn og andre personlige oplysninger. Hvilke oplysninger gjorde det muligt at svare? Hvilke måtte I spørge om bagefter? Skriv de nødvendige oplysninger ind i briefet sammen med begrundelsen. Et felt skal have en opgave: hjælpe jer med at vurdere sagen, finde den rette kollega eller kontakte kunden igen.

Det kan for eksempel være en kort opgavebeskrivelse, en lokation og den foretrukne kontaktform. Budget, filupload og detaljerede valgmuligheder skal kun med, hvis de er nødvendige i netop jeres første afklaring. Oplysninger, der først bruges senere, kan vente til samtalen.

W3C's vejledning om formularer anbefaler korte, relevante formularer med tydelige feltnavne og instruktioner. Den beskriver også, at brugeren skal kunne forstå fejl og få besked, når opgaven er gennemført. Det er konkrete krav, som kan skrives direkte ind i et brief.

Beskriv hvad der sker efter et tryk på send

En kvittering på skærmen er kun en del af forløbet. Briefet bør også navngive den person eller funktion, som modtager henvendelsen, og hvor den bliver gemt. Skal den ligge i en fælles indbakke, i et kundesystem eller i en opgaveliste? Aftal også, hvordan en kollega ser, at nogen allerede har taget sagen, så kunden ikke får to forskellige svar.

Skriv den ønskede kvittering i almindeligt dansk. Den skal fortælle, at beskeden er modtaget, og hvad næste skridt er. Lov kun et svartidspunkt, hvis I faktisk kan stå inde for det. Mangler systemet forbindelse, skal kunden kunne se, at afsendelsen ikke er bekræftet. En grøn besked må ikke dække over en henvendelse, som ingen kan finde.

Aftal, hvordan I tester den færdige side

Beskriv en kort prøve, som både I og den, der bygger siden, kan udføre. Åbn siden på en telefon. Find den relevante ydelse. Send en testhenvendelse med de nødvendige oplysninger. Kontroller derefter både kundens kvittering og modtagerens indbakke eller opgaveliste. Gentag med et manglende felt og en forkert mailadresse.

• Kan en ny besøgende forklare, hvilken opgave siden hjælper med?
• Kan formularen bruges med tastatur, og er felterne tydeligt navngivet?
• Bevares de indtastede oplysninger, når et felt skal rettes?
• Kan den ansvarlige finde henvendelsen og se, hvad kunden forventer?

Mål det led, I vil forbedre

Hold besøg, påbegyndte formularer, gennemførte henvendelser og relevante samtaler adskilt. Hvis mange starter, men få sender, er det et andet problem end en fuld indbakke med opgaver, I ikke tager. Skriv jeres definition af en relevant henvendelse i briefet, og aftal hvordan I følger op på den. Det giver et mere brugbart grundlag for næste ændring end et generelt ønske om mere trafik.

Vil I bygge videre på briefet, kan I læse guiden til at vælge en udviklingspartner eller beskrive den opgave, I ønsker hjælp til. Vedlæg gerne den kundesituation og de oplysninger, som siden skal hjælpe med at samle.

Kilder

W3C WAI: Forms Tutorial, læst 8. september 2026. Bruges til afsnittet om feltnavne, relevante oplysninger og feedback. Briefets øvrige arbejdsspørgsmål er redaktionens forslag.