Overdracht of vaste partner? Kies je Shopify-model voor na de livegang vóór je tekent
Door Robin Laseur
Een model voor Shopify-ondersteuning na de livegang kies je per werkstroom: elk onderdeel gaat naar het team met de kennis, de tijd en de verantwoordelijkheid om het te dragen. Een volledige overdracht werkt als je interne team het aankan. Een vaste partner past als je blijvend specialisten nodig hebt. Een hybride model verdeelt het eigenaarschap. Leg dat vast voordat je tekent, niet in de laatste week voor de livegang.
Vaak lijkt de keuze simpel: je houdt het bureau aan of je haalt de webshop in huis. In de praktijk kunnen merchandising, development, koppelingen, incidenten en optimalisatie elk een andere eigenaar nodig hebben. Begin bij de verantwoordelijkheden, niet bij een retainerpakket.
Wat valt er eigenlijk onder Shopify-ondersteuning na de livegang?
Ondersteuning na de livegang bestaat uit vier lagen: stabilisatie direct na de lancering, operationele support, gepland wijzigingswerk en doorlopende verbetering. Elke laag vraagt om andere reactietijden, andere vaardigheden en andere commerciële afspraken. Gooi je ze op één hoop onder de noemer ‘support’, dan weet niemand meer wat het bureau heeft beloofd en wat je eigen team moet leveren.
Houd die lagen dus uit elkaar. Stabilisatie kan onderdeel zijn van de implementatie. Operationele support kan werken met serviceniveaus. Gepland wijzigingswerk kan uit een retainer komen of een eigen scope krijgen. En verbetering vraagt om bewijs en om iemand die voor het resultaat staat.
Shopify houdt een developer changelog bij met updates, wijzigingen waarop je moet handelen, breaking changes en functies die verdwijnen. Dat maakt een retainer niet verplicht. Maar iemand moet wel de relevante platformwijzigingen volgen, inschatten wat ze betekenen en ingrijpen als dat nodig is.
Waarom kies je het model al vóór je tekent?
Omdat het model overal in doorwerkt: de architectuur, de documentatie, de training, de bezetting, de toegang, de commerciële voorwaarden en de vraag wanneer het project af is. Een bureau dat bouwt voor een intern team dat het straks overneemt, maakt andere keuzes dan een bureau dat na de livegang verantwoordelijk blijft voor de technische roadmap.
Wie laat beslist, krijgt voorspelbare gaten. Je interne team heeft dan geen deploymenttoegang, kent de koppelingen niet of heeft geen tijd voor releases, terwijl het bureau ervan uitgaat dat zijn taak bij de livegang ophield. Een algemene belofte om “de webshop te ondersteunen” lost dat niet op.
Het gewenste model moet het project vanaf de discoveryfase sturen:
Architectuur, documentatie en training sluiten aan bij wat de toekomstige eigenaar kan.
Accounts, repositories, omgevingen en leveranciersrelaties hebben elk een eigenaar met naam en toenaam.
Bij de acceptatie maak je onderscheid tussen fouten en nieuwe wensen.
Het livegangplan regelt wie de stabilisatie dekt en wanneer die fase klaar is.
De commerciële voorwaarden passen bij hoeveel werk er is, hoe urgent het is en hoe onzeker.
De richtlijnen van Shopify voor bureauprocessen noemen overdracht en training, testcases voor koppelingen, kwaliteitscontrole en roadmapplanning als werk dat baat heeft bij vastgelegde processen. De les is eenvoudig: een overdracht is geen laatste meeting. Het is een resultaat van het project, en dat moet je ontwerpen en testen.
Zet het model daarom op je lijst met vragen voor een Shopify-bureau vóór de discovery, zolang scope en commerciële opties nog open liggen.
Welke modellen zijn er voor Shopify na de livegang?
In de praktijk zijn er drie: volledige overdracht, een vaste bureaupartner en hybride eigenaarschap. Welke past, hangt af van wat je team kan, hoe het werk binnenkomt, hoeveel operationeel risico er is en hoe vaak er iets verandert. Kies waar nodig per werkstroom. Eén webshop kan interne merchandising combineren met development door het bureau en een roadmap die je samen bewaakt.
Kies niet op het etiket. De ene retainer levert andere capaciteit, vaardigheden, reactietijden en betrokkenheid bij de roadmap dan de andere. Ook overdrachten verschillen sterk in documentatie en training. Vergelijk wat er in de praktijk gebeurt.
Wanneer werkt een volledige overdracht?
Een volledige overdracht werkt als je interne team de webshop kan draaien, veelvoorkomende storingen kan opsporen, leveranciers kan aansturen, veilig wijzigingen kan uitrollen en de roadmap kan dragen, zonder terug te vallen op kennis van het bureau die nergens is vastgelegd. Je draagt bewust de regie en de kennis over. Dat is iets anders dan een implementatiecontract dat gewoon afloopt.
Je team hoeft niet alle disciplines in huis te hebben die de webshop hebben gebouwd. Het moet wel een betrouwbare route naar specialistische hulp hebben. Controleer vijf voorwaarden voordat je voor een volledige overdracht kiest:
Kennis: Er zijn concrete mensen die Shopify, de storefront, de gekoppelde systemen en de releaseprocessen kennen, voor zover hun rol dat vraagt.
Tijd: Die mensen hebben ruimte voor onderhoud, incidenten en roadmapwerk.
Mandaat: Het is duidelijk wie beslist over product, techniek en commercie.
Bezetting: Je kunt ook reageren als iemand afwezig is, tijdens drukke verkoopperiodes en bij zware incidenten.
Toegang voor externen: Specialisten kunnen aan de slag zonder afhankelijk te zijn van accounts van het bureau of een inrichting die nergens beschreven staat.
Wat hoort er in een Shopify-overdrachtspakket?
Een bruikbaar overdrachtspakket bevat alles wat je nodig hebt om de live webshop te draaien en aan te passen: bestanden, toegang, kennis en geteste procedures. Of het deugt, blijkt uit oefeningen in de praktijk. Laat iemand een release uitrollen, een orderflow natrekken of een nagebootste storing in een koppeling oplossen.
Loop in elk geval deze onderdelen na:
Eigenaarschap van en toegang tot Shopify, domeinen, repositories, apps, analytics en deploymentdiensten.
Architectuur- en datastroomdiagrammen van de storefront en de belangrijkste gekoppelde systemen.
Procedures voor omgevingen, releases, goedkeuring, rollbacks en spoedwijzigingen.
Runbooks voor koppelingen: authenticatie, monitoring, retries, storingen en contactpersonen bij leveranciers.
Testresultaten, bekende fouten, uitgestelde scope, technische schuld en afspraken over herstel.
Instructies voor het theme, het design system, het contentmodel, analytics en veilig merchandisen.
Training per rol, escalatieroutes en een definitief overzicht van wie waarvoor verantwoordelijk is.
Laat de toekomstige eigenaren vóór de acceptatie een paar typische taken uitvoeren. Documentatie alleen bewijst niet dat je team klaar is om het over te nemen.
Wanneer kies je voor een vast Shopify-bureau op retainer?
Een vaste partner is zinvol als je steeds opnieuw specialistisch werk hebt, als koppelingen of releases echt risico dragen, als de roadmap vol wijzigingen staat of als je team te klein is voor alle disciplines. De waarde zit in helder eigenaarschap en continuïteit. Niet in het automatisch aanhouden van het bureau dat de webshop heeft gebouwd.
Door die continuïteit hoeft niemand zich telkens opnieuw in te lezen in architectuurkeuzes en afhankelijkheden. Gereserveerde capaciteit helpt ook teams die development, UX, data, koppelingen of strategisch advies nodig hebben, maar die dat niet allemaal zelf in huis kunnen halen.
Komt het werk maar af en toe voor, of kan je eigen organisatie het zelf, dan is een retainer lastiger te verdedigen. Een maandbedrag zegt niets over of iemand klaarstaat.
Maak eerst onderscheid tussen deze categorieën voordat je een retainer beoordeelt:
Kijk daarna wat de retainer echt belooft:
Welke rollen, welk senioriteitsniveau, en of de capaciteit vast toegewezen, gereserveerd of op basis van best effort is.
Hoeveel capaciteit erin zit, de looptijd, het meenemen van uren, de opzegtermijn en wat er gebeurt met ongebruikte uren.
Supporttijden, prioriteitsniveaus, reactietijden en escalatieroutes.
Het verschil tussen reageren, een tijdelijke oplossing, herstel en een definitieve oplossing.
Wat voorgaat als incidenten en roadmapwerk tegelijk aandacht vragen.
Hoe afstemming met derden, rapportage en bezetting in piekperiodes geregeld zijn.
De plicht om te documenteren en de procedure voor overdracht aan een ander team.
Een goede vaste partner zorgt dat je altijd kunt vertrekken: met actuele documentatie, toegang die bij jou ligt en een vastgelegde exitprocedure.
Wanneer is een hybride model beter?
Een hybride model past bij een intern team dat de dagelijkse commerciële operatie zelf aankan, maar voor development, koppelingen, grote releases of gestructureerd verbeterwerk hulp van buiten nodig heeft. Je besteedt het bureaubudget dan aan schaarse vaardigheden. De kennis van je business en de dagelijkse commerciële keuzes blijven binnen je eigen organisatie.
Hybride betekent niet automatisch: content intern, development bij het bureau. Verdeel het eigenaarschap op basis van je team en je risicoprofiel. De ene organisatie doet de front-end development zelf. De andere laat het bureau de releases van Shopify, ERP, PIM en POS op elkaar afstemmen.
Met een eigenaarschapsmatrix maak je die verdeling toetsbaar:
Het grootste risico zit op de grens waar niemand eigenaar van is. “Gedeeld” mag nooit betekenen dat beide partijen op elkaar wachten. Leg voor elk proces dat over teams heen loopt vast wie eindverantwoordelijk is, wie moet bijdragen, wie beslist, waar het werk wordt overgedragen en waar je escaleert.
Hoe kies je tussen overdracht, retainer en hybride?
Breng in kaart welk werk steeds terugkomt, welke vaardigheden het vraagt, hoe sterk de vraag schommelt, hoe kritisch het is en hoeveel tijd je team heeft. Wijs per werkstroom een eigenaar aan en kies daarna de voorwaarden die daarbij passen. Zo kunnen verschillende lagen van één eCommerce-operatie in de praktijk verschillende eigenaren en afspraken hebben.
Gebruik deze zeven vragen als toets voordat je beslist:
Welk werk is er na de livegang? Maak onderscheid tussen dagelijkse operatie, incidenten, onderhoud, releases en verbeteringen.
Welke vaardigheden vraagt dat werk? Neem alleen de disciplines mee die een werkstroom echt nodig heeft.
Wat heb je zelf in huis? Kijk naar concrete mensen en hun beschikbare tijd, niet naar vacatures die je nog hoopt te vullen.
Wat kost vertraging? Een kritiek probleem met orders of voorraad vraagt om een andere dekking dan een verbetering in het design.
Hoe grillig is de vraag? Terugkerend werk, incidenten en losse projecten vragen elk om andere afspraken.
Hoe vaak verandert het platform? Met een drukke roadmap voor meerdere markten moet er meer worden afgestemd.
Kan het eigenaarschap zonder gedoe over? Controleer documentatie, toegang, afhankelijkheden en overstapkosten.
Beoordeel elke werkstroom apart. Vier gebieden intern, twee bij een vaste partner en één als los project: ook dat kan een samenhangend model zijn.
Wat moet het contract regelen over de periode na de livegang?
Beschrijf stabilisatie, garantie, doorlopende support, eigenaarschap, servicemeting, commerciële grenzen en de exit als verplichtingen die je kunt controleren. “Doorlopende support” en “voorrang” blijven vaag zolang niet vastligt wat er gedekt is, wat een actie in gang zet, wie waarvoor verantwoordelijk is en hoe de capaciteit werkt. Het contract moet ook zeggen hoe de verantwoordelijkheid verschuift als de implementatie klaar is.
Zorg dat dit helder is voordat je tekent:
Wie de stabilisatie bemant, wat die dekt, wanneer die eindigt en op basis van welke criteria.
De garantieperiode, wat als fout geldt, wat is uitgesloten en hoe herstel verloopt.
Servicetijden, prioriteitsniveaus, reactietijden en escalatiekanalen.
Of de normen gaan over bevestiging, een tijdelijke oplossing, herstel of een definitieve oplossing.
Capaciteit, tarieven, het meenemen van uren, goedkeuring van meerwerk en herprioritering.
De grenzen tussen incidenten, fouten, onderhoud, wensen en projecten.
Wie verantwoordelijk is voor kritieke afhankelijkheden bij jou, het bureau, het platform en leveranciers.
Het eigendom van bestanden, accounts, data, inloggegevens en documentatie.
Rapportage, opzegging, offboarding, kennisoverdracht en het intrekken van toegang.
Reactietijd is geen oplostijd. Een bureau kan een incident snel bevestigen en toch afhankelijk zijn van het platform, een app-leverancier of een systeem aan jouw kant. Leg vast wat het bureau zelf in de hand heeft, hoe het anderen aanstuurt en hoe je op de hoogte blijft.
Bekijk deze voorwaarden als je offertes van Shopify-bureaus vergelijkt. De implementatieprijs zegt pas iets als ook zichtbaar is wie de webshop daarna draait en wat dat kost.
Wanneer past Flatline als partner na de livegang?
Flatline kan passen bij een Shopify-operatie die één regie nodig heeft over strategie, design, development, connectors, PIM, ERP of WMS, headless architectuur of POS. Die breedte telt als het werk na de livegang over die grenzen heen gaat. Voor af en toe wat configuratie, of voor werk dat je team zelf doet, heb je die breedte niet nodig.
De eCommerce-diensten die Flatline publiceert, zijn een startpunt. Controleer welke mensen, capaciteit, bezetting, systeemverantwoordelijkheid, governance en exitprocedure er voor jouw account worden voorgesteld.
Het type bureau moet ook bij je team passen. De vergelijking tussen een Shopify-specialist, creatieve studio en full-service commercebureau helpt je bepalen of brede, vaste capaciteit zinvol is of dat een smallere partner efficiënter werkt.
Twijfel je welke verantwoordelijkheden je na de livegang zelf wilt houden? Flatline loopt het voorgestelde model met je door en zet de opties naast elkaar: overdragen, bij een vaste partner beleggen of samen delen. Wat je eraan hebt, is een model dat je eigen team kan draaien, of Flatline nu betrokken blijft of niet.
Veelgestelde vragen
Hoe lang moet Shopify-ondersteuning na de livegang duren?
Daar is geen vaste termijn voor. De stabilisatie loopt door tot de afgesproken risico's, fouten met voorrang, datacontroles en werkprocedures aan de exitcriteria voldoen. Doorlopende support houd je aan zolang er genoeg specialistisch werk is, met vaste evaluatiemomenten, want je team en je roadmap veranderen.
Wat is het verschil tussen garantie en doorlopende support?
Garantie herstelt opgeleverd werk dat niet aan de afgesproken eisen voldoet, binnen de voorwaarden van die garantie. Doorlopende support dekt wat de live webshop nodig heeft, zoals incidenten beoordelen, onderhoud of geplande wijzigingen. Leg vast welke dienst, welke reactietijd en welke commerciële afspraak waarvoor geldt.
Heeft elke Shopify-webshop een onderhoudsretainer bij een bureau nodig?
Nee. Een webshop heeft wel een duidelijke eigenaar nodig voor platformwijzigingen, onderhoud, incidenten, koppelingen, releases en verbeteringen. Dat kan een intern team zijn. Een retainer is nuttig als kennis van buiten, continuïteit of gereserveerde capaciteit het werk beter afdekt.
Kun je na de livegang overstappen naar een ander Shopify-bureau?
Ja, als jij de belangrijke accounts en bestanden in handen hebt en je bruikbare documentatie, een overzicht van alle toegang, de bekende problemen, informatie over de architectuur en hulp bij de offboarding krijgt. Kijk vroeg naar de opzegtermijn en de afspraken over intellectueel eigendom. Een nieuw bureau moet daarna nog steeds een technische en operationele discovery doen.
De belangrijkste punten
Zie ondersteuning na de livegang als vier lagen: stabilisatie, operationele support, gepland wijzigingswerk en doorlopende verbetering.
Kies het model voordat je tekent. Het bepaalt de oplevering, training, toegang, documentatie en kosten.
Kies een volledige overdracht als je team de kennis, de tijd, het mandaat en de bezetting heeft.
Kies een vaste partner als terugkerend specialistisch werk, continuïteit of gereserveerde capaciteit duidelijk iets oplevert.
Kies een hybride model om werk te verdelen naar vaardigheid, maar zet op elke grens één eindverantwoordelijke.
Houd garantiefouten, incidenten, onderhoud, wijzigingsverzoeken en roadmapverbeteringen uit elkaar.
Leg capaciteit, serviceniveaus, escalatie, afhankelijkheid van derden en de exit vast in termen die je kunt controleren.
Zorg dat toegang en kennis overdraagbaar blijven, ook als de samenwerking met je bureau goed loopt.
Een goed model geeft elke belangrijke werkstroom een eigenaar die het kan, genoeg tijd, duidelijke beslisbevoegdheid en een werkbare route om het over te dragen. Beslis dat voordat de druk van de livegang aannames verandert in operationeel risico.
Gerelateerde artikelen
