Vem upptäcker när synken stannar?
Så bygger ni uppföljning och förvaltning runt integrationen mellan HubSpot och affärssystemet.
En integration är inte färdig bara för att den första ordern går över. Den behöver också fungera när ett system ligger nere, uppgifter saknas eller en anslutning förändras. För företag som använder HubSpot i det dagliga arbetet är övervakning och tydligt driftansvar en del av själva lösningen.
Ett lyckat test säger inte hur fel hanteras
Vid driftsättningen ser teamet rätt kund, ordernummer och belopp i HubSpot. Några veckor senare svarar affärssystemet långsammare än vanligt och en överföring avbryts. Ordern saknas i CRM, men medarbetaren vet inte att något har hänt.
Det är ett typiskt glapp mellan fungerande överföring och fungerande drift. Integrationens normala flöde kan vara korrekt, samtidigt som verksamheten saknar ett sätt att upptäcka undantagen.
Utgå därför från både vad som ska synkas och hur ni ska veta att det blev gjort. Planeringen av objekt, riktningar och triggers behöver kompletteras med en plan för uppföljningen.
Varje körning behöver gå att följa
När en order saknas vill ni kunna hitta dess körning och se vad som hände. En användbar körningshistorik visar exempelvis vilken post som behandlades, när det skedde, vilka steg som slutfördes och varför bearbetningen avbröts.
Det bör gå att följa samma ärende genom flera steg och system. Om ett kundnummer sparades men ordern inte skapades behöver detta vara synligt. Ett allmänt meddelande om att något gick fel ger sällan tillräcklig hjälp.
Loggarna ska samtidigt hanteras med omsorg. Spara tillräckligt för felsökning, begränsa åtkomsten och undvik att lägga hemligheter eller onödiga personuppgifter i körningsinformationen.
Alla fel ska inte få samma behandling
Ett tillfälligt avbrott kräver en annan åtgärd än ett ogiltigt kundnummer. Om systemen för tillfället inte kan ta emot fler anrop kan integrationen behöva vänta och försöka igen. Om en obligatorisk uppgift saknas behöver underlaget ofta rättas.
Behörighetsproblem kräver i sin tur kontroll av anslutningen, inte obegränsade återförsök. Ett praktiskt upplägg skiljer därför mellan sådant som kan lösa sig genom väntan och sådant som behöver mänsklig åtgärd.
En integrationsplattform kan samla denna hantering: köer, väntetider, larm och körningar som behöver granskas. Reglerna måste fortfarande anpassas till respektive API och flöde.
Ett återförsök får inte skapa en ny beställning
Anta att ordern skapades i affärssystemet, men att svaret aldrig nådde integrationen. Ett nytt försök måste kunna upptäcka att ordern redan finns. Annars kan samma fel som skulle rättas leda till en dubblett.
Använd beständiga referenser och tydliga matchningsregler. Bestäm också hur en avbruten flerstegskörning ska fortsätta. Ska den börja om från ett säkert läge, eller kontrollera och återanvända det som redan skapats?
För offert och order är identifieringen central. För affärsrader behöver ni dessutom kontrollera att ett avbrott inte lämnar ett ofullständigt radinnehåll.
Fånga även det som aldrig blev en körning
Det räcker inte alltid att bevaka misslyckade anrop. En ändring kan ha missats innan någon körning startade. Då ser fellistan tom ut trots att en order saknas.
Komplettera därför med avstämning som jämför förväntat och faktiskt resultat. Det kan vara att kontrollera att relevanta order under en viss period har en motsvarande post, att de senaste uppdateringarna kommit över eller att centrala belopp stämmer.
Anpassa kontrollen till processen. Antalet poster kan se rätt ut även om fel order har uppdaterats. I vissa flöden behövs jämförelse av både identitet, version och innehåll.
Bestäm vem som agerar och när
Ett larm gör ingen nytta om ingen äger nästa steg. Beskriv vem som bevakar, vem som får rätta underlag och vem som kontaktar verksamheten när ett fel påverkar arbetet.
Klargör också vilka tider övervakningen omfattar och hur snabbt olika fel ska hanteras. En återkommande statistikuppdatering och en beställning som stoppar leveransen behöver inte ha samma prioritet.
Undvik att tolka ordet övervakning som ett löfte om ständig bemanning. Det faktiska åtagandet behöver vara överenskommet. Samma sak gäller lagring av körningshistorik, planerade ändringar och vad som ingår i löpande förvaltning.
En partner kan ta hand om driften
En integrationspartner kan erbjuda både plattform och hanterad drift. Då kan bevakning, felsökning och återkörning samlas hos ett team som känner flödena. Cedeo arbetar med integrationer till HubSpot och affärssystem och kan hjälpa till med både upplägg och förvaltning.
Det praktiska värdet är att verksamheten får någon att vända sig till och en process för att återställa synken. Be partnern visa hur ett fel upptäcks, hur det rättas och hur man säkerställer att rätt resultat till slut finns i båda systemen.
Ta också med förändringar över tid. Nya obligatoriska fält, ändrade statusar och förnyade anslutningar kan kräva justeringar även om ingen har ändrat integrationskoden. Vår guide till HubSpots dokumentation och ändringslogg visar hur ni hittar information om plattformsförändringar.
Vanliga frågor om integrationsdrift
Behöver vi övervaka en färdig standardkoppling?
Ja, ni behöver åtminstone förstå vilken övervakning som ingår, hur fel blir synliga och vem som agerar. En färdig koppling tar inte bort behovet av ansvar.
Ska alla misslyckade körningar köras om automatiskt?
Nej. Tillfälliga fel kan ofta hanteras med återförsök, medan felaktigt underlag eller saknade behörigheter behöver en annan åtgärd.
Hur hittar vi en order som aldrig synkats?
Genom avstämning mellan förväntade poster och det som faktiskt finns. Körningsloggar räcker inte om händelsen aldrig startade ett flöde.
Vad bör ingå i hanterad drift?
Ett tydligt åtagande för bevakning, incidenthantering, återkörning och kommunikation. Bestäm även tillgänglighet, ansvar och hur förändringar hanteras.
Vill ni få bättre kontroll på integrationerna?
Vi går igenom hur era flöden körs, följs upp och förvaltas. Läs om våra integrationer eller kontakta Cedeo.