POC design B2B avgör om ett test blir ett gemensamt lärande eller om du som säljchef råkar finansiera en leverantörs gratiskonsultation. Skillnaden syns sällan i demon – den syns i hur testet är avgränsat, hur beslut ska tas och vad som faktiskt ska bevisas.
I modern B2B-försäljning är POC ofta den punkt där affären antingen accelererar eller tappar fart. När en POC sväller i tid och innehåll händer två saker: köparen får ingen tydlig signal för beslut, och du tappar kontroll över både resursåtgång och affärslogik. Den här guiden hjälper dig att designa en POC som ger beslutsunderlag – inte merarbete.
Utgångspunkten är enkel: en POC ska reducera osäkerhet kopplad till ett beslut. Allt som inte reducerar osäkerhet är utanför testets uppdrag.
1) Börja med beslutet, inte med lösningen
En lärorik POC startar med frågan: vilket beslut ska kunden kunna ta när testet är klart? Inte ”vad vill ni prova?” utan ”vilket val ska ni kunna göra?”. Det tvingar fram en tydlig riktning och gör det enklare att säga nej till extra önskemål under resans gång.
Konkreta beslut kan till exempel vara att välja leverantör, välja integrationsväg, eller fastställa att en viss process faktiskt går att standardisera. Om kunden inte kan formulera beslutet är risken hög att POC blir en allmän behovskartläggning – och då är du redan på väg mot gratiskonsultation.
Sätt detta på papper i POC-beskrivningen: ”Efter POC ska vi kunna besluta X baserat på Y.” Det är grunden för bra POC design B2B och hjälper dig hålla samtalet på affär istället för teknikdetaljer.
2) Lås ett smalt scope som skyddar både tid och värde
Den vanligaste orsaken till att en POC spårar ur är otydligt scope. Ett smalt scope är inte ”mindre ambitiöst” – det är mer beslutsorienterat. Välj därför en begränsad process, en begränsad datamängd och en tydlig målgrupp för testet. Om kunden vill testa tre avdelningar, fyra integrationer och två användarfall samtidigt har ni i praktiken initierat ett projekt, inte en POC.
Arbeta med två tydliga avgränsningar:
– Vad som ingår: exakt vilka flöden, vilken data och vilka roller som deltar.
– Vad som inte ingår: sådant som ofta smyger in, till exempel utbildningspaket, generell processdesign, full datamigrering eller ”kan ni även titta på våra andra system?”.
En bra tumregel är att scope ska vara så smalt att du kan förklara det på 30 sekunder utan att använda interna produktord. Om du inte kan det, är testet för stort.
3) Sätt kriterier som går att mäta och som kopplar till affären
En POC utan kriterier skapar diskussioner, inte beslut. Kriterier ska vara få, mätbara och kopplade till den risk ni faktiskt ska eliminera. Undvik mål som ”känns bra” eller ”användarvänligt” om ni inte har en metod för att bedöma det.
Bygg kriterier i tre nivåer:
– Tekniska kriterier: fungerar dataflödet, prestanda, behörigheter, loggning.
– Processkriterier: kan användarna genomföra en uppgift med rimlig ansträngning inom ramen för testet.
– Affärskriterier: vad måste vara sant för att kunden ska vilja gå vidare, exempelvis tidsbesparing i ett steg, minskad risk eller kortare ledtid.
Koppla varje kriterium till hur det ska verifieras. ”Vi testar” räcker inte – definiera testfall, testdata och vem som signerar resultatet. Det är här POC design B2B skiljer sig från en ”pilot som pågår tills någon tröttnar”.
4) Designa POC som ett samarbete med tydliga roller och kostnad
Om kunden förväntar sig att du ska driva hela POC:n, skapa underlag, samla krav och föreslå framtida processer – då är det sannolikt konsultation. För att hålla POC på rätt sida behöver ni en enkel ansvarsfördelning: vem tillhandahåller data, vem har systemaccess, vem bokar användartester, vem fattar beslut när ni stöter på hinder.
Var tydlig med resursåtgång. En POC som är gratis kan fortfarande vara värdefull, men bara om båda parter investerar. Be kunden att namnge en intern sponsor och en operativ ansvarig. Om kunden inte vill avsätta tid är signalen ofta att POC:n inte är prioriterad – eller att de vill ”se vad ni kan göra” utan att själva binda upp sig.
En praktisk metod är att sätta en fast tidsbox, till exempel 2-4 veckor, och definiera exakt vilka möten som ingår. Tidsboxen gör att designen tvingas bli skarp, och den minskar risken för att scope utökas via små beslut som tas ad hoc.
5) Bygg in stoppunkter och en tydlig väg vidare
En lärorik POC behöver stoppunkter. Det kan låta hårt, men det skapar trygghet: om ni inte når kriterierna ska ni kunna avbryta utan att någon tappar ansiktet. Skriv därför in vad som händer vid tre utfall:
– Godkänd POC: nästa steg är ett kommersiellt förslag eller en implementeringsplan med pris och tidslinje.
– Delvis godkänd: vad justeras, och är det en ny POC eller ett betalt uppdrag.
– Underkänd: vad lärde ni er, och avslutas dialogen eller byter ni spår.
Den här delen är ofta där gratiskonsultationen maskerar sig. Om ni efter POC ska ”ta fram en mer detaljerad kravbild” eller ”rita framtida processer” utan att det finns en beställning, då har testet glidit från validering till leverans. En bra design gör överlämningen tydlig och kommersiellt rimlig.
Sammanfattat: en POC ska ha ett definierat beslut, ett smalt scope, mätbara kriterier och en tidsbox med ansvarsfördelning. När du gör det konsekvent blir POC design B2B ett verktyg som driver affären framåt istället för att äta upp säljteamets tid.
Nästa steg: ta din senaste POC-mall och skriv om den så att beslut, scope och kriterier står på första sidan – och låt inget annat få plats förrän det är tydligt.
