Show HN: A collection of support replies to make your support stand out | Hacker News Reader

Show HN: A collection of support replies to make your support stand out

supportexamples.com

198 pointssivaram63683 comments

I know this is generally effective, which is why it's done, but personally I hate it: reflecting what I said back to me and telling me how frustrating it must be. No shit, I know that. Don't make me read that, just tell me how the problem can be solved. I don't even need you to tell me you're sorry. I'm not looking for empathy or a shoulder to cry on, I'm looking for a solution and to waste as little time as possible. The worst is when you're calling support and have to listen to them talk through this BS in real time, at least in an email I can skim over it.

For the cynical among us, these responses are probably aggravating.

For the majority of people though, they're probably effective.

You are highlighting something that we are trying to quantify on my team right now. Customers come to you either scared or savvy, or somewhere on that spectrum.

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.

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

I am very interested in this. especially the change in accounting and the reasoning behind this. could you point me in the right direction regarding where you read it?

thanks in advance.

It has been some years, but I think the book that most opened my eyes on this was this one: https://www.amazon.com/gp/product/B006IED92S/

I know less about them, but I also was really impressed by a talk from Bjarte Bogsnes about Beyond Budgeting. https://bbrt.org/

Thank you so very much! Appreciated...

Oh, and one way I've heard to express it is that most businesses are focused on costs and profits. But the right approach is to focus on value creation and waste.

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?

Sure thing. Feel free to contact me via email or twitter DM if I can be of further service.

Look into cost accounting vs. lean accounting. /The Goal/ is a classic and relatively fun read. /Principles of Product Development Flow/ is also highly regarded, although neither are strictly accounting books.

The Goal is currently on my list after having read "The Phoenix Project". Thanks for also giving me additional material with "Principles of Product Development Flow".

The reality is, very few customers really care about apologies or words. They want results. When customer service can't do anything without approval or just can't fix anything then you may as well call what you do customer no service. I've been doing CS for over 10 years.

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.

This is one of the main reasons I still sit down every day and take the first contact from a customer via the support channel myself.

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.

I wish these engineers would simply have some empathy for those of us working support.

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.

That sounds like a tricky problem indeed. It reminds of work I've done in the past for a site that had mostly novice users as an audience, but still had a healthy contingent of advanced and knowledgeable users. It was in the automotive space, and catering to both was a constant challenge. The advanced users wanted straight access to raw facts and details, while the novice users needed to feel comfortable and that this was something that was not above their head.

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.

Cool way to view it! This is also an argument in favour of long-term business relations over short-term ones: you can skip the part where you figure out where the customer is, because you already know it. Meaning much less wasted time and more efficient support on both ends.

That said, sometimes a savvy customer can become scared, if say, adopting a new feature. I agree that TAMs and other account managers may be able to feed data into that model, support may be the front line as it shifts (but also a TAM or another Account Exec could be too).

It's still in it's early stages in use here, but it's been a huge help already intra-support for my team.

Undervalued too. Anyone who's competent tends to leave for greener pastures.

Just parroting what someone says... that's super annoying, but there is some use to something like it.

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.

