Ett genomarbetat support- och underhållsavtal gör det enklare att ge rätt hjälp, planera resurser och hantera önskemål som går utanför den ordinarie tjänsten.
Avtalet beskriver vilken löpande hjälp och vilket underhåll en leverantör ska ge för en produkt eller tjänst. Det kan reglera supportkanaler, öppettider, felhantering, uppdateringar, kundens medverkan och ersättning för extra arbete.
Support handlar ofta om att hjälpa användaren och hantera problem. Underhåll kan exempelvis omfatta felrättningar och uppdateringar av programvaran. Begreppen används på olika sätt, så definiera vad de betyder i just ert erbjudande.
Hur skiljer sig avtalet från ett SLA?
Supportavtalet beskriver vilken hjälp som ingår och hur samarbetet fungerar. Ett SLA anger mätbara servicenivåer, exempelvis svarstid eller tillgänglighet, och hur avvikelser hanteras.
Dokumenten kan vara separata eller ingå i samma avtalsstruktur. Det viktiga är att de ger samma besked. En utfästelse om svar inom en timme behöver exempelvis kopplas till supportens öppettider och till vilka ärenden den gäller.
1. Beskriv vad supporten omfattar
Börja med att identifiera produkten, tjänsten eller miljön som supporten gäller. Ange också vilka versioner, moduler och integrationer som omfattas.
Beskriv sedan vilken typ av hjälp kunden får. Det kan vara användarfrågor, felsökning, felanmälan eller teknisk vägledning. Förklara om installation, utbildning och kundspecifika anpassningar ingår eller beställs separat.
Ett användbart sätt att göra omfattningen tydlig är att ge exempel:
| Situation | Fråga som avtalet bör besvara |
|---|---|
| En användare kan inte logga in. | Ingår felsökning av konto och behörighet? |
| Kunden vill koppla in ett nytt system. | Är det support eller ett separat integrationsuppdrag? |
| Kunden behöver utbilda nya medarbetare. | Ingår utbildning eller finns ett tilläggserbjudande? |
| Felet uppstår efter en kundspecifik ändring. | Vem utreder orsaken och hur debiteras arbetet? |
2. Gör det enkelt att kontakta rätt person
Ange hur kunden ska registrera ett ärende och vilka kontaktvägar som gäller. Om kritiska incidenter kräver telefonkontakt behöver det framgå tydligt.
Bestäm även om alla användare får kontakta supporten eller om kunden ska utse kontaktpersoner. För större kunder kan en intern första linje förenkla ärendehanteringen, men då behöver ansvarsfördelningen vara överenskommen.
Beskriv öppettider, tidszon och hur helgdagar hanteras. Kunden ska kunna förstå när den kan förvänta sig hjälp och vad som gäller utanför ordinarie tider.
3. Skilj på svar och lösning
En svarstid anger när kunden får en överenskommen första respons. Den säger inte automatiskt när problemet är löst.
Om ni också avtalar om återställning eller rättning behöver dessa åtaganden beskrivas separat. Förklara när tidsmätningen börjar, vilka tider som räknas och om några tidsangivelser är mål snarare än bindande löften.
Undvik att låta en automatisk mottagningsbekräftelse räknas som kvalificerad respons utan att det är tydligt avtalat. Kunden behöver veta vilken faktisk hantering servicenivån innebär.
4. Prioritera ärenden efter påverkan
Ett fel som stoppar en affärskritisk funktion behöver en annan hantering än en mindre visningsfråga. Utgå från verksamhetspåverkan och möjligheten att fortsätta arbeta med en tillfällig lösning.
Bestäm vem som sätter prioritet, vilken information som behövs och när nivån kan ändras. Ange även hur ärenden eskaleras och hur ofta kunden får uppdateringar vid mer omfattande problem.
En gemensam modell minskar risken att allt märks som akut eller att ett allvarligt fel hamnar i en vanlig ärendekö.
5. Definiera underhåll och uppdateringar
Kunden behöver förstå vad som ingår när programvaran utvecklas. Skilj exempelvis mellan felrättningar, säkerhetsuppdateringar, nya versioner och nya funktioner som säljs separat.
Beskriv också vem som installerar uppdateringar och vilka tekniska förutsättningar som krävs. För en molntjänst kan leverantören hantera införandet, medan installerad programvara kan kräva kundens medverkan.
Om äldre versioner slutar stödjas behöver kunden få tydlig information om tidplan, alternativ och konsekvenser. Hanteringen måste passa de villkor ni faktiskt har avtalat och de regler som gäller för produkten.
6. Planera driftstopp och kundens medverkan
Om underhåll kan påverka tillgängligheten bör avtalet beskriva hur det planeras och kommuniceras. Ange hur detta förhåller sig till eventuella servicefönster i SLA.
Beskriv även vad kunden behöver bidra med vid felsökning, exempelvis loggar, felbeskrivning eller tillgång till en testmiljö. Be om relevant information och använd säkra rutiner när material delas.
Vid fjärråtkomst behöver det vara tydligt vem som godkänner åtkomsten, hur den begränsas och när den avslutas. Supportprocessen ska fungera tillsammans med era säkerhets- och dataskyddsrutiner.
7. Reglera kostnader för tillägg
Bestäm hur arbete utanför ordinarie omfattning beställs och prissätts. Det kan röra kvällsarbete, utbildning, extra felsökning eller hjälp med tredjepartslösningar.
Kunden bör få veta när ett ärende riskerar att bli debiterbart och vem som får godkänna kostnaden. Ange om priset beräknas per timme, per uppdrag eller enligt en särskild prislista.
En tydlig övergång från supportärende till beställt tilläggsarbete minskar risken för överraskningar på fakturan.
8. Hantera beroenden till andra leverantörer
Kundens miljö kan innehålla flera system som påverkar varandra. Ange om ni hjälper till att samordna felsökningen även när grundorsaken finns hos en annan leverantör.
Skilj på ansvar för att åtgärda ett fel och ansvar för att kommunicera om det. Kunden kan fortfarande behöva en uppdatering från er även när ni väntar på besked från en driftpartner.
Kontrollera att underleverantörernas supporttider och åtaganden stödjer de löften ni lämnar.
9. Beskriv uppföljning och avslut
Bestäm hur parterna följer upp återkommande problem. En enkel genomgång av ärendevolym, svarstider och vanliga orsaker kan ge underlag för både produktförbättringar och utbildning.
Reglera också avtalstid, uppsägning och vad som händer med öppna ärenden när avtalet avslutas. Om kunden behöver överlämning till en ny leverantör bör omfattning och ersättning vara tydliga.
Ett praktiskt exempel
En kund anmäler att en rapport inte går att exportera efter att ett externt system har uppdaterats. Avtalet bör hjälpa parterna att avgöra vem som felsöker, om den aktuella integrationen omfattas och hur en eventuell anpassning beställs.
En bra rutin gör att ärendet kan undersökas utan att kunden och leverantören först behöver förhandla om hela supportens omfattning.
Vanliga frågor om support- och underhållsavtal
Ingår nya funktioner alltid i underhåll?
Nej, det beror på avtalet. Beskriv vilka uppdateringar som ingår och vilka funktioner eller moduler som kräver separat beställning.
Är support och garanti samma sak?
Inte nödvändigtvis. En garanti eller ett åtagande att rätta leveransfel kan ha en annan omfattning än löpande användarstöd. Dokumenten behöver förklara hur åtagandena förhåller sig till varandra.
Behöver en SaaS-tjänst ett separat supportavtal?
Supportvillkor kan ingå i kundavtalet eller beskrivas i en bilaga. En separat struktur kan vara praktisk om olika kunder köper olika supportnivåer.
Kan vi ta extra betalt för hjälp utanför omfattningen?
Reglera när extra ersättning kan bli aktuell och hur kunden godkänner arbetet. Kunden behöver kunna skilja inkluderad hjälp från en ny beställning.
Gör supporten tydlig redan i affären
Swedish Software erbjuder branschavtal och rådgivning kring avtalen. Det ger medlemsföretag stöd i att skapa tydliga villkor för återkommande leveranser.
Läs också:
Artikeln ger generell information och ersätter inte juridisk rådgivning i ett enskilt fall