Hi,
Why is a Ticket associated channel not ready before the creator has actually written in it?
/Simon
Hi,
Why is a Ticket associated channel not ready before the creator has actually written in it?
/Simon
Could you provide an example of what you mean? I’d like to better understand the problem.
-Tyler
Sure thing and thank you for a swift reply.
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.
/Simon
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.
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