| Alternativ | Omfang | Forutsetning og avveining | Kontrollpunkt |
|---|---|---|---|
| Beholde dagens rutine | Fortsette med e-post og muntlige påminnelser. | Ingen innføring, men uklart ansvar for godkjenning består. | Kunden vurderer om risikoen ved neste oppstart er akseptabel. |
| Avklart bestillingsrutine | Avtale felter, godkjenner og frister; teste ved neste oppstart. | Kunden må navngi godkjenner og sende komplett bestilling i tide. | Kontorleder og leverandør kontrollerer avtalte tilganger før start. |
| Ny bestillingsløsning | Innføre verktøy, tilgangsstyring og opplæring. | Krever budsjett og innføringsarbeid. Bør begrunnes med flere behov enn én forsinkelse. | Test krav til godkjenning og bestilling før en eventuell større utrulling. |
Løsningssalg: Metode og et konkret B2B-eksempel
Se hvordan løsningssalg kobler et bekreftet behov til riktig leveranse. Få et B2B-eksempel med alternativer, omfang og kriterier for resultatet.
Oppdatert · Av Aventra6 min lesetid
Innhold
Hva er løsningssalg?
Løsningssalg er en salgsmetode der dere tar utgangspunkt i kundens problem og ønskede resultat før dere foreslår en leveranse. Målet er å koble et bekreftet behov til en løsning kunden kan vurdere, med tydelig omfang, forutsetninger og ansvar. Et langt produktforedrag blir ikke løsningssalg bare fordi det avsluttes med en anbefaling.
Metoden er særlig nyttig når flere valg påvirker resultatet: arbeidsmåte, integrasjoner, opplæring, leveransekapasitet eller roller hos kunden. Ved et enkelt og avklart standardkjøp kan en omfattende kartlegging være unødvendig. Tilpass undersøkelsen til usikkerheten og konsekvensen av å velge feil.
Behovsanalyse handler om å forstå situasjonen. Løsningssalg tar arbeidet videre til å velge hva som bør gjøres. Derfor må også leveranseansvarlig få vurdere forslaget før selgeren lover et resultat.
1. Bekreft problem, konsekvens og prioritet
Start med en konkret hendelse og dagens arbeidsmåte. Hva ønsket kunden å få gjort, hva skjedde, og hvilken konsekvens fikk det? Et symptom som «vi bruker mye tid» må undersøkes før dere foreslår et nytt system. Kanskje oppgaven stopper fordi ansvar er uklart, ikke fordi verktøyet mangler en funksjon.
Be kunden bekrefte oppsummeringen. Spør også hvorfor endring er aktuelt nå og hva som skjer hvis problemet venter. En reell utfordring er ikke nødvendigvis et prioritert kjøp. Dersom kunden ikke ønsker å endre noe, bør dere avtale om saken skal settes på pause fremfor å skrive et omfattende tilbud.
- Hvilken konkret situasjon skal bli bedre?
- Hvem opplever konsekvensen, og hvem kan godkjenne endringen?
- Hva har kunden allerede forsøkt?
- Hvilke begrensninger gjelder for tid, penger og gjennomføring?
2. Definer hva en fungerende løsning skal gjøre
Beskriv et resultat kunden kan observere. «Bedre IT» er vanskelig å vurdere. «Avtalte tilganger er kontrollert før en ny ansatt begynner» gir en oppgave og et kontrollpunkt. Avklar hvem som avgjør om kriteriet er møtt, og hvilke opplysninger eller godkjenninger kunden må levere.
Hold ønsket effekt atskilt fra det dere kan forplikte dere til. En leverandør kan avtale opplæring, oppsett og en kontrollert test. At alle ansatte endrer arbeidsmåte over natten, ligger også hos kunden. Hvis effekten avhenger av slike forhold, skal avhengigheten stå i forslaget.
3. Sammenlign alternativer og velg minste tilstrekkelige omfang
Vis kunden mer enn én mulig vei når det finnes reelle alternativer. En justert rutine, et avgrenset oppdrag og en større leveranse kan ha ulik kostnad, gjennomføringstid og risiko. Ta med dagens løsning som sammenligningsgrunnlag. Kunden bør forstå hvorfor dere anbefaler ett alternativ.
Tabellen viser et tenkt IT-eksempel. Den begynner med årsaken som ble avklart, og lar større investeringer vente til det finnes et behov for dem. Å selge en mindre løsning kan være riktig hvis den løser oppgaven og gir et tryggere grunnlag for videre samarbeid.
4. Avklar hvem som vurderer og godkjenner forslaget
Personen som beskriver problemet, er ikke alltid den som kan bestille. Spør hvordan en endring blir vurdert, hvilke andre roller som må involveres, og hvilket underlag de trenger. La kontaktpersonen hjelpe dere med prosessen uten å anta at vedkommende kan ta alle beslutninger.
Ulike roller trenger ulike avklaringer. Brukeren vurderer om oppgaven fungerer; IT-ansvarlig vurderer systemer og tilgang; økonomiansvarlig vurderer pris og omfang. Samle spørsmålene i ett forslag slik at motstridende krav blir synlige før avtalen inngås.
5. Skriv et tilbud som kan kontrolleres
Åpne tilbudet med kundens bekreftede situasjon og ønskede resultat. Beskriv deretter leveransen, hva som er utenfor omfanget, prisgrunnlaget, kundens bidrag og hvordan dere vil kontrollere arbeidet. Hvis noe fortsatt er uavklart, skriv det som en forutsetning eller en egen avklaring.
Avtal neste steg før tilbudet sendes. Det kan være en teknisk gjennomgang, bekreftelse fra en godkjenner eller en dato for beslutning. Oppfølgingen skal undersøke den avklaringen som mangler, ikke bare om kunden har lest dokumentet.
Bevar begrunnelsen når saken går fra salg til leveranse
Registrer problemet, kundens kriterier, valgt omfang og åpne spørsmål sammen med saken. Et notat om at kunden er «positiv», hjelper lite hvis leveranseteamet ikke vet hva som ble lovet. I Aventra kan dere samle kontaktpersoner, notater, tilbud og oppfølgingsoppgaver rundt kundearbeidet.
Etter levering kontrollerer dere om de avtalte kriteriene ble møtt. Spør også om løsningen hjalp med situasjonen kunden beskrev. Hvis ikke, undersøk om behovet var feil forstått, omfanget var for lite eller en forutsetning ikke ble oppfylt. Ta læringen tilbake til neste behovsanalyse.