Offert mjukvaruutveckling mall för tydliga kundförslag

En offert för mjukvaruutveckling ska göra det lätt för kunden att förstå vad som faktiskt köps, vad det kostar och vad som inte ingår. Det är särskilt viktigt i utvecklingsprojekt där ord som ”webbplats”, ”app” eller ”integration” kan betyda mycket olika saker för beställaren och leverantören.

Med en genomarbetad offert mjukvaruutveckling mall kan du beskriva projektet på ett enhetligt sätt och minska risken för missförstånd senare. Mallen på denna sida kan redigeras direkt i webbläsaren och exporteras till PDF eller Word när kundförslaget är klart.

Varför en tydlig offert är viktig i utvecklingsprojekt

Programvaruutveckling är ofta ett arbete som växer fram stegvis. Kunden kan ha ett affärsmål, men inte alltid en färdig teknisk kravspecifikation. Leverantören behöver därför översätta behovet till konkreta leveranser, antaganden och avgränsningar.

En offert är både ett säljdokument och ett underlag för ett eventuellt avtal. Den ska hjälpa kunden att jämföra alternativ och fatta beslut, men också ge båda parter en gemensam bild av uppdraget. Om offerten accepteras bör det vara tydligt på vilket sätt den blir bindande och om ytterligare avtal eller villkor ska gälla.

Avtal kan i många situationer uppstå genom anbud och accept enligt avtalsrättsliga principer. Läs lagtext och offentlig information hos Riksdagen om du behöver kontrollera rättskällor. I praktiken är det klokt att tydligt ange offertens giltighetstid och hur kunden ska acceptera den.

Detta ska en offert för mjukvaruutveckling innehålla

Det finns ingen universell offert som passar alla digitala projekt. En mindre insats för att rätta fel i ett befintligt system behöver mindre detaljnivå än utveckling av en ny kundportal. Grunduppgifterna bör dock alltid finnas med.

• Leverantörens och kundens namn, kontaktuppgifter och organisationsnummer när det är relevant.
• Offertnummer, offertdatum och hur länge erbjudandet gäller.
• En kort bakgrund som beskriver kundens mål och uppdragets syfte.
• Omfattning, leveranser och tydliga avgränsningar.
• Tidplan, milstolpar, beroenden och förutsättningar.
• Pris, moms, betalningsplan och eventuella kostnader utöver arvodet.
• Villkor för ändringar, testning, godkännande, rättigheter och sekretess.

Undvik att skriva att du ska leverera ”en komplett lösning” utan att definiera vad lösningen omfattar. Använd hellre punkter som går att kontrollera: antal vyer, specificerade funktioner, dokumentation, utbildning eller driftsättning.

Beskriv omfattning och leveranser utan otydlighet

Omfattningen är den del av offerten som oftast avgör om projektet blir lätt eller svårt att genomföra. Börja med kundens önskade resultat och skriv sedan vad leverantören konkret ska göra för att nå dit.

Formulera funktioner på rätt nivå

För en webbapplikation kan det vara relevant att beskriva exempelvis inloggning, behörighetsroller, formulär, rapporter, administrativa funktioner, integration med externa tjänster och responsiv utformning. Skriv inte bara ”användarhantering”; förklara vilka roller och basfunktioner som ingår.

Det är inte alltid lämpligt att låsa varje teknisk detalj i en offert. Men kunden ska kunna se vilka resultat som ingår. Ange gärna att tekniskt genomförande kan anpassas under projektet, så länge det inte ändrar den överenskomna funktionen, omfattningen eller priset utan en godkänd ändring.

Skriv också vad som inte ingår

Avgränsningar är inte negativa. De skyddar båda parter och gör det enklare för kunden att förstå vilka delar som behöver beställas separat. Vanliga avgränsningar kan vara innehållsproduktion, licenser, molntjänster, drift, support efter godkänd leverans, juridisk granskning, tillgänglighetsgranskning eller arbete med system som inte nämns i offerten.

