For the cynical among us, these responses are probably aggravating.
For the majority of people though, they're probably effective.
You are often a savvy customer, that is being treated like you are scared. That disconnect is where your animosity comes from.
Good Support will be able to quickly identify where you are on the scale, and tailor the response appropriately.
Problem number two: It's hard to keep good people in support because it's difficult and often underpaid because its a cost of good sold.
That's one way to look at it. Another is that it's marketing and brand-building. Yet another is that it's user research. And vital data for process improvement, product improvement, and waste reduction.
In reading about Lean Manufacturing, one of the most interesting things I learned is that companies that successfully transition to it don't just change their manufacturing. They change their accounting. That's because traditional accounting has viewpoints baked into it that conflict with long-term improvement.
thanks in advance.
I know less about them, but I also was really impressed by a talk from Bjarte Bogsnes about Beyond Budgeting. https://bbrt.org/
So if I'm making hamburgers, the way to sustained profit isn't identifying my biggest cost (say, beef) and then cutting it. It's by identifying the biggest wastes and reducing them. So the first thing I do is to reduce beef inventory, so I'm not throwing out unused meat (or serving old meat, which also reduces customer value). I minimize overproduction, so I'm not tossing (or serving) staled cooked burgers. Maybe I change how the patty is made, because all things equal people like the look and flavor of a thinner but wider burger that peeps past the edge of he bun.
Similarly, I'd look at customer service as a way to maximize value delivered. Even if we make and sell a product that's in theory great, no value is delivered if a person can't figure out how to work it. So obviously, we need to help every person who buys it. But then we also look upstream in the process, to see how we can redesign the product and its experience so that customer support is less necessary. That in turn lets existing CS staff discover and mitigate less obvious problems.
Is that helpful?
Two examples from my experience. Had a lady crying because her laptop never arrived and she thought it would be charged to her anyway. I apologized to try and console her. But it wasn't until I promised that she wouldn't be charged if she never got it that she stopped crying.
Another time, on the receiving end, the company AAA gave me the runaround for 3 months in an infuriating circle of no service. Finally I called the other party and told him I'd have to file a lawsuit if it wasn't resolved by the next day. Miraculously I got a phone call from an upper manager with a real apology and an explanation of their failure. We were able to cut a deal then and there. I never felt more relieved than when he was giving that apology and it changed the entire tone of where the call was going.
Thats what the apology should do. It should shape the rest of the call. A predestined stock apology only serves to annoy the caller on the rest of that transaction.
Although you said it better, basically what I'm trying to do is triage each customer issue and figure out where they fit on that spectrum.
Then, hopefully, get them the right answer, but also in line with their expectations and experience. The goal is never to have them say "Yea, thanks, I already did that..."
The last thing I want is to patronize an engineer with a list of stock questions they already have tried and still have a problem.
Our intention is _never_ to aggravate you. We make mistakes, we miss words and sentences. Support is fast and hard and to put it lightly often looked down upon.
We want your shit to work, too. Being an engineer for every company that is your customer with few details is insanely difficult.
Designing navigation, in particular, was more difficult. Novices didn't yet have the domain-specific mental models yet the experts were skimming for jargon and keywords.
Those advanced users were also the most allergic to any kind of empathy-based support.
It's still in it's early stages in use here, but it's been a huge help already intra-support for my team.
I do a lot of:
"Here is the problem as I understand it, X -> Y -> Z, when A, B, C.
Let me know if I got that right."
Then I go on into what I saw when I tried it.
What repeating SHOULD be is confirming that we're all on the same page (often with new details and specifics). What it often is ... is just repeating.
Sadly I found folks so generally frustrated by support that a large % of time they would be upset even when you were trying to understand. Some folks are so sensitive to repeating things back that they miss when I include new information / questions.
Support sucks, customers are frustrated so they don't really participate and hurt themselves ... companies devalue support, good management avoids / leaves support, and the whole thing stinks. I chose to leave that general business unit / area despite being well paid because of such things. I actually had engineering folks at my previous job reach out to me to encourage me to apply and return because we worked together well, I enjoyed working with them, but there was no getting around that I would be on the support team and I didn't want that.
It's really import to clarify:
1. What they're trying to accomplish
2. The steps they're taking
3. The expected result
4. The actual result
A misunderstanding of any of those points can waste huge amounts of time and cause lots of frustration.
It happens mostly when I distill a problem down into its most basic, abstract form, because otherwise it's too difficult to explain (I mean I can't fault people for not wanting to take 30 minutes to understand all design nuances and trade offs that were made over the last 10 years in my particular case). Then they take that abstract example as the real use case and find reasons to not answer the actual question. Then again, I'm probably in the 'cynical' category mentioned up-thread.
If you don't ... hold on man it's gonna be a wild ride because really you're just guessing.
I mean sure, this technique can be handy in person in the hands of a skilled person who actually cares. But I have to suspect most people see through the insincerity, at least on a subconscious level.
I honestly am happier if somebody quickly and sincerely acknowledges my feelings and POV, as then I can be sure I got my point across. (Before moving on to solutions, of course, because eagerness to fix the problem is a major part of my feelings.) But what immediately doubles my irritation is when responses feel synthetic.
It's like when an on-hold recording says, "We're sorry for the delay." Who exactly is sorry? The little bit of looped tape? The voice actor hired 7 years ago to record the script? The telephone network? Nobody. Nobody is experiencing sorrow that I'm on hold. If they were, they might work to fix the problem. Support responses generally feel the same way to me. And I'm especially looking at you here, Amazon.
Totally agree. To me the effect is very similar to the beginning of a typical scam telephone call where the caller starts by asking whether I'm having a good day.
I do a fair amount over SMS of all things. It is potent. They can quickly send the trouble, media, etc...
I will just open a ticket for them at some point to capture things for later, but a quick response almost always works well.
I've been dealing with some support recently that leans heavily on the empathy. They're also proving to be useless at actually addressing my problems. This is a great combination for generating extreme frustration, particularly in a cynic like myself.
I may be alone in this, but I suspect maybe not.
Thanks for taking time to cut and paste your response into your company's email support system. Unfortunately, I will not give you any future business because instead of quickly resolving the issue you are wasting my valuable time with patronizing platitudes and endless ineffectiveness.
However, I realize you are just a cog in a wheel doing your job to get a paycheck so I will play a few rounds of cut-and-paste with you just for fun before I call in and play the punch-a-zero-until-reaching-a-person game to actually get the issue resolved.
I hope this feedback helps. Let my spam filter know if you have any more questions or comments!
I'm American. I find close to 70% of my interactions with support staff is insincere on the part of the support staff.
And it's not just B2C, this type of behavior is creeping into B2B interactions as well, to the degree that technical consultants and specially trained staff are expected to act in a vapid and thoroughly "insincere" manner as well, anything else is seen as unprofessional.
In most parts of Europe, it's another story entirely. If you know what you're doing and you're doing it well, most people understand you're just doing your job, and they will not expect faked enthusiasm or insincere empathy. In fact, in many markets a dash of cynicism will actually get you closer to the customer.
Of course, this is generalizing and there are Americans who "act European" and vice versa, but the minefield of attempting to be sincere to a US customer is like nothing I've experienced anywhere else. It's almost like an angebergesellschaft where some people are just waiting to pounce on you for your unprofessional behavior, knowing that they will be backed up by management because noone wants people to be unprofessional, right.
Google didn't help with translating this one, can you shed Teutonic light on this word?
The support person needs to understand the problem that the customer faces and how it connects to the product they are supporting (today and in the future.) Often, support is a just a cost to companies, or they offer no career path in support, which means that templates become the norm for bad support management.
...until yields go in the dumpster.
Only then it is seen as part of the entire cycle needed to make money.
Support is a part of the cycle. It should be priced in and those people given good opps same as everyone.
And, in many scenarios, support can lead to sales too. Good support people get to know their contacts. And that relationship can lead to genuine interest in more business. Experienced ones will do this naturally. It is all bonus money when they do. (Low cost of sales) Personally, I would spiff em. No quotas though.
Please, whoever reads this thinking about how to drive sales... just stop. Empower people to have those chats, make introductions, etc... but don't put it on your forecast, or under sales management. I am not speaking to that. I am speaking about experienced support people who become aware they can help on that front when indicated and warranted. Not looking for chances to make a pitch.
The moment you do, what was genuine becomes as contrived as these template are.
When I do support, I treat my users as a peer to the highest degree possible. They are on my team, and I am on theirs and this is how we feed the kids. Or build for our futures... whatever.
I do find some need the handling described here. And they get it. No worries. Most do not. They want help first and foremost. I make sure they get it asap.
But this stuff as a first response?
No way. I much prefer to respond in a way that shows I understand what they are telling me, and either give them options to resolve, or start asking questions so that I can do that.
And when I do not know, I say that, asking for their help getting after fixing whatever has happened to them.
I reckon the problem is this vague notion that exists about what "professional" looks like - slick, smooth, bland, and relentlessly positive seems to be an easy bar.
Honestly if you want to promote replies that stand out, then you need to do just that: make them stand out, not just blend in.
Thanks so much for commenting about this — I’m sorry to hear that you were caught off guard by our httpd configuration.
I can totally get how it can be frustrating to receive a protocol that you weren’t expecting, especially when you’ve just started to use our site.
Could you share a bit more information with me so that we can get to the bottom of this? For example, would you mind sending me the URL associated with your request along with the date that you accessed the page? Using that, I can take a look at our system and see how we can get this fixed for you.
"Hey Bob, we have seen that one happen and we have nothing special noted on your case so far.
Let me send you our internal tech note. Give it a go and let me know where you end up. If anything does not make sense get back with me and we can do it together.
They know it is a cut n paste, but one that is qualified, warranted and indicated. Easy peasy.
Actually reading my question.
Giving me a competent answer that doesn't include telling me to try thing that I've already tried, and which I've also documented in my original email/support ticket (see my first point).
If I hit a bug in the system, acknowledge that it's a bug, and tell me something about its state (has it been triaged yet?). If possible, point me to it in a public bug tracker.
What most people intend to do is to optimize themselves, but what they end up doing is automating themselves. Overusing predefined replies, no matter well written, turns one into an automaton.
I lead a technical support team - we have very well written macro responses for a variety of topics, some technical and some not, but almost always we modify the boilerplate with ticket-specific context. There's no reason why I should type the description of a Request Timeout error 15 times per day, but it's certainly worth the effort to include that pre-written information with some relevant context.
These replies are the most useful when Support is B2C and absolutely crucial for some cultures like the US.
When supporting a business I've found that there are other useful skills:
* Understanding different stakeholders and how their needs differ. Just because someone's email is firstname.lastname@example.org doesn't mean they can increase scope and give you more work just because.
* Building trust is crucial, and being seen as genuine is extremely important - better err on the side of being truthful, even if it means you might be rude.
* If you correct the person you are talking to might be just what the his organization wants and expects from you.
* Generally the people you talk to the other side must be treated as peers, because at the end of the day you and they are both hired by someone to achieve a particular goal. They might even turn out to be contractors, but often this information is hidden.
* Above all else your job is to make money for your company. It is up to you, not marketing, upper management or sales.
I'm interested to hear what you mean by this. What does non-US support look like? I'm from Australia but it seems most companies here adopt US-centric support system which seem to sliiightly hit the mark, but I can't quite put my finger on the difference.
We've built a quick UI that shows the same dataset & would be interested to see which other features the community would like to see: https://support-samples.mintdata.com/
"The future isn’t a robot boot stamping on a human face forever. It’s a world where everything you see has a little telemarketer inside them, one that knows everything about you and never, ever, stops selling things to you."
Template conversations intended to convince the mark they are heard and understood. Scripts designed to simulate a real human interaction and conversation.
Sure this is int he context of "support" rather than "telemarketing" but the feel is the same. Substitute real human interaction with scripted simulated interaction, designed and optimized to evoke the desired emotional reaction to the target.
Of course I don't think this should be used as a copy/paste solution but more for finding inspiration on how to politely reply to customers when hard questions arise (eg. request for discounting)
I'm sure everyone here's experienced the difference between a support superstar vs. apathetic call centre zombie. High-caliber reps don't need to fake it with cosmetic literary lipstick. On the other hand if you're using these templates to script the interactions of your underperformers, their tone and empathy will lose authenticity as soon as your customer figures out they were cut and pasted by someone who couldn't be bothered to personalize a response.
But in the case of bugs and feature enhancements, this requires a more (..and I hate to say the words..) a more 'agile' approach.
In my experience, there is often a big gap between Support and Engineering.
If I were given a choice between delivering new features and fixing existing ones, I would always choose the latter.
Make an existing customer happier, and make future sales more viable.
What an utterly meaningless phrase.
Actual useful support replies can't really be scripted, because they are specific to the context of the request.
If you provide phone support, email your customer a summary of what their problem was and how you solved it on the call along with links to user guide articles where applicable.
The customer can now easily send follow-up questions via that thread, while your team has better documentation of their support history.
See "Bedbug letter".
They forgot to remove the instruction text before replying, I guess this is the modern equivalent of the forgotten Post It note in the bedbug letter.
I would bet that if you had two competing services, with 1) being expensive but providing you with individual support, while 2)
Being cheaper and giving you automatic responses, 99% would go for the 2) option.
People are not willing to pay for the level of customer support that they assume.
Plenty of people will pay for value added. The whole trick is to actually add that value and ask money for it.
The ones that buy in will use the support and appreciate its role in their success.
Look at all the top PLM, ERP, CAD...
And capital equipment.