Customer support
Wrong customer on an email ticket? Fix the requester without losing the thread
Colleague forwards and shared inboxes often stick the wrong person as requester. Rebind the customer on an email ticket, keep the full conversation, and keep plugins and portal access honest.
A coworker forwards a client email into support. Your shared inbox address becomes the “customer.” Someone else in the thread gets bound as the requester (customer) during early triage. The messages are fine—the identity is wrong.
The requester is the customer the ticket belongs to right now: the person the reply To address follows, the person plugins and recent history key off, and (when self-service is on) the person who can open the thread in the portal. Until you fix a bad binding, all of that trails the wrong person. Recreating the ticket throws away context. Changing the requester keeps the thread and corrects ownership.
Why the wrong person sticks
Email tickets inherit identity from how the mail arrived or who was selected when the ticket was created. Common failure modes:
- A colleague forwards a client message, and the colleague (or a generic address) becomes the requester.
- A shared inbox address is treated as the customer instead of the person who needs help.
- The wrong contact is chosen when composing or during the first minutes of triage.
That binding is sticky on purpose—tickets need a stable customer. The cost is that a one-time routing mistake can mis-attribute the whole conversation until someone corrects it.
What Change requester does
On an email ticket, associates with access to the ticket’s inbox can open ⋯ Actions (top right of the ticket screen) and choose Change requester. It is not available on trial organizations—contact support if you need it during a trial.
What happens:
- The ticket’s live requester rebinds to another customer (existing, matched by email, or newly created with email + name).
- The full conversation stays—you do not clone or close the ticket.
- An internal system note records the change for audit.
- Downstream UI that depends on the current customer updates: sidebar, plugins, recent tickets, and the reply To address.
- If your org has CC email routing enabled, you can optionally keep the previous requester on Cc (unchecked by default).
Think in terms of who owns this ticket now, not frozen From headers from create time.
How to fix it
- Open an email ticket.
- Open the ⋯ Actions menu in the top right of the ticket screen.
- Choose Change requester.
- Review the current requester summary.
- Enter the new requester email (type it or pick from customer suggestions).
- If the email is a new customer, fill in the required Name field.
- If CC routing is on, decide whether to check Keep previous requester on Cc.
- Read the on-screen warnings, then confirm Change requester.
After success, the ticket refreshes with the new customer, the audit note appears in the timeline, plugins and recent tickets follow the new identity, and the composer To / Cc reseeds from the updated recipients.
See the product update on changing the ticket requester for the release note.
Before you confirm: three gotchas
| Watch-out | What to expect |
|---|---|
| Plugins | Sidebars keyed to the current customer email (billing, CRM, custom data) refresh for the new identity—data for the old address may disappear from the panel. |
| Self-service portal | The new requester gets portal access to the entire thread; the former requester loses it. Tell teammates before you surprise either party. |
| Channel | The action is email only. It is hidden on Telegram and other non-email channels. |
Also: if you only need to fix a display-name typo with no identity change, edit the customer record instead of changing the requester.
Correct identity, keep the story
Misattributed email tickets are ordinary ops friction, not a reason to rebuild history. Change the requester when the wrong person is stuck on the ticket, keep the thread, and treat plugins and portal access as part of the decision—not an afterthought.
For related workflows, see Hand off a support thread without losing the customer (associate ownership) and Self-service that actually gets used (portal habits). More product notes live on Updates.