Skip to main content
Customer Journey Trace is the chain of interactions a single customer has with your contact center — every call, callback, IVR session, AI conversation, queue wait, and agent handoff — correlated under one journey identifier so you can observe outcomes across the full path, not inside one platform alone.

​
How it works

A journey is the customer’s end-to-end path across your contact center platforms. A span is one segment of that journey on one platform. Operata recognises span types for telephony, IVR, AI conversation, agent interaction, queue wait, and platform handoff. Each span carries timestamps, platform-native IDs, attributes, signals, and any insights detected during that segment. Operata assembles a journey progressively as data arrives from each platform. Some platforms emit data in real time; Amazon Connect Contact Trace Records (CTRs) can land 5–20 minutes after the contact ends. Early views of a journey are intentionally partial — the trace fills in as platforms report. The journey identifier is stable across that assembly window, so a journey opened mid-flight resolves into the same record once late data arrives. Operata correlates spans by joining native platform identifiers (ContactId for Amazon Connect, CallSid for Twilio, Conversation ID for Genesys Cloud) on transfer events, SIP headers, and CTR attributes. Operata divides the journey into legs, one per platform: leg 1 is where the journey starts, leg 2 is the first handoff destination, and so on. The leg counter tells you how many systems handled the same customer.

​
Why Operata assembles journeys asynchronously

Contact-level observability misses the question developers actually have to answer: where in the customer’s path did the contact fail? A dropped call in Amazon Connect looks identical to a normal contact-end if you only see the Amazon Connect side of the data — the cause sits in the transfer that preceded it. Operata could withhold journeys until every platform has reported, but that delays observability by 20+ minutes for every contact, including the 95% that need no investigation. The current approach favours partial reads over slow reads: a journey is queryable the moment its first span lands, with the understanding that the rest fills in as data arrives. Operata generates the journey identifier rather than relying on any single platform’s ID because no platform sees the full path. Even when a CCaaS platform emits its own conversation ID, that ID is unique to that platform’s leg of the journey, not to the journey itself.
  • Contacts and interactions — what a Contact, an Interaction, and a Conversation each mean across Amazon Connect, NICE CXOne, and Genesys Cloud.
  • Signals and observations — the unit each collector emits and how Operata stores it against a contact.
  • Insights — the per-contact and per-journey rollups that surface inside spans.
  • EventBridge — how journey-level updates reach your downstream systems.
  • List contact summaries — each contact carries the journey it belongs to and its position in the journey.
  • Complete contact record — exposes the spans, handoffs, and platform-native IDs for one contact in the journey.
  • Contact stats — aggregates over journeys, not just contacts, so trends include cross-platform paths.
  • Webhooks overview — Amazon EventBridge events fire as new spans land, so downstream systems can react to handoffs and journey-end before the full trace is assembled.