Migrate from Servicetonic Helpdesk Tool to Intercom

Servicetonic Incidents map directly to Intercom Conversations. The Incident title becomes the Conversation subject, incident description becomes the initial message, and priority level maps to an Intercom SLA plan assignment. Status history from Servicetonic's incident lifecycle is preserved as conversation state changes. We map incident category and subcategory to Intercom conversation tags for filtering parity. Incident assignment to Servicetonic agents maps to Intercom Assignee via the Team and User mapping.

Servicetonic Service Requests map to Intercom Conversations separately from Incidents. The request type maps to a custom conversation attribute or tag in Intercom. Approval status from Servicetonic (Pending Approval, Approved, Rejected) does not have a native Intercom equivalent; we preserve it as a custom conversation attribute and note it for the customer's admin to implement via Intercom's rules engine post-migration.

Servicetonic end-user requester profiles (name, email, organization, location, contact preferences) map to Intercom Contacts. We preserve organizational affiliation as the Intercom Contact company link. Requester contact preferences (email opt-in, phone preference) map to Intercom's unsubscribe and email_notification fields. Any custom user attributes migrate as custom Contact attributes.

Servicetonic agent profiles (name, email, role, team, permission level) map to Intercom Team Members. Role and team assignment in Servicetonic maps to Intercom's Inbox and Team structure. Permission-level mapping depends on whether the Servicetonic agent has admin or agent-only access; Intercom's admin-user permission model is applied accordingly.

Servicetonic Knowledge Base articles (title, body content, attachments, visibility settings, category assignment) map to Intercom Articles. We preserve article body as HTML content, attachments as file links, and visibility settings mapped to Intercom's collection-level visibility (public, default, or internal). Category hierarchy from Servicetonic translates to Intercom Collections and Sections during the knowledge base import phase.

Servicetonic's KB category hierarchy (category, subcategory, article assignment) maps to Intercom's Collection and Section structure. We flatten multi-level Servicetonic categories into one Collection per top-level category and one Section per subcategory, preserving the full article-to-category assignment. Visibility inheritance from Servicetonic KB categories maps to Intercom's collection visibility flags.

Servicetonic SLA definitions (response target, resolution target, tied to priority level and calendar) cannot map 1:1 to Intercom's SLA model because Intercom uses a simpler per-conversation SLA plan with basic business-hours calendar and single timezone. We preserve the original SLA metric and threshold values as custom conversation attributes and flag every non-standard Servicetonic SLA calendar during the mapping phase, calling out discrepancies for customer approval before import. SLA calendar rebuild is documented for the customer's admin in Intercom's SLA settings post-migration.

Configuration Items (IT assets, systems, linked components) in Servicetonic have no direct Intercom equivalent. We map CI type, name, and location as a custom Contact or Conversation attribute where the data fits, or flag them for a separate asset management integration post-migration if the customer uses a dedicated CMDB tool. CI-to-incident linkage does not migrate as a native relationship; it is preserved as a text attribute for manual reference.

Service Catalog entries (service description, fulfillment process, linked forms) in Servicetonic map to Intercom Articles where the catalog entry functions as informational content. Approval workflows tied to catalog fulfillment do not migrate; we document each catalog approval chain as a written artifact for the customer's admin to rebuild in Intercom's rules engine or a separate workflow tool.

Servicetonic's incident status transition history (Open, In Progress, Pending, Resolved, Closed with timestamps) maps to Intercom conversation state changes. Each status transition timestamp is preserved as a conversation event in Intercom's conversation timeline, maintaining the full audit trail of how the incident moved through the service desk lifecycle.