Fluit och klassisk headless commerce
En headless commerce-motor gör en sak och gör den bra: katalog, varukorg, kassa och order. Allt annat som en butik behöver köper ni separat. Den här sidan visar vad det innebär i praktiken, och när det ändå är rätt val.
Motorn är sällan problemet
De stora headless-plattformarna är genuint bra på det de gör. De hanterar kampanjtoppar utan att blinka, har rabattmotorer som klarar det mesta och API:er som är trevliga att bygga mot.
Frågan är vad som händer efter att kunden tryckt på köpknappen. Varan ska plockas, saldot skrivas ned, artikeln köpas in igen, fakturan skapas, returen tas emot och krediteras. En commerce-motor håller reda på orderstatus, saldo och återbetalning, men själva arbetet i lagret och i ekonomin ligger utanför den. Det är ingen brist, det är avgränsningen som gör motorn bra. Följden är att e-handelssatsningen aldrig blir bara ett projekt.
Vad ni upphandlar utöver motorn
Exakt uppdelning varierar mellan leverantörer, och någon enstaka bit kan ingå. Mönstret är ändå detsamma: det här är delarna som blir egna avtal, egna integrationer och egna kontaktpersoner.
Butiksfront
Motorn levererar API, inte gränssnitt. Fronten byggs av er eller en byrå.
Produktinformation
Bilder, texter, attribut och översättningar hamnar ofta i ett separat PIM.
Innehåll och sidor
Startsida, kampanjsidor och blogg kräver vanligtvis ett CMS bredvid.
Sök och merchandising
Fritextsök med relevansstyrning köps oftast som egen tjänst.
Lager och plock
Fysisk lagerhantering ligger i ett WMS, inte i commerce-motorn.
Inköp och påfyllning
Beställningsförslag och leverantörsuppföljning hör hemma i ett ERP.
Ekonomi och fakturering
Kundfakturor, kreditfakturor och bokföringsunderlag skapas någon annanstans.
Frakt och etiketter
Bokning mot transportör sker via en fraktplattform.
Returer
Returportal och returflöde är vanligen en egen leverantör.
Kundtjänst
Ärenden och kunddialog kring en order lever i ett separat verktyg.
Till det kommer den byrå som fogar ihop delarna, och förvaltningen efteråt. Varje koppling mellan två system är kod som någon har skrivit och som någon måste hålla vid liv när systemen uppdateras. I Fluit delar de här delarna databas, så det blir färre systemgränser att förvalta. Kopplingar utåt finns kvar där de gör nytta: Fortnox för bokföringen, nShift för frakten och Ongoing när lagret sköts av tredje part.
Sida vid sida
Fluit mot en typisk headless-stack. Kolumnen till höger beskriver mönstret, inte en enskild produkt.
| Funktion | Fluit | Headless-stack |
|---|---|---|
| Öppet commerce-API att bygga egen front på | Fluit: Ingår | Headless-stack: Ingår |
| Färdig butiksfront ingår | Fluit: Ingår | Headless-stack: Saknas. Byggs av er eller byrå |
| Produktinformation och kategorier | Fluit: Ingår | Headless-stack: Delvis, via tillägg eller partner. Ofta separat PIM |
| Innehållssidor, blogg och navigation | Fluit: Ingår | Headless-stack: Delvis, via tillägg eller partner. Ofta separat CMS |
| Sök och filter i butiken | Fluit: Ingår | Headless-stack: Delvis, via tillägg eller partner. Ofta separat söktjänst |
| Butikens saldo är lagrets saldo | Fluit: Ingår | Headless-stack: Saknas. Synkas mellan system |
| Plock, pack och inleverans | Fluit: Ingår | Headless-stack: Saknas. Separat WMS |
| Inköp och beställningsförslag | Fluit: Ingår | Headless-stack: Saknas. Separat ERP |
| Fakturering och bokföringsunderlag | Fluit: Ingår | Headless-stack: Saknas. Separat ekonomisystem |
| Returer och kreditfaktura i samma flöde | Fluit: Ingår | Headless-stack: Delvis, via tillägg eller partner |
| Kundtjänstärenden kopplade till ordern | Fluit: Ingår | Headless-stack: Delvis, via tillägg eller partner |
| B2B-portal med offert, faktura och retur | Fluit: Ingår | Headless-stack: Delvis, via tillägg eller partner |
| Frakt och etikettutskrift | Fluit: Ingår. Inbyggd (nShift) | Headless-stack: Delvis, via tillägg eller partner |
| Webhooks och event mot egna system | Fluit: Ingår | Headless-stack: Ingår |
| Bredd av checkoutleverantörer | Fluit: Delvis, via tillägg eller partner. Klarna Checkout i dag | Headless-stack: Ingår |
| Flera marknader med egen valuta per butik | Fluit: Delvis, via tillägg eller partner | Headless-stack: Ingår |
| Publik prislista | Fluit: Ingår | Headless-stack: Saknas. Offert per kund |
| Igång utan utvecklingsprojekt | Fluit: Ingår | Headless-stack: Saknas |
Högerkolumnen beskriver ett vanligt upplägg, inte en namngiven produkt. Enskilda plattformar har mer eller mindre inbyggt, och funktioner, priser och avtalsvillkor varierar per leverantör och avtal. Stämmer något inte, hör av dig till info@fluit.se så rättar vi.
Vill ni bygga fronten själva går det
Det här är ingen jämförelse mellan headless och inte headless. Fluits butiksyta är ett öppet REST-API med 95 anrop för katalog, sök, priser, saldo, varukorg, kassa och kundens egna sidor. Samma API driver Fluits färdiga butik, så det ni bygger mot är produktens egen yta och inte en integrationsyta vid sidan av.
Skillnaden mot stacken är alltså inte om ni får bygga eget. Den är att lager, inköp, fakturering och kundtjänst redan finns bakom API:et den dagen ni behöver dem.
Se commerce-API:et →När stacken är rätt val
Det finns lägen där en composable stack är det riktiga svaret, och då ska ni välja den. Tre av dem:
Ni har ett eget utvecklingsteam
Finns det utvecklare in-house som redan äger butiksfronten är motorns enda uppgift att svara snabbt och inte stå i vägen. Då betalar ni för funktioner ni ändå bygger själva.
Volymen är i toppskiktet
Handlar det om miljontals ordrar och kampanjtoppar som tiodubblar trafiken på en minut är det den sortens last de stora motorerna är byggda och prissatta för.
ERP:et är redan satt
Kör ni en etablerad ERP-installation som ingen tänker röra behöver ni inte ett system till som vill äga lager och ekonomi. Ni behöver en motor som pratar med det ni har.
Känner ni inte igen er i något av de tre lägena är friheten att välja tio leverantörer i praktiken ett krav på att förvalta tio leverantörer. Vi har skrivit ned när ni inte ska välja Fluit också, med namn på vad ni bör titta på i stället.
Passar Fluit dig? →Vanliga frågor
Är Fluit ett headless commerce-system?
Fluit har en headless-yta: 95 anrop för katalog, sök, priser, saldo, varukorg, kassa och kundens egna sidor. Skillnaden mot en ren commerce-motor är att ni inte måste använda den. Vill ni bygga er egen front gör ni det mot samma API som driver Fluits egen butik i produktion. Vill ni inte, startar ni den färdiga butiken i stället.
Vad kostar en headless-stack jämfört med Fluit?
Vi publicerar inte siffror för andras produkter, men strukturen skiljer sig: i en stack betalar ni licens till varje leverantör plus bygget och förvaltningen av integrationerna mellan dem. Fluit har en publik prislista med grundlicens och valbara moduler. Räkna på hela stacken, inte bara motorn, när ni jämför.
Vi växer. Målar vi in oss i ett hörn med Fluit?
Butiksfronten är utbytbar utan att systemet under den byts. Går ni från Fluits färdiga butik till en egen bygger ni mot samma API, med samma sortiment, priser och order. Data ligger kvar och lagret märker ingenting.
Vi har redan ett ERP. Är Fluit fel då?
Möjligen. Fluit är byggt för att äga lager, order och ekonomiunderlag, och den styrkan blir en dubblering om ett annat system redan gör det. Kör ni Fortnox är svaret ett annat: Fluit integrerar med Fortnox och tar lager, order och e-handel medan bokföringen ligger kvar.
Är composable och MACH fel sätt att bygga?
Nej. Det är ett bra svar på ett verkligt problem, nämligen att stora organisationer vill byta ut en del i taget utan att stanna resten. Frågan är om ni har det problemet. Utan eget utvecklingsteam blir friheten att välja tio leverantörer i praktiken ett krav på att förvalta tio leverantörer.
Räkna på hela stacken, inte bara motorn
Boka en demo så går vi igenom vad ert upplägg faktiskt kräver, och om Fluit är rätt för det.