Offertverktyg för B2B: vad ni ska kräva av leverantören

Ni har skickat en offert och kunden vill ändra omfattningen. Säljaren öppnar kalkylbladet, justerar priset och skickar en ny PDF. När kunden accepterar behöver ekonomiavdelningen reda ut vilken version som gäller.

Så kan det se ut hos en industrileverantör där förfrågan kommer via e-post och ordern registreras manuellt. Två veckor mellan utskicken räcker för att prislistan, lagersaldot eller leveransvillkoren ska hinna ändras.

Ett offertverktyg behöver därför hålla ihop det ni faktiskt lovar kunden. Pris, produktval, behörigheter och villkor måste gå att kontrollera även efter utskicket. Dokumentets utseende är en mindre del av det arbetet.

Var offertverktyget sitter i köpprocessen

Kundens förfrågan behöver börja med rätt sammanhang. Vilket bolag handlar, vem företräder kunden och vilket avtal gäller? Om säljaren väljer fel kundkonto kan hela kalkylen bygga på fel prislista.

Därefter väljs produkter och kundavtal. Verktyget räknar priset, kontrollerar eventuella undantag och skickar offerten för internt godkännande. Kunden får sedan ett erbjudande med en bestämd omfattning och giltighetstid.

När kunden accepterar behöver rätt offertversion följa med till ordern. Affärssystemet ska kunna ta emot överenskomna artikelrader, priser och villkor. Ekonomiavdelningen behöver senare kunna följa affären till leverans och betalning.

Ordningen spelar roll. Ett felaktigt kundavtal vid produktvalet ger fel pris i kalkylen. Om felet passerar attesteringen får orderavdelningen ett underlag som redan innehåller ett felaktigt löfte.

Enligt SCB tog 30 procent av svenska företag med minst tio anställda emot beställningar via egen webbplats eller app under 2024, jämfört med 21 procent inom tillverkningsindustrin.

För er innebär det att offertflödet behöver bedömas utifrån hur kunderna köper. Vissa förfrågningar kräver rådgivning före kalkylen. Andra kan börja med produktval i en portal och fortsätta hos en säljare.

Ett dokumentverktyg kan sammanställa uppgifter till en PDF. Ett kontrollerat offertflöde behöver dessutom bevara sambandet mellan kundens förfrågan, den godkända kalkylen och den accepterade ordern.

Sju funktioner och vad var och en måste klara

Använd funktionerna som en checklista mot er nuvarande process. Bedöm varje funktion utifrån vilka uppgifter den tar emot och vad nästa ansvariga person faktiskt kan använda.

Offertförfrågan och kundinloggning tar emot förfrågan med kundkontext och produktval. Kundnummer, organisationsnummer och kontaktperson måste stämma. Utan funktionen matar säljaren in samma uppgifter igen.

Prissättning och kundavtal räknar pris per rad med prislista och avtalspriser. Prislista, rabattregel, valuta och moms måste stämma. Utan funktionen kan fel pris gå ut till kunden.

Konfiguration och produktdata hämtar artiklar, varianter och villkor. Artikelnummer, enheter och leveranstid måste stämma. Utan funktionen kan offerten bygga på en gammal produktbeskrivning.

Godkännande och attestnivåer styr vem som får skicka, ändra och godkänna offerten. Behörighet och beloppsgränser måste stämma. Utan funktionen kan en obehörig person godkänna en offert.

Versionshantering sparar varje utskickad offert som en egen version. Versionsnummer och giltighetstid måste stämma. Utan funktionen blir det oklart vilket pris kunden accepterade.

Synk till order skickar den accepterade offerten till affärssystemet som order. Orderreferens, kundnummer och lagerstatus måste stämma. Utan funktionen uppstår dubbelregistrering och avvikelser mellan offert och order.

Uppföljning följer status, datum och orsak till förlust. Offertstatus, datum och skäl till förlust måste stämma. Utan funktionen vet ingen varför offerter går förlorade.

Kundinloggningen behöver koppla användaren till rätt köpande bolag. En kontaktperson kan företräda flera bolag med olika avtal. Fel kundnummer kan därför ge både fel rabatt och fel fakturamottagare.

Prissättningen behöver också ha en bestämd ordning. Verktyget måste veta hur avtalspris, mängdrabatt och manuellt pris samverkar. Annars kan en rabatt läggas ovanpå ett redan reducerat avtalspris.

Anta att artikelbeskrivningen finns i affärssystemet, tekniska egenskaper i ett separat register och leveransinformationen i ett kalkylblad. Säljaren kan då välja rätt artikelnummer men skicka en gammal beskrivning. Kunden accepterar en egenskap som den aktuella varianten saknar.

