How to fix a PostHog Conversations ticket linked to the wrong customer
You can't edit the ticket directly. PostHog's own GitHub issue tracker confirms it. The distinct ID, the sender email, and the linked person are all read-only fields on a Conversations ticket, and the ticket detail panel has no edit control for any of them. As of this writing that feature request is open with zero comments, so there's no shipped fix path from PostHog's side.
There's still a real fix, and it works because of how the match gets made in the first place. A ticket doesn't store a frozen link to a person at the moment it's created. It stores a distinct ID (or a sender email, on the email channel), and PostHog looks up which person that resolves to fresh, every time someone opens the ticket or the list loads. Fix the underlying identity data instead of the ticket, and the same ticket points at the right person the next time anyone looks. The one case with no workaround at all is a team that stores no email property on any person profile. Nothing exists for an email-channel ticket to match against, ever.
How PostHog decides whose ticket this is
PostHog's support docs describe four channels a ticket can arrive from: an in-app widget that auto-attaches whatever identity is active in the session, inbound email forwarded to a support address, a Slack integration, and monitored GitHub repos. The product name in the docs is Support. The code, the API path, and the issue tracker's own feature/conversations label still call it Conversations, which matters if you go looking for it in the codebase and can't find "Support" anywhere.
Underneath all four channels, identity resolves the same two ways. Most tickets carry a distinct ID, matched straight to the person that ID belongs to. Email is the exception. An inbound message is created with the sender's raw address as its distinct ID, so on that channel the address is effectively the only key. When no person owns that exact distinct ID, PostHog falls back to a second lookup, matching the sender's address against every person's email property, case-insensitive. Two people can share that property, and when they do, PostHog's lookup query prefers whichever one is already identified, and within that group, whichever was created first. That ordering is the exact seam this whole class of bug lives in.
When Piermont's ticket panel showed the wrong company
A ticket landed flagged urgent, from a dispatcher at Hardwick Freight:
Marguerite Osei, by email: Our drivers can't pull today's routes, the app just spins. Six trucks are sitting still right now.
Owen Kessler, who runs support at Piermont, a routing-software vendor that sells to freight dispatchers like Hardwick, opened the ticket to check her plan and recent usage before replying. The panel showed a person called "QA Test Sandbox," zero events in ninety days, no plan attached. Not Marguerite, and not Hardwick Freight.
He went looking, and the cause turned up fast. Months earlier, someone on Piermont's own team had run a widget test using Marguerite's real personal Gmail as a throwaway identify string, and that stub profile had sat in PostHog ever since with her email still attached to it. Marguerite's real, identified Hardwick Freight profile used her work address, not the personal one she happened to email support from during the outage. Both profiles were identified, both carried her personal address in different fields, and the QA stub had been created first. The lookup's own tie-break rules picked it every time.
The two fixes that work
Two corrections cover most of this bug's shape, and neither one touches the ticket itself.
Clear the stray identity that's winning the tie. Owen didn't need to touch Marguerite's account at all. He opened the leftover QA profile and removed the email property that had been sitting there since the test, which took it out of the lookup entirely. Her ticket stopped matching a dead sandbox the next time anyone opened it.
Add the missing address to the right person. That alone wasn't enough, because Marguerite's real profile still only carried her work email, not the personal address she'd written in from. Owen added her personal Gmail to her Hardwick Freight profile's email property. On his next refresh, the ticket resolved to the real account, with the correct plan, correct usage history, and correct company.
A different shape of the same bug calls for a different fix. When two people get merged into one profile by accident, usually because they shared a browser before either one called identify(), PostHog's person-profile page has a Split IDs button that pulls a specific distinct ID back out of an over-merged profile. Split the bad ID out, let it resolve on its own or get identified correctly going forward, and a ticket carrying that ID resolves correctly on its next open, same as Owen's case. PostHog also won't silently merge two profiles that are both already identified; it refuses the merge and logs an ingestion warning instead, per its own identify() docs. Bad merges mostly start from the anonymous side.
The one setup with no workaround
Some teams deliberately never store an email property on any person, keying everything on an internal user ID instead, for privacy reasons. For those teams, an email-channel ticket has nothing to match against. Not the wrong person, no person, permanently, because the only lookup PostHog runs on that channel is the one they've opted out of storing data for. That's the exact gap named in the open feature request. Identity fields are locked with no override, and no custom field exists on a ticket to hold a corrected key either. If that's your setup, routing email-channel tickets through the widget instead, where the signed-in session carries a real distinct ID, is the only workaround until PostHog ships an editable link.
Past the single ticket
Everything above fixes one ticket, in one inbox. It doesn't touch the fact that the same customer's history lives scattered across whatever else you run alongside Conversations: a Slack channel, an old Zendesk thread, a call transcript with a different spelling of their name. A support tool resolving its own tickets correctly was never going to solve that; it was never trying to.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThat's the point where a tool like Modem does different work than fixing the link on a single ticket. Modem's PostHog integration reads events, flags, and experiments alongside whatever support tool a team actually runs, Conversations included, and resolves each requester against its own person and company records instead of trusting any one tool's automatic match. It doesn't require moving off Conversations, or off Zendesk, or off whatever combination a team already has running; a wrong match in one inbox stops deciding who gets credited for a request everywhere else. Modem is the company writing this, so read that comparison with your own judgment, not just ours. The broader identity gaps in PostHog's newer support surface are covered in our guide to whether Conversations replaces a dedicated helpdesk tool, and a related display-only version of this same identity problem, on the survey side, is in how to see who actually submitted a PostHog survey response.
The two-minute check before you reply
Before answering any ticket that feels off, check whether the plan, usage, and company match what the customer is describing. If a dispatcher says six trucks are down and the panel shows zero events in ninety days, that's not a quiet account, that's the wrong account. Fix the identity underneath it, not the ticket, and reopen it to confirm the match actually changed before you send a reply based on the wrong customer's history.
