Category: Peeves (Page 1 of 4)

Let’s put on a little play, in one act. To set the scene you need to know that my employers use a service called Backup Radar to track successes and failures across our suite of supported backup products. Backup Radar uses APIs to connect to some services and relies on emailed reports for others. CrashPlan is one of those others.

Until recently, CrashPlan has sent a daily summary report of successes and failures all in one message. Nice, simple, all in one place, easy to parse. Then they decided to change report formats…

Me, to CrashPlan Support: Hey, guys. I noticed the new report format. Looks snazzy, but could you re-enable reporting successful jobs? This is important to us.

CrashPlan Support: LOL No.

Me, to CPS: Do you have an API we could query instead?

CPS: Um what?

Me, to CPS: Any options at all to remedy this problem? It’s serious enough that we’re going to look at replacing your product in our offerings.

CPS: We only look forward, never back.

Me, to Backup Radar Support: Looks like CrashPlan have utterly crippled our ability to use their centralized daily summary report to track successful jobs. Got any suggestions?

Backup Radar Support: Here’s an article on how to configure the CrashPlan clients individually to send their daily reports, bypassing the useless centralized reporting situation.

Me: Well, okay. That’ll be tedious, but whatever works, thanks!

CrashPlan: Oh hey, we just updated the UI for all clients to remove the email reporting option. LOL!

Me: …sigh.

Hey, remember when CrashPlan didn’t suck? I used their services for years! I pushed for us to adopt them as the replacement for Ahsay!

Argh.

The script you’re about to read doesn’t detail how every interaction with a particular vendor’s tech support staff goes, but it’s very, very indicative and common…

Me: Hello! A problem has occurred with your product. Now, having worked with this product nigh onto a decade now, I’m aware of the usual issues and have gone through the knowledge base articles numbered Such and Such. I can confirm that the state of the usual problem-causing factors is nominal. I am looking for alternative avenues to pursue to remedy the problem.

Ticket: *remains unassigned for hours*

Me: Hello, Support Manager! I can’t help but notice that the High Priority ticket I submitted has gone unassigned. We, ah, kind of need this problem resolved ASAP.

Support Manager: I have assigned your ticket. Please be aware that we do not post support SLAs.

Me: That’s nice, but five hours without assigning a ticket isn’t about SLAs, it’s about “if we treated our clients like that, we’d be put out of business.” But whatever.

Tech: Hello, I have been assigned to your ticket. Judging by the environment, you should read knowledge base article numbered Such. It will resolve your problem.

Me: Had you actually read my ticket (*), you’d know that I already referenced and followed the instructions in that article. Next?

Tech: Have you tried rebooting the system?

Me: …yes. The system has been rebooted. Next?

Tech: You are using the wrong kind of credential (**). Change that and you’ll probably be all set.

Me: Tried that. Tried two variants of that, actually. Still not working. Next?

Time: *passes*

NewTech: I see that you are trying to use the product in a particular environment. Please see knowledge base article Such, it will remedy the problem.

Me: Hello, NewTech! If you’d read my ticket notes, you would know that I have already addressed the possibility detailed in the second article. Next?

Time: *passes*

Me: *sighs*

And that’s where things stand.

(* – If I had a dollar for every time this vendor’s techs utterly failed to read the text of my ticket submission, I could treat both of my girlfriends and their families, all together, to a very nice dinner out.)

(** – This is a domain controller. The credential account was technically shown as a “local” account but since it’s a domain controller, its local accounts are domain accounts. Idiots.)