When is a channel created / visible

Hi,

Why is a Ticket associated channel not ready before the creator has actually written in it?

/Simon

@simonb,

Could you provide an example of what you mean? I’d like to better understand the problem.

-Tyler

@Tyler

Sure thing and thank you for a swift reply. :slight_smile:

  1. Server side we create Ticket with the users SendBird credentials (userid & token). This ticket as an associated channel.
  2. We automatically log in with an agents credentials to write the initial message (Hi welcome to your support channel…).
  3. We intend this ticket should show up in the users ticket list in the App and in the Desk UI for IRL agents to view. But it does not show up until the user who created the Ticket / channel actually writes a message in the channel.

We are looking for the following flow:
APP: 6 Channels / Tickets should be preset for each user where they can enter the channel and request support. When they enter the channel it is imperative that they can view their entire communication history in a peer to peer style based format. Otherwise it becomes very impersonal.

SERVER: When a user registers we create a SendBird user and the 6 Tickets.

DESK UI: Out team of experts (Agents) will handle tickets as they come in invite specific topic experts to join in solving customer issues. We will prevent our experts (Agents) from closing tickets and just idle them when a request has been resolved.
This is to prevent experts from monitoring and being part of several thousands channels (I guess 2K the limit).

I hope some of this makes any sense. :slightly_smiling_face:

/Simon

@simonb,

Let me do some testing today and see if I can figure out a workaround for you.

-Tyler

@simonb,

Couple of quick questions while I’m looking at this.
From the user’s perspective, how are you generating the list of visible tickets for them?
How are you sending the agent message?

Thanks!

@simonb I took a look and what you’re talking about and I can see that its because the ticket does not move away from the INITIALIZED state until the customer has responded. I attempted a couple of ways to force it from INITIALIZED to PENDING, but was unable to do so.

I believe part of this is that tickets are not designed to be long ongoing conversations but rather transactional incidents.

1 Like

Thank you, Tyler!

Yeah. Kinda figured that was the reason. For our customers and agents, the history-element is crazy important to have right in front though out the lifetime.

We’ll hack on… thx.

/Simon

1 Like