Je catalogus automatisch bijgewerkt vanuit leveranciers- of voorraaddata. Prijzen, beschikbaarheid, specificaties. Twee cases, op nacalculatie.
Een productcatalogus die automatisch bijwerkt haalt prijzen, beschikbaarheid en specificaties uit je leveranciers- of voorraaddata en zet die door naar je site of platform. Zonder dat iemand per artikel overtypt. EIGHTY8 bouwt die voedingslijn met vaste regels voor wat automatisch mag wijzigen en wat eerst een mens ziet.
De leverancier stuurt een nieuwe prijslijst; de voorraad schuift; een artikel wijzigt van specificatie. Elke keer hetzelfde ritueel: het bestand openen, handmatig vergelijken met wat op de site staat, per artikel overtypen. En hopen dat je niets mist. Wat er doorheen glipt is voorspelbaar: een oude prijs die online blijft staan tot een klant erop afrekent, een artikel in de etalage dat al maanden niet leverbaar is, en omschrijvingen die in twee versies door het leven gaan.
De pijn groeit met het assortiment. Bij een paar honderd artikelen is het nog handwerk met een checklist; bij duizenden is het een baan op zich, en het gebeurt altijd te laat: de catalogus klopt met de werkelijkheid van vorige week, niet met die van vandaag. En het is precies het werk dat valt op de drukste dagen, want dan heeft niemand er tijd voor.
De voedingslijn begint bij de bron: een leveranciersfeed, een export of een koppeling met het systeem waar de voorraad al leeft. Per veld ligt vast waar hij vandaan komt en wat er mag gebeuren. Kleine prijsschuiven lopen direct door; grote sprongen of nieuwe artikelen komen eerst in een controle-lijst, zodat iemand met verstand van het assortiment een blik werpt voordat ze zichtbaar worden. Niet-leverbare artikelen verdwijnen uit de etalage op een vast moment in plaats van stilletjes te blijven staan.
Een taalmodel heeft hier één rol en niet meer: tekst. Omschrijvingen die uit de bron rommelig binnenkomen, kan hij leesbaar herformuleren. Als concept, met het origineel ernaast. Prijzen en beschikbaarheid komen nooit uit een model, maar uit rekenregels en de bron; daar is geen interpretatie nodig en dus geen interpretatie toegestaan. Elke wijziging wordt gelogd: wat is veranderd, wanneer, vanuit welke bron, zodat je achteraf kunt uitleggen waar een prijs vandaan kwam.
Wat de mens blijft doen: het assortiment zelf. Wat je verkoopt, wat je schrapt en welke merken je voert, zijn beslissingen van het bedrijf; de automatisering zorgt alleen dat de catalogus de werkelijkheid volgt in plaats van erachteraan te hobbelen.
Alles hangt aan de kwaliteit van de bron: een koppeling die elke nacht een handmatig onderhouden spreadsheet opnieuw inleest, automatiseert juist de fouten die erin zitten. In de discovery bekijken we waar je productgegevens nu leven, wie ze bijwerken en welke velden betrouwbaar genoeg zijn om automatisch door te zetten. En welke velden eerst gesaneerd moeten worden. De kaarten hieronder volgen uit dat beeld.
Het werkt voor bedrijven met een bewegend assortiment: webshops waar prijzen en voorraad schuiven, groothandels die hun leveranciers volgen, autobedrijven met een voorraad die per week verandert. Hoe vaker de catalogus verandert en hoe meer artikelen, hoe sneller het overtypen zichzelf terugverdient. En hoe kleiner de kans dat er foutieve informatie online staat.
Het werkt níet als de leveranciersdata zelf rommelig en zonder structuur is. Dan is de eerste stap afspraken maken over het bestand, geen automatisering eroverheen. Ook niet voor een klein en stabiel assortiment: wie twintig producten verkoopt die twee keer per jaar van prijs wisselen, is met de hand sneller en goedkoper klaar. En een catalogus die alleen indruk moet maken zonder prijzen of voorraad, heeft een andere oplossing nodig dan een voedingslijn.
Twee casepagina's laten dit zien: een duurzaamheidsbedrijf wiens catalogus actueel blijft vanuit zijn eigen data (prijzen, beschikbaarheid, specificaties) en een autobedrijf waar de voertuigcatalogus uit de eigen voorraad wordt gevoed, inclusief de status van elk voertuig. Wat je daar níet leest: assortimentsgroottes en leveranciersafspraken, want die horen bij die bedrijven zelf.
Het aantal bronnen, de structuur van hun data en de regels voor wat automatisch mag bepalen de omvang. We lopen de bronnen in de discovery langs, zetten de mappings en uitzonderingen op papier en rekenen af op nacalculatie; een extra leverancier of categorie erbij is later een afgebakende toevoeging, geen herbouw.
Deels. Technische specificaties komen uit de bron. Die zijn feiten en worden overgenomen, niet geschreven. Losse omschrijvingsteksten die rommelig of incompleet binnenkomen, kan een taalmodel leesbaar herformuleren, maar als concept met het origineel ernaast, zodat iemand met kennis van het assortiment ze goedkeurt. Prijzen en beschikbaarheid worden nooit door een model geschreven; die zijn rekenwerk, en rekenwerk heeft geen interpretatie nodig.
Dan faalt de voedingslijn luid, niet stil. De laatste goede stand van de catalogus blijft online, het gat wordt gemarkeerd en er gaat een melding naar de mens die er iets mee kan. Wat nooit gebeurt, is een catalogus die er compleet uitziet terwijl er ergens een leverancier of een dag ontbreekt. Een stille halve catalogus is het ergst denkbare falen, en die klasse fouten sluiten we bewust uit.
Ja, per merk, categorie of artikel. Soms is er een actieprijs die de leveranciersprijs moet overschrijven, soms een assortiment waarvan de marges vastliggen. Dat soort uitzonderingen leggen we als vaste regels vast, met een lijst waarop je ze terugkunt zien. Wat er niet komt, is een uitzondering die leeft in het hoofd van één collega en verdwijnt zodra hij een dag vrij is.
De eerlijke vuistregel: hoe meer artikelen en hoe vaker prijzen of voorraad schuiven, hoe sneller het terugverdient. Bij duizenden artikelen die wekelijks bewegen is het handwerk niet vol te houden; bij een klein en stabiel assortiment is overtypen prima en zeggen we dat ook. De omvang van de bronnen en het aantal leveranciers bepalen het werk, en dus de offerte. Die schatten we vooraf op nacalculatie.
EIGHTY8