En effektiv RFP för webbprojekt beskriver mål, funktioner, integrationer, tidsplan, budget och styrning, och gör det möjligt att få jämförbara, träffsäkra offerter. De fem grundstenarna är projektmål, en tydlig funktionslista, definierade integrationer, en realistisk tidsplan och ett budgetintervall. Nästa steg är enkelt: samla en styrgrupp, sätt en svarstid på två till tre veckor och börja formulera user stories redan i dag.
Kort sagt:
- En komplett RFP bör tydligt ange projektmål, funktioner, integrationer, tidsplan och budget för att minska skillnader mellan offerter.
- Prioriteringsmetoder som MoSCoW och acceptanskriterier hjälper till att skilja viktiga funktioner från önskelistan och underlättar testbarhet.
- Integrationer med externa system är ofta den största kostnadsfaktorn och kräver konkret beskrivning av system, data och ansvar.
- En svarstid på två till tre veckor ger tid för noggranna offerter och bättre förberedelse, medan kortare perioder ofta leder till sämre underlag.
- En tydlig styrgrupp och definierade beslutsprocesser minskar risk för omprioriteringar och förenklar projektets styrning.
Innehållsförteckning
- Vad måste en rfp för webbprojekt innehålla?
- Så prioriterar och strukturerar du krav i rfp:en
- Tidsplan och milstolpar för webbprojektet
- Vilka tekniska krav driver upp kostnaden mest?
- Mall för user stories att kopiera in i din rfp
- Styrning: vem bestämmer vad under projektet?
- Frågor att ställa leverantörer
- Så går utvärderingen och urvalet av leverantörer till
- Vilka kriterier avgör om en offert är bra?
- Vanliga fallgropar i rfp-processen för webbprojekt
- Exempel på rfp-mallar för webbprojekt
- Författarens perspektiv
- Hur Hive Creatives hjälper dig genom hela rfp-processen
- Källor
- Vanliga frågor
Vad måste en rfp för webbprojekt innehålla?
En ofullständig RFP är den vanligaste orsaken till att offerter skiljer sig med hundratusentals kronor för samma projekt. Efter över 200 upphandlingar av webbprojekt konstaterar Webicient att många förfrågningar saknar avgörande information, vilket gör leverantörernas gissningar till en stor del av prissättningen. Ju mer du specificerar, desto mindre gissar leverantören, och desto mer träffsäker blir offerten.
En komplett kravspecifikation webb bör innehålla följande delar:
- Projektmål och affärs-KPI:er. Varför byggs webbplatsen? Är målet fler leads, högre konvertering i e-handeln eller minskad administration internt?
- Målgrupper och användarfall. Beskriv vem som ska använda sajten och i vilket sammanhang, exempelvis privatkunder på mobil eller inköpare på dator.
- Funktionslista och användarflöden. Lista varje funktion konkret, inte bara “bokningssystem” utan hela flödet från sökning till bekräftelse.
- Integrationer och beroenden. Ange vilka system som ska kopplas ihop, till exempel CRM, ERP, betalningslösning eller andra API:er.
- Tekniska krav. Hosting, prestandamål, säkerhetsnivå och GDPR-hantering hör hemma här, inte i ett separat dokument som skickas efteråt.
- Support och förvaltning. Vem ansvarar för drift efter lansering, och vilken svarstid gäller vid buggar eller driftstopp?
- Budgetintervall och debiteringsmodell. Ange ett spann, inte en exakt siffra, och säg om ni föredrar fast pris eller löpande timdebitering.
Tydlighet kring omfattning, funktioner, integrationer och tidsplan minskar spridningen mellan offerter och gör dem enklare att jämföra rakt av, enligt Swivrr. Den strukturen är själva poängen med en rfp webbyrå ska kunna svara på utan att behöva ringa fem gånger för att fråga vad du egentligen menade.
Så prioriterar och strukturerar du krav i rfp:en
Att lista tjugo funktioner utan inbördes ordning tvingar leverantören att gissa vad som är viktigast för er, och gissningar kostar pengar. Lös det med en tydlig prioriteringsmodell innan dokumentet skickas ut.
- Sortera kraven med MoSCoW. Dela in varje funktion i Must have, Should have, Could have och Won’t have denna gång. Det tvingar er att skilja kärnfunktioner från önskelistan.
- Skriv acceptanskriterier per funktion. Ett krav som “snabb sökfunktion” är omöjligt att testa. “Sökresultat visas inom 1 sekund vid 500 samtidiga användare” är mätbart och går att kontrollera vid leverans.
- Vikta utvärderingskriterierna innan offerterna kommer in. Bestäm i förväg hur mycket pris, tidsplan, teknisk lösning, erfarenhet och supportmodell ska väga i beslutet, till exempel 30 % pris, 25 % teknik, 20 % tidsplan, 15 % erfarenhet, 10 % support.
- Låt budgetintervallet filtrera tidigt. Ett angivet spann sorterar automatiskt bort leverantörer som inte matchar er nivå, vilket sparar tid för båda sidor. Att ange ett budgetintervall tidigt leder till fler relevanta och jämförbara offerter, enligt Webicient.
Proffstips: Skapa en enkel poängmatris i ett kalkylblad innan offerterna kommer in. Sätt vikterna först, poängsätt sedan varje leverantör utan att titta på totalsumman, så undviker ni att den leverantör ni “gillade mest” vinner på känsla istället för fakta.
Tidsplan och milstolpar för webbprojektet
En vanlig svarstid för offerter är två till tre veckor, vilket ger leverantörer tid att ställa frågor och räkna ordentligt istället för att chansa, enligt Webicient. Ett kortare fönster ger sämre offerter, inte snabbare projekt.
Ett webbprojekt går normalt igenom sex faser:
- Upptäckt. Workshops, kravanalys och teknisk förstudie.
- Design. Wireframes, UX-flöden och visuell design.
- Utveckling. Kodning av frontend, backend och integrationer.
- Test. Funktionstest, integrationstest och användartest.
- Lansering. Driftsättning, DNS-byte och slutkontroll.
- Drift. Löpande förvaltning, support och vidareutveckling.
Bygg in extra tid för integrationstest, det är nästan alltid den fas som drar ut mest. Lägg också en buffer för förändringshantering, eftersom nästan alla projekt får minst en scopeändring under vägen. Ange tydliga milstolpar med skriftlig acceptans, exempelvis “design godkänns skriftligt inom 5 arbetsdagar”, annars riskerar hela tidsplanen att glida utan att någon formellt sagt ja eller nej.
Vilka tekniska krav driver upp kostnaden mest?
Integrationer med externa system som CRM, ERP eller betalningslösningar är ofta den enskilt största kostnadsdrivaren i ett webbprojekt, eftersom oklara gränssnitt skapar dolda arbetstimmar som ingen budgeterat för. Var därför konkret redan i projektförfrågan webb:
- Ange exakt vilka system som ska kopplas ihop och vilken version eller vilket API som används.
- Specificera vilka datafält som ska överföras, hur ofta synkronisering ska ske och vad som händer vid fel.
- Beskriv ansvarsfördelningen: vem bygger API-anropen, vem mappar fälten och vem felsöker om synkroniseringen krånglar.
- Ange GDPR-krav för känsliga data, exempelvis var personuppgifter lagras och hur länge.
Att tydligt beskriva vem som ansvarar för API-leverans, fältmappning och felhantering minskar risken för dolda kostnader längre fram, enligt Swivrr. För komplexa integrationer är en kort teknisk förstudie på en till två veckor värd att prissätta separat innan den slutliga offerten läggs, det förhindrar feltolkningar i huvudanbudet.
Mall för user stories att kopiera in i din rfp
Formatet “Som {roll} vill jag {åtgärd} så att {nytta}” rekommenderas för att göra krav tydliga och lätta att testa, enligt Asana. Formatet gör krav mindre tekniska och mer konkreta, vilket förenklar både offertarbetet och den senare acceptanstestningen.
- Som besökare vill jag fylla i ett kontaktformulär för att kunna få svar snarast möjligt.
- Som återkommande kund vill jag logga in med sparade uppgifter så att jag slipper fylla i allt igen.
- Som kund vill jag lägga varor i kundvagn och betala med kort eller Swish så att köpet går snabbt.
- Som administratör vill jag se en dashboard med dagens order så att jag kan planera leveranser.
- Som marknadschef vill jag exportera trafikrapporter så att jag kan följa upp kampanjer.
- Som redaktör vill jag publicera nyheter utan hjälp av utvecklare så att innehållet hålls aktuellt.
Bryt ner varje story till tre till fem acceptanskriterier, till exempel: formuläret validerar e-postadress, ett bekräftelsemejl skickas inom en minut, och ett felmeddelande visas vid ofullständig ifyllnad.
Styrning: vem bestämmer vad under projektet?
En styrgrupp med en utsedd projektledare på kundsidan behövs för att godkänna delleveranser och hålla projektet inom krav och tid, enligt Projektforum. Utan det stannar beslut hos fel person, eller hos ingen alls.
- Sätt en styrgrupp med tre till fem personer: en beslutsägare, en teknisk kontaktperson och en representant för slutanvändarna.
- Definiera vad styrgruppen godkänner: design, scope-ändringar och budgetavvikelser, inte detaljer i varje knapp.
- Boka fasta avstämningar, till exempel varannan vecka, med kort skriftlig status efter varje möte.
- Utse en person med sista ordet vid oenighet, annars stannar små beslut i veckor.
Att ha styrgruppen på plats redan innan RFP:n skickas minskar risken för omfattningsändringar senare, eftersom besluts- och godkännandevägarna redan är satta, enligt Projektforum.
Proffstips: Skriv namnet på beslutsägaren direkt i RFP-dokumentet. En leverantör som vet exakt vem som godkänner offerten vågar prissätta mer aggressivt, eftersom risken för sena omprioriteringar känns lägre.
Frågor att ställa leverantörer
De frågor du ställer under upphandlingen säger nästan mer om kvaliteten än referenserna leverantören visar upp. Ställ frågor som tvingar fram konkreta svar, inte marknadsföring.
Fråga alltid om teamets sammansättning: vem är faktisk utvecklare på projektet, inte bara vem som säljer in det. Be om exempel på liknande projekt inom er bransch eller storlek, och fråga specifikt vad som gick fel i något av dem, ett ärligt svar säger mer än en perfekt referens.
Fråga hur leverantören hanterar scopeändringar under projektet: vilken process gäller, och vad kostar en extra funktion som dyker upp i vecka tre? Be om en tydlig beskrivning av vad som ingår i priset kontra vad som faktureras extra, särskilt kring integrationer, innehållsmigrering och testning.
Ställ frågor om drift efter lansering: vilken svarstid gäller vid akuta fel, finns en supportavtal med definierade nivåer, och vad kostar mindre ändringar efter att garantiperioden gått ut? Fråga också hur leverantören testar prestanda och säkerhet innan lansering, och be om konkreta mätvärden istället för allmänna löften.
Slutligen, fråga vem som äger koden och innehållet efter projektets slut. Det låter som en formalitet men avgör om ni kan byta leverantör senare utan att börja om från noll.
Så går utvärderingen och urvalet av leverantörer till
Utvärderingen bör ske i minst två steg för att undvika att första intrycket avgör hela beslutet. Första steget är en enkel avstämning mot måste-kraven: saknar en leverantör en grundläggande kompetens eller referens, sorteras den bort direkt oavsett pris.
De leverantörer som klarar första gallringen går vidare till en djupare bedömning där ni använder den viktade poängmatrisen från prioriteringsarbetet. Boka gärna ett kort möte eller en presentation med de två eller tre bästa kandidaterna innan slutgiltigt beslut, ett samtal avslöjar ofta mer om samarbetsförmåga än vad ett skriftligt dokument kan.
Kontrollera referenser aktivt, ring upp och fråga specifikt om projekt som liknar ert eget i storlek och komplexitet. Fråga referenspersonen om vad som var svårast i samarbetet, inte bara vad som gick bra. Jämför också hur väl varje leverantör faktiskt svarat på er ursprungliga RFP: en offert som ignorerar era frågor och bara skickar en standardpresentation är en varningssignal, oavsett hur fint priset ser ut.
Låt styrgruppen fatta det slutgiltiga beslutet gemensamt, men med en tydlig beslutsägare om rösterna går isär. Dokumentera varför ni valde den vinnande leverantören, det underlättar om frågor uppstår senare i projektet.
Vilka kriterier avgör om en offert är bra?
En bra offert svarar på precis det ni frågat, i samma struktur som RFP:n, utan att gömma undan viktig information i bilagor. Bedöm varje offert mot samma kriterier ni satte upp i prioriteringsarbetet.
Pris ska alltid ses i relation till vad som faktiskt ingår. En låg totalsumma som exkluderar integrationstest och drift är ofta dyrare i slutändan än en offert som redovisar allt från start. Jämför fast pris mot löpande debitering utifrån hur väl scope är definierat: ju osäkrare kraven är, desto rimligare blir löpande debitering.
Tidsplanen ska vara realistisk i förhållande till teamets storlek, inte bara optimistisk för att vinna affären. Fråga hur leverantören kommit fram till tidsestimatet, ett svar med konkreta arbetstimmar per fas väger tyngre än en rund siffra utan motivering.
Teknisk lösning bedöms utifrån hur väl den matchar era integrationskrav och framtida behov, inte bara vilken plattform som låter modernast. Erfarenhet värderas bäst genom konkreta, verifierbara referensprojekt snarare än allmänna beskrivningar av kompetens. Supportmodellen ska vara tydligt prissatt med definierad svarstid, en offert som lämnar drift som “diskuteras senare” är en ofullständig offert oavsett hur bra resten ser ut.
Vanliga fallgropar i rfp-processen för webbprojekt
Den vanligaste fallgropen är att skicka ut en RFP innan styrgruppen är på plats. Resultatet blir att offerter kommer in, men ingen har mandat att fatta beslutet, och processen fastnar i internpolitik istället för i leverantörsval.
En annan vanlig miss är att beskriva funktioner utan användarperspektiv, vilket tvingar leverantören att gissa vad “modernt admin-gränssnitt” faktiskt betyder i praktiken. Vaga krav ger vaga offerter, och vaga offerter ger obehagliga överraskningar i fakturan.
Att utelämna budgetintervall är ett tredje klassiskt misstag. Många tror att det ger bättre priser att hålla budgeten hemlig, men i praktiken leder det bara till att ni får offerter från fem helt olika prisnivåer och slösar tid på att jämföra äpplen med päron.
Integrationer beskrivs ofta alltför löst, “ska kopplas till vårt CRM” utan att ange vilket system, vilka fält eller vilken frekvens. Det är den enskilt vanligaste orsaken till att projekt spårar ur budget efter att kontraktet redan är signerat.
Slutligen missar många att sätta en tydlig svarstid och tappar därför kontrollen över processens tempo. Utan deadline kommer offerter in i en utdragen, ojämn takt som gör jämförelsen svårare för varje vecka som går.
Exempel på rfp-mallar för webbprojekt
En praktisk mall för rfp webb behöver inte vara lång, men den måste följa en fast struktur som gör det enkelt för leverantören att navigera. En fungerande grundmall innehåller följande avsnitt i ordning: bakgrund och mål, målgrupper, funktionslista prioriterad enligt MoSCoW, user stories för de viktigaste flödena, tekniska krav och integrationer, tidsplan med milstolpar, budgetintervall och debiteringsmodell, samt krav på support och förvaltning.
Lägg till ett kort avsnitt om hur offerten ska struktureras för att underlätta jämförelse, exempelvis “ange pris per fas, inte bara totalsumma” och “bifoga referensprojekt med kontaktuppgifter”. Det tvinga alla leverantörer att svara i samma format, vilket gör poängmatrisen från utvärderingen enkel att fylla i utan att behöva tolka fritt formulerad text.
En bra RFP-mall bör också innehålla ett tydligt avsnitt om hur frågor under anbudstiden hanteras, till exempel ett datum för sista frågedag och ett gemensamt frågor-och-svar-dokument som delas med alla leverantörer samtidigt. Det säkerställer att ingen leverantör får ett informationsövertag som snedvrider konkurrensen.
Författarens perspektiv
De flesta RFP:er vi ser saknar inte ambition, de saknar ägarskap. Tre återkommande fel: ingen utsedd beslutsägare, funktioner utan acceptanskriterier och integrationer beskrivna i en enda mening. Det vi uppskattar mest är motsatsen: tydlig teknisk information och en namngiven kontaktperson. Det ger snabbare projektstart och skarpare pris, för då slipper vi gissa.
— Peter
Hur Hive Creatives hjälper dig genom hela rfp-processen
Det finns möjlighet att få hjälp att formulera krav så att leverantörer kan prissätta träffsäkert, istället för att gissa sig fram genom en mall från nätet.
En RFP-workshop hos oss börjar med att gå igenom era mål och användarfall tillsammans, sedan bryter vi ner dem till user stories och tekniska krav som går att offerera mot. Vi hjälper till med kravanalys, webbutveckling av själva lösningen, och när sajten är i drift kan vi ta hand om SEO och löpande digital marknadsföring så att lanseringen faktiskt ger resultat, inte bara en ny design. Läs mer om hur vi arbetar som webbyrå om du vill förstå processen innan du bokar.
Boka en kostnadsfri första konsultation för att gå igenom era krav och få en second opinion på er kravspecifikation innan ni skickar ut den, se våra tjänster här.
Källor
- User stories — Asana
- Projektskolan — Projektforum
- Offertförfrågan för digitala tjänster — Swivrr
- Guide till RFP för webb — Webicient
Vanliga frågor
Vad ska en rfp för webbprojekt alltid innehålla?
Den ska innehålla projektmål, målgrupper, en prioriterad funktionslista, integrationer, tekniska krav, tidsplan, budgetintervall och krav på support efter lansering. Tydlighet i dessa delar minskar spridningen mellan offerter och gör dem mer jämförbara, enligt Swivrr.
Hur lång svarstid bör leverantörer få på en offertförfrågan?
En vanlig och rimlig svarstid är två till tre veckor, vilket ger leverantören tid att ställa frågor och räkna ordentligt, enligt Webicient. Kortare tid ger ofta sämre underbyggda offerter.
Varför är budgetintervall viktigt att ange i förfrågan?
Ett angivet budgetintervall filtrerar bort leverantörer som inte matchar er nivå redan innan offerter skickas in, vilket sparar tid för alla parter. Att ange intervallet tidigt leder till fler relevanta och jämförbara svar, enligt Webicient.
Vad är user stories och varför används de i en rfp?
User stories är krav skrivna i formatet “Som {roll} vill jag {åtgärd} så att {nytta}”, vilket gör krav lättare att testa och förstå för både beställare och leverantör, enligt Asana. De omvandlas sedan till konkreta acceptanskriterier som går att bocka av vid leverans.
Kan Hivecreatives hjälpa till med att skriva rfp:n?
Ja, Hivecreatives hjälper företag att formulera kravspecifikationen, bryta ner den till user stories och tekniska krav, och kan sedan genomföra själva webbutvecklingen om ni väljer det. Aktuella priser för tjänsterna finns listade på webbplatsen.
