Stel je voor dat je als consumentenmerk moeiteloos een gepersonaliseerde klantervaring creëert. En dat in combinatie met de efficiëntste digitale processen. Headless e-commerce maakt dit mogelijk.
Elke e-commerce organisatie moet periodiek op zoek naar een nieuw softwareplatform. Er is dan een behoefte aan nieuwe technologie, betere integratiemogelijkheden of meer schaalbaarheid. Daarnaast faalde volgens onderzoek van Gartner afgelopen jaar meer dan de helft van de grote organisaties bij het verenigen van hun saleskanalen. Klantinteracties verschillen daardoor vaak sterk per platform, en dat resulteert in een slechte klantervaring en merkbeleving.
Hoe vind je de perfecte e-commerce-oplossing voor dit probleem? In het verleden kozen organisaties vaak een one-size-fits-all softwarepakket met een hoop onnodige functies. Die pakketten hadden een groot nadeel: de back- en front-end waren onlosmakelijk aan elkaar verbonden. Daardoor is het lastig om wijzigingen door te voeren zonder fouten in andere onderdelen van het systeem te veroorzaken.
Loskoppelen van back-end en front-end
Headless e-commerce is de nieuwe standaard. In tegenstelling tot een traditioneel softwarepakket bestaat een headless systeem uit een back-end die losgekoppeld is van de front-end, ofwel de webstore(s). Dit maakt het doorvoeren van wijzigingen in beide systemen een stuk minder foutgevoelig.
De front- en back-end zijn wel onderdeel van een uniform platform en werken daarom sterk met elkaar samen. Extra functies of software worden eenvoudig toegevoegd via api’s. Ideaal voor bedrijven die een best-of-breed-softwarestrategie volgen. Dit is een strategie waarbij je voor diverse bedrijfsonderdelen softwareoplossingen kiest van verschillende leveranciers die marktleiders zijn op dit gebied.
In een uiterst snel veranderend e-commercelandschap is het noodzakelijk dat merken meebewegen met klantbehoeften. Dit vereist dat je nieuwe technologie en tools snel implementeert. Dit is met een standaard softwarepakket lastig, aangezien één update in potentie het hele systeem overhoop haalt.
Met een headless systeem is het toevoegen van nieuwe tools of het doorvoeren van wijzigingen een fluitje van een cent. Dit heeft alles te maken met de flexibiliteit die dit soort platformen bieden. Ze vertrouwen immers niet op een set applicaties die van elkaar afhankelijk zijn. Met een headless systeem voer je wijzigingen snel door en schaal je individuele componenten onafhankelijk van elkaar. Dit ondersteunt de bedrijfsgroei en beheerst je operationele kosten.
Centrale plek
Schaalbaarheid is sowieso een groot voordeel van headless e-commerce. Alle gegevens worden opgeslagen op een centrale plek, waar je vervolgens geautomatiseerde processen kunt toepassen op alle on- en offline-winkels. Het resultaat? Je voegt eenvoudig nieuwe magazijnen, winkels en markten toe aan je platform terwijl je controle houdt over de data.
Een headless e-commerce systeem hoeft overigens niet altijd volledig opgebouwd te worden uit verschillende softwareoplossingen. Sommige e-commerce-platformen bieden ‘het beste uit twee werelden’ door een aantal standaardfunctionaliteiten mee te leveren, zoals applicaties voor pim, oms of winkelbeheer, die je naar behoefte gebruikt. Je hebt dan het gemak van een complete softwaresuite, maar je behoudt de flexibiliteit om bepaalde componenten niet te gebruiken of te vervangen door andere software.
De voordelen van headless e-commerce zijn het grootst voor snelgroeiende merken. Zij innoveren hiermee uiterst snel én op hun eigen voorwaarden. Dat is een groot verschil met niet-headless systemen, waarbij aanpassingen of upgrades soms weken tot maanden duren. En het belangrijkste? Je ontwikkelt eenvoudig een gepersonaliseerde klantervaring.
Headless (software architecture). Die term had ik nog niet eerder gehoord. Een term die de lading veel beter dekt dan alles wat er tot nu toe voor gebruikt is. Weg met 3-tier, SOA, API-Driven. Er moet natuurlijk nog wel een frontend blijven voor implementeren, testen e.d. maar die zijn niet voor de eigenlijke doelgroepen. Dit begrijpt iedere klant direct. Die houden we erin wat mij betreft.
Als je aan de voorkant groeit dan moet je achterkant meeschalen want slechte klantervaring en merkbeleving zit vooral in een logistiek die om de levering gaat. Virtueel voeg je makkelijk een magazijn toe maar in de echte wereld zorgen distributiecentra voor de levering van al die spulletjes. Een procesmatige ontkoppeling lijkt me dan ook niet raadzaam als we kijken naar datagedreven ontwikkelingen in de markt. Oja, klantdata valt onder de categorie PII en zoals ik het lees draait oplossing op Amazon wat een punt van aandacht is als we kijken naar ervaringen met Nebu eerder dit jaar.
@eenoudlid helemaal eens. Groei dient vanuit de disciplines technologie, operatie en marketing te worden benaderd. Daarin is fulfilment goed op te schalen via service providers. Bedrijven die een DTC strategie nastreven willen zich onderscheidenden van platformen en doen dit aan de voorkant, waar het merk leeft. Een headless aanpak geeft dan de nodige snelheid en flexibiliteit om het (multi) merkverhaal uit te dragen en een unieke gebruikerservaring neer te zetten. Wat baart je zorgen over AWS?
@Evert
Zie casus Nebu (https://uitspraken.rechtspraak.nl/#!/details?id=ECLI:NL:RBROT:2023:2931) want met AWS hebben we het over de cloud wat voor allerlei non-technische zaken aangaande compliance zorgt. Vergeet hierin niet de logfiles want deze bevatten veelal persoonlijk identificeerbare informatie (PII) waardoor er wat extra zorg voor de data ingericht moet worden. Klantinteracties zoals het recht op verwijdering wordt vaak vergeten. Maar naast een data stewardship hebben we de data portabiliteit welke zonder de nodige expertise als een verzekering zonder dekking is:
https://www.computable.nl/artikel/opinie/cloud-computing/5020126/1509029/wa-verzekering-in-de-cloud.html
Als je de primaire processen van je bedrijfsvoering afhankelijk maakt van een SaaS dienstverlening dan zou ik nadenken over een exit strategie. Je verkoopt teslotte makkelijker asperine aan iemand die hoofdpijn heeft als we kijken naar fulfillment van een behoefte.
Dit artikel gaat over commerce, handel. Die zijn vaak niet zo technisch.
Toch is Rob er lyrisch over. Headless (software architecture). Het schijnt een lading te dekken. Meestal slecht idee om je technische kennis uit een e-commerce artikel te halen tenzij je veel wilt horen over Klantinteracties, “klantervaring en merkbeleving”, “gepersonaliseerde klantervaring”, “meebewegen met klantbehoeften”.
Op zich rode vlaggen zat, alleen al in de titel : e-commerce, geheime wapen, winstgevendheid-verhogen. Dan weet je al, dat wordt geen technisch verhaal.
Zo staan er gewoon onjuistheden in : “In tegenstelling tot een traditioneel softwarepakket bestaat een headless systeem uit een back-end die losgekoppeld is van de front-end, ofwel de webstore(s).” Alsof front-end en back-end iets is dat met headless geintroduceerd is. En waarom je nou headless wel makkelijk een magazijn kan toevoegen en met traditioneel CMS niet..
headless commerce, headless software, headless software architecture. Wat is nou wat. “Dit begrijpt iedere klant direct”, maar ja ik ben techneut. e-commerce is eigenlijk altijd CMS, een systeem om content te managen. En zo is headless e-commerce gewoon een headless CMS ( https://www.computable.nl/artikel/blogs/internet/6617077/5260614/het-cms-van-de-toekomst-is-headless.html uit 2019 voor Rob die er nog nooit van gehoord heeft ). In een notedop is een headless CMS een CMS met front/backend tier waarbij de presentation (van de data) in de front-end zit. Traditioneel is een CMS een frontend, bijv een website in php, en een backend met de content en minimaal een gedeelte van de presentatie/opmaak. Je kunt er dan voor kiezen om die opmaak zo generiek mogelijk te maken zodat die zowel op grote monitor als op een telefoon schermpje mooi rendert, maar wat als je een heel eigen presentatie wilt bijv in een app. Dan wilt je mischien helemaal geen html en misschien wil je wel ook net iets andere content in in je app.
Oudlid kan weer niet genoeg van zn stokpaardjes krijgen met zn howabout PII, AWS, dataportabiliteit, compliancy. Stokpaardjes want het is niet specifiek voor headless. Toch zijn Rob, oudlid en en de auteur het “helemaal eens” met elkaar. Alleen niet duidelijk waarover.
Die houden we erin.
Inderdaad gaat de blog over handel waarbij ik niet reageer op vorm en inhoud van etalage (CMS) maar op de klantbeleving van levering. Stokpaardje gaat eerste reactie dus meer om de logistiek want van magazijn naar distributiecentrum is er meer dan alleen voorraad als we kijken naar de totale organisatorische capaciteit. Ander punt is het digitale residu van alle transacties want er is uiteindelijk nog een digitale papierstroom als we kijken naar de bonnetjes. Laatste paragraaf over centralisatie gaat over de digitale magazijnen voor vorm en inhoud van de administratie waarbij ik wijs op wat lessen uit het verleden. Het gaat bij een persoonlijke klantbeleving tenslotte meer om CRM dan een CMS.
De casus Nebu kent een ander arrest dan Nebula maar de goodwill op de balans wordt grotendeels bepaalt door de relaties die een organisatie heeft. Henry Ford wist dan ook al dat de techneuten sneller stokpaardjes willen want nogmaals hetzelfde rondje in alle cyclische ontwikkelingen heeft ook de plaatselijke afhaalchinees een CMS waarbij je kunt bestellen via de e-mail maar klantbeleving van 2 uur wachten niet voor de positieve reacties zorgt.
Wat ik denk dat Evert ermee bedoelt (en is ieder geval wat ik eronder versta) is dat je een (vakmaterie-)specifieke applicatie van laag 2 en 3) niet moet voorzien van een presentatielaag (laag 1) ofwel grafische gebruikersinterface ofwel GUI’s . Laag 1 vergt andere expertise en heeft een andere levenscyclus. De belangrijkste (software) clients van laag 2 zijn uiteindelijk bovendien eventuele andere lagen 2 en vroeger of later ontstaat de behoefte GUI’sfunctioneel zoveel mogelijkl te vervangen of aan te vullen met Laag 2 gebruikers of wel softwarematige gebruikers.
In onze gevallen gaat veruit het meest geld in de GUI’s zitten terwijj onze toevoegende waarde grotendeels in laag 2/3 zit. Het eerste wat een laag 2/3 moet kunnen is als API-client functioneren zodat je applicatie o.a. opschaalbaar in de richting van meervoudige nodes/instances. Data is nu eenmaak geografisch verspreid en je moet dus backends met elkaar kunnen laten praten, bij voorkeur op identieke wijze als waarmee eventuele GUI’s met een backend node praten.