Da jeg jobbet i StarLeaf, lærte jeg hvor avgjørende en god demo og en strukturert Proof of Concept, ofte forkortet PoC, kan være for å vinne riktige kunder. Når du selger en premiumløsning i øvre prisklasse, holder det ikke å bare si at løsningen fungerer. Kunden må få kjenne på det selv, i sin egen hverdag, med sine egne brukere, krav og interne prosesser.
En PoC har til hensikt å finne ut om kunden faktisk er riktig for leverandøren, like mye som om leverandøren er riktig for kunden. En god PoC er derfor ikke en gratis prøveperiode med litt teknisk pynt på toppen. Det er en gjensidig evaluering, der begge parter får testet om løsningen, samarbeidet og forventningene henger sammen.
PoC er mer enn en teknisk test
Mange tenker på en PoC som en måte å bevise at produktet fungerer. Det er bare halve bildet. I praksis handler en god PoC like mye om å redusere risiko, bygge tillit og avdekke om organisasjonen er klar for å ta løsningen i bruk.
Teknologien kan fungere perfekt, men PoC-en kan likevel feile dersom feil personer er involvert, målene er uklare, eller kunden ikke har avklart hva som faktisk skjer etter testen. Det er ofte ikke produktet som velter prosessen. Det er alt rundt.
Tillit er blitt viktigere
Salesforce skriver i State of the AI Connected Customer at 61 % av kundene mener utviklingen innen AI gjør det enda viktigere at selskaper er til å stole på. 72 % sier også at det er viktig å vite om de kommuniserer med en AI-agent. Selv om dette handler om AI, peker det på noe større: Kunder ønsker å forstå hva de går inn i, hvem de forholder seg til, og om leverandøren er åpen nok til å fortjene tillit.
Derfor bør en PoC starte før selve testen
En PoC bør ikke starte med installasjon, teknisk oppsett eller en kalenderinvitasjon. Den bør starte med avklaringer. Hva skal testes? Hvem skal evaluere? Hva betyr suksess? Hva skjer hvis testen lykkes? Og kanskje like viktig: Har kunden faktisk forstått prisbildet før testen begynner?
Jeg lærte tidlig at en PoC uten avklart økonomi fort kan bli en gratis konsulentjobb. Når kunden først har sett og akseptert rammene for pris, leveranse og videre prosess, blir testen mer realistisk. Da tester man ikke bare en idé. Man tester et mulig samarbeid.
Fem steg til en bedre PoC
1. Finn de riktige personene hos kunden
En PoC blir sjelden bedre enn menneskene som er involvert. Derfor må de riktige rollene med fra starten. Beslutningstakere må forstå hvorfor testen gjennomføres. Prosjektleder eller avdelingsleder må sikre intern forankring. Tekniske ressurser må kunne vurdere integrasjoner, sikkerhet og praktisk gjennomføring. Brukerne må faktisk bruke løsningen slik den er ment brukt.
Hvis bare teknisk avdeling tester løsningen, kan du få et teknisk ja og et organisatorisk nei. Hvis bare ledelsen er involvert, kan du få et strategisk ja og et praktisk nei. En god PoC må treffe begge deler.
2. Definer mål, delmål og suksesskriterier
En PoC uten tydelige mål blir fort en subjektiv smakstest. Noen liker løsningen. Andre synes den var uvant. En tredje person fikk ikke logget inn første dag og konkluderer med at alt var håpløst. Da har man ikke testet godt nok. Man har bare samlet inn tilfeldige reaksjoner.
Før testen starter, bør kunden og leverandøren bli enige om hva som faktisk skal måles. Er målet bedre brukeropplevelse, enklere administrasjon, høyere stabilitet, bedre sikkerhet, lavere supportbehov eller raskere utrulling? Jo tydeligere kriteriene er, desto lettere blir det å vurdere resultatet etterpå.
B2B-kjøp er sjelden lineære
Gartner beskriver moderne B2B-kjøp som en ikke-lineær prosess der kjøpere beveger seg mellom problemforståelse, utforsking av løsninger, kravbygging og valg av leverandør. Usikkerhet, interne prosesser og flere interessenter gjør kjøpsreisen mer kompleks. En PoC kan derfor fungere som et felles holdepunkt, så lenge den har tydelige mål og en avklart vei videre.
3. Lag en teststruktur som speiler virkeligheten
En PoC bør ikke designes for å få produktet til å se best mulig ut. Den bør designes for å finne ut om løsningen fungerer i kundens faktiske hverdag. Det betyr at testen må inkludere realistiske brukstilfeller, relevante brukergrupper og tydelige scenarioer.
En god teststruktur bør vise hva som skal testes, hvem som har ansvar, hvordan tilbakemeldinger skal samles inn, og hvilke kriterier som avgjør om testen er vellykket. Da blir PoC-en mer enn en demonstrasjon. Den blir et beslutningsgrunnlag.
4. Synkroniser forventningene før testen starter
En av de vanligste feilene er å behandle PoC-en som et isolert prosjekt. Det er den sjelden. Hos kunden kan testen være knyttet til sikkerhetsvurderinger, budsjettprosesser, intern opplæring, IT-arkitektur, eksisterende avtaler eller politiske hensyn internt i organisasjonen.
Derfor bør man snakke om hva som skjer dersom testen er vellykket:
- Hvem tar beslutningen?
- Når kan en eventuell implementering starte?
- Hvilke ressurser må være tilgjengelige?
- Finnes det interne prosesser som kan stoppe eller forsinke veien videre?
5. Følg opp underveis, ikke bare etterpå
En PoC bør ikke være noe leverandøren setter i gang og deretter håper går bra. Jevnlig kontakt underveis er avgjørende. Ikke for å mase, men for å fange opp små problemer før de blir store irritasjoner.
Tilbakemeldinger underveis er ofte mer verdifulle enn en sluttrapport. Det er da du ser hvor brukerne stopper opp, hva de faktisk forstår, hva de misforstår, og hvilke behov som ikke kom tydelig frem i salgsprosessen.
Kundeinnsikt er strategisk
McKinsey fremhever at kundeinnsikt hjelper selskaper med å forstå skiftende behov, markedsetterspørsel og hvordan produkter og tjenester oppleves. I en PoC får man denne innsikten direkte fra kundens faktiske brukssituasjon. Det gjør testen verdifull både for salg, implementering og videre produktutvikling.
Vanlige feil som ødelegger en PoC
En PoC feiler sjelden bare fordi teknologien er dårlig. Ofte feiler den fordi rammene rundt testen er for svake. Her er noen av feilene jeg har sett gå igjen:
- Uklare mål: Ingen vet egentlig hva som skal bevises.
- Feil deltakere: De som tester løsningen, er ikke de som skal bruke eller beslutte den.
- Manglende prisavklaring: Kunden liker løsningen, men får prissjokk etterpå.
- Ingen plan for neste steg: Testen lykkes, men prosessen stopper fordi ingen vet hva som skjer videre.
- For bred test: Man prøver å teste alt samtidig og ender opp med å lære lite om det som faktisk betyr mest.
Hva skjer etter en vellykket PoC?
Hvis PoC-en oppfyller suksesskriteriene, bør neste steg allerede være kjent. Da handler det ikke om å starte en ny diskusjon fra bunnen av, men om å gå videre med implementering, avklaringer og praktisk gjennomføring.
Det er her mange mister fart. Man feirer en vellykket test, men glemmer at kunden fortsatt kan mangle interne ressurser, budsjettgodkjenning, sikkerhetsavklaring eller en konkret utrullingsplan. En god PoC avsluttes derfor ikke bare med «testen var vellykket». Den avsluttes med en tydelig forståelse av hva som skjer videre.
En PoC tester også relasjonen
For meg er det viktigste poenget at en PoC ikke bare tester produktet, men også samarbeidet. Kunden får se hvordan leverandøren følger opp, håndterer problemer og lytter til tilbakemeldinger. Leverandøren får samtidig se hvordan kunden prioriterer, kommuniserer og involverer egne folk.
Det er litt som å prøvekjøre en bil. Du tester ikke bare om bilen starter. Du kjenner etter om den passer deg, om du stoler på den, og om du faktisk kan se for deg å bruke den i hverdagen.
Hvorfor lar så få digitale tjenester deg teste det du faktisk skal kjøpe?
Mange apper og digitale tjenester tilbyr riktignok en gratisversjon, men ofte er det bare en begrenset smakebit. Funksjonene som faktisk avgjør om løsningen passer behovet ditt ligger gjerne bak en betalingsmur eller et abonnement.
Jeg har selv opplevd flere ganger å betale for en fullversjon, bare for å oppdage at opplevelsen ikke var slik jeg hadde sett for meg. Da sitter man igjen med følelsen av å ha kjøpt noe man egentlig ikke fikk testet ordentlig først.
Det er litt spesielt når vi tenker over det. Vi prøver bilen før vi kjøper den, vi prøver klær før vi går til kassen, og vi smaker gjerne på maten før vi bestiller mer. Samtidig forventes det ofte at vi skal abonnere på digitale løsninger uten å få oppleve det som faktisk skiller gratisutgaven fra produktet vi betaler for.
Jeg tror flere leverandører hadde oppnådd høyere kundetilfredshet ved å tenke mer som en god PoC som gir kundene en realistisk mulighet til å forstå hva de faktisk kjøper.
Kilder
- Salesforce, State of the AI Connected Customer, 7th edition.
- Gartner, B2B Buying Journey.
- McKinsey, Customer Insights.
