Wholeheartedly agree here, but it requires your support staff to have strong reading comprehension and writing skills - something I've not seen in various "live chat" support options that I've used.
That's a staffing issue. If reading and writing is an issue, then I seriously doubt the phone support experience will be of any quality, so there's really nothing lost.
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.
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)
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).
Needy customers. That's the problem. Some of your customers literally just want to chat. They want to feel close to your brand and give feedback directly to the CEO. It's problematic. Easier to keep them at arm's length with email.
Off topic: I thought the post would be a plea for tty support replacements since no one TTYs but everyone TXTs or IMs or emails.
My experiences: I don't know if others will chime in with their experiences, but Rogers in Canada has textual/live chat support channels in place and you can even contact a manager by chat. For background, Rogers is Comcast plus Verizon for Canada. Yeah. But I'm actually quite pleased by the chat service. As a customer I could copy and paste what I would otherwise repeat laboriously from agent to agent. The only weakness was that not everyone I needed to speak with had signed up for the chat service. Many departments then required me to call in, reference the chat, then get transferred. It would be nice to integrate the touch points between chat and call. Better still? Assume that I'm in the middle of an existing issue at the start by asking for a previous ticket number or having the right people call me back in a timely manner. Apple has done a few of these things but could use improvements, specifically in the disconnect between store and phone services or online. Microsoft... is still working on their Store processes, they've quite a few kinks as it took weeks of hour-long calls to finally place and receive an order -- and they asked me to call to place it from an email they sent me. Yeah, not calling or having others call me? Way better than calling and wasting both my and your time, service providers. If we both know time is limited, working asynchronously with the ability for escalations and status notifications is just what we need.
From a customer point of view, I'll go for the phone call if phone is available on the website. Why ? Because it's much faster.
A simple example is to change a flight, I could do it by email but then if I call I have the immediate confirmation that my flight has been changed, that I have a correct seat and a confirmation by email (yeah I know those kind of stuff should be doable directly from the airlines website but Singapore Airlines and Malaysia Airlines do not offer that for some of my flights). Of course those call center are in Asia, so staffing is not an issue.. Western company take so much time to deal with. Air France took 2-3 days to change a detail on a flight. Valve took 5 days to tell me that cross country checkout is disabled. It would have taken only 5 minutes on the phone.
Text of any form is not good for support because it amplifies the back-and-forth duration required to actually determine the issue and walk them through the resolution. The key here is bi-directional conversation - that is, you can talk to them and they can talk to you at the same time.
Think of someone helping Grandpa with using his email. On the phone, most of the time is spent in back-and-forth, explaining a concept multiple ways until he understands the request. The information he gives back may be vague and incomplete, so you can discuss it with him to get instant further clarification and context. You can then walk him through the solution in a bi-directional conversation, whereby you say a step and then he asks for clarification about certain aspects, before you proceed to the next step.
Now consider email/text/etc. Focus even on the solution stage. You send 5 steps to perform to complete the task. He gets stuck on step 2, and so responds. He doesn't know if he'll get stuck on steps 3, 4 and 5 either because he can't get past step 2. That's potentially 8 emails back and forth to get the problem resolved.
By not having instantaneous bi-directional communication, it is a hell of a lot harder to debug and walk someone through the solution particularly if they're not technically adept. For us on HN it may be fine - we can stumble our way through blanks relatively easily - but for Grandpa, he has no hope of doing that and so phone support is by far the most time-efficient method.
I can see there being a happy medium here as no all support requests are task oriented. Either a) asynchronous support for support inquiries like "When will product x be in stock?" or "What does policy y mean to me?" where as "How do I setup email on my phone?" could be handle synchronously. or b) begin asynchronously and move to synchronous communication as needed.
At the very least both options should be offered. I almost exclusively use text-based communication unless it's a time-restricted request. This works well for Simple (the bank) where I tend to have a lot of financial questions that I don't need answered -right now- so I shoot off a quick message and follow up if needed; however I've had a couple of situations that required immediate answers and response and those times I absolutely picked up the phone.
Having worked in tech support for two major telecomm companies though, I'm convinced it's most commonly a problem of formatting. The discrepancy between instruction and reality is what throws non-technical people off. Given accurate instructions your grandpa could figure it out at least 75% of the time. One of the companies placed extreme emphasis on their resources with the reasoning "They'll figure it out." and according to them and their metrics they seemed to think most people did figure it out by braille if you will.
I think the problem with offering both options is that you can't count on your customers to choose the right one, and they'll blame you when they choose the wrong one.
Customer (via SMS): hey, the whole internet on my phone crashes when i use feature x. wtf???
Customer Support Rep A: Hey, we'd be happy to help you with that. What platform/version/subscription do you have?
Customer (7.5 hours later): its the latest version, and i have a verizon. why can't you guys fix this???
CSR B: [lists some possible troubleshooting steps, asks customer to call]
Customer, the next day on Twitter and Facebook: [Company] has the worst support! They broke my phone, and they say they'll help you by text, but then when you ask them anything they just ignore your problem or tell you to call anyway. FUCK [COMPANY] AND DON'T BUY THEIR CRAP!!!
That's absolutely valid, CR exists because customers don't know what to do next. That said, there's a lot that could be done to mitigate that.
- High phone support visibility on how-to pages: Don't link to chat if it's not going to an ideal experience
- Focus on customer facing how-to resources: I'm confident every minute spent making the thorny aspects of phones (e.g. moving photos from internal storage) rock-solid is worth no less than an hour of CSR time.
- Proactively making recommendations on more ideal support scenarios if applicable: "Hey, before we get started, this part can be tricky and I'd love to walk you through it, it'll only take a few minutes and I can schedule a time to call you if you're busy right now. <details of next steps>."
- Perhaps most importantly (I just noticed from your interaction) CSR A should handle (and be given the freedom to handle) the problem from start to finish OR it should be made -very- easy for CSR B to pick up where it was left off (either a great CRM or an honest "I've got a family to go home to, I'm going to hand you off to So-and-So or I'll be back and available at"). That said, Simple lacks consistent CSR interaction but I haven't encountered a problem with the hand-off, most of the time I never notice.
When I was a CSR 99% of the time the customer wasn't my enemy, it was my coworkers (or my CRM).
That said, I don't believe SMS literally is a reasonable form of support and should never be marketed that way, but chat, even in-app chat could substitute. Additionally, providing these methods gives people a chance to ask questions and get resolutions that may be nagging them but not enough to call someone, it also opens up lines of communication to people like myself who get anxious thinking about calling people.
This rings very true to me. It makes me wonder why most commercially supported software sold to end users doesn't have remotely activated remote administration built in, scary though that may sound.
The key difference between phone and email support is the expectations of the customer, not the underlying technology. When I send an email to support, I don't expect an answer for at least a few hours. When I call, I expect to get my issue resolved before hanging up. I may wait on hold for 30m, but I am going to resolve the problem before I get off the phone.
I don't believe this is due to technological limitations of email. I have had conversations via email that are essentially realtime chats. I think the real issue is that passive support simply gets a lot more support requests than non-passive support. Offering SMS sadly wouldn't resolve this, it would just be another support medium that gets flooded like email.
NOTE - By passive support I mean anything where you send a message and just wait for a response. Non-passive support would be something like a phone call where you wait on hold for someone to be available.
SMS is terrible for this. It is completely insecure. You can fake transmissions easily, and nothing is encrypted, so you can't discuss any private info. There are very good, and obvious, reasons why organization do not use SMS for support.
While it's great to have a simple text-based medium to do this, SMS is awful.
I agree with the sentiment, but it's hard to take this guy serious when he suggests something so obviously bad.
So, how about using WhatsApp or WeChat or Line? These apps are as convenient and cheap as SMS for many people, but don't suffer from the same ease of spoofing.
Transmitting personally identifiable information, including credit card data and supporting documentation as suggested in the article, through email, text or an app sounds like an extremely dangerous minefield.
I'm not sure how this is necessarily much different than phone communication with the notable caveat that text is quicker to parse. It's already inadvisable to give that information over the phone as a landline can be tapped and there's plenty of proof of concepts of tapping wireless networks.
At least with an app you have the option of adding in security layers. SSL for one, Simple uses a PIN on their app, Art.com will process a transaction in chat but direct you to their website to submit payment information, and on top of all this you have the added benefit of easily documented interaction. -You- can reference your own interaction without the near impossibility of having a call recording audited (as a call center CSR and supervisor I've seen this happen no more than six times).
In fact, in one interaction with Art.com I sent an email to an agent with photos of some damage to the piece they shipped me in my initial email which resulted in a resolution in the response.
Another case with GIGABYTE I was able to send photographic description of my issue due to a consistent (likely language barrier related) misunderstanding about what was meant by "a missing pin." which immediately clarified the conversation and we were able to move forward.
tl;dr the variety of "offline" security measures available and the convenience gained with "offline" support makes that minefield significantly less dangerous in my experience, especially considering the dangers already present in phone based support.
Companies do this even if they don't publicize it. You say you're deaf, and then they don't have any choice.
After failing to get through on their various numbers, I cancelled my eFax account via e-mail this way (as they don't/didn't allow online cancellations) and it went smoothly.
If a company has limited resources for providing text based support to the disabled, I'm not sure it's really cool to tie that up by claiming your disabled when you aren't.
To close an account, I have done this a few times.
Especially when every other type of account activity is on-line, my feeling is they just want to make it difficult for you, or hit you with a sales pitch.
It's also not "cool" for a company the size of eFax to not put a simple cancel mechanism on their site and then not answer any of their phone numbers when you want to cancel.
So simple e-mail vs do a credit card chargeback. As a merchant, I know which I'd prefer. If they have capacity issues with support, that's their issue to resolve as a business. If you can't adequately support your customers equally and you can't work out how to fix that, you deserve to go out of business.
Of course, hogging a teletype operator specifically for the disabled to tackle some minor support issue probably isn't the most positive thing to do, but sending an e-mail.. anyone can do that and if it takes a white lie to get past an internal policy, so be it.
>It's also not "cool" for a company the size of eFax to not put a simple cancel mechanism on their site and then not answer any of their phone numbers when you want to cancel.
Right, but it's not eFax you're hurting by tying up their accessibility resources.
Thanks, good thoughts here. I work for a crazy-fast growing tech company that supports its users by email and text only. Yet we still receive multiple requests on a daily basis from our strongest users to speak on the phone.
I believe there is a perceived notion in the general public that speaking is the fastest way to resolve an issue. This probably comes from the fact that we can speak our thoughts faster than almost any other method of communication. Verbally talking with someone is also the most primal way of resolving issues. Finally, 7% of any message is conveyed through words,
38% through vocal elements (how those words are spoken),
and 55% through nonverbal elements (facial expressions, gestures, posture, etc) (from a blog I wrote - http://blog.blainelight.com/2012/09/NonVerbalCommunication.h... most people want to have their frustrations 'heard' when reach out to support, and text only convey's 7% of their whole message.
In a tech-centric world, it's easy for us to want to embrace the future. We have to realize that even the early majority is still dependent on voice communications to express their primal need for help (i.e. asking for support from a company).
As a company, maybe I want to inconvenience the customer a little bit. Making them pick up the phone seems like a barrier to support requests and may therefore cut down on the number I have to deal with, reducing costs.
I've found most companies worth using do provide email/ticket support, with the main ones that don't being ones in very old/stagnant industries.
The article talks about apps though, and honestly, I'd rather sit through a hour on hold on the phone than install some bloatware app. Forget 'apps', email is perfect for support.
The problem that needs to be solved is support availability through telephone and email channels. There's no reason for companies to force their customers to sit on hold and there's no reason to drive them through complicated voice menu trees. Similarly, with email based interactions, multiple responses means that the agent is probably not handling the interaction well and could be asking better, more probing questions to get to the heart of the matter more quickly.
(I write this as the head of a large customer service operation for a US-based mobile phone provider - if a phone company can answer the phone without putting their customers through voice menu hell, anyone can do it.)
I do not care about support via Text. Web-based chat on the other hand is awesome and I use it everywhere it is available. I often need support during working hours and using web chat means I do not have to yak over the phone about my problems and disturb co-workers around me. Oftentimes I need to type something into the computer and it is much more convenient to Alt-Tab between things and copy paste something instead of typing by one hand (yes, I know head set would solve the problem).
34 comments
[ 4.7 ms ] story [ 75.8 ms ] threadHow 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
The biggest obstacle to SMS support IMHO is authentication.
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)
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).
My experiences: I don't know if others will chime in with their experiences, but Rogers in Canada has textual/live chat support channels in place and you can even contact a manager by chat. For background, Rogers is Comcast plus Verizon for Canada. Yeah. But I'm actually quite pleased by the chat service. As a customer I could copy and paste what I would otherwise repeat laboriously from agent to agent. The only weakness was that not everyone I needed to speak with had signed up for the chat service. Many departments then required me to call in, reference the chat, then get transferred. It would be nice to integrate the touch points between chat and call. Better still? Assume that I'm in the middle of an existing issue at the start by asking for a previous ticket number or having the right people call me back in a timely manner. Apple has done a few of these things but could use improvements, specifically in the disconnect between store and phone services or online. Microsoft... is still working on their Store processes, they've quite a few kinks as it took weeks of hour-long calls to finally place and receive an order -- and they asked me to call to place it from an email they sent me. Yeah, not calling or having others call me? Way better than calling and wasting both my and your time, service providers. If we both know time is limited, working asynchronously with the ability for escalations and status notifications is just what we need.
And let's not talk about banks...
Think of someone helping Grandpa with using his email. On the phone, most of the time is spent in back-and-forth, explaining a concept multiple ways until he understands the request. The information he gives back may be vague and incomplete, so you can discuss it with him to get instant further clarification and context. You can then walk him through the solution in a bi-directional conversation, whereby you say a step and then he asks for clarification about certain aspects, before you proceed to the next step.
Now consider email/text/etc. Focus even on the solution stage. You send 5 steps to perform to complete the task. He gets stuck on step 2, and so responds. He doesn't know if he'll get stuck on steps 3, 4 and 5 either because he can't get past step 2. That's potentially 8 emails back and forth to get the problem resolved.
By not having instantaneous bi-directional communication, it is a hell of a lot harder to debug and walk someone through the solution particularly if they're not technically adept. For us on HN it may be fine - we can stumble our way through blanks relatively easily - but for Grandpa, he has no hope of doing that and so phone support is by far the most time-efficient method.
At the very least both options should be offered. I almost exclusively use text-based communication unless it's a time-restricted request. This works well for Simple (the bank) where I tend to have a lot of financial questions that I don't need answered -right now- so I shoot off a quick message and follow up if needed; however I've had a couple of situations that required immediate answers and response and those times I absolutely picked up the phone.
Having worked in tech support for two major telecomm companies though, I'm convinced it's most commonly a problem of formatting. The discrepancy between instruction and reality is what throws non-technical people off. Given accurate instructions your grandpa could figure it out at least 75% of the time. One of the companies placed extreme emphasis on their resources with the reasoning "They'll figure it out." and according to them and their metrics they seemed to think most people did figure it out by braille if you will.
Just my two (or more) cents.
Customer (via SMS): hey, the whole internet on my phone crashes when i use feature x. wtf???
Customer Support Rep A: Hey, we'd be happy to help you with that. What platform/version/subscription do you have?
Customer (7.5 hours later): its the latest version, and i have a verizon. why can't you guys fix this???
CSR B: [lists some possible troubleshooting steps, asks customer to call]
Customer, the next day on Twitter and Facebook: [Company] has the worst support! They broke my phone, and they say they'll help you by text, but then when you ask them anything they just ignore your problem or tell you to call anyway. FUCK [COMPANY] AND DON'T BUY THEIR CRAP!!!
- High phone support visibility on how-to pages: Don't link to chat if it's not going to an ideal experience - Focus on customer facing how-to resources: I'm confident every minute spent making the thorny aspects of phones (e.g. moving photos from internal storage) rock-solid is worth no less than an hour of CSR time. - Proactively making recommendations on more ideal support scenarios if applicable: "Hey, before we get started, this part can be tricky and I'd love to walk you through it, it'll only take a few minutes and I can schedule a time to call you if you're busy right now. <details of next steps>." - Perhaps most importantly (I just noticed from your interaction) CSR A should handle (and be given the freedom to handle) the problem from start to finish OR it should be made -very- easy for CSR B to pick up where it was left off (either a great CRM or an honest "I've got a family to go home to, I'm going to hand you off to So-and-So or I'll be back and available at"). That said, Simple lacks consistent CSR interaction but I haven't encountered a problem with the hand-off, most of the time I never notice.
When I was a CSR 99% of the time the customer wasn't my enemy, it was my coworkers (or my CRM).
That said, I don't believe SMS literally is a reasonable form of support and should never be marketed that way, but chat, even in-app chat could substitute. Additionally, providing these methods gives people a chance to ask questions and get resolutions that may be nagging them but not enough to call someone, it also opens up lines of communication to people like myself who get anxious thinking about calling people.
I don't believe this is due to technological limitations of email. I have had conversations via email that are essentially realtime chats. I think the real issue is that passive support simply gets a lot more support requests than non-passive support. Offering SMS sadly wouldn't resolve this, it would just be another support medium that gets flooded like email.
NOTE - By passive support I mean anything where you send a message and just wait for a response. Non-passive support would be something like a phone call where you wait on hold for someone to be available.
While it's great to have a simple text-based medium to do this, SMS is awful.
I agree with the sentiment, but it's hard to take this guy serious when he suggests something so obviously bad.
At least with an app you have the option of adding in security layers. SSL for one, Simple uses a PIN on their app, Art.com will process a transaction in chat but direct you to their website to submit payment information, and on top of all this you have the added benefit of easily documented interaction. -You- can reference your own interaction without the near impossibility of having a call recording audited (as a call center CSR and supervisor I've seen this happen no more than six times).
In fact, in one interaction with Art.com I sent an email to an agent with photos of some damage to the piece they shipped me in my initial email which resulted in a resolution in the response.
Another case with GIGABYTE I was able to send photographic description of my issue due to a consistent (likely language barrier related) misunderstanding about what was meant by "a missing pin." which immediately clarified the conversation and we were able to move forward.
tl;dr the variety of "offline" security measures available and the convenience gained with "offline" support makes that minefield significantly less dangerous in my experience, especially considering the dangers already present in phone based support.
After failing to get through on their various numbers, I cancelled my eFax account via e-mail this way (as they don't/didn't allow online cancellations) and it went smoothly.
So simple e-mail vs do a credit card chargeback. As a merchant, I know which I'd prefer. If they have capacity issues with support, that's their issue to resolve as a business. If you can't adequately support your customers equally and you can't work out how to fix that, you deserve to go out of business.
Of course, hogging a teletype operator specifically for the disabled to tackle some minor support issue probably isn't the most positive thing to do, but sending an e-mail.. anyone can do that and if it takes a white lie to get past an internal policy, so be it.
Right, but it's not eFax you're hurting by tying up their accessibility resources.
I believe there is a perceived notion in the general public that speaking is the fastest way to resolve an issue. This probably comes from the fact that we can speak our thoughts faster than almost any other method of communication. Verbally talking with someone is also the most primal way of resolving issues. Finally, 7% of any message is conveyed through words, 38% through vocal elements (how those words are spoken), and 55% through nonverbal elements (facial expressions, gestures, posture, etc) (from a blog I wrote - http://blog.blainelight.com/2012/09/NonVerbalCommunication.h... most people want to have their frustrations 'heard' when reach out to support, and text only convey's 7% of their whole message.
In a tech-centric world, it's easy for us to want to embrace the future. We have to realize that even the early majority is still dependent on voice communications to express their primal need for help (i.e. asking for support from a company).
Would love to hear your further thoughts. -Blaine
Just a thought.
The article talks about apps though, and honestly, I'd rather sit through a hour on hold on the phone than install some bloatware app. Forget 'apps', email is perfect for support.
(I write this as the head of a large customer service operation for a US-based mobile phone provider - if a phone company can answer the phone without putting their customers through voice menu hell, anyone can do it.)