Connect Intercom and turn conversations into accountable support Cases

The Intercom integration connects a conversation channel with Supportbench’s Case-based support process. You choose the conversation milestone that should create a Case, the routing defaults and the requirements for creating an identifiable customer Case. Review the current creation-timing and closure limitations below before relying on the settings labels. For B2B teams, the value is a deliberate handoff from a conversation to accountable follow-up, with the customer context, ownership and service work managed in the appropriate system.

Decide where the conversation becomes Case work  ·  Current Core creation and closure behavior  ·  Prepare accounts, permissions and a test plan  ·  Connect the intended workspace  ·  Choose routing, creation and closure behavior  ·  Test the handoff from start to finish  ·  Make the B2B customer handoff explicit  ·  Worked example: chat discovers a recurring integration issue  ·  Use Help Center knowledge with verification  ·  Verify or disconnect without losing track of pending edits  ·  Troubleshoot missing Cases and unexpected routing

Decide where the conversation becomes Case work

Choose the intended milestone based on how your teams actually divide responsibility, then check the current behavior below. It is not accurately described as “every Intercom chat always creates a Case”. The contact-email requirement and connection state also matter.

Current Core creation and closure behavior

Do not select an assignment or close option based on its wording alone. Review this mapping with the integration owner and verify the intended event using an approved test conversation before depending on it. If creation at conversation start or no automatic creation fits your process, those choices avoid this label ambiguity; do not change a live process solely as a documentation workaround.

The current processor does not read the saved Close the Supportbench Case when Intercom closes setting when handling conversation updates. Existing linked conversation updates use the Case update path, which can set the Case back to Open. Keep an explicit owner for Case completion and verify actual status after events. Closing Intercom and closing Supportbench remain separate operational checks.

Prepare accounts, permissions and a test plan

1. Confirm which Supportbench account and Intercom workspace should be connected. If your organization has several workspaces, write down the intended one before authorizing.
2. Confirm you can edit the Intercom integration in Supportbench. The integration-edit permission and the applicable settings availability control changes.
3. Use an Intercom account authorized to install or authorize the integration for the intended workspace. Review the permissions shown during authorization.
4. Choose the intended Division, Priority and fallback Queue using existing supported values. Confirm the receiving team can access and monitor the resulting Cases.
5. Agree whether a contact email is required before Case creation and who will collect it during the conversation.
6. Assign responsibility for closing the Supportbench Case separately. The current saved auto-close setting is not used by the Core conversation-processing path.
7. Prepare a harmless test conversation and an approved test contact. Record the expected milestone, routing, owner and closure result before testing.

The native connection uses an authorization flow. The support operations administrator does not need to build a new Intercom app, copy an access token into a Case, or share a client secret to follow these steps. If the connection reports that installation is unavailable, ask the responsible Supportbench administrator or support team to investigate the integration setup.

Connect the intended workspace

1. Open Settings → Integrations → Intercom. Read the connection status before changing anything.
2. If disconnected, choose Connect Intercom.
3. In the Intercom authorization flow, sign in using the appropriate account and select the intended workspace when prompted. Review the requested access and authorize only the workspace your organization intends to connect.
4. Return to the Supportbench Intercom settings page. Confirm the connection status and displayed workspace name or masked identifier.
5. If the wrong workspace is shown, stop the operational rollout and correct the connection through the authorized process. Do not create test conversations in unrelated customer workspaces.
6. Continue with the routing and conversation settings below, then save and verify the complete configuration.

Intercom’s official OAuth documentation describes the provider’s authorization and workspace permissions. The Supportbench button handles the integration flow; the developer token-exchange examples are not steps that an operations user must execute. See Intercom’s official OAuth authorization reference when your administrator needs provider context.

If provider sign-in fails, check that you are using the correct workspace account and region. Do not paste credentials, callback codes or tokens into a public article or support conversation. Report the visible error and intended workspace through the approved support route.

Choose routing, creation and closure behavior

1. Review every field on the connected settings page. Confirm the Division context, available Priority and fallback Queue.
2. Select the Case-creation milestone and the contact-email requirement.
3. Review the closure limitation below and agree who will close the Supportbench Case when its work is complete.
4. Review the optional Help Center setting with the knowledge owner.
5. Use the settings toolbar to save the changes. Read the result, then reopen or refresh the form to verify the saved values.
6. Complete the test below before relying on the integration for live operational handoffs.

Test the handoff from start to finish

