Tio misstag vi ser i upphandlingar av hemsidor

De flesta webbprojekt som går fel gör det innan byrån är vald.

Vi har arbetat med webbprojekt i mer än tjugo år och läst fler kravspecifikationer än vi kan räkna. Vissa är tydliga och genomtänkta. Många är det inte. Och de som inte är det brukar falla på samma sätt, oavsett bransch, storlek eller om upphandlingen är offentlig eller privat.

Den här genomgången handlar om de misstagen. Inte för att peka på beställare — ofta är det vi byråer som borde ha ställt frågorna tidigare — utan för att de går att undvika, och för att de kostar mer än någon räknar med.

1. Ni börjar med lösningen i stället för målet. Skriv målet först och låt varje funktion motivera sig mot det.
2. Ni ber om offert på något som inte är bestämt. Rita flödet innan ni upphandlar.
3. Kravspecifikationen blir för stor för tidigt. Spika mål, budget, flöden, integrationer och lagkrav. Lämna utformningen öppen.
4. Önskelistan från ChatGPT. Fråga vem hos er som behöver varje krav. Det krav ingen kan svara på stryks.
5. Sidan 3 säger en sak, sidan 5 något annat. Låt en person läsa hela dokumentet i ett svep innan det skickas.
6. Tre personer, tre kravspecifikationer, ett dokument. Utse en person som äger dokumentet och har mandat att säga nej.
7. Ni vill ha fast pris på en lös beskrivning. Skriv en tydlig kravspecifikation, eller köp en förstudie först.
8. Kraven har ingen förankring i hur ett webbprojekt går till. Låt dem som ska arbeta med webbplatsen läsa kraven innan upphandlingen skickas.
9. Priset väger tyngst. Jämför totalkostnaden över tre år, inklusive förvaltning och vidareutveckling.
10. SEO hanteras för sent. Inventera det som fungerar i dag och planera omdirigeringarna innan designen börj

Nästan alla misstag nedan är varianter av samma sak:

Byrån ska räkna på projektet när den vet som minst.

En kravspecifikation är tänkt att minska osäkerheten i ett projekt. Allt för ofta flyttar den i stället osäkerheten till byrån. Byrån kan då svara på tre sätt: gissa lågt och ta igen det senare med tilläggsarbeten, gissa högt och lägga in en säkerhetsmarginal, eller tacka nej.

Beställaren förlorar på alla tre.

Vi har delat in misstagen efter var i processen de görs: innan dokumentet skrivs, i själva dokumentet, när anbuden bedöms och när den gamla webbplatsen ska ersättas.

Kravspecifikationen handlar om funktioner: vi vill ha en slider och en chatt. Den säger inget om vad webbplatsen ska åstadkomma — fler förfrågningar, färre samtal till kundtjänst, högre konvertering i butiken.

Det är begripligt. Funktioner är konkreta och lätta att peka på hos en konkurrent. Mål kräver att man först bestämt sig för vad webbplatsen är till för.

Men utan mål bygger byrån det som beställts, inte det som behövs. Och det går inte att mäta om den nya webbplatsen blev bättre än den gamla, eftersom ingen bestämt vad en konvertering är eller vem som ska sätta upp mätningen.

Gör så här: skriv målet först och låt varje funktion motivera sig mot det. Chatten ska finnas för att den minskar antalet samtal till kundtjänst, inte för att konkurrenten har en. Skriv in mätningen i samma avsnitt: vilka verktyg, vilka konverteringar, vem som ansvarar.

Detta ger möjlighet för blivande byrån som dagligen arbetar med detta att komma med förslag och hitta lösningar som ni eventuellt inte kände till.

Ni ber om offert på tjänster ni inte själva vet om ni behöver. Flödet på webbplatsen är inte bestämt: vad ska besökaren göra, vart tar förfrågan vägen, vad ska kopplas till vad?

Det händer ofta när en budget eller en deadline driver på, och upphandlingen startar innan det interna arbetet är klart.

Problemet är att integrationerna — kopplingen till CRM, affärssystem, bokning eller lager — är det dyraste och mest riskfyllda i ett webbprojekt. När de är okända räknar byrån på en webbplats som kanske inte blir den som ska byggas.

