Een effectief supportticket voor TrekMail schrijven

Een goed geschreven supportticket geeft het team de gegevens die nodig zijn om zonder giswerk onderzoek te doen. Het kan geen reactietijd of uitkomst beloven, maar maakt de volgende stap duidelijker. Deze handleiding legt uit wat u moet opnemen en biedt sjablonen voor veelvoorkomende ticketcategorieën.

Zie Het Support Center gebruiken voor hoe u een ticket indient, waar u klikt en welke velden u invult. Dit artikel gaat over de inhoud.

De basisstructuur van een goed ticket

Elk nuttig ticket beantwoordt vier vragen:

1. Wat ik probeerde te doen: uw doel, niet alleen wat er misging.
2. Wat er werkelijk gebeurde: de precieze fout, status of het gedrag dat u zag.
3. Wat ik al heb geprobeerd: zo wordt een basiscontrole niet herhaald.
4. Identificerende informatie: het domein, postvak, factuurnummer of tijdstippen waarmee de zaak kan worden gevonden.

Hoe meer context u geeft, hoe eenvoudiger het is om het juiste productonderdeel te controleren. Neem nooit een wachtwoord, 2FA-code of API-token op.

Wat u per categorie moet opnemen

Factureringstickets

• Factuurnummer of betalingsreferentie uit Billing of het betalingsbewijs.
• De verwachte afschrijving tegenover de werkelijke afschrijving als die verschillen.
• Of het probleem gaat om een verlenging, activering van een add-on, terugbetalingsverzoek of iets anders.
• Laatste 4 cijfers van de kaart bij een kaartspecifiek probleem, maar nooit het volledige PAN of de CVV.
• Valuta en bedrag van het geschil.

Voorbeeld:

Gisteren is $52 afgeschreven, maar ik verwachtte $39. Het factuurnummer uit mijn Billing-pagina staat hieronder. Laatste 4 cijfers van de kaart: 4242. Kunt u uitleggen of het verschil een ander onderdeel of belasting betreft? Ik heb een screenshot van het dashboard met de afschrijving bijgevoegd.

Technische tickets of verzendtickets

• Adres van het verzendende postvak.
• Adres van de ontvanger of patroon, bijvoorbeeld "alle ontvangers op @gmail.com".
• Exacte foutmelding, met de volledige tekst en eventuele foutcodes zoals 550 of 421.
• Wanneer het begon: vermeld waar mogelijk datum, tijd en tijdzone.
• Of hetzelfde postvak naar andere adressen kan verzenden: dit toont of het probleem tot één ontvanger of provider beperkt is.
• Of webmail hetzelfde bericht kan verzenden: dit helpt een configuratieprobleem in een mailapp te onderscheiden van een account- of bezorgingsprobleem.

Voorbeeld:

Het postvak alice@mycompany.com kan sinds vanochtend naar geen enkel adres op gmail.com verzenden. Andere ontvangers (yahoo.com, outlook.com) werken wel. De bounce is "550 5.7.1 [2026-05-15.05] Our system has detected an unusual rate of sending. Please try again later." Webmail toont dezelfde fout. Begonnen om ~09:00 UTC op 2026-05-15. Andere postvakken op hetzelfde domein kunnen gmail.com ook niet bereiken.

DNS-tickets

• Domeinnaam.
• De status die TrekMail voor het domein toont en het exacte record dat niet is geverifieerd.
• Het resultaat van een DNS-opzoeking, als u dat hebt. Bijvoorbeeld de dig-uitvoer voor een MX- of SPF TXT-record.
• Uw DNS-provider, zoals Cloudflare of GoDaddy.
• Het specifieke record dat niet wordt geverifieerd.
• Of u DNS onlangs hebt gewijzigd, inclusief het tijdstip bij benadering.

Voorbeeld:

Domein: mycompany.com. Het DKIM-record is nog rood op de Domains-pagina. Ik heb het record gisteren bij Cloudflare toegevoegd en ingesteld op alleen DNS, zonder proxy. dig +short TXT dkim._domainkey.mycompany.com geeft de verwachte waarde v=DKIM1; k=rsa; p=... terug. TrekMail markeert het nog steeds als ontbrekend. Ik heb de propagatie ook via een andere DNS-opzoekdienst gecontroleerd.

Bezorgings- of spamtickets

• Domein en verzendend postvak.
• Bouncepercentage uit het paneel Domain Email Stats.
• Voorbeeldontvangers bij wie berichten bouncen of in spam belanden, zonder de hele lijst te delen.
• Bron van uw lijst: opt-informulier, een eerdere provider of een andere bron.
• Recent verzendpatroon: of volume of doelgroep onlangs is veranderd.

Voorbeeld:

Het bouncepercentage van domein mycompany.com steeg in de afgelopen zeven dagen van 0.5% naar 8%. Ik heb een screenshot van Email Stats bijgevoegd. Ik verzend naar een opt-innieuwsbrieflijst met ongeveer 2,000 abonnees. De bounces bevatten "user unknown" en "mailbox over quota". Twee weken geleden heb ik ongeveer 200 inactieve abonnees verwijderd, de enige recente wijziging. Moet ik de resterende lijst verifiëren voordat ik opnieuw verzend?

API-tickets