1. Confirm the settings have been saved and the displayed workspace is correct. Use Verify connection when available to check the saved installation.
2. Start an approved test conversation using the test contact. Compare the saved visible choice with the current-behavior table below and exercise the actual event in your approved test.
3. Find the resulting Supportbench Case using known test details. Confirm the contact identity, conversation context and intended Case rather than assuming the newest Case is the test.
4. Check the final Division, Priority, Queue and owner. If the Intercom assignee does not match an active agent, verify the fallback Queue is appropriate.
5. Add a harmless follow-up to the test conversation and verify the linked Case update. Changing the creation setting does not mean an existing linked conversation stops updating its Case.
6. Test the email-required condition with an approved test conversation lacking an email, if that condition is part of your process. Confirm it remains in Intercom without creating the expected Case until the required eligibility is met; investigate the subsequent event path rather than assuming an immediate historical replay.
7. Close the approved test conversation and inspect the linked Case without assuming it will close. The current update path can set a linked Case back to Open; confirm its status and remaining obligations.
8. Record the result and the responsible receiving team. If any step is uncertain, resolve it before treating connection verification as end-to-end success.

Make the B2B customer handoff explicit

A connected conversation can still lose momentum if no one knows who owns the next step. When a conversation becomes Case work, the receiving agent should verify the customer and account context, read the conversation, and identify what remains unresolved.

1. Confirm the customer’s business impact, affected product or asset, and any existing related Case before starting a duplicate investigation.
2. Identify the Case owner and the next action. A fallback Queue needs an actual monitoring and assignment process.
3. Check the service commitment and deadlines using the Case/SLA process. Do not infer them from the Intercom conversation’s age alone.
4. Agree which channel will carry the next customer update. Review the actual reply type, From address and recipients before sending. Do not assume every Supportbench Activity is automatically a real-time Intercom reply.
5. If another team must investigate, record the handoff and preserve a clear customer-contact owner.
6. Close the Case only when its actual obligations are complete, especially if the conversation ended earlier.

Worked example: chat discovers a recurring integration issue

A customer contacts your team in Intercom about a recurring integration failure. Your operation uses the conversation-start creation option, requires a contact email, and uses a monitored integration-support Queue as fallback. The receiving agent verifies the customer identity and examines existing account history before asking for logs already supplied in another Case.

Because engineering work may continue after the chat ends and the current auto-close setting is not consumed, the team manages Case completion explicitly. The agent records the next update and uses the Case’s escalation process when required. Once a resolution is verified, the knowledge owner improves the relevant article so future conversations have a useful answer.

The benefit comes from continuity: a short conversation becomes a tracked support obligation with context and an owner. Measure whether handoffs receive timely ownership and whether customers need to repeat information; do not assume a connection alone guarantees those outcomes.

Use Help Center knowledge with verification

The optional Help Center setting uses matching published Intercom articles for supported AI answers. Draft or unpublished provider content is not the intended source. An empty or unavailable Intercom knowledge result does not mean every other authorized knowledge source must stop working.

1. Have the knowledge owner confirm the provider articles are current and suitable for the intended questions.
2. Enable the setting only after agreeing ownership of future content changes.
3. Ask representative support questions and inspect the actual answer and referenced source. Confirm that the answer follows the current procedure rather than merely mentioning the right feature name.
4. Correct missing prerequisites, ambiguous terms or stale instructions in the source article when needed.
5. Retest after publication and keep a record of unanswered operational questions. Do not assume enabling the setting guarantees an answer for every conversation.

Verify or disconnect without losing track of pending edits

1. Before using Verify connection, reconnecting or disconnecting, save or cancel any pending settings edits deliberately.
2. For a connection check, use Verify connection and read the returned status. Investigate a failed check before assuming future conversations will be processed.
3. To remove the local connection, use Disconnect Intercom only as part of an agreed operational change. Review the confirmation and expected interruption.
4. After disconnecting, confirm the Supportbench page shows the disconnected state. The action removes the saved local connection and workspace mapping.
5. If your organization also intends to uninstall or revoke the app within Intercom, handle that separately through the provider’s authorized administration. Disconnecting here does not itself uninstall the Intercom app.
6. Notify the responsible operational owner through your normal change process and arrange how new conversations will be handled during the gap.

Troubleshoot missing Cases and unexpected routing

Continue learning

• Configure every Intercom connection setting
• Work the resulting Case with customer context
• Maintain Companies and Contacts
• Configure fallback queues and assignment
• Escalate work with a clear owner
• Keep knowledge useful through KCS