Gör så här: rita flödet innan ni upphandlar. Det behöver inte vara snyggt. Besökaren kommer hit, gör det här, och då händer det här i vårt CRM. Går flödet inte att rita är ni inte redo att be om ett fast pris, då bör det vara en faktor som byrån får ta fram offert för senare i projektet tillsammans med er.

Motsatsen finns också. Allt ska spikas i förväg i en tjock kravspecifikation: varje sida, varje fält, varje knapp. Det känns tryggt, och i offentliga upphandlingar är det ofta ett krav.

Men då låses projektet innan någon besökare har testat något. Det finns inget utrymme att lära av användartester och ändra riktning, och varje ändring blir ett tilläggsarbete. Webbplatsen byggs efter hur man trodde att besökarna skulle bete sig, inte efter hur de faktiskt gör.

Gör så här: spika det som inte får ändras — mål, budget, flöden, integrationer och lagkrav. Lämna utformningen öppen, och skriv in att den ska testas och får justeras.

Allt fler kravspecifikationer vi får är i stort sett skrivna med ChatGPT. De ser proffsiga ut, täcker allt och är välformulerade. Men ingen hos beställaren kan förklara varför kraven finns eller vilka som faktiskt behövs.

AI är ett bra stöd, och vi använder det själva varje dag. Men det svarar på frågan vad kan en webbplats ha, inte vad behöver vi. När varje krav ser lika viktigt ut räknar byrån på alla. Offerten blir dyrare än behovet, eller så stryks fel saker när budgeten inte räcker.

Gör så här: använd gärna AI för att få med allt, men gå igenom varje krav och fråga: vem hos oss behöver det här, och vad händer om vi inte har det? Det krav ingen kan svara på stryks.

Kravspecifikationen motsäger sig själv. Ett avsnitt vill ha ett enkelt system som marknadsavdelningen sköter själv, ett annat kräver integrationer som bara en utvecklare kan underhålla. Budgeten på en sida passar inte funktionerna på nästa.

Det händer när ett dokument vuxit under lång tid och ingen läst det från början till slut innan det skickats. Byrån får då välja tolkning, och olika byråer väljer olika. Resultatet är offerter som inte går att jämföra.

Gör så här: låt en person läsa hela dokumentet i ett svep innan det skickas. Varje krav som krockar med ett annat stryks eller prioriteras.

En gång var en kravspecifikation så svår att förstå att vi fick använda AI för att sammanfatta den och lista ut vad kunden ville ha. Det visade sig att tre personer hade skrivit var sin kravspecifikation i samma dokument, utan att någon sammanfogat dem.

Ingen var utsedd att äga dokumentet. Alla bidrog, ingen bestämde. Byrån fick gissa vems krav som gällde, och den som skrivit minst tydligt riskerade att få minst av det den behövde.

Gör så här: utse en person som äger kravspecifikationen och har mandat att säga nej. Och ett enkelt test: om ni själva behöver en sammanfattning för att förstå dokumentet kommer byrån också att behöva det. Skriv den själva och skicka med den.

Beskrivningen är några rader lång, men ni vill ha ett fast pris. Samtidigt är kraven på byrån höga: referenser, garantier, tidsplan.

Det här är den gemensamma nämnaren i sin renaste form. Ett fast pris kräver en fast beskrivning. Utan den blir priset antingen en gissning eller en säkerhetsmarginal som ni betalar för.

Gör så här: välj ett av två. Lägg tid på en tydlig kravspecifikation, eller köp en förstudie först och be om fast pris efteråt. Båda är billigare än att betala för byråns osäkerhet.

Det här ser vi framför allt många gånger i offentliga upphandlingar. Kraven på leverantören och på projektet är teoretiska. De är formulerade för att vara heltäckande och juridiskt säkra, inte utifrån hur ett webbprojekt faktiskt genomförs.

Ofta skrivs upphandlingen av en upphandlare eller utifrån en mall, inte av dem som ska använda webbplatsen varje dag. Byråer som skulle passa bra sorteras då bort på formalia. Den som vinner har visat att den kan skriva anbud, inte nödvändigtvis att den passar för uppdraget som skall byggas eller förvaltas.

Gör så här: låt dem som ska arbeta med webbplatsen läsa kraven innan upphandlingen skickas. Varje krav ska gå att koppla till ett verkligt behov.

