Intercom Certification cheat sheet

Launch Fin is a staged rollout: connect content sources, resolve Fin's answers against them, then publish to channels one at a time.

Fin answers only from content you explicitly give it; anything not in a connected source is treated as unknown, so coverage gaps surface as unanswered questions.

The launch sequence is: content sources, Fin configuration (tone, audience, escalation), test in a sandbox or test workspace, then go live on one channel.

Fin requires a minimum volume of resolved conversations to learn from; expect a ramp period before deflection metrics stabilize.

Rollout order rule: start with the highest-volume, most repetitive channel (usually chat) before adding email or messaging apps.

Deflection rate = conversations Fin resolved without handoff / total conversations Fin handled; track it separately from CSAT.

Resolution rate and deflection are not the same: a resolution can still be escalated if the customer asked for a human.

Before launch, confirm billing/plan entitlement for Fin seats and the AI features you intend to enable.

An AI-first helpdesk treats Fin as the default first responder; human teammates are the escalation path, not the first touch.

Core objects: conversations, contacts, teammates, teams, inboxes, and articles; Fin's knowledge comes from articles, snippets, and connected external sources.

Set up routing before launch: inbox assignment rules, team inboxes, and round-robin or load-balanced assignment determine where escalations land.

Workflows (rules-based automations) handle deterministic actions: tagging, assignment, SLA-style timing, and auto-responses; Fin handles open-ended answers.

Snippets are short reusable answers that Fin can use; they are ideal for policies, shipping, and pricing facts that don't warrant a full article.

Define escalation triggers explicitly (e.g., billing disputes, legal, churn risk) and encode them as Fin instructions or workflow rules.

Messenger and Help Center share the same article base; publish articles publicly to power both self-serve and Fin's answers.

Data hygiene rule: duplicate or contradictory articles degrade Fin's accuracy; consolidate before connecting a source.

Key metrics: first response time, time to close, resolution rate, deflection (Fin), CSAT, and conversation volume by channel.

Fin's performance is measured on resolution/deflection rate and the share of conversations escalated; review unanswered questions weekly.

Workload balancing uses inbox assignment rules plus teammate availability; monitor backlog by inbox rather than in aggregate.

Quality review samples closed conversations against a rubric; Fin conversations should be sampled on the same cadence as human ones.

Staffing rule: forecast volume by channel and day-of-week, then map to coverage; Fin deflection reduces but does not eliminate peak load.

Reporting views include conversation trends, teammate performance, and Fin analytics; export or schedule reports for stakeholder reviews.

Escalation design is a manager decision: which topics Fin must always hand off, and to which team inbox.

Change management: publish article updates before policy changes go live so Fin answers reflect the new policy immediately.

Agents work from the Inbox; each conversation shows the contact, channel, and any Fin-handled context in the conversation history.

When Fin escalates, the handoff includes the conversation transcript; read it before replying so you don't repeat questions.

Use saved replies and snippets for repetitive responses; use notes (internal) versus replies (customer-visible) correctly.

Tag conversations consistently; tags feed reporting and Fin's understanding of topic categories.

Close or snooze conversations deliberately: snooze sets a reopen time, close ends the conversation and triggers CSAT where enabled.

Escalate to another team by reassigning the conversation to the correct team inbox rather than messaging a teammate directly.

If Fin gave a wrong answer, flag the underlying article or snippet; the fix is content, not retraining the model.

Personal tone settings and signatures apply per teammate; verify your signature and availability status before a shift.

Optimization loop: review Fin's unanswered and low-confidence questions, add or fix content, then re-test the same question.

Content quality beats content volume: short, single-topic, clearly titled articles resolve better than long multi-topic pages.

Fin's answer quality depends on the source: contradictory articles cause inconsistent answers, so resolve conflicts first.

Use Fin's reporting on resolution rate, deflection, and escalation reasons to prioritize which content gaps to close.

Add explicit instructions for tone, scope, and refusal behavior; Fin should decline out-of-scope topics and hand off.

Test changes against a set of real customer questions before publishing; keep a regression list of previously failing questions.

Snippets are the fastest fix for a single recurring question; promote to a full article once it recurs at volume.

Measure before and after each content change; without a baseline you cannot attribute deflection changes to the edit.

Email differs from chat: asynchronous, longer messages, multiple questions per message, and no immediate clarification.

