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.
Comments
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.
Just my two (or more) cents.
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.
Wait time, time spend bouncing around various departments and "executives" and "supervisors" are worse than that.
but text is precise and can be referenced later? and if it involves a gui, screenshots?