Intercom vs Dixa (2026): Architecture, TCO & Migration Guide

Intercom is an AI-first, object-oriented messaging platform built for product-led SaaS companies. Dixa is an omnichannel, offer-based routing platform with native telephony, built for ecommerce and voice-heavy support teams. They are not solving the same problem.

The choice comes down to whether your operation centers on in-app messaging and autonomous AI resolution, or on native voice, push-based routing, and EU data residency. This guide covers the real architectural differences, total cost of ownership, API constraints, data model gaps, and what actually breaks when you migrate between them.

Core Architecture: Object-Oriented vs Offer-Based Routing

This architectural split drives every downstream difference — billing, agent workflow, AI strategy, integration complexity, and migration difficulty.

Intercom: Relational Data Model + AI Layer

Intercom is built on a relational data model designed to mirror your product's database. The core entities are Contacts (users and leads), Companies, Conversations, Tickets, and Custom Objects. Conversations and Tickets link to Contacts and Companies. Custom attributes live on contacts and companies. Tags apply to conversations.

A visitor initiates a chat via the Messenger widget, creating a conversation. If the issue needs tracking, state management, or cross-team handoff, an agent or automation converts it into a ticket with a formal lifecycle (open → pending → snoozed → resolved). This relational structure enables sophisticated segmentation, proactive messaging (product tours, email campaigns, banners), and CRM-style reporting.

Intercom's Inbox is queue-based. Work drops into team inboxes, and agents pull from those queues based on priority and assignment rules. You can trigger an in-app message or route a conversation based on a user's subscription tier, their last login date, or the specific custom object they're viewing.

Fin, the autonomous AI agent, sits in front of the human inbox. Fin resolves queries across chat, email, WhatsApp, SMS, phone, and Slack. Intercom reports that Fin resolves approximately 76% of incoming support requests autonomously across its customer base — a figure that varies significantly by industry, knowledge base quality, and conversation type. The trade-off: per-resolution billing ($0.99 per outcome) means your AI costs scale directly with volume.

Dixa: Conversation-Centric + Push Routing

Dixa takes a fundamentally different approach. It is an omnichannel router, not a relational database. Dixa does not natively support "Companies" or "Custom Objects" the way Intercom does. The data model is conversation-centric: every interaction, regardless of channel, is a conversation with an end user.

Dixa uses an "offered" routing model — a push-based system where every conversation is automatically routed to the best-available agent based on skills, language, customer priority, and presence status (Available, Away, Busy). Agents don't browse a queue or cherry-pick from a shared inbox. They receive the next conversation pushed to them. If an agent doesn't accept within a configured timeout, the offer bounces to the next agent. This is classic contact center architecture, optimized for reducing response times in high-volume B2C environments.

All channels — phone, email, live chat, WhatsApp, Instagram, Facebook Messenger, SMS — flow into a single routing engine, so the same skill-based routing logic applies whether a customer sends an email or calls in.

Voice and Telephony: The Major Divergence

If voice is a primary channel for your support team, this comparison often ends here.

Dixa is a fully functional cloud PBX. Native telephony is built directly into the platform across all plans. You can purchase phone numbers, configure IVR menus within Dixa's Flow Builder, record and transcribe calls, handle callback and voicemail, and port numbers across 60+ countries. Agents take calls directly in the browser with no desktop app required. Voice routes through the exact same routing engine as email and chat, meaning a single set of skill and priority rules applies across all channels.

Intercom does not have native telephony. It is a messaging-first platform. To handle voice, you must integrate a third-party CTI provider like Aircall, Dialpad, or Talkdesk. These integrations log calls as conversation events in Intercom and offer screen-pops, but they operate on separate routing engines. Your voice routing rules live in Aircall (or equivalent); your text routing rules live in Intercom. You are managing two routing systems with no unified presence or skill logic across them.

SLA depth on voice: Dixa supports SLA policies that span voice and digital channels in a single configuration. In Intercom, SLAs apply to conversations and tickets — not to calls handled in a third-party CTI — so cross-channel SLA reporting requires custom tooling.

