If the channels you use to communicate with your users are non-standard and not in the list of Deskie default channels, this functionality will help you add them.
How does it work
In standard channels, users are identified by basic data (email address, phone number, Telegram ID, etc.). This data is also used to send agents' responses.
However, when it comes to custom channels, anything can act as a user ID (your login, serial number, random character set, phone number), and we receive this data from you. When an agent writes a response, we send it to the URL specified in the settings so you can display this response where you need it.
Moreover, communication via custom channels can be carried out both by analogy with mail, and in a real-time mode, like chats.
Use cases
1) You have a mobile application your customers use to communicate directly with support.
Let's say you implemented registration through social networks in that app. In this case, you have a user ID from the social networks. Accordingly, when a user writes to support from the application, you can not create a case using API through one of the standard channels because to do that you must have an email address or phone number.
So, you create a custom channel, add such cases with an external user ID, agents send responses from Deskie, and you display them in the application.
2) There is a "Support" section in the customer's account on your service, where users can create cases, see previous cases and receive responses from agents.
In this scenario, the user's ID is his login and not the email address, which can be changed in the settings.
You want to ensure that agents' responses are sent only to the customer's account and are not duplicated as emails. Unlike the standard "Email" channel, a custom channel is perfect for this.
3) You developed your own chat with a self-learning bot, identification through phone number confirmation, and other features that solve your specific needs.
The problem is that such a chat has to be used separately from all other channels. A custom channel will allow you to connect it to Deskie so that agents can work in the same interface.
4) There is a popular forum in your industry where users often leave their questions and ask for help.
Your agents are forced to monitor the forum from time to time and help users in threads. However, you do not have a clear understanding of user data, the history of correspondence through other channels, and agents' performance statistics.
Ask the forum owners for API access to receive the messages sent to your topics and send responses from agents. The custom channel will take care of the rest.
Customization and features
1) You can add a custom channel along the path: administrator account — section "Channels" — subsection "Custom channels". When creating, there are several fields:
Webhook URL — the address all agents' responses go to.
Channel type allows you to choose how the channel works: as mail (asynchronous) or in real-time mode (synchronous).
2) When creating a channel, we add it to the rules, statistics, agent access level, and the agent account's interface. Therefore, be sure to provide the necessary agents with access to the created channel: administrator account — section "Team" — subsection "Agents" — editing agent data.
3) The API has a "Custom Channels" section for getting a list of custom channels with their parameters.
4) The API gives the ability to create cases through custom channels. The standard method is used along with the user_custom_id and channel parameters.
When creating a case through a custom channel, the response will indicate the user_id, which you need to save on your side (link it with user_custom_id) to use for other API requests later.
If other user data (name, company, etc.) is transmitted, we also record it.
When passing an email address and/or phone number, we immediately link profiles (user_custom_id + email/phone profile), provided that the email or phone number is not already associated with another user_custom_id of the same custom channel. This allows you to see the history of correspondence with this user through other channels.
5) Agents' responses sent to the Webhook URL you specified have the following structure:
We send data both when agents respond and when a message sent through the rule (sent_via_rule = 1) appears in the case.
If you've added an agent response via the API, then it will also be sent to the Webhook URL you specified. If you need to ignore such responses from agents, mind the parameter b_from_api = 1.
6) If you need to add a response on behalf of the user, use the standard method. The user_id is the ID received from us when creating the first user's case and from the webhook with the agent's response.
Before adding a response, you need to get the last chat with the user, since correspondence is always conducted only in the last chat, and check its status:
a. if the chat is in the "closed" status, you need to create a new case;
b. if it is in the "open" or "pending" status — add a message to the same chat;
c. if there is no new chat whose ID is saved on your side, it means that the agent merged it with the previous chat, and you need to add a response exactly to the previous chat (the last one at the moment).
You can get a list of chats through the list all cases method passing the user_id and show_active_chats = true parameters.