Hvad I skal skrive i et web-udbud — så I kan sammenligne

Et udbud, I ikke kan sammenligne, koster uger efter I har valgt. Det ene tilbud er et tema. Det andet er et custom Next.js-site. Det tredje er 'vi finder ud af det i workshop'. I vælger på prisfornemmelse og kemi, og opdager i uge fire, at I har købt tre forskellige produkter. I tror I har et leverandørproblem. I har et dokumentproblem.

Teams skriver den forkerte spec. De specificerer slider, antal skabeloner og CMS-navn, fordi det er konkret. De glemmer hvem sitet er til, hvad der skal være sandt på lancering, og hvad der allerede findes. Så får I tre løsninger, der alle 'opfylder kravspecen', og ingen af dem kan I lægge ved siden af hinanden. Det konkrete var det forkerte konkrete.

Det er også et SEO- og ejerskabs-spørgsmål. Hvis udbuddet ikke siger, at URL'er skal leve, at I ejer DNS, og at I skal kunne skifte leverandør, så byder folk på et site, I ikke kan flytte. Hvis det ikke siger, hvem indholdet kommer fra, byder folk på tomme skabeloner. Kravspecen er det første sted, I enten tager ejerskab — eller giver det væk.

Vi skriver det, fordi 'kravspecifikation website' er blevet en PDF, I kan sende, før I har en sætning om lanceringen. Et ærligt udbud er kedeligt: målgruppe, lanceringssandheder, det I har, det der er ude, hvordan I beslutter, og at discovery må sige nej til jeres yndlings-stack. Uden den sætning har I en ønskeseddel. I har ikke et udbud, I kan forsvare over for en bestyrelse.

Et web-udbud er et dokument, der stiller det samme spørgsmål til flere parter: kan I få de her sandheder til at holde på en lancering, med det her I allerede har, og med det her ude? Svaret må være en løsning. Spørgsmålet må ikke være en. Når spørgsmålet allerede siger WordPress og 12 skabeloner, har I ikke bedt om råd. I har bedt om en pris på en beslutning, I ikke har testet.

En kravspecifikation er listen over det, der skal være sandt — ikke listen over widgets. 'En redaktør kan udgive en artikel uden en udvikler' er et krav. 'Vi vil have Gutenberg og et slider-plugin' er en løsning. 'Produktet kan vises på dansk og engelsk med samme URL-logik' er et krav. 'Vi har valgt et headless CMS' kan være rigtigt — hvis I kan sige hvorfor, og hvis I tillader at svaret er nej.

Det er heller ikke en kontrakt. Udbuddet skal gøre tilbud sammenlignelige. Kontrakten kommer bagefter, når I har valgt, og når discovery har skåret. At bede om en fast løsning på en ønskeseddel, I selv er i tvivl om, er hvordan I får et billigt-set tilbud, der sprækker når indholdet kommer. Bureau-spørgsmålene tester partneren. Udbuddet tester om I har stillet det samme spørgsmål.

Og det er ikke discovery. En uge der producerer beslutninger, kommer når I har valgt nogen, I tør sidde i rum med. Udbuddet kommer før. Hvis I prøver at få discovery til at ske i PDF'en, får I en spec, ingen kan estimere — præcis det, discovery-ugen er sat i verden for at erstatte. Skriv nok til at I kan sammenligne. Skriv ikke så meget, at I har låst det, I ikke har set.

Den første fejl er at liste features, I har samlet fra tre andre sites. 'Nyhedsbrev, chat, blog, cases, login, shop, portal, booking.' Det er fem produkter. Et ærligt udbud siger hvilket ét der skal være sandt på lancering, og hvilke der er fase to. Uden den skæring byder folk på det, de er gode til, ikke på det I har brug for.

Den anden fejl er at skjule det, I allerede har. Domæne, Search Console, cookie-setup, et PIM, en mail-liste, en webshop der skal leve, en PDF med 80 sider copy. Hvis det ikke står i udbuddet, gætter tilbuddene. Gæt bliver til tillæg. Skriv inventaret. Skriv også hvad I ikke har — 'ingen billeder, ingen produkttekster, DNS står hos en tidligere leverandør'.

Den tredje fejl er at glemme ude-listen. 'Ikke en webshop i den her omgang.' 'Ikke et intranet.' 'Ikke at I hoster vores mail.' Uden ude bliver hvert tilbud et andet scope. Med ude kan I se, hvem der respekterer kanten, og hvem der sælger jer et ekstra produkt i samme PDF.

Den fjerde fejl er at bede om pris på det, I ikke har skåret, og så sammenligne tallene som om de var det samme arbejde. Vi skriver ikke priser her — og I bør ikke beslutte på et tal, dokumentet ikke har gjort sammenligneligt. Sammenlign hvad de har forstået, hvad de har sagt nej til, og om de tør flytte stakken. Tallet kommer i samtalen, når scope er det samme.

Et formelt udbud — kommune, region, en indkøbsramme — har skabeloner, I ikke kan smide. Så skal I stadig skrive lanceringssandheder og ude-listen ind i det rum, skabelonen giver. Hvis skabelonen tvinger et CMS-navn, så skriv hvorfor, og bed om et afvigelses-svar. Et udbud der kun kan vinde ved at nikke, får nikkende sites.

En SMV der sender en mail til tre bureauer, har ikke brug for 20 sider. I har brug for de fem trin ovenfor på to sider. Et moodboard må følge med som smag, ikke som krav. 'Vi kan lide det her site' er fint. 'Byg det her site' er hvordan I betaler for en kopi, I ikke kan eje. Lad stemningen være input. Lad sandhederne være kravet.

SEO hører til som sandheder, ikke som et plugin-navn. 'Vi skal kunne holde URL'er ved relancering.' 'Vi skal have ærlig title og description pr. side.' 'Vi vil kunne se Search Console selv.' Det er krav. 'Vi vil have et SEO-plugin og 500 blogposts' er en løsning, og ofte den forkerte. Relancering uden at miste placeringer er et andet indlæg. Her skal udbuddet bare ikke gøre tabet til standard.

Hvis I allerede har valgt bureau med kemi, har I ikke brug for et teater-udbud. I har brug for de samme sandheder i et brief, så I ikke opdager scope i uge fire. Dokumentet er ikke et ritual. Det er den eneste måde I og de kan pege på det samme 'færdigt'. Uden det er samtalen hyggelig, og kontrakten er et håb.