There are some interesting hurdles, and you've done a great job of thinking of a few of them! I can see three likely async solutions: SMS style message based (explicitly not real time), real-time message based, or real-time chat.
SMS Style Messaging: In my customer-facing experience with the concept I don't think SMS is suited to the challenge. Instead a full fledged chat application would need to be used. As far as queuing goes, related to this and my experience with Simple most of my interactions a) aren't real-time and that expectation is set when I create a message, and b) if they go on for a period of time they're handled by different CSRs. I've never had a poor experience because of that.
> With a voice call, the representative is on the line with you until your problem is resolved.
Additionally, related to this, there are a lot of times where that's not the case, or there's research to be done and if I were allowed I could do that research and come back with a response. That's discouraged/forbidden in call centers because there's the assumption you won't perform without pressure but that's almost certainly a staffing issue (or if there are too many basic/uninteresting research requests then it may be a systemic problem).
Real-Time Messaging: If we're looking for a more real-time message based solution (i.e. not chat), a single CSR could handle a few requests, but if they get a particularly detailed one there could be an expiration that hands it off to another rep, but that could get messy fast, even with a "So-and-So is busy at the moment, my name is..." (though with more elegant verbage).
Real-Time Chat: As I do everything in my power to avoid calling people, I will use chat if available as an alternative. Now, I can't say I've asked every person I've spoken to, but I know a couple of cases where I can confirm I was their sole interaction. It took a bit longer, but I was doing other stuff while I waited and I had the expectation when I started the interaction.
tl;dr Set expectations of delayed responses to messaging based support, don't bother with real-time messaging as it doesn't make logistic sense, and treat all real-time support the same (one active interaction).
SMS Style Messaging: In my customer-facing experience with the concept I don't think SMS is suited to the challenge. Instead a full fledged chat application would need to be used. As far as queuing goes, related to this and my experience with Simple most of my interactions a) aren't real-time and that expectation is set when I create a message, and b) if they go on for a period of time they're handled by different CSRs. I've never had a poor experience because of that.
> With a voice call, the representative is on the line with you until your problem is resolved.
Additionally, related to this, there are a lot of times where that's not the case, or there's research to be done and if I were allowed I could do that research and come back with a response. That's discouraged/forbidden in call centers because there's the assumption you won't perform without pressure but that's almost certainly a staffing issue (or if there are too many basic/uninteresting research requests then it may be a systemic problem).
Real-Time Messaging: If we're looking for a more real-time message based solution (i.e. not chat), a single CSR could handle a few requests, but if they get a particularly detailed one there could be an expiration that hands it off to another rep, but that could get messy fast, even with a "So-and-So is busy at the moment, my name is..." (though with more elegant verbage).
Real-Time Chat: As I do everything in my power to avoid calling people, I will use chat if available as an alternative. Now, I can't say I've asked every person I've spoken to, but I know a couple of cases where I can confirm I was their sole interaction. It took a bit longer, but I was doing other stuff while I waited and I had the expectation when I started the interaction.
tl;dr Set expectations of delayed responses to messaging based support, don't bother with real-time messaging as it doesn't make logistic sense, and treat all real-time support the same (one active interaction).