Färre manuella steg. Ett flöde som håller ihop.

01

Fortnox-integration: bestäm vad som ska följa med

Behöver order från webbutiken bli underlag i Fortnox? Vi börjar med att rita upp flödet: vilket system skapar ordern, var kund- och artikeluppgifter ska finnas och hur ändringar eller returer hanteras.

Fortnox har en befintlig koppling för WooCommerce. Vi kontrollerar först om en standardintegration klarar era behov innan vi föreslår egen utveckling. Licenser, stödda flöden och åtkomst behöver granskas för just er lösning.

En första test kan avgränsas till en typ av order med representativa testuppgifter. Vi kontrollerar att uppgifterna blir rätt, att samma händelse inte ger dubbla poster och hur ni upptäcker ett misslyckat överföringsförsök. Ansvarig för bokföringen granskar det ekonomiska underlaget före skarp användning.

02

Börja med arbetet som upprepas

Visa en uppgift från början till slut: vad kommer in, vilka bedömningar görs och var ska resultatet hamna? Det kan vara en materialberäkning, en produktuppdatering eller en offertförfrågan som ska innehålla rätt produktuppgifter.

Vi går även igenom undantagen. Vad händer om uppgifter saknas, samma underlag kommer två gånger eller en koppling till ett annat system slutar svara? Det avgör vad som kan automatiseras och vad någon behöver granska.

03

Erfarenhet av regler, produktdata och API

För TJB utvecklade jag databas och API till en taksäkerhetskalkylator. Arbetet omfattade produktregler, materiallistor, tester och justeringar efter återkoppling under 2025. Den interna administrationen fick behörighetsstyrning och tvåstegsverifiering.

I Taklagrets butik arbetade jag vidare med kalkylatorns integration, vyer och produktregler. Det är exempel på genomförda uppdrag. Ett nytt projekt börjar alltid med en genomgång av era egna produkter, regler och tekniska förutsättningar.

04

Integration, fasta regler eller AI?

Om två system ska dela samma produktuppgift kan en integration vara tillräcklig. Om ett resultat ska räknas fram från mått och ett fast regelverk passar tydliga beräkningsregler. Vi börjar med den enklaste lösningen som klarar uppgiften.

AI kan vara värt att prova när underlaget är fri text, till exempel för att sortera inkommande frågor eller föreslå ett textutkast. Då behöver vi först bestämma vilka uppgifter som får användas, hur förslagen granskas och vad som händer när svaret är fel. En sådan lösning testas på ett avgränsat underlag innan den får påverka ett skarpt flöde.

Du behöver inte välja teknik i förväg. Beskriv uppgiften, så bedömer vi om den bäst löses med en befintlig funktion, en integration, ett eget verktyg eller ett test av AI-stöd.

05

Förfrågningar som får med sig rätt information

En kund ska inte behöva skriva om information som redan finns på produktsidan. För Sharkhead utvecklade jag en offertfunktion där uppgifter om den valda produkten följer med förfrågan.

I ett nytt uppdrag går vi igenom vilka val kunden behöver göra och vad säljaren behöver för att kunna svara. Ett formulär kan vara tillräckligt; ibland behövs ett produktval, en beräkning eller en koppling till ett annat system.

06

Testa litet och bestäm vem som tar hand om lösningen

Vi väljer ett arbetsflöde och kommer överens om vad den första versionen ska klara. Du får ett förslag med omfattning, pris och tidsplan. Licenser, drift och externa system redovisas separat.

Innan publicering provar vi riktiga typer av situationer med lämpliga testuppgifter: ett normalt fall, ofullständiga indata och fel från ett anslutet system. Vi bestämmer också vem som får ändra reglerna, hur ett fel upptäcks och hur det manuella arbetssättet kan användas om lösningen behöver pausas.