Customer 360 context auto-attach

An agent opening a new ticket rarely starts on the problem. They look up the account in the CRM. They check the last order and the current plan. Then they scan whether this person wrote in last week. Auto-attach runs those lookups at intake and writes the result onto the ticket as structured fields.

The output is a context panel. Account tier, plan, lifecycle stage, recent orders with dates and statuses, open and recently closed tickets, and the entitlements that decide what support this customer is owed. Each value carries the system it came from and the time it was read.

What it does not produce is an interpretation. "High-value customer, handle carefully" is a judgment. "Enterprise plan, renewal in 41 days, three tickets this month" is context. The first hides its reasoning. The second lets the agent reach a conclusion and check it.

This is also not diagnosis. The panel says what the account looks like. Whether the failure sits on the customer's side belongs to an agent that calls logs and product APIs later in the workflow.

Start from what agents actually open. Sit with a queue for a morning and write down every tab. That list, not the CRM's field catalog, is the specification. Panels built from what is available rather than what is used become wallpaper.

Each field needs four things defined. The source system. The exact field or endpoint. The join key. And a freshness rule saying how old a cached value may be before it must be refetched or marked stale.

The join key is the whole problem. A ticket arrives with an email address. The billing system keys on account ID. The order system keys on customer ID, and one household can hold two. Write the resolution path down: which identifier is authoritative, what happens on a partial match, and what happens on none.

Decide the failure behavior in advance. If identity resolution returns two candidate accounts, attach neither. Show both as unresolved and let the agent pick. A panel confidently attached to the wrong account is worse than an empty one, because the agent will trust it.

Entitlement fields need the tightest rule. Priority support, an active warranty, or a paid onboarding package all shape what the agent may promise. If that field cannot be read, say so on the panel. Do not default to the common case.

Pull, do not paraphrase. Every value should trace to a record an agent can open. Show the field, the value, the system, and when it was read. A link back to the source record is the difference between a panel people trust and one they re-verify by hand.

Rank fields by relevance to this ticket, not by recency alone. A billing question wants the last three invoices and the payment method status. A shipping question wants the last two orders and their tracking states. Serving the same twelve fields on every issue type buries the two that matter.

Summarize only where volume forces it. A customer with sixty prior tickets cannot show all sixty. Show the three most similar to the current one, plus a count of the rest. That overlaps with surfacing resolved tickets that match the current issue, but the panel's job is narrower. It shows that this person has asked before.

Keep derived scores out. Health scores, propensity numbers, and risk grades belong in a separate column with their own owner. Churn-risk and VIP flagging runs at triage against a documented model. Mixing a model output into a panel of retrieved facts makes the whole panel read as an opinion.

Take a hypothetical case. A meal-kit subscription company runs weekly deliveries across twelve metro areas. A customer emails on Thursday afternoon to say the box never arrived and the food she planned around is gone.

Identity resolves cleanly. The sending address matches one subscriber record, and that record links to a single delivery address.

The panel attaches seven fields. Plan: four meals per week, two servings, active since March. Billing status: current, next charge Sunday. Delivery zone: metro three, Thursday window. This week's order: dispatched Wednesday, carrier scan at the local depot Wednesday night, no delivery scan. Prior orders: eleven delivered, one late by a day in June. Ticket history: two contacts, one about a missing ingredient in May, one about pausing a week in July. Credits issued: one, for the May ingredient.

Three of those fields do real work. The missing delivery scan tells the agent this is a carrier problem rather than a picking error, before any investigation starts. The single prior credit shows this is not a repeat claimant. The Sunday charge date sets a deadline, because skipping next week has to happen within three days.

The panel does not say to refund her. It does not say she is likely to cancel. It gives an agent who has never seen this account the same footing as one who remembers her.

Four failure modes account for most of the disappointment here.

Wrong-account attach. Shared inboxes, forwarded mail, family accounts, and agencies writing for clients all produce ambiguous identity. When the match is uncertain, the panel must say uncertain. Silent best-guess matching puts one customer's order history in front of a conversation about another.

Stale values presented as current. A plan field cached last night is wrong if the customer upgraded this morning. Timestamp every value. For fields that drive a promise, such as entitlement or balance, refetch at open rather than serving cache.

Panel bloat. Thirty fields is a wall, and walls get skipped. Once agents stop reading the panel, they go back to the tabs, and the integration work returns nothing. Cut fields nobody clicks.

Privacy scope creep. That a system can attach something does not mean it should. Card details, health information, and free-text notes from sales calls do not belong on a support ticket by default. Set the scope with whoever owns data governance, and log what was attached.

One quieter failure deserves naming: context that answers the wrong question. A panel full of commercial data on a ticket about a broken feature reads as a sales briefing. Match fields to the issue type, or the intent already normalized at intake has been wasted.

The panel informs. It does not authorize. Before an agent tells a customer a warranty covers a replacement, they open the entitlement record and read it. The panel got them to the right record faster, and that is the whole benefit.

Treat every attached value as evidence with a timestamp, not as truth. When the customer says something the panel contradicts, the panel is not automatically right. Sync delays and duplicate records are common enough that the contradiction is worth logging on its own.

Nothing here should route or prioritize by itself. A plan tier sitting in a field is not a priority. Those decisions belong to triage and assignment, where the rules are written down and reviewable, as with workload-aware auto-assignment.

Review the panel the way you would review a report. Once a quarter, ask agents which fields they used and which they ignored. Drop the ignored ones. Add the tabs they still open. A context panel that never changes is either perfect or unread, and it is rarely perfect.