Klantensupport
Verkeerde klant op een e-mailticket? Corrigeer de requester zonder de thread te verliezen
Doorstuurs van collega’s en gedeelde inboxen plakken vaak de verkeerde persoon als requester. Bind de klant opnieuw op een e-mailticket, bewaar het volledige gesprek en houd plugins en portal eerlijk.
Een collega stuurt een klantmail door naar support. Het adres van je gedeelde inbox wordt de “klant.” Iemand anders in de thread wordt tijdens vroege triage als eigenaar vastgezet. De berichten zijn prima—de identiteit is fout.
De requester is de klant aan wie het ticket nu toebehoort: de persoon die reply To volgt, waar plugins en recente geschiedenis op sleutelen, en (met self-service aan) wie de thread in het portal kan openen. Zolang de binding fout is, volgt dat alles de verkeerde persoon. Het ticket opnieuw aanmaken gooit context weg. De requester wijzigen houdt de thread en corrigeert het eigendom.
Waarom de verkeerde persoon blijft hangen
E-mailtickets erven identiteit van hoe de mail aankwam of wie bij aanmaak werd geselecteerd. Veelvoorkomende missers:
- Een collega stuurt een klantbericht door, en de collega (of een generiek adres) wordt de requester.
- Een gedeelde-inboxadres wordt als klant behandeld in plaats van de persoon die hulp nodig heeft.
- Het verkeerde contact wordt gekozen bij opstellen of in de eerste minuten van triage.
Die binding is expres stabiel —- tickets hebben een consistente klant nodig. De prijs is dat één routeringsfout het hele gesprek verkeerd kan toeschrijven tot iemand het corrigeert.
Wat Change requester doet
Op een e-mailticket kunnen agents met toegang tot de inbox van het ticket ⋯ Actions openen (rechtsboven op het ticketscherm) en Change requester kiezen.
Wat er gebeurt:
- De live requester van het ticket wordt opnieuw gebonden aan een andere klant (bestaand, op e-mail gevonden, of nieuw met e-mail + naam).
- Het volledige gesprek blijft—je kloont of sluit het ticket niet.
- Een interne systeemnotitie documenteert de wijziging voor audit.
- Downstream UI die van de huidige klant afhangt wordt bijgewerkt: sidebar, plugins, recente tickets en het reply-To-adres.
- Als je organisatie CC e-mailrouting heeft, kun je optioneel de vorige requester op Cc houden (standaard uitgevinkt).
Denk in wie dit ticket nu bezit, niet in bevroren From-headers van het aanmaakmoment.
Hoe je het herstelt
- Open een e-mailticket.
- Open het menu ⋯ Actions rechtsboven op het ticketscherm.
- Kies Change requester.
- Bekijk de samenvatting van de huidige requester.
- Voer het e-mailadres van de nieuwe requester in (typ of kies uit klantsuggesties).
- Als het e-mailadres een nieuwe klant is, vul het verplichte veld Name in.
- Als CC-routing aan staat, beslis of je Keep previous requester on Cc aanvinkt.
- Lees de waarschuwingen op het scherm en bevestig Change requester.
Na succes ververst het ticket met de nieuwe klant, verschijnt de auditnotitie in de timeline, volgen plugins en recente tickets de nieuwe identiteit, en zaait de composer To / Cc opnieuw vanuit de bijgewerkte ontvangers.
Voor je bevestigt: drie valkuilen
| Let op | Wat te verwachten |
|---|---|
| Plugins | Sidebars gekoppeld aan het huidige klant-e-mailadres (facturering, CRM, custom data) vernieuwen voor de nieuwe identiteit—gegevens van het oude adres kunnen uit het paneel verdwijnen. |
| Self-serviceportal | De nieuwe requester krijgt portaltoegang tot de hele thread; de vorige verliest die. Waarschuw het team voordat je een van beide verrast. |
| Kanaal | De actie is alleen e-mail. Ze is verborgen op Telegram en andere niet-e-mailkanalen. |
Ook: als je alleen een typfout in de weergavenaam wilt fixen zonder identiteitswijziging, bewerk dan het klantrecord in plaats van de requester te wijzigen.
Juiste identiteit, intact verhaal
Verkeerd toegeschreven e-mailtickets zijn gewone operationele frictie, geen reden om geschiedenis opnieuw op te bouwen. Wijzig de requester wanneer de verkeerde persoon aan het ticket vastzit, bewaar de thread, en behandel plugins en portaltoegang als onderdeel van de beslissing—niet als bijzaak.
Voor gerelateerde workflows, zie Een supportthread overdragen zonder de klant te verliezen (agent-eigendom) en Self-service die echt gebruikt wordt (portalgewoonten). Meer productnotities op Updates.