Wat een discovery moet uitzoeken voordat je een offerte krijgt voor je eCommerce-project

Een vaste prijs die je vóór de discovery krijgt, is een gok met twee cijfers achter de komma. Oneerlijk is dat niet. Het is rekenwerk op basis van aannames, en juist die aannames gaan veranderen. Wat de bouw van een webshop echt kost, hangt af van drie dingen: het datamodel, de koppelingen met andere systemen en de commerciële regels die het systeem moet kunnen verwerken. Heeft een discovery die drie niet op tafel gelegd, dan levert hij geen bedrag op waar je je handtekening onder moet zetten.

Hieronder staat de checklist die een serieuze discovery afwerkt. Bij elk onderdeel lees je wat er in de offerte verandert als het wordt overgeslagen. Gebruik hem om je eigen discovery voor te bereiden, of om te beoordelen of de discovery die je al hebt gehad zijn werk heeft gedaan.

Waarom offertes verschuiven, en welke kant op

Na een discovery gaat een offerte bijna nooit omlaag. Hij gaat omhoog, en steeds om een handvol dezelfde redenen.

Iemand ontdekt dat de prijzen niet uit één prijslijst komen, maar uit een set regels met uitzonderingen. Iemand ontdekt dat het ERP het veld waar de bouw op rekende niet beschikbaar stelt. Iemand ontdekt dat drieduizend producten eigenschappen hebben die alleen in de omschrijving staan. Niets daarvan is uitzonderlijk, en alles is te vinden voordat er een bedrag op papier staat.

Een discovery is er niet om onzekerheid weg te nemen. Hij is er om die onzekerheid van de factuur naar het scopedocument te verplaatsen. Daar kun je er nog over praten, zolang beide partijen nog keuzes hebben.

Checklist één: het commerciële model en de prijsregels

Het onderdeel dat het vaakst wordt onderschat, en dat een offerte het vaakst flink verandert.

• Elke prijs die een product kan hebben, en wat bepaalt welke geldt: catalogusprijs, contractprijs per klantaccount, staffelprijzen, actieprijs, verschillen per valuta en per markt.

• Wie wat mag zien. Ziet elke klant het hele assortiment, of hangt dat af van account, markt of kanaal?

• Betaaltermijnen en betaalmethoden per klanttype, inclusief betalen op factuur als er klanten zijn die zo kopen.

• Btw in elke markt die meedoet, en per markt of prijzen inclusief of exclusief btw worden getoond.

• Acties en hoe ze samengaan. Welke kortingen je mag stapelen en welke niet. Die lijst is langer dan de meeste teams denken, en staat zelden ergens op papier.

• Minimale bestelhoeveelheden, bestelveelvouden en alle regels over wie hoeveel mag bestellen.

Wat er verandert als je dit overslaat: de prijslogica komt pas tijdens de bouw boven water, meestal als verzoek nadat het datamodel al vastligt. Dat is de meest voorkomende reden voor een scopegesprek halverwege het project. Prijsregels raken namelijk tegelijk het assortiment, de winkelwagen, de checkout en de rapportages.

Checklist twee: het datamodel en het assortiment

• Aantal producten, aantal varianten en hoe de opties echt in elkaar zitten. Duizend producten met elk vier opties gedragen zich anders dan vierduizend enkelvoudige producten.

• Waar elke producteigenschap nu staat. In vaste velden, in eigen velden of als lopende tekst in de omschrijving. Dat laatste los je niet op door velden aan elkaar te koppelen. Het is een migratieproject op zich.

• Configureerbare producten, bundels en sets, en hoe hun prijs en beschikbaarheid worden berekend.

• Welk systeem per veld de bron is. Het eCommerce-platform, het ERP, het PIM of een spreadsheet die iemand bijhoudt. Die spreadsheet noemen is niet gênant. Hem in maand drie ontdekken is duur.

• Hoe klanten en accounts zijn opgebouwd. Zijn je klanten particulieren, bedrijven met vestigingen en gebruikers, of allebei?

• Beeld: hoeveel foto's per product, wie ze maakt, en of ze er zijn voor het hele assortiment of alleen voor de producten die je nu promoot.

Wat er verandert als je dit overslaat: de bouw gaat uit van nette, gestructureerde data en krijgt lappen tekst. Eigenschappen uit die tekst halen is traag handwerk, en het komt terecht bij een merchandisingteam dat het niet zag aankomen.

Checklist drie: de koppelingen

• Elk systeem waarmee de webshop data moet uitwisselen, bij naam, met versie en eigenaar. ERP, PIM, WMS, kassasysteem, CRM, marketingautomatisering, boekhouding, verzending en retouren.

• Per systeem: richting, frequentie en volume. Eén keer per nacht de ene kant op is iets heel anders dan vrijwel realtime heen en weer. Dat verschil is niet klein.

• Wat de API echt kan, niet alleen dat er een is. Is er documentatie, geven de endpoints de velden die je nodig hebt, wat zijn de rate limits, en wie bij de leverancier kan een vraag beantwoorden?