Workflows and AI Automation

Both platforms offer visual workflow builders, but they optimize for different outcomes.

Intercom Workflows and Fin

Intercom's Workflows are designed to deflect volume before it reaches an agent. The platform leans heavily into Fin for autonomous resolution. Fin ingests your knowledge base, past closed tickets, and external URLs to resolve customer queries conversationally.

Intercom's automation excels at triage, data collection via bots, and AI-driven resolution. If an issue requires human intervention, the workflow routes the conversation to a specific team inbox. The Workflows builder supports complex, branching logic with API calls — more extensible than Dixa's visual builder for multi-step automations involving external systems.

A resolution in Intercom's billing model is counted when the customer confirms the answer worked or stops replying for a defined period without asking for more help (an "assumed resolution"). The exact inactivity window and the signals Intercom uses to determine assumed resolution involve multiple factors including conversation state and channel — not a simple 24-hour timer. Escalations to human agents are not billed as Fin resolutions.

Dixa Flow Builder and Mim

Dixa's Flow Builder is a routing engine, not a chatbot engine. It is designed to get the customer to the right human as fast as possible. You build visual decision trees that evaluate channel, time of day, customer priority, queue depth, and agent skills. You define exactly what happens when a VIP customer calls from Germany at 2:00 AM on a Sunday, and Dixa executes that logic deterministically.

Dixa's AI layer consists of two products: Mim (the autonomous customer-facing AI agent) and AI Co-Pilot (agent-assist for drafting, summarizing, and translating). Mim launched in December 2023 as a knowledge-base chatbot and was relaunched in 2025 as a more agentic system. Dixa's AI stack draws from two acquisitions: Solvemate (bot builder) and Miuros (QA and analytics), acquired in 2022 for a combined approximately $43M.

Head-to-Head Feature Comparison

Total Cost of Ownership: The Real Math

Published seat prices tell less than half the story. Neither platform is cheap, and they bill on entirely different axes. Here is the actual math for a 15-agent team handling 8,000 conversations per month.

Intercom TCO (15 agents, Advanced plan)

Fin's resolution pricing is the dominant cost driver. At volume, $0.99 per resolution compounds fast. If Fin successfully deflects 40%+ of inbound volume, the reduction in required human headcount can produce a net-negative TCO — but the math depends entirely on your deflection rate and average handle time for human agents. A high-volume ecommerce operation during peak season will see AI costs spike unpredictably because resolution volume, not seat count, drives the bill.

Intercom's email handling is a known operational gap. Intercom's email channel is functional but consistently rated below dedicated help desk tools (Zendesk, Freshdesk) for shared inbox management, threading, and bulk operations. Teams with high email volume often find they need a separate tool or extensive Workflow configuration to match the email UX they had in a traditional help desk.

Dixa TCO (15 agents, Ultimate plan)

If voice is a primary channel, add telecom costs: per-minute rates for inbound and outbound calls, plus monthly fees for phone numbers. Dixa's telecom rates are regionally variable and must be requested directly. Model these separately and compare against standalone cloud PBX providers before assuming Dixa telephony is cheaper.

Where Each Platform Gets Expensive

Intercom gets expensive when:

• AI resolution volume is high (ecommerce peaks, seasonal surges)
• You need multiple add-ons (Proactive Support, SMS, WhatsApp)
• You're on Expert tier for SLA rules, workload management, and CSAT
• You're tracking millions of free or inactive users (contact record costs)
• You need Fin on email and voice in addition to chat

Dixa gets expensive when:

• Your team is small — the 7-seat minimum is €623/month on Growth before any AI add-ons
• You need AI features (Mim, Co-Pilot, and QA are separate add-ons with opaque pricing)
• You want SCIM/SSO (Enterprise plan only, highest tier)
• Monthly billing rather than annual adds a 15–20% surcharge
• You run a high call volume (per-minute telecom rates scale independently of seat count)

SLA Configuration: A Critical Ops Decision Point

Both platforms offer SLA policies, but the configurability differs in ways that matter for operations-led teams:

