Answer “why is this customer calling?” in one pass

Why Customer 360 needs a live graph

When a subscriber or enterprise customer contacts support, the cause is often one or two hops away from their profile row: a household member opened a ticket yesterday, their fiber service sits on a node with packet loss or scheduled maintenance, a recent payment failed, or repeated app/call-center touches spiked in the last 48 hours.

Example Customer 360 graph

• Identity & hierarchy: HOUSEHOLD / HOLDING → ACCOUNT / CUSTOMER / SUBSCRIBER → CONTRACT, SERVICE, DEVICE.
• Infrastructure & incidents: SERVICE / DEVICE → NETWORK_EVENT → CELL_SITE / FIBER_NODE ← INCIDENT / MAINTENANCE.
• Care & billing: HAS_TICKET -> TICKET, HAS_INVOICE -> INVOICE, MADE -> PAYMENT, CONTACTED -> CALL_CENTER, USED_APP -> APP, MEMBER_OF -> SEGMENT.

How care and ops AI agents use it

• Full context before the first reply: an agent calls get_schema once, then resolves 1- and 2-hop context via get_neighbors and cypher_read to correlate open tickets with upstream incidents or billing friction.
• Repeat-contact & outage bursts: get_histogram and get_edge_state surface sudden jumps in disconnects, support contacts, or app failures without querying cold logs.
• Proactive care segments: create_signal and create_segment group impacted accounts (for example, subscribers on an affected node with open tickets) so outreach or retention workflows act immediately.