Praktiskt tips: Låt varje viktig leverans kunna besvaras med frågan ”hur ser vi att den är klar?”. Om svaret är oklart behöver leveransen beskrivas mer konkret eller delas upp i mindre delar.

Välj prismodell och redovisa kostnaden öppet

Prissättningen ska spegla hur väl arbetet går att avgränsa. Fast pris kan vara enkelt för kunden, men förutsätter att omfattningen är tydlig. Löpande räkning ger större flexibilitet, men behöver kompletteras med uppskattning, rapportering och gärna en överenskommen arbetsram.

Skriv alltid om priser anges exklusive eller inklusive moms. För företag anges priser normalt exklusive moms, men det ska framgå tydligt. Specificera också om tredjepartskostnader tillkommer, till exempel för domän, driftmiljö, licenser, betaltjänster eller externa API:er.

Om du använder löpande räkning bör offerten ange timpris eller annan beräkningsgrund, hur arbetad tid redovisas och när fakturering sker. Undvik att kalla en tidig uppskattning för ett fast pris om den i verkligheten bara är en budgetbedömning.

Gör tidplanen realistisk och synlig

En bra tidplan visar inte bara när slutleveransen förväntas vara klar. Den beskriver också vilka steg som behöver ske på vägen och vad kunden behöver bidra med. Projekt försenas ofta när underlag, beslut, åtkomster eller test återstår hos kunden.

Exempel på relevanta milstolpar

• Startmöte och bekräftelse av krav eller prioriteringar.
• Godkännande av designförslag, teknisk inriktning eller prototyp.
• Utveckling av överenskomna funktioner.
• Testperiod och hantering av fel som omfattas av uppdraget.
• Kundens godkännande och överlämning.

Beskriv datum som preliminära om de förutsätter kundens medverkan eller externa leverantörer. Ange även vad som händer om kunden dröjer med material, behörigheter eller återkoppling. Då blir det tydligt att tidplanen bygger på gemensamt arbete, inte en ensidig utfästelse.

Hantera ändringar innan de blir tvister

Ändringsönskemål är normala i utvecklingsprojekt. Det som skapar problem är när de genomförs utan att parterna först är överens om konsekvenserna. Offerten bör därför ha en enkel rutin för ändringar.

1. Kunden beskriver ändringsönskemålet skriftligt.
2. Leverantören bedömer påverkan på omfattning, kostnad och tidplan.
3. Parterna godkänner ändringen skriftligt innan arbetet startar.
4. Offert, projektplan eller arbetsorder uppdateras vid behov.

Rutinen behöver inte vara tung. I små uppdrag kan ett tydligt e-postgodkännande räcka, om det framgår vad som har accepterats. Det viktiga är att den ursprungliga omfattningen och tillkommande arbete går att skilja åt.

Testning, godkännande och felrättning

En leverans bör inte betraktas som klar enbart för att koden har lagts upp på en server. Offerten bör ange hur kunden får möjlighet att testa, vilka acceptanskriterier som gäller och hur fel rapporteras. Anpassa nivån efter projektets storlek.

Beskriv exempelvis om kunden ska testa i en testmiljö, om det finns en överenskommen testperiod och vilken typ av avvikelser som ska rättas inom uppdraget. Skillnaden mellan fel och nya önskemål behöver vara tydlig: ett fel innebär att den levererade funktionen inte stämmer med överenskommen specifikation, medan en ny funktion normalt är en ändring.

För verksamheter som hanterar personuppgifter kan utvecklingen även beröra dataskydd. Kunden och leverantören bör klargöra roller, åtkomst och säkerhetskrav tidigt. Vägledning finns hos Integritetsskyddsmyndigheten, särskilt när en leverantör behandlar personuppgifter för kundens räkning.

Rättigheter, sekretess och drift