• Intercom supports SLA policies tied to conversations and tickets, with rules based on priority, team, and inbox. SLAs do not natively span voice (handled in a third-party CTI). Reporting on SLA breach rates requires either Intercom's built-in reports or API-level extraction.
• Dixa supports cross-channel SLA policies that apply uniformly to phone, email, and chat within a single configuration. You can set different SLA targets by customer priority tier, queue, or language. SLA breach escalation can trigger automatic re-routing within Flow Builder.

If your compliance or enterprise contracts require SLA reporting across all channels including voice, Dixa's unified SLA model is operationally simpler.

API Constraints That Shape Migration

If you're building integrations or planning a migration, API limits are non-negotiable constraints. The two platforms differ significantly here.

Intercom API

• Rate limits: 10,000 API calls per minute per app, 25,000 per minute per workspace. Distributed in 10-second windows (~1,667 calls per 10-second window for the per-app limit). See Intercom API rate limit documentation for current values.
• Authentication: OAuth 2.0 for public apps, bearer token for private apps.
• Data export: CSV dataset export (metadata only), cloud storage export to S3/GCS (JSON, but no conversation transcripts), REST API for full message content.
• Transcript gap: Intercom's built-in export tools silently omit conversation message body content. To retrieve full transcripts, you must use the REST API and paginate through each conversation's parts individually. This is not documented prominently.
• Export job limit: Only one active export job per workspace at a time. A second attempt while one is running returns HTTP 429. Completed exports expire after two days and cannot be re-downloaded.
• Search API ceiling: Limited to 10,000 results per query. For full historical migrations, paginate strictly by updated_at timestamps to avoid hitting the ceiling. Do not paginate by offset — you will receive duplicate or missing records on large datasets.

// Example Intercom Search Payload (timestamp-based pagination)
{
  "query": {
    "field": "updated_at",
    "operator": ">",
    "value": 1672531200
  },
  "sort": {
    "field": "updated_at",
    "order": "ascending"
  }
}

Webhook Behavior: Intercom

Intercom webhooks use a configurable retry policy: failed deliveries are retried with exponential backoff over several hours. Webhook payloads include a delivery_attempts field. Events are delivered at-least-once; implement idempotency on your receiver using the id field. HMAC-SHA256 request signing is available for payload verification.

For a deep dive on Intercom data extraction, see How to Export Data from Intercom: Methods, API Limits & Transcripts.

Dixa API

• Rate limits (main API): 10 requests per second per token, with a short burst allowance of 4 requests and a daily ceiling of 864,000 requests per token. Rate limits are per token, not per organization — splitting work across multiple tokens increases total throughput proportionally. See Dixa API documentation for current values.
• Exports API: Separate base URL at exports.dixa.io. Streams conversations and messages by time range. Rate limited to 10 requests per minute. Data can only be requested in maximum 31-day windows per call. Internal notes are not included in the message export endpoint — they appear under conversation_wrapup_notes in the conversations endpoint.
• No Retry-After header: When you receive a 429, Dixa does not return a Retry-After header indicating when to retry. Implement exponential backoff client-side.
• Authentication: Bearer token. Tokens generated in Settings → Integrations → API token.
• No list-all-conversations endpoint: Conversation retrieval uses POST /v1/search/conversations with filter criteria in the request body.
• No native idempotency on import: Dixa does not deduplicate on re-import. Every retry without client-side deduplication logic creates duplicate conversations that must be manually identified and removed.

# Example Dixa Export Request (31-day window maximum)
curl -X GET "https://exports.dixa.io/v1/conversations?startTimestamp=1672531200&endTimestamp=1675209600" \
  -H "Authorization: Bearer YOUR_DIXA_API_TOKEN"

Webhook Behavior: Dixa

Dixa webhooks have limited documented retry logic. Unlike Intercom, there is no published retry schedule or Retry-After signal on 429 responses. If your webhook receiver is down during an event, you cannot rely on automatic redelivery — implement a polling reconciliation strategy using the Exports API to catch missed events. Event schemas use conversation IDs that are consistent with the main API, enabling join operations.

