Hacker News Reader

Comment by nkrisc | Hacker News Reader

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.

View on HN

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.

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.

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

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

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

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

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?

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.

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

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.

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.

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.

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

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.

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.

Reply on news.ycombinator.com