Hacker News new | ask | show | jobs
by mojowo11 2744 days ago
As a manager of a customer service team, everyone on my team knows exactly whether something has been "totally wiped" or not, regardless of whether it's something that would require developer intervention to recover. To have your reps not understand this and ultimately mislead the customer (or, in this case, I suppose former customer would be more accurate) is a management/training problem, and what the rep ultimately said on behalf of the company was a lie as a result.
3 comments

I have to disagree with this wholeheartedly because sometimes you don't want to set the expectation with a front-line representative that the data is recoverable. In many cases, you don't want reps promising to recover data that's potentially unrecoverable. It's one thing to recover data in the event of a mistake on behalf of the company but that should require a conversation with someone outside of front-line customer service. I've been in situations too many times where our front-line team knew when something had not been "totally wiped" and they turned out to be "totally wrong" because they were aware that we kept backups but not aware that we had a strict retention policy outside of a specific timeframe or, in other cases, where a hardware failure caused a loss of a specific set of data because it was marked for deletion and wasn't scheduled to have a backup anyways. The customer had cancelled their account and agreed to losing their data but didn't actually read the terms of the cancellation they agreed to and then returned over a month later asking for their data and a rep told them that it's not really lost because we keep backups every 30, 60, and 90 days. That part was true for live accounts but not for deleted accounts.

In other words, data recovery that can't be handled by the customer service reps and that requires developer intervention should be a "surprise and delight" sort of situation and not a "customer should expect this" type of situation.

Saying you know when you don't is a lie. Instructing people to say they know when they don't is instructing them to lie on your behalf.

The answer should be: "I can't know." Followed by one of: (1) Let me connect you to someone who can know (2) Let me tell you how much it costs to find out (or 3) Also we don't care.

That would be honest. Not saying it's easy.

>Saying you know when you don't is a lie. Instructing people to say they know when they don't is instructing them to lie on your behalf.

Because, in that case, the intent of the statement is to deceive. If the intent of the statement is simply to not set an expectation that can't be guaranteed rather than to intentionally deceive, then it's not a lie, in my opinion.

I work in audio editing and recovery/enhancement and there are situations on a regular basis where we tell customers that their audio can't be recovered. I don't think we're lying to customers in saying that despite the fact that, in some cases, we may be able to recover or enhance the audio to the point where it's usable if we invested an exorbitant amount of time on it. In the most literal sense, yes we can recover the audio but in the practical sense and, most importantly, to the customer we can't recover the audio in any meaningful way because they either can't afford the work necessary, we don't have the resources to devote to that work, or we can't guarantee that, even if we can recover it, it's acceptable for whatever purpose they need it for despite being "good enough" for us.

I agree with what you say. I think the trouble starts when the economical burden of recovery is not on the customer, but on the company.

If I tell somebody that something's unrevocerable because I know they wouldn't want to pay the recovery, I'm not lying. But saying nothing can be done when I'm just afraid of the cost of righting my mistake: that is lying.

The correct response is to tell the customer that it has been deleted from the main server, and that it MAY be recoverable with escalation to the dev team. Why would you even consider telling them anything else, if that is not the truth?
Agreed, regardless of whether the rep can see it or not, they should be trained properly and reply that they no longer have access to the data, and that access would require an escalation of some sort. To simply say the data is gone is a straight up lie.
A lie is a falsehood that's meant to deceive someone. A rep saying the data is gone because, functionally, it is is not a lie. If the intent is to set proper expectations with a customer then I think telling them it's gone and potentially being able to say "actually, we were able to recover it by escalating it" is better than "we may be able to recover it by escalating the issue" because you're underpromising and overdelivering. The opposite just sets you and the customer for failure.
It's possible that tools used by Care/Support don't have everything implemented
to quote your parent:

> regardless of whether it's something that would require developer intervention to recover.