För varje fält behöver ni ange var den gällande uppgiften finns. Behovet av gemensamma källdata för produktinformation blir särskilt tydligt när samma artikel används i webb, portal och offert.

Godkännandet behöver därefter följa den färdiga kalkylen. Om någon ändrar en rabatt efter attesteringen bör verktyget kunna kräva ett nytt godkännande. Orderöverföringen och uppföljningen måste sedan använda den godkända versionen.

Markera vilka funktioner ni har, vilka som sköts manuellt och vilka som saknas. Skriv också namnet på personen som ansvarar för varje manuellt moment. Då syns både systemluckor och uppgifter som saknar en tydlig ägare.

När priset i offerten blir bindande

Färre klick i offertflödet kan höja avtalsrisken om kontrollerna samtidigt försvinner. Enligt avtalslagen är ett anbud bindande för den som lämnar det när mottagaren accepterar i tid, och lagen gäller även mellan företag. Hur ert eget avtal och era villkor påverkar bedömningen behöver avgöras av den som ansvarar för era avtal.

Tekniskt kan ett utskick fungera perfekt samtidigt som innehållet är fel. Verktyget kan leverera fel valuta, en passerad giltighetstid eller bilagor med motstridiga leveransvillkor. En elektronisk accept undanröjer inte sådana problem.

Anta att en säljare ger en rabatt över sin attestgräns. Verktyget tillåter utskick eftersom behörigheten bara kontrolleras när användaren loggar in. Kunden accepterar innan försäljningschefen upptäcker rabatten.

Då behöver ni kunna visa vilket mandat säljaren hade, vilken kontroll som saknades och vad kunden fick. Den juridiska bedömningen kräver sitt underlag. Verktyget behöver bevara händelserna så att ni kan ta fram det.

En ändring efter utskick ska skapa en ny offertversion med egen tidsstämpel. Det tidigare innehållet ska finnas kvar.

Bestäm också hur prisförnyelse ska fungera. En användbar intern regel är att en behörig säljare får räkna om ett utgånget erbjudande. Avvikelser från prislistan skickas därefter till den attestansvariga innan den nya versionen lämnar systemet.

Den regeln behöver kompletteras med en hantering av äldre erbjudanden. Ett nytt utskick betyder inte automatiskt att ett tidigare anbud saknar verkan. Låt den som ansvarar för era avtalsvillkor fastställa hur återkallelser och ersättande offerter ska uttryckas.

Kontrollera slutligen att kundens accept pekar på ett bestämt versionsnummer. Bilagor, giltighetstid och eventuella reservationer ska höra till samma version. Då kan ni utreda ett ifrågasatt pris utan att jämföra mejltrådar och lokalt sparade dokument.

Varför synken mot affärssystemet avgör ert resultat

Systemet skapar ordern, men svaret når aldrig tillbaka. Kopplingen försöker igen och lägger en andra order, fast priset och kundens accept var rätt.

Felet sitter i kvittensen. Eftersom offerten styr pris och villkor måste överföringen vara idempotent: samma identifierare ger samma resultat även om begäran skickas en gång till.

Kund, offert och order behöver var sin beständiga identifierare. Vid ett uteblivet svar ska kopplingen kunna kontrollera om posten redan har skapats. Samma princip gäller när meddelanden levereras på nytt efter ett avbrott.

En PDF kan visa artikelnummer och villkor för en människa. Dokumentet ensamt ger däremot ingen säker fältmappning till en order. Strukturerade offertrader gör det möjligt att kontrollera varje värde innan affärssystemet tar emot det.

Vid överföringen måste organisationsnummer och kundnummer avse samma köpande bolag, orderreferensen och offertversionen peka på kundens accepterade erbjudande, och artikelnummer och enhet kunna användas på rätt orderrad. Moms och valuta ska följa den godkända kalkylen, medan leveransadress och betalningsvillkor ska överensstämma med erbjudandet.

Upphandlingsmyndigheten

Ni behöver samtidigt bestämma vilket system som äger pris och lagersaldo. Ett aktuellt saldo vid kalkyleringen innebär inte att varorna är reserverade. Offerten behöver därför skilja mellan uppgiven tillgänglighet och en bekräftad leverans.

Utse en ansvarig för fältmappningen och testa ändringar i affärssystemet mot offertflödet. Stäm av ett urval accepterade offerter mot ordrar varje månad och dokumentera avvikelserna. Resonemanget om integration med affärssystemet hjälper er att precisera vilket ansvar som behöver följa med kopplingen.