• Wat er gebeurt als een synchronisatie mislukt. Wordt het opnieuw geprobeerd, gaat er een melding uit, en naar wie? Geen antwoord hebben is hier ook een bevinding.

• Middleware: is die er, blijft die bestaan, en wie onderhoudt hem?

• Authenticatie en toegang, inclusief wie per systeem inloggegevens kan uitgeven en hoe lang dat meestal duurt.

Wat er verandert als je dit overslaat: de koppelingen staan als één regel in de offerte en worden een project op zich. Het patroon is steeds hetzelfde. De gedocumenteerde API van het ERP blijkt precies één veld niet te leveren waar het commerciële model op leunt, en de omweg is dan groter en minder voor de hand liggend dan je hoopt.

Checklist vier: wat er al is, en de migratie

• Een volledige crawl van de huidige site, met een complete lijst van URL's in plaats van alleen de sitemap. Die twee verschillen, meestal flink.

• Een aanpak voor de redirects, met als afspraak één-op-één waar een vergelijkbare pagina bestaat.

• Een overzicht van alle content: wat gaat mee, wat wordt herschreven, en wie schrijft het? Voor content is in een bouwtraject het vaakst niemand aangewezen.

• Historische data: hoeveel bestelgeschiedenis gaat mee, en komen klantaccounts en wachtwoorden over?

• Bestaand maatwerk, gesplitst in wat bedrijfslogica bevat en wat alleen om de beperkingen van het oude platform heen werkt. Die tweede groep hoort niet opnieuw gebouwd te worden. Dat vroeg zeggen is meer waard dan het later zeggen.

• SEO-nulmeting: huidige posities, verkeer en best presterende pagina's vastleggen voordat er iets verandert, zodat je na de livegang kunt meten wat er verschuift.

Wat er verandert als je dit overslaat: de redirects worden gebaseerd op een sitemap waar een derde van de geïndexeerde pagina's in ontbreekt. Het verlies aan verkeer na de livegang merk je dan pas als het te laat is om de oorzaak nog te vinden. Welke migratieroute je kiest, lees je uitgebreider in ons artikel over overstappen naar een nieuw platform zonder dat je bedrijf eronder lijdt.

Checklist vijf: eigenaarschap en wie beslist

Het lijkt projectadministratie, maar het gedraagt zich als een technische afhankelijkheid.

• Wie per onderdeel akkoord geeft. Design, commerciële regels, data, koppelingen. Eén naam per onderdeel.

• Hoe lang een besluit duurt in jouw organisatie, eerlijk gezegd. Twee weken voor een akkoord in een bouwtraject van twaalf weken is geen detail. Het is een gegeven waar de planning mee moet rekenen.

• Wie eigenaar is van de productdata en tijdens het project ook tijd heeft om eraan te werken.

• Hoeveel interne capaciteit er is toegezegd, in uren en niet in goede bedoelingen.

• Welke stakeholder nog niet aan tafel heeft gezeten. Meestal zijn dat finance en klantenservice. Wie ze aan het begin buiten de deur houdt, krijgt hun eisen pas aan het eind.

Wat er verandert als je dit overslaat: de planning houdt stand tot hij jouw goedkeuringsproces tegenkomt, en vangt daarna het verschil op. Dit is de meest voorkomende oorzaak van vertraging waarvoor geen van beide partijen de ander de schuld kan geven.

Zo herken je een echte discovery

Leg elke discovery langs deze toetsen, ook die van ons.

Ze wilden je systemen zien, niet alleen erover horen 

Een discovery die alleen uit meetings bestaat, heeft jouw beschrijving van je data voor waar aangenomen. De verrassingen komen pas boven als iemand de echte export van het assortiment en de echte API-documentatie leest.

Ze stelden ongemakkelijke vragen over eigenaarschap 

Wie beslist, wie heeft er tijd voor, welke stakeholder is nog niet gehoord. Een bureau dat die vragen ontwijkt, beschermt de verkoop en niet het project.

Ze vertelden je iets wat je niet wilde horen 

Concludeert een discovery dat alles eenvoudig is en het oorspronkelijke budget precies klopt? Dan is het óf echt een simpel project, óf er is niet goed gekeken.

Ze hielden uit elkaar wat ze weten en wat ze aannemen 

Een scopedocument dat zijn aannames expliciet benoemt, is meer waard dan een document dat klinkt als zekerheid. Over die aannames ga je later namelijk onderhandelen.

Ze leverden documenten op, geen verkooppraatje 

Wat een discovery oplevert, hoort een datamodel, een overzicht van de koppelingen, een besluitenlog en een risicoregister met eigenaren te bevatten. Een presentatie met een prijs op de laatste slide is gewoon een offerte die zichzelf discovery noemt.

Ze durfden af te raden om te bouwen 

