Kort svar
Supportavtaler blir ofte for vage om innhold, responstid og pris, og da blir det vanskelig å skille vedlikehold fra ekstraarbeid.
Før dere signerer eller begynner å levere, bør dere ha kontroll på hva som inngår i vedlikehold og ordinær support, hvordan feil, prioritet og responstid håndteres og hva som prises som endringer eller tilleggstjenester.
Når dette blir aktuelt
- når programvare skal følges opp etter leveranse
- når kunden forventer løpende forbedringer gjennom supportavtalen
- når leverandøren vil unngå at alt regnes som inkludert
Det bedriften bør avklare først
| Spørsmål | Hvorfor det betyr noe |
|---|---|
| Hva som inngår i vedlikehold og ordinær support | avgjør hva kunden faktisk betaler for |
| Hvordan feil, prioritet og responstid håndteres | er viktig for forventningsstyring og kapasitet |
| Hva som prises som endringer eller tilleggstjenester | reduserer risikoen for diskusjon om timebruk og omfang |
Slik bør dere gå fram
- Beskriv hvilke typer bistand som er inkludert og hvilke som ikke er det.
- Lag klare kategorier for feil, responstid og kontaktpunkter.
- Knyt avtalen til et sakssystem eller annen sporbar måte å melde og følge opp henvendelser på.
- Avklar hvordan endringer og forbedringer utenfor avtalen skal bestilles og prises.
Dokumenter og spor som bør være på plass
De fleste kontraktstvister starter fordi leveranse, ansvar eller endringer ikke ble gjort tydelige nok i forkant.
- support- eller vedlikeholdsavtale med tjenestebeskrivelse
- feilkategorier, responstider og åpningstider
- prisark for tilleggstjenester eller endringsarbeid
- rutine for bestilling og logging av saker
Typiske feil
- supportbegrepet brukes om alt fra brukerhjelp til produktutvikling
- kunden kan ikke se hva som er inkludert i fastprisen
- sakshåndtering skjer i ustrukturert e-post uten historikk
Når bør dere få konkret hjelp?
Når programvaren er sentral i kundens drift eller supportvolumet er høyt, bør avgrensningen kvalitetssikres før avtalen tas i bruk.
Slik bruker dere guiden i praksis
For en bedrift er ikke målet å lese seg opp på vedlikeholds- og supportavtale for programvare i seg selv. Målet er å avklare hva som må besluttes, hvem som eier oppfølgingen, og hvilke dokumenter som bør tåle en senere kontroll, tvist eller intern gjennomgang.
Bruk derfor guiden som en arbeidsliste: start med partene, leveransen, prisen, risikoen og exit, og fordel deretter oppgavene mellom kommersiell ansvarlig, økonomi og den som eier leveransen. Da blir vurderingen mer konkret enn en generell regelavklaring, og dere reduserer risikoen for uklar leveranse, svake ansvarsgrenser og dyre diskusjoner ved endring eller opphør.
Spørsmål som gir bedre avklaring
- Hvem er avtalepartene, og hvem kan faktisk forplikte dem?
- Hva skal leveres, når skal det leveres, og hvordan skal endringer bestilles?
- Hvilke punkter kan gi størst økonomisk tap hvis de er uklare?
- Hva må være regulert om data, rettigheter, underleverandører eller konfidensialitet?
- Hvordan kan avtalen avsluttes ryddig hvis samarbeidet ikke fungerer?
Et godt beslutningsgrunnlag bør vise
| Del | Hva bør stå klart |
|---|---|
| Leveranse | hva partene faktisk skal gjøre, levere, betale og godkjenne |
| Risiko | hvilke feil, forsinkelser, rettigheter eller ansvarsgrenser som kan bli dyre |
| Oppfølging | hvordan endringer, avvik, fornyelse og avslutning skal håndteres |
Denne typen oversikt gjør det enklere å prioritere riktig nivå på arbeidet. Den hjelper også bedriften å skille mellom det som kan løses med bedre intern rutine, det som bør avklares med motpart eller leverandør, og det som bør vurderes før dere tar neste formelle steg.
Relaterte guider
- Lisensavtale for programvare eller innhold
- Leverandøravtale: hva bedriften bør sikre
- Rammeavtale med kunde: når lønner det seg?