From travel bookings and airlines to on-demand services, customer service is an essential part of every business. Zendesk is a comprehensive customer service solution that meets the needs of customers as well as the businesses that serve them. Chat is a useful way to have efficient customer service conversations and, if built well, can ensure a positive experience for both the customer and the agent. That’s why, in this guide, we’ll create a globally available chat within the Zendesk ecosystem by leveraging Sendbird Chat.
First, we’ll introduce the three components that are important for chat support. Then, we’ll discuss the basics of ticket routing and ticket assignment, before moving on to the system flows for creating and updating Zendesk tickets. The full Zendesk integration project described here leverages three visible Zendesk objects and one hidden object, which we’ll talk about below!
Let’s get started! 💻
The background is an invisible object and nothing is displayed in the UI. It is used to trigger initialization of the top bar object. The background object automatically opens and closes the top bar each time the Zendesk agent logs in so as to establish a Sendbird connection. The connection to Sendbird collects the latest data for the agent, including unread message counts and current chat data.
The top bar makes Sendbird chat globally available in Zendesk. The top bar icon opens a popover chat modal.
The functionality of the top bar includes the ability to display a list of the current agent’s Sendbird channels, which correspond to Zendesk tickets the agent is assigned. The agent can see a messaging UI, and unread message badges. The top bar icon can also change color to indicate there are new or unread messages. Note that unread message counts are updated in real time while connected to Sendbird.
The ticket sidebar appears only when a Zendesk ticket is open. The sidebar securely connects to Sendbird via the Zendesk REST API call out service and collects the latest data about the Sendbird group channel associated with the open Zendesk Ticket.
The Zendesk integration is based on one ticket being associated with one Sendbird channel.
Zendesk triggers and webhooks are used for creating Sendbird channels, adding customers and agents into Sendbird channels, and moving agents in and out of channels.
Now that we’ve covered the basics, let’s talk about ticket routing and assignment.
Zendesk’s automated skills based ticket routing does not provide an API to assign a ticket to a particular agent. Instead, the automated ticket routing assigns a new ticket to groups. For example, a new ticket can show up in the “New tickets” menu item, among other categories.
In the context of ticket routing, this implementation listens for when an agent is assigned to a ticket in one of two ways. First, an agent can change themselves to be the owner in the UI, and then save the ticket. Alternatively, a supervisor or agent can assign the ticket to a different agent in the UI, and then save the ticket. Therefore, the project’s ticket sidebar and background objects listen for that save event and change who is a member in the ticket’s corresponding Sendbird Channel.
So what would the ticket creation flow look like? The diagram below represents one possible system flow. An explanation follows the diagram.
First, a user creates a new Zendesk ticket using their own web server (an example server is provided later in this guide). A Zendesk trigger and a Zendesk webhook are fired. Then your server accepts the webhook, which contains user details and the ticket ID. Next, your server creates a Sendbird channel using the ticket ID and adds a requesting user to the channel. The end user automatically becomes aware of the newly created channel via websocket and/or a callback from your server.
Now that we know how tickets are created, let’s talk about how tickets are updated. The diagram below represents one possible system flow. Please scroll for an explanation.
After a Zendesk agent/supervisor changes the owner of a Zendesk ticket, a Zendesk trigger and a Zendesk webhook are fired. Then your server accepts the webhook which contains agent and user details, as well as the ticket ID. Next, your server fetches the ticket’s corresponding Sendbird channel which includes its current members. Finally, your server updates the channel membership according to the newly assigned agent.
The diagram below represents one possible logic based on ownership change and what is provided in the Zendesk webhook’s body:
Keep an eye out for our upcoming guide, which has other details you may find useful!
Now let’s move on to the flow of the agent top bar. The top bar has a clickable icon that opens a modal. The top bar modal, open or closed, contains a Sendbird instance. The Sendbird instance maintains a WebSocket connection to Sendbird. The WebSocket connection listens for real time events. The Sendbird instance uses Sendbird’s built in connectionManager (see the connectionManager code for iOS and Android) to maintain a connection between Sendbird and the Zendesk user interface.
The diagram below summarizes the top bar flow.
Lastly, it is up to the implementation what to display in the Zendesk ticket sidebar. In this project, the sidebar’s primary functions are to fetch and display details of a ticket’s associated channel, including channel membership and message history. The sidebar in this project uses Zendesk’s secure call out functionality for secure Platform API calls to Sendbird.
The below diagram shows the associated flow.
And that’s it for the Zendesk integration! You now know the system flows of creating a background module, top bar, and ticket sidebar with Sendbird and Zendesk. Keep an eye out for our upcoming guide in which we’ll show you more code samples!
Stay up-to-date on the latest technical content from Sendbird.