Soms is de eerlijke uitkomst dat verbeteren op het huidige platform kleiner en goedkoper is, of dat het knelpunt in de organisatie zit en niet in de techniek. Over dat gesprek gaat ons artikel over de groeikeuzes in eCommerce die merken te laat maken.

Wat je aan het eind in handen moet hebben

Zes documenten. Je moet ze aan een ander bureau kunnen geven, en dat bureau moet het project dan begrijpen.

1. Een datamodel van producten, varianten, eigenschappen, klanten en accounts, met per veld waar het vandaan komt.

2. Een overzicht van de koppelingen, met per systeem de richting, de frequentie en de eigenaar.

3. De commerciële regels op papier: prijzen, wie wat mag zien, acties, betaalvoorwaarden en hoe ze op elkaar inwerken.

4. Een scope die scheidt wat erin zit, wat er uitdrukkelijk buiten valt en wat is aangenomen.

5. Een risicoregister met eigenaren bij naam en een maatregel per risico, geen algemene lijst.

6. Een plan voor de migratie en het behoud van je vindbaarheid, inclusief de lijst van URL's en de aanpak van de redirects.

Of je de documenten kunt meenemen, is de toets die telt. Een discovery waarvan alleen het bureau dat hem deed de uitkomst begrijpt, heeft je risico niet verkleind. Hij heeft het bij één partij gelegd.

Voordat je voor een offerte tekent

Vraag je offertes op voor een nieuwe webshop of een overstap naar een ander platform? Dan werkt deze volgorde: eerst de discovery, dan de prijs. Spreek de discovery af als los traject en betaal hem apart, zodat de uitkomst van jou is, wie er ook gaat bouwen.

De eCommerce-discovery van Flatline brengt het datamodel, de koppelingen en de prijsregels in kaart voordat de scope vastligt. Je krijgt de zes documenten hierboven, in een vorm die je kunt meenemen. We zijn Shopify Platinum Partner, en de discovery is ook bruikbaar als een ander bureau gaat bouwen. Plan een afgebakende discovery voordat je voor een offerte tekent.

Veelgestelde vragen

Hoe lang duurt een eCommerce-discovery? 

Voor een middelgroot project twee tot vier weken doorlooptijd, met een paar dagen geconcentreerd werk van je eigen team. Korter betekent meestal dat de systemen zijn beschreven in plaats van onderzocht. Duurt het veel langer, dan ligt de scope van de bouw zelf vaak nog niet vast. Dat is een ander gesprek.

Moet je betalen voor een discovery? 

Een betaalde discovery levert documenten op die van jou zijn en die je aan elk bureau kunt geven, ook aan een bureau dat je uiteindelijk niet inhuurt. Een gratis discovery hoort bij de verkoop. Waardeloos is hij daarmee niet, maar hij gaat nooit dieper dan wat het bureau ervoor wil investeren. Betaal je, leg dan schriftelijk vast dat de uitkomst van jou is.

Wat als een bureau een offerte geeft zonder discovery? 

Vraag op welke aannames het bedrag rust en wat het zou veranderen. Een goed antwoord noemt concrete aannames over data, koppelingen en prijsregels. Een vaag antwoord betekent dat het bedrag gaat schuiven zodra die dingen worden onderzocht. En het schuift omhoog.

Kun je de discovery zelf doen? 

Deels, en dat loont. De controle van het assortiment, het overzicht van je systemen en de prijsregels op papier kan je team allemaal afronden voordat je iemand inschakelt. Elke discovery daarna wordt er korter door. Lastiger om zelf te beoordelen is of de koppelingen haalbaar zijn. Daarvoor moet je weten wat het nieuwe platform wel en niet kan.

De belangrijkste punten

• Na een discovery gaan offertes omhoog, steeds om dezelfde paar redenen: prijsregels die niemand kende, velden voor koppelingen die niet bestaan, en producteigenschappen die in lopende tekst staan in plaats van in vaste velden.

• Drie onderdelen bepalen de kosten meer dan wat ook: de commerciële regels, het datamodel en de koppelingen. Een offerte zonder alle drie is rekenwerk op basis van aannames.

• Eigenaarschap en wie beslist horen in de discovery thuis. Lange goedkeuringsrondes en datawerk waar niemand voor is aangewezen, zijn de meest voorkomende oorzaken van vertraging waarvoor geen van beide partijen de ander de schuld kan geven.

• Beoordeel een discovery op wat hij oplevert en of je dat kunt meenemen. Je risico wordt pas kleiner met een datamodel, een overzicht van de koppelingen, de commerciële regels, een scope, een risicoregister en een migratieplan waar een ander bureau mee verder kan.

De discovery is het goedkoopste deel van een bouwtraject, en het deel met de meeste invloed op alles wat erna komt. Een paar weken uitzoeken wat er echt klopt aan je data, je systemen en je commerciële regels maakt het verschil tussen een offerte waar je iemand aan kunt houden en een bedrag dat in maand twee begint te schuiven.