Migrate from TrueEngage to Zendesk

The primary interaction records — chat sessions, voice calls, video calls — live in Genesys Cloud, which is the system of record for TrueEngage. We extract from the Genesys Cloud API (interaction records, call disposition, recording references, outcome data) and create Zendesk Ticket records. TrueEngage-specific channel metadata (widget channel type, Cobrowse initiation flag) is appended as internal Zendesk comments on each ticket so the full session context is preserved. Zendesk tickets inherit the original interaction timestamp as created_at and the assigned agent from Genesys routing.

TrueEngage passes visitor contact records into Genesys Cloud as part of the interaction context. We extract end-user records from Genesys Cloud (name, email, phone, organization reference) and map to Zendesk User (End User) records. The Zendesk user.email field serves as the dedupe key. If the organization is known, we also create a Zendesk Organization record and link it via the user.organization_id lookup.

TrueEngage Visitor records are session-scoped browser and mobile identities used by Visitor Engagement AI for proactive triggers. They are ephemeral and tied to active Widget sessions. We do not migrate the full Visitor identity graph — it is transient and has no long-term value in Zendesk. However, visitor email addresses captured during interaction sessions (for callback requests, Feedback form submissions) migrate as Zendesk User records if a matching contact does not already exist.

Cobrowse session outcomes, shared screen logs, and session duration live in TrueEngage. We extract session summaries (session_id, start_time, end_time, outcome, agent_id, visitor_id) from TrueEngage and append them as Zendesk internal notes on the corresponding ticket. For organizations with an active Zendesk third-party Cobrowse add-on (e.g., Cobrowse.io), we map session metadata to the add-on's object model. Zendesk does not have native Cobrowse; session records are preserved as structured notes for agent reference.

Callback requests from website visitors initiated through a TrueEngage Widget are queued into Genesys Cloud as callback appointments. We extract callback request records (visitor contact, requested time, queue assignment, status, outcome) from Genesys Cloud and create Zendesk Ticket records. The Zendesk ticket type is set to 'task' or 'question' to reflect the callback intent, and the original callback scheduling data is stored in a custom Zendesk field cb_original_requested_time__c. If the callback was completed, the call recording and disposition migrate as comments on the ticket.

TrueEngage Feedback forms (questions, branching logic, styling) have no export API. We document the current form schema during a joint discovery session — capturing each question, field type, branching conditions, and response set — and provide a written specification for the customer to recreate in Zendesk as a custom ticket form and set of custom fields. Historical form submissions migrate as Zendesk ticket comments or as entries in a Zendesk custom object (on Enterprise) so agents can reference the submission history alongside the ticket.

TrueEngage Widgets (channel configuration, targeting rules, scheduling, branding) have no export API. We document the current Widget configuration during discovery: active widget count, channel types enabled, geographic and page-based targeting conditions, availability schedules, and routing queue assignments. This documentation is delivered as a written configuration inventory for the customer to rebuild in Zendesk as separate Zendesk Channel configurations, Business Rules, and Schedule definitions. This is a manual rebuild step and must be scoped explicitly before migration begins.

Widget targeting rules — geographic conditions, time-of-day routing, visitor-segment triggers, page-based routing — are defined per Widget in TrueEngage and pushed as routing flows into Genesys Cloud. We document the current routing logic during discovery (conditions, queue assignments, priority overrides, overflow settings) and deliver a written routing map for the customer to rebuild in Zendesk as Zendesk Triggers, Automations, and SLA policies. Routing rule documentation requires a joint session with the TrueEngage admin.

TrueEngage business hours, holiday calendars, and queue availability rules drive Widget availability and are defined in the TrueEngage Widget management panel. We export schedule definitions (timezone, business hours per day, holiday list) and map them to Zendesk Business Hours configuration. Zendesk Business Hours support multiple schedules per schedule group; each TrueEngage queue schedule becomes a separate Zendesk schedule group.

WebRTC voice and video calls routed through TrueEngage Widgets are handled as standard Genesys Cloud calls with a SIP trunk provisioned by TrueEngage. Call records, duration, disposition, and recording references exist in Genesys Cloud and migrate from there to Zendesk Tickets. TrueEngage-specific SIP trunk and DID references (TrueEngage-owned infrastructure) are stripped and replaced with a note in the Zendesk ticket that the call originated via TrueEngage WebRTC for audit continuity. Post-migration, the destination platform must provision its own SIP trunk for continued web calling.

Cross-channel transfers and escalations (chat to voice to video) during a single TrueEngage interaction carry a channel-switch event log. TrueEngage records the channel-switch events; Genesys Cloud records the routing and disposition. We extract transfer event logs from Genesys Cloud and append them as structured internal comments on the Zendesk ticket, noting the originating channel, target channel, transfer timestamp, and agent handling each segment. This preserves the escalation history for compliance and quality assurance review.