For Dixa extraction details, see How to Export Data from Dixa: Methods, API Limits & Data Mapping.

Data Model Mapping: What Translates and What Doesn't

Migrating between these platforms is not a copy-paste. The data models have fundamental structural differences. Because of the architectural mismatch — relational/object-oriented vs conversation-centric — you must translate, not transfer.

Objects That Map Cleanly

Objects That Don't Map

• Intercom Tickets → Dixa: Dixa has no separate ticket object with a formal state machine (open → pending → snoozed → resolved → closed). Everything in Dixa is a conversation. You lose ticket-specific SLA clocks, status workflows, and ticket type configurations.
• Intercom Product Tours, Banners, Carousels → Dixa: No equivalent. These are Intercom-specific engagement features with no functional analog in Dixa.
• Intercom Series (multi-step campaigns) → Dixa: No equivalent. Engagement flows must be rebuilt using external marketing automation tools or Dixa's Flow Builder for routing-only scenarios.
• Intercom Custom Objects → Dixa: Dixa does not support relational Custom Objects. Flatten this data into custom attributes or tags. For example, if an Intercom conversation is linked to a "Workspace" custom object, extract the Workspace ID and relevant attributes, then inject them as custom attributes on the Dixa end user or conversation record.
• Dixa Queues and Offer Logic → Intercom: Intercom has no push-based routing. Rebuild as assignment rules and Workflows. Accept that agent experience will change: agents will go from receiving pushed conversations to managing a shared inbox.
• Dixa Native Voice → Intercom: There is no native destination. Call recordings must be downloaded from Dixa, stored externally (e.g., AWS S3 with a signed URL), and appended as note links in Intercom conversation history. Intercom does not natively host audio files.
• Dixa Flow Builder automations → Intercom: Must be rebuilt as Intercom Workflows. The visual paradigms differ enough that this is a manual redesign, not a migration. Dixa's routing-first logic (skills, presence, priority queues) maps poorly to Intercom's segmentation-first logic (user attributes, custom object values).

Data Retention and GDPR Considerations

For teams in regulated industries or EU jurisdictions, data retention and deletion behavior are decision-relevant factors that most comparison guides omit.

Intercom stores conversation data in the US by default. EU hosting is available but requires explicit configuration and is plan-restricted. GDPR deletion requests (Article 17 right to erasure) can be submitted via the Intercom API — specifically by deleting the Contact record, which triggers deletion of associated conversation metadata. However, conversation message content retention timelines and the propagation of deletion through backups are not publicly documented in detail. Verify current data retention schedules with Intercom's legal or privacy team before committing if this is a compliance requirement.

Dixa is EU-native, hosted on AWS eu-west-1 (Ireland). Personal data does not leave the EU by default, which simplifies GDPR Article 5 compliance documentation. Dixa's data processing agreement (DPA) is available on request and covers sub-processor obligations. Right-to-erasure requests can be fulfilled via the API by deleting end user records. Internal notes (conversation_wrapup_notes) are stored separately from message content — account for both when fulfilling deletion requests.

Practical implication: If your legal team requires documented data residency and predictable deletion propagation for customer data, Dixa's EU-native architecture is operationally simpler to defend in a compliance audit than Intercom's US-default model with optional EU hosting.

Migration Path: Intercom → Dixa

Extraction

1. Contacts: Paginate through GET /contacts with cursor-based pagination. Export users, leads, and company associations separately.
2. Conversations with transcripts: List conversations via GET /conversations, then fetch each conversation's parts individually using GET /conversations/{id}. At roughly 8 API calls per conversation on average (list + parts fetch + attachment metadata), 100K conversations ≈ 800K API calls against the Intercom API.
3. Tags and custom attributes: Extract during the contact and conversation pull — they are embedded in the response bodies.
4. Articles: Use the Articles API to export help center content with collection and section hierarchy.

Transformation

