Comment by greenyoda | Hacker News Reader

Comment by greenyoda | Hacker News Reader

This article only thinks about what the caller's experience is, and doesn't consider at all what it would take to implement this on the call center side.

How would you guarantee responsiveness? With a voice call, the representative is on the line with you until your problem is resolved. With a text message, the rep would have to start helping somebody else if you took too long to reply, and may not be able to get back to you for a long time. Since they have no way of knowing how soon you'll reply, or if you'll reply at all, they can't just sit there idly waiting for your reply for a couple of minutes. And if a rep gets a large number of slow repliers queued up at once, he'd have to mentally juggle several different conversations and couldn't give any of them his full attention. Which caller gets priority? The one who you're currently texting with or the one who just came back after five minutes? What if a caller hasn't replied for a while and it's the end of the rep's shift?

Also, is there any way to route text messages through a call center so that a caller could text a single customer support number instead of having to know the number of the next available service representative?

One more thing: SMS messages get lost at a rate of 1 to 5%[1], so you're going to have a lot of irate customers wondering why they never received a reply. If a voice call drops, both sides know about it immediately.

[1] https://en.wikipedia.org/wiki/SMS#Unreliability

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).

From the call center perspective, this is no different than live chat. Many, many customer service organizations handle that. Typically, a CS rep will juggle several concurrent requests because people are slow to type.

The biggest obstacle to SMS support IMHO is authentication.

>Also, is there any way to route text messages through a call center ...

Yes; any number of providers offer inbound text messaging delivery to your webservice (or via SMPP or SMTP); routing could be relatively straight forward, subject to your other (important!) issues.

I don't think responsiveness is unsolvable, there are plenty of companies doing support via text chat with a browser, and in many cases, this is not a terrible experience.

You could also send an immediate reply to the first message with an expectation of response time to help the user know that they got the message; combined with a note next to the 'text for help' messaging to call if you don't hear back right away, this could help with the dropped SMS problems.

You still are likely to have communications issues when problems develop between your SMS provider and your user's carriers. Something were you say 'if we don't hear from you in a while, we'll give you a call to clear things up' could work here (provided sufficient staffing to place the calls in a timely fashion)

Reply on news.ycombinator.com