Use of side conversations with 3rd party support tools

Question

Hello all, we have a number of use-cases where we need to engage with 3rd parties for “shared customers” in a form of “ticket sharing”.Current practice is to use a side-conversation and trigger an email (which is likely a conversation part) to that 3rd party, and then responses from that 3rd party link back to the side conversation.Whilst the above sort of works, it is not the most intuitive experience as it is not obvious that there has been a response (you have to open each ticket, navigate to side conversation, see a traffic light indicating a new email).The bigger challenge is this does not consistently work (it does with Zendesk as it was levelling feature to match what they do), but does not for SPRINKLR and Service Cloud where the responses to side conversations create a whole new disconnected conversation, resulting in additional handling and bringing together of conversations.Has anyone done much work on how to connect 3rd party systems and “share tickets”? Is side conversations the right way to do this?I am playing with the idea of using back-office tickets but this does not really work either as the back-office ticket is bound to the user/company on the primary customer ticket, so you end up having to add the 3rd party as a participant which means the shared customer can see all the back and forth (removing the customer and adding the 3rd party in the back-office ticket, changes the customer ticket also).Keen to unpack if anyone else has effectively solved for “ticket sharing” via Intercom inbox.

Paul Byrne · Accepted Answer

Hi ​@Craig TitheringtonPaul here from support engneeringAt the moment, Intercom doesn’t offer a built-in “ticket sharing” feature similar to what Zendesk provides. Side conversations via email are the most supported workaround, and while they do work well in some cases (e.g., with Zendesk), responses from platforms like Sprinklr or Service Cloud often break threading. This can result in a new, disconnected conversation being created, as you’ve described.You're absolutely right that this isn’t always intuitive or reliable for consistent collaboration with external systems.Here are a few considerations:Side Conversations: Best for basic email interactions. Make sure the third-party system preserves email headers (In-Reply-To and Message-ID)if these are stripped, Intercom may not link the reply correctly.Back-office Tickets: These are primarily for internal collaboration. Since they inherit the same user/company context, they’re not suitable for keeping third-party communications separate.Custom Integration (Advanced): Some teams use middleware (e.g., via Zapier or a custom app) to ingest external replies and tag or update the original Intercom conversation manually. This takes effort but may offer more control.I agree this is an area that could benefit from more flexibility, and I’d be happy to flag this to our product team as a feature request.

seos · Answer

Great discussion! This is a common challenge when integrating third-party systems with Intercom. While side conversations can work in some cases (like Zendesk), the threading issues with Sprinklr and Service Cloud are definitely a pain point.One approach I've seen work is using a middleware solution (like Zapier or a custom-built integration) to sync ticket updates between Intercom and the third-party system. This can help maintain context without relying solely on email threading.If you're looking for a creative break after tackling these complex integration issues, check out some lighthearted andhttps://namesglow.com/over at NamesGlow – it’s a fun way to unwind! 😊Hopefully, Intercom will introduce more robust native ticket-sharing features in the future!

Join the Intercom Community 🎉

Intercom Customers and Employees

Login to the community

Intercom Customers and Employees

Scanning file for viruses.

This file cannot be downloaded