När offerten blir order

Så håller integrationen ihop samma affär i HubSpot genom hela förloppet.

Illustration av en offert som blir order i affärssystemet och fortsätter som samma affär i HubSpot med båda identifierarna.

Offerten har redan kommit över till HubSpot. När kunden beställer får den ett ordernummer i affärssystemet. Nu behöver integrationen förstå att det är samma affär som fortsätter. Med rätt identifierare och tydliga regler går det att behålla historik, aktiviteter och ansvar utan att skapa en ny affär vid varje steg.

En affär kan följa både offert och order

Ett vanligt upplägg vid affärssystemintegration är att låta samma deal, alltså affär, i HubSpot representera både offertskedet och det fortsatta orderförloppet. Deal stages visar då var affären befinner sig, medan affärssystemet hanterar sina egna offert- och orderposter.

Det är en integrationsmodell som behöver väljas medvetet. HubSpot har även separata offert- och orderobjekt. Dessa kan vara relevanta i andra upplägg och ska inte förväxlas med att representera en extern offert eller order på en affär. HubSpot beskriver exempelvis sitt orderobjekt i den egna kunskapsbanken.

I den här guiden utgår vi från modellen med samma affär genom förloppet. Den är användbar när medarbetarna behöver en sammanhängande plats för kunddialog och uppföljning.

Spara både offert-ID och order-ID

Anta att offerten har identifieraren O-1042. Integrationen skapar en affär och sparar offertens identifierare där. När offerten konverteras får ordern identifieraren A-7821. Om integrationen då bara söker efter ordernumret finns ännu ingen matchning.

Lösningen behöver kunna följa sambandet tillbaka till offerten. Den hittar då den befintliga affären, sparar även orderns identifierare och uppdaterar relevanta uppgifter. Affärens interna HubSpot-ID är fortfarande detsamma.

Offert-ID och order-ID bör därför hanteras separat. Kontrollera också skillnaden mellan ett synligt nummer och ett internt ID i affärssystemet. Om flera bolag använder samma nummerserie kan matchningen behöva omfatta både bolag och identifierare.

Beskriv matchningsordningen

Ett robust upplägg behöver en bestämd ordning för hur befintliga poster hittas. Vid en orderuppdatering kan integrationen först kontrollera om ordern redan är kopplad. Om den inte är det kan den undersöka den ursprungliga offertreferensen.

Om ingen matchning finns behöver flödet veta vad som ska hända. En direktorder utan föregående offert kan vara helt normal. En konverterad offert där länken saknas kan däremot behöva stoppas för kontroll. Att skapa en ny affär i båda fallen riskerar att dölja ett integrationsfel som en till synes lyckad körning.

Det här hör ihop med objektmappning, riktning och triggers. Matchningsreglerna ska vara en del av underlaget, inte bara något som finns i utvecklarens huvud.

Deal stage behöver spegla en genomtänkt process

När ordern skapas kan affären flyttas till det steg som representerar beställningen. Men affärssystemets alla statusar behöver inte bli egna försäljningssteg i HubSpot.

Fundera på vad användarna och rapporteringen behöver. När räknas affären som vunnen? Ska leveransstatus visas i ett separat fält? Vad betyder en makulering? Om en redan vunnen affär flyttas tillbaka kan det påverka hur teamet tolkar resultatet.

Använd integrationen för att stödja den överenskomna processen. Låt inte varje teknisk statusförändring automatiskt bli ett nytt affärsmässigt besked. Vid den tekniska mappningen behöver även stegens interna ID:n hanteras korrekt.

Vad händer med belopp och rader?

Den godkända ordern kan skilja sig från offerten. Kunden kanske väljer färre produkter eller kommer överens om ett annat pris. Bestäm vilken version som ska styra affärens aktuella värde och hur den ursprungliga offerten ska kunna följas upp.

Om både offertuppdateringar och orderuppdateringar fortsätter komma in behövs regler för vilket underlag som gäller efter konverteringen. En sen offertuppdatering ska inte oavsiktligt skriva tillbaka äldre information på orderaffären.

För radinnehållet behöver ni skilja mellan produktregistret och raderna på den aktuella affären. Läs vår guide om products, line items och priser.

När en offert blir flera order

En offert kan ibland delas upp i flera beställningar. Då räcker inte antagandet att varje affär alltid har exakt ett order-ID.

Ni behöver välja hur de olika orderna ska representeras och hur deras värden ska summeras. I vissa fall behövs flera affärer eller separata kopplade poster. I andra fall passar en gemensam affär med tydlig uppdelning av orderinformationen.

Det är inte en regel som integrationen bör gissa. Ta med delorder, återkommande avrop och tilläggsbeställningar i kartläggningen om de förekommer i verksamheten.

Testa även upprepade och försenade uppdateringar

En normal konvertering är bara ett testfall. Prova också att samma ordermeddelande kommer två gånger, att ordern uppdateras innan offerten hunnit synkas och att affärssystemet svarar långsamt.

Kontrollera att det fortfarande finns rätt antal affärer, att rätt identifierare är sparade och att den senaste informationen gäller. I en integrationsplattform kan körningshistorik och styrd bearbetning hjälpa er att följa dessa situationer. Övervakning och förvaltning behövs sedan för att fånga dem i drift.

Vanliga frågor om offert–order-synk

Måste en order skapa en ny affär i HubSpot?

Nej. Om integrationen använder samma affär genom offert- och orderförloppet ska den normalt hitta och uppdatera den befintliga affären.

Varför behövs både offert-ID och order-ID?

De identifierar olika poster i affärssystemet. Sambandet mellan dem gör att integrationen kan följa konverteringen och hitta rätt affär vid senare uppdateringar.

Har HubSpot egna objekt för offerter och order?

Ja. Att använda affärer och deal stages för externa offerter och order är ett valt upplägg, inte HubSpots enda datamodell.

Vad ska vi göra med direktorder?

Definiera ett eget tillåtet flöde. En order utan offert kan skapa en ny affär om det är rätt för processen, men ska inte blandas ihop med en konvertering där matchningen misslyckats.