• Flatten Intercom's Company → Contact relationship into Dixa end user custom attributes (e.g., company_id, company_name, plan).
• Map Intercom ticket states to Dixa conversation statuses. Dixa has fewer states; build a mapping table before transformation and document what state information you are discarding.
• Convert Intercom conversation parts into Dixa message format. Dixa's import endpoint supports only email and genericapimessaging channel types — all historical chat, in-app, and social messages must be imported as one of these two types. This is a semantic loss that affects historical channel attribution reporting.
• Tag conversations handled entirely by Fin with a specific label (e.g., handled_by_fin) so historical reporting remains accurate after migration.
• Parse HTML content of Intercom messages, extract inline image URLs, download the images, and re-upload as Dixa attachments. Images linked inline in Intercom messages will break if Intercom deactivates the CDN after migration.
• Preserve original created_at and updated_at timestamps explicitly — do not allow the import tool to overwrite them with import timestamps.

Load into Dixa

• Use Dixa's API at 10 req/s per token. For 100K conversations, plan for approximately 2–4 hours of import time per token with error handling and backoff.
• Implement client-side deduplication with a lookup table keyed on the original Intercom conversation ID before every write. Dixa has no native idempotency — retries create duplicate records that must be identified and removed manually.
• Run a test batch of 1,000–2,000 conversations, validate message ordering, timestamp accuracy, and attachment accessibility before running the full import.

Timeline Estimate

For a team with ~20 agents and 100K historical conversations: 3–5 weeks including planning, data mapping design, test migration, workflow rebuild in Dixa's Flow Builder, agent training, and validation. The workflow rebuild phase — not the data transfer — typically drives timeline.

Migration Path: Dixa → Intercom

Extraction

1. Conversations and messages: Use the Exports API at exports.dixa.io. Stream conversations and messages by time range in maximum 31-day windows. Plan your date-range chunking before starting.
2. Internal notes: These live under conversation_wrapup_notes in the conversations endpoint — they are not returned by the message export endpoint. Fetch separately.
3. End users: Extract via the main Dixa API. Includes custom attributes.
4. Tags: Embedded in conversation export records.
5. Knowledge base: Use the Dixa Knowledge API to export articles with category hierarchy.
6. Voice recordings: Call recordings are returned as time-limited URLs in the API response. Download and store to a persistent external location (AWS S3 or equivalent) during extraction — do not rely on Dixa's hosted URLs remaining valid post-migration.

Transformation

• Map Dixa end users to Intercom Contacts. Decide upfront whether historical contacts become user or lead type in Intercom — this affects segmentation and billing.
• If you tracked company information in Dixa custom attributes, restructure into Intercom Companies and create contact-company associations.
• Map Dixa's internal agent IDs to Intercom Admin IDs to preserve the historical record of which agent handled each conversation. Maintain a lookup table during transformation.
• Convert Dixa conversation messages into Intercom conversation parts format.
• Voice recordings: generate signed S3 URLs and append to Intercom conversations as internal notes with structured metadata (duration, recording URL, call direction, agent name).
• Dixa internal notes (conversation_wrapup_notes) map to Intercom conversation notes — preserve authorship and timestamps.

Load into Intercom

• Use the Conversations API to create historical conversations with explicitly preserved timestamps.
• Intercom's API allows 10,000 calls/min per app — significantly higher throughput than Dixa's export rate. The bottleneck in a Dixa → Intercom migration is almost always the Dixa extraction side, not the Intercom import side.
• Intercom does not fire workflow triggers or automations on API-imported conversations, which is the correct behavior for historical data import. Verify this in your test batch before running at scale.

Timeline Estimate

Similar team profile (20 agents, 100K conversations): 3–5 weeks. Dixa's extraction rate limits slow the extraction phase, but Intercom's higher import throughput compensates. The primary timeline driver is the same as the reverse direction: workflow redesign and agent retraining, not data volume.

When to Pick Intercom

• You're a product-led SaaS company where support lives inside the product and context about user behavior in the app is essential for effective support.
• In-app messaging, product tours, proactive engagement, and email campaigns are central to your CX strategy — you need a single platform for both marketing and support touchpoints.
• You want AI-first resolution and accept usage-based AI pricing with the understanding that high-deflection scenarios yield ROI.
• Support requires deep relational context — Companies, Custom Objects, segmentation by plan or feature usage.
• Voice is a secondary or non-existent support channel.
• You want a large ecosystem of native integrations and a high-throughput REST API.
• Your team can be as small as one seat — Intercom has no minimum.