Fin on email must handle multi-question threads; configure it to answer what it can and escalate the remainder.

Threading matters: replies must stay in the same conversation thread so context and history are preserved.

Email requires stricter scope rules because a wrong answer is sent as a formal written response; tighten handoff triggers.

Set expectations in the auto-reply: state that Fin is an AI assistant and how to reach a human.

Deliverability and sender configuration (domain authentication, reply-to address) must be set before enabling Fin on email.

Volume per conversation is higher on email; monitor time-to-first-response separately from chat metrics.

Test with real email threads, including forwarded messages and attachments, before going live.

A Fin Procedure is a defined, multi-step task Fin follows, distinct from a single-article answer.

Procedure anatomy: trigger/scope (when it applies), required inputs, ordered steps, decision branches, and a defined handoff or completion outcome.

Procedures should reference specific content sources for each step rather than relying on general knowledge.

Branching rule: every decision point needs an explicit fallback to a human when the condition is not met.

Keep procedures narrow: one procedure per task (e.g., refund eligibility check) rather than one large procedure for all billing topics.

Test procedures with both happy-path and edge-case inputs; record expected outputs for each case.

Procedures that collect data must specify exactly which fields to capture and where to store them (contact attributes or notes).

Version and review procedures when underlying policy changes; a stale procedure produces confidently wrong answers.

Sales use of Fin centers on qualification and routing: capture intent, company size, and use case before handing to a rep.

Fin can answer pre-sales questions from product and pricing content, but pricing exceptions and custom quotes must route to a human.

Lead qualification rule: define qualifying fields up front and have Fin collect them conversationally rather than via long forms.

Routing: qualified leads go to the correct sales inbox or owner; unqualified or support-type requests route to support.

Fin should never commit to discounts, contract terms, or delivery dates; those are explicit handoff triggers.

Track sales metrics separately: qualified conversations, meeting requests, and handoff-to-rep rate, not support deflection.

Content for sales Fin includes pricing pages, feature comparisons, security/compliance docs, and integration lists.

Boundary rule: keep support and sales knowledge sources separated so Fin does not answer contract questions with help-center content.

Launch Fin is a staged rollout: connect content sources, resolve Fin's answers against them, then publish to channels one at a time.

Fin answers only from content you explicitly give it; anything not in a connected source is treated as unknown, so coverage gaps surface as unanswered questions.

The launch sequence is: content sources, Fin configuration (tone, audience, escalation), test in a sandbox or test workspace, then go live on one channel.

Fin requires a minimum volume of resolved conversations to learn from; expect a ramp period before deflection metrics stabilize.

Rollout order rule: start with the highest-volume, most repetitive channel (usually chat) before adding email or messaging apps.

Deflection rate = conversations Fin resolved without handoff / total conversations Fin handled; track it separately from CSAT.

Resolution rate and deflection are not the same: a resolution can still be escalated if the customer asked for a human.

Before launch, confirm billing/plan entitlement for Fin seats and the AI features you intend to enable.

An AI-first helpdesk treats Fin as the default first responder; human teammates are the escalation path, not the first touch.

Core objects: conversations, contacts, teammates, teams, inboxes, and articles; Fin's knowledge comes from articles, snippets, and connected external sources.

Set up routing before launch: inbox assignment rules, team inboxes, and round-robin or load-balanced assignment determine where escalations land.

Workflows (rules-based automations) handle deterministic actions: tagging, assignment, SLA-style timing, and auto-responses; Fin handles open-ended answers.

Snippets are short reusable answers that Fin can use; they are ideal for policies, shipping, and pricing facts that don't warrant a full article.

Define escalation triggers explicitly (e.g., billing disputes, legal, churn risk) and encode them as Fin instructions or workflow rules.

Messenger and Help Center share the same article base; publish articles publicly to power both self-serve and Fin's answers.

Data hygiene rule: duplicate or contradictory articles degrade Fin's accuracy; consolidate before connecting a source.

Key metrics: first response time, time to close, resolution rate, deflection (Fin), CSAT, and conversation volume by channel.

Fin's performance is measured on resolution/deflection rate and the share of conversations escalated; review unanswered questions weekly.

Workload balancing uses inbox assignment rules plus teammate availability; monitor backlog by inbox rather than in aggregate.

