Requester, end user and organisation: the records a ticket hangs off
In short
A ticket carries four identity pointers: the requester whose problem it is, the submitter who typed it, the followers watching, and the organisation on the hook commercially. Entitlement, priority floor and ownership may only be read from the organisation; language, tone and notification targets only from the person. Every account-aware triage bug starts with one of those two rules being broken.
Key takeaways
- Entitlement, priority floor and named ownership read from the organisation, never from the person.
- Language, tone, timezone and notification targets read from the person, never from the organisation.
- The submitter is who typed the ticket; the requester is whose problem it is. They differ often.
- Followers and CCs are a notification list. They may not influence routing, priority or entitlement.
- An inferred organisation may set a default. It may never raise a priority or unlock an entitlement.
- A wrong company attachment can expose that company's ticket history, so treat it as a disclosure risk.
One human generates several records in a helpdesk, and a ticket points at 4 of them at once. Read the wrong pointer and the failure is not cosmetic: a contractor on a personal address gets an enterprise response target, or a named account's administrator sits in the standard queue because nobody registered their domain.
The fix is a written rule about which record may decide what, applied everywhere a decision is made: triggers, views, the model's feature set, and whatever writes the assignee.
The records, and what each is allowed to decide
| Record | What it answers | May decide | Must never decide |
|---|---|---|---|
| Requester | Whose problem is this? | Language, tone, timezone, notification target | Entitlement, response target, queue |
| Submitter | Who typed this in? | Audit trail, reply-to, public or internal reply | Anything. It is a provenance field |
| Followers and CCs | Who is watching? | The notification list, and nothing else | Routing, priority, entitlement, ownership |
| Organisation | Which company is on the hook? | Entitlement, priority floor, response target, named owner | Language, tone, the person's working hours |
The submitter row is the surprising one. An agent raising a ticket after a call is the submitter, not the requester; so is a partner filing for an end customer. If automation reads the submitter as the requester, every phone-raised ticket is attributed to staff and account-level reporting stops meaning anything.
Entitlement is a property of the contract, tone is a property of the person
Both feel like they describe the customer, and they describe different ones. The contract is with a legal entity; the conversation is with a human who may be 1 of 400 people inside it, some of whom are not covered by it at all.
- A free individual at a paying company. The domain matches, so they get an enterprise response target nobody sold them. The expensive direction.
- A paying company's contractor on a Gmail address. No domain match, so a contract promising a named owner lands in the standard queue. The direction that produces the escalation email.
- One person across 2 organisations. A consultant working for two of your customers has one identity and two entitlements; the ticket's organisation decides which applies.
- Language and hours travel with the person. A German-speaking user inside a US-headquartered account gets German and their own working day; the response target still comes from the account.
Resolution order when the sender matches nothing
This is where guessing gets institutionalised, so it needs 6 written steps. Work strictly down the list and stop at the first match.
- Exact match on a verified identity. The address is already on a user record. Use it and stop — no further inference.
- Exact match on a secondary address of an existing user. People forward from a second mailbox constantly, and this is the cheapest merge available.
- Domain match against a registered organisation domain, and only from an explicit list. Never infer from Gmail, Outlook or any shared or agency domain.
- Thread ancestry. The message replies within a thread already attached to an organisation, so inherit the organisation — not the user, who may genuinely be new.
- A verified reference in the body: account number, licence key or order id, checked against the system of record. Parse it, then verify it; never trust it as parsed.
- Stop. Create an unaffiliated requester, apply the unknown-customer entitlement, and route to a human triage view. Guessing is worse than asking.
What breaks downstream when the records are conflated
- Two systems write the owner. An account rule assigns by organisation while an intent rule assigns by topic, and the ticket oscillates — tickets bouncing between two groups.
- The clock uses the wrong calendar. A target inherited from the organisation but measured against the requester's local schedule produces SLA breaches on tickets that arrived at 2am.
- The classifier learns the account, not the question. Give an intent model an organisation identifier and it predicts your largest customer's dominant topic for everything they send — a quiet route to one intent label absorbing the queue.
- Analysis groups by the wrong entity. Counting themes by ticket, by person or by company gives 3 different answers, which must be settled before choosing between a fixed tag taxonomy and open clustering.
None of this is exotic. It is the ordinary problem of one real-world entity holding several records in several systems, which turns up wherever operational software meets the physical world — the same reconciliation runs through AI in logistics operations.
Getting the identity graph right gates everything else in ticket and inbox triage: no routing, entitlement or reporting decision is trustworthy while the records are ambiguous. It is ordinary AI agents and automation groundwork inside our SaaS and customer support practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is the difference between the requester and the submitter on a ticket?
The requester is whose problem the ticket describes; the submitter is who typed it in. They are the same for an inbound email and different for a ticket raised by an agent after a call, or by a partner on behalf of an end customer. Treat the submitter as provenance and never let automation read it as the customer.
Should a CC on a ticket inherit the customer's entitlement?
No. A CC is a notification list and nothing more. Entitlement follows the organisation the ticket is attached to, so adding an outside adviser to a thread must not change the response target, the queue or the owner — and must not silently attach that person to the customer's company.
How should tickets be linked to a company when people use personal email addresses?
Through an explicit verified link on the user record, not through domain inference. Add the personal address as a secondary address on the existing user, or have the account administrator confirm the person, so the attachment is a recorded decision. Domain matching is a convenience for corporate addresses; it cannot be the mechanism for exceptions.
Can one person belong to more than one organisation?
Yes, and the ticket must decide rather than the person. Consultants and agency staff routinely hold one identity across several of your customers, so entitlement is resolved from the organisation on that specific ticket. A helpdesk forcing one company per user makes this unrepresentable, and teams work around it by creating duplicate people.
- identity
- triage
- helpdesk
- entitlement
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- Suspended ticket queue: what lands there, and why real customers do tooSuspension is a triage decision your helpdesk makes before your rules, your macros and your model see the message — and the only triage decision whose mistakes leave no trace.definition
- The same ticket keeps getting reassigned between two teamsCount assignment changes per ticket for one week. A handful of tickets with many hops is a rules conflict; many tickets with exactly two hops is a boundary problem in the taxonomy.diagnostic
- Your SLA is breaching on tickets that arrived outside working hoursOvernight breach reports are almost always a schedule problem rather than a staffing problem. One chart — breach rate by hour of arrival, in the schedule's own timezone — tells you which, and the rest of the afternoon is configuration.diagnostic
- Intent taxonomy: the label set a support router can act onAn intent is not a description of a ticket. It is the instruction a router acts on, which means a label no queue, macro or automation consumes is not a label at all.definition
- A mail loop is manufacturing tickets between your system and theirsRunaway ticket volume from a single counterparty is rarely spam. It is two automated systems answering each other, and the fix is a header rule your responder should already have been applying.diagnostic
- Customer replies are opening new tickets instead of threadingOpen the raw source of one orphaned reply. Whether the References chain contains your outbound Message-ID decides whether this is a matching bug, a stripped-header problem, or an identity problem.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation