En integration är sällan svår för att tekniken är svår. Den är svår för att två system har olika uppfattning om verkligheten, och någon måste bestämma vems som gäller.
Det vanligaste misslyckandet är inte att integrationen inte fungerar. Det är att den känns som ett hopp ut ur upplevelsen.
Besökaren klickar ”köp biljett” och landar i något som ser ut som en annan värld, med annan typografi, andra knappar och plötsligt en inloggning som inte fanns förut. Tekniskt fungerar allt. Men förtroendet tar en törn precis i det ögonblick där det behövs som mest.
Det andra vanliga problemet är underhåll. En integration byggd som en engångsinsats går sönder när det andra systemet uppdateras, och då är det ingen som äger den.
Vi börjar med att förstå vilken data som faktiskt behöver flyttas, och åt vilket håll. Ofta visar det sig vara mindre än man trodde.
Vi bygger så att skarven inte syns för användaren, i den mån systemet tillåter det. Ibland gör det inte det — och då säger vi det tidigt i stället för att lova något vi inte kan hålla.
Vi bygger felhantering på riktigt. Vad händer när det andra systemet är nere? Användaren ska få veta något begripligt, inte en teknisk felkod.
Och vi håller efter dem. Integrationer är den del av en webbplats som oftast går sönder utan att någon märker det.
Biljettsystem, CRM, affärssystem och medlemsregister, bland annat. Men det viktigare svaret är att vi läser API-dokumentation för nya system varje år — det är sällan systemet i sig som avgör.
Det är en vanligare fråga än man tror. Vi har erfarenhet av att jobba i projekt där andra parter äger den tekniska plattformen, och där blir kommunikation och avstämning lika viktigt som koden.
Ibland. Det beror på vad systemet erbjuder — filexport, webhooks, databasdelning. Vi säger hellre vad som faktiskt går än lovar något vi inte kan hålla.
Berätta hur det ser ut, så säger vi vad som är rimligt.