HomeIndustry Commentary

How not to apologize: A case study

Like Tweet Pin it Share Share Email

Another reason the world won’t go Digital on schedule, heavily redacted and anonymized:

My wife is the {unspecified position} for a small, boutique {unspecified services} firm. As such, she has to process {unspecified business transactions} constantly. To help with all the needed {non-generic due diligence} (they do a lot of government work), they use a {non-generic screening service] from a fairly well known company in that space.

A few weeks ago, the screening company pushed out a new version of its software and portal.

It was a shambles! What had been a quick, routine part of my wife’s day had become a nightmarish game of frozen screens, endless time on hold, being shuffled around from one support person to another, and STILL not getting the needed {non-generic due diligence} done.

Of course, her sales department was yelling at her too, for being slow in performing the {non-generic due diligence} needed to perform the services they’d sold their customers.

About a week after the rollout, she received the following email, ostensibly from the {non-generic screening service} firm’s CEO:

============================================ 

From: {Name of CEO}

Sent: {sometime this summer}, 2018

To: {Helpless Customers}

Subject: {Our Flagship Product} Technology Update

Good afternoon,

On {date}, we released our all-new {clever acronym} screening technology. From development through implementation, our goal has always been the same — to deliver the best experience for you, our customers.

Last week’s release was the culmination of more than two years of development. It would be an understatement to say we’re excited. But with that excitement comes an awareness that this platform is far from perfect.

We fully understand that a release this ambitious and of this magnitude is bound to have issues, and you’re likely experiencing some of those issues first-hand. After the first week of wide release, many of the reported bugs have been minor. We are fixing and improving every day.

This initial launch is just the beginning of a new chapter for {company name}. We’re playing the long game — working constantly to fine-tune the technology through your feedback. We hope you already see the power and speed behind this incredible new platform. It’s only the beginning.

As we have for the past {number of years}, we’re here to help. Helpful tutorials and videos {link provided} are available in the resource center {link provided} of the {clever acronym} dashboard. And our friendly team is here to assist you in any way they’re able. Please don’t hesitate to reach out.

Thank you for your patience with us during this transition, as we work aggressively to fix bugs and improve the platform. 

Thank you for your trust in us to be your screening partner. We never take your partnership for granted and work every day to redefine value in {non-generic screening services}.

Sincerely,

{First name of CEO}

{Company logo, address and contact info}

{Inspiring quote from an old NFL football coach}

============================================

Where to start …

Communication: Groucho Marx once asked, “Who are you going to believe, me or your own eyes?” That was supposed to be comedy, not a serious business message. Don’t send spin to the people with direct experience. Send it to everyone else, to convince them the people experiencing the problem are exaggerating.

Software Quality Assurance: The first rule of SQA is that you always test. Sometimes you test before you put software into production. Sometimes you test by putting it into production.

Before is better.

Your customers’ SQA matters too. Just because you’re a cloud provider, that doesn’t mean you’re providing an “island of automation.” Quite the opposite, as SaaS becomes more important, integrating SaaS applications into the rest of the applications portfolio becomes exponentially more important (actually, polynomially more important, but let’s not quibble).

The consequence: A SaaS provider’s internal testing should be just the beginning. After that its customers should have a chance to regression test new releases to make sure they don’t break internal IT’s integrations.

Along the way, its customers’ end-users would be in a position to discover whether the new release is a turkey, before it’s inflicted on everyone.

The Cloud doesn’t change the rules. It makes them more important. For example, well-run internal IT follows a simply stated rule when it comes to implementing software changes: Always have a back-out plan. If, in spite of SQA’s best efforts, the software turns out to be unusable, internal IT restores the previous version to minimize business disruption.

Just because you’re a SaaS provider that doesn’t mean you get to ignore the basics.

You have to master them.

Comments (10)

Comments are closed.