Anatomy of an apology

We are human, and we will make mistakes. We can hope that they don’t have disastrous consequences, but sooner or later mistakes will be made. There’s just no way around it. Sometimes we’re unlucky, sometimes we’re lazy, and sometimes we’re simply negligent. Whatever the case might be, the end result is the same; a mistake has been made. That, however, is only part of the picture.

Once a mistake has not only been made, but identified, we need to correct its effects as best we can. Sometimes we can’t do much of anything, and sometimes we can fully and wholly repair the damage. Regardless, offering an apology is part and parcel of how we attempt to repair it. What, then, goes into a good apology?

It has been my experience that the very best apologies are specific. They acknowledge and accept accountability for the mistake that has been made, and it also addresses how one prevents it from happening again. Here’s an example from a little while ago:

The end user had been in touch with some colleagues of mine to get help from us. Long story short, we provide the platform on which they operate a service. Our internal documentation is very clear that we do not touch the service. At all. My colleague who handled the ticket asked another colleague, and was told “no, we do not handle that system, they have to look into it within their own organization”.

The end user does just that, and is met by assertions that this is inaccurate. While the customer operates the service, the issue was related to the platform. They escalate it within their own chain of command, before it’s escalated with our KAM, who asks me to weigh in. I look into it, find the original ticket, and see what has happened; my colleague – who doesn’t know neither the client nor the specific system anywhere near as well as I do – has misunderstood something or other.

Having identified the general nature of the issue, I send an email to most people involved – though I leave the two colleagues directly involved out of the recipient list. The email went something along these lines:

Good afternoon;
I would like to offer my apologies, there appears to be some sort of misunderstanding with regards to who handles what. I will inform the involved parties to ensure this doesn’t happen again.
As you are aware, the division of responsibility here is that we deliver the platform, while you own and operate the service.
I found the original ticket, number #98765432, and see that the project at issue is still active, and that <original user> has the appropriate permissions. That identifies this as a platform issue.

I next forward the same email to my two colleagues, with an addendum about some specifics that are incidental. I also talk to them about the nature of the misunderstanding, which happened to be some language in our internal documentation which was ambiguous. I rewrote the documentation, had my colleague look it over to check what I had done made sense, before following up with the client:

All concerned, a quick update:
I have discussed the issue with my colleagues who made the mistake. In our discussions, we identified ambiguity in our documentation regarding the division of responsibility. The documentation has been rewritten to prevent a repeat occurrence.

Within the space of three emails and a quick discussion, I have apologized for the mistake, and accepted accountability for it on behalf of my organization. I have also identified the root cause and taken specific steps to avoid having it happen again.

Mistakes are unavoidable. They are also an opportunity to learn, grow, and improve. Failure to do so is the biggest mistake of all.