One of our client’s web services (an API) experienced some brief downtime recently, related to an error on our part in rolling out some new data.

Things like this happen – they’re inevitable when dealing with even simple APIs and web applications. But, it’s not the downtime itself that is the main problem, it’s the communication of the issue, the solution, and the future prevention that are more important.

A first draft of our e-mail to the client had a sentence like this:

“Our sincerest apologies for this service hiccup, we always strive for the highest quality products and services and feel terribly when something like this occurs.”

This was quickly scrapped, since this sentence:

• is totally not our style. We prefer simple, clear communication, and this has a lot of fluff.

• doesn’t really say anything. It sounds a little market-y, and that’s not our job.

• doesn’t contain any details about what what happened or the solution, or how we will prevent it from happening again

Instead, we just simply outlined 3 main points:

• what caused the issue

• what we did to solve it

• what we implemented to prevent this from happening (a Scout plugin!)

Much better, don’t you think?