limelytix
← Artikler
Rapportskriving

Hva skal en kvalitetsrapport for livestream egentlig inneholde?

Det vanligste spørsmålet vi får: hva må med i rapporten, og hvor lang bør den være? Her er svaret, med funn, alvorlighetsgrad og anbefalinger i en fast rekkefølge.

Henrik Solbakken

5 min lesetid

Hva skal en kvalitetsrapport for livestream egentlig inneholde?

Spørsmålet vi får oftest

På nesten hvert kurs kommer det samme spørsmålet i løpet av første time: hva skal egentlig stå i en rapport etter en livestream? Deltakerne har ofte gode notater, skjermbilder og loggføringer, men vet ikke hvordan de skal samles til noe en produsent faktisk kan bruke dagen etter sending.

Svaret mitt er alltid det samme. En rapport skal gjøre det mulig for mottakeren å forstå hva som skjedde, hvor alvorlig det var og hva som bør gjøres før neste sending. Alt som ikke bidrar til det, hører hjemme i arbeidsnotatene dine og ikke i selve rapporten.

Dette er andre del av vår gjennomgang av rapportskriving og anbefalinger. Her tar vi selve oppbygningen. Selve vurderingen av prioritering og oppfølging behandles ikke her.

Fast rekkefølge gjør rapporten lesbar

Vi anbefaler en rekkefølge som lesere kjenner igjen fra gang til gang. Først en kort oppsummering på noen få linjer: hva ble vurdert, hvor lenge, og hva er hovedinntrykket. Deretter funnene, ordnet etter område. Til slutt anbefalingene, rangert etter hva som bør rettes først.

En fast struktur sparer leseren for leting. Produsenten som åpner den tredje rapporten din vet allerede hvor hun finner lydfunnene og hvor anbefalingene står. Den som skriver sparer også tid, fordi malen tvinger frem de samme spørsmålene hver gang.

Husk at oppsummeringen skrives sist, selv om den står først. Først når funnene er ferdig sortert vet du hva som faktisk var hovedpoenget.

  • Oppsummering: omfang, varighet og hovedinntrykk
  • Funn per område: bilde, lyd, synk, teksting, avbrudd
  • Anbefalinger i prioritert rekkefølge
  • Vedlegg: logg, målinger og tidspunkter

Et funn er mer enn en observasjon

Det er forskjell på å skrive at lyden var for lav og å skrive et funn. Et godt funn har fire deler: hva du så eller hørte, når det skjedde, hvordan du målte eller kontrollerte det, og hvilken konsekvens det hadde for seer eller sending.

Eksempelvis: «Mellom tidspunkt 00:42 og 00:51 lå talenivået klart under resten av sendingen, målt med samme måler hele veien. Seere ville trolig skrudd opp volumet og blitt overrasket av musikken som fulgte.» Her kan mottakeren sjekke tidspunktet selv, og det er hele poenget med etterprøvbarhet.

Unngå formuleringer som «dårlig lyd» eller «litt hakkete». De sier mer om skribentens følelse enn om sendingen, og de gir ingen å rette på.

  • Hva ble observert
  • Når, med tidspunkt i sendingen
  • Hvordan det ble kontrollert
  • Hvilken effekt det hadde for seeren

Alvorlighetsgrad skiller viktig fra mindre viktig

Ikke alle funn veier like tungt, og en rapport som behandler dem likt gjør jobben vanskeligere for mottakeren. Vi bruker en enkel skala med tre trinn: må rettes før neste sending, bør rettes, og kan vurderes senere. Skalaen forklares én gang øverst, og deretter merkes hvert funn.

Poenget er ikke presisjon i seg selv, men at produsenten raskt ser hva som krever handling. Et svart bilde i åpningen og en liten forskyvning i teksten midt i sendingen er begge funn, men de hører ikke til på samme trinn.

Vær ærlig når du er usikker på årsaken. Skriv hva du vet, hva du antar og hva som må undersøkes videre. Det er mer nyttig enn en trygg påstand som viser seg å være feil.

Anbefalinger som noen faktisk kan følge

En anbefaling bør kunne gjøres om til en oppgave. «Forbedre lydkvaliteten» er ikke en oppgave. «Kontroller talenivået mot en referansetone før sending og noter verdien i sjekklisten» er det. Knytt hver anbefaling til funnet den svarer på, slik at sammenhengen er åpen.

Hold antallet nede. Fem til åtte anbefalinger som blir fulgt er verdt mer enn tjue som havner i en skuff. Rangér dem, og si tydelig hvem som er naturlig eier av hver av dem, selv om du ikke setter navn.

Til slutt: skriv anbefalinger til neste sending, ikke som kritikk av forrige. Tonen avgjør om teamet leser rapporten som hjelp eller som dom.

  • Knytt hver anbefaling til ett funn
  • Formuler den som en oppgave
  • Rangér etter alvorlighetsgrad

Hvor lang skal den være

Det andre vanlige spørsmålet er lengden. Svaret er at lengden følger sendingen. For en kort sending holder én til to sider, mens en lang produksjon med flere avbrudd gjerne trenger fire til seks, medregnet vedlegg. Selve rapporten bør kunne leses på ti minutter.

Legg detaljer i vedlegg: målinger, loggutdrag og skjermbilder med tidspunkt. Da kan den som vil etterprøve gjøre det, mens den som bare trenger hovedlinjene slipper å lese gjennom alt.

På kurset øver vi på dette med eksempelmateriale, og deltakerne skriver rapporten flere ganger. Andre utkast er nesten alltid kortere og bedre enn første.

En god rapport har fast rekkefølge, funn som kan etterprøves, en tydelig skala for alvorlighetsgrad og anbefalinger som lar seg gjøre om til oppgaver. Den er kort nok til å bli lest og detaljert nok til å bli trodd. Øv på å skrive den flere ganger, og be en kollega som ikke så sendingen lese den. Forstår vedkommende hva som bør gjøres først, har rapporten fungert.

Skrevet av

Henrik Solbakken

Hovedinstruktør, bilde og video

Har jobbet med videoproduksjon og strømming i over ti år. Underviser i bildekvalitet og feilsøking.

Les også

  1. Hva en kvalitetsrapport koster, og hva som styrer prisen

    Hvor mye tid går med til en teknisk rapport om en livestream, og hvilke valg gjør den dyrere eller billigere å lage? Her er en gjennomgang med faste punkter.

  2. Slik gjennomgår vi teksting: verktøyene bak en etterprøvbar vurdering

    En gjennomgang av metodene og hjelpemidlene vi bruker når vi vurderer tekstingens timing, lesbarhet og dekning, og hvordan funnene blir til rettelser etter sending.

Send oss en melding