Yup, all too often support cases may have an X/Y Problem (see http://xyproblem.info/).

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.

Well I've gotten allergic to the term 'XY problem' itself. All too often it's tossed around by people who think they know my problem better than I do, and then dismiss me by saying 'don't do that' or 'just do something else' (this is mostly in the context of 'community support' like Stack Overflow).

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.

Yeah if you can come up with a good definition of a problem, you can save serious time / $.

If you don't ... hold on man it's gonna be a wild ride because really you're just guessing.

http://3e.org/xy.png

Is it generally effective?

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.

Repeating what the customer said back to them only seems popular because the status quo in first-line support is reply with a form e-mail without having read and understood the customer's e-mail

> personally I hate it

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 agree. And definitely do not call me if I contacted you via email.

Yes, respond on the channel received.

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.

> For the cynical among us, these responses are probably aggravating.

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.

Hi [customer rep's name]

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!

Sincerely,

[your name]

Thanks for this! And I never respond to customer satisfaction surveys.

Might be a British/American difference but I found all of these incredibly patronising and insincere. You need empathy and sincerity to be good at customer service. At the very least just think of the reply you'd expect if you had the same problem with a different company.

> I found all of these incredibly patronising and insincere

I'm American. I find close to 70% of my interactions with support staff is insincere on the part of the support staff.

I don't mean for this to sound patronizing but that's because your compatriots (Americans) expect and want this kind of support. I know this from working in support for a long time and handling customers from all over the globe. Nowhere is the entitlement and expectation for "beyond friendly" service as problematic as it is for US customers.

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.

> angebergesellschaft

Google didn't help with translating this one, can you shed Teutonic light on this word?

I got angeber = "show off" and gesellschaft = "society", which I think makes sense in the context of hnarn's comment. I'm not German though so not 100% sure.

"Angeber" is a somewhat archaic word for an informant (but apparently means "show-off" today), so it's someone who reports you to the authorities, essentially a "snitch" but with a much more authoritarian connotation. So it's a society of informants, where everybody's afraid to be genuine due to the possible repercussions.

I find about that percentage of my interactions with anyone involved in business, generally insincere and gross. Work and providing value to people can feel great but business is disgusting.

Indeed. Empathy doesn't come from message templates. It comes from actual empathy.

Templates do have a part to play when they are incorporated correctly into training and procedures. At times, they can be used as a checklist for inexperienced support people, but as a support manager you need people to understand that these aren't even the minimum required for a response to a customer. I always show our templates and what actually gets sent to the customer for comparison.

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.

Like tending the ground on a farm can be seen as a cost.

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

I pretty much hate these.

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.

They stand out as overly verbose and insincere, but I'm not sure that's something worth emulating.

If "standing out" is your goal, sorry but generic boilerplate platitudes is not the way to go.

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.

Hey sivaram636, can I request that you redirect port 80 to 443? You've already got TLS and HSTS enabled, but people can still use your site via HTTP, which is what you linked. Optionally, you can follow these instructions to preload your domain to the HSTS preload list: https://hstspreload.org/?domain=supportexamples.com

Hi eganist,

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.

Thank you, [customer support]

Thanks for letting me know. I have added a force redirect to https :)

This is what a customer service response should look like.

Seems like a collection of generic corporate speak. Most of them are some variation on "I'm so [sorry/happy] that you had a [frustrating/great] experience with our product".

As someone who have worked in support for a long time, these may do the trick for a non-technical customer base that isn't interested in anything but 75% therapy and 25% problem resolution, but I state with conviction that most customers that come to you with a problem of a technical nature, and have the technical competence to understand the crux of the issue, will expect a technical and competent response. That's how you "stand out" in terms of support, because it's pathetically and amazingly rare.

I honestly believe that auto-generated messages of any kind should be marked as such. It's incredibly annoying to read through these kinds of messages knowing they're not really written for you. The issue here for me is respecting your customer's time/attention.

That is what I do with templates.

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

You know what makes support stand out, in a positive way?

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.

I'm all in favor of reusing my own replies to customers as long as I customize them. I'm just saving myself some typing. I teach others to do this as a way to optimize their workflow and save the typing, but not the thinking.

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.

This.

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.

I've worked for years in various forms of Support, both end users and business clients (basically the bosses of the users).

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 person@clientdomain.com 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.

> absolutely crucial for some cultures like the US

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.

For example you have to tell customers "I will fix this for you" otherwise seem to get uncomfortable and might call your manager to complain that you are not helpful enough. I've seen it happen enough they train support reps yo use that specific phrase.

Question for sivaram636: if you contacted a supplier about a problem and received a reply like one of these, how would it make you feel?

Hey sivaram636, it'd be fun to collaborate on maintaining this list of responses & how it evolves over time.

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/

Thoughts?

On a mobile phone the original is noticeably faster to load, way more visually appealing, and not broken. Mintdata doesn't seem to care for mobile phone display width (in this case?)

It's not loading for me. Do I need to do anything?

Honestly its things like this which remind me of the "telemarketer singularity."

https://ieet.org/index.php/IEET2/more/rinesi20150806

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

Thank you! As a non-native English speaker this is actually pretty useful.

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)

These canned responses totally miss the point. Good support comes from putting knowledgeable people who truly care on the front lines, and giving them the tools and authority to get things done directly.

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.

'Customer Support' is treated as a cost-center in far too many businesses. Good customer support can be used as a marketing tool - a differentiator to competitors.

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.

So the plan for standing out is by copying someone else's answers...

The plan is to create a place for customer support heroes to share and learn from each other.

I am sorry to say this, but this is the opposite of what you have accomplished. You've just given lazy support reps templates so that they don't have to think, they can just copy/paste. I've been doing support for 20+ years in various roles, and I have seen what happens when people have templates: They stop thinking for themselves. It's not good. I wish you the best all the same.

> customer support heroes

What an utterly meaningless phrase.

Yeah, no. The patronizing wall-of-text approach is terrible.

Actual useful support replies can't really be scripted, because they are specific to the context of the request.

One way we make our support replies stand out that wasn't obvious when we started:

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.

None of the answers shown have anything to do with fixing the problem. If I contact support, I want either a fix or a refund.

See "Bedbug letter".[1]

[1] https://www.snopes.com/fact-check/the-bedbug-letter/

Right now, the second example is an actual example of this === I know that having to go through multiple troubleshooting steps and not having any of them work can be a real pain, especially when you have more important things to be doing.” Lastly, let them know that you have been looking into the issue and that you think it should be resolved: “That being said, I think we might have gotten to the bottom of this." ===

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.

The entitlement here in the comments is astounding.

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.

Sure they are, but those expectations need to be set early on too.

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.

I've yet to see an example of this that actually works. I guess Google is one of the heaviest proponents of "get support only if you pay for it". Any others?

There is a big world of business out there.

Look at all the top PLM, ERP, CAD...

And capital equipment.

Many others.

Aw, I was hoping the summary was sarcasm and this would have humorous examples of things NOT to do.

"Cribbing support replies from a website" is a pretty good example of what not to do.

Give me one of these responses and I will leave your service.

This reminds me of how support and related teams are underfunded and undertrained both in their product line and in psychology.

Does a site like this exist for sales script?

Found this https://marketingexamples.com/ :)

Reply on news.ycombinator.com