Fem mätetal som visar om offerterna lönar sig

Snabb offertproduktion kan kombineras med svag lönsamhet. Om säljaren använder inaktuella inköpspriser kan fler accepterade offerter ge sämre marginal. Därför behöver ni följa både arbetsinsatsen och affärens ekonomiska utfall.

Era offertmått behöver utformas efter den egna processen och kunna härledas till faktiska händelser.

Tid från offert till accepterad order visar hur lång väg affären tar. Värdet kommer från tidsstämplar i offertversioner och order. Ett vanligt fel är att starta mätningen vid fel tillfälle.

Andel offerter som blir order visar konvertering per kanal och produktgrupp. Värdet kommer från offertstatus och orderregister. Ett vanligt fel är att inte räkna med förlorade offerter.

Manuella korrigeringar per offert visar var offerten behöver handpåläggning. Värdet kommer från loggen över ändringar efter utskick. Ett vanligt fel är att ändringarna görs i kalkylblad utanför verktyget.

Andel orderrader som matchar affärssystemets data visar hur väl offert och order stämmer. Värdet kommer från avstämning mot orderrader i affärssystemet. Ett vanligt fel är att göra avstämningen först vid fakturan.

Bruttomarginal mot rabattpolicy visar om rabatterna följer era regler. Värdet kommer från offertrad, inköpspris och rabattregel. Ett vanligt fel är att följa marginalen först när kvartalet är slut.

Definiera när ledtiden börjar och slutar. Om vissa säljare registrerar förfrågan direkt och andra först vid utskick blir jämförelsen missvisande. Bestäm också hur öppna offerter hanteras när ni beräknar andelen som blir order.

Korrigeringar behöver ha en orsak. En kund som utökar beställningen är en annan händelse än att säljaren rättar fel valuta. Blandar ni dem kan ett aktivt säljarbete se ut som dålig datakvalitet.

Varje offertrad bör bära produktidentitet, prislista, rabattregel, valuta, momsbehandling och beräkningsversion. Marginalberäkningen behöver dessutom ett definierat kostnadsunderlag. Annars kan ekonomi och försäljning få olika svar på samma affär.

Lagra mätpunkterna per kanal och affärssystem. Då går det att jämföra portalbaserade offerter med säljarinmatade offerter utan att blanda ihop olika arbetssätt.

Det finns ingen gemensam branschnorm att använda som facit för dessa mått. Betrakta den första mätningen som er nollpunkt. Markera vad ni kan mäta direkt och vilka händelser som ännu saknar loggning.

Välj efter läge, från standard till eget bygge

En offert är ett bindande löfte om pris och villkor, så valet av verktyg är i praktiken ett val av kontrollsystem för era prisregler. Vilket upplägg som passar beror på offertvolymen, komplexiteten i rabattreglerna och vilken kapacitet ni har att förvalta lösningen över tid.

Kalkylblad med CRM-export passar när ni har få offerter per år och få prisregler. Det kräver disciplin i versionshanteringen och en ansvarig person. Den största risken är att spårbarhet mot order saknas.

En standardfunktion i befintlig plattform passar när flödet är vanligt och prisreglerna är få. Det kräver en namngiven ansvarig för prislistor. Den största risken är att en generell lösning inte klarar rabattreglerna.

En anpassad funktion efter er affärslogik passar när attest och prisregler skiljer sig från standard. Det kräver ett beslut om vem som äger regelverket. Den största risken är att reglerna ändras oftare än funktionen.

En kundunik lösning för ett bolag eller en portal passar när flödet är unikt och behöver avgränsas från övriga delar. Den kräver budget för förvaltning efter go-live. Den största risken är att uppgraderingar blir dyra om lösningen inte är isolerad.

Ett eget bygge från grunden passar när ni har en egen utvecklingsorganisation. Det kräver kapacitet för integrationer och uppgraderingar. Den största risken är att kunskapen sitter hos få personer.

Ett kalkylblad kan räcka när offerterna är få, prislistan enkel och en person ansvarar för arbetet. Det blir olämpligt så fort flera personer ska ändra i samma erbjudande eller när kundavtal kräver återkommande specialkontroller, eftersom varje ändring då måste kunna spåras tillbaka till ordern.

En standardfunktion passar ett väl avgränsat flöde. Testa den med era svåraste rabattfall före beslutet. Om säljarna måste räkna färdigt utanför systemet har ni fortfarande ett manuellt kalkylsteg att förvalta.