• Naam van het API-token, maar plak niet het werkelijke token.
• Het endpoint dat u aanroept.
• De requestbody, met gevoelige gegevens afgeschermd.
• De response, met statuscode en body.
• Verwacht gedrag tegenover waargenomen gedrag.

Voorbeeld:

Ik roep POST /api/v1/verify/bulk aan met een afgeschermde array emails en mode: quick. Ik ontvang HTTP 422; de responsebody staat hieronder met verwijderde e-mailadressen. Ik verwachtte dat een verificatietaak zou worden gemaakt. Tokennaam: "production-verify-token". Dit begon vandaag rond 13:00 UTC en hetzelfde verzoek werkte gisteren.

Account- of inlogtickets

• Het account-e-mailadres, uw inlogadres.
• Wat er gebeurt, zoals niet kunnen inloggen, geen wachtwoordreset ontvangen of niet-werkende 2FA.
• Browser en besturingssysteem.
• Of u inlogt met een sociale provider, zoals Google, Microsoft of vergelijkbare diensten.
• Datum bij benadering van de laatste geslaagde login.

Beschrijf bij een 2FA-herstelverzoek het toegangsprobleem en geef alleen accountgegevens die via de officiële supportprocedure worden gevraagd. Stuur nooit een huidig wachtwoord, 2FA-code, herstelcode of identiteitsbewijs in een normaal ticketbericht, tenzij een geverifieerd TrekMail-proces daar expliciet om vraagt.

Wat u NIET moet opnemen

Deel geen:

• Wachtwoorden in platte tekst. Nooit. Niet uw dashboardwachtwoord, postvakwachtwoorden of wachtwoorden van externe diensten.
• Volledige creditcardnummers, CVV's of volledige bankgegevens. De laatste 4 cijfers zijn voldoende voor identificatie.
• API-tokens in platte tekst, want we kunnen ze aan hun naam herkennen.
• Adressen of gegevens van andere klanten in bijlagen. Anonimiseer of scherm ze af.
• Gevoelige persoonsgegevens van ontvangers, tenzij die essentieel zijn voor het onderzoek.

Als u per ongeluk een geheim deelt, trek het dan waar mogelijk in of roteer het en vertel het supportteam direct, zodat het over de volgende stap kan adviseren.

Richtlijnen voor bijlagen

• Screenshots: alleen JPEG, PNG, GIF of WebP, maximaal 5 MB. Toon de relevante pagina en fout, maar snijd URL's met tokens, postvakadressen of andere privégegevens weg of scherm ze af.
• Uitvoer van DNS-query's: plak die als tekst, voor leesbaarheid opgemaakt met backticks, niet als screenshot.
• Foutlogs: plak de relevante regels, niet het volledige logboek.
• Bouncebericht: neem het volledige bouncerapport op, vooral de regel Diagnostic-Code:.
• Browserscreenshots: toon geen andere tabbladen, meldingen, opgeslagen wachtwoorden of niet-gerelateerde klantgegevens.

Afbeeldingsbijlagen bij tickets worden volgens planning 30 dagen nadat het ticket is gesloten verwijderd. Bewaar lokaal een kopie van alles wat belangrijk is.

Eén probleem per ticket

Hebt u twee afzonderlijke problemen, dien dan twee afzonderlijke tickets in. Zo blijft elk gesprek gericht en is de geschiedenis eenvoudiger te volgen.

Zijn twee problemen gekoppeld, bijvoorbeeld "facturering mislukt EN verzending gestopt", dan mogen ze in één ticket zolang het verband duidelijk is.

Een ticket bijwerken

Als het probleem zichzelf oplost voordat support antwoordt, bijvoorbeeld omdat DNS-propagatie is voltooid of een externe dienst terugkeert, voeg dan een korte update toe zoals: "Opgelost: DNS-propagatie is voltooid. Sluit dit ticket alstublieft." U kunt een actief ticket ook zelf vanaf de pagina sluiten.

Als een gedeeltelijke tijdelijke oplossing acceptabel is maar niet de gewenste oplossing, zeg dat dan: "Ik heb het omzeild door X te doen, maar ik wil nog steeds begrijpen waarom de oorspronkelijke aanpak niet werkte."

Sjablonen die u kunt kopiëren

Voor een algemeen ticket over iets dat niet werkt:

Subject: <one-line summary of the issue>

What I was trying to do:
  <your goal>

What happened:
  <exact error or behaviour, including error messages>

Started:
  <timestamp or "always", "since yesterday", etc.>

What I tried:
  - <attempt 1>
  - <attempt 2>

Identifying info:
  - Domain: <domain.com>
  - Mailbox: <user@domain.com>
  - <Invoice number if billing, API token name if API, and similar identifiers>

Voor een functieverzoek:

Subject: Feature request: <one-line description>

What I'd like to do:
  <user story: "as a <type of user>, I'd like to <action> so that <benefit>">

Current workaround:
  <if any>

Why this would help:
  <use case, frequency, scale>

Similar in other tools:
  <if any reference example>

Voor een factureringsgeschil:

Subject: Billing dispute: <one-line summary>

Invoice number or payment reference: <from Billing or the payment receipt>
Charge amount: $X.XX
Expected amount: $Y.YY
Account email: alice@mycompany.com

What I was expecting:
  <explanation of what your subscription should have charged>

What was actually charged:
  <explanation of the actual invoice / charge>

Resolution requested:
  <refund / credit / explanation / something else>