Quality review samples closed conversations against a rubric; Fin conversations should be sampled on the same cadence as human ones.

Staffing rule: forecast volume by channel and day-of-week, then map to coverage; Fin deflection reduces but does not eliminate peak load.

Reporting views include conversation trends, teammate performance, and Fin analytics; export or schedule reports for stakeholder reviews.

Escalation design is a manager decision: which topics Fin must always hand off, and to which team inbox.

Change management: publish article updates before policy changes go live so Fin answers reflect the new policy immediately.

Agents work from the Inbox; each conversation shows the contact, channel, and any Fin-handled context in the conversation history.

When Fin escalates, the handoff includes the conversation transcript; read it before replying so you don't repeat questions.

Use saved replies and snippets for repetitive responses; use notes (internal) versus replies (customer-visible) correctly.

Tag conversations consistently; tags feed reporting and Fin's understanding of topic categories.

Close or snooze conversations deliberately: snooze sets a reopen time, close ends the conversation and triggers CSAT where enabled.

Escalate to another team by reassigning the conversation to the correct team inbox rather than messaging a teammate directly.

If Fin gave a wrong answer, flag the underlying article or snippet; the fix is content, not retraining the model.

Personal tone settings and signatures apply per teammate; verify your signature and availability status before a shift.

Optimization loop: review Fin's unanswered and low-confidence questions, add or fix content, then re-test the same question.

Content quality beats content volume: short, single-topic, clearly titled articles resolve better than long multi-topic pages.

Fin's answer quality depends on the source: contradictory articles cause inconsistent answers, so resolve conflicts first.

Use Fin's reporting on resolution rate, deflection, and escalation reasons to prioritize which content gaps to close.

Add explicit instructions for tone, scope, and refusal behavior; Fin should decline out-of-scope topics and hand off.

Test changes against a set of real customer questions before publishing; keep a regression list of previously failing questions.

Snippets are the fastest fix for a single recurring question; promote to a full article once it recurs at volume.

Measure before and after each content change; without a baseline you cannot attribute deflection changes to the edit.

Email differs from chat: asynchronous, longer messages, multiple questions per message, and no immediate clarification.

Fin on email must handle multi-question threads; configure it to answer what it can and escalate the remainder.

Threading matters: replies must stay in the same conversation thread so context and history are preserved.

Email requires stricter scope rules because a wrong answer is sent as a formal written response; tighten handoff triggers.

Set expectations in the auto-reply: state that Fin is an AI assistant and how to reach a human.

Deliverability and sender configuration (domain authentication, reply-to address) must be set before enabling Fin on email.

Volume per conversation is higher on email; monitor time-to-first-response separately from chat metrics.

Test with real email threads, including forwarded messages and attachments, before going live.

A Fin Procedure is a defined, multi-step task Fin follows, distinct from a single-article answer.

Procedure anatomy: trigger/scope (when it applies), required inputs, ordered steps, decision branches, and a defined handoff or completion outcome.

Procedures should reference specific content sources for each step rather than relying on general knowledge.

Branching rule: every decision point needs an explicit fallback to a human when the condition is not met.

Keep procedures narrow: one procedure per task (e.g., refund eligibility check) rather than one large procedure for all billing topics.

Test procedures with both happy-path and edge-case inputs; record expected outputs for each case.

Procedures that collect data must specify exactly which fields to capture and where to store them (contact attributes or notes).

Version and review procedures when underlying policy changes; a stale procedure produces confidently wrong answers.

Sales use of Fin centers on qualification and routing: capture intent, company size, and use case before handing to a rep.

Fin can answer pre-sales questions from product and pricing content, but pricing exceptions and custom quotes must route to a human.

Lead qualification rule: define qualifying fields up front and have Fin collect them conversationally rather than via long forms.

Routing: qualified leads go to the correct sales inbox or owner; unqualified or support-type requests route to support.

Fin should never commit to discounts, contract terms, or delivery dates; those are explicit handoff triggers.

Track sales metrics separately: qualified conversations, meeting requests, and handoff-to-rep rate, not support deflection.

Content for sales Fin includes pricing pages, feature comparisons, security/compliance docs, and integration lists.

Boundary rule: keep support and sales knowledge sources separated so Fin does not answer contract questions with help-center content.