En anpassad funktion kan behövas när attestregler skiljer sig mellan produktgrupper eller när godkännandegränser ska gälla olika för olika kundsegment. Kundunika delar kan vara motiverade för ett särskilt bolag eller en portal. De behöver hållas isolerade så att ändringar och uppgraderingar kan testas utan att störa resten.

Ett eget bygge kräver att ni kan bemanna utveckling, dokumentation och felsökning över tid. Det blir ett svagt val om ni saknar kapacitet att underhålla kopplingarna efter lanseringen. Oavsett upplägg behöver någon hos er besluta vad prisreglerna ska betyda; verktyget kan verkställa reglerna men inte definiera dem.

Glanser levererar standardfunktioner, anpassade funktioner och kundunika funktioner ur Funktionsbiblioteket till fast pris, och Glanser Care omfattar versionsuppföljning, kompatibilitet genom uppgraderingar och buggrättning till fast månadskostnad.

Kostnaden efter go-live behöver ingå i jämförelsen redan från början, så granska tre poster som saknas i er TCO-kalkyl innan ni räknar på alternativen. Ett enkelt flöde med få offerter kan fortfarande hanteras rimligt i ett kalkylblad, men det kräver samma tydliga ägarskap som ett eget bygge.

Tre frågor att ställa till leverantören

En demonstration visar hur det tänkta flödet fungerar. Era frågor behöver också visa vad som händer när någon ändrar ett pris, en överföring avbryts eller den ansvariga personen slutar.

Hur versionerar ni en offert efter utskick och vad händer med priset kunden redan har accepterat? Ett vagt svar avslöjar att leverantören kan sakna en beständig koppling mellan accepten och den godkända kalkylen. Be leverantören visa både historiken och den order som skapades.

Vilka fält följer med till ordern och hur hanterar ni ett avbrott när affärssystemet redan har skapat ordern? Ett svar utan idempotens eller motsvarande skydd visar risk för dubbla order. Demonstrationen bör även visa hur administratören upptäcker ett misslyckat försök och kan fortsätta säkert.

Vem äger prislistorna och regelverket efter go-live, och vad kostar en ändrad prisregel i pengar och tid? Svaret visar hur arbetet fungerar när affärsvillkor och systemversioner förändras. Skilj på att uppdatera en prislista, konfigurera en befintlig regel och utveckla en ny beräkning.

Jämför svaren med en sparad offertversion och tillhörande order för accepterat pris, en händelselogg och visad återhämtning för avbruten överföring samt ansvarig roll, avtalad omfattning och hantering av ändringen för en ändrad prisregel.

Hos oss behöver gränsen mellan befintliga funktioner och ny funktionalitet vara tydlig före arbetets start. Ett fast pris går att bedöma först när omfattningen är beskriven.

Skriftliga svar ger er något att jämföra mellan leverantörerna. Svaren bör ange både vad lösningen klarar och vilka moment ni själva ansvarar för.

Två timmar och 72 timmar räcker för att se ert läge

En leverantörspresentation gör det lätt att välja innan det nuvarande offertflödet är kartlagt. Då riskerar ni att köpa funktioner ni redan har och lämna de besvärliga överlämningarna orörda. Kartlägg först hur en accepterad offert blir en korrekt order hos er.

Underlaget behöver visa vilka funktioner ni använder, var priset beräknas och hur kopplingarna fungerar. Ta även fram ett exempel där något har gått fel, till exempel en korrigerad faktura eller en offert med flera revisioner. Sådana fall tydliggör vad en vanlig demonstration missar.

Ta med er nuvarande webb, e-handel eller portal för att visa vilka delar som kan behållas, en offert med revisioner för att visa var pris och villkor ändras, motsvarande order för att visa hur överlämningen fungerar samt beskrivna prisregler för att visa vilka funktioner och undantag som behövs.

I en 72-timmarsanalys av er befintliga lösning visar ni er nuvarande webb, e-handel eller portal och avsätter två timmar av er tid. Inom 72 timmar får ni en tydlig bild av var lösningen står och exakt vad ett byte skulle innebära. Analysen är kostnadsfri och underlaget är ert att använda oavsett vem ni väljer.

För att bedömningen ska bli användbar behöver ni kunna förklara era viktigaste prisregler. Den som ansvarar för försäljningens villkor bör därför delta tillsammans med den som kan systemen, eftersom avvägningarna ofta sitter i gränsen mellan affärsregler och teknik.

Utfallet kan vara att lösningen står kvar som den är. Den kan också vara bra i grunden och behöva avgränsade justeringar, eller behöva byggas om. I så fall ska det framgå vilka behov som motiverar det och hur kostnaderna fördelas.