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