Lägsta anbud vinner. Priset jämförs, men inte vad som ingår, vad som händer efter lansering eller hur länge plattformen håller.

Priset är det enda som är lätt att jämföra, särskilt när kravspecifikationen är lös och anbuden svarar på olika saker. Men det lägsta anbudet blir ofta dyrare i längden: genom tilläggsdebiteringar för det som inte stod i offerten, genom sämre kvalitet, eller genom en plattform som måste bytas ut efter ett par år.

Många kravspecifikationer slutar dessutom på lanseringsdagen. De säger ingenting om vem som uppdaterar, säkerhetskopierar och svarar när något går sönder.

Gör så här: jämför totalkostnaden över tre år, inklusive förvaltning och vidareutveckling. Och ställ en enkel fråga till varje leverantör: vad händer om webbplatsen går ner en fredagskväll? Svaret säger mycket om hur seriöst byrån tar drift och säkerhet.

Vid byte av webbplats tappar många sin trafik från Google. Ingen har planerat omdirigeringar, adresstruktur eller hur innehållet som rankar i dag ska flyttas med.

SEO ses som något man gör efter lanseringen, inte som en del av bygget. Kravspecifikationen beskriver den nya webbplatsen men säger ingenting om den gamla. Trafiken kan då rasa redan veckan efter lansering och ta lång tid att få tillbaka, om den kommer tillbaka alls.

Det är ofta det dyraste misstaget av alla, och det syns sist.

Gör så här: kräv en inventering av det som fungerar i dag, sidor som rankar, sökord ni syns på, formulär som konverterar. Kräv en plan för omdirigeringar och adresser innan designen börjar. Släng inte ut barnet med badvattnet.

Misstag 3 och 7 ser ut att säga emot varandra. En kravspecifikation kan vara för detaljerad, och den kan vara för lös.

Det är ingen motsägelse. Problemet är inte hur lång kravspecifikationen är, utan vad den låser.

En bra kravspecifikation är fast på vad webbplatsen ska åstadkomma och vad den ska kopplas till, och öppen på hur den ska se ut. De flesta gör tvärtom: lösa mål och detaljerade funktioner.

Det vore enkelt att lägga allt ansvar på beställaren. Men många av misstagen ovan fortsätter för att vi byråer låter dem fortsätta.

Vi borde ställa frågorna tidigare: vad är målet, hur ser flödet ut, vem äger beslutet? Vi borde säga nej till att räkna fast pris på något som inte går att räkna på, i stället för att gissa och hoppas. Och vi borde oftare föreslå en förstudie, även när det betyder att offerten dröjer.

En upphandling blir bättre när båda parter vet vad som ska byggas innan priset sätts. Det är egentligen hela poängen med denna listan.

Vad ska en kravspecifikation för en hemsida innehålla?
Syfte och mål, funktionalitet, design och användarvänlighet, SEO och prestanda, innehåll, mätning, tidsplan och budget, juridiska krav, intern projektorganisation samt förvaltning och support. Viktigast är att målen och integrationerna är tydliga. Utformningen kan lämnas öppen.

Hur lång ska en kravspecifikation vara?
Så lång som behövs för att mål, flöden, integrationer och lagkrav ska vara entydiga, och inte längre. En tjock specifikation som låser utformningen i detalj gör projektet dyrare att ändra när ni lär er något nytt.

När behövs en förstudie?
När ni vill ha ett fast pris men inte kan beskriva flödet på webbplatsen eller vilka system den ska kopplas till. En förstudie tar fram det underlag som gör att byrån kan räkna på riktigt.

Kan man använda ChatGPT för att skriva en kravspecifikation?
Ja, som stöd för att inte glömma något. Men varje krav måste kunna motiveras av någon hos er. AI vet vad en webbplats kan ha, inte vad just ni behöver.

Hur jämför man anbud från olika webbyråer?
Jämför totalkostnaden över tre år, inte bara projektpriset. Titta på vad som ingår efter lansering, hur byrån ställer frågor om ert behov, och vilka personer som faktiskt ska arbeta i projektet.

Står ni inför en upphandling? Vår guide Upphandling av hemsida går igenom hela processen, med en checklista över de tio områden en kravspecifikation ska täcka. Ladda ner guiden