Introductie
De indiener werkt als reseller in de IT-sector. Hij bouwt en beheert websites voor klanten en maakt daarvoor al jaren gebruik van dezelfde hostingprovider. De samenwerking verliep lange tijd naar tevredenheid: nieuwe klanten konden eenvoudig worden toegevoegd via het portaal van de provider en het beheer verliep grotendeels zelfstandig.
Situatiebeschrijving
Het werkproces is overzichtelijk. De reseller neemt een hostingpakket af, voegt via het portaal nieuwe klanten toe en bouwt of beheert vervolgens hun websites. Facturen worden betaald en het systeem functioneert zoals verwacht.
Op een bepaald moment krijgt hij een bericht van de hostingprovider dat het huidige pakket eigenlijk groter is dan nodig. Samen besluiten ze het pakket te downgraden. Dat voelt als goede service: de provider lijkt mee te denken en kosten te besparen.
Maanden later ontstaat plots een ernstig probleem. Driekwart van de websites van zijn klanten staat offline. Mail werkt niet meer en de sites zijn onbereikbaar. Na contact met de hostingprovider blijkt dat het pakket “onder water staat”: er zijn meer gebruikers actief dan het pakket toelaat. Alles wat buiten het pakket valt, is daarom automatisch uitgeschakeld.
De oplossing lijkt eenvoudig: extra blokken aanschaffen zodat het aantal gebruikers weer binnen de licentie past. Maar vervolgens ontstaat een periode van drie weken waarin communicatie moeizaam verloopt. Antwoorden komen laat, eerder gegeven informatie wordt weer ingetrokken en telefonisch contact is niet mogelijk. Ondertussen liggen websites van klanten plat en groeit de druk richting de reseller.
Waar het eerst voelde als een stabiele samenwerking, voelt het nu alsof hij tegenover een onbereikbaar systeem staat.
De Kwestie
Hoe ga je om met een leverancier die zich achter procedures en pakketten verschuilt terwijl jouw klanten afhankelijk zijn van een werkende dienst?
Mijn Antwoord
Wat hier gebeurt, zie ik vaker in relaties tussen organisaties en hun leveranciers. In het begin is de samenwerking persoonlijk en soepel. Zolang alles binnen de standaard loopt, voelt het alsof er een partnerschap bestaat. Maar zodra er iets buiten de kaders valt, neemt het systeem het over.
Het eerste spanningspunt zit al in het moment van de downgrade. Wat bedoeld was als service, heeft waarschijnlijk een technische grens geïntroduceerd die eerder niet speelde. Dat hoeft op zichzelf geen probleem te zijn, zolang beide partijen zich bewust zijn van de consequenties. Wanneer dat gesprek onvoldoende expliciet wordt gevoerd, ontstaat een situatie waarin de ene partij denkt dat alles hetzelfde blijft, terwijl de andere partij verwacht dat de grenzen bekend zijn.
Het tweede spanningspunt zit in verantwoordelijkheid. De reseller is degene die naar zijn klanten toe verantwoordelijk is voor bereikbaarheid en continuïteit. Voor de hostingprovider is dat anders: zij beheren een platform met duizenden klanten en sturen op standaardisering. Vanuit hun perspectief is het uitschakelen van diensten buiten het pakket een logisch automatisme. Vanuit het perspectief van de reseller voelt dat als een abrupte en onpersoonlijke ingreep.
De derde laag gaat over communicatie. Wanneer systemen leidend worden, verschuift vaak ook de manier van contact. Vragen worden tickets, gesprekken worden mails, en persoonlijk overleg verdwijnt. Daardoor ontstaat het gevoel dat niemand echt eigenaar is van het probleem, terwijl voor de klant juist snelheid en duidelijkheid cruciaal zijn.
Het probleem zit dus niet alleen in techniek of contract, maar in de spanning tussen schaalbare systemen en relationele verantwoordelijkheid. De reseller opereert in een wereld van individuele klanten en vertrouwen. De hoster opereert in een wereld van pakketten, limieten en processen. Wanneer die twee werelden elkaar raken, ontstaat precies dit soort situaties.
Mijn advies
- Zorg dat de websites en mail zo snel mogelijk weer structureel binnen een passend pakket vallen. Dat kan tijdelijk betekenen dat er capaciteit bij geplaatst moet worden, wat mij betreft vanuit de provider, puur om rust te creëren voor de (gezamenlijke!) klanten.
- Vraag om één duidelijk aanspreekpunt
Probeer bij de hostingprovider een vaste contactpersoon of accountmanager te krijgen. Wanneer communicatie alleen via tickets verloopt, verdwijnt eigenaarschap en blijft het probleem rondzingen. - Leg verwachtingen expliciet vast
Bespreek met de provider wat er gebeurt bij overschrijding van limieten. Wordt er gewaarschuwd? Wordt er automatisch afgesloten? En hoeveel ruimte is er voordat dat gebeurt? Dit soort afspraken voorkomen verrassingen. - Overweeg je afhankelijkheid
Wanneer een leverancier structureel moeilijk bereikbaar is bij incidenten, is het verstandig om te onderzoeken of er alternatieven zijn. Niet als dreigement, maar als strategische keuze voor de betrouwbaarheid richting jouw klanten. - Communiceer open naar je eigen klanten
Leg uit wat er is gebeurd en wat je doet om herhaling te voorkomen. Klanten begrijpen vaak meer dan we denken, zolang ze merken dat iemand verantwoordelijkheid neemt.
De belangrijkste les in dit soort situaties is dat techniek zelden het echte probleem is. Het gaat uiteindelijk om vertrouwen, bereikbaarheid en duidelijkheid in de relatie tussen organisaties. Wanneer dat goed is ingericht, worden technische grenzen bespreekbaar.