On this blog, I’ve pointed out the failings of many others. I’ve hinted at having to take ownership for others failures as the customer sees us, and not the people behind us (often messing with us). Our job is, among many other things, to hide that silliness away from them so they can focus upon their issues.
This is not to say we/I don’t mess up. Most of the time its minor. Every now and then, well, …
So today, after moving our mail servers over to a new setup (long story, another post), I went on a ticket updating spree on RT. When we close out tickets we add comments. I encourage my team, in general, to put all their thoughts into the tickets.
You might see where this trajectory is headed. Yup, you’d be right.
I put my thoughts in on a particularly annoying ticket. It was a bad situation, punctuated by a customer avoiding making critical decisions in a timely manner. To which there are a number of consequences. One of this was, in this case, massive data loss. Think old, out of warranty machine, never well maintained after customer went cheap on support (they had dropped paid support, and then decided to hire a local body shop to take over). A combination of a support group in well above their heads, a customer focused like a laser on only the near term costs, and a rotating backup system designed to keep 90 days of data.
They took well more than 90 days to make up their mind on what to do, very close to 1/2 of a year. In the mean time, no one ever shut off their backup system, which happily pruned old directories … because, no one, ever, would take even 30 days to make a critical business decision like this.
Ahh … those best laid plans of mice, men, and storage and backup systems.
But the point was that I was brutally direct in my internal summary. I was to the point, I assigned the blame to where it obviously was. I made sure the ticket was in resolved mode, and that this was in the (internal) comments.
We do our commenting as directly as possible to make sure we haven’t lose the critical aspects of the nature of the service. If the customer has made a mistake, we call it out. If we have, we call it out.
It was all there for us to review at a later time.
I clicked close.
And it sent it to the customer.
I realized this after about a minute. I sent the customer an apology for being brutally direct, but I stood behind my analysis. It was spot on, even if it was hard for them to read.
Obviously they didn’t like this, but, as they had decided long ago that our service cost too much (it didn’t, it just wasn’t free, and there was triage involved), it wasn’t going to cost us a customer that we didn’t have anyway.
I am not hand waving this off. This is a cautionary tale of making annotations that should be private be, really, private. I know some people are put off by my direct bluntness. I don’t sugar coat things. And I feel bad that they saw my direct bluntness. But the value of this approach is that, in the future, when a customer such as them (but obviously not them), calls up for service, we can see a summary of what they’ve done right/wrong/dangerously. And see it discussed in concise, to the point language that spares no one’s feelings. This isn’t about peoples feelings, its about providing high quality service and support, learning from issues, and making sure that lessons are not lost.
So I don’t think its bad karma … not something coming around to bite us … but it is a potential hazard w.r.t. the way we work. It was my failure in not keeping this morbidity and mortality report private.
So you can laugh at me for my own particular failing in this regard. My analysis was brutally direct and blunt, and I stand by it, but it should have remained within our walls. And I can’t blame anyone but me. Call it a layer 8 failure.
Viewed 56793 times by 2494 viewers