When to Pick Dixa

• Voice is a primary channel — you need native VoIP, IVR, call recording, transcription, and number porting without a separate telephony vendor.
• You're an ecommerce, retail, or travel company with native Shopify or Magento requirements and need order-context routing.
• You want EU data residency by default (AWS eu-west-1, Ireland) without extra configuration or plan upgrades, and need a straightforward GDPR compliance story.
• You prefer push-based routing where agents receive work deterministically rather than pulling from shared inboxes — important for contact centers managing adherence and occupancy metrics.
• You manage complex multi-brand, multi-language, or multi-queue SLA routing rules that must apply uniformly across voice and digital channels.
• AI cost predictability matters more than AI resolution depth — Mim's flat-rate billing avoids per-resolution cost spikes during volume surges.
• Your team has at least 7 agents — the minimum commitment is a hard constraint, not a soft recommendation.

When to Pick Neither

• If you need a pure ticket management system with deep SLA policies, group SLAs, and extensive views and triggers — evaluate Zendesk. See our Zendesk vs Intercom guide.
• If you need a flat-rate, EU-hosted platform for a very small team (under 7 agents) — look at Crisp. See our Crisp vs Intercom guide.
• If you're weighing Intercom against Freshdesk, see our Freshdesk vs Intercom decision matrix.
• If you need deep CRM alignment, structured ticket pipelines, and cross-department visibility, evaluate HubSpot Service Hub. See our Intercom vs HubSpot Service Hub guide.

The Salesforce Acquisition Factor

The pending Salesforce acquisition adds a variable you cannot ignore if you're signing a contract today. The deal is signed but not closed as of mid-2026. Pricing and API endpoints have not changed. But Salesforce has stated intent to integrate Fin into Agentforce, which raises three realistic post-close scenarios that any multi-year commitment should account for:

1. Fin bundled into Salesforce Service Cloud: If Fin becomes a component of Salesforce's existing product line, standalone Intercom pricing tiers may be retired or restructured. Customers without Salesforce contracts could face price increases or feature deprecation.
2. API and integration priorities shift toward Salesforce ecosystem: Intercom's broad third-party integration ecosystem has been a key differentiator. Post-acquisition, native Salesforce CRM and Service Cloud integrations may receive investment priority while others stagnate.
3. Agentforce displacement of current tier structure: Salesforce's agent AI platform uses a different pricing model than Intercom's current per-resolution structure. Migration between models post-close could create billing surprises.

Practical guidance by situation:

• Already on Intercom and satisfied: No immediate action required. Monitor post-close product announcements, specifically around pricing tier changes and API deprecations.
• Evaluating Intercom for a new deployment: Negotiate contractual price-protection clauses, API stability guarantees, and flexible exit terms before the deal closes. Get commitments in writing.
• Existing Dixa customer evaluating a switch to Intercom: Wait until the acquisition closes and the initial integration roadmap is published before committing to a multi-year Intercom contract.

Making the Call

Intercom and Dixa solve different problems for different operational contexts. Intercom is the right platform when your world revolves around in-app engagement, relational customer data, AI-first resolution, and a product-led operating model. Dixa is the right platform when native voice, deterministic push-based routing, EU data residency, and ecommerce channel integrations are non-negotiable.

The wrong choice costs you a multi-quarter migration project to undo. The data model differences are fundamental — not superficial — and the workflow redesign phase is consistently the hard part. Neither platform's native export tools make it easy to leave: Intercom drops transcripts from its bulk exports, and Dixa's Exports API forces 31-day chunking with no idempotency guarantees on the import side.

Do not assign a cross-architecture migration to a junior developer as a weekend script. The data mapping between a relational object model and a conversation-centric model requires deliberate architectural planning to avoid historical data loss, duplicate records, and broken SLA reporting.