Frågor om immateriella rättigheter bör inte lämnas till slutet av projektet. Skriv vad kunden får använda efter betalning och om leverantören behåller rättigheter till befintliga komponenter, ramverk, verktyg eller generell kunskap. Om kunden ska äga eller få full nyttjanderätt till särskilt framtagen kod, design eller dokumentation bör detta formuleras klart.

Offerten bör också ange om drift och förvaltning ingår. Att leverera ett system är inte samma sak som att övervaka det, installera uppdateringar eller ge löpande användarstöd. Om efterföljande support erbjuds kan den beskrivas som en separat tjänst med egen omfattning och prissättning.

Exempel på sådant att reglera

• Vilket material kunden ansvarar för att tillhandahålla och ha rätt att använda.
• Vilka delar leverantören överlåter eller upplåter nyttjanderätt till.
• Om öppen källkod eller tredjepartstjänster används.
• Hur konfidentiell information ska hanteras.
• Om drift, backup, support och säkerhetsuppdateringar ingår eller beställs separat.

Så använder du mallen steg för steg

Den redigerbara mallen fungerar bäst när du fyller i den efter ett inledande samtal med kunden. Ha kravunderlag, anteckningar och prisberäkning till hands. Anpassa texten till den faktiska omfattningen i stället för att behålla generella formuleringar som inte passar uppdraget.

1. Fyll i kontaktuppgifter, offertnummer, datum och giltighetstid.
2. Sammanfatta kundens mål med ett kort och begripligt språk.
3. Lista leveranser och avgränsningar i separata punkter.
4. Välj prismodell och redovisa moms, betalningsvillkor samt externa kostnader.
5. Beskriv tidplan, beroenden, testning och kundens godkännande.
6. Lägg in villkor om ändringar, rättigheter, sekretess och eventuell support.
7. Kontrollera att alla belopp, datum och hänvisningar är korrekta innan du skickar offerten.

När texten är klar kan du redigera den direkt på sidan, skriva ut den eller exportera dokumentet till PDF eller Word. Spara gärna en kopia av den version som skickas till kunden, så att offertens innehåll går att följa upp vid en senare beställning.

Vanliga frågor

Är en offert för mjukvaruutveckling samma sak som ett avtal?

En offert är ett erbjudande och kan bli avtalsgrundande när kunden accepterar den enligt angivet sätt och inom angiven giltighetstid. Vid större eller mer komplexa projekt är det ofta lämpligt att komplettera med ett separat avtal och mer detaljerade villkor.

Ska jag ange fast pris eller timpris?

Välj fast pris när leveransen är tydligt avgränsad. Välj timpris eller löpande räkning när kravbilden kan förändras. En etappindelning kan vara ett bra mellanting, särskilt när projektet behöver utvecklas i flera beslutade steg.

Hur detaljerad måste omfattningen vara?

Den ska vara tillräckligt detaljerad för att kunden förstår vad som levereras och för att ni kan avgöra om arbetet är slutfört. För omfattande krav kan placeras i en bilaga eller separat specifikation som offerten hänvisar till.

Hur ska jag skriva om ändringsönskemål?

Ange att ändringar ska beskrivas skriftligt, bedömas av leverantören och godkännas av båda parter innan de genomförs. Skriv också att en ändring kan påverka pris, omfattning och tidplan.

Ingår källkod automatiskt i leveransen?

Nej, det bör inte förutsättas. Offerten eller avtalet behöver beskriva vilken rätt kunden får till källkod, dokumentation, design och annat material efter betalning.

Kan mallen användas för både appar och webbprojekt?

Ja. Anpassa leveranserna efter uppdraget, exempelvis mobilapp, webbapplikation, intern portal, integration eller vidareutveckling av ett befintligt system. Ta bort villkor som inte är relevanta och fyll i projektets egna förutsättningar.

Källor och referenser

• Avtalslagen (1915:218).
• Dataskyddsförordningen (EU) 2016/679.
• Riksdagen – lagar och andra författningar.
• Integritetsskyddsmyndigheten – vägledning om dataskydd.
• Verksamt – information för företag om avtal och affärsverksamhet.