Support-context portability: what reaches the next person?

Support context needs two receiving paths

A support team needs context both when a conversation leaves the product and when a human takes over inside it. Those are different receiving paths. This note examines six first-party documentation pages for Zendesk, Intercom and Freshdesk/Freshworks, retrieved on 2026-11-01. Vendor-documented means stated within those selected pages, not independently verified. We have not performed hands-on testing or accessed vendor accounts. The proposed drill is unperformed; it supplies acceptance criteria, not observed results. This is not a ranking, endorsement or assessment of pricing, performance, AI accuracy or resolution. The sources do not establish completeness for an account. An unanswered question is an evidence gap, not proof that a provider lacks a feature.

Keep the artifact, lifecycle and access decisions separate

Start with the export artifact: a metadata row, a readable transcript and structured message data answer different questions. Export lookback describes which period can be requested; retention describes how long data remains; deletion/purge describes removal. Resolve/archive state is another control, not evidence of removal. Private/internal-note visibility and redaction need separate checks for each route and receiving role. An explicit human request, routing destination, availability/fallback and receiving-human context are four separate handoff requirements. Product roles/admin access describe permissions within a customer workspace; they do not answer provider-personnel or AI data-use questions. Neither an export button nor a successful routing event proves a complete backup, attachment fidelity or reconstructable identity/thread relationships. Use the customer-support guide to choose the workflow, then name the context required at each receiving boundary.

Zendesk: JSON, CSV and XML carry different omissions

Vendor-documented — the account-export article describes JSON, CSV and XML for ticket, user or organization data. In JSON, a ticket exceeding 1 MB loses its comments from the file. CSV excludes deleted tickets, comments and descriptions. Full XML includes ticket comments, but full and user XML exports are unavailable above 200,000 tickets; XML has a 500 MB file limit. AI-agent tickets are excluded from this documented account export. Organization JSON includes deleted organizations; that narrow inclusion does not define ticket retention, purge timing or backup deletion. A download link valid for at least three days is delivery-link availability, not service-data retention. The account owner must ask Support to enable exports; admins perform account export. The article excludes Team plans from these UI tools and mentions a REST API alternative on all plans, without establishing equivalent content or entitlement for the intended account. Coverage of private notes, redaction, attachment fidelity and migration reconstruction remains unknown. The API alternative does not erase the documented format limits.

Intercom: distinguish transcripts, reporting rows, API and S3

Vendor-documented — teammate PDF and text transcript exports contain message chronology, timestamps, participants and visible conversation content within that route; customers can download a .txt transcript from Messenger. Bulk UI transcript export covers about 200–300 conversations per operation. CSV contains reporting metadata, not full message content. The Export API has a 90-day maximum timeframe per request without volume restrictions in this article. S3 produces structured JSON with detailed message content and attachments, not a transcript; exported data cannot be imported into a new Intercom workspace. That description does not establish attachment fidelity or reconstructable threads. Internal notes are excluded from transcript exports, with no option to include them. Sensitive payment data is redacted at entry within this source boundary; this is not a general redaction-tool claim or a statement about note visibility in APIs, S3, AI context or the receiving inbox. Up to two years of CSV/JSON data is export availability, not retention or deletion after two years. Saved-view export requires an Inbox seat and conversation-export permission. Dataset export separately requires chart drill-in and CSV-export permissions. These route-specific requirements do not establish plan entitlement or provider access.

Freshdesk: a ticket list is not the referenced account export

Vendor-documented — the ticket-list route exports CSV or Excel with selected fields. It does not include the entire conversation or archived history. The article points separately to an account export; its format, field coverage, private notes, attachments, redaction and re-import path remain unknown in this selected source. Do not fill that gap from an older article or treat the reference as proof of a complete conversation artifact. Ticket-list export requires an Admin or Supervisor role plus export permission; a custom role can restrict the option. Current and previous plan badges and the warning about Freshdesk Omni accounts created before December 2025 do not establish entitlement for an intended account. Auto-resolve in the handover article marks a conversation resolved after configured inactivity; it is not deletion and supplies no retention duration. The handover configuration path is AI Agent Studio > AI Agent > Build > Configurations > Handover settings, but its required role and plan are not stated.

A request, a destination and a visible record are separate tests

Zendesk documents messaging/email escalation flows that gather customer details, add tags/update fields, identify suitable agents and forward to an agent or specified escalation team. Availability blocks can consider business hours or agent availability; at least one customer or AI-agent message is required for escalation. Its Send an email option is no longer recommended for ticket escalation; the separate recipe is outside this source set. The selected page does not establish the response to every explicit human request. Intercom documents immediate escalation for a clear request for a human, but a deployment with no human routing target does not offer escalation. Rules/guidance decide when; workflows collect information, create tickets and select the destination. Workflow buttons can offer a choice of Fin or a human. Human in the Loop on email/chat is beta: the conversation stays assigned to Fin while a teammate supplies input; it is not a handoff. Freshdesk transfer triggers can include an explicit human request, sensitive/out-of-scope issues or manual review, configured with sample phrases/topics. It can collect customer properties and show a pre-transfer message with translation review. Outside business hours, the action can make the conversation available for agent assignment or assign it to a designated group. Availability and fallback still require separate verification: being available for assignment is not proof that someone received the case. None of these selected handoff sources proves that the receiving human sees every prior message, internal note, attachment, AI action or summary. Do not infer AI reasoning, prompt or collected-field visibility. Routing documentation does not establish response performance.

Obtain these answers in writing for the intended account

The selected pairs do not establish a full retention/deletion lifecycle or provider-personnel/AI data-use terms. Product-admin access is not evidence about provider personnel. Ask which provider personnel and subprocessors can access conversations, exports, private notes, redacted content, AI prompts and derived data, with which approval and logging controls. Is content used to train or improve provider/general models by default, opt-in, opt-out or never, and do settings cover subprocessors and derived artifacts? Obtain contractual deletion, incident-response, regional-hosting, encryption and audit commitments for the exact plan and AI features. Ask for default and configurable retention for active, resolved, archived, spam and deleted tickets, and purge timing for primary storage, backups, logs, derived analytics, AI summaries, embeddings and disaster-recovery copies. Identify legal-hold, support, subprocessor and contract exceptions. These are questions, not conclusions about provider access or training.

• Export coverage: for each UI/API/cloud route, does the exact plan/account include customer, agent and AI messages, attachments, event timestamps, participant identity, channel metadata, custom fields, routing and audit events? Are internal notes included, excluded, separately permissioned or irreversibly omitted? Can re-import or migration preserve thread/order/identity relationships?
• Visibility and redaction: who can see internal notes in the UI, API, exports, AI context and after handoff? Is redaction destructive, reversible and auditable, and does it propagate to exports, search indexes, caches, analytics, AI summaries and backups? Which content classes are redacted automatically versus by an admin/agent?
• Handoff: exactly which transcript, fields, AI summary, attachments, actions, confidence/decision metadata and private notes reach the human? What happens with no human available, failed routing or an after-hours request? Can customers always request a human, and can admins disable, delay or override that path? Obtain the applicable permissions, configuration and fallback in writing; verify only in an authorized evaluation account.

Proposed eight-step support-context drill

Use synthetic data in an isolated evaluation workspace and a receiving environment under your control. This drill has not been performed. Agree on required context and stop conditions before acting; use no customer records, real payment data or live notifications. Keep expected values separate from later observations. Each acceptance criterion is proposed, not a finding that a provider passes. Unavailable controls remain unresolved; do not bypass permissions.

• Baseline SUPPORT-001 ledger: inventory synthetic customer, agent and AI messages, a private note, harmless attachment, timestamps, participant IDs, channel, fields, routing events, AI actions and a summary where available. Acceptance: each required object and relationship has an expected value, receiving role and reviewer before any export or transfer.
• Format-specific export comparison: request the authorized UI/API/cloud routes separately, recording format, selected fields, filters, period and limits. Acceptance: reconcile every required SUPPORT-001 entry with each artifact; label metadata, transcript and structured data separately, and record omissions, file bytes versus links and manual identity/thread mapping without assuming a complete backup.
• Private-note/redaction visibility: compare authorized customer, agent and admin views with each export and the receiving role, using harmless synthetic markers. Acceptance: document included, excluded and inaccessible notes separately, and whether a synthetic redaction propagates; unknown reversibility, auditability or routes remain gaps, never generalized from Intercom transcript behavior.
• Retention/export-window/resolve/delete boundary: record the export window and link expiry separately from written retention and purge terms; compare active, resolved and archived synthetic cases, and only an authorized disposable deletion case. Acceptance: no resolve/archive state or missing export row counts as deletion evidence; primary, backup and derived-data purge timing without written support stays unresolved.
• Explicit human request: submit a clear synthetic request and record trigger, configuration and customer-facing response. Acceptance: distinguish escalation from human input while Fin remains assigned; record whether the path can be disabled, delayed or overridden, without marking unavailable routing as a successful handoff.
• Availability/routing/fallback: exercise agreed business-hours, after-hours, unavailable-human and failed-routing cases in the isolated setup where supported. Acceptance: identify destination, actual assignment, customer message and fallback owner for each case; queue availability alone cannot satisfy receipt by a human.
• Receiving-human context reconciliation: have an authorized receiver compare the inbox record with SUPPORT-001, including messages, notes, attachments, fields, timestamps, identity, AI actions and summaries. Acceptance: every required element is evidenced or explicitly missing; a routing success cannot substitute for the reconciliation, and manual reconstruction is recorded separately.
• Final decision record including provider-personnel and AI-data-use gaps: classify requirements as accepted, unresolved or outside scope. Acceptance: attach observations only after execution, obtain written provider access/training and lifecycle answers, assign an owner and next action to each gap, and block acceptance while any essential requirement remains unresolved.

Accept a defined receiving boundary

Keep source URL and retrieval date, documented route/limit, proposed check, later observation and unresolved dependency in separate fields. Do not copy documentation into the observation column. Have the receiving team identify which missing context prevents continuation, and the data owner identify which unanswered control prevents approval. A narrower workflow may be acceptable only if its exclusions are explicit. Revisit the decision when export routes, roles or handoff settings change. Return to the related customer-support guide to connect this record with queue ownership, knowledge maintenance and the wider service brief; this note does not choose a vendor.