When AI replies directly to a customer, the team needs to decide which information it can use, which actions it can take, and how a person picks up the conversation. Intercom’s Fin documentation makes those decisions visible enough to examine.
Sources checked September 19, 2026. This is a review of public product documentation, not a tested customer deployment or a recommendation to buy Fin. The scope is customer-facing Fin AI Agent. Intercom’s Copilot assists support teammates in the Inbox; it is a different workflow. Intercom explains the distinction in its FAQ.
The workflow at a glance
| Layer | Documented capability | Decision for the deploying team |
|---|---|---|
| Knowledge | Choose sources available to Fin | Which content is appropriate for customer answers? |
| Connected systems | Configure data connectors and how they run | Which records and actions may this workflow reach? |
| Human handoff | Combine escalation guidance, rules, and routing | Who receives the case, with what context? |
| Evaluation | Batch-test questions and inspect responses | What evidence meets your acceptance criteria? |
| Operations | Track outcomes and manage deployment paths | How will you review failures and stop the workflow? |
These are documented capabilities. Their presence does not establish that a particular customer’s configuration works correctly.
Source selection is a publishing decision
Intercom lets teams manage sources separately for Fin, Copilot, and the Help Center. Fin can answer from content that is not itself publicly visible, including internal articles and snippets. A document being absent from the public Help Center does not mean its contents are unavailable to customer-facing AI. Read the knowledge-source documentation.
Our take: have a content owner approve the material used for customer answers. Test a question that should use an internal source and one that should never disclose internal information. Record the expected boundary before testing.
A connector introduces another responsibility
Data connectors can fetch information from external systems. Their setup includes inputs, response configuration, connection testing, and a choice between automatic triggering by Fin and explicit invocation. Intercom’s connector setup guide documents those choices.
Our take: a working connection is only the start. Test whether the backend enforces the correct customer identity and permitted operation. Keep retrieving an order’s status separate from changing that order. For actions, establish approval requirements, retry behavior, and recovery before enabling the path.
Handoff needs somewhere to go
Fin combines default behavior with escalation guidance, rules, and workflows. Intercom says that without a configured human routing target, Fin does not offer human escalation and instead ends with a “get more help” outcome. Read the escalation guidance.
Our take: test the entire handoff. A customer asking for a person should reach the intended queue with enough context for that person to help. Also test what the customer experiences when the receiving team is unavailable. A message promising help is not evidence that someone received the case.
Review conversations behind the dashboard
Intercom’s batch-testing tools accept questions from previous conversations, CSV files, or manual input. Reviewers can rate responses, inspect contributing sources or guidance, and export results. Read the batch-testing guide.
Its outcome definition includes both customer-confirmed resolution and assumed resolution when a customer leaves after an answer without requesting more assistance. Intercom also describes reversing a resolution when the customer returns to the same conversation for more help. Read the outcome definitions.
Our take: pair the product metric with reviewed answer quality, repeat contacts, and work transferred to human agents. Keep the definition and denominator with every reported rate. An assumed resolution alone cannot establish that the answer was correct.
Rehearse the stop procedure
Intercom warns that pausing the primary deployment toggle may leave other active paths. Its shutdown instructions also cover workflows and profiles, followed by a new-conversation test. See the disable instructions.
Our take: name the person who can stop the pilot and verify each deployed path. Preserve the manual support route so stopping AI does not leave customers without help.
Turn this into your pilot review
Start with one support category and approved knowledge. Record answer quality, wrong-account requests, missing information, handoff, and shutdown tests in the pilot evaluation worksheet. These are proposed checks, not results we have observed.
If your team wants a person to review every reply before sending, use the support-drafting workflow instead of assuming direct customer replies are the right starting point.
This review does not establish customer ROI, model-routing internals, retention terms, or tenant-isolation guarantees. Resolve those questions against current product terms, your configuration, and test evidence before committing.
Research assisted by AI and reviewed against the linked first-party documentation. Product behavior and terms can change. Send a correction.