Ett lead som säger ’vi behöver koppla ihop våra system’ kan vara ett välavgränsat API-uppdrag – eller ett flerårigt integrationsprogram utan intern ägare. För en API-integrationsbyrå är rätt affär inte den som nämner flest plattformar, utan den där dataflöde, ansvar, behörigheter och driftsättning går att definiera. Så kvalificerar ni nya integrationsprojekt innan ni lägger dagar på offert.
Kvalificera leadet med sju svar
- Affärshändelse: vilket konkret beslut eller flöde ska integrationen möjliggöra?
- System: vilka källor och mål finns, med versioner, miljöer och ansvariga?
- Data: vilka objekt, fält, datamängder och synkfrekvenser ingår?
- API-villkor: finns dokumentation, sandbox, rate limits, webhook-stöd och avtal?
- Säkerhet: vem beslutar om behörigheter, personuppgifter, loggning och retention?
- Drift: vem övervakar fel, köer, återförsök och incidenter efter lansering?
- Affärsram: finns budget, teknisk beställare, beslutsperson och tidsfönster?
Skilj integration från dataplattform och CRM-migrering
En punkt-till-punkt-integration mellan order och lager är inte samma sak som en ny dataplattform. En data engineering-byrå kan vara rätt när lagring, transformation och analysplattform dominerar. En CRM-migreringsbyrå behöver ofta ta ansvar för datarensning och cutover. API-specialistens uppdrag kan i stället handla om kontrakt, autentisering, händelser och felhantering mellan existerande system.
Tre leads som ser lika ut – men inte är det
- E-handel till ERP: order, lager, priser och returer kräver tydliga regler för konflikt, duplicering och uppdateringsordning.
- SaaS till kundens system: autentisering, tenant-isolering, API-versionering och kundspecifika fält kan styra scope.
- Intern processautomation: webhook-händelser, godkännanden och återförsök kräver spårbarhet även när ingen användare tittar.
Från första samtal till betald discovery
Sälj inte ett fastpris innan ni vet vilka API:er som går att använda. Be om testkonton och dokumentation. Föreslå en begränsad discovery med integrationskarta, riskregister, exempelpayloads och en prototyp av det mest osäkra flödet. Sätt sedan acceptanskriterier: vad händer när källsystemet ligger nere, samma händelse skickas två gånger eller ett fält ändrar format?
Särskilt viktigt är idempotens och återförsök: ett nytt försök får inte skapa två ordrar eller dubbla debiteringar. Microsofts arkitekturvägledning beskriver hur idempotency keys kan göra återförsök säkrare. OWASP lyfter bristande objektbehörighet som en central API-risk. Dessa är relevanta kontrollpunkter, inte bevis för att en viss kund har en sårbarhet.
Frågor som avgör om ni ska lämna offert
- Har kunden teknisk tillgång till båda systemen, inklusive en testmiljö?
- Finns en ägare för datamodell och beslut vid konflikt mellan systemen?
- Vilka fel måste upptäckas automatiskt och vem ska få larm?
- Hur hanteras hemligheter, tokenrotation och behörighet per kund?
- Vad ska hända vid timeout, dubbletter och förändrade API-kontrakt?
- Finns ett realistiskt test- och lanseringsfönster med ansvariga på båda sidor?
- Vem äger kod, dokumentation, support och ändringsbudget efter överlämning?
Så kan ni beskriva ert erbjudande på Mosai
Beskriv vilka integrationsmönster, plattformar och branschsituationer ni faktiskt behärskar. Ange om ni tar discovery, utveckling, säkerhetsgranskning, övervakning eller förvaltning. Visa gärna en anonymiserad projektstruktur och vilka beroenden kunden måste lösa. Undvik att skriva att ni kan ’alla API:er’ eller lova driftsättning innan systemåtkomst har granskats.
Mosai kan hjälpa företag att hitta byråer med relevant inriktning och ge byråer möjlighet att synas i rätt sammanhang. Matchning beror på projektets fit; någon leadvolym garanteras inte. Läs hur Mosai arbetar med leads och aktuella alternativ innan ni väljer profilnivå.
Varningssignaler i pipeline
Avvakta när beställaren saknar åtkomst, inte kan utse en teknisk ägare eller vill ha en fast leveranstid utan dokumenterade API-villkor. Ett bra nej sparar ofta mer än en dåligt kvalificerad offert. Samla i stället en kort behovsbeskrivning med mål, system, risker, budget och beslutspunkter – då kan ni avgöra om affären förtjänar nästa möte.
Tekniska referenser: Microsoft om idempotens i tjänstearkitektur och OWASP om API-behörighet.