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

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

Crisp is a flat-rate, EU-hosted messaging platform built for small teams. Intercom is a per-seat, AI-first customer platform built for scale. The choice between them comes down to whether you need predictable costs and simplicity or relational data models, autonomous AI, and enterprise workflows.

This guide covers the real architectural differences, total cost of ownership math, API constraints — including rate limits, webhook behavior, and search API limitations — data model gaps, and what actually happens when you need to move data in either direction.

Core Architecture: Conversation-First vs Object-Oriented

This is the fundamental divide that drives every downstream difference — billing, reporting, integration complexity, and migration difficulty.

Crisp: The Unified Conversation Stream

Crisp is a conversation-first messaging platform. Every interaction — live chat, email, WhatsApp, Instagram, Messenger, Telegram, Line — flows into a single continuous conversation thread per contact. When a visitor initiates a chat, Crisp creates a session. Every subsequent interaction is appended to that same thread.

This model works well for fast, transactional support. Agents see the full customer history in a single scroll without digging through past tickets. Ticketing is available only on the Plus plan.

But the architecture introduces hard limits at scale:

• No real company objects. Company data is embedded directly on contact profiles as custom attributes. You can't query "all contacts at Company X" without scanning every profile. B2B teams managing multi-contact accounts hit this ceiling fast.
• No discrete ticket resolution on lower plans. The thread is continuous — closing a conversation merely archives the session until the user replies. You can't easily separate a billing inquiry from a bug report submitted by the same user a week later.
• Flat CRM layer. Custom data attributes exist, but there's no relational depth between contacts, companies, and deals.
• Conversation message limits. Crisp enforces a per-conversation message ceiling (documented in their API as returning 409 too_many_messages when exceeded). Long-running integrations or high-frequency bots are the primary trigger.

Intercom: Discrete Objects With Relationships

Intercom operates on an event-driven, object-oriented architecture. Data is structured around standard objects:

• Contacts — users and leads, distinguished by a role attribute.
• Companies — relational objects that group multiple contacts.
• Conversations — discrete threads containing conversation parts (individual messages, notes, assignments, state changes). Each part is a discrete record with its own metadata.
• Tickets — separate from conversations, with their own lifecycle and SLA rules.
• Custom Objects — external data entities (Orders, Subscriptions, Workspaces) linked to contacts or companies.

When a user contacts support, Intercom creates a discrete conversation. A user can have an open billing ticket assigned to finance and an open bug report assigned to tier-2 engineering simultaneously, without threads colliding. Company ↔ contact relationships are explicit — you can attach multiple contacts to a company and query them independently.

The trade-off: Intercom's data model is more complex to work with. Conversation parts are not returned when listing or searching conversations — only when retrieving a single conversation by ID. There is a hard limit of 500 parts per conversation, and Intercom's search API (v2.x) does not support full-text search on conversation body content — searches are limited to metadata fields (contact ID, assignee, tag, state). This significantly constrains migration scoping and conversation auditing workflows.

For B2B SaaS companies managing account hierarchies, the object-oriented architecture is a requirement, not a luxury. The ability to link a conversation to a specific Custom Object (like a failed payment event) enables routing and automation that Crisp cannot support.

Pricing: Flat-Rate vs Per-Seat + Usage

Crisp Pricing (2026)

Crisp bills per workspace, not per seat. Each plan includes a fixed number of agents.

Key constraints:

• AI credit limits are the hidden gate. Essentials includes a daily AI action cap — once depleted, Hugo AI stops unless pay-as-you-go billing is enabled. Verify your current cap directly in the Crisp dashboard, as Crisp has adjusted these limits across plan iterations.
• Seat expansion only on Plus. Free, Mini, and Essentials have hard agent caps with no expansion option — you must upgrade the entire plan.
• Plus is the realistic minimum for teams that need ticketing, advanced analytics, white-labeling, or meaningful AI automation.

Intercom Pricing (2026)

Intercom bills per seat with separate usage-based charges for AI and messaging channels.

On top of seat costs:

• Fin AI Agent: $0.99 per resolution. A resolution is a conversation handled entirely by Fin without escalation to a human agent. This is the primary cost driver for high-volume teams.
• SMS, WhatsApp, phone are billed per message/minute.
• Proactive Support Plus add-on runs $99/month for 500 messages.
• No free plan. Only a 14-day trial.

TCO Comparison: Real Numbers, Not Marketing Math

Headline pricing is meaningless without modeling your actual team size and conversation volume.

Scenario 1: 5-Agent Startup, ~500 Conversations/Month

Crisp wins by a wide margin at this scale. The daily AI action cap on Essentials is likely sufficient for low-volume teams.

Scenario 2: 10-Agent Mid-Market Team, ~3,000 Conversations/Month

The gap is substantial. But at that price, Intercom provides advanced workflows, SLA management, product tours, and autonomous AI resolution across multiple channels.

Scenario 3: 25-Agent Scale Team, ~10,000 Conversations/Month

The price delta is stark. But price alone doesn't capture the operational cost of hitting Crisp's architectural limits — manual workarounds for missing SLA enforcement, building integrations that Intercom provides natively, or running separate tools for product onboarding.

Feature Comparison: What Actually Matters

AI Capabilities

Intercom's Fin AI Agent handles conversations end-to-end — not just deflection, but autonomous resolution across chat, email, WhatsApp, SMS, phone, and Slack. Fin is built on Intercom's own fine-tuned support model, optimized for resolution rate rather than general-purpose generation. Per-resolution pricing means you pay only when Fin closes a conversation without human escalation.

Crisp's Hugo AI drafts replies, translates messages, and answers questions from your knowledge base. It's effective for agent assistance on the Plus plan but does not approach Fin's autonomous resolution capability. Hugo runs on plan-bundled AI credits and stops when depleted on lower tiers.

If your primary AI use case is autonomous resolution at scale, Intercom is the clear choice. If it's agent assist (faster drafts, translations, suggested replies), Crisp handles it adequately on Plus.

Event Tracking and Product Analytics

Crisp allows you to push custom events via their JavaScript SDK or REST API. Events appear in the user's timeline, giving agents context, and can trigger automated campaigns. However, you cannot build multi-step SLA rules or state-machine logic based on historical event frequency or event metadata combinations.

Intercom's event tracking is foundational. You can track up to 120 unique event types per contact, each with arbitrary metadata. Intercom's automation engine can evaluate event history — for example: "If a user triggers export_failed three times within one hour, and their Company MRR exceeds $1,000, create a high-priority ticket and notify the on-call engineer." This depth extends Intercom well beyond support into customer success and proactive lifecycle management.

Channels, Webhooks, and Inbox

Channel coverage:

Webhook architecture:

Crisp provides webhooks for conversation events (message:send, message:received, conversation:opened, conversation:closed, conversation:assigned) and contact events (profile:created, profile:updated). Webhooks fire per workspace and use HMAC-SHA256 signing for payload verification. Crisp does not provide delivery receipts or built-in retry logic — if your endpoint returns a non-200 response, the event is dropped. Teams that need guaranteed delivery must implement their own acknowledgment and replay layer.

Intercom webhooks cover a broader event surface: conversation events, ticket state changes, user events, and company events. Intercom's webhook delivery includes automatic retry with exponential backoff for failed deliveries (non-2xx responses trigger retries over 72 hours). Payloads are signed with a client secret for verification. Intercom also supports topic-level subscriptions, allowing you to subscribe to only the event types your integration needs rather than receiving all workspace events.

Key gap: Intercom webhooks do not include full conversation part content by default — they include a conversation ID and metadata. Receiving the message body requires a follow-up API call to retrieve the conversation part. This doubles API call volume for real-time message-processing integrations.

Mobile SDK Comparison

Both platforms provide iOS and Android SDKs, but with different design philosophies:

Crisp Mobile SDK:

• Open-source iOS (Swift) and Android (Kotlin) SDKs available on GitHub
• Renders the Crisp chat widget inside a WKWebView / WebView component — not a native UI
• Supports user identity token authentication
• No offline message queuing — messages require active connectivity
• Push notifications require manual APNs/FCM configuration

Intercom Mobile SDK:

• Native iOS (Swift/Objective-C) and Android (Kotlin/Java) SDKs with fully native UI components
• Supports push notifications with Intercom-managed certificate handling
• Includes in-app message rendering (banners, tooltips, surveys) natively
• Offline message queuing with automatic send-on-reconnect
• Larger SDK size (~5-8MB iOS, ~3-5MB Android) vs. Crisp's lighter WebView approach

For consumer-facing mobile apps where in-app engagement (onboarding flows, NPS surveys, product tours) matters, Intercom's native SDK is meaningfully superior. For internal tools or B2B apps where chat is a secondary feature, Crisp's WebView approach is adequate and easier to integrate.

Knowledge Base and Help Center

Both platforms include knowledge base functionality, but with different capability levels:

Crisp Knowledge Base (Plus plan only): Article editor with basic formatting, public-facing help center with custom domain support, and integration with Hugo AI for article-sourced replies. No article versioning, no multi-language content management, no analytics on article deflection rates.

Intercom Help Center: Multi-collection organization, article versioning, multi-language support (content can be served in the user's detected language), and detailed article analytics (views, reactions, conversation deflection rates per article). Fin AI draws on Help Center articles as its primary knowledge source and can cite specific articles in its responses.

Integrations and Extensibility

Crisp's native integration catalog includes approximately 29 apps. These cover essentials — Slack, Stripe, HubSpot, Salesforce — but integrations are surface-level. The Stripe integration displays subscription status in the agent sidebar but does not support two-way actions. Deeper functionality requires custom middleware via the REST API.

Intercom's marketplace includes 350+ apps. Because of its object-oriented design, integrations embed deeply into routing and automation engines. The Salesforce integration natively maps Intercom Custom Objects to Salesforce Custom Objects for bi-directional sync without relying on Zapier.

Intercom also provides the Canvas Kit, a UI framework for building interactive applications inside the messenger. A SaaS company can build a custom app that lets users upgrade their plan, select add-ons, and process payment — all within the chat window, without talking to an agent.

Ticketing and SLA Management

Crisp Plus adds ticketing but lacks the enforcement mechanism that makes SLAs operationally meaningful — breach alerts, SLA-based routing rules, and reporting on SLA compliance. Intercom Advanced supports multiple concurrent SLA policies with configurable first-response and resolution targets, breach notifications to team leads, and retrospective SLA reporting.

Data Residency and GDPR

Crisp has a structural advantage here. It's a French company (SAS Crisp IM) that stores all data in the EU — messaging data in the Netherlands, plugin data in Germany — by default. No configuration required. No customer data is transferred outside the EU.

Intercom offers EU data hosting as an opt-in configuration during workspace provisioning. You must explicitly select the EU region at workspace creation — you cannot migrate an existing US-hosted Intercom workspace to the EU region after the fact. The workspace region is permanent. Teams with GDPR hard requirements should verify their workspace region in Settings → General before importing any customer data.

API Architecture: Constraints That Drive Your Timeline

Crisp REST API

• Authentication: Website tokens (single workspace, quick setup) and Plugin tokens (multi-workspace, configurable quotas via Crisp Marketplace).
• Rate limiting: Multi-level system based on client IP and user identifier. Plugin tokens use a daily quota system instead of per-minute limits, allowing controlled burst requests. Higher quotas available on request via Crisp Marketplace submission.
• Data export: Contact profiles exportable as CSV from the dashboard. Conversation data — messages, notes, attachments — has no native bulk export. You must extract via the REST API page by page.
• Search: Conversations are filterable by status, assignee, and segment. No full-text search on message body via API.
• Webhook delivery: No built-in retry. Non-2xx responses result in dropped events.

Intercom REST API

• Rate limiting: 10,000 API calls per minute per app, 25,000 per workspace. Distributed across 10-second windows (max ~1,666 requests per 10-second window). Rate limit headers (X-RateLimit-Remaining, X-RateLimit-Reset) are included in every response.
• Conversation parts: Not returned when listing or searching conversations — only on single conversation retrieval via GET /conversations/{id}. Hard limit of 500 parts per conversation.
• Search API limitation: The /conversations/search endpoint in v2.x does not support full-text search on conversation body. Searchable fields are limited to metadata: contact ID, admin ID, tag, state, created_at range, custom attributes. This means you cannot retrieve "all conversations mentioning refund" via the API alone.
• Attachment URLs: User-uploaded files return signed URLs that expire after 30 minutes. You must download attachments immediately after fetching each conversation — you cannot batch-export and download later.
• No bulk create endpoint for contacts. Contacts must be created individually via POST /contacts with rate-limit handling.
• Webhook delivery: Automatic retry with exponential backoff over 72 hours for non-2xx responses.

Migrating Between Crisp and Intercom

Whether you're moving from Crisp to Intercom or the reverse, this is an API-first project. Neither platform offers a native import/export path for the other.

Data Model Mapping

Crisp → Intercom Migration

Step 1: Extract Data from Crisp

Query GET /website/{website_id}/conversations/ for a paginated list of session IDs, then make secondary requests per session for messages, timestamps, and sender metadata. Implement exponential backoff — concurrent requests against large conversation sets will trigger IP-level throttling. Download all attachments immediately during extraction, as Crisp's signed URLs expire.

curl -X GET "https://api.crisp.chat/v1/website/{website_id}/conversations/{session_id}/messages" \
  -H "Authorization: Basic {encoded_credentials}" \
  -H "X-Crisp-Tier: plugin"

Step 2: Transform and Map Data

Crisp's flat CRM doesn't map 1:1 to Intercom's relational model. For each contact with a company_name custom attribute:

1. Normalize company names (Crisp stores them as free-text — deduplication is required)
2. Create the Company in Intercom via POST /companies
3. Retrieve the new Company ID
4. Associate the Contact to the Company

Conversation splitting is required for any thread exceeding 500 messages — Intercom will reject the load otherwise. Decide on a splitting strategy (by date window, by topic if parseable, by arbitrary 450-part chunks) before writing your transform layer.

Step 3: Load into Intercom

{
  "user_id": "usr_12345",
  "body": "Historical message content",
  "created_at": 1672531200
}

Critical requirements during load:

• Preserve original timestamps. Use Unix timestamps in created_at — otherwise all historical conversations appear as created on import day.
• Create agents and contacts before conversations. Author mapping requires Intercom admin IDs and contact IDs to exist before conversation parts reference them.
• Re-host attachments. Download from Crisp during extraction, upload to durable storage, and reference stable URLs when creating conversation parts in Intercom. Intercom's 30-minute attachment URL expiry also applies during subsequent API reads.

Intercom → Crisp Migration

This direction is structurally different and often overlooked. The primary challenges are:

Data model flattening. Intercom's relational Company → Contact hierarchy must be flattened into Crisp's contact-centric model. Company attributes (name, plan, MRR) become custom attributes on each individual contact profile. If multiple Intercom contacts share a company, their company data becomes redundant attribute values on separate Crisp profiles.

Conversation part reassembly. Intercom conversation parts include messages, notes, assignment events, and state-change events. Crisp only has message and note types. Assignment events and state changes must be either dropped or converted to internal notes during transformation.

Custom Objects don't transfer. Intercom Custom Objects (Orders, Subscriptions, etc.) have no equivalent in Crisp. This data either needs to migrate to a separate CRM or be embedded as custom attributes on contact profiles, losing relational integrity.

Ticket → Conversation mapping. Intercom Tickets are separate objects from Conversations. In Crisp, both become conversation threads. During migration, create Crisp conversations from Intercom tickets and prepend ticket metadata (type, priority, SLA deadline) as an internal note.

Extraction approach:

# Retrieve all Intercom conversations (paginated)
curl -X GET "https://api.intercom.io/conversations" \
  -H "Authorization: Bearer {access_token}" \
  -H "Intercom-Version: 2.11"
 
# Retrieve full conversation with parts (required separately)
curl -X GET "https://api.intercom.io/conversations/{conversation_id}" \
  -H "Authorization: Bearer {access_token}" \
  -H "Intercom-Version: 2.11"

Download all attachment URLs immediately — they expire 30 minutes after the API response.

Migration Architecture

┌─────────────┐     ┌──────────────────────────┐     ┌─────────────────┐
│  Source API  │────▶│     Transform Layer       │────▶│  Target API     │
│  (Extract)   │     │  (Map + Validate + Split) │     │  (Load)         │
└─────────────┘     └──────────────────────────┘     └─────────────────┘
       │                         │                            │
  Pagination +            Company dedup               Rate limit handling
  exponential backoff     Conversation splitting      (10K/min Intercom,
  Download attachments    >500 parts                  daily quota Crisp)
  immediately             Flatten objects             No bulk create
                          (Intercom → Crisp)          Re-host attachments
                          Drop/convert                Preserve timestamps
                          assignment events

Critical Migration Edge Cases

1. Attachment expiration in both directions. Crisp's signed URLs expire at an undocumented interval. Intercom's attachment URLs expire after 30 minutes. In either direction, download files during active pagination — never defer attachment handling.
2. Conversation threading decisions. Crisp's continuous conversation model means a single thread can span months or years. Decide before migration whether to preserve the full thread or split by date window. This affects both Intercom's 500-part limit and usability post-migration.
3. Intercom search API limitation affects pre-migration auditing. You cannot search Intercom conversations by body content via API. Scoping a partial migration (e.g., "only migrate conversations mentioning billing") requires exporting full conversation text and filtering locally.
4. What doesn't transfer: Chatbot/workflow configurations, knowledge base articles (require separate migration), analytics history, internal segments, and SLA policy definitions must be rebuilt manually in the target platform.

Knowledge Base Migration

Neither platform provides an API bridge for knowledge base content. Articles must be migrated manually or via script:

1. Export articles from Crisp (or Intercom) via their respective content APIs
2. Transform HTML/Markdown content, preserving heading structure and internal links
3. Re-upload images (article image URLs from both platforms are not permanent)
4. Recreate collection hierarchy in the target platform
5. Update internal article cross-links to new target article IDs

Intercom's Help Center API (GET /articles, POST /articles) supports programmatic migration. Crisp's knowledge base has more limited API coverage — article creation via API requires Plus plan access.

For large knowledge bases (500+ articles), plan 2–5 additional days beyond conversation migration.

When to Choose Crisp

• You have fewer than 20 support agents and want predictable flat pricing.
• EU data residency is a hard requirement and you want it by default, not as an opt-in configuration.
• You're an SMB with high-volume, transactional support where requests are generally resolved in a single session.
• Budget is the primary constraint — at $295/mo for 20+ agents with AI and ticketing, Crisp is 5–20x cheaper than comparable Intercom setups depending on conversation volume.
• You need Telegram or Line as native channels without custom middleware.
• You don't need relational company objects, custom objects, or SLA enforcement with breach alerting.
• Your mobile app integration can work with a WebView-rendered chat widget rather than native SDK components.
• Your webhook integrations can tolerate dropped events (no retry logic required).

When to Choose Intercom

• You need AI to autonomously resolve a large percentage of conversations — Fin's per-resolution model makes ROI calculable and direct.
• You're a B2B SaaS company managing account hierarchies, custom objects, and user-level event analytics.
• You need full-lifecycle product engagement: in-app messages, product tours, outbound campaigns, and NPS surveys alongside support.
• Your team needs advanced SLA enforcement with breach alerting, multi-policy support, and compliance reporting.
• You want native mobile SDK components (not WebView) for iOS and Android.
• Your webhook integrations require guaranteed delivery with automatic retry.
• You need 350+ native integrations with deep routing and automation embedding.
• You're scaling past 20 agents and need Canvas Kit for building interactive in-messenger applications.
• You're already in the Salesforce ecosystem — the pending acquisition may create deeper native integration post-close.

When to Choose Neither

• E-commerce brands on Shopify with order management requirements should evaluate Gorgias, which has native Shopify data access (order status, refund actions) built into the agent interface — neither Crisp nor Intercom matches this depth for commerce workflows.
• Email-first B2B teams handling complex, multi-stakeholder deals may find Help Scout or Front a better fit among other Crisp alternatives — both handle shared inboxes and CC/BCC threading more naturally than either platform's chat-centric design.
• Enterprise teams on Salesforce Service Cloud already have case management, SLA enforcement, and customer data in one platform. Adding Intercom creates data duplication and workflow fragmentation unless the specific use case is product-led growth engagement, not core support.

The Salesforce Acquisition: What It Means for This Decision

Salesforce signed the definitive agreement to acquire Fin (formerly Intercom) on June 15, 2026 for approximately $3.6 billion. The deal is expected to close in Salesforce's Q4 FY2027, pending regulatory approval.

Short-term (now through close): Nothing changes. Fin operates independently. Pricing, APIs (api.intercom.io), OAuth scopes, and support channels remain the same.

Medium-term (post-close): Expect Fin's AI agent capabilities to integrate with Salesforce's Agentforce platform. The Intercom Custom Object model maps naturally onto Salesforce's object schema, which could accelerate native bi-directional sync beyond what the current Salesforce marketplace integration provides.

Long-term risk: Post-acquisition pricing restructuring is a documented pattern in enterprise software consolidation. Teams signing multi-year Intercom contracts should negotiate explicit price-protection clauses and API continuity guarantees. The Intercom API endpoint structure (/intercom.io) has not changed post-rebrand, but that provides no contractual protection post-acquisition.

For teams choosing Crisp specifically to avoid enterprise platform dependency, the acquisition reinforces that rationale. For Salesforce-native organizations evaluating support tooling, it makes Intercom more strategically attractive — but only after close and integration work are complete.

Migration Scoping Reference