De manier waarop je je Channable-account indeelt bepaalt voor een groot deel hoe prettig het werkt naarmate je groeit. Een doordachte projectstructuur betekent dat nieuwe producten vanzelf op de juiste plek belanden, dat je rules begrijpelijk blijven en dat je niet bij elke uitbreiding hoeft te puzzelen. Een rommelige structuur betekent het omgekeerde: telkens meer uitzonderingen, rules die elkaar in de weg zitten en een catalogus die je niet meer overziet. Deze gids laat zien hoe je projecten, imports en exports zo opzet dat je catalogus overzichtelijk blijft groeien.
Ben je net begonnen, lees dan eerst de gids over beginnen met Channable. Deze gids gaat een stap verder: niet hoe je iets aanzet, maar hoe je de fundering legt waarop alles daarna rust.
01. De bouwstenen: account, project, import, export
Channable kent een vaste hiërarchie. Bovenaan staat je account. Daaronder leven projecten. Elk project heeft één of meer imports die data binnenhalen, een rule-laag die die data transformeert, en exports die het resultaat naar kanalen sturen. Wie deze vier lagen scherp uit elkaar houdt, snapt meteen waar een wijziging thuishoort.
De valkuil is om alles door elkaar te laten lopen: een rule die eigenlijk in de import had gemoeten, of een filter dat in de export hoort maar in een rule is gepropt. Houd per laag vast wat hij doet. De import gaat over binnenhalen, de rules over transformeren, de export over verzenden naar een specifiek kanaal.
Waarom de hiërarchie ertoe doet
- Een wijziging in de bron raakt alle exports tegelijk, dus daar zit je grootste hefboom
- Een rule die je breed inzet, werkt door op elk kanaal dat eronder hangt
- Een export-specifiek filter raakt alleen dat ene kanaal, precies zoals bedoeld
02. Eén project of meerdere?
De meeste MKB-sellers beginnen met één project voor hun hele catalogus. Dat is bijna altijd de juiste keuze: één bron, één rule-set en alle kanalen bij elkaar. Je houdt overzicht en je hoeft logica maar op één plek te onderhouden.
Splitsen wordt pas zinnig als een deel van je assortiment fundamenteel anders is. Denk aan een B2B-lijn met eigen prijzen, een dropship-assortiment dat uit een andere bron komt, of producten die nooit naar dezelfde kanalen gaan. Het signaal dat je te lang in één project zit: je bouwt steeds meer conditionele rules om twee soorten producten uit elkaar te houden.
03. Imports ordenen
Een project kan meerdere imports combineren, bijvoorbeeld je hoofdcatalogus uit de shop en een aanvullende voorraadbron. Houd hierbij één principe vast: er is altijd één leidende bron voor elk veld. Komt prijs uit je shop, dan komt prijs niet ook nog ergens anders vandaan. Zo voorkom je dat twee bronnen elkaar tegenspreken.
Hoe een feed technisch van bronveld naar kanaalveld loopt, lees je in de gids over de architectuur van een datafeed. De keuze tussen feed, API of plug-in als importmethode behandelt het blog Channable import-bronnen vergelijken.
Praktische ordening van imports
- Geef elke import een herkenbare naam, niet de standaard URL als label
- Stel de verversfrequentie per import af op het soort data: voorraad vaak, catalogus minder vaak
- Controleer na elke nieuwe import of velden overlappen met een bestaande bron
04. Exports en kanalen indelen
Elke export is de brug naar één kanaal: Google Shopping, Bol, Amazon of een ander platform. De kunst is om gedeelde logica in de rule-laag te houden en alleen het echt kanaal-specifieke in de export af te handelen, zoals een laatste categorie-filter of een kanaaleigen attribuut-mapping.
Wie meerdere kanalen bedient, doet er goed aan eerst de gids over multi-channel verkopen te lezen. Voor de inrichting van die meerdere koppelingen op maat bestaat de multi-channel dienst.
05. Rules organiseren zodat ze meegroeien
Rules draaien van boven naar beneden, en die volgorde is de ruggengraat van een project. Een logische opbouw is: eerst rules die velden samenstellen, dan rules die opschonen, dan rules die filteren en uitsluiten. Wie deze volgorde aanhoudt, voorkomt dat een latere rule het werk van een eerdere ongedaan maakt.
Geef rules een vaste naamgeving, bijvoorbeeld een prefix per functie. Een set die er na een jaar nog leesbaar uitziet, bespaart je elke keer dat je iets aanpast. Voor de werking van condities en transformaties zelf is de gids over de rules-engine de logische verdieping.
06. Meegroeien zonder herbouw
Een goed gestructureerd project hoef je bij groei niet opnieuw op te bouwen, alleen uit te breiden. Nieuwe producten stromen via je import binnen en pakken automatisch de bestaande rules op. Een nieuwe categorie vergt hooguit een mapping erbij. Een nieuw kanaal is een extra export op dezelfde basis.
De test of je structuur klopt: kun je een nieuw kanaal toevoegen zonder bestaande rules te slopen? Lukt dat, dan staat je fundering. Lukt dat niet, dan zit er ergens te veel kanaal-specifieke logica op de verkeerde laag.
07. Zelf doen of uitbesteden?
De projectstructuur zelf opzetten is goed te doen, zeker met één project en een handvol kanalen. Het denkwerk zit niet in de techniek maar in de keuzes: wat hoort waar, en welke logica deel je. Wie tijd heeft om er rustig over na te denken, komt een heel eind.
Wordt het complexer, met meerdere bronnen, een B2B-lijn of een dropship-stroom, dan loont het om de fundering in één keer goed te laten neerzetten. Een doordachte structuur vooraf bespaart later veel herstelwerk. Daarvoor bestaat de setup-dienst. Twijfel je over de juiste indeling voor jouw situatie, leg het dan voor via contact en je krijgt een eerlijk advies, ook als zelf doen slimmer is.
08. Veelgestelde vragen
Voor de meeste sellers is één project voor de hele catalogus het beste startpunt. Eén bron, eén set rules en alle kanalen op één plek houdt het overzichtelijk. Pas wanneer een productgroep echt afwijkende logica nodig heeft, bijvoorbeeld een aparte B2B-lijn of een dropship-assortiment met een eigen bron, splits je in meerdere projecten.
Splits zodra een deel van je assortiment een fundamenteel andere import, andere prijslogica of andere kanalen heeft dan de rest. Een goede toets: als je merkt dat je voortdurend conditionele rules bouwt om twee soorten producten uit elkaar te houden binnen één project, is dat het signaal dat ze in aparte projecten thuishoren.
Geef rules een vaste naamgeving, groepeer ze per functie en houd de volgorde logisch: eerst opbouw, dan opschoning, dan uitsluiting. Documenteer waarom een rule bestaat, niet alleen wat hij doet. Zo blijft de set begrijpelijk, ook als je over een half jaar terugkomt of het werk overdraagt aan iemand anders.
Exports horen bij het project waarin ze leven, dus je deelt ze niet rechtstreeks tussen projecten. Wel kun je een doordachte rule-structuur kopiëren als basis voor een nieuw project. Daarom loont het om je eerste project schoon en logisch op te zetten: het wordt het sjabloon waarop alles wat erna komt verder bouwt.
Verder in de kennisbank: De architectuur van een datafeed: de complete gids · De rules-engine van Channable doorgronden: de complete gids · Beginnen met Channable: de complete gids