Choose a customer service app by matching its channels, customer-data system of record, collaboration model, and billing unit to the way your team actually works. A team already using HubSpot CRM may value shared customer context more than another standalone inbox. An ecommerce team may instead prioritize order actions inside support conversations.
Customer service apps receive, track, route, and help resolve customer conversations. A full help desk manages tickets across support channels; a social-care tool focuses on social messages; an ecommerce support workspace may add store and order actions. This is an operational buying guide, not a universal ranking. Pricing and product details are a research snapshot dated October 10, 2026. Confirm current plans and entitlements with vendors before buying.
Start with four questions: Which channels must the team support? Where is the authoritative customer record? What unit drives the bill: seats, tickets, AI outcomes, sessions, or credits? Which actions require human approval?
How to choose a customer service app
Choose the operating model before comparing feature lists. Shortlist two or three products, then test the same representative case in each one: receive a message, find its customer context, assign ownership, complete the required action, report on the result, and export or retrieve the data you need.
Record what happens at each step. Does the app preserve the source conversation ID? Can an agent see the account record without a fragile synchronization process? Can a supervisor distinguish an automated suggestion from a human decision? Does the price change when a rule, AI agent, or human sends a message?
The best shortlist is the one that completes a real case with clear ownership, preserved context, and a predictable cost unit. Test the workflow before scoring optional features.
Match the app to your operating model
Use the following as fit hypotheses based on documented vendor positioning, not independent performance rankings. If customer data is spread across business systems, decide how the app will connect to your CRM systems and which system will own each field.
| Operating need | Candidate | Pricing or packaging signal | Verify before buying |
|---|---|---|---|
| Support and sales context share a CRM record | HubSpot Service Hub | Free plan for up to two users; Starter from $7 per seat/month under the displayed annual-billing structure | Edition entitlements, onboarding fees, and HubSpot Credits |
| Highly configured ticket operations | Zendesk | Ticketing APIs support creation and updates; no current price quoted here | Required plan, permissions, limits, and implementation effort |
| In-app support and AI outcomes | Intercom | Fin is $0.99 per outcome with Intercom, in addition to applicable plan and seat costs | Outcome definitions, channel costs, and expected usage |
| Ticket-focused support | Freshdesk | Growth is $19 per agent/month when billed annually; paid plans list included AI sessions | Current offer, session allowance, and whether Freshdesk Omni is needed |
| Ecommerce actions in the support workspace | Gorgias | Ticket usage, separate AI automation charges, and possible overages | Ticket counting, AI charges, store permissions, and voice or SMS add-ons |
| Cross-functional case coordination | Front | Starter is $25 per seat/month annually and is single-channel | Whether required channels need a higher plan or add-on |
| Credit-based AI support | Helply | Current materials describe plans starting at $49/month and credit-based AI billing | Credit consumption, included usage, and the current product edition |
HubSpot positions Service Hub as connected to its CRM. Its current pricing page lists Professional from $90 per seat/month and Enterprise from $150 under the displayed annual-billing structure, with required onboarding fees of $1,500 and $3,500 respectively. AI features may also consume HubSpot Credits. Review the official Service Hub pricing and product overview for plan conditions.
Zendesk is a candidate when ticket customization and operations controls matter. Its documentation covers ticket creation, updates, custom fields, and safe updates. Intercom suits teams centering support in a digital product and offers outcome-priced Fin when used with Intercom. Freshdesk is worth considering for ticket-oriented work, but distinguish it from Freshdesk Omni when checking phone and other real-time channels. Gorgias is positioned for ecommerce, where supported store integrations can bring order actions into support work. Front emphasizes team coordination. Helply is a separate credit-based AI offering whose current materials should not be confused with earlier per-ticket pricing.
Compare total cost, not headline price
Build a monthly estimate for low, expected, and peak demand. Record human seats, tickets or conversations, expected AI outcomes or sessions, voice and SMS charges, onboarding, annual minimums, overages, integration costs, and occasional collaborators who need access.
- Seat-based: multiply required seats by the applicable plan price, then add usage, channel charges, and onboarding.
- Outcome-based: estimate billable AI outcomes separately from seats and plan charges. Intercom’s Fin outcome charge is additional to applicable plan and seat costs.
- Ticket-based: confirm what counts as a ticket and whether human, automated, or AI messages incur a help-desk ticket fee. Gorgias documents ticket usage, separate AI automation charges, and possible overages.
- Session-based: confirm how many AI sessions are included and the price of additional packs. Freshdesk’s current pricing page lists included Freddy AI Agent sessions on paid plans and additional session packs.
- Credit-based: estimate credits for expected AI work. HubSpot AI features may consume HubSpot Credits, while Helply’s current materials describe credit-based AI billing.
Use current vendor pricing pages and your own volume assumptions, not a single advertised starting price. If an overage or usage rule is unclear, ask for a written estimate using normal and peak volume before signing. Calculated scenarios are planning estimates, not vendor quotes.
A seat price, ticket fee, AI outcome, session allowance, and credit balance are different cost units. Convert each into the cost of the workload your team expects to handle.
Design intake and AI classification before automating routing
Separate hard routing constraints from ambiguous language. Use deterministic rules for account tier, contractual SLA, known channel queues, explicit security escalation, permission checks, and duplicate suppression. AI can propose a controlled intent label, summarize a long message, or suggest a queue. It should not decide identity, contractual entitlement, or whether a security rule applies.
Intercom documents webhook configuration and conversation event topics. The sequence below is a proposed integration design built around that documented mechanism. It is not a complete Intercom connector or a vendor-published workflow.
The following contract is illustrative. Its field names, taxonomy, and confidence value are implementation choices, not Intercom’s schema. A receiving service should parse the result, reject unknown queue values, and preserve the AI proposal separately from any human-reviewed value.
{
"source_system": "intercom",
"workspace_id": "workspace_123",
"source_event_id": "evt_456",
"conversation_id": "conv_789",
"ai_run_id": "run_001",
"intent": "account_access",
"confidence": 0.91,
"suggested_queue": "account_support",
"model_version": "classifier_v1",
"human_review_status": "pending"
}Here, source_system + workspace_id + source_event_id identifies one source event. The conversation ID can recur across many events, and ai_run_id identifies one classification execution. Do not use a conversation ID or date alone as the unique key for event or AI-run records.
For a ticket-oriented destination, map only validated values to supported fields. HubSpot documents ticket-object updates and a required tickets scope in its ticket update API. That operation does not by itself implement ticket creation, association, monitoring, or AI routing.
Compare implementation patterns before you commit
The same buying decision can produce very different integration work. Use this compact design comparison to identify the operational owner and the failure mode before a pilot begins.
| Trigger and inputs | AI job | Validation and action | Fallback and owner |
|---|---|---|---|
| Intercom conversation event with event ID, conversation ID, customer data, timestamp, and message | Optional controlled intent and summary proposal | Validate identifiers and taxonomy; deduplicate by a database-enforced event key; write a normalized record or approved queue value | Integration owner handles permission, schema, and repeated-delivery failures; support operations reviews policy-sensitive cases |
| Existing Zendesk ticket with current update timestamp and proposed fields | Suggest values only if the classification passed review gates | Use Zendesk safe-update behavior; on a newer timestamp, retrieve the latest ticket and re-evaluate | Bounded retries handle transient failures; unresolved conflicts go to a reconciliation queue |
| New ticket with message text, account tier, contractual SLA, and source identifiers | Map language to an approved intent, summarize, and suggest a queue | Apply deterministic SLA and security rules first; validate JSON, taxonomy membership, and local confidence threshold | Support lead reviews low-confidence, billing, refund, account-change, contract, and security cases |
These are architecture patterns, not importable templates. Intercom webhook documentation establishes event configuration and topics. Zendesk documentation establishes ticket operations and safe updates. The normalization layer, AI fields, deduplication key, and destination workflow remain implementation decisions.
Prevent duplicate tickets and unsafe updates
Webhook deliveries can be repeated, and concurrent workers can process the same event. A search-then-create check is not enough because two workers can both find no ticket and create duplicates.
In the integration datastore, enforce a unique key such as source system plus workspace ID plus source event ID, or use a transactional upsert. If a repeated event arrives, load its existing event record and continue from its recorded state. Do not rely on a lookup immediately before creation as the only concurrency control.
For an existing Zendesk ticket, use its documented safe-update behavior: read the ticket and retain its last known update timestamp when preparing the change. If Zendesk detects a newer edit, retrieve the latest ticket and re-evaluate the proposed update rather than overwriting it. Zendesk also publishes ticket-operation rate limits, so use bounded retries, queueing, and backoff. Repeated conflicts belong in a human reconciliation queue. See the official ticket creation and update guidance and rate-limit documentation.
Set AI review gates and keep an audit trail
Treat a classification as a proposal until it has been tested against your taxonomy and the cost of an error. Preserve the original customer content, AI output, and final human-edited value separately. Store an AI run ID, model or policy version, source conversation ID, processing time, reviewer, review time, destination record ID, and write result where applicable.
Set a confidence threshold using a labeled sample from your own work. Permit automatic routing only when the result is schema-valid, uses an allowed queue, meets the locally tested threshold, and does not trigger a deterministic escalation rule. Require human approval for refunds, account changes, billing decisions, contract terms, and security-related cases. For teams defining bounded AI responsibilities, AI agent implementation is a related service area.
- The taxonomy and allowed queue values are documented and tested on representative cases.
- Low-confidence, invalid, and policy-sensitive results reach a named human queue.
- AI proposals and final human decisions are stored separately with run and model provenance.
- A human-reviewed value cannot be silently overwritten by a later AI run.
- Routing corrections, duplicate events, escalation outcomes, and write failures are measured during the pilot.
Measure outcomes at the right data grain
Track first-response time, resolution time, reopen rate, CSAT, SLA attainment, and ticket volume at the ticket or conversation grain appropriate to each measure. Define the population, reporting period, and denominator for resolution rate. Do not treat an AI execution as a conversation or count repeated runs as separate resolved cases.
- Source event: one row per received webhook or message event, uniquely keyed by source system, workspace or account, and stable source event ID.
- Conversation: one row per customer conversation, keyed by source system, workspace or account, and conversation ID.
- Destination ticket: one row per support-system ticket, keyed by destination system, account, and ticket ID.
- AI run: one row per model execution, keyed by conversation or ticket context plus a unique run ID.
- Reported summary: one row per defined reporting period, population, metric, and aggregation scope. It is not an event record.
Use a unique constraint or atomic upsert for event records. Keep raw observations separate from reporting aggregates and CRM contact or deal events. Intercom changed Fin performance metric definitions during 2026, so check the reporting period and methodology before comparing its figures across time.
Pre-purchase and pilot checklist
- Confirm that each required channel is included in the intended plan. Ask whether voice, SMS, WhatsApp, or social care is native, an add-on, or outside the help desk.
- Request an estimate using actual seats, monthly volume, AI usage, peak demand, onboarding, session or outcome assumptions, and overage rules.
- Test customer identity matching, ownership, permissions, required API scopes, webhook behavior, exports, and exception ownership.
- Run a bounded pilot with a baseline, success measures, human review, duplicate-event tests, and a rollback path.
- Name owners for duplicate handling, failed writes, conflicting edits, low-confidence classifications, and permission failures before production rollout.
Measure routing correction rate, duplicate rate, escalation rate, unresolved conflicts, write failures, and cost per resolved case alongside service measures. ConsultEvo provides CRM and workflow automation services relevant to support operations.