Wanneer heeft je bedrijf technische support nodig?

Je nieuwsbrief is net verstuurd en de webshop wordt traag. Of de koppeling stuurt ineens geen orders meer door. Op zo'n moment vraag je je niet meer af of technische support nodig is. Je wilt iemand aan de lijn die de omgeving kent en het probleem oplost.

Toch zou ik niet elk bedrijf een vaste supportafspraak aanraden. Bij een eenvoudige website zonder koppelingen, met weinig verkeer en een beperkt commercieel belang, betaal je dan vooral voor zekerheid die je niet gebruikt. Draaien er bestellingen of koppelingen met partners op je systemen, dan raad ik een vaste technische partner aan.

Waar die grens ligt, hangt af van wat er gebeurt als een systeem stilvalt of onbetrouwbaar wordt.

Technische support is nodig waar uitval geld kost

De beste graadmeter is wat een uur stilstand kost op het slechtste moment dat je kunt bedenken. Je webshop die op een rustige dinsdag een uur onbereikbaar is: vervelend, misschien te overzien. Valt dezelfde omgeving uit terwijl een nieuwsbrief, campagne of tv-uiting bezoekers stuurt, dan haken klanten af en lopen je campagnes door naar een site die onbereikbaar is.

Een storing in een intern portaal blijft voor klanten misschien onzichtbaar en kan intussen de planning of de facturatie stilleggen, waarna collega's het werk met de hand overnemen. En ondertussen weet je niet zeker of alle data goed verwerkt is.

Een check die je vandaag kunt doen: schrijf per systeem op welke processen erop draaien, hoe lang het maximaal plat mag liggen en wie het als eerste merkt. Twijfel je bij een van die antwoorden, dan leunt je bedrijf waarschijnlijk zwaarder op dat systeem dan je dacht.

Koppelingen maken van een storing een zoektocht

Bij groeiende bedrijven stapelen de koppelingen zich vaak geleidelijk op. Het begint met een website die goed werkt. Daarna komen er een betaalprovider, voorraadsoftware, een CRM en marketingtools bij, en soms een maatwerkportaal of een mobiele app.

In zo'n opzet is een storing zelden een los probleem. Een foutmelding in de app kan voortkomen uit hostingcapaciteit, een databasequery, een gewijzigde koppeling of een update bij een externe dienst. Zonder partij die het geheel kent, gaat er kostbare tijd op aan de vraag welke leverancier je moet bellen. De hoster wijst naar de bouwer, de bouwer naar de API, en intern weet niemand wie de regie heeft.

Hier zou ik het geld uitgeven: aan één partner met zicht op ontwikkeling, infrastructuur en integraties. Zo'n partner kan de oorzaak onderzoeken en het herstel organiseren, en dat is waar je voor betaalt. Ik zou die keuze ook maken als je klanten verwachten dat alles altijd bereikbaar is, of als je eigen team geen tijd heeft om meldingen te beoordelen.

Op afroep kan, als de basis aantoonbaar klopt

Gebruik je een overzichtelijke, stabiele toepassing die weinig verandert en geen bedrijfskritische processen raakt, dan zou ik de doorlopende supportovereenkomst overslaan en kiezen voor periodiek onderhoud, goede back-ups en een aanspreekpunt dat bereikbaar is als er iets gebeurt.

Onderhoud blijft nodig. Browsers, mobiele besturingssystemen en beveiligingsrisico's veranderen, en een oplossing die vandaag goed werkt, kan over zes maanden afhangen van een verouderd onderdeel of van een externe API die zich anders gedraagt.

De prijs van deze keuze betaal je in voorbereiding. Hulp op afroep werkt alleen als degene die je belt meteen aan de slag kan. Loop deze punten na:

• Kun je met de toegangsgegevens die je nu hebt inloggen bij de hosting en de beheeromgeving?
• Is er ooit een back-up teruggezet om te zien of herstel werkt?
• Staat ergens op papier welke software en koppelingen je gebruikt?

Een noodnummer zonder documentatie en zonder toegang tot de juiste omgeving is geen continuïteitsplan.

Zorg ook dat iemand binnen je bedrijf bepaalt wat spoed is. Een fout in de betaalstap pak je direct op; een knop die op één pagina verkeerd uitlijnt, kan wachten. Maak vooraf afspraken over ernst, bereikbaarheid en de reactietijd die je verwacht. Dat scheelt frustratie aan beide kanten.

Leg de route vast voordat je 24/7 bespreekt

De vraag of je 24/7 support wilt, stel ik als laatste. Begin bij de momenten waarop je systemen niet mogen falen. Een consumentenplatform dat 's avonds en in het weekend omzet draait, vraagt andere afspraken dan een B2B-portaal dat alleen tijdens kantooruren wordt gebruikt.

Een reactietijd op papier zegt weinig als niemand weet hoe een storing bij de juiste persoon terechtkomt en wat die mag doen. Bespreek daarom met je partner:

• Wordt een storing gemonitord voordat klanten bellen?
• Mag de partner direct ingrijpen, of is eerst interne goedkeuring nodig?
• Wie zijn de actuele contactpersonen voor spoed?
• Welke herstelacties zijn vooraf toegestaan?

Zet er ook bij wie de hosting beheert, wie de prestaties monitort, wie eigenaar is van de broncode en de toegangen, en wie een incident oppakt als een externe koppeling faalt. Die vragen beantwoord je op een rustige dinsdag. Tijdens een storing ben je te laat.

Houd in de afspraken drie begrippen uit elkaar. Beschikbaarheid gaat over of je systeem draait. Reactietijd gaat over wanneer iemand het incident oppakt. Oplostijd hangt af van de oorzaak en valt niet altijd vooraf exact te beloven. Een betrouwbare partner is daar eerlijk over en houdt je tussentijds op de hoogte.

Herstel is pas de helft van het werk

Snelheid telt bij een storing, en soms is een tijdelijke oplossing nodig om je processen weer te laten draaien. Daarna moet iemand uitzoeken waarom het gebeurde en of een structurele verbetering nodig is. Gebeurt dat niet, dan betaal je meerdere keren voor hetzelfde probleem.

Vraag daarbij om uitleg in begrijpelijke taal. Een technisch verhaal zonder handelingsperspectief helpt een operationeel manager niet verder. Je wilt weten wat de impact is en welke keuze er bij jou ligt.

Ook buiten storingen om valt er werk te doen. Een platform kan online zijn en toch omzet kosten doordat pagina's traag laden op drukke momenten. Updates uitstellen omdat alles nu werkt, voelt efficiënt tot iemand een kwetsbaarheid misbruikt. Pas daarbij op voor het andere uiterste. Onnodige wijzigingen brengen ook risico en kosten mee, dus doe wat stabiliteit en veiligheid vragen en laat de rest liggen.

Vertel je partner wat er aankomt

Een productlancering, seizoenspiek, nieuwe integratie of groei in gebruikers vraagt voorbereiding. Regel je capaciteit, foutafhandeling en monitoring pas na de livegang, dan maak je het risico onnodig groot.

Je partner ziet die momenten alleen aankomen als jij ze deelt. Een marketingactie kan technisch grote gevolgen hebben. Een nieuwe leverancier kan een bestaande koppeling raken, en na een interne proceswijziging moet een tool soms iets anders doen dan waarvoor hij ooit is gebouwd.

Daarvoor is één eigenaar binnen je bedrijf genoeg: iemand die zakelijke prioriteiten vertaalt naar wat er technisch nodig is. De partner bewaakt vervolgens de uitvoering en de risico's. Werk je met maatwerk, apps, integraties en hosting tegelijk, dan is één technisch aanspreekpunt vaak het praktischst. Bij LJPc liggen ontwikkeling en infrastructuur dicht bij elkaar, zodat onderzoek en herstel bij dezelfde partij blijven.

Pak deze week je agenda erbij en zoek het eerstvolgende moment op waarop je systemen niet mogen haperen, zoals een actie of je drukste periode van het jaar. Schrijf erbij wie een storing dan als eerste ziet en wie mag ingrijpen. Lukt dat niet, bespreek het dan met je technische partner of aanspreekpunt voordat die datum er is.