Een opzegging in WHMCS vereist drie beslissingen: wanneer de facturering stopt, wanneer eventuele externe overeenkomsten voor terugkerende betalingen worden beëindigd en wanneer de toegang tot de hosting wordt beëindigd. Noteer de aangevraagde en ingangsdata, de betaalde dekking en het verantwoordelijke systeem voordat je actie onderneemt. Een opzegging via het portaal is geen bewijs dat elke betalingsgateway, hostingmodule en registrar de bijbehorende actie heeft voltooid.
Deze handleiding is bedoeld voor hostingproviders die de zelfbediening voor klanten herzien of de facturering van klanten naar een ander portaal verplaatsen. Het bevat een origineel opzeggingsformulier en een sjabloon voor de bevestiging aan de klant. Het bevat geen aanbeveling voor een universele opzegtermijn en vervangt je servicevoorwaarden niet. Lees voor een bredere keuze aan platforms de ‘Vergelijking van WHMCS-klantenportalen’.
Welke invloed hebben WHMCS-opzeggingsverzoeken op een dienst?
WHMCS kan opzeggingsverzoeken van klanten accepteren en de beëindiging van diensten verwerken volgens de configuratie. Het resultaat hangt af van het type verzoek, de automatiseringsinstellingen en de provisioningmodule. Controleer het geïnstalleerde gedrag voordat je toezegt dat op een bepaalde datum de facturering en hosting tegelijkertijd worden stopgezet.
De officiële Documentatie over het opzeggen van WHMCS beschrijft onmiddellijke en geplande beëindiging, verzoeken van klanten en handmatige goedkeuring. Hierin wordt uitgelegd dat opzegging het genereren van toekomstige facturen stopt en dat beëindiging via de module invloed kan hebben op de toegang tot de geleverde dienst. Dit zijn consequente acties, niet louter een wijziging van een label in het portaal.
Controleer welke taken zijn ingeschakeld en wie uitzonderingen afhandelt. Een door de klant ingediend verzoek kan actie van het personeel vereisen wanneer automatische beëindigingsverwerking niet is ingeschakeld. Een supportticket dat als ‘opgelost’ is gemarkeerd, is geen bewijs dat een hostingmodule de opdracht heeft voltooid.
Definieer wat beëindiging betekent voor het specifieke product. Beheerde hosting, een onderhoudsovereenkomst en een jaarlijkse domeinregistratie hebben verschillende operationele taken. Als een klant vraagt om één item op te zeggen, controleer dan de servicereferentie ervan voordat je een gerelateerde bundel of alle diensten op het account wijzigt.
Maak ook onderscheid tussen opzegging en een factureringsmigratie. Het verplaatsen van een klant naar een nieuw portaal betekent niet dat de klant de hostingdienst wil beëindigen. Lees de ‘handleiding voor de overdracht bij verlenging’ voordat je een opzeggingscontrole gebruikt louter om oude facturering te onderdrukken.
Houd facturering, betalingsafspraken en toegang apart bij
Leg elke actie en het waargenomen resultaat vast. Het stopzetten van de facturering bewijst op zichzelf nog niet dat een terugkerende overeenkomst aan de kant van de provider is opgezegd. Evenzo leidt het beëindigen van een terugkerende betalingsovereenkomst niet noodzakelijkerwijs tot beëindiging van het hostingaccount.
WHMCS beheer van gateway-abonnementen is een optionele modulefunctie voor extern verwerkte terugkerende overeenkomsten. Het gedocumenteerde gedrag ervan is afhankelijk van de ondersteuning en instellingen van de gateway. Controleer het resultaat bij de provider in plaats van ervan uit te gaan dat elke integratie hetzelfde opzegtraject volgt.
Behandel de toegang tot de hosting als een eigen levenscyclus. Een moduleopdracht moet mogelijk in het hostingsysteem worden geverifieerd. Als een integratie is mislukt, kan een gewijzigde factureringsstatus samengaan met een account dat beschikbaar blijft. Geef een medewerker de verantwoordelijkheid om die discrepantie op te lossen.
Automatische domeinverlenging is een andere verantwoordelijkheid die moet worden gecontroleerd wanneer dit relevant is. Een opzegging van de hosting mag niet stilletjes een keuze voor domeinverlenging beïnvloeden die hier geen verband mee houdt. Leg vast wat de klant heeft gevraagd te beëindigen en wat actief blijft, inclusief de eigenaar van eventuele acties aan de kant van de registrar.
Gebruik de daadwerkelijke statussen in de communicatie met de klant. „Verzoek ontvangen“, „gepland om te beëindigen“ en „beëindigd“ moeten overeenkomen met verschillende bewijzen. Vermijd het versturen van een definitieve bevestiging zolang belangrijke facturerings- of toegangsacties nog niet zijn geverifieerd.
Gebruik één opzeggingsoverdrachtsrapport per dienst
Download het CSV-bestand met opzeggingsgegevens. Het Engelstalige sjabloon bevat fictieve voorbeelden voor onmiddellijke en geplande verzoeken. Het legt beslissingen en observaties vast; het voert geen opzegging uit en importeert niet naar WHMCS of PayRequest.
| Veld | Fictief voorbeeld | Waarom het belangrijk is |
|---|---|---|
| Servicereferentie | Voorbeeld A / managed hosting | Bepaalt precies wat er wordt opgezegd |
| Verzoek ontvangen | 10 oktober 2026 | Bewaart het oorspronkelijke verzoek van de klant |
| Betaald tot | 31 oktober 2026 | Maakt onderscheid tussen betaalde looptijd en opzegtermijn |
| Ingangsdatum | Bevestigen na controle van de voorwaarden | Voorkomt een verzonnen einddatum |
| Eindfacturatieverantwoordelijke | Bestaande factureringsworkflow | Identificeert openstaande of definitieve facturen |
| Uitkomst betalingsovereenkomst | In afwachting van bevestiging door de provider | Scheidt een verzoek van een voltooide opzegging |
| Hostingactie en verantwoordelijke | Gepland / hostingbeheerder | Bepaalt de beslissing over de toegang |
| Bevestiging aan de klant | Nog niet verzonden | Vereist gecontroleerde data en uitkomsten |
Voeg het type verzoek, eventuele openstaande bedragen en een locatie voor het bevestigingsbewijs toe. Houd aantekeningen feitelijk en evenredig. Het werkblad heeft geen wachtwoorden, servergeheimen of betalingsgegevens nodig om aan te geven wie verantwoordelijk is voor de volgende actie.
Laat de facturerings- en hostingbeheerders hetzelfde dossier beoordelen. Afzonderlijke privé-notities zijn soms nodig, maar tegenstrijdige einddatums leiden tot vermijdbare fouten. Eén persoon moet de algehele verantwoordelijkheid voor de zaak dragen, terwijl de relevante specialisten hun acties verifiëren.
Verwerk onmiddellijke en einde-periode-verzoeken
Stel dat klant A € 29 heeft betaald voor hosting in oktober en op 10 oktober een opzegging per einde van de periode aanvraagt. Leg de daadwerkelijk betaalde periode en de servicevoorwaarden vast en bevestig vervolgens de ingangsdatum via de geconfigureerde workflow. Maak geen nieuw doorlopend abonnement aan tijdens een gelijktijdige portaalmigratie.
Controleer of er al een toekomstige verlengingsfactuur of betalingspoging bestaat. Als dat het geval is, controleer dan de status ervan voordat je het schema wijzigt. Een onopgeloste, in behandeling zijnde poging vereist een andere actie dan een voltooide betaling of een conceptfactuur die nog niet is verzonden.
Klant B vraagt om onmiddellijke beëindiging van een afzonderlijke dienst. Controleer of het verzoek geautoriseerd is en breng de gevolgen voor toegang en gegevens in kaart. Onmiddellijke beëindiging, het achterwege laten van toekomstige facturen en een besluit over terugbetaling zijn afzonderlijke zaken. Suggereer niet dat het indrukken van een annuleerknop automatisch leidt tot terugbetaling van de ongebruikte periode.
Klant C heeft een maandelijks hostingabonnement en een jaarlijks verlengd domein. In het verzoek wordt alleen de hosting genoemd. Maak de beslissing over het domein expliciet, inclusief of automatische verlenging ingeschakeld blijft en wie er bij de registrar actie moet ondernemen. Leid de opzegging van het domein niet af uit het hostingverzoek alleen.
Deze voorbeelden zijn fictieve planningsgevallen. Ze laten zien waarom één enkele kolom ‘opgezegd’ niet alle uitkomsten kan verklaren. Datums, betrokken diensten en bewijs van voltooiing stellen medewerkers in staat de klant nauwkeurig te antwoorden en de zaak door een overstap naar een ander factureringsplatform te loodsen.
Configureer PayRequest-zelfbediening afgestemd op het product
De 'documentatie voor zelfbediening door klanten' van PayRequest beschrijft onafhankelijke bedieningselementen voor pauzeren en opzeggen per product. Hierin wordt onderscheid gemaakt tussen onmiddellijke opzegging en een workflow voor opzeggingsverzoeken. Controleer de beoogde productinstellingen in plaats van ervan uit te gaan dat elk portaal identieke acties toont.
De 'documentatie over opzeggingsverzoeken' legt de aanvraag, het supportdossier en de ingangsdatum van de opzegging uit die in de workflow worden weergegeven. Controleer de daadwerkelijke datum voordat je deze aan de klant bevestigt. Een instelling voor de opzegtermijn en een reeds betaalde factureringsperiode zijn geen onderling uitwisselbare termen.
Kies de bedieningselementen op basis van de serviceovereenkomst en de toepasselijke verplichtingen van de klant. Een pauze is niet automatisch geschikt voor een domein of een geleverde hostingservice. Integratiespecifieke producten kunnen anders werken; controleer wat de configuratie ondersteunt voordat je een algemene pauzeknop aanbiedt.
Test de formulering voor de klant aan de hand van de daadwerkelijke actie. Als het portaal een verzoek aanbiedt, leg dan uit dat het om een verzoek met een ingangsdatum gaat. Als het product onmiddellijke opzegging hanteert, leg dan het daaruit voortvloeiende abonnementsgedrag uit en controleer eventuele afzonderlijke hostingacties.
Gebruik de demo van het portaal ter illustratie om de taken van de klant te bespreken. De demo bevat fictieve gegevens en zegt geen echte dienst op. De bedieningselementen zijn een voorbeeld van de ervaring, geen bewijs dat je WHMCS-hostingmodules zijn geïntegreerd.
Neem lopende opzeggingsverzoeken mee in een factureringsmigratie
Inventariseer lopende verzoeken voordat je actieve abonnementen verplaatst. Vermeld de aangevraagde datum, ingangsdatum, servicereferentie, huidige facturatie-eigenaar en eventuele geplande hostingacties. Onder „actief“ in het bronsysteem kan ook een klant vallen wiens opzegging al is ingepland.
Zet niet elk actief record om in een nieuwe, verlengbare dienst. Bekijk de opzeggingsgroep apart en bepaal wat er in het doelsysteem moet worden weergegeven. Anders kan het lijken alsof een klant die al opzegging heeft gegeven, heeft ingestemd met een nieuwe, doorlopende overeenkomst.
Behoud het oorspronkelijke verzoek en de beslissingen van het personeel. Klanten verplichten een geldig verzoek te herhalen, louter omdat het portaal is gewijzigd, leidt tot een vermijdbaar operationeel probleem. Stel de historische gegevens ter beschikking aan de mensen die de overdracht afhandelen.
Controleer de betalingsovereenkomst en de volgende factuur in combinatie met de ingangsdatum. Als de oude overeenkomst met de provider nog bestaat, stopt het migreren van de verzoektekst de incasso niet. Gebruik de ‘handleiding voor betalingsgereedheid’ om vast te stellen welke regeling nog in rekening kan worden gebracht.
Volg tijdens de eerste pilot één lopende opzegging vanaf het oude verzoek tot aan de eindafrekening en het resultaat. Leg vast welke systemen zijn gecontroleerd en welke stappen nog niet zijn afgehandeld. Breid pas uit nadat uit het verslag blijkt wie er in elke fase handelt en wat de klant te zien krijgt.
Stuur een bevestiging met specifieke data en verantwoordelijkheden
Een nuttige bevestiging vermeldt de betreffende dienst, de datum van het verzoek, de overeengekomen ingangsdatum, de betaalde dekkingsperiode en eventuele acties die de klant moet ondernemen. Ook wordt uitgelegd welke onderdelen actief blijven. Vermijd een algemeen bericht als „je account is opgezegd“ wanneer slechts één product afloopt.
Een herbruikbaar bericht is: „We hebben je opzeggingsverzoek voor [dienst] op [datum] ontvangen. De bevestigde ingangsdatum is [datum]. Uw huidige betaalde dekking loopt tot [periode]. [Vermeld eventuele geverifieerde afsluitende factureringsacties]. De toegang tot de hosting zal [geverifieerde uitkomst en datum] plaatsvinden. [Vermeld eventuele afzonderlijke diensten die actief blijven]. Neem contact op met [ondersteuningskanaal] als deze gegevens niet overeenkomen met je verzoek.”
Vul het bericht pas in nadat de relevante controles zijn uitgevoerd. Als een toegangsactie nog in behandeling is, vermeld die status dan duidelijk in plaats van definitieve bewoordingen te gebruiken. Doe geen ongefundeerde belofte van terugbetaling en beschrijf een onopgeloste overeenkomst met een provider niet als opgezegd.
Geef medewerkers de mogelijkheid om de bevestiging en de ontvanger vast te leggen. Een klant die later vraagt naar een verlenging, moet een traceerbaar antwoord kunnen krijgen: welke dienst, welke periode en welke actie is voltooid. Het verslag moet bruikbaar blijven nadat het oude portaal alleen-lezen is geworden.
Controleer hoe klanten historische facturen kunnen opvragen na wijzigingen in de toegangsrechten. Toegang tot facturen en toegang tot de geleverde hosting kunnen aan verschillende regels onderworpen zijn. Bepaal van tevoren de ondersteuningsroute, zodat een beëindigd hostingaccount niet tot gevolg heeft dat een legitieme vraag over de facturering onoplosbaar wordt.
Sluit de zaak pas af nadat de resultaten zijn gecontroleerd
Voer een laatste controle uit van het serviceregister, het facturatieschema, de overeenkomst met de provider en het hostingsysteem. Controleer welke acties zijn voltooid en welke nog moeten worden opgevolgd. Een gewijzigde status in één applicatie is slechts één observatie, geen volledig overzicht van de opzegging.
Controleer bij een ingetrokken verzoek de tegenovergestelde acties net zo zorgvuldig. Controleer of de dienstverlening wordt voortgezet, wie de volgende facturatieverantwoordelijke is en of er instellingen voor verlenging zijn gewijzigd. Het heropenen van een abonnement zonder een eerder beëindigde externe overeenkomst te controleren, kan ertoe leiden dat een actieve dienst blijft bestaan zonder de beoogde incassomethode.
Houd uitzonderingen zichtbaar voor de verantwoordelijke medewerker. Een mislukte beëindiging of onverwachte factuur moet een verantwoordelijke en een volgende actie hebben. Verberg dit niet door het verzoek als ‘opgelost’ te markeren, louter omdat het bericht aan de klant is verzonden.
Als je het factureringsportaal vervangt, leg dit overzicht dan voor aan de Beoordeling van de WHMCS-migratie. Dit helpt bij het bepalen welke opzeggingstaken in PayRequest thuishoren en welke bij de bestaande hosting- of registrar-workflows blijven.
PayRequest Business kost € 20 per maand en omvat het klantenportaal en terugkerende facturering. De standaard betalingskosten van het platform bedragen 0% zolang het betaalde abonnement actief is. Verwerkingskosten van de aanbieder worden apart in rekening gebracht; commissiebetalingen behouden hun eigen tarief. Voltooi de accountconfiguratie en activeer Business bij het afrekenen. Het selecteren van Business tijdens de aanmelding verleent op zichzelf nog geen betaalde toegang. Raadpleeg huidige prijzen voordat je je configuratie kiest.
Redactionele opmerking: AI heeft bijgedragen aan dit artikel en de illustratieve omslagafbeelding. De officiële documentatie is op 7 oktober 2026 gecontroleerd. Werkbladen en klantberichten zijn originele planningssjablonen. Alle voorbeelden zijn fictief; er zijn voor dit artikel geen daadwerkelijke afboekingen, klantmigraties of beëindigingen van hostingcontracten uitgevoerd.


