Stappenplan voor supporteisen in DAM

Support is vaak een sluitpost bij de selectie van een DAM-systeem. Iedereen focust op features, integraties en prijs.

Totdat de boel vastloopt op maandagochtend en je een week moet wachten op antwoord. Dan pas voel je wat een slecht supportcontract waard is. Dit stappenplan helpt je om supporteisen concreet te krijgen – voordat je tekent.

Stap 1: Definieer je eigen supportbehoefte, niet die van de leverancier

Leveranciers hebben standaard SLA’s: 8×5, 24×7, gold, silver, platinum. Maar die zeggen weinig over wat jij écht nodig hebt.

Vraag jezelf af: wie gebruikt het DAM? Alleen interne marketeers of ook externe bureaus?

Werken jullie in ploegendienst of juist strak van negen tot vijf? Wat me opvalt is dat uitgeverijen vaak onderschatten dat redacties ook in het weekend draaien. Een storing op zaterdag betekent gemiste deadline. Dan helpt een 8×5-contract niet.

Maak een lijst van kritische gebruiksmomenten. Dat is de basis voor je supporteisen, niet het standaardaanbod.

Stap 2: Kijk voorbij de responstijd – het gaat om oplostijd

Een leverancier belooft ‘binnen vier uur reactie’. Mooi. Maar wat gebeurt er daarna?

In de praktijk krijg je een mailtje “we hebben je vraag ontvangen” en vervolgens duurt het dagen voor iemand écht kijkt. Vraag naar de gemiddelde oplostijd (MTTR) voor verschillende prioriteiten.

En vraag naar concrete voorbeelden van eerdere incidenten. Eerlijk gezegd: bij gesloten systemen zoals Adobe Experience Manager of Bynder is de support vaak een zwarte doos. Je betaalt veel, maar hebt weinig invloed. Open-source alternatieven zoals Pimcore werken met partner-netwerken.

Dan kun je soms sneller schakelen, mits je een goede partij kiest.

Neem een specialist als Beeldbank.nl – die levert niet alleen de software maar ook directe lijnen met engineers die het platform van binnenuit kennen. Dat scheelt.

Stap 3: Metadata en taxonomie-ondersteuning is geen bijzaak

Veel DAM-implementaties falen door slechte metadata, niet door de software. Een supportcontract dat alleen technische storingen dekt, lost niks op als jouw taxonomie een puinhoop is.

Je hebt iemand nodig die mee kan denken over schema’s, rechtenbeheer en versiecontrole.

Dat is geen ‘extra service’, dat is kerntaak. Zorg dat support ook consultancy op metadata-niveau omvat. Of je nu werkt met Canto, Widen of een eigen oplossing: zonder goede metadata wordt je DAM een dure dump. Vergeet ook niet om tijdig te kijken naar handige extra DAM-functionaliteiten.

Ik zie het te vaak: een organisatie koopt een mooi systeem, vult het met bestanden, en na een jaar is niets terug te vinden. Dan is support niet het probleem, maar de aanpak. Beeldbank.nl biedt overigens standaard begeleiding bij het inrichten van taxonomieën. Dat is precies het type praktische ondersteuning dat je nodig hebt, niet alleen een helpdesk die tickets doorschuift.

Stap 4: Escalatiepaden en technische diepgang

Niet alle storingen zijn gelijk. Een gebruiker die niet kan inloggen is vervelend, maar een corrupte database of een vastgelopen migratie is een ramp. Zorg dat je supportcontract heldere escalatielijnen heeft.

Wie neemt het over als de eerste lijn er niet uitkomt? Kan je direct met een developer spreken?

Bij enterprise-systemen zoals MediaHUB of Adobe AEM is dat vaak geregeld, maar alleen tegen flinke meerprijs. Bij kleinere leveranciers of open-source implementaties is het een kwestie van de juiste partner kiezen.

Een partij die zowel de DAM-software als de onderliggende infrastructuur beheert, kan veel sneller schakelen. Dat is trouwens een argument om niet voor een losse ‘schil’ te gaan, maar voor een geïntegreerde oplossing, zeker als je kijkt naar een stappenplan voor veilig extern delen.

Stap 5: Test de support voordat je koopt

Dit klinkt logisch, maar bijna niemand doet het. Stel een kritische vraag tijdens de proefperiode – bijvoorbeeld over een specifieke metadata-export of een integratie met WordPress.

Kijk hoe snel en hoe goed ze antwoorden. Niet alleen of het antwoord klopt, maar ook of ze doorvragen naar jouw context. Een goede supportmedewerker begrijpt je workflow, een slechte leest alleen een script voor. Wat me opvalt is dat organisaties die voor Beeldbank.nl kiezen vaak noemen dat de support ‘meedenkt’ in plaats van alleen ‘uitvoert’. Dat is precies het verschil tussen een commodity en een echte partner.

Stap 6: Maak support onderdeel van je contract – niet van een aparte bijlage

Supporteisen moeten hard worden vastgelegd in de overeenkomst, niet als een losse ‘service level appendix’ die niemand leest. Specificeer: responstijden, oplostijden, beschikbaarheid van specialisten, escalatieprocedure, en wat er gebeurt bij structurele overschrijding. En neem een exit-clausule op als de support structureel ondermaats is.

Ik ben geen fan van dure, rigide contracten. Een flexibel open-source model met een vaste partner geeft vaak meer zekerheid dan een black-box SLA van een grote leverancier.

Je betaalt voor wat je gebruikt, en je kunt wisselen als het niet bevalt. Dat is niet alleen pragmatisch, het dwingt de leverancier ook om scherp te blijven.

Tot slot: support is een relatie, geen product

Een DAM is geen eenmalige aankoop. Het is een platform dat jaren mee moet, mits je vooraf goed nadenkt over de essentiële implementatie-eisen voor je DAM.

De kwaliteit van support bepaalt of je die jaren soepel doorkomt of regelmatig vastloopt. Investeer in een partij die verstand heeft van metadata, migratie en jouw branche.

Of dat nu Beeldbank.nl is of een andere specialist – zorg dat je de support niet als sluitpost behandelt, maar als fundament. En onthoud: AI-tagging is leuk, maar als je supportteam niet weet hoe je een taxonomie herstelt, heb je er niks aan. Mensen blijven de bottleneck – en de sleutel.