Migrate from Servicely to Intercom

Servicely tickets (incidents and service requests) map to Intercom Conversations. We preserve the ticket title as the conversation subject, status mapping from Servicely states to Intercom open/closed/snoozed, priority to Intercom Ticket Priority, and timestamps (created_at, updated_at) for conversation ordering. Internal notes and agent comments map to Intercom's internal and public reply types. Custom ticket fields from Servicely must be pre-defined in Intercom as conversation attributes before migration so that attribute values can be mapped correctly during import.

Servicely Customer records map to Intercom Contacts. Email, name, phone, and any custom properties migrate as Contact attributes. We validate that the contact's email is unique in the destination workspace before insert. If phone number validation is enabled in Intercom during migration, we coordinate with the customer's admin to disable it temporarily to prevent invalid phone numbers from causing import rejections.

Servicely Company records map directly to Intercom Companies. Company name, domain, and custom properties migrate as Company attributes. The Company record is created before any linked Contact migration so that the Company-Contact relationship is satisfied at insert time. Dedupe key is the company domain name.

Servicely Service Catalog items with variable fields and approval chains require a split mapping decision during scoping. Items used as knowledge content (how to request a service) map to Intercom Articles under a dedicated Collection. Items with structured data (service request types with custom fields) map to an Intercom Custom Object named ServiceRequest with attributes matching the source item fields. Approval chain logic is not migratable as automation; we document every approval condition in the workflow inventory.

Servicely Agent records map to Intercom Admins. We map agent email, name, and role designation. Servicely role-based permissions (workflow assignment permissions, catalog access scopes) do not map directly to Intercom's admin role hierarchy (regular, team admin, super admin). We flag any non-standard permission configuration and preserve it as a custom attribute on the Admin record for the customer's admin to configure post-migration.

Servicely workflow trees with activity nodes (comment, user action, approval, complete, scriptable, timer, if/else branches) export as structured JSON. Intercom's Rules engine operates on conversation events and does not support scripted nodes, approval gates, or timer-based escalation natively. We do not migrate workflows as code. We export the Servicely workflow JSON and produce a written inventory document describing each workflow step, its trigger conditions, branching logic, and a recommended Intercom Rules equivalent. The customer's admin rebuilds these in Intercom Rules post-migration.

Servicely SLA configurations defining response and resolution deadlines by priority map to Intercom SLA Policies. We preserve the SLA name, first response target, next response target, and resolution target in hours or business-hours. Calendar-based SLA scheduling (if configured in Servicely) requires Intercom business hours configuration to be set up before SLA targets take effect. SLA enforcement logic migrates as policy definitions only; runtime enforcement begins when Intercom is the active system of record.

File attachments on Servicely tickets migrate as files attached to the corresponding Intercom conversation. We download from Servicely, re-upload to Intercom via the files API, and link the file to the conversation reply or note. Original filenames and MIME types are preserved. Attachment URLs referencing external storage in Servicely are documented as reference links if re-upload is not feasible.

Servicely KB articles (title, body HTML, category, tags) map to Intercom Help Center Articles under Collections and Sections. The two-level Servicely category hierarchy maps to Intercom's Collection and Section structure. Tags migrate as article labels. Formatting compatibility depends on whether Servicely used rich text; we run a content scrub on HTML body content to ensure rendering in Intercom's article editor. Articles without a parent section land under the root Collection directly.

Tags applied to tickets and articles in Servicely migrate as label arrays to Intercom. No value transformation is required. We flag any tags exceeding 500 unique values during scoping because very high-cardinality tag sets on the Servicely side may indicate that tags are being used as a de facto custom field, which requires a separate conversation about Intercom custom attribute design.

Servicely's virtual agent and embedded GenAI append resolution notes and suggested fixes to tickets, stored as ticket comments or custom note fields depending on the customer's AI configuration. We flag the presence of AI-generated content during discovery and either preserve it as a formatted internal note block in the Intercom conversation or map it to a dedicated custom attribute on the Contact record if the customer wants AI context available